IC驗證培訓——SV Interface 入門指導

路桑的個人網址：路科驗證 -IC驗證培訓-數字晶片驗證

當涉及到驗證時，介面可能是SystemVerilog語言中經常用到的部分。介面廣泛的應用在靜態的被測設計（DUT）和動態的測試平臺之間。本文介紹了在典型的片上系統（SOC）中不同的測試平臺連線到DUT的方法。

 

一、介紹

將測試臺連線到DUT的最常見方法是SystemVerilog虛擬介面。這種方法在許多情況下是連線到DUT的最佳方式。

 

根據我們的專業經驗，應該把被測設計作為一個黑盒，並且測試臺完全獨立於被測設計。因此我們堅決反對將SystemVerilog動態的測試模型中層次化的行為模型做的同靜態的DUT中一樣。應該將測試平臺的構造獨立於DUT的層次。這將使測試平臺更容易複用。當測試平臺需要訪問DUT中的例項時，例如通過後門暫存器進行讀或寫，我們展示瞭如何使用SystemVerilog繫結的結構體和類將DUT連線到測試平臺上。這相當於保持了SystemVerilog在靜態的DUT中的層次的參考。

 

在以下所有示例中，測試環境被構建成幾乎所有驗證IP(VIP)都是UVM相容的。這允許使用者在時間允許的情況下將傳統VIP遷移到通用驗證元件（UVCs）上，而不必更改測試環境，測試序列和測試用例。VHDL匯流排功能模型（BFMs）將被整合到一個環境中，看起來就像一個（UVC）。

 

圖1是典型的SOC處理器，外設和自定義邏輯模組的高層次框圖。下面的示例參考了我們的SOC的UART模組。

二、VHDL匯流排功能模型

與人們的想法相反，VHDL仍然廣泛用於FPGA的開發。在許多情況下，使用者可能擁有現有VHDL BFM的大型庫，並希望遷移到UVM測試環境，但可能不知道如何將BFM整合到UVM測試平臺。其中一些使用者假定所有的傳統VHDL模型必須轉換為SystemVerilog UVC。 在這裡，我們證明轉換到UVC不是必須的。雖然不像Verilog BFM有多種方法可以整合到UVM測試環境中，但在UVM測試臺中也有一種方法連線VHDL BFM。

 

使用VHDL BFM時需要解決幾個問題，最重要的一個是沒有VHDL-SystemVerilog模擬的語言參考手冊（LRM）。這意味著每個模擬器的供應商對於這兩種語言的互通性都有自己特定的規則（限制VHDL的埠型別，常量和資料型別）。下一個問題，不可能在SystemVerilog中呼叫VHDL的程式；或者將SystemVerilog中的跨模組參考模型（XMR）應用到VHDL的實體中（注意：由於取決於供應商，在UVM基類庫中也不支援通過暫存器模型後門訪問VHDL）。

 

互動性和程式呼叫的問題可以通過向BFM中新增兩個層次的程式碼的方法來解決。第一層是將VHDL進行封裝：將record型別的埠分解成單獨的訊號，並呼叫BFM過程。第二層是將VHDL BFM封裝後連線到SystemVerilog虛擬介面上。為了最大可能的確保在不同的模擬器上都能互動成功，我們將VHDL BFM 的封裝埠的資料型別定義為：std_logic， std_logic_vector， integer，和 real data types型別（注意：通常也支援strings型別）。

在圖2的示例中，DUT是典型的UVM測試平臺中的一個簡單的UART。靜態測試平臺包含DUT，時鐘和復位發生器，還有封裝好的BFM和一些虛擬介面。

圖3所示的傳統BFM在其埠對映中有一個record型別。它從佇列中彈出transaction並呼叫uart_read，uart_write和uart_reset任務，這些任務在圖4所示的包中定義。這個包也定義了埠對映中使用到的record型別。

如圖5所示VHDL BFM wrapper，將BFM的記錄型別埠分解為單獨的訊號。基於由虛擬介面驅動的訊號，它通過呼叫函式將transactions 插入到uart_bfm ben架構使用的佇列中。

圖6顯示了將動態驗證環境連線到VHDL BFM wrapper上的介面。

 

