随着敏捷方法的建立提高了生产力和质量，业界对于硬件设计的兴趣正在增长。
尽管如此，人们普遍认为硬件领域的成功依旧是有限的。现实可能比想象要好一些，因为硬件中的某些敏捷性趋势没有明确标记。
例如，我们看到越来越多的努力将 IP 级设计和验证与 SoC 级设计和验证分离。在这种情况下，不同的 IP 团队都从 SoC 项目的“列车模型”上以异步的方式运行，当完成 SoC 设计时可以选择任何版本的 IP。
虽然这种方法没有被贴上敏捷的标签，但这种方法确实符合敏捷哲学。
敏捷设计发展的最大阻力 —— 算力
芯片流片的高成本和流片后无法更改设计通常被认为是敏捷方法不能很好地映射到到硬件设计的关键原因。但是，流片后无法敏捷并不一定意味着我们不能在流片前更加敏捷。
在硬件设计中采用敏捷性设计最大阻力之一是硬件验证的复杂性。测试软件程序只需要执行该程序所需的计算，当然测试会全速运行。
测试硬件设计需要一个模拟器程序，该程序可以在软件中模拟芯片设计在硬件中制造时的行为。这个模拟器程序的计算非常昂贵，但其执行速度比它正在模拟的真实芯片的速度慢数千倍。
设计硬件的公司在测试其设计时会受到计算能力的限制。几家支持系统设计的公司都提供特殊的仿真加速器，它们使用专为仿真加速而设计的专用处理器或 FPGA。这些系统的模拟速度比通用服务器上的模拟快数百倍，它们的成本也相应地更加昂贵。因此，设计团队发现他们在这些平台上的计算资源同样有限。
敏捷设计需要持续集成和测试，不仅是单元级别，整个系统级别同样如此。如果测试受限于计算能力，那么敏捷设计需要更高的计算效率，尤其是在系统级别。例如，一个典型的现代 SoC 需要在数千台机器的服务器群上进行长达五天的连续计算来完成一组基本的完整芯片测试。
在如此极端的计算背景下，设计团队如何才能让芯片设计变得更加敏捷?
解决敏捷计算挑战的两个方法
有两个关键方法可以推动解决敏捷硬件设计中的计算障碍：通过参数化减少设计规模和通过计算物流，计算物流涉及使用计算和高等数学来规划和实施大型和复杂的任务。计算物流应用于许多领域，包括货物、服务和相关信息从原产地到消费地的流动和储存。)减少测试规模。
第一，参数化。复制在 SoC 设计中越来越普遍，无论是 IP 级复制(如多核 CPU)，还是架构级复制(如 GPU 中的着色器内核或 AI 加速器中的 MAC 节点)。通过利用参数化，可以在某种形式的参数化下将更多相似但不同的事物融合在一起，从而显着增强复制的范围。
设计中的复制越多，自动生成设计的缩减配置的可能性就越大，这些配置更小但对测试仍然有意义。参数化的使用越复杂，在 SoC 级别最小化用于测试特定功能的设计尺寸就越灵活。
System Verilog 等主流硬件描述语言 (HDL) 已经很好地支持复制和参数化，但可以通过采用更高级的语言作为 HDL 生成器来进一步启用它们。例如，SystemC、Matlab、Python 或 Chisel。与分离 IP 和 SoC 级设计的趋势一样，采用高级语言进行硬件设计也出现了类似的趋势。
至于计算物流，如果我们在敏捷设计方法下持续集成和测试，那么每次集成和测试都是对之前的集成和测试的增量。对于给定的增量设计更改，计算逻辑意味着自动确定最佳设计配置、测试集和测试配置，以便以最低的计算成本提供良好的验证质量。
可以将其视为一类新的 EDA 工具 —— 一个引擎在完整的验证流程中控制所有其它引擎。
我们看到了通过计算物流提高验证计算效率的巨大潜力，特别是如果期待异构的、基于云的未来，在广泛的模拟和仿真平台上可以对无限使用容量进行计费。正如计算物流改变了 UPS 和 FedEx 等运输公司的包裹吞吐量一样，它也可以改变硬件设计中的验证吞吐量。
总结
硬件设计已经变得更加敏捷，但仍有很大的改进空间。与软件验证相比，这种改进的一个关键障碍是硬件验证的巨大计算成本。
通过利用复制、参数化和高级语言作为 HDL 生成器，我们可以最大限度地减少测试中的设计尺寸。
通过采用计算物流，我们可以最大限度地减少测试工作量并进一步优化测试中的设计尺寸，尤其是在支持云的未来，以及基于使用无限制验证计算的可用性。
