解碼國產(chǎn)EDA數(shù)字仿真器系列之二 | 如何實(shí)現(xiàn)全面的SystemVerilog語法覆蓋？

SystemVeirlog的全面支持是開發(fā)商用仿真器的第一道門檻。市面上可以找到不少基于純Verilog的仿真器，但是真正能完整支持SystemVerilog 的仍然屈指可數(shù)。如何全面地支持SystemVerilog語言，是開發(fā)仿真器的一個(gè)重要任務(wù)。

SystemVerilog的發(fā)展歷程

數(shù)字芯片的驗(yàn)證技術(shù)是隨著Verilog語法的演變而演變的。最早，Verilog是完全用來描述（Model）硬件的，因此又叫HDL（Hardware Description Language硬件描述語言）。隨著驗(yàn)證技術(shù)的進(jìn)步，需要將很多軟件的思路融進(jìn)Testbench以豐富測試場景。EDA公司都曾經(jīng)推出過一些針對(duì)Testbench的語言，如OpenVera等。

與Verilog的靜態(tài)屬性不同，這些Testbench的驗(yàn)證語言引入了很多動(dòng)態(tài)的概念，甚至有類（class）、繼承、多態(tài)等。然而最終，這些語言又逐步融進(jìn)了Verilog，最終形成了今天的SystemVerilog。下圖顯示在SystemVerilog剛剛成為標(biāo)準(zhǔn)時(shí)，它各個(gè)模塊的來源。

圖片來源：SystemVerilog is changing everything - Tech Design Forum Techniques (techdesignforums.com)

基于SystemVerilog，各個(gè)EDA廠商推出了各自的仿真器，并在這個(gè)基礎(chǔ)上，進(jìn)一步開發(fā)了基于SystemVerilog的methodology library, 最后統(tǒng)一成今天用的通用驗(yàn)證方法學(xué)——UVM （Universal Verification Methodology）。

從上面的歷程可以看出，SystemVerilog的發(fā)展和支持不是一步到位的，是在其他語言的基礎(chǔ)上經(jīng)過多年演變形成的。各個(gè)EDA廠商根據(jù)他們的自身優(yōu)勢開發(fā)了對(duì)SystemVerilog的支持。雖然這些仿真工具都符合LRM（語言參考手冊(cè)）的標(biāo)準(zhǔn)，但是由于其發(fā)展路徑不同，在性能上及個(gè)別語義上，仍然存在一定的差異。

SystemVerilog的語法特點(diǎn)

SystemVerilog為了給驗(yàn)證提供更多的靈活性，從其他編程語言，尤其是面向?qū)ο蟮木幊陶Z言（如C++， Java）借鑒了很多語法。這使得SystemVerilog語法非常復(fù)雜，各種語法耦合性強(qiáng)，環(huán)環(huán)相扣。

因此，這就要求在設(shè)計(jì)時(shí)，需要一個(gè)全局的概念，不能切成一個(gè)個(gè)孤立的模塊，否則最終很難拼起來；即使勉強(qiáng)拼出來，也不牢固。這點(diǎn)非常像中國古建筑的“榫卯”結(jié)構(gòu)。比如，SystemVerilog引入了class、structure，以及各種動(dòng)態(tài)類型的數(shù)組，如 queue。這些都不能是孤立的。它們?cè)趯?shí)際使用中（比如UVM）都是嵌套使用的。一個(gè)類型的數(shù)組，很可能其元素是另一個(gè)類型。

以下通過一個(gè)uvm的例子，來更直觀的了解一下SystemVerilog的語法。

一個(gè)支持SystemVerilog的仿真器，要想跑通上述case，至少需要關(guān)注以下幾個(gè)方面：

復(fù)合類型成員的初始化

class ’my_sequence’ 中的成員 ’settings’(第12行)是一個(gè)queue類型的變量。這種類型的變量需要進(jìn)行特殊的初始化，給queue分配初始空間。該queue的成員又是一個(gè)struct 類型，而struct是個(gè)復(fù)合類型，因此，這里面是一類比較復(fù)雜的嵌套類型。

數(shù)組的方法調(diào)用（array method）

