面向方面的设计方法（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（面向方面编程）就是要在已有的代码中添加一些新的功能点而不用去改变内部的代码。虽然这正是行业所希望实现的，但是这是否现实呢？

Sonics首席技术官Drew Wingard从更高的层次来解释硬件的抽象模型。在片上网络(OCN: On-chip network)空间内，网络看起就像一个地址映射，它表明硬件的抽象模型正在与哪个硬件资源进行通信，以及正在访问该资源内部的哪个地址。我们最关心的部分还是这些系统的性能特性。大部分的成本降低或者性能提升都是通过共享一些紧张资源如片外存储器来实现的。共享程度的大小必须确保系统中的各个组件能够达到相应的性能水平。”

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的打补丁神技真得可以让你的双手在键盘上飞起来，然而每次当我遇到这种“天才式”的代码方式，我只能暗自叹一声倒霉，如果我还想让她变回梦露的话，我必须给她瘦身，花那些看起来可有可无的力气瘦身。我不知道我这种处女座的倾向是不是都一分不落地遗传给我大女儿身上，至少她现在每天早上去幼儿园系鞋带追求完美的气质就够让我无奈了。