为提高软件代码质量而创建的敏捷方法越来越多地应用于硬件验证。

这不像它最初出现的那样急剧变化。开发验证测试平台主要是软件，但是类似的方法可用于减少硬件中的错误。

开放的开发架构框图

“测试平台只不过是一个大型软件项目，在这里采用敏捷开发过程非常有意义，”西门子公司Mentor的首席验证科学家Harry Foster说。 “[SystemVerilog]采用了Verilog，并使用新的面向对象的结构对其进行了扩充，从而促进了必须集成并开发到测试平台中的现代代码。在此之前，我们创建了测试 - 并且仍在使用C，C ++和SystemC。“

但是，使用敏捷开发方法并不是那么简单。 “有很多硬件组都希望将Agile（敏捷）用于硬件开发，但敏捷从来没有考虑过硬件，所以存在差异，”福斯特说。

电源管理芯片开发流程（示意图）

要理解为什么，有助于牢记敏捷开发的关键结构：

• 个人和流程与工具之间的互动。
• 通过综合文档处理软件。
• 客户通过合同谈判进行协作。
• 响应遵循计划的变更。

“硬件开发过程涉及许多工具和流程，这样做是为了确保可重复性和质量，”福斯特说。 “因此，敏捷，个人和流程与工具之间的互动的第一个关键方面成为一个问题。软件开发从来没有真正具有那么多的可重复性。我将无法按下按钮并获得相同的结果。它更像是一个创造性的过程，因此与软件开发相比，软件开发工具更少，而且流程更不正式。“

Scrum 架构

即便如此，许多项目已将敏捷开发过程的各个方面纳入硬件领域，包括军事和高端服务器。 “我知道一些硬件项目已经采用了scrum Agile框架，特别是sprint，因此当他们创建他们的RTL代码时，他们就会开始做一点点冲刺，一次添加一些小功能，”他说。 “这非常成功。另一件真正成功采用的是持续整合。“

尽管持续集成在硬件领域取得了一些成功，但仍然存在问题。具体来说，在持续集成之前，工程团队会开发RTL，然后同步多个签到，因此在一天结束或每隔几天会有多个IP。然后整合噩梦就开始了，因为一些集成的东西会破坏其他东西，而工程团队通常不知道为什么。

通过持续集成，当检查某些内容时，它会进行回归测试。如果它不起作用，其他人可以继续工作，这简化了调试过程。

“[持续集成]与敏捷完全契合，”Cadence系统与验证集团产品管理总监Larry Melling表示。 “当你正在调整并做出这些改变时，真正激发其能力而不失去控制的是持续集成，其中有一个非常可靠的测试和回归验证方法。随着变化的发生，您可以快速验证，看到您没有破坏东西，或将设计带到不稳定的地方。如果你在没有验证的情况下做了太多的改变，那么你可以把自己带到一个不稳定的地方并挖一个洞，让你很难走出困境。到目前为止，敏捷和连续集成或接近持续集成的东西几乎是成功部署它的必要条件。“

幸运的是，尽管硬件世界的采用可能相对较新，但在过去二十年的大部分时间里，这里的工作一直在进行，仿真产品管理和营销，基于FPGA的原型设计和硬件的高级组主管Frank Schirrmeister说。 / Cadence的软件支持。 “一旦这个行业有了一个术语，就可以更容易地谈论它，但它已经在很多半导体公司的使用模型中使用了很长一段时间。这是能够尽早开始硬件和软件集成的概念，然后在每次更改时，验证您没有破坏任何先前的测试，然后在抽象级别进一步优化测试，添加更多需要定时的测试，添加更多需要甚至门级类型定时的测试，这样的事情。现在，在持续集成中可以更好地捕获它。“

集成的自适应EA驱动的敏捷开发方法

这预示着要采用和应用敏捷方法。

