數(shù)字硬件建模SystemVerilog(三)-仿真

數(shù)字仿真是一種軟件程序，它將邏輯值變化（稱為激勵）應用于數(shù)字電路模型的輸入，以實際硅傳播這些邏輯值變化的相同方式通過模型傳播該激勵，并提供觀察和驗證該激勵結果的機制。

SystemVerilog是一種使用0和1的數(shù)字仿真語言。該語言不表示仿真電壓、電容和電阻。SystemVerilog提供的編程結構，用于對數(shù)字電路建模、對激勵發(fā)生器建模以及對驗證檢查器建模。

示例1.4說明了一個可以仿真的簡單數(shù)字電路模型。這與前面示例1.3所示的電路相同。

示例1-4：帶有輸入和輸出端口的設計模型（32位加法器/減法器）在本例中，請注意模型具有輸入端口和輸出端口。為了仿真該模型，必須提供將邏輯值應用于輸入端口的激勵，并且必須提供響應檢查器以觀察輸出端口。

使用testbench封裝激勵生成和響應驗證。在SystemVerilog中有許多方法可以對測試臺進行建模，測試臺中的代碼可以是簡單的編程語句，也可以是復雜的面向?qū)ο蟆⑹聞占壘幊?，示?-5說明了32位加法器/減法器設計的簡單testbench。

示例1-5：32位加法器/減法器模型的testbench例1-5中的主要代碼塊是一個初始化過程，它是一種過程塊，過程塊包含編程語句和時序信息，用于指示仿真器做什么以及什么時候做。SystemVerilog有兩種主要類型的程序塊：initial procedures and always procedures。

初始過程是用關鍵字initial定義的。初始過程，不管其名稱如何，都不用于初始化設計。相反，初始過程只執(zhí)行一次編程語句。當?shù)竭_最后一條語句時，對于給定的仿真運行，不會再次執(zhí)行初始過程。初始過程不可綜合，也不用于RTL建模。本系列著重于編寫用于仿真和合成的RTL模型，因此不再深入討論初始過程。

Always過程是用關鍵字always、always_comb、always_ff和always_latch定義的，Always過程是一個無限循環(huán)，當過程完成過程中最后一條語句的執(zhí)行時，過程自動返回到開頭，并再次啟動過程。對于RTL建模，Always程序必須以靈敏度列表開始；例如示例1-4）中所示的@（posedge clk）定義。后面將更詳細地討論各種形式的always程序。

過程塊可以包含一條語句，也可以包含一組語句。過程塊中的多個語句在關鍵字begin和end之間分組（驗證代碼還可以在關鍵字fork和join、join_any或join_none之間分組語句）。begin和end之間的語句按其列出的順序執(zhí)行，即：從第一條語句開始，到最后一條語句結束。

示例1-5中的初始過程包含一個重復循環(huán)。這個循環(huán)被定義為執(zhí)行10次。循環(huán)的每個過程：

• l、 延遲到c1k信號的下降沿。
• 2. 為設計的a、b和mode輸入生成隨機值。
• 3. 延遲到clk的下一個下降沿，然后調(diào)用檢查結果任務（子例程）以驗證設計輸出是否與計算的預期結果匹配。

該設計在其時鐘輸入的上升沿工作。測試臺使用同一時鐘的相對邊緣，以避免在設計使用的時鐘邊緣上驅(qū)動輸入和讀取設計的輸出。如果測試臺在時鐘的下降沿驅(qū)動值，則在設計使用輸入之前，這些輸入的穩(wěn)定設置時間為零。同樣，如果測試臺在時鐘的下降沿驗證設計結果，那么這些設計輸出穩(wěn)定的時間將為零。

在同一時刻修改和讀取值被稱為simulation競爭條件。使用設計時鐘的相對邊緣來驅(qū)動激勵是測試臺避免設計仿真競爭條件的一種簡單方法，例如滿足設計設置和保持時間要求。

測試臺被建模為具有輸入和輸出端口的模塊，類似于正在驗證的設計。最后一步是將測試臺端口連接到設計端口，并生成時鐘。這是在頂級模塊中完成的。示例1-6顯示了這方面的代碼。

