敏捷开发（Agile）在硬件中的应用

Posted 2021-04-25 路科验证

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放

以前用来做硬件设计和验证的方法不再适用。敏捷开发是一个新的可能。如今，硬件团队正在仔细研究软件领域的敏捷开发方法，因为，随着SoC复杂程度的不断提高，过去设计和验证的效率和正确率并没有随着提高。

开发流程需要不断更新，这样才能使得开发的效率更高，质量更好，开发成本更低以及尽量让我们的产品一次性成功。敏捷开发，一种来源于软件的产品开发方式，其支持者声称它的一些关键思想是非常前沿和有效的。

Mentor的首席验证科学家Harry Foster 认为我们要从历史的角度来审视敏捷开发的基本原理。在上个世纪的70年代和80年代，有很多大型的项目在开发，特别是有很多像发射卫星以及炸弹研制等航空航天和军事项目。那个时候已经建立了很多真正重量级的软件开发模型，典型的就是瀑布式的开发模式和V型开发模式。这些都是顺序开发模式，通常遵循一种典型的开发流程——需求分析，架构设计，设计代码，测试和维护。这些模型基本上都来源于制造业的建设方式。但是软件开发和制造开发的一个很大的不同，就是制造业的标准说明通常非常严谨，其要求也很容易理解，但是软件开发过程中说明文档有时候可能非常模糊。

软件开发人员经常抱怨开发要求不够清晰明确。Foster说，很多软件开发团队意识到他们交付的软件经常满足不了客户的需求。而且一般的顺序开发流程非常僵硬，并且任务繁重，导致设计团队无法承受。在他们把软件交付给客户之前，不得不反复地执行一些繁重冗长的流程，并且还有可能无法满足客户的需求。软件设计团队不得不设法转移到一些轻量级的设计方法上，使得软件的开发可以和用户的需求一同发展。这些对于解决软件团队当前遇到的问题是非常有意义的。

但是我们今天要讨论的问题是，硬件电路设计行业是否存在同样的问题，我们是否有可能将上述那些软件开发的方法应用到硬件开发上去。Foster认为从纯粹应用的角度来看不太可能。硬件开发中确实也有很多同样的问题，软件开发领域中确实也有很多东西值得我们硬件开发人员去学习和借鉴，并且很多东西也已经被采用了。但是我们无法在硬件开发上来实现敏捷开发过程中需要不断创建产品并交付客户这一不断迭代的循环过程。有的人可能会认为，虽然在迭代过程中我们不能够交付一个完整的芯片，但我们可以提供一个模型。硬件和软件有很多的不同，从SoC开发的角度来看，目前很多SOC都是由IP构成的，而且这些IP很多都是固定的无法简单修改，IP的使用也早已确定。如果像软件那样迭代开发，我们根本没有时间来不断更新我们的架构模型。

硬件与软件的对比

Agnisys首席执行官Anupam Bakshi认为，现在硬件开发的抽象层次已经上升到软件开发的初级地步。但是适用于软件的敏捷开发可能并不完全适用于硬件。首先“个体(individuals)，过程之间的相互影响(interaction over process)以及工具(tools)”在硬件开发中并不能从字面上来理解。不像软件其开发，基本上只需要一个编译器(compiler)，硬件开发需要依赖大量的EDA工具。同时，他也指出，敏捷开发中强调的第四个思想“响应变化胜过遵循计划(Responding to change over following a plan)”，并不适用于硬件开发，集成电路的代码是一种“硬”编码，不能经常更改。但是开发人员是可以通过配置寄存器来配置硬件电路，从而使得电路具有一定的适应性的。

Bakshi认为，如果工作的侧重点在于频繁开发某一产品，需要客户与开发团队之间的持续沟通以及要在不断变化的需求下实现产品开发的灵活性，那么“敏捷”的开发方式可以作为一种高效的硬件开发方式。

与此同时，Sonics的首席技术官Drew Wingard指出，我们在思考硬件设计团队能从软件的敏捷开发中学习到什么的时候，要注意芯片开发和软件开发之间有一个非常关键的区别，芯片设计有一个所谓的“掩膜集（Mask set）”，而在软件当中存在的“敏捷掩码集(agile mask set)”在硬件中毫无意义。

