隋金雪，張 霞，郁添林，

(1. 山東工商學院電子與信息工程學院，山東 煙臺 264003；2. 北京大學信息技術高等研究院，浙江 杭州 311215)

1 引言

隨著大規(guī)模集成電路技術的發(fā)展，實現(xiàn)復雜多樣的功能，需要更多的知識產權模塊(intellectual Property，IP)加入片上系統(tǒng)(System On Chip，Soc)。Soc總線作為實現(xiàn)IP之間高效通信的重要組件，影響整個片上系統(tǒng)的處理速度。實現(xiàn)IP間高效通信成為SOC性能的關鍵問題。因此驗證設計的功能正確性對整個SOC系統(tǒng)的正常運行具有重要作用。

傳統(tǒng)的驗證方法要求設計者根據(jù)被測設計(Design under test，DUT)的信號接口手動編寫測試向量，并通過檢查相應的DUT來判斷設計功能的正確性。這種類型的驗證方法具有較低的抽象級別。對于復雜的設計，在功能點驗證、不可重用、浪費大量開發(fā)時間等方面存在不足。本文采用通用驗證方法UVM對AXI4總線模塊進行驗證。UVM結合了OVM和VMM兩種驗證方法的優(yōu)點，得到Synopsys、Mentor和Cadence三大廠商的支持，已成為芯片驗證行業(yè)通用的驗證標準。UVM是一個以Systemverilog類庫為主體的驗證平臺開發(fā)框架。通過它的可重用組件，構建一個具有標準化層次結構和接口的功能驗證環(huán)境。UVM驗證方法有效地結合了測試激勵的隨機生成、自檢平臺和隨機化約束，大大提高了驗證的工作效率。

2 AXI總線主要特性

AXI(Advanced eXtensible Interface)是一種面向高性能、高帶寬、低時延的片內總線，分為讀地址、讀數(shù)據(jù)、寫地址、寫數(shù)據(jù)、寫響應5個獨立的信息通道。主要具有以下幾個特點：

1)AXI協(xié)議以突發(fā)模式(burst)傳輸，主機只需給出突發(fā)傳輸首地址，從機可以突發(fā)傳輸寬度自動計算后續(xù)地址。為了防止突發(fā)傳輸訪問兩個從機的邊界和限制從機所需支持的地址自增數(shù)，突發(fā)傳輸不能跨4KB邊界。

2)共享地址多數(shù)據(jù)(Shared-Address Multiple-Data，SAMD)交叉體系結構，具有面向寫入和讀取數(shù)據(jù)通道的并行路徑。AXI IP最多可接16個主器件和從器件。

3)AXI使用基于valid/ready的握手機制數(shù)據(jù)傳輸協(xié)議，傳輸源端使用valid表明地址/控制信號、數(shù)據(jù)是有效的，目的端使用ready表明能接收信息。具有字節(jié)選通機制，可實現(xiàn)非對齊的數(shù)據(jù)傳輸。

AXI4與AXI3的主要區(qū)別在于對burst長度進行了擴展；去掉了WID信號，減小了設計復雜度，降低死鎖的概率；增加了用戶自定義信號。AXI總線滿足高性能內存映射需求，提高了多主多從系統(tǒng)互聯(lián)的性能和利用率。

3 基于UVM的AXI4模塊化驗證平臺

3.1 AXI總線功能模型

AXI BFM(bus function model)用于自定義的RTL設計流程驗證AXI主機和從機的連接性和基本功能。圖1顯示了單個AXI BFM，測試平臺也可以包含多個AXI BFMs實例。DUT和AXI BFMs在包含時鐘和復位發(fā)生器的測試平臺上進行實例化。然后，測試編寫人員將測試平臺實例化到測試模塊中，并使用BFM API層創(chuàng)建一個測試程序。測試程序將使用fork和join順序或并發(fā)地調用API任務。

