中文 英语

通用验证方法失去动力

当复杂性压倒关键方法时,是时候再次提升抽象了。

受欢迎程度

在过去十年左右的时间里,通用验证方法(UVM)一直是整个EDA行业所支持的事实上的验证方法。但随着芯片变得越来越异构、越来越复杂、越来越大,UVM正在失去动力。

共识是需要一些基本的改变,将工具提升到一个抽象级别,并使它们对不同的架构更加不可知。这些工具需要能够支持生成约束随机的、基于图的、有方向的或覆盖驱动的便携式刺激使测试可以在仿真、原型和仿真中重复使用。

当一段代码用C、c++或任何其他高级语言编写时,用户并不真正关心底层的体系结构或结构指令集架构(ISA)程序终于要运行了。“类似地,架构不可知的测试框架允许刺激在更高的抽象级别上开发,这样验证工程师就可以专注于用例,而不是担心要使用的确切ISA语义。Valtrix系统

当涉及到用例验证时,架构不可知论尤其有用,因为大多数处理器或SoC组件(如内存管理单元、管道和浮点)都具有定义良好的相关用例。

“以CPU缓存为例,从验证的角度来看,大多数有趣的用例都是相当标准的——填充缓存,创建卷移除等等。应用这些场景的流量模式可以通过高级算法引导的内存访问轻松实现。架构不可知验证的目标是允许在抽象级别上开发这些算法,允许在不同指令集架构上最大限度地重用刺激,”Roy Choudhury解释道。

每当复杂性超过工具的能力时,提高抽象级别就会成为验证工程师讨论的一个主题。

“验证总是试图上升到不可知论,对于任何新的验证项目来说,它总是在杂草中开始,”设计验证技术部的营销总监Neil Hand说Mentor是西门子旗下的企业.“然后它会上升到越来越高的层次。到目前为止,它工作的一个例子是接口的VIP。没有人知道这个接口是如何实现的。这完全无关紧要。对于CPU来说也是如此。如果是RISC-V,讨论的焦点是遵从性,而不是架构实现。这些都是相当一般的。这同样适用于任何SoC,其中在底层有许多不同的处理器架构,但你要验证它们。如果你更进一步,当你用算法验证的时候硬件/软件合作设计我们要做什么?我们在底层处理器上运行软件。我们在衡量绩效。我们衡量的是输入和输出,如果它工作,它的工作原理就相对不重要了。是的,你必须有模型,你必须建立所有这些东西,但不可知论是验证自然想要去的地方,因为当你达到更高的层次时,它是尽可能广泛的市场中最少的工作。所以所有东西都想去那个地方。然而,要达到这个目标需要时间、精力和理解。”

一般来说,与体系结构无关的验证的主要好处如下:

  • 这种方法允许最大限度地重用验证。对于使用不同isa开发系统的公司来说,拥有高级验证刺激是很重要的,这样就可以在多个项目中重用相同的测试,而无需重写测试。
  • 验证准备在项目中得到了极大的改善。综合刺激意味着减少冗余。
  • 减少验证工程师的负担,因为测试根据实现中可用的特性自动扩展。

Roy Choudhury指出,一个可能比较困难的领域是将高级刺激转换为最终指令流,这可能不是最优的,因为架构之间缺乏特性。

此外,在验证硬件时,行业标准的方法是定义功能测试并查看代码覆盖率。“从功能覆盖来看,不可避免地依赖于你所使用的架构,”微软高级营销总监Roddy Urquhart说Codasip.如果您的测试计划不能充分地测试您独特的体系结构,那么您就无法验证您的设计。您不仅需要了解什么是设计的正常行为,还需要了解什么会破坏它。对于代码覆盖,这不可避免地与架构无关。你想要找到每一种可能的方法来实现你的覆盖目标。因此,为了实现较高的代码覆盖率,将受约束的随机方法和覆盖驱动方法结合起来绝对是明智的。如果有部分代码很难用这些方法覆盖,那么特定的定向测试就是常识。”

UVM所扮演的角色
同时,UVM非常擅长数据随机化。

“这是真正开始数据随机化概念的原因之一,以及与之相关的覆盖范围,”验证研发部门的小组主管伯尼·迪莱(Bernie DeLay)说Synopsys对此.“这些都是相辅相成的。用UVM最难的是生成场景,比如拥有UVM序列的能力,控制它们的顺序,控制流等等,这是很难做到的。便携式刺激计划正试图解决这一难题。在基于图形的语言中描述控制流要容易得多,比如按顺序发生什么,并行发生什么,可以从哪些操作中进行选择。这是一种更自然的方式,也更省力。如果我要在UVM中尝试这样做,并且我正在编写一些相当复杂的约束,我可能最终会为了实现同样的事情而直接做一些事情。”

但是随着复杂性和异质性的增加,UVM正在失去动力。“编写方差和控制流真的很困难,”DeLay说。“我们看到这种情况越来越多。SoC上的I/ o和相关外设的数量使得在UVM中更加困难。然后,刺激计划和覆盖范围齐头并进。这里也是一样的。基本上,如果我试图编写覆盖率来了解我生成的场景——我们为数据对象编写覆盖率——里面什么都没有SystemVerilog写覆盖率来问,‘我有这个控制流序列吗?真的发生了吗?’在类似PSS的东西中,无论是在语言中还是在实现它的工具中,获得覆盖——无论是用户编写的还是由工具自动化来理解测试中的交互/活动——都要容易得多。”

