Lite寄存器模型的設計與實現

潘國騰，歐國東，晁張虎，李夢君

（國防科技大學計算機學院，長沙410073）

（?通信作者電子郵箱gtpan@nudt.edu.cn）

0 引言

在摩爾定律驅動下，單顆芯片的邏輯門數增長迅速，更多的功能模塊集成到片上，同時引入更多寄存器，通用片上系統（System-on-Chip，SoC）芯片面臨的情況尤為突出［1］。SoC芯片擁有數量龐大的各類寄存器，寄存器驗證已成為SoC芯片研發過程中的重要驗證項。根據SoC芯片分層驗證理念［2-3］，模塊級的設計規模小、功能簡單、激勵構造相對容易，但模塊數量較多［4］；子系統級的設計規模適中、功能相對獨立、接口清晰，而驗證的完備性卻是最大的挑戰［5］；系統級的設計規模龐大，功能復雜，對仿真資源的需求比較大［6］。無論在模塊級、子系統級或系統級驗證中，寄存器都是驗證的重心之一。如何更高效、更完備地完成芯片的寄存器驗證，成為芯片驗證工程師必須解決的問題。

目前，業界在芯片的寄存器驗證中更多采用C語言或者匯編語言開發測試激勵，芯片寄存器初始化配置過程經過取值、譯碼、執行，然后逐層傳輸到寄存器所在模塊。單個寄存器的配置過程通常需要幾百個時鐘周期，芯片的初始化過程通常需要配置成千上萬個寄存器，配合軟件模擬緩慢的仿真速度，使得整個寄存器配置過程需要很長時間。裸機環境下的寄存器通路測試遇到的問題更加嚴重。寄存器通路驗證通常需要覆蓋整個芯片的所有寄存器，其數量是初始過程需要配置寄存器數量的數倍，急需一種更加高效的驗證方法。

通用驗證方法學（Universal Verification Methodology，UVM）的高可重用性、帶約束的隨機激勵生成、完善的UVM庫以及覆蓋率驅動驗證（Coverage Driven Verification，CDV）理念非常貼合模塊級和子系統級的驗證需求［7-9］，逐漸成為業界的主流。UVM里的RAL（Register Abstraction Layer）方案［10］是一套完整的寄存器驗證解決方案，在模塊級和子系統級的UVM驗證環境中發揮著重要作用，但在系統級驗證中卻極少被使用，原因是UVM庫代碼繁復，仿真運行時消耗內存較大，對驗證的仿真資源有非常高的要求；同時，UVM的RAL方案要求寄存器模型和RTL代碼均符合電子知識產權（IP-XACT）標準［11-12］，UVM內建的寄存器測試用例不對“只讀（Read Only，RO）”“只寫（Write Only，WO）”等屬性的寄存器進行Access檢查，導致UVM寄存器模型在系統級驗證中難以得到推廣。

針對以上問題，本文提出一種Lite寄存器模型，實現更小的運行時內存消耗，可以更廣泛地應用于各種驗證場景。Lite寄存器模型保留UVM寄存器模型前/后門訪問等功能，采用前/后門訪問結合的方法進行寄存器通路驗證，不僅可以提高仿真驗證的速度，同時實現對地址映射的驗證。Lite寄存器模型配合內建測試用例，實現對所有訪問屬性（包括“RO”和“WO”屬性）寄存器的Access檢查，使功能驗證更加高效完備。該模型可以在UVM或非UVM的模塊級、子系統級或系統級仿真驗證環境中使用，并針對系統級寄存器通路驗證進行加強；同時，開發寄存器模型自動生成工具，提供Lite寄存器模型內建測試用例，形成完整的寄存器模型解決方案。

1 Lite寄存器模型

Lite寄存器模型使用SystemVerilog語言實現，支持對多種讀寫屬性的寄存器進行建模，提供各類方法滿足不同的寄存器訪問需求。

1.1 Lite寄存器模型結構

Lite寄存器模型分3層：Field層、Register層、Regmodel層；外加用于寄存器前門訪問的Adaptor，構成寄存器模型的主體。