上面例子用到了‘sort’這個(gè)方法(第25行)。這里面，又涉及到了嵌套類型，因?yàn)閝ueue的成員是struct 類型的。而struct屬于復(fù)合類型，是不能直接比較的。IEEE1800標(biāo)準(zhǔn)引入了 with (item.mebmer...)，可以針對(duì)復(fù)合類型的某個(gè)成員進(jìn)行排序操作。

垃圾回收

SystemVerilog類似Java，它不需要用戶自己進(jìn)行類似delete操作。這就要依賴仿真器提供垃圾回收的功能。否則在運(yùn)行時(shí)會(huì)出現(xiàn)內(nèi)存泄漏。

進(jìn)程管理

上述例子中的task ‘main_phase’ 中用到了‘fork join‘，(第33-36行)。仿真器需要有一套進(jìn)程管理來支持這個(gè)用法。進(jìn)程管理實(shí)現(xiàn)的是否高效，將直接影響到仿真器的性能。

除此之外，還有很多技術(shù)點(diǎn)需要考慮，這里就不贅述了?？傊?，一個(gè)對(duì)SystemVerilog全面覆蓋的頂層設(shè)計(jì)，對(duì)支持UVM非常關(guān)鍵。

SystemVerilog的scheduling semantics

當(dāng)人們理解SystemVerilog時(shí)，可能會(huì)比較專注該語言增加的語法部分，但是這里要注意的是，SystemVerilog的引入仍然是為了驗(yàn)證硬件，而不是為了開發(fā)軟件。它是為了豐富Testbench做驗(yàn)證的能力。SystemVerilog在豐富了語法的同時(shí)，也會(huì)帶來其他的問題，這就需要制定更多的規(guī)范來定義這些新出現(xiàn)的狀況，IEEE1800 scheduling semantics就是一個(gè)。

Phil Moorby 是Verilog的發(fā)明者。他寫了Verilog的第一個(gè)仿真器——Verilog-XL。Verilog的仿真從誕生起，其實(shí)就存在一個(gè)問題，那就是如何確保Verilog仿真器軟件的行為和硬件的行為一致，否則仿真就沒有意義。為此，需要制定一些細(xì)則，來規(guī)范Verilog在scheduling 上的行為。其中，大家比較熟悉的非阻塞賦值（non-blocking assignment）, 就是Phil 引入的，其目的就是確保Verilog在仿真時(shí)序邏輯時(shí)的行為和硬件一致。

2002年，Phil Moorby加入Synopsys, 從事SystemVerilog語言的定義和開發(fā)工作。筆者曾有幸和Phil共事，參與了早期SystemVerilog相關(guān)feature（如clocking block等）的開發(fā)。這些新的SystemVerilog語法的引入會(huì)對(duì)Simulator的行為帶來一定的不確定性，為此，Phil對(duì)原有的Verilog scheduling semantics進(jìn)行了擴(kuò)展來消除這些不確定，其中包括Testbench和DUT之間能進(jìn)行精準(zhǔn)的無歧義的數(shù)據(jù)通信。這些思想，后來都被Accellera國際電子行業(yè)標(biāo)準(zhǔn)化組織采納，變成了今天IEEE1800 scheduling semantics 的一部分。

以下是1800 scheduling的semantic，來自 IEEE1800-2017, page 64——

GalaxSim對(duì)SystemVerilog的設(shè)計(jì)思路

前面提到，SystemVerilog并非誕生起就一成不變的，而是在不斷變化發(fā)展。因此，作為后來者，芯華章開發(fā)的高性能數(shù)字仿真器GalaxSim，在開發(fā)SystemVerilog時(shí)，不存在EDA巨頭公司的歷史包袱，可以從一開始，就把SystemVerilog當(dāng)作一個(gè)整體來支持，而不是先支持老的Verilog部分，再支持新的SystemVerilog 部分。這里面包括了以下一些設(shè)計(jì)上的考慮：

1) 更精準(zhǔn)的SytemVerilog語義解析

SystemVerilog經(jīng)過了十幾年的使用和演變，有些早期的語義可能有了新的含義。此外，很多SystemVerilog的語法是在先有了EDA工具支持后再寫入標(biāo)準(zhǔn)的。我們?cè)趯?shí)現(xiàn)SystemVerilog支持時(shí)，會(huì)根據(jù)其背后所體現(xiàn)的實(shí)際驗(yàn)證應(yīng)用背景來設(shè)計(jì)仿真行為，而不是簡單地做一個(gè)語言層面的編譯器。這樣，我們確保了GalaxSim在SystemVerilog上的仿真行為上和國際主流仿真工具兼容。