圖7中的測試平臺例化了DUT，VHDL BFM wrapper和SystemVerilog介面：

環境中UART的主要任務是呼叫BFM中的過程。這個過程會反過來作用到DUT的引腳上。uart_uvc_if的start和done訊號使得過程被呼叫。當一個讀或者寫操作的sequence在UART上啟動時，driver將設定rw_start訊號。這將啟動從VHDL wrapper到BFM上的的一個讀或者寫的過程。當這個過程完成後，VHDL wrapper將設定rw_done訊號來告訴uart_driver來呼叫item_done。driver的原始碼見圖8。

從測試環境的角度看來，這和普通的舊的UVM測試環境並沒有什麼差別。測試用例和測試環境可以不經修改的直接使用；並且如果專案進度允許的話，UART UVC可以在uart_driver上進行很小的修改從而遷移到標準UVC上。

 

三、Verilog匯流排功能模型

對於Verilog BFM，有多種方法可用於將BFM整合到UVM測試平臺中。 所選擇的方法需要考慮以下幾個因素：

• BFM程式碼可以被修改嗎？

• BFM需要引數嗎？

• BFM使用引數化的介面嗎？

這些因此決定那種方法最適合將特定的BFM整合到UVM測試平臺中。所有以下解決方案允許在測試臺中使用多個BFM，而不必在測試環境中硬編碼例項化識別符號。

 

（A）BFM Wrapper

如果現有的Verilog BFM不能被修改，一種處理方法是將BFM封裝一下，如前面的VHDL示例一樣。

 

（B） Abstract and Concrete Class

也可以通過使用抽象和具體類來整合Verilog BFM。這種情況下，靜態測試平臺和動態環境採用略有不同的形式，測試平臺來例化一個具體的類，這個類是從測試環境中定義的抽象類中派生而來的:

注意在圖9中，沒有使用虛擬介面，而是在測試平臺的程式碼中使用型別過載來將動態的測試環境連線到靜態的測試平臺上。派生類uart_driver_concrete可以定義在與例化BFM的同一個作用域中，以此來訪問舊版Verilog BFM。當動態環境的基類成員uart_driver通過型別過載建立為uart_driver_concrete時，它們將具有相同的作用域，因此也可以訪問BFM。參見圖10，基類和派生類的使用給出了虛擬介面的錯覺。這一切都是源於factory機制，基類在UVM factory中註冊並在執行時被過載。

 

如果BFM具有引數化的介面，那麼使用抽象/具體類是連線到DUT的一個不錯的選擇。

 

（C） Interface中的任務

如果使用者幸運地擁有可以修改的BFM，那麼最簡單的方法是將任務複製並貼上到SystemVerilog介面中。靜態測試平臺將具有包含BFM任務的虛擬介面。測試環境將包含shell UART agent。下圖與之前顯示的VHDL示例幾乎相同。環境是相同的，但圖11所示的靜態測試平臺的不同之處在於，虛擬介面直接連線到DUT，而不是通過BFM wrapper。

四、硬體/軟體流程控制

驗證任何SOC時都會遇到一個古老的問題：哪個先到，軟體還是硬體？對於一個擁有大量優秀軟體工程師的公司，建立一個在處理器上執行程式碼的模擬環境很有意義。這些公司通過執行與ASIC並行開發的實際應用程式程式碼來驗證SOC。另一方面，如果使用現有硬體來驗證軟體，或者在真實硬體可用之後，模擬環境將以硬體為中心。在這兩種情況下，都會有在處理器上執行的程式碼。主要區別是主要起控制作用的是硬體端還是軟體端。

 

不管哪種情況，在硬體和軟體之間需要某種型別的同步/握手機制。這種同步通常使用共享儲存器（或郵箱）來實現。任何測試的一般流程如下：處理器載入程式碼，處理器啟動，然後監視郵箱以獲得告訴硬體要做什麼的命令（例如，從VIP向DUT傳送一些乙太網分的包，或者將一些資料從DUT上的SPI埠傳送到SPI VIP）。

 