用AXI BFM建立DUT的內存模型，從如圖2所示的測試結構，將主從bfm直接互聯(lián)。使用從通道級API的的存儲器模型可以創(chuàng)建寫數(shù)據(jù)路徑，先等待寫地址總線上的任何寫地址請求，確保記錄第一個檢測到的有效寫地址握手，并將詳細信息傳回；再獲取與寫地址請求相對應的寫數(shù)據(jù)突發(fā)，捕獲具有指定id標記的整個寫入數(shù)據(jù)突發(fā)；然后從寫數(shù)據(jù)突發(fā)中獲取數(shù)據(jù)并將其放入存儲器陣列；最后確定傳輸是否互斥，并響應發(fā)送回具有與寫入數(shù)據(jù)傳輸相同的ID標簽的從站?；蛘叩却x取地址總線上的任何讀取地址請求，在找到讀取地址通道傳輸后；從存儲陣列中獲取請求的數(shù)據(jù)，并以讀取突發(fā)的形式發(fā)送，實現(xiàn)創(chuàng)建讀取數(shù)據(jù)路徑的存儲器模型。

圖1 單總線功能模型測試平臺

AXI BFM把底層的操作封裝起來，調用這些task或function將其轉化成底層信號的動作，將驗證的抽象層次從底層信號提升到傳輸事物層。同時，AXI BFM能自動從錯誤中恢復，根據(jù)問題的嚴重程度做出停止仿真、打印錯誤報告或警告信息繼續(xù)仿真的決策。AXI總線功能模型作為驗證平臺的獨立模塊，避免了驗證同類型設計的重復開發(fā)。不斷改進的重用總線功能模型，降低重新構建驗證組件帶來的風險，簡化驗證激勵的編寫，提高驗證效率并增強可靠性。

圖2 多測試用例平臺結構

3.2 驗證平臺的組件功能

本文設計的AXI4總線功能驗證平臺如圖3所示。頂層是environment，包含讀寫的request＿scoreboard、response＿scoreboard；master＿agent、slave＿agent；axi＿interface。其中讀寫request＿scoreboard用作記錄讀寫請求是否選擇到正確的slave端，并判斷id、addr、len、size等信號是否一致。讀寫response＿scoreboard是判斷master端獲得的response數(shù)據(jù)流與slave端發(fā)送的一致性。

仿真開始后，運行run＿phase，在master＿agent類中，master＿driver從sequencer得到具體的transaction，判斷讀寫請求方式，并驅動讀或寫的地址通道，當寫請求時還需驅動寫數(shù)據(jù)通道，等待數(shù)據(jù)傳輸完成后，清除通道信號，繼續(xù)等待下一筆數(shù)據(jù)傳輸。

master＿monitor派生自uvm＿monitor，對DUT接口進行實時采樣，捕獲其事務中的數(shù)據(jù)信息，做進一步分析。master＿monitor把讀寫請求方式發(fā)送至scoreboard，并存至相應的隊列。在接收到讀寫響應后，進入隊列檢索id，判斷一個讀寫請求是否完成。

圖3 驗證平臺框架

slave＿agent類中的slave＿driver是根據(jù)讀寫請求方式驅動讀或寫的響應通道，等待數(shù)據(jù)傳輸完成的標志位有效后，表示一次傳輸完成。

slave＿monitor只需要對地址、寫數(shù)據(jù)和讀響應通道信號監(jiān)測，將接收到的讀寫請求方式發(fā)送到request＿scoreboard，并在隊列中檢索id進行信息比對。在數(shù)據(jù)傳輸完成后，把讀響應發(fā)送到response＿scoreboard，在讀響應隊列檢索響應id對應的數(shù)據(jù)流。

當slave＿monitor接收到讀寫請求時，需要response＿handle模塊進行處理。如圖4所示，response＿handle模塊的功能是將slave＿monitor中接收到的request信號，存入空的queue中，同時遍歷整個queue，根據(jù)request＿id、request＿type、request＿len、request＿size等數(shù)據(jù)，隨機生成相應的response信號，經sequencer發(fā)送至slave＿driver的response信號通道。

圖4 response＿handle模塊

為保證驗證平臺與DUT通信，需在最頂層的testbench中例化interface，并指向多個virtual interface，同時將config＿db機制用于UVM驗證平臺間傳遞參數(shù)。將agent類中須例化的driver、monitor和sequencer組件配置active模式，對應DUT接口需要激勵驅動和監(jiān)測的場景，而passive模式對應DUT接口已連接只需要監(jiān)測的場景。

本文搭建的驗證平臺采用層次化設計，將自動化執(zhí)行與調試的多語言腳本文件、rtl級代碼、驗證測試平臺以及編譯仿真產生的輸出文件層級放置，提高驗證平臺的可重用性。