1）Field層：負責描述寄存器內各域段的基本屬性（期望值、映射值、復位值、讀寫屬性、位寬等），是寄存器模型的最小單元。

2）Register層：負責處理寄存器各Fields遍歷/拼接、寄存器讀寫操作（前門/后門），記錄寄存器的后門訪問路徑、地址等信息，是寄存器模型的基本單元。

3）Regmodel層：寄存器模型的頂層，配置模型包含的各寄存器基地址、頂層后門訪問路徑等屬性，設置寄存器模型的Adaptor，建立集成管理方法，為內建測試激勵提供接口。

4）Adaptor：處理寄存器模型與待測設計（Design Under Test，DUT）之間的接口協議適配，使用SystemVerilog的Callback機制實現靈活重構。

該寄存器模型的主要功能如下：

1）支持寄存器前門訪問和后門訪問：后門訪問通過SystemVerilog提供的直接編程接口（Direct Programming Interface，DPI）［13］接 口 實 現 ；前 門 訪 問 使 用 接 口 適 配 器Adaptor完成事務級與信號級的相互轉換，實現寄存器模型與設計接口的解耦，接口協議變化后只需重新實現Adaptor，已實現的寄存器模型無需改動，增強寄存模型的可重用性。

2）每個寄存器模型包含3個值：復位值、期望值、映射值。復位過程中，有復位值的寄存器，其模型內的期望值被初始化為復位值；期望值是寄存器模型對設計中寄存器值的預期值；映射值是寄存器模型發起同步操作時，從設計中得到的寄存器的真實值。期望值在前、后門寫訪問成功后更新，映射值在前、后門讀訪問成功后更新。讀訪問成功后會觸發模型內部期望值和映射值的比對，檢查寄存器值的變化是否正確。

3）支持READ操作、WRITE操作、讀等待（Wait READ，WREAD）操作和強制寫（Force WRITE，FWRITE）操作四種寄存器訪問操作：READ和WRITE操作分別有前門訪問和后門訪問兩種模式；WREAD操作能夠檢查“WO”類屬性寄存器的前門寫操作是否正確；FWRITE操作能夠檢查“RO”類屬性寄存器的前門讀訪問是否正確。WREAD操作和FWRITE操作僅支持后門訪問。

4）支持對25種讀寫屬性的寄存器建模：只讀、讀寫、讀清零、讀置位、可寫讀復位、可寫讀清零、寫清零、寫置位、寫置位讀清零、寫清零讀置位、寫1清零、寫1置位、寫1反轉、寫0清零、寫0置位、寫0反轉、寫1置位讀清零、寫1清零讀置位、寫0置位讀清零、寫0清零讀置位、只寫、只寫清零、只寫置位、一次寫、一次只寫。

5）該模型不依賴UVM庫（DPI函數庫除外），但可應用于UVM環境和非UVM環境中。

6）內建寄存器通路驗證測試用例，包括寄存器復位值檢查、寄存器讀寫功能檢查和寄存器后門訪問路徑檢查。

圖1 Lite寄存器模型的總體結構Fig.1 Overall structure of Lite register model

1.2 Lite寄存器模型庫單元

UVM寄存器模型底層庫歷經OVM（Open Verification Methodology）、VMM（Verification Methodology Manual）、UVM 的不斷演進，歷史包袱沉重，源碼結構復雜，多有冗余。業界各主要電子設計自動化（Electronics Design Automation，EDA）工具編譯出的Database格式各異，為便于調試均往UVM源碼庫中添加大量代碼，使得UVM源碼庫更加繁雜。Lite寄存器模型重新設計底層源碼庫，結構清晰簡約，有效減少對內存的損耗。

Lite寄存器模型庫由4部分內容組成：

1）宏定義模塊。集中配置模型內部的數據結構，針對具體目標調整，可有效減小運行時內存消耗。

2）接口協議適配器。處理模型與DUT之間事務級與信號級的相互轉換，同時兼具接口協議BFM功能；

3）寄存器模型基類。描述寄存器的各類屬性，建立相關的函數和方法。

4）內建測試激勵。用于寄存器通路驗證。

Lite寄存器模型庫單元完整Package包含如下文件：

packagelite_regmodel；

