可以采用面向方面的设计实践使我们更快更好的设计吗?最初的尝试这些技术在验证并没有完全成功。
早在1992年,有主意,软件编程的学科称为面向方面编程(AOP)和将其应用于硬件的验证。这些概念被纳入e语言和Verisity成立商业化。
荷兰人见过,使用面向对象(OO)技术将允许的抽象testbench上面提高寄存器传输级(RTL)。添加面向方面的功能将提供更灵活的testbenches和允许RTL补丁作为testbench改性处理而不是重写testbench。
当时,e是一个重大的进步testbenches了,还被支持吗节奏,它使用以来一直在下降SystemVerilog和普遍的验证方法(UVM)。可以从验证的一些经验教训帮助改进设计流程?
今天,许多设计衍生品的一个平台。该平台可以验证,导致功能齐全的硅。如果添加一个新的边缘块,系统必须的代码有多少改变?必须re-verified多少?也许设计保持不变,但较低的版本被创造出来。就好了,不需要改变任何完全RTL验证。
“AOP能够功能添加到现有代码没有触及到的代码,”解释了Tom Fitzpatrick验证技术导师图形。这是行业想要的确切位置。但是这有意义吗?
首席技术官超音速后退一步看抽象建模的硬件。“在片上网络(OCN)空间网络开始看起来像一个地址映射,它告诉硬件资源的抽象模型跟什么地址,访问资源。最重要的部分是这些系统的性能方面。很大一部分的成本/性能优势来自共享昂贵的资源,比如片外存储器。分享的能力,和确保系统中的组件可以实现所需的性能水平。”
Wingard观察到有更多的建筑师写性能模型之间的协同和验证人试图抽象底层硬件与实际硬件设计师本身。这或许表明,AOP更有用的更高的抽象级别上的任何改变在现有流与RTL设计有关。
“当我们看性能分析需要使用的一个概念模型,从这个我们可以推出一个操作场景,“继续Wingard。“对于一个给定的SoC往往有最重要的用例集的设计团队正在考虑设备。这让你关注确保你可以适当大小和配置内存和网络必须满足吞吐量需求的核心。”
就是力量相似呢?我们可以使用AOP来指定电源方面的设计,从而能够实现这些功能,无需修改的功能设计?并进一步协同Wingard看到相似之处。“我们有一组用例,我们获得一组场景,我们要确保我们的用电是适当的在这。之间的协同作用是什么这些和那些被用于性能?大约有80%的重叠。有很多抽象的描述这些场景之间的协同优化网络拓扑结构、内存的系统特征域分区优化性能和力量。”
为什么这个行业没有准备好迅速跳上AOP吗?
电源有问题
“AOP的问题是,虽然强大对于特定类型的应用程序,这也是非常危险的,”Janick Bergeron说,研究员Synopsys对此和用户的e语言,然后他去工作辆在2003年,Synopsys对此收购的公司。“作为一个知识产权供应商我想知道最终得到执行。神气活现的任何人都可以用我的代码,取而代之,扩展,添加的方式我无法控制。这使得支持一场噩梦。你需要知道确切的代码,具体的顺序加载复制一个问题。”
导师的Fitzpatrick表示同意。AOP的主要抱怨是你必须非常小心或者陷入困境。的嗯是一种帮助他们避免这些问题。从那时起,已经纳入UVM类似的功能。UVM侧重于面向对象部分,您可以扩展一个类来创建一个新的类和交换使用的工厂。这是更容易跟踪你终于结束了。可能需要更多的代码,但它给你的控制在不牺牲灵活性是有利的。”
Bergeron还认为AOP的可伸缩性的问题。“当这个项目是一个小型的IP核心,AOP工作好,但随着设计的规模越来越大,它变成了一个管理的噩梦。当你可以保持它在你的脑海中是不错的,但除此之外…”
敏捷和AOP ?
敏捷是另一个技术今天收到相当多的关注。建立敏捷取代了瀑布型的开发方法与增量的方法。看起来AOP补充敏捷。
”方面允许您进行修复和迭代,敏捷要求,你可以从外面,“Bergeron说。“所以我改变我的代码库或扩展它吗?我现在承担技术债务或晚吗?“Bergeron技术债务的定义是一个术语,用来描述惯性或熵所积累的捷径。“你必须付清。”
所以当Bergeron看到可能的协同作用,他不相信是它的适用性。他认为AOP带来高额债务,但“敏捷似乎导致尽可能少的债务。AOP对编写测试是很好的事情,因为这是你写的最后一件事。任何基础设施或本该是可重用的,我们会建议人们远离它,因为你不能控制或保护它。”
其他的方式
问题就变成了如何获得优势而导致技术债务。“事实上,AOP是为了集合相关的所有代码一个横切关注点是有趣的,你可以用纯面向对象编程,将你所有的类扩展和回调函数在单个文件,Bergeron解释道。“这是一个重要的组织和方法。”
没有问题从Fitzpatrick说:“我们都做过类似的事情在SystemVerilog和UVM工厂。”
AOP设计
Bergeron为AOP设计提供了一个假设。“AOP可能相关的设计方面,因为没有一个设计方面的能力是面向对象的。这是一种固有的结构性的事。如果你把一个模块,实现了一个设计和您想要添加的功能,你不能扩展模块。没有虚拟的模块可以扩展。我已经修改文件。通过创建一个新模块,现在我必须修改环境来验证我保持之前的功能和添加了新功能。如果我可以定义方面的模块来添加一个新的功能,添加一些港口,一些新功能吗?原模块还在和原功能仍然可以验证但你只需要添加新功能的testbench。”
菲茨帕特里克并不急于遵循这条道路。“在设计社区,硬件人不倾向于认为即使在OO更不用说AOP术语和条款更有可能得到意大利面条式代码。我犹豫去设计团队,说我们有能力使用AOP的RTL设计。”
但它似乎采用统一格式(权力统一格式)是定义——它的设计的一个方面权力配置文件。“我们确实需要定义如果AOP意味着一切都在一个编程语言,“Bergeron说。“执行语义定义通过添加方面但是,权力不影响执行语义,因此只是一个执行的不同视图。它将影响最终实现,所以从实现的角度来看,但与AOP方面,你不需要使用相同的语言。”
“UPF值是一种面向方面的设计,“Anand艾耶说,产品营销主管Calypto。然而,他认为,我们没有必要的工具能够以这种方式使用它。“一起把各个方面的挑战是下游手中的工具。这些迟到的过程和决定他们如何相互作用意味着你有必要的性能分析工具和那些在比赛中只能迟到。”
菲茨帕特里克认为别的东西。“人们似乎舒服你可以指定正交功能功能设计,所以有这个单独的事情放在第一的RTL和按摩可以达到的事情是可以接受的。”
Fitzpatrick仍然是关心这些事情的实现和完整的AOP模型不适用。“从编码的角度来看,我更喜欢能够看到一切都在两个地方——模块定义或UPF值规范模块。你知道到哪里去寻找任何功能,不用担心其他的代码编译器可能发生链接修改的东西我很满意。”
Fitzpatrick可以看到优点。“你真的想单独的逻辑功能,这是我们需要担心与验证,从附加功能验证问题,增加了更多的复杂性。此外,验证设计的电力方面的能力作为一个独立的事情有意义,你可以确保它是一致的在你试着检查一下上面的RTL功能。这个分裂问题,允许你考虑分开,还要看他们在一起,这是非常强大的。”
不是每个人都认为UPF值是一个自上而下的过程的一部分。“UPF值是一个抽象和有一个受益于做功率控制硬件的设计,设计网表的分区结果符合流的物理需求,然后自动创建一个相匹配的UPF值表示,“Wingard说,他认为UPF值文档选择的一种方式。“我们都希望IP来约束UPF值描述的基本功能块对权力的控制。在集成级别,我们需要知道我要付钱,领域我能承受多少?我应该用电源隔离环包围每一块吗?我怎样才能减少电力领域的总数和州为实现可控的子集?向流沟通的一些增量UPF值。我们开发电力控制器领域我们需要确保他们符合UPF值描述他们。”
一条通向未来的路
许多年前,加里·史密斯和我有一个关于采用英语辩论持续了数年。而史密斯集中在设计工具,如高水平的合成,我总是坚持认为,没有人会完全成功,直到抽象设计的建模和验证已经解决。似乎有太多的问题需要验证什么和如何验证。没有这个,的价值非母语英语课程一直质疑和设计流不确定。
“英语所面临的挑战是让ROI,芯片架构师愿意投资一些工具,”他Wingard。今天,大多数SoC架构师使用电子表格,但是他看到隧道尽头的光。“如果我们有信息可以以多种方式捕获的场景,可以使用,可用于驱动一个好的模型对系统性能、驱动电源设计,使这些地区之间的权衡,然后有更多的可能性,他们将得到采纳。”
的Accellera便携式刺激工作小组场景的努力可能会导致更好的方法可以定义,反过来可能会驱动未来的验证和设计方法。
|
|
|
|
|
|
|
|
|
|
本文的很多专家意见反映严重缺乏最近的经验与AOP——尤其是大型现代SOC验证。就我个人而言,我将在2015年尴尬讨论技术,我上次在2003年使用。
我想解决本文反对AOP声明:
1)封装完全支持(公有、私有、保护等)…所以与代码“清理”并不是一个真正的问题。作为IP提供商,您还可以加密代码或定义un-extendable。
2)随着基本编码规则,UVM-e明显比UVM-SV更健壮,并提供所需的所有方向不“陷入困境”。此外,不需要宏UVM所需的每个特性已经内置到语言。根据我的经验这导致几乎一半的代码作为UVM-SV。每一行代码是一个机会写一个错误,这是一个重大优势。
3)我们有项目非常成功规模UVM-e全芯片的验证。类似的项目使用UVM-SV无法规模超出了子系统水平。而我们UVM-e项目乐于使用任何可用的仿真,SV项目绝对需要仿真来验证他们的系统。
4)我们的HLS UVM-e设计可以很容易地验证。的设置方法和特性是不可知论者潜在的设计语言。我可以使用相同的testbench系统c设计和生成的RTL。我必须改变单个文件声明信号名称和打开我的时间具体检查。我不能很轻易与UVM-SV这样做,即使我做了,testbench的性能将大大减少我在系统c的生产力。
该行业的真正原因还未跳上AOP是因为只有节奏支持得很好。AOP如果Synopsys对此或导师有一个可行的解决方案,他们会很快促进UVM-SV显著提高。相反,我看到他们是非常无知的FUD。
布莱恩的问候。我想提供一个反例- >
“当这个项目是一个小型的IP核心,AOP工作好,但随着
设计越来越大,它变成了一个管理噩梦”
我们的骄傲https://en.wikipedia.org/wiki/Xeon_Phi团队)
相当成功地利用AOP(通过UVM-e)非常大的SoC。享受不断发展/改善近10年的代码库。
如果AOP可供设计在某种程度上,它是用于验证,我认为这将改变整个行业。
有趣的概念——“AOP敏捷的服务”。
事实上人们喜欢的一件事关于e是简单的提供/补丁。通常,一旦你知道错误在哪里,你可以很容易地创建一个补丁加载。
同样适用于添加功能。你认为一个新概念,您编写一些代码,加载它的编译环境,和它玩。你可以问别人试试没有问他们花太多时间在重新编译环境——“负载”,让我知道它是如何工作的。本身可以加载和顶部,不需要重新编译环境让你敏捷…
关于AOP设计——我发现这一个很酷的主意设计方法的未来。AOP可以节省大量的时间,这将是伟大的如果设计师也可以享受它。
是的! !会杀死能够补丁设计代码无需修改代码库(从数据库管理单独的观点)。是一回事,黑客在快速变化,又是一件管理许多变化。这通常是大规模集成工作。插件需要维护,直到后续修订。修正来的时候,很有可能与当地修复会发生合并冲突。添加加载一个神奇的“e”技巧的解释补丁的编译后的二进制文件(不需要重建),你真的有一场革命。如果相同的RTL能做,补丁构建有效周转时间是0。这将允许对多个每天vs 1(更大的构建,需要8个小时或者更多)。
回到主题博客”可以采用面向方面的设计实践使我们更快更好的设计吗?“- >是的,是的,是的,这是我所有的钱,是的!
我的直觉是,AOP设计很有帮助。而AOP可以用于添加快速补丁(这应该之后,理想情况下,被合并到原始的代码),其主要用途是为保持关注点隔离(可能像原来的文章中讨论的权力的例子)。
在后者情况下,使用AOP技术部门不承担。事实上,可以说没有AOP,需要手动合并不同的关注点为一块代码,使结果更少的维护。
如果你同意这种风格的关注点分离确实是有用的,那么它可能是一个好主意使用内置的AOP (e,支持访问控制指令“私有”和“包”),而不是使用回调的乏味刀和工厂方法。
最后,我的直觉是,战斗设计复杂性也许最好使用AOP和一个强大的组合language-definition-language (e)。这样,一个人可以定义新的特定于域的语句(明智),当实例化,方面代码添加到现有的结构。
问候Yoav !
我很难表达多少我同意”这种风格的关注点分离确实是有用的”只是说使我能够完成的事情,我只是不能想象没有它。已经说过,不愿意或不能实现这个跨越。更糟的是,消极修辞(如下面)使它更加困难的飞跃。
“AOP的问题是,虽然强大
某些类型的应用程序,它也非常危险”
“任何人都可以把我的代码,取而代之,扩展
的方式,再加上它我无法控制”
“主要的投诉AOP是你必须的
小心你也可以遇到麻烦”
“当这个项目是一个小型的IP核心,AOP
好的,但随着设计的规模越来越大,成为管理噩梦”
我真的见过灯泡去了眼中的不相信当他们显示与修补能做些什么。他们选择自己从地板上之后,讨论中(和最终拥抱)管理通过AOP可以横切关注点。
有些相关。每当我发现自己思考你和“e”语言,这个有趣的亨利•福特(Henry Ford)引用跳进我的脑海。
“如果我问别人他们想要什么,他们会说更快的马”
谢谢你的美言
顺便说一句,我觉得相当确信AOP-for-design是一个好主意,我不是完全清楚具体情况。例如,沃尔夫冈Roesner IBM和我已经讨论这个年龄(布莱恩,也许你应该试着采访他)。当我们上次会面(HVC的14)他说他们最终创建自己的面向方面的织布工(重置,电力、热力、调试、复苏,DFT等)。
理解。我真的很想看到的是接近高层的基于“e”的变体从C / c++ RTL综合。
我真的想要的(和主题)是大众的“e”。从我的角度来看,“e”是我遇到过的最自然的语言。一次可作为一种通用语言,AOP将成为我们的集体思维的一部分。“占主导地位的模式分解的暴政”将是过去的事了!生病的人类在地球上可以在自然和直观的方式代码。这将导致……减少自己。也许更好的你的博客中讨论。让我知道如果有任何兴趣这一思想,我们可以选择它。