SystemVeirlog的全面支持是开发商用仿真器的第一道门槛。市面上可以找到不少基于纯Verilog的仿真器,但是真正能完整支持SystemVerilog 的仍然屈指可数。如何全面地支持SystemVerilog语言,是开发仿真器的一个重要任务。
01. SystemVerilog的发展历程
数字芯片的验证技术是随着Verilog语法的演变而演变的。最早,Verilog是完全用来描述(Model)硬件的,因此又叫HDL(Hardware Description Language硬件描述语言)。随着验证技术的进步,需要将很多软件的思路融进Testbench以丰富测试场景。EDA公司都曾经推出过一些针对Testbench的语言,如OpenVera等。
与Verilog的静态属性不同,这些Testbench的验证语言引入了很多动态的概念,甚至有类(class)、继承、多态等。然而最终,这些语言又逐步融进了Verilog,最终形成了今天的SystemVerilog。下图显示在SystemVerilog刚刚成为标准时,它各个模块的来源。
图片来源:SystemVerilog is changing everything - Tech Design Forum Techniques (techdesignforums.com)
基于SystemVerilog,各个EDA厂商推出了各自的仿真器,并在这个基础上,进一步开发了基于SystemVerilog的methodology library, 最后统一成今天用的通用验证方法学——UVM (Universal Verification Methodology)。
从上面的历程可以看出,SystemVerilog的发展和支持不是一步到位的,是在其他语言的基础上经过多年演变形成的。各个EDA厂商根据他们的自身优势开发了对SystemVerilog的支持。虽然这些仿真工具都符合LRM(语言参考手册)的标准,但是由于其发展路径不同,在性能上及个别语义上,仍然存在一定的差异。
02. SystemVerilog的语法特点
SystemVerilog为了给验证提供更多的灵活性,从其他编程语言,尤其是面向对象的编程语言(如C++, Java)借鉴了很多语法。这使得SystemVerilog语法非常复杂,各种语法耦合性强,环环相扣。
因此,这就要求在设计时,需要一个全局的概念,不能切成一个个孤立的模块,否则最终很难拼起来;即使勉强拼出来,也不牢固。这点非常像中国古建筑的“榫卯”结构。比如,SystemVerilog引入了class、structure,以及各种动态类型的数组,如 queue。这些都不能是孤立的。它们在实际使用中(比如UVM)都是嵌套使用的。一个类型的数组,很可能其元素是另一个类型。
以下通过一个uvm的例子,来更直观的了解一下SystemVerilog的语法。
一个支持SystemVerilog的仿真器,要想跑通上述case,至少需要关注以下几个方面:
1 复合类型成员的初始化
class ’my_sequence’ 中的成员 ’settings’(第12行)是一个queue类型的变量。这种类型的变量需要进行特殊的初始化,给queue分配初始空间。该queue的成员又是一个struct 类型,而struct是个复合类型,因此,这里面是一类比较复杂的嵌套类型。
2 数组的方法调用(array method)
上面例子用到了‘sort’这个方法(第25行)。这里面,又涉及到了嵌套类型,因为queue的成员是struct 类型的。而struct属于复合类型,是不能直接比较的。IEEE1800标准引入了 with (item.mebmer...),可以针对复合类型的某个成员进行排序操作。
3 垃圾回收
SystemVerilog类似Java,它不需要用户自己进行类似delete操作。这就要依赖仿真器提供垃圾回收的功能。否则在运行时会出现内存泄漏。
4 进程管理
上述例子中的task ‘main_phase’ 中用到了‘fork join‘,(第33-36行)。仿真器需要有一套进程管理来支持这个用法。进程管理实现的是否高效,将直接影响到仿真器的性能。
除此之外,还有很多技术点需要考虑,这里就不赘述了。总之,一个对SystemVerilog全面覆盖的顶层设计,对支持UVM非常关键。
03. SystemVerilog的scheduling semantics
当人们理解SystemVerilog时,可能会比较专注该语言增加的语法部分,但是这里要注意的是,SystemVerilog的引入仍然是为了验证硬件,而不是为了开发软件。它是为了丰富Testbench做验证的能力。SystemVerilog在丰富了语法的同时,也会带来其他的问题,这就需要制定更多的规范来定义这些新出现的状况,IEEE1800 scheduling semantics就是一个。
Phil Moorby 是Verilog的发明者。他写了Verilog的第一个仿真器——Verilog-XL。Verilog的仿真从诞生起,其实就存在一个问题,那就是如何确保Verilog仿真器软件的行为和硬件的行为一致,否则仿真就没有意义。为此,需要制定一些细则,来规范Verilog在scheduling 上的行为。其中,大家比较熟悉的非阻塞赋值(non-blocking assignment), 就是Phil 引入的,其目的就是确保Verilog在仿真时序逻辑时的行为和硬件一致。
2002年,Phil Moorby加入Synopsys, 从事SystemVerilog语言的定义和开发工作。笔者曾有幸和Phil共事,参与了早期SystemVerilog相关feature(如clocking block等)的开发。这些新的SystemVerilog语法的引入会对Simulator的行为带来一定的不确定性,为此,Phil对原有的Verilog scheduling semantics进行了扩展来消除这些不确定,其中包括Testbench和DUT之间能进行精准的无歧义的数据通信。这些思想,后来都被Accellera国际电子行业标准化组织采纳,变成了今天IEEE1800 scheduling semantics 的一部分。
以下是1800 scheduling的semantic,来自 IEEE1800-2017, page 64——
04. GalaxSim对SystemVerilog的设计思路
前面提到,SystemVerilog并非诞生起就一成不变的,而是在不断变化发展。因此,作为后来者,芯华章开发的高性能数字仿真器GalaxSim,在开发SystemVerilog时,不存在EDA巨头公司的历史包袱,可以从一开始,就把SystemVerilog当作一个整体来支持,而不是先支持老的Verilog部分,再支持新的SystemVerilog 部分。这里面包括了以下一些设计上的考虑:
1) 更精准的SytemVerilog语义解析
SystemVerilog经过了十几年的使用和演变,有些早期的语义可能有了新的含义。此外,很多SystemVerilog的语法是在先有了EDA工具支持后再写入标准的。我们在实现SystemVerilog支持时,会根据其背后所体现的实际验证应用背景来设计仿真行为,而不是简单地做一个语言层面的编译器。这样,我们确保了GalaxSim在SystemVerilog上的仿真行为上和国际主流仿真工具兼容。
2)更加原生的支持
EDA主流的仿真器在支持SystemVerilog上都走了很长的一段路,这是因为SystemVerilog本身并没有稳定下来。往往会出现的情况是,既有的仿真器的infrastructure无法满足新出现的SystemVerilog的语法。
GalaxSim不会面临这个问题,因为我们在设计其基础结构的时候,就会把SystemVerilog需要的各种data type一并考虑进去。这样的设计带来的优势就是开发更加流畅,质量更高。
3)更加优异的性能
性能始终是仿真器的灵魂。然而,对于SystemVerilog这种相对较新的语言,其性能往往不如纯Verilog。这是因为,它们往往是先开发feature,确保功能的完备性;直到后来在客户端遇到了性能问题,再进行性能优化甚至重构。
GalaxSim对SystemVerilog的支持,在设计之初,就根据目前的设计规模,将性能问题与功能同步设计,确保4大性能指标(Compile Time、Compile Memory、Run Time、Run Memory)比肩甚至超越国际主流仿真器。
4)更加贴近验证的scheduling semantics
SystemVerilog的目的是为了验证。因此,仿真器对scheduling的要求是非常严格的。有些甚至并没有非常明确地写在标准里,但是已经被业内主流EDA企业在事实上使用了。这些规范都是被数十年客户检验过,也是在实际应用中必须遵守的“戒律”。
05. 总结
SystemVerilog作为最复杂的语言之一,是国产数字仿真器开发的第一道门槛。如果LRM(语言参考手册)的覆盖率不够,就会阻碍仿真器的商用推广。但从上文的分析中不难发现,实现复杂的SystemVerilog需要巨大的工程量。如何在纷杂的SystemVerilog语法中将主流UVM所需的部分,高质高量地实现出来,是GalaxSim为代表的国产EDA数字仿真器,需要解决的首要问题。
芯华章核心研发团队曾在跨国公司成功主导过大型仿真器项目研发,对验证语言、方法学、仿真器核心构架、算法、优化有着丰富的技术储备,尤其在SystemVerilog 方面有着多年的耕耘,因此能将复杂的SystemVerilog背后的“榫卯”嵌套结构梳理清楚,进而可以在清晰的架构上,一步到位支持几乎所有SystemVerilog的语法。 实现对SystemVerilog语法的支持,仅仅使得仿真器可以编译用户的设计了。要想使仿真器真正发挥验证作用,还需要在SystemVerilog的基础上搭建各种应用,如Debug、SVA、Coverage等,才能最终使仿真器成为真正的仿真平台。此外,性能始终是仿真器的核心。在完成SystemVerilog支持的同时,如何结合调试(Debug),提升性能方面的功能,也是需要面对的重大课题。
责任编辑:彭菁
-
仿真器
+关注
关注
14文章
1011浏览量
83577 -
eda
+关注
关注
71文章
2679浏览量
172674
发布评论请先 登录
相关推荐
评论