Darko Tomusilovic,首席验证工程师Vtool他指出,多年来,大多数问题都可以用UVM解决。现在情况已经不同了。

Tomusilovic说:“在我们的一个项目中,UVM被证明是非常低效的,因为设计本身被分割成许多相互不相关的功能。”“最后,我们决定重新设计整个系统,我们只是继续使用每个功能定制的组件。因此,我们不是依赖于一个通用的代理监视器/驱动程序/记分牌基础设施,而是简单地有一个代理来实现该功能,该代理结合了刺激生成、监控和跟踪器。这里非常高效的是,它是本地化的,所有的代码都在一个地方。当你有一个包含许多不同逻辑的记分牌时,它可能会非常混乱,非常难以阅读。然后你需要多个工程师维护同一个文件,所以在复杂的项目中会变得一团糟。在这里,我们基本上把每个特性的所有内容都分割到我们所谓的特性代理中,然后我们有一个开发人员负责验证一个特性。他们会维护这个代理,仅此而已。所以即使它对我们来说完全违背了UVM方法,但它真的非常有效,非常有用,非常容易拆分任务。虽然UVM是一个很好的起点指南,但已经有很多地方不适合它,您需要对其进行大量扩展。 For low-power state machine modeling and verification you need something else, and there it makes sense to call it a guideline. It’s a good reference. But in the end, every product will contain so much customization that I don’t really think of calling it a methodology.”

遗留代码问题
今天UVM的另一个挑战是遗留代码。当实现一个新的验证项目时,遗留代码是如何合并的?

Mentor’s Hand强调,这对于当今的工程团队来说是一个大问题,特别是如果遗留代码存在于非标准环境中。“我们如此热情地接受标准的原因是因为它至少部分地解决了这个问题。如果您有使用专有语言的遗留代码,这就限制了您将遗留代码引入新环境的能力,或者将该环境限制为特定的供应商,这真的是不可取的。所以,一般来说,我们试图推动标准化。这就是为什么我们把inFact语言放到Accellera中,用于便携式刺激计划。这就是我们这么做的原因OVM技术UVM。这就是为什么我们把低功耗语言交给UPF。你想要避免这个遗留问题,因为现在,如果你有遗留的UVM你想要把它带入一个可移植刺激的世界,我们可以很容易地做到这一点,我们可以建立那个环境。如果你有遗留的Verilog或SystemVerilog,我们可以很容易地做到这一点。对于大多数工程团队来说,我不时看到的唯一遗留问题是e。所有其他语言都是基于标准的,并且有自己的路径。您可以跟踪从Verilog到SystemVerilog到UVM到Portable Stimulus的路径。这里有一条允许抽象级别的路径,你偶尔会得到一些小的支线。我们过去用过Vera,用过e,用过SuperLog, Verilog子集。在大多数情况下,如果你碰巧押错了方向,就会有翻译成本,也会有让人们迁移的成本。”

对于Tomusilovic来说,遗留代码的第一个挑战是很难证明抛弃旧的遗留代码是正确的。“他们已经把它扔了一次,并把它放在了UVM。很难证明抛弃UVM而加入新东西是合理的。第二个挑战是,尽管UVM已经存在了近十年,但没有一个项目是100%按照UVM完成的。一旦你有了一些与众不同的东西,事情就会变得更加困难。”

以一个简单的SoC项目为例。“如果你有一个处理器,它将执行一些代码,对于如何预加载这个处理器,如何遵循它的代码,如何与系统的其他部分通信,实际上并没有一个标准的方法testbench以及如何立即采取行动,”托穆西洛维奇说。“核心方法论基本上会崩溃,因为在每个项目中。您将有一堆不同的监视器/组件来跟踪消息传递,并与某种内存邮箱进行通信,这是不标准化的。一旦你有了这个箱子,它基本上就会破裂。该方法失败的另一种情况是寄存器建模,其中UVM确实定义了一个非常好的、完美的寄存器模型,适用于非常简单的接口。但是一旦你有了支持突发的更复杂的寄存器接口,或者支持一些更复杂的东西,比如低功耗建模,一切都崩溃了。你需要重新发明你自己的方法,以某种方式在UVM周围添加你自己的层,弄清楚如何使它工作。每个人都这么做,只是方式不同。我相信在几乎每个项目中,都有这样的案例。每个人,尽管出发点是一样的,但选择了不同的方向,做出了他们自己版本的UVM。 Therefore, even though we started with a methodology, it’s very easy to diverge.”

