OOP（面向对象）的硬件设计思路就够头疼了，还搞什么AOP？

Posted 2021-05-01 路科验证

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

原文来自于 Semiengineering"Poised For Aspect Oriented Design?"

https://semiengineering.com/poised-for-aspect-oriented-design//

面向方面的设计方法（aspect-oriented）能否帮助我们更快更好地完成电路设计呢？一切都还是未知，虽然这些技术在验证领域的初步尝试并不成功。

1992年，Yoav Hollander就试图将面向方面编程（AOP: Aspect-oriented programming）这一软件编程的思想应用到硬件验证当中去。后来这些思想被融入到了e语言（e-language）当中，并借助Verisity进一步形成了商业化的产品。

Hollander很早就发现，使用面向对象技术（Object-oriented）能够将测试平台的抽象程度提高到寄存器传输级之上，但是如果增加一些面向方面的功能将能够使得测试平台更加灵活，甚至可以将RTL的更新作为测试平台的一点补丁而不用重写整个测试平台。

在那时,e语言的应用是测试平台构建方式的一个重大改进，虽然得到了Cadence公司的大力支持，但自从SystemVerilog和UVM测试方法学的出现以来，其使用率一直在下降。验证的发展能给我们提供一点经验来帮助改进设计流程吗？

如今，许多设计都是围绕着一个平台。这个平台可能已经验证完备了而且在硅片上也已经验证功能完全。但是如果我们要添加一个新的外围模块呢？那么要改变多少的系统代码呢？有多少部分需要重新验证呢？又或者是另外一种情况，设计代码保持不变但是需要增加低功耗的特性，这时候是不是就不必去改变任何已经被验证完备的RTL代码了呢？

Mentor Graphics公司的验证技术专家Tom Fitzpatrick解释说，AOP（面向方面编程）就是要在已有的代码中添加一些新的功能点而不用去改变内部的代码。虽然这正是行业所希望实现的，但是这是否现实呢？

Wingard注意到，与实际的硬件设计人员相比，制定硬件性能模型架构的工程师和习惯抽象底层硬件模型的验证人员之间存在更多的默契。这或许也可以表明面向方面编程(AOP)更适合在更高的抽象层次上使用，而不适合将其用于RTL设计相关的流程当中。

Wingard继续说：“当我们进行性能分析时，我们首先要制定一个使用模型，并可以从中映射出一种使用场景。例如对一个给定的SOC来说，硬件设计团队往往关注的是该SOC一些极其重要和典型的使用案例。这样我们只需要适当地调整内存的大小以及合理的配置内存和网络来满足内核的吞吐量要求即可。”

功耗是否也类似呢？我们是否能够使用面向方面编程（AOP）来指定设计的功耗特性呢？如果这样的话我们是不是就可以在不修改设计功能性代码的前提下实现该设计的功耗特性呢？Wingard看到了一些相似性以及进一步协同设计的可能性。我们设计了一系列的使用案例，从中我们可以映射出一系列工作场景。我们在这些工作场景中测试功耗并希望在这些运行场景中可以表现出良好的低功耗特性。我们可能会问功耗和性能之间有什么可以协同设计的地方吗？答案是它们之间大约会有80%的交叉部分。为了优化电路网络拓扑结构而进行的抽象场景描述，和为了提高系统性能而设计的内存特性以及为了降低功耗而优化的电源域设计等均存在着可以协同设计的可能。”

那么为什么工业界还没有快速切换到面向方面编程（AOP）呢？

功耗可能存在问题

Janick Bergeron是Synopsys公司的一名研究员，同时也是e语言的熟练使用者。他认为面向方面编程（AOP）的问题在于，虽然其在解决某些类型的问题上非常强大，但它同时也有很大的风险。“作为一名IP设计者，我希望知道我的设计最终在执行什么，如果任何人都可以使用我的代码，替换它，扩展它，以我无法控制的方式修改它，这将使得我的技术支持成为一场噩梦。我需要知道确切的代码，以及确切的执行方式以此来重现发现的问题。”

Mentor公司的Fitzpatrick也同意，他说，关于AOP的主要抱怨就是，你必须非常小心，否则很容易陷入困境。但是业界也有一种eRM的解决方法来帮助我们避免这种问题。并且从那以后，类似的功能被带入了UVM。UVM侧重于面向对象这一部分，我们可以通过扩展一个基类来创建一个新类，并使用工厂机制来交换(swap)它们。这样追踪你最终的结果就要容易得多。虽然这样可能需要多编写一点的代码，但是它却可以在不牺牲很大的灵活性的情况下给予我们很方便的控制能力。