3.3 測試用例

驗證過程中，需要根據(jù)AXI總線的猝發(fā)傳輸、亂序傳輸?shù)忍匦詠碓O計測試用例。針對DUT特性的驗證需求，制定測試點。在測試用例中啟動sequence，向sequencer傳輸transaction，驅動driver，以測試設計是否符合預期。本文的驗證IP設計了多種驗證方案，包括帶約束隨機激勵測試，監(jiān)測AXI4中的len，size，burst，ready、valid等信號，并自動打印信息(uvm＿info)匯總。本文驗證IP設計了對于突發(fā)傳輸類型，讀寫隨機傳輸方式的測試用例。

以FIXED、INCR和WRAP三種突發(fā)傳輸類型，分別對某固定地址進行數(shù)據(jù)更新；數(shù)據(jù)以突發(fā)傳輸基地址為起始，遞增量與突發(fā)傳輸尺寸有關；在初始地址上遞增至最高地址界限，回到初始地址繼續(xù)遞增，循環(huán)往復。

讀寫隨機傳輸方式不同于對所有master port進行遍歷，直接進行n次隨機選擇master port，每次隨機到某個端口后，隨機讀寫n次地址，地址范圍不超過32′h0fffffff。對同一個端口，用不同的突發(fā)傳輸類型交叉，且請求信號必須等上一個請求信號完成后才能觸發(fā)。

對每個sequence都會進行一系列的配置信息，包括打印信息等級、fsdb文件生成、仿真時間和總線仲裁方式，其部分代碼如下：

tags=[′protection′，′dataflow′]，

args=[RANDOM＿SEED＿ARG]，

test＿seq＿name=′+test＿seq＿name=axi＿interconnect＿mixed＿fixed′，

test＿uvmverbosity=′+UVM＿VERBOSITY=UVM＿HIGH′，

test＿dump＿fsdb=′+test＿dump＿fsdb=YES′，

test＿run＿time=′+test＿run＿time=short′，

test＿arbiter＿type=′+test＿arbiter＿type=priority′

用python執(zhí)行相同的隨機數(shù)種子，可重復隨機出現(xiàn)的實驗結果。根據(jù)測試用例不同的需求，可調整以上參數(shù)選項，降低驗證占用的硬件資源，縮短仿真時間。

4 驗證結果與分析

驗證平臺搭建完成后用vcs和verdi進行聯(lián)合仿真驗證，根據(jù)輸出的波形和日志分析工具，參照總線功能模型和dut的一致性，并查看覆蓋率和測試用例的通過率，保證驗證的完備性。

4.1 波形圖分析

由圖中看出，AXI總線工作在burst=0和burst=1的模式下，數(shù)據(jù)從高位開始發(fā)送，數(shù)據(jù)寬度為64位，波形圖可以看出當處于INCR突發(fā)傳輸類型時size=2，且請求信號路由到對應的slave端，接收到正確的請求信號，讀寫響應信號已正確發(fā)回對應的master port，響應狀態(tài)為0。圖中還有握手信號，包括猝發(fā)讀傳輸和寫傳輸?shù)男盘?，當ready和valid信號同時為高電平時，表示握手成功，數(shù)據(jù)有效。

圖5 以INCR讀寫混合為例的各端口波形圖

4.2 覆蓋率分析

圖左側給出從平臺頂層模塊top＿tb對主從讀寫請求以及主從讀寫響應的覆蓋率統(tǒng)計，圖右側是針對具體的覆蓋點和斷言的bins值。通過增加隨機化次數(shù)、添加約束、自定義bins、調整hits次數(shù)分布，由于代碼覆蓋率最終覆蓋率達到100%，滿足驗證需求。

圖6 AXI4總線部分覆蓋率報告

5 結束語

本文基于AXI4總線功能的驗證需求，使用UVM搭建可重用的模塊驗證平臺。該驗證平臺將總線功能模型、測試用例、仿真報告、可執(zhí)行腳本文件及環(huán)境參數(shù)層次化構造，提高測試平臺的可重用性和自動化水平。驗證結果表明，該驗證平臺能夠全面地對AXI4的功能進行驗證，達到了預期效果，縮短了驗證周期，對同類型總線驗證平臺的搭建具有一定的參考價值。