'include"lite_reg_macros.svh"

'include"dpi/uvm_hdl.svh"

'include"dpi/uvm_svcmd_dpi.svh"

'include"dpi/uvm_regex.svh"

'include"lite_adaptor.sv"

'include"lite_field.sv"

'include"lite_reg.sv"

'include"lite_regmodel.sv"

'include"lite_reset_check_tc.sv"

'include"lite_hdl_path_check_tc.sv"

'include"lite_access_check_tc.sv"

endpackage

庫單元中主要類模塊的層次結構如圖2所示，其中Lite_adaptor為virtual類，Lite_regmodel和Lite_reg中均有其句柄，用戶創建Lite_adaptor的子類后注冊到Lite_reg中（SystemVerilog的callback機制），實現每個Lite_reg與adaptor的連接，打開寄存器的前門訪問通道。

圖2 寄存器模型庫單元類模塊層次結構Fig.2 Hierarchical structure of register model library cell class module

Lite_regmodel類中new函數和build函數為virtual函數，由用戶在子類中實現具體內容。add_reg函數將模型中所有的Lite_reg句柄存入寄存器池內，以便進行遍歷操作。

Lite_reg類中new函數和configure函數為virtual函數，其余函數封裝在類內。hdl_check函數、access_check函數和reset_check函數負責寄存器通路檢查，fwrite函數、wread函數、read函數和write函數處理前/后門讀寫訪問，add_field函數將所有的field存入fields池內。

圖3 Lite_reg類構成Fig.3 Composition of Lite_reg

Lite_adaptor類是virtual類，bus2reg任務和reg2bus任務根據具體接口協議在其子類中實現，wread任務解決了“RO”類寄存器的通路檢查問題。

圖4 Lite_adaptor類構成Fig.4 Composition of Lite_adaptor

Lite_field類中new函數和configure函數為virtual函數，其余函數封裝在類內。被封裝的函數分別負責寄存器field的mirror值和desire值的維護、為通路驗證提供底層支持、前/后門讀寫訪問等。force_wr函數和release_wr函數解決了“WO”類寄存器的通路檢查問題。

1.3 內建測試用例

Lite寄存器模型內建寄存器后門訪問路徑檢查、寄存器復位值檢查和寄存器讀寫功能檢查3個測試用例。內建測試用例使用foreach遍歷Lite_regmodel中的寄存器池進行寄存器復位值檢查和后門訪問路徑檢查，根據讀寫屬性采用不同的方式進行寄存器讀寫功能檢查。

圖5 Lite_field類構成Fig.5 Composition of Lite_field

寄存器讀寫功能檢查測試用例對每個寄存器進行兩種模式的檢查：前門寫+后門讀檢查、后門寫+前門讀檢查。前門寫+后門讀檢查將寄存器模型中的映射值按位取反后從前門寫入DUT，同時更新寄存器模型中的期望值。隨后通過后門讀配合模型中的期望值，檢查前門寫訪問是否正確。后門寫+前門讀檢查采用相反的操作，檢查前門讀訪問是否正確。

UVM源碼庫內建的寄存器讀寫功能檢查測試用例不對寄存器模型中具有“RO”屬性和“WO”屬性的寄存器進行讀寫功能檢查：“RO”屬性寄存器值的變化僅由設計內部邏輯決定，驗證環境對其不可預期；“WO”屬性寄存器在進行前門寫后，寫入的值可能在很短的時間被設計內部邏輯清除，后門讀操作的時機無法控制，但是在子系統級、系統級對這兩類寄存器進行讀寫通路驗證同樣很有必要。

為解決這兩個難題，Lite寄存器模型內建讀寫功能測試用例，處理“RO”屬性寄存器時，調用Lite寄存器模型的fwrite函數，采用force操作完成后門寫，前門讀訪問完成后再release；處理“WO”屬性寄存器時，調用Lite寄存器模型的wread方法，在前門寫訪問完成后逐拍進行后門讀訪問，直到讀出期望的值。在寄存器模型中設置寄存器訪問最大延遲周期，當后門訪問持續拍數大于該最大周期數后報訪問超時錯。

2 自動生成腳本