2）更加原生的支持

EDA主流的仿真器在支持SystemVerilog上都走了很長的一段路，這是因?yàn)镾ystemVerilog本身并沒有穩(wěn)定下來。往往會(huì)出現(xiàn)的情況是，既有的仿真器的infrastructure無法滿足新出現(xiàn)的SystemVerilog的語法。

GalaxSim不會(huì)面臨這個(gè)問題，因?yàn)槲覀冊(cè)谠O(shè)計(jì)其基礎(chǔ)結(jié)構(gòu)的時(shí)候，就會(huì)把SystemVerilog需要的各種data type一并考慮進(jìn)去。這樣的設(shè)計(jì)帶來的優(yōu)勢就是開發(fā)更加流暢，質(zhì)量更高。

3）更加優(yōu)異的性能

性能始終是仿真器的靈魂。然而，對(duì)于SystemVerilog這種相對(duì)較新的語言，其性能往往不如純Verilog。這是因?yàn)?，它們往往是先開發(fā)feature，確保功能的完備性；直到后來在客戶端遇到了性能問題，再進(jìn)行性能優(yōu)化甚至重構(gòu)。

GalaxSim對(duì)SystemVerilog的支持，在設(shè)計(jì)之初，就根據(jù)目前的設(shè)計(jì)規(guī)模，將性能問題與功能同步設(shè)計(jì)，確保4大性能指標(biāo)（Compile Time、Compile Memory、Run Time、Run Memory）比肩甚至超越國際主流仿真器。

4）更加貼近驗(yàn)證的scheduling semantics

SystemVerilog的目的是為了驗(yàn)證。因此，仿真器對(duì)scheduling的要求是非常嚴(yán)格的。有些甚至并沒有非常明確地寫在標(biāo)準(zhǔn)里，但是已經(jīng)被業(yè)內(nèi)主流EDA企業(yè)在事實(shí)上使用了。這些規(guī)范都是被數(shù)十年客戶檢驗(yàn)過，也是在實(shí)際應(yīng)用中必須遵守的“戒律”。

總結(jié)

SystemVerilog作為最復(fù)雜的語言之一，是國產(chǎn)數(shù)字仿真器開發(fā)的第一道門檻。如果LRM（語言參考手冊(cè)）的覆蓋率不夠，就會(huì)阻礙仿真器的商用推廣。但從上文的分析中不難發(fā)現(xiàn)，實(shí)現(xiàn)復(fù)雜的SystemVerilog需要巨大的工程量。如何在紛雜的SystemVerilog語法中將主流UVM所需的部分，高質(zhì)高量地實(shí)現(xiàn)出來，是GalaxSim為代表的國產(chǎn)EDA數(shù)字仿真器，需要解決的首要問題。

芯華章核心研發(fā)團(tuán)隊(duì)曾在跨國公司成功主導(dǎo)過大型仿真器項(xiàng)目研發(fā)，對(duì)驗(yàn)證語言、方法學(xué)、仿真器核心構(gòu)架、算法、優(yōu)化有著豐富的技術(shù)儲(chǔ)備，尤其在SystemVerilog 方面有著多年的耕耘，因此能將復(fù)雜的SystemVerilog背后的“榫卯”嵌套結(jié)構(gòu)梳理清楚，進(jìn)而可以在清晰的架構(gòu)上，一步到位支持幾乎所有SystemVerilog的語法。

實(shí)現(xiàn)對(duì)SystemVerilog語法的支持，僅僅使得仿真器可以編譯用戶的設(shè)計(jì)了。要想使仿真器真正發(fā)揮驗(yàn)證作用，還需要在SystemVerilog的基礎(chǔ)上搭建各種應(yīng)用，如Debug、SVA、Coverage等，才能最終使仿真器成為真正的仿真平臺(tái)。此外，性能始終是仿真器的核心。在完成SystemVerilog支持的同時(shí)，如何結(jié)合調(diào)試(Debug)，提升性能方面的功能，也是需要面對(duì)的重大課題。