Bergeron也发现了AOP的扩展性问题。“当这个项目是一个小型的IP核时，AOP还可以发挥很大的作用，但是随着设计的规模越来越大，它就成了管理的噩梦。”

敏捷开发和面向方面编程

敏捷开发也是在当今获得相当多关注的另一种技术。敏捷开发已经开始逐步取代已建立的采取渐进式的瀑布型开发方法。看起来面向方面编程似乎是对敏捷开发的补充。

Bergeron说：“面向方面编程允许我们从外部完成敏捷开发所要求的漏洞修复和迭代。所以如果我现在更改我的基础代码并扩展它，我现在或者以后是否会承担相应的技术债务（technical debt）呢？”Bergeron将技术债务定义为通过走捷径而积累的一种类似于惯性或者熵的术语。“反正你最终必须付出相应的代价”Bergeron补充到。

所以Bergeron看到了AOP支持协同开发的特性，但并不看好它的适用性。他认为AOP会积累很多上面提及的技术债务，但是敏捷开发恰恰相反，它是尽可能地去减少这种技术债务。AOP非常适合去做测试，因为这是产品开发的最后一项工作了。对于任何基础架构性的或者需要可重用的部分，他建议不要去使用AOP因为你不能很好地去控制它以及保护它。

其他方法

问题在于，如何在不增加技术性债务的前提下充分利用AOP的优势呢? Bergeron解释说：“AOP试图将所有交叉相关的代码组合在一起。您也可以使用纯粹的面向对象编程来完成上述事情，将所有类的扩展和回调放在一个文件里面即可。这是一个代码组织和方法论的问题。”

Fitzpatrick表示，他们已经在SystemVerilog和UVM的工厂机制中做了类似的事情。

AOP在设计中的应用

Bergeron提出了一个AOP应用到设计当中的假设。“AOP可能与设计相关，因为设计都没有可能面向对象。设计是一个固定的结构性的东西。如果你有一个设计的模块，并且想添加一些新的功能，你是不可能基于这个模块来扩展出一个新的模块。模块上没有虚拟的东西可以被用来做扩展。我们必须修改整个设计文件。如果这样做的话我们就相当于创建了一个新的模块，并且我们必须还要修改之前的验证环境来验证之前保留的功能以及添加的新的功能是否正确。但是如果我们在设计模块上定义一些面向方面的东西呢？通过这个来添加一些新的功能以及一些新的端口，这样的话原始的模块仍然存在，保留的功能不需要再验证而只需要为新添加的功能搭建一个测试平台。”

Fitzpatrick表示他并不急于将AOP应用于设计当中。“在设计团队当中，硬件设计人员甚至都不愿意用面向对象的思想去思考问题，更不用说AOP了。如果盲目去使用AOP来设计电路可能最后就会是一些意大利面条式的代码。并且我还不确定是否要告诉设计团队我们有能力使用AOP来进行RTL设计。”

看起来采用统一功耗描述形式(UPF: Unified Power Format)就可以定义出硬件电路的功耗特性。Bergeron说：“我们确实需要定义AOP这一单一的编程语言要包含的所有东西。一般来说执行语义（execution semantics）是由各个相关的方面来定义的（defined by adding the aspects ）但是功耗不会影响执行语义，它只是从一个不同的角度来表征硬件的运行情况。功耗会影响最后的电路实现，所以从这个角度来看，功耗和RTL功能是两个不同的方面但它们并不是面向方面的编程（AOP），因为你需要使用不同的编程语言。”

Calypto产品营销总监Anand Iyer说，UPF描述的是硬件电路的一个方面，但是我们还没有一种工具能够将UPF按AOP的形式来使用。许多项目开发后期所使用的工具都面临着很大的挑战，这些工具很难将硬件电路的各个方面都综合在一起。并且想要弄清楚各个方面的相互影响，我们仍然需要进行性能分析，而这都只能在项目开发的后期出现。

Fitzpatrick仍然担心一些AOP模型不能完全适用的情形。他说：“从编写代码的角度来看，我更喜欢所有的东西都只存放在两个地方，无论是在模块定义中还是在该模块的UPF规范当中。这样你完全能够清楚哪项功能是在哪里实现的，而不必担心我的编译器可能会链接到其他的一些代码从而修改一些我很满意的东西。”