“例如，从敏捷的角度来看，我们确实看到了像scrums工程团队那样的，正在关注产品的功能开发，“Shirrmeister说。 “他们可能会说，'本周，我们正专注于这三个功能的调查。'在这种情况下，我们的情况是，在验证中，您有这个验证计划。在敏捷中，随着时间的推移，还会有一些验证焦点，你可以说，'我现在专注于视频子系统。其中一些可以并行运行，但可以运行其他子系统进行验证。然后，有一些焦点非常类似于您在敏捷方法中的scrums或sprint中看到的焦点。但是比软件部分更重要的是，你需要确保不要破坏任何以前的测试，这样回归就会随着你的努力而增长。“

OneSpin Solutions的技术营销经理Sergio Marchese指出，他的公司采用了许多敏捷技术进行研发。 “在硬件方面，虽然有一些共识认为敏捷可以减少开发浪费并促进更合作的工作环境，但采用率有限。其中一个例外是验证，特别是形式验证。“

作为验证工程师，他在应用敏捷原则方面拥有许多成功经验。 “敏捷硬件开发的一个主要好处是，识别和修复错误以及验证新RTL版本的周转时间可以在复杂项目中从几天到几分钟大幅缩短，”他说。 （见下图）：

图：敏捷的优势。资料来源：OneSpin解决方案

正式验证工具可实现此类流程。 “设计师可以自己使用正式工具来执行自动检查，并快速探索复杂的设计功能，而无需模拟测试平台，”Marchese说。 “他们还可以与验证工程师并肩工作，以结对编程的形式开发端到端断言，旨在提供正确的代码迭代。成功的最终衡量标准是传统的非敏捷验证应该找到很少甚至没有错误。“

挑战

尽管如此，这并不总是那么容易。

“虽然硬件社区越来越关注敏捷方法，但由于其在软件项目上的成功，很明显，如果没有一些适应性，敏捷方法不能应用于硬件项目，”Marchese说。 “此外，旨在完全接受敏捷的公司需要改变他们的工程文化，这是一个渐进而复杂的过程。”

还有其他挑战。 Meilling说需要有一个安全网，这是一个连续的整合件。此外，重要的是不要忽视设计的路线图。

“这是敏捷的真正风险之一，”Melling说。 “你进入日常的操作实践，说'我们需要做到这一点，我们需要这样做'，并且非常非常重要的是，顶级环境不会丢失。团队应该说，'等一下，我们正在创造这个产品，使用功能都必须在那里。'不要陷入忽视目标并加倍努力的陷阱。验证计划需要与需求可追溯性相关联。这些是可以让你立足于路线图的事情。“

Schirrmeister说，另一个使持续集成工作成为可能的组件是Portable Stimulus。 “在这种情况下，验证重用的概念是巨大的，因为一旦你在项目流程中再过三个月，你就不能在新环境中重新开始重写相同的测试。验证重用的数量肯定会在未来变得更加重要，这使得这种敏捷性能够重新使用之前的验证测试，对其进行优化并对其进行改进。

在硬件验证中使用软件中常用的敏捷开发方法

结论

可以肯定的是，敏捷流程正在不可避免地进入半导体设计和验证。

“通常，迭代设计和测试组件被集成到连续运行的回归环境中，”Breker Verification Systems首席营销官Dave Kelf指出。 “像GitHub这样的存储库允许一定程度的自动化和基于云的环境将进一步改善这一过程。提供在系统级别运行并可移植到不同验证引擎的抽象测试平台将构成敏捷回归环境的支柱。可以选择意图规范的各个元素来针对特定的设计组件，同时收集全局覆盖度量。“

经过多年的讨论，这才刚刚开始在设计界崭露头角。

“敏捷今天在这里进行验证，如果人们不这样做，他们应该调查它，”Mentor的福斯特说。 “这是一种非常有效的方法，可以加速，提高工作效率，并在创建测试平台时准确地提供客户所需的内容。”

(完)