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

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

SystemVerilog的發(fā)展歷程

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

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

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

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

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

SystemVerilog的語法特點

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

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

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

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

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

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

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

上面例子用到了‘sort’這個方法(第25行)。這里面，又涉及到了嵌套類型，因為queue的成員是struct 類型的。而struct屬于復(fù)合類型，是不能直接比較的。IEEE1800標準引入了 with (item.mebmer...)，可以針對復(fù)合類型的某個成員進行排序操作。

垃圾回收

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

進程管理

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

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

SystemVerilog的scheduling semantics

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

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

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

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

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

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

1) 更精準的SytemVerilog語義解析

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

2）更加原生的支持

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

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

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

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

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

4）更加貼近驗證的scheduling semantics

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

總結(jié)

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

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

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