Fitzpatrick也看到了一些优势，我们确实想将传统验证所关心的逻辑上的功能与一些会增加验证复杂性的附加功能分开。就像将硬件的功耗作为一个独立的功能方面来进行验证也是非常有意义的。我们可以确保在进行功耗设计和验证之前，RTL的功能是正确的。这样就把RTL的功能问题与电路的功耗问题分开了，使得我们既可以分开考虑又可以把他们放在一起综合分析，这是非常强大的。

并不是每个人都将UPF视为自上而下设计过程中的一部分。Wingard认为UPF是一个抽象概念，对那些有功耗要求的硬件的设计非常有帮助。我们将设计网表按照实际物理电路的要求划分，然后自动创建与之相匹配的UPF文件。Wingard将UPF看作一种说明文档。我们都希望每个IP都有一个相应的UPF文档，用来描述该IP的功耗特性。这样在顶层集成的时候我们就能知道我们的芯片要负载多少个电源域？我们是否要在每个电源域周围增加电源隔离单元？我们应当如何减少电源域和电平的总数使其能达到一个可控的水平？当我们为各个电源域开发功耗控制单元的时候，需要确保它们与UPF的描述一致。

未来的展望

多年以前Gary Smith和我有一场持续数年关于电子系统层级抽象ESL（Electronic System Level）的应用的讨论。虽然Smith专注于设计工具的开发，比如高层次的综合工具。但我始终认为只有在解决了抽象设计的建模和验证之后这种工具才有可能完全成功。现在还有很多问题没有解决比如要验证哪些方面，如何验证这些方面。这些问题没有解决，ESL的价值将会一直被质疑，并且设计的流程也将无法确定下来。

Wingard表示：“ESL所面临的挑战是如何将投资回报率(ROI)提高到芯片架构师愿意投资一些新工具的水平。现在大多数SOC架构师还在使用电子表格来帮助设计。如果我们能捕获一些实际工作场景的详细信息，并且这些信息可以被用来驱动系统模型以此来评估系统性能或者来驱动电源架构，这样的工具更有可能被他们采用。”

Accellera便携式激励工作小组的努力可能会提出更好的方式来描述工作场景，从而推动未来的验证和设计方法。

路桑说

一切的一切终将归于虚无。EDA和这些首席们考虑问题的时候都是登高望远，用“抽象”、“哲学”的系统性思维来考虑next step。路桑并不是这里专门跪舔这种吃一年种三年的长远眼光，而是觉得无论你的身份是设计、验证、后端还是EDA，随着经验的提升，都需要往形而上，高层次的地方去探照IC设计这座冰山。我们每个人的日常都只是那冰山表面的1%，至于剩下的部分，可能需要我们更多的时间，从更多的人和case那里收集到项目中的痛点在哪儿，用什么方式去黏合，甚至从方法学层面上来继承原有的优点而再推出新的流程。

比如文中提到的eRM方法学，路桑也是曾经的拥趸。除了谈到的AOP的编程思想，这种“打补丁不伤衣”的方式在当时写测试用例的时候真是懒人的帮凶。还有e语言的天生柔软性，软到几乎你想要让它做的事情它从随机约束、覆盖率、断言、验证结构都已经覆盖到，20年前啊神思路啊。再来看看SV后来居上之上，发生了什么——将e语言原来的OOP和AOP的双臂断了一臂，为什么？已经那么牛X了，怎么还会倒退？这跟文中加粗字体的项目吐槽不无关系，什么意思呢？当第一个人构建eRM验证结构的时候，她就是玛丽莲梦露啊，宛如芙蓉；当第二个人试图维护eRM结构，添加新组建和新用例的时候就不自觉地使用AOP这个打补丁的特性，渐渐地，你会发现梦露的体型越来越大不说而且身材比例还不匀称；等到第三个人再来此地的时候，他一看这代码身材，我靠，写得云里雾里，前人打得补丁自己又不能动，只能自己继续加补丁，加到后来就成了贾玲了。

路桑在讲什么意思呢，AOP在验证的部分诚如Bergeron大神所说，它在代码中的使用会使得善意的代码初衷经过一两一两的加码之后，让原有代码的完美身材变得面目全非，这就是Bergeron所给的比喻，技术债务。技术债务在我们验证环境维护的过程中已经是屈指可数的几件头痛大事。如果你在对新模块开发验证环境的时候没指望后来的维护者对你感恩戴德疯狂打call，那么杂乱无章的结构再配合AOP的打补丁神技真得可以让你的双手在键盘上飞起来，然而每次当我遇到这种“天才式”的代码方式，我只能暗自叹一声倒霉，如果我还想让她变回梦露的话，我必须给她瘦身，花那些看起来可有可无的力气瘦身。我不知道我这种处女座的倾向是不是都一分不落地遗传给我大女儿身上，至少她现在每天早上去幼儿园系鞋带追求完美的气质就够让我无奈了。

