为提高软件代码质量而创建的敏捷方法越来越多地应用于硬件验证。
这并不像乍看起来那样剧烈。 开发验证测试平台主要是软件,但可以使用类似的方法来减少硬件中的错误。
开放式开发架构框图
“测试平台只不过是一个大型软件项目,采用敏捷开发流程在这里很有意义,”西门子公司 Mentor 的首席验证科学家 Harry Foster 说。 “[SystemVerilog] 采用 Verilog 并用新的面向对象结构对其进行了增强,促进了必须集成并开发到测试平台中的现代代码。在此之前,我们创建了测试 - 并且仍然使用它们 C、C++ 和 SystemC”
然而,使用敏捷开发方法并不是那么简单。 “有很多硬件团体希望使用敏捷进行硬件开发,但敏捷从未考虑过硬件,所以这是有区别的,”福斯特说。
电源管理芯片开发流程(示意图)
要理解原因,记住敏捷开发的关键结构会有所帮助:
“硬件开发过程涉及许多工具和流程,这样做是为了确保可重复性和质量,”福斯特说。 “因此,敏捷性的第一个关键方面,个人与流程和工具之间的交互成为一个问题。 软件开发从未真正具有如此高的可重复性。 我无法按下按钮并得到相同的结果。 它更多的是一个创造性的过程,所以工具更少,过程也不像软件开发那么正式。”
Scrum架构
即便如此,许多项目已将敏捷开发流程的各个方面融入到硬件中,包括军用和高端服务器。 “我知道一些硬件项目已经采用了 scrum 敏捷框架,特别是冲刺,因此当他们创建 RTL 代码时,他们开始进行小冲刺,一次添加一些小功能,”他说。 “它非常成功。另一个真正成功采用的方法是持续集成。”
尽管持续集成在硬件领域取得了一些成功,但仍然存在问题。 具体来说,在持续集成之前,工程团队会开发RTL,然后同步多个签入,因此一天结束或每隔几天就会有多个IP。 然后集成噩梦就开始了,因为集成的某些东西会破坏其他东西,而工程团队通常不知道为什么。
通过持续集成,当检查某些内容时,它会进行回归测试。 如果不起作用,其他人可以继续工作,这简化了调试过程。
“[持续集成] 与敏捷完美契合,”Cadence 系统和验证小组产品管理总监 Larry Melling 说道。 “真正让您在适应和进行这些更改时不失去控制的能力是持续集成,其中有非常强大的测试和回归验证方法。当更改发生时,您可以快速验证,看看您没有破坏东西,或者将设计带到一个不稳定的地方,如果你在没有验证的情况下进行了太多的更改,你可能会把自己带到一个不稳定的地方并挖一个让你很难摆脱敏捷和持续集成的困境。或者类似的东西几乎是成功部署它的必要条件。”
幸运的是,虽然在硬件领域的采用可能相对较新,但在过去二十年的大部分时间里,这项工作一直在进行,由仿真产品管理和营销、基于 FPGA 的原型设计和硬件的高级集团总监 Frank Schirrmeister 负责说。 /Cadence软件支持。 “一旦行业有了一个术语,谈论它就更容易了,但它长期以来一直存在于许多半导体公司的使用模式中。 它的概念是能够尽早开始硬件和软件集成,然后每次进行更改时,验证您没有破坏任何先前的测试,然后在抽象级别进一步细化测试,添加更多需要的测试时序软件项目管理与敏捷方法,添加更多甚至需要门级类型时序的测试,诸如此类。 现在,处于持续集成中。 可以更好地捕捉它。”
集成自适应EA驱动的敏捷开发方法
这预示着敏捷方法的采用和应用。
“例如,从敏捷的角度来看,我们确实看到像 scrums 这样的工程团队专注于产品的功能开发,”Shirrmeister 说。 “他们可能会说,‘本周,我们将重点研究这三个特征。’ 在这种情况下,我们的情况是,在验证中,您有这个验证计划,随着时间的推移,您可以说,“我现在专注于视频子系统”。其中可以并行运行,但可以运行其他子系统进行验证,但比软件部分更重要的是,您需要确保不会破坏任何先前的测试,以便回归随着您的努力而增长。”
oneSpin Solutions 的技术营销经理 Sergio Marchese 指出,他的公司使用许多敏捷技术进行研发。 “在硬件方面,虽然人们一致认为敏捷可以减少开发浪费并促进更具协作性的工作环境,但采用程度仍然有限。 一个例外是验证,特别是形式验证。”
作为验证工程师软件项目管理与敏捷方法,他拥有许多应用敏捷原则的成功经验。 “敏捷硬件开发的一个主要好处是,在复杂项目中,识别和修复错误以及验证新 RTL 版本的周转时间可以从几天大幅缩短到几分钟,”他说。 (见下文):