芯片中的寄存器數量龐大，通過手工編碼實現對所有寄存器的建模耗時長且容易出錯。Lite寄存器模型自動生成工具，可以極大地減少編碼的工作量且避免人為錯誤的引入。

2.1 寄存器描述文檔

寄存器描述文檔作為《詳細設計文檔》的重要組成部分，在整個芯片研發周期中幾乎貫穿始終。

圖6給出工程實踐中寄存器描述文檔的規范格式，表頭包括項目名稱、寄存器所在模塊名、寄存器通路位寬、寄存器最大訪問周期數和文檔版信息。正文描述每個寄存器的詳細屬性。

表頭中的“protocal”決定 adaptor的實現，“hdl_path”與寄存器中每個field的hdl_path拼接構成寄存器的后門訪問路徑。每個寄存器中各field可能擁有不同的讀寫屬性，前門訪問使用寄存器地址，將同一個寄存器內各fields作為整體進行讀寫，后門訪問以field為單位調用DPI接口實現。

2.2 寄存器模型生成腳本

本文使用Python語言［14］編寫寄存器模型生成腳本，從寄存器描述文檔中提取信息，對寄存器進行分層建模。腳本采用模塊化開發方式，主要包括以下模塊：Excel信息掃描模塊、Fields生成模塊、Register生成模塊、Regmodel生成模塊。模塊化開發增加腳本的可擴展性和可重用性，例如寄存器文檔格式變化后只需要修改Excel信息掃描模塊，其他模塊可完全重用。

圖6 寄存器描述文檔規范Fig.6 Register description document specification

不同寄存器建立的模型之間存在大量的“共性”，比如都包含new函數、configure函數、read/write task等；同時不同寄存器之間也存在著明顯的“差異”，如圖6中描述的地址、讀寫屬性、復位值、寄存器名等。因此，腳本使用gen_reg函數生成寄存器模型的“共性”部分，同時提取圖6中的“差異”信息生成“個性”部分，建立完整的寄存器模型。

最后，腳本根據寄存器文檔表頭信息生成寄存器模型的頂層文件，將已完成建模的所有寄存器逐一在頂層文件中例化。

3 實驗結果

首先選取工程實踐中具有代表意義的寄存器，使用硬件描 述 語 言 Verilog［15］做 寄 存 器 傳 輸 級（Register Transaction Level，RTL）編碼，作為實驗的DUT。然后運行寄存器模型生成工具對DUT中實現的寄存器進行Lite寄存器模型建模。最后采用業界主流模擬仿真工具進行仿真，評估寄存器模型的功能和性能。

3.1 自動生成寄存器模型

執行寄存器模型生成腳本，生成test_regmodel.sv文件，test_regmodel.sv中單個寄存器模型：

classclr extends lite_reg；

rand lite_field clr；

function void build（）；

clr=new（"clr"）；

clr.configure（32，0，"WO"，0，'h33333333，1，0，0）；

add_field（clr）；

endfunction

endclass

寄存器模型頂層模塊：

classtest_regmodel extendslite_regmodel；

function new（string name="test_regmodel"，virtual interface

apb_if avif）；

adaptor=new（"adaptor"，20）；

this.avif=avif；

endfunction

rand clr clr；

…

function void build（）；

adaptor.avif=avif；ctl=new（"ctl"）；

ctl.build（）；

ctl.configure（"top_tb.dut.rg_ctl"，'h00）；

ctl.adaptor.push_back（adaptor）；add_reg（ctl）；

…

endfunction

…

endclass

3.2 功能模擬

Lite寄存器模型設計實現底層庫單元，支持前門訪問和后門訪問，寫訪問時更新寄存器模型的值，讀訪問時進行返回值的正確性檢查。該模型兼容UVM模擬仿真環境和非UVM模擬仿真環境。

