通用驗證方法學

通用驗證方法學聯合支援的驗證方法學，其最新版本為1.2版。概述.最原始、最簡陋的Verilog測試平臺通常會做以下幾件事情：第一，在測試平臺模組中例化被測設計；第二，建立若干變數中的不同時間點對它們進行賦值，使這些變數充當被測設計的輸入激勵；第三，採集被測設計輸出埠的訊號，或者直接採集被測設計的內部訊號；第四，在測試平臺模組內建立一些功能模組，將採集到的訊號與根據之前設計規範預測的參考數值進行對比，然後輸出一些資訊以方便故障的排除。這樣的驗證模式對於簡單的被測設計尚可，但是如果被測設計的複雜程度較高，這樣的測試平臺將會變得十分臃腫，而且不利於工程師維護和重用。例如，如果驗證人員想在原有輸入激勵基礎上新增一系列新的測試序列，則很可能會牽一髮而動全身，影響測試平臺的其他部分。工程師需要將驗證平臺的不同組分，例如輸入激勵、輸出採集、記分板對比等不同部分相互隔離。在超大規模積體電路已經是主流的今天，Verilog結構化的程式設計方式使程式碼的複用成為了一個嚴重的難題。雖然SystemVerilog的面向物件程式設計特性提供瞭解決了上述問題的可能，但是仍然存在一些問題。工程師有了更靈活的語言，但是怎麼用這種語言來搭建驗證平臺卻是沒有明確規範的，因而不同人搭建的驗證平臺在結構上會有差異。最明顯的是，不同工程師對於驗證平臺功能的劃分可能不一樣，即使採用同樣的劃分，其中同類模組對外的介面。驗證方法學提供了一套基於SystemVerilog的類庫，驗證工程師以其中預定義的類作為起點，就可以建立起具有標準結構的驗證平臺。由於行業競爭的關係，歷史上不同廠商曾推出了數種略有差異的驗證方法學。使用不同驗證方法學的驗證平臺之間的互操作性仍有一定的障礙。為了進行實現驗證方法學的標準化，早在2009年12月，內部就透過投票，決定以之前的2.1.1版為基礎，構建一個新的功能驗證方法學。在此之前，不同的電子設計自動化廠商相繼推出了自己的驗證方法學，例如開放驗證方法學就是Cadence和Mentor Graphics合作推出的。這種情況就造成了不同驗證方法學之間的協同工作需要工程師額外的精力。2011年2月21日，Accellera通過了通用驗證方法學的1.0版，並得到了三大廠商的共同支援。目前最新版本為1.2版。類庫結構.以下列出了通用驗證方法學的類庫結構，注意這與驗證平臺中例項的層次關係有所不同例化被測設計的頂層模組.採用通用驗證方法學的驗證平臺最大的特點就是將其中不同功能的程式碼以標準化的規範相互分離。整個驗證平臺中最頂層的劃分是被測設計例項化和測試本身的劃分。劃分之後，被測設計之間的聯絡做準備：頂層模組和測試類之間的關聯.上面簡歷的這個頂層模組的聯絡是透過以下兩步建立的。run_test()方法.首先，當頂層模組執行codice_6方法。這些物件所屬的類都是從通用驗證方法學預定義的基類繼承而來，驗證人員需要覆蓋一些特定名稱的方法，通用驗證方法學的引擎在執行模擬時會自動呼叫這些方法，來達到驅動被測設計、取樣所需訊號的目的介面.介面。頂層模組還必須將所用的介面在工廠，即配置資料庫。測試類獲得這個介面之後，會負責將它在測試類這一端連線到測試類內部的相關元件，而是分別只對介面內的訊號進行讀寫。虛介面.介面是在頂層模組被例項化，並與被測設計例項進行連線的。理論上，測試類部分的成分，例如驅動器、監視器，也需要例項化一個介面，並透過配置資料庫與頂層模組中的介面例項進行匹配。測試類中的這個介面在例項化時，必須使用關鍵字codice_18關鍵字進行宣告。將配置資料庫中的介面取出，並賦值給此虛介面，就可以將測試類和頂層模組聯絡起來。測試類.由測試基類codice_12繼承。整個驗證平臺中除去頂層模組、被測設計之外的面向物件部分，其頂級類被稱為測試類。測試類通常負責例項化一個環境、一個序列，並呼叫序列例項的codice_20方法來啟動一個環境例項的代理例項的序列產生器。環境類.由環境基類codice_21繼承。記分板例項、訂閱者例項也在環境中被建立，它們通常不直接讀寫那個與頂層模組直接相連的介面。與那個介面發生直接關係的驅動器、監視器都由環境例項內的代理例項包裹。透過使用通訊介面，事務包由代理生成，傳輸給記分板和覆蓋統計模組。代理類.由代理基類codice_22繼承。序列發生器類.由序列發生器基類codice_23繼承。這一繼承是引數化繼承，需要指定與其相關的序列專案類的名稱。序列發生器不需要定義資料成員和方法。一旦高層次的測試中建立了一個序列例項，然後在測試類例項中執行了類似codice_24這樣的開啟方法，序列發生器例項就在後臺將連串的資料包傳送出去。開發人員只需要在驅動器類中呼叫其基類成員之一的codice_26通訊埠的codice_27方法，驅動器就能獲得資料包。驅動器類.由驅動器基類codice_28繼承。這一繼承是引數化繼承，需要指定與其相關的序列專案類的名稱。驅動器是代理中直接與被測設計發生作用的部分。它本身並不知道如何產生激勵訊號，它只是呼叫codice_27方法，從序列發生器接收的一系列資料包，然後將包中對應的訊號透過賦值施加到整個測試平臺的公共匯流排介面上，從而間接地給被測設計提供了所需的輸入激勵。監視器類.由監視器基類codice_30繼承。監視器是一個被動的模組，透過介面和被測設計中的訊號相連。獲得要監測的資料包負責接收。記分板類.由記分板基類codice_33繼承。記分板不直接與被測設計發生互動，而是透過通訊埠，從監視器那裡獲取後者提供的事務通常會提取出資料包中的訊號，然後將它們與預設的參考模型進行對比，從而驗證被測設計的功能是否與預期相同。如果不同，驗證人員可以選擇在螢幕上顯示提示或警告，或者直接中斷模擬的執行。訂閱者類.由訂閱者基類codice_35繼承。這一繼承是引數化繼承，需要指定與其相關的序列專案類的名稱。覆蓋統計模組通常是一個訂閱者。序列類.由序列基類codice_36繼承。。這一繼承是引數化繼承，需要指定與其相關的序列專案類的名稱。序列類不需要定義任何與codice_37有關的方法，開發人員只需要覆寫codice_38方法，隨機化方法codice_41會在呼叫codice_42生成資料包時被隱式地呼叫。序列專案類.由序列專案基類codice_43繼承。序列專案定義了了資料包每一幀包含哪些資料成員，這些資料成員可以被宣告為SystemVerilog的隨機變數型別，進一步產生連串的資料包。使用虛序列產生器和虛序列.虛序列產生器、虛序列本質上是序列產生器類和序列類的例項。有時存在多個序列來負責產生生針對被測設計不同部分的輸入資料包，並進一步需要使用多個獨立的序列產生器來連線不同的驅動器。這時通常會使用虛序列產生器和虛序列來排程多個這樣的操作。主要需要以下幾步：Phase的自動執行機制.通用驗證方法學測試類及其成員所屬的類都是從預定義的基類繼承，因此都具有有一系列以codice_54類的例項為引數的方法，分別對應該物件的建立、連線、執行等階段。開發人員只需要在自己的類定義裡覆寫這些方法，驗證方法學引擎就可以在執行測試時依次自動執行這些方法內的程式碼。主要的類方法的原型：配置資料庫.前面提到了在頂層模組中例項化和使用的介面可以透過配置資料庫來連線類名和靜態方法名來呼叫。訊息報告.Verilog和SystemVerilog都提供了一個codice_70方法用於字串顯示的。這對於簡單的測試平臺較為實用，但是試想當驗證平臺十分龐大，所執行的測試也極為複雜時，測試執行過程中會產生海量的字串資訊，驗證人員將花費額外的經歷從中篩選與某個故障相關的資訊。通用驗證方法學以已有的SystemVerilog訊息顯示方法為基礎，建立了一套更加完善的訊息報告機制。工程師不再直接使用SystemVerilog自帶的訊息顯示方法，而是呼叫驗證方法學定義的較高層次的宏來輸出字串。透過在啟動測試時指定codice_71，可以對訊息進行過濾。通用驗證方法學的訊息報告主要是透過呼叫以下幾個宏名稱對應的方法來完成：訊息級別從低到高有：codice_77、codice_73、codice_79、codice_80、codice_81和codice_82。如果呼叫訊息方法時指定的訊息級別低於啟動測試時指定的訊息過濾級別，那麼訊息會被顯示出來，否則會被過濾掉。