示例1-6：將測試臺連接到設計的頂層模塊# 系統(tǒng)Verilog仿真器

所有SystemVerilog仿真器都有很多共同點，這對于理解如何編寫能夠正確仿真的SystemVerilog RTL模型至關重要。這些功能包括：編譯、精化、仿真時間和仿真事件調(diào)度（compilation elaboration simulation time and simulation event scheduling），下面將討論仿真的這些方面。

編譯和精化Compilation and elaboration

SystemVerilog源代碼需要編譯和詳細說明才能進行仿真。編譯包括根據(jù)IEEE SystemVerilog標準中定義的規(guī)則檢查SystemVerilog源代碼，以確保其語法和語義正確。精化將構成設計和測試臺的模塊和組件綁定在一起。精化還解析可配置代碼，例如常量的最終值、向量大小和仿真時間縮放。

IEEE SystemVerilog標準沒有定義精確的編譯和精化過程。標準允許每個仿真器供應商以供應商認為最適合該產(chǎn)品的方式定義該過程以及編譯和精化之間的劃分。一些仿真器將編譯和精化過程作為單個步驟進行組合，而其他仿真器將這些過程劃分為單獨的步驟。一些仿真器可能在編譯階段捕獲源代碼中某些類型的錯誤，而其他仿真器在精化階段捕獲這些錯誤。這些差異不會影響本系列中討論的RTL編碼風格和指南，但了解所使用的仿真器如何處理RTL源代碼的編譯和精化是有幫助的。請參閱特定仿真器的文檔，了解該產(chǎn)品如何處理編譯和精化。

源代碼順序

SystemVerilog語言，與大多數(shù)語言一樣；如果不是所有編程語言在源代碼順序上都有一定的依賴關系，那么在引用這些定義之前，必須編譯用戶定義的類型聲明和聲明包。用戶定義的類型聲明和包通常與使用聲明的RTL代碼位于不同的文件中。這意味著設計者必須注意這些文件是按正確的順序編譯的，因此聲明是common的，在被引用之前堆積起來.

并非所有聲明都是順序相關的，例如，SystemVerilog允許在編譯模塊之前引用模塊名稱。在模塊內(nèi)，任務和函數(shù)可以在定義之前調(diào)用，只要定義在模塊內(nèi)。

全局聲明和$unit聲明空間

SystemVerilog允許在名為unit中的聲明可以由多個文件共享，全局聲明依賴于編譯順序，必須在引用之前編譯，全局unit添加定義，這可能會導致隨意的全局定義，從而難以確保在引用定義之前對其進行編譯.

SystemVerilog編譯器指令，如“定義文本宏和”時間刻度時間縮放，也屬于$unit space，全局聲明必須在受指令影響的代碼之前編譯。

最佳做法準則1-1

將包用于全局聲明，而不是$unit聲明空間。

單文件和多文件編譯

當涉及多個文件時，IEEE SystemVerilog標準定義了兩種編譯/精化范例的規(guī)則：多文件編譯和單文件編譯。

多文件編譯范例允許同時編譯多個源代碼文件。一個文件中的全局聲明和編譯器指令對于在聲明和指令之后編譯的其他文件中的源代碼是可見的。

單文件編譯范例允許獨立編譯每個文件。一個文件中的任何全局聲明或編譯器指令僅在該文件中可見。無論文件的編譯順序如何，其他文件都不會看到這些聲明或指令。

所有仿真器和合成編譯器都支持多文件范例，但并非所有工具都支持單文件編譯，但是，默認情況下，支持兩種范例的工具不一定使用相同的范例。默認情況下，某些工具使用單文件編譯，多文件編譯需要特定于工具的調(diào)用選項。默認情況下，其他工具使用多文件編譯，并且需要調(diào)用選項進行單文件編譯或增量重新編譯。

關于仿真或者驗證方面，還有很多很多內(nèi)容，但是不是本系列重點，所以這里推薦《systemverilog驗證》了解更多關于SV的仿真和驗證知識。