這是“軟體為中心”的流程，“硬體為中心”的流程與其類似，一旦處理器啟動完畢，控制命令將被傳遞到SystemVerilog段，並啟動sequences。在以硬體為中心的流程中，處理器的操作被簡化為三個命令：讀，寫，比較。這允許使用最小量的C（或彙編）程式碼來對SOC硬體進行功能驗證。

 

要在硬體和軟體之間來回傳遞控制，需要監視和驅動DUT內部的節點，理想情況下不需要在共享記憶體中建立層次化的行為模型。對於以硬體為中心的方法，我們將使用一個processor agent，將命令（讀，寫或比較）寫入共享記憶體，並設定處理器中斷。 處理器中斷子程式讀取共享儲存器，執行請求的命令，然後在命令完成後清除中斷。

 

如圖13所示，processor agent是標準UVM agent，除了driver具有額外的介面。這個event_if介面在圖14中被定義，它包含了一些事件，在這些事件中driver可以控制傳送到處理器到命令。

如圖14所示，monitor在儲存內容改變時設定這些事件。除了被driver使用之外，這些事件將由在測試環境中執行的sequences使用來控制執行。為了監視共享記憶體，我們使用一個SystemVerilog繫結結構，類似於白盒驗證技術。 使用虛擬介面中的任務來執行向共享儲存器寫入資料或從共享儲存器讀取資料。

五、UVM暫存器層後門訪問

UVM基類庫具有內建機制以允許後門訪問暫存器，但是可能存在無法使用預設DPI訪問暫存器的情況：VHDL DUT或者暫存器宣告為多維陣列，或者DPI對模擬效能有較大的影響。有一個代替方案是使用一個基類來進行使用者自定義的後門訪問。其中一種方法通過對DUT的層次化訪問以繞過DPI並提高模擬效能，但是測試臺不再能與DUT完全分離，並且暫存器模型的資料不能包含在資料包中。 另一種方法是將層次化的行為模型放到介面中。除了保持測試環境與DUT完全獨立之外，這種方法還具有從暫存器模型中刪除DUT層次結構的優點，並且可以與VHDL DUT一起使用（注意：從SystemVerilog到VHDL的後門寫操作只能使用 模擬器特定程式）。如果DUT層級改變，但暫存器保持不變，則不需要更新暫存器模型，因為它不包含任何HDL層次化路徑構造，例如add_hdl_path（“top_tb.dut_wrapper.dut”）或status_reg_h.configure this，null，“<hierarchical_path_to_register>”）。

圖15顯示了SystemVerilog DUT的後門讀/寫任務。 如果DUT是VHDL，則必須使用如圖16所示的繫結結構。

六、引數的問題

對於使用工業標準通訊或匯流排協議的大多數設計，幾乎所有VIP都使用引數化介面，如圖17所示。引數化的介面需要建立一個引數化的類，它可以根據通用類和實際的引數值的不同被例化為不同樣子。對於有多個引數相組合的設計，這將增加測試平臺的複雜性，並且需要使用基於型別的factory而不是基於字串的factory。

如果你的設計僅包含最少數量的引數值，多個AHB都具有相同的地址和資料寬度，那麼使用引數化類可能是一個很好的選擇。另一方面，如果有多個引數化介面需要許多值的組合，最好的解決方案是使用抽象基類-具體派生類。

當具體化變得很麻煩，抽象基類-具體派生類便能發揮很大的作用。圖18所示的例子與本文第三節B部分的例子大致相同。測試平臺例化了含有不同引數的介面。介面本身定義了一個具體的類，它擴充套件了一個抽象基類，並定義了用於切換DUT引腳的任務。這個抽象類是driver的成員並通過driver呼叫get_config_object()進行過載。唯一需要知道引數的實體是測試平臺本身。

 

七、結論

本文介紹了在典型的片上系統（SOC）設計中使用不同的方法連線測試平臺和DUT。它包括很多有關連線方法的例子，同時嚴格遵守將動態和靜態原件分離的思想。用本文介紹的技術，使用者可以利用其現有的驗證IP建立高度可重用的測試環境，並且如果時間允許的話可以用UVC替換BFM。

 

謝謝你對路科驗證的關注，也歡迎你分享和轉發真正的技術價值，你的支援是我們保持前行的動力。