但是他同时也指出，敏捷开发的一些思想在其他领域是很有效的。比如敏捷开发中有一个迭代(Sprint)的概念即在一个很短的时间内明确一系列关键的目标，然后尽可能快的完成这些目标，并努力在这一过程中了解这些任务。这与传统的芯片开发方式有着很大的不同，因为一个迭代周期里面的目标和要求往往不会非常完整。这种迭代的概念要求我们一边想办法去完成当前目标的同时一边去探索新的可能，这与传统的瀑布式的开发方式非常不同。虽然瀑布式的开发方式有很多优点，但大部分都是来源于我们设计芯片时层次化的思考方式。设计芯片的过程是最终我们会得到一个掩膜数据库，通常就是GDS II。但是在得到这个数据库的初始版本之前，我们要进行电学设计规则检查，版图设计规则检查，版图与原理图一致性检查。经过不断反复，得到电路的布局布线。至此你仅仅只进行了逻辑综合和测试电路的插入。然后还需要继续将各个芯片组件集成在一起，再次进行逻辑电路设计以及混合信号电路设计等等。最终我们将我们的设计架构，算法，以及设计理念以硬件电路的形式表现出来。

瀑布式的开发方式有一个很显著的特点就是所有上述的那些任务都是分开进行的。Wingard指出，在芯片开发中我们能明显感觉到，如果一个步骤没有被充分确认完成就进行下一个流程其带来的风险太高了，完全不值得这样做，这是与软件敏捷开发的思想完全不同的。

Wingard也指出，在软件设计中，敏捷开发指导我们，尽量集中在少的任务上，并尽可能地深入至需要我们达到的程度，把重点放在我们最担心的或者对其他部分有很大影响的那一部分上。我们只专注于整体功能的某一部分，所以我们需要关注诸如接口之类的东西，我们还需要关注很多与项目相关的测试套件，这些测试套件可以帮助我们确认即使我们只实现了一部分功能但在整个项目中这一部分功能也是正确的。事实上，在很多敏捷开发项目中，都是先编写测试框架，然后尝试实现测试套件里面的软件功能。他们没有编写规范，而是将测试作为规范。通过对比软件设计和硬件设计我们确实会发现很多有趣的东西。

敏捷思想在硬件中的应用

虽然采用速度缓慢，但是越来越多的证据表明，硬件工程师们正在逐步接纳某些敏捷开发中的思想理念。

 Wingard回忆说，十年前当工程师团队讨论芯片的设计节点的时候，首先有一个顶层编译，然后他又开始接触到工程师们把零级编译(Compile Zero)也被作为一个项目节点。零级编译就是在第一次编译之前存在的顶层对象。那这意味着什么呢？这意味着硬件工程师们正在有意识地去处理不完整的信息，因为他们想尝试去做出一个芯片的初始蓝图，并进行一些其他的设计规划。同时他们也想在芯片设计开始之前就去测试他们用来编译整个芯片的工具以及其他基础组件的功能。工程师们同时也希望即使芯片设计还没达到50%的地步，他们也可以看到时钟域分区或者功耗分布以及DFT模块的大致情况。在Wingard看来这就是一种敏捷开发的方式，但是仍然有很大的包袱在里面。

需要特别指出的是，附加的工具是非常重要的，可以更好地帮助硬件设计人员处理不完整的信息。

或许敏捷开发更多的帮助是在便携式测试平台的开发上。他们希望不用编写规范文档而是使用测试工具的内容作为规范。所以更青睐于敏捷开发，使得他们能轻松地将测试组件自动移植到不同的环境中去。

Cadence公司系统与验证组产品管理高级总监Frank Schirrmeister观察到，敏捷开发的另一个应用领域介于模拟验证与FPGA原型验证之间。他说：“我们提供很多类似的编译器，你完全可以以一种敏捷开发的方式来进行设计，当时你的设计还没有稳定的时候，你可以使用不同性能的编译器来辅助开发。一旦你的设计稳定下来，需要高速运行你的硬件设计来进行软件开发的时候，你就可以切换到FPGA原型验证。”

敏捷的定义

XtremeEDA的首席咨询师Neil Johnson认为，敏捷是一个非常宽泛的词，可以包含很多不同的东西，一提到敏捷开发，人们最常想到的就是持续开发或者增量式式开发。假设你在开发一个软件，采用增量式的开发方式，那么实际上在每一个增量结束的时候，这一阶段的产品开发也就结束了。不论是将软件部署到网页上还是其他任何地方，递增式开发总是非常容易的，这也是为什么软件可以逐步开发和增量部署的原因。但是对于硬件开发人员来说，这一开发方式非常不友好，尤其是对于ASIC芯片的开发，渐进式概念并不适合。

Neil Johnson同时也认为敏捷开发不应仅仅只局限于增量开发和渐进式的部署。我们有明确的技术实践比如测试驱动开发(test-driven development TDD)，这就是一个非常有效的应用。单从技术实践来看，测试驱动开发(TDD)非常具有实用意义。其中构建跨职能团队的思想对于SoC团队来说非常具有价值。我们无法否认，与硬件设计团队相比软件团队的成员之间的协同合作更加容易。这一点在硬件开发上显得非常重要。构建共享工作空间并不是说一定把硬件开发人员和敏捷开发方式结合起来，而是一种非常简单的工作方式，就像是我跟我一起工作的人坐在一起，我直接问他们问题，而不是发送电子邮件或提交错误报告或者是借鉴敏捷开发团队中成员之间的沟通方式。