所以Bergeron也讲到，索性的是AOP出现的环节时针对验证语言和测试环节，如果这样的思想发生在设计领域，谁又知道会发生什么呢？更可怕的是考虑到硬件designer经验迭代的速度落后于verifier经验迭代的速度更落后于software developer经验迭代的速度（不过他们的技术职业平均寿命恰好相反），等到他们也跟我一样哀叹这种打补丁的方式会将一代代迭代开发的芯片代码弄到面目全非再没有人敢动的时候，那就不是重写代码的事情，公司也就可以歇菜了。所以SV在制定标准的时候不是没有考虑过AOP（路桑的猜测），而是考虑到项目实践的稳定，将AOP这头猛兽关到了笼子里面。想一想目前国内的验证界现实吧，好多人还掌握不好OOP，再有个AOP，再有个generic programming，真得干脆让verifier们死了算了，生活已经够不容易了，想一想designer只需要懂HDL语言就能新手上路做任务，顿时觉得选择职业真得很重要啊。

退一步而言，就算designer被逼着使用这种闻所未闻的设计方式，路桑也对让这些人吃这么大一只螃蟹表示忧虑，AOP的思维方式跟硬件开发完全不是一个套路啊。所以，designer不买单，只能考虑更上一层ESL喽？然而system/architect工程师也不一定买单，他们更多的人也依然停留在Excel表格绘制数据来评估整个系统的性能，除非你先让他们投入到SystemC virtual prototyping的流程中去，毕竟已经有完整的流程可以实现可综合的SystemC代码从结构设计、到自动综合到RTL、再到后端的方式了。然而为什么这种方式不火呢？因为还是那句话，IC人的谨小慎微不是天生的，而是钱决定的啊。让他们勇敢地去吃螃蟹不是等第一个人吃完，而是要等第100个人吃完才敢。 

再进一步，到了这篇文章最后考虑的，即使ESL的全综合流程能够被买单，可是验证哪些目标呢？如何去验证呢？要知道目前主流的验证方法都还针对的是RTL代码，如果设计搬迁到SystemC更高这一层已经趋近于软件描述方式，那么对于验证的思想又将是颠覆，正可谓是设计和验证的相爱相杀命运。从目前的就是来看，SC和SV还是井水不犯河水，各自在其已有的领域继续根深蒂固的通知，偶尔会发生两个级别的模型做一做co-simulation，但指不准哪天某一个EDA公司首席跳出来说，恩，SC可以投入到验证中来，那么验证的人又要再哭一遍了。细思极恐的是，SC这厮天生就是软件身材，随意编译随意调试，轻量化到可以无视它的重新编译时间，又能更灵活地跨接到模拟器emulator的平台。因为装逼一点从哲学层面来看，要解决系统开发的效率问题，验证的效率需要从提高自身抽象性（语言的特点）和跨平台性（覆盖率的统一和测试平台的复用）来出发，这么看SC的赛道优势很明显，而这一思路跟Accellera的便携激励小组和其标准制定也是一致的。一句话那就是提高提高再提高（抽象层次）。

讲到最后，不禁又想起了那个美好的时代，eRM跟各种仿真器的黏合，然后就可以测试了，速度奇快完全体会不到编译的时间，因为Verisity将Specman工具跟仿真器剥离开，这也不难解释为当时作为一家以色列的小公司如何左右逢源在EDA大佬们的阴影下活得那么滋润。至于后来是不是因为没有跟Accellera积极组队，让SV后来一统江湖就不得而知了。在OVM有统一方法学迹象的那一段时间，曾经Cadence（已经受够了Verisity Specman）还专门出了一套将eRM的寄存器包移植到OVM的寄存器包，甚至将SV OVM的结构移植到了eRM一侧，但无奈跪舔地心好累，最终不得不举手联合M家和S家一起推出UVM来终结这多年的方法学战国时代。验证的新人们在这里应该暗自庆幸没有成为技术迭代的牺牲品，不然三年学习一种新的方法学真得叫人欲哭无泪。

快过年了，本来准备停更来每天熬粥包饺子带孩子，但又觉得纯粹的生活也叫人乏味，索性还是时不时地更新一点，侃一侃IC验证发展的可能性和方向，毕竟论验证，我们还是最专业的（傲娇脸.jpg）。

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