為驗證Lite寄存器模型讀寫訪問功能是否正確，分別在非UVM模擬環境頂層top_tb的Initial塊和UVM模擬環境的sequence中添加基于Lite寄存器模型的內建測試激勵和自建測試激勵，模擬實際工程項目驗證項對DUT進行寄存器驗證。實驗中分別使用Lite寄存器模型的前門/后門訪問方式結合READ、WRITE、FWRITE和WREAD操作方法，對DUT中寄存器進行訪問。內建測試激勵包括寄存器后門路徑檢查、寄存器復位值檢查和寄存器讀寫功能檢查，內建測試用例；自建測試激勵覆蓋Lite寄存器模型的所有寄存器訪問方式。仿真結果如圖7、8所示。

圖7 仿真運行波形Fig.7 Waveformof simulation

圖8 仿真運行終端打印結果Fig.8 Output result of simulation terminal

//create regmodel

regmodel=new（"regmodel"，apb_if）；

regmodel.build（）；

//createreset valuecheck testcase

reset_check=new（"reset_check"）；

reset_check.rgm=regmodel；

reset_check.start_test（）；

//create hdl path check testcase

hdl_check=new（"hdl_check"）；

hdl_check.rgm=regmodel；

hdl_check.start_test（）；

//createaccesscheck testcase

access_check=new（"access_check"）；

access_check.rgm=regmodel；

access_check.start_test（）；

為驗證Lite寄存器模型對錯誤的檢測功能是否正常，在自建測試激勵中通過force操作注入錯誤。仿真過程中該模型準確檢查出注入的錯誤并打印錯誤報告。

自建測試用例：

//add testcase

regmodel.ctl.read（FRONTDOOR，value）；

regmodel.status.read（FRONTDOOR，value）；

regmodel.clr.read（FRONTDOOR，value）；

regmodel.ctl.write（FRONTDOOR，'h7ffffff5）；

regmodel.status.write（FRONTDOOR，'hffff0000）；

regmodel.clr.write（FRONTDOOR，'hcccccccc）；

regmodel.clr.wread（'hcccccccc）；

//inject error force dut.rg_ctl.lock=1'b1；

regmodel.ctl.read（BACKDOOR，value）；

regmodel.status.read（BACKDOOR，value）；

regmodel.clr.read（BACKDOOR，value）；

releasedut.rg_ctl.lock；

@（posedgeclk）；

regmodel.ctl.write（BACKDOOR，'h7ffffff5）；

regmodel.status.write（BACKDOOR，'hffff0000）；

regmodel.clr.write（FRONTDOOR，'h33333333）；

regmodel.status.fwrite（'h55555555）；

regmodel.ctl.read（FRONTDOOR，value）；

regmodel.status.read（FRONTDOOR，value）；

regmodel.clr.read（FRONTDOOR，value）；

仿真結果證明，Lite寄存器模型通過前門/后門對寄存器發起READ、WRITE、FWRITE和WREAD操作，能夠進行數據正確性比對，實現預期功能；Lite寄存器模型的內建測試用例能夠對包括“RO”屬性和“WO”屬性等特殊寄存器在內的所有寄存器進行寄存器通路驗證，解決了UVM寄存器模型在此方面的問題。

3.3 性能分析

為分析Lite寄存器模型仿真時對內存的消耗，實驗中分別使用Lite寄存器模型和UVM寄存器模型對同一個DUT做寄存器建模，如圖9所示。在仿真過程中加入-memxprof選項（仿真工具中收集仿真性能的選項）收集內存消耗，得到結果如圖9所示。

圖9 模型內存消耗分析報告Fig.9 Analysisreport of model memory consumption

通過分析報告可知，得益于精簡的底層庫實現及配置化處理，Lite寄存器模型的運行時內存消耗是UVM寄存器模型運行時內存消耗的21.65%，極大地減小了仿真所需的內存資源消耗，在實際工程應用，尤其在系統級寄存器通路驗證中意義較大。

4 結語

本文針對實際工程應用中UVM寄存器模型的不足，設計實現Lite寄存器模型，并配套開發內建測試激勵和Lite寄存器模型自動生成工具。實驗結果表明，Lite寄存器模型能夠替代UVM寄存器模型完成寄存器驗證，且對運行時內存的消耗更??；同時，可兼容UVM和非UVM的模擬驗證環境，配合自動生成工具和內建測試用例形成完整的集成電路寄存器驗證方案，在實際工程項目中發揮重要作用。