尽管如此,实际被替换的还是很少。DeLay说:“在可移植刺激解决方案中,您不会丢弃底层的UVM环境。“你可能仍然想在UVM中进行主要的数据随机化和低级别的事情。这实际上控制了UVM序列本身以及它们发生的顺序。有些人认为他们会把所有UVM的东西都扔掉。这不是你想做的。您希望利用在环境、检查和基序列中已经完成的工作,并更好、更容易地使用它。作为一种结构,这就是可移植性发挥作用的地方,因为如果你进入嵌入式环境,你有相同类型的结构。而不是UVM组件或UVM VIP,您只是将其替换为一个事务处理程序或您从嵌入式端控制的实际RTL。我想要重用的是控制事情如何发生的东西,而不是它的底层东西,如果我可以重用它,那么它就会减少从一个到另一个的工作量。 I don’t know how many people I’ve talked to that say, ‘I wrote this in SystemVerilog. Now I rewrote it in C when I went to the SoC level. And then if you talk to the DV guys in silicon, I don’t know why they do this but they tend to rewrite that C code one more time. Basically, you’re going to end up re-doing that same initialization sequence three times. It’s error-prone, and every time you end up introducing new bugs along the way.”

实际上,这是关于新一代验证工具的。

同样,这将导致下一个抽象级别,就像业界从SystemVerilog到UVM以解决UVM中无法完成的事情一样,例如在模拟器或虚拟平台上轻松地从块到子系统再到系统。“虽然我们还没有做到这一点,但我们的目标是同样的场景可以在每个级别上运行,无论你是在数字模拟器、虚拟原型上运行,还是在模拟器或原型系统上运行。一切都很顺利。”汉德说。

更好的验证
然而,根本问题依然存在。迪莱说:“如果我开始一个新的验证项目,第一步实际上是更多地从我想要验证的角度来分解它,什么是验证一个或多个区块或部分区块的最佳方法。”他说:“如果你从最高层开始,可移动刺激计划可能是一种办法。对于其他事情,它可能是正式的。我不会使用Portable Stimulus来做应该静态完成的事情,因此从顶级验证思维开始是方法学的第一步。方法论不仅仅是UVM。这是解决这类问题的一种非常特殊的方法。验证方法的起点要高得多。”

他的建议是,将您想要验证或需要更好验证的所有内容分解,然后决定使用什么合适的工具或子方法来实现这一目标,因为实现同一件事通常有不同的方法。“正式就是一个很好的例子,”他说。“对于某些区块,我不建议模拟。你最好正式地处理数据路径的事情,所以从验证方法的角度出发,从更高的层面决定使用什么工具来完成特定的路径。”

更好的验证从您真正需要验证的内容开始,而不是试图适应UVM。“你需要建立一些环境,这将帮助你有效地验证这个芯片,然后只有在第二阶段,你才应该尝试看看它是否适合标准的UVM组件。如果UVM可以帮助你,那太好了。这是一个很棒的工具。这很有帮助。但只有在你有一个定义良好的基础设施之后,它才能开始应用,”Tomusilovic说。

如果在一开始就没有正确地定义这一点,它将对项目产生巨大的影响,并且需要额外的时间来解决这个问题。Vtool的高级验证工程师Olivera Stojanovic说:“在某些情况下,你没有时间,在某些情况下,如果一开始没有正确的计划,那么删除所有内容,从头开始会更好。”

当人们在自然的、更高层次的抽象和不可知论中展望验证的下一步时,Mentor’s Hand认为使用基于标准的方法比专有解决方案更可取。“如果不是,睁大眼睛去做,知道它可能会把你困在那个解决方案中,或者你以后必须迁移。在某些情况下,人们会说,‘这项新技术太棒了,我愿意冒这个险。他说,目前我们处于一个相当舒适的境地,我们正在考虑的下一个抽象层面是可移植刺激(Portable Stimulus)。我们正在考虑这样做,即使是现有的东西,如VIP,已经是不可知论者。但如果我们能把它纳入便携式刺激计划,那就意味着它无处不在。”

结论
不过,没有什么是可以保证的。考虑到COVID-19大流行正在影响技术的采用,便携式刺激设备的采用可能比一些人预期的时间要长一些。

汉德说:“普遍的不确定性意味着新技术不会很快被采用。”“对于那些正在考虑便携式刺激的工程团队来说,他们说他们喜欢它的承诺,但他们会坚持使用UVM。他们知道这对项目进度意味着什么,也知道这对他们正在做的工作意味着什么。”

他把目前的情况比作互联网泡沫破裂,当时正试图启动正式的核查工作。由于全球经济衰退的不确定性,客户选择投资于维持员工,而不是投资于新技术。正式的核实随后花了许多年才获得支持。

便携式刺激器是否真的如此还有待观察,但有足够的创造力和工程独创性来为整个行业和离散的工程组织绘制验证方法的前进道路。它的演变可能比预期的要长一些。



2的评论

凯文·卡梅隆 说:

我一直认为UVM的理由être是有约束的随机测试可以卖很多模拟许可证。UVM作为数字、正式和半正式方法的验证方法很糟糕,而且无论如何都应该是根据构造进行校正的。CR只有在电源控制等模拟领域才真正有用,而且只有当你使用模拟模拟器而不是数字模拟器时才有用。

我一直不明白便携式刺激计划的意义。

说:

随机化不需要UVM。也只有系统verilog类

留下回复


(注:此名称将公开显示)

Baidu