2999
SystemVeirlog的全面支持是开发商用仿真器的第一道门槛。市面上可以找到不少基于纯Verilog的仿真器，但是真正能完整支持SystemVerilog 的仍然屈指可数。如何全面地支持SystemVerilog语言，是开发仿真器的一个重要任务。
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（语言参考手册）的标准，但是由于其发展路径不同，在性能上及个别语义上，仍然存在一定的差异。
SystemVerilog的语法特点
SystemVerilog为了给验证提供更多的灵活性，从其他编程语言，尤其是面向对象的编程语言（如C++， Java）借鉴了很多语法。这使得SystemVerilog语法非常复杂，各种语法耦合性强，环环相扣。
因此，这就要求在设计时，需要一个全局的概念，不能切成一个个孤立的模块，否则最终很难拼起来；即使勉强拼出来，也不牢固。这点非常像中国古建筑的“榫卯”结构。比如，SystemVerilog引入了class、structure，以及各种动态类型的数组，如 queue。这些都不能是孤立的。它们在实际使用中（比如UVM）都是嵌套使用的。一个类型的数组，很可能其元素是另一个类型。
以下通过一个uvm的例子，来更直观的了解一下SystemVerilog的语法。
一个支持SystemVerilog的仿真器，要想跑通上述case，至少需要关注以下几个方面：
复合类型成员的初始化
class ’my_sequence’ 中的成员 ’settings’(第12行)是一个queue类型的变量。这种类型的变量需要进行特殊的初始化，给queue分配初始空间。该queue的成员又是一个struct 类型，而struct是个复合类型，因此，这里面是一类比较复杂的嵌套类型。
数组的方法调用（array method）
上面例子用到了‘sort’这个方法(第25行)。这里面，又涉及到了嵌套类型，因为queue的成员是struct 类型的。而struct属于复合类型，是不能直接比较的。IEEE1800标准引入了 with (item.mebmer...)，可以针对复合类型的某个成员进行排序操作。
垃圾回收
SystemVerilog类似Java，它不需要用户自己进行类似delete操作。这就要依赖仿真器提供垃圾回收的功能。否则在运行时会出现内存泄漏。
进程管理
上述例子中的task ‘main_phase’ 中用到了‘fork join‘，(第33-36行)。仿真器需要有一套进程管理来支持这个用法。进程管理实现的是否高效，将直接影响到仿真器的性能。
除此之外，还有很多技术点需要考虑，这里就不赘述了。总之，一个对SystemVerilog全面覆盖的顶层设计，对支持UVM非常关键。
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——
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企业在事实上使用了。这些规范都是被数十年客户检验过，也是在实际应用中必须遵守的“戒律”。
总结
SystemVerilog作为最复杂的语言之一，是国产数字仿真器开发的第一道门槛。如果LRM（语言参考手册）的覆盖率不够，就会阻碍仿真器的商用推广。但从上文的分析中不难发现，实现复杂的SystemVerilog需要巨大的工程量。如何在纷杂的SystemVerilog语法中将主流UVM所需的部分，高质高量地实现出来，是GalaxSim为代表的国产EDA数字仿真器，需要解决的首要问题。
芯华章核心研发团队曾在跨国公司成功主导过大型仿真器项目研发，对验证语言、方法学、仿真器核心构架、算法、优化有着丰富的技术储备，尤其在SystemVerilog 方面有着多年的耕耘，因此能将复杂的SystemVerilog背后的“榫卯”嵌套结构梳理清楚，进而可以在清晰的架构上，一步到位支持几乎所有SystemVerilog的语法。
实现对SystemVerilog语法的支持，仅仅使得仿真器可以编译用户的设计了。要想使仿真器真正发挥验证作用，还需要在SystemVerilog的基础上搭建各种应用，如Debug、SVA、Coverage等，才能最终使仿真器成为真正的仿真平台。此外，性能始终是仿真器的核心。在完成SystemVerilog支持的同时，如何结合调试(Debug)，提升性能方面的功能，也是需要面对的重大课题。
