解码国产EDA数字仿真器系列之二

如何实现全面的SystemVerilog语法覆盖？

1. 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）。

VMM

SynopsysUVM

Cadence

OVM

200920082005

从上面的历程可以看出，SystemVerilog的发展和支持不是一步到位的，是在其他语言的基础上经过多年演变形成的。各个EDA厂商根据他们的自身优势开发了对SystemVerilog的支持。虽然这些仿真工具都符合LRM（语言参考手册）的标准，但是由于其发展路径不同，在性能上及个别语义上，仍然存在一定的差异。

2. SystemVerilog的语法特点

SystemVerilog为了给验证提供更多的灵活性，从其他编程语言，尤其是面向对象的编程语言（如C++， Java）借鉴了很多语法。 这使得SystemVerilog语法非常复杂，各种语法耦合性强，环环相扣。 

因此，这就要求在设计时，需要一个全局的概念，不能切成一个个孤立的模块，否则最终很难拼起来；即使勉强拼出来，也不牢固。这点非常像中国古建筑的“榫卯”结构。比如，SystemVerilog引入了class、structure，以及各种动态类型的数组，如 queue。这些都不能是孤立的。它们在实际使用中（比如UVM）都是嵌套使用的。一个类型的数组，很可能其元素是另一个类型。

    以下通过一个uvm的例子，来更直观的了解一下SystemVerilog的语法。

1  import uvm_pkg::*;

2  typedef struct {

3    string msg;

4    int addr;

5  } lite;

6

7  class my_sequence extends uvm_sequence;

8  function new(string name, uvm_sequence parent = null );

9    super.new(name);

10 endfunction

11

12 lite settings[$];

13

14 function void add();

15   lite setting_array[10];

16   foreach(setting_array[i]) begin

17     setting_array[i].msg = $sformatf("msg_%0d", int'(i));

18     setting_array[i].addr=32 * i;

19     settings.push_back(setting_array[i]);

20   end

21 endfunction

22

23 function void sort();

24   if (settings.size() > 0)

25     settings.sort() with (item.addr);

26 endfunction

27

28 extern function void find(int addr);

29

30 task main_phase();

31   add();

32   sort();

33   fork

34     find(32);

35     find(192);

36   join

37 endtask

38 endclass

39

40 function void my_sequence::find(int addr);

41   if (settings.size() < (addr / 32))

42     $error;

43   else

44     $display(settings[addr / 32]);

45 endfunction

46

47 module top();

48   my_sequence my_set = new("test", null);

49   initial begin

50     my_set.main_phase();

51   end

52 endmodule

 一个支持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非常关键。

3. 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——

4. 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企业在事实上使用了。这些规范都是被数十年客户检验过，也是在实际应用中必须遵守的“戒律”。

5. 总结

    SystemVerilog作为最复杂的语言之一，是国产数字仿真器开发的第一道门槛。如果LRM（语言参考手册）的覆盖率不够，就会阻碍仿真器的商用推广。但从上文的分析中不难发现，实现复杂的SystemVerilog需要巨大的工程量。如何在纷杂的SystemVerilog语法中将主流UVM所需的部分，高质高量地实现出来，是GalaxSim为代表的国产EDA数字仿真器，需要解决的首要问题。

芯华章核心研发团队曾在跨国公司成功主导过大型仿真器项目研发，对验证语言、方法学、仿真器核心构架、算法、优化有着丰富的技术储备，尤其在SystemVerilog 方面有着多年的耕耘，因此能将复杂的SystemVerilog背后的“榫卯”嵌套结构梳理清楚，进而可以在清晰的架构上，一步到位支持几乎所有SystemVerilog的语法。

实现对SystemVerilog语法的支持，仅仅使得仿真器可以编译用户的设计了。要想使仿真器真正发挥验证作用，还需要在SystemVerilog的基础上搭建各种应用，如Debug、SVA、Coverage等，才能最终使仿真器成为真正的仿真平台。此外，性能始终是仿真器的核心。　在完成SystemVerilog支持的同时，如何结合调试（Debug），提升性能方面的功能，也是需要面对的重大课题。

接下来，我们会结合数字仿真器的其他功能与性能要求，诸如coverage、debug等方面，更进一步讲解一款高质量的数字仿真器应该具备哪些特征。独木不成林，我们也期待行业的各位有志同仁，参与我们的讨论，一起畅谈国产数字仿真器发展之路。欢迎您关注“芯华章”官方微信公众号并在后台留言，或者反馈给我们的市场部邮箱communications@x-epic.com。每一个宝贵的意见，我们都将认真对待！