如果将敏捷开发视为一个整体，整个方案最终将渐进式地部署结束。这样的方案可能很难让其他人接受。如果我们分解开来看，关注敏捷开发的思想或者了解增量部署的好处，根据实际情况将其应用到我们的项目中，可能会比单纯的使用增量部署更有意义。因为并不是所有的敏捷软件开发团队都在使用增量部署的方式，相反很多人都是在一个共享的工作空间内相互协同工作，并且都坚持要达到零缺陷。很多人都能够接受像测试驱动开发，结对编程(pair-programming)等等开发方式，所以相比把整个敏捷开发融入我们的开发方式中，分解开来，然后按实际情况放入我们自己的方法论中会更容易。

那么到底是什么导致了敏捷开发一直被硬件工程师拒之门外呢？硬件工程师在做决策的时候非常小心谨慎。Neil Johnson说：“我们之所以不喜欢接受新的方法，是因为我们不想抛弃我们的历史记录。作为一名验证工程师，我会查看随机验证的随机记录或者是UVM打印的记录，并基于这些记录来决定我应该对结果持有多大的怀疑。我们喜欢坚持我们喜欢的东西。例如我们相信随机验证能真的帮助我们发现问题，想信统计出来的故障数量，缺陷率等。不是我们总对新技术持批评的态度，而是往往这些新的技术都没有可信的历史纪录。”

路桑说

在4、5年前的时候，路桑所在的公司挂起过一阵shift left的暴风，宣传要将软件开发提前，硬件开发再拉近到硬件架构期。一个主要目的就是为了让芯片研发从架构到硬件实现再到软件开发的链条能够更加高效，并且更快响应用户的要求。好事是好事，而且关于shift left的战略在每家大公司也都有一些口号和影子。那一年的潮流就是提出了移植敏捷开发的理念，而我竟然还就信了，于是乎研究了好多敏捷开发的方法模式。那几年（也包括现在），最火的莫过于Scrum了。而在认真学习研究了一阵子之外，我的观点也跟上面文中采访的几位大咖一致，那就是敏捷开发无法整套照搬到硬件开发中，因为一个致命的而且目前看来依旧无法解决的问题在于，敏捷开发所倡导的背景在于软件开发的工具环境相对单一，试错成本低可以增量式开发，也能够容忍未知的不确定性。

然而，芯片的开发无法渐进，更不能在开发的过程中进行增量式的修改矫正或者功能特性的添加。硬件开发从立项到架构，再到硬件开发、后端综合、测试链插入，继而流片封装上板调试，可谓是经过九九八十一难才能到软件开发的环节。而在这些繁复缜密的环节中，很难允许有增量式的开发，因为一旦有功能特性的显著变化，就意味着“取经”需要从头来过，而这一从头又得花费数周的时间，其增量方式所带来的人力成本要远远胜于在软件开发周期的成本。不过，敏捷式开发的优点例如结对式编程，测试驱动式开发仍然值得硬件开发所借鉴。例如路桑之前的一篇关于SV单元测试的开源测试包就是针对测试驱动式开发模式。

同时，文中有一句话值得特别注意，“敏捷开发更多的帮助是在便携式测试平台的开发上。他们希望不用编写规范文档而是使用测试工具的内容作为规范。所以更青睐于敏捷开发，使得他们能轻松地将测试组件自动移植到不同的环境中去。”这句话在于表明，测试驱动式开发很有可能用来实现跨开发小组的效率提高。因为通过简单易懂，共同的便携式激励测试语言可以被结构、硬件和软件组的工程师所理解，继而在不同的环节利用相同的测试套件，可以保证实际的测试场景贴合软件需求，同时也能将硬件验证周期的测试代码移植到软件环节，真正实现跨开发小组的“巴别塔”建设。

在当时，全公司都在呈现出一种追逐敏捷，应用Scrum的态势时，不过我所观察到的最终结果是，真正能够有敏捷移植土壤的只有软件开发小组，而这种简单的方法移植也仅仅是从传统软件开发应用到了硬件公司的软件开发，难度并不太大。而敏捷开发在硬件开发的更多贡献必定需要它的一次重生，或者说，一次结构性的改良，比如我们提到的便携式激励的范测试模式（general test mode）。

所以，当年公司推广的硬件敏捷开发潮流就那样声势越来越小，最后就不了了之了。

原文来自于 Semiengineering"Using Agile Methods for Hardware"

https://semiengineering.com/using-agile-methods-for-hardware/

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。