劉森態(tài)，龐宇，魏 東

（重慶郵電大學 光電工程學院，重慶 400065）

0 引言

基于TestBench 的傳統(tǒng)芯片驗證方法，對人員的驗證經(jīng)驗要求高，且平臺可移植性差，難達到預期覆蓋率，不適于快速迭代芯片設計市場[1]。目前，UVM 已是IC 驗證領域主流的方式，它由SystemVerilog 語言編寫，具有面向對象（Object Oriented Programming，OOP）的特點，擁有豐富的組件和基類，完善的通信機制，繼承并克服開源驗證方法（Open Verifcation Methodology，OVM）沒有寄存器的解決方案，可以根據(jù)驗證需求，快速地搭建工程[2-3]。

串行外設接口SPI（Serial Peripheral Interface） 是由Motorola 公司定義一種單主機多從機全雙工的模式通信，協(xié)議標準下由主入從出數(shù)據(jù)線（Master Input Slave Output，MISO）、主出從輸入數(shù)據(jù)線（Master Output Slave Input，MOSI）、串行時鐘信號線（Serial Clock，SCK）和從機選擇信號線（Slave Select，SS）共4 種引腳組成。該接口可與模數(shù)轉換器DAC、數(shù)模轉換器DAC 和外部存儲器等芯片通信，是SoC（System on Chip）最主要的外設接口之一。

Wishbone 總線是由Silicore 提出的，現(xiàn)由OpenCore 組織維護管理，是SoC 三大總線標準之一[4]。Wishbone 總線是一種IP 核（Intellectual Property Core）互聯(lián)體系結構，它定義IP 核之間公共接口，減輕系統(tǒng)組件集成難度，提高系統(tǒng)組件可重用性、可靠性和可移植性，兼容所有綜合工具，可用多種硬件描述語言實現(xiàn)[5]。Wishbone 總線為IP 核提供點到點、數(shù)據(jù)流、共享總線和交叉開關這四種互聯(lián)方式滿足不同模塊的通信需求。

本文驗證的模塊是由Wishbone-SPI 搭建的一個子系統(tǒng)，并著重闡述模塊設計、驗證環(huán)境搭建、寄存器模型生成、驗證流程、激勵用例開發(fā)以及功能覆蓋率統(tǒng)計，最終對仿真結果進行統(tǒng)計和分析。

1 Wishbone-SPI 模塊設計

SPI 作為MCU 芯片重要外設，在芯片內完成串行數(shù)據(jù)流轉換與并行數(shù)據(jù)流的轉換[6]。該模塊有多種傳輸模式，其最大輸出時鐘為系統(tǒng)輸入時鐘的一半。不同SPI模塊的最大時鐘需求不同，需要用時鐘控制模塊來調節(jié)通信頻率。

1.1 Wishbone 總線接口

Wishbone 總線信號接口分為公共信號、數(shù)據(jù)信號和總線周期信號。

公共信號包括復位信號rst 和時鐘信號clk，它們對于主設備和從設備都是公共的。

總線控制信號有錯誤信號err，重試信號rty，響應信號ack，讀寫使能信號we，中斷請求信號int，選通信號stb，總線周期信號cyc，位寬信號sel。

數(shù)據(jù)信號包括地址信號addr，數(shù)據(jù)發(fā)送信號dat_o，數(shù)據(jù)接收信號dat_i。

Wishbone 支持多種單周期讀/寫，塊讀、讀修改寫。以單周期寫為例，如圖1 所示，在clk 上升沿a 時刻，主設備設置位寬sel 信號將地址信號addr 和待寫入數(shù)據(jù)dat發(fā)送到總線上，拉高we，同時將cyc 和stb 置高，開始一次總線的寫操作。在時鐘上升沿a 到達前，從機設備檢測到主設備的寫操作，鎖存總線上的數(shù)據(jù)，同時拉高ack作為對主設備的響應。從設備可以在ack 有效之間插入任意周期的等待狀態(tài)。在clk 上升沿b 時刻，主設備發(fā)現(xiàn)ack 為高，將stb 和cyc 置低表示操作完成。從設備發(fā)現(xiàn)stb 為低后將主設備ack 也置低。一次Wishbone 寫操作便完成。

圖1 Wishbone 單次寫操作

1.2 SPI 模塊

考慮到SPI 協(xié)議接口信號具有不同通信模式的特點，SPI 模塊設計采用基于狀態(tài)機的方法，SPI 模塊基本設計框架如圖2 所示?？刂萍拇嫫魇荢PI 模塊的核心，用于控制SPI 通信方式，主要監(jiān)視Wishbone 總線上的讀寫命令，根據(jù)讀寫命令調用控制狀態(tài)機，進而控制數(shù)據(jù)的發(fā)送與接收。分頻器寄存器將模塊的輸入時鐘分頻后用于時鐘產(chǎn)生輸出SCK，從而靈活地選擇外設頻率。狀態(tài)寄存器反映模塊內的運行狀態(tài)，如發(fā)送完成標志，讀寫完成標志。數(shù)據(jù)寄存器存放待發(fā)送到芯片或接收來自于外部模塊的數(shù)據(jù)。循環(huán)冗余校驗（Cyclic Redundancy Check，CRC）校驗器判斷傳輸數(shù)據(jù)是否正確，當發(fā)送數(shù)據(jù)時將產(chǎn)生CRC 校驗碼并附加到數(shù)據(jù)后面，接收數(shù)據(jù)時則自動計算CRC 校驗碼并與總線數(shù)據(jù)上的校驗碼進行比較得出結果并反映到狀態(tài)寄存器中。

圖2 Wishbone-SPI 框圖

2 UVM 驗證平臺

2.1 主要通用驗證組件

基本的UVM 平臺包括以下部分：Test 是最頂層的類，首要負責驗證平臺的配置，創(chuàng)建下一級別的驗證組件，可以用來啟動Sequence 開始仿真。Environment 是一個容器，包含較高級別驗證組件，包括Agent、Scoreboard、Config以便更高層次的復用。Agent 是一個將Driver、Monitor、Sequencer 三個組件進行封裝的容器組件，方便相同功能的組件多次例化和復用。Driver 是將sequence 中的數(shù)據(jù)包發(fā)送到DUT 引腳上的組件，會根據(jù)特定的協(xié)議轉化為時序激勵。Monitor 用來觀察接口上的數(shù)據(jù)或信號，可以通過事務極傳輸模型（Transaction-Level Modeling，TLM）將信號發(fā)送到其他組件上。Sequencer 管理不同類型的Sequence，并帶有仲裁的功能。Sequence 定義了需要發(fā)送或接收驅動器Driver 的數(shù)據(jù)類型，需要掛載到相應的Sequencer，是驗證平臺中流動的血液。Scoreboard 接收來自Monitor 的數(shù)據(jù)值并且與期望值進行比較。接口Interface包含了連接、同步和兩個或者多個模塊之間的通信。

如圖3 所示，本次設計中驗證環(huán)境Wishbone2spi_env中包含Scoreboard、Coverage、Predictor、Agent 和Transaction。Agent 內Driver、Monitor 和Sequencer 通過TLM 通信。在Sequencer 幫助下，頂層仿真序列Sequence 產(chǎn)生的數(shù)據(jù)類型送給Driver?？偩€上的讀寫操作激勵將廣播到Predictor上。Predictor 根據(jù)DUT 配置和Wishbone 總線上的輸入來傳輸SPI 的激勵。Predictor 輸出發(fā)送到Scoreboard上，并與DUT 的輸出結果進行比對。Coverage 記錄SPI 操作的功能覆蓋率。Virtual_sequencer 控制不同的Sequencer，起統(tǒng)一調度的作用[7]。平臺中有3 個Sequencer，一個是寄存器模型的數(shù)據(jù)傳輸，一個是控制Wishbone 到SPI 的數(shù)據(jù)，還有一個則是控制SPI 到Wishbone 的數(shù)據(jù)產(chǎn)生。

圖3 SPI 驗證環(huán)境

通常DUT 的接口數(shù)量不定，為滿足芯片驗證需求，加快驗證的準備速度，通常相同功能驗證組件封裝在Agent 容器內。如圖4 所示，通過在Env 組件內的config配置不同Agent 的config 屬性，實現(xiàn)驗證環(huán)境集成多路接口驅動，并同時使用，滿足驗證的不同需求。

圖4 多驅動驗證平臺

2.2 RAL 模型

寄存器抽象層（Register Abstraction Layer，RAL）是一種中心化管理寄存器配置的模型[8]，其核心思想是把需要驗證的所有寄存器封裝在一個統(tǒng)一模型內，通過映射完成對寄存器的驗證工作。RAL 模型一般包括不同寄存器的地址和不同位寬的功能段域，其中段域是控制模塊功能的最小單位，多個段域組成一個功能寄存器。使用RAL 模型一般使用腳本語言進行管理，可以在大規(guī)模芯片設計中減少手動檢查寄存器的時間，避免寄存器配置錯誤，實現(xiàn)平臺復用性。

UVM 中對寄存器的訪問方式包括前門訪問和后門訪問。前門訪問是在總線上模擬時序，進而在寄存器模型上進行讀寫操作，是真實的物理操作。而后門訪問是利用UVM 中的內置方法，將寄存器的操作直接作用到DUT 內的寄存器變量，比起前門訪問速度更快，段域值修改更便捷。前門訪問方式使用轉換器（adapter）類來充當不同抽象層轉化媒介。該類將寄存器激勵信息轉化后發(fā)送到總線上，最后由總線上的driver 完成轉化?？刂萍拇嫫鹘Y構如表1 所示。

表1 控制寄存器

RES（Reserved）域為功能保留，只能讀；BIDIMODE（Bidirectional data mode enable）為雙向通信方向，寫1 時表示雙向傳輸，為0 時是單向傳輸。BIDIOE（Output enable in bidirectional mode）域用于雙向通信模式下的傳輸方向；CRCNEXT（CRC transfer next）表示下一次傳輸為CRC。CRCEN（Hardware CRC calculation enable）開啟硬件CRC。MSTR（Master selection）為主、從模式選擇。IE（Interrupt enable）域表示中斷使能；LSB（Least Significant Bit）域表示最低有效位收/發(fā)比特位置順序；SPE（SPI Enable）域表示SPI 使能。CPOL 與CPHA 組合控制著SPI 傳輸?shù)乃姆N模式。下面以SPI 的控制寄存器SPCR 為例，驗證平臺的寄存器縮略代碼如圖5 所示。

圖5 控制寄存器驗證代碼

依據(jù)模塊功能手冊，寄存器每個域配置主要包括位域所屬的寄存器、段域的位寬大小、該段域最低位在寄存器中的位置、訪問方式、段域是否易變、復位后的默認值、能否復位以及能否單獨訪問。其中訪問方式主要指讀 寫RW（Read Write）、只 讀RO（Read Only）、只 寫WO（Write Only）等。

本次設計包含了12 個SPI 寄存器，如表2 所示，除了控制寄存器，還有狀態(tài)寄存器和數(shù)據(jù)寄存器等。每個寄存器位寬均是32位，偏移地址依次以4 遞增。發(fā)送數(shù)據(jù)寄存器和接收數(shù)據(jù)寄存器共享地址，通過控制寄存器中的讀寫標志區(qū)分。在傳輸啟動前，寫數(shù)據(jù)寄存器，則發(fā)送數(shù)據(jù)；在完成傳輸后接收MISO 上的數(shù)據(jù)，讀數(shù)據(jù)寄存器。Wishbone 總線上以前門訪問的方式來配置SPI 的功能。通過后門訪問方式讀取寄存器里的值，最后比較寫入值和期望值是否一致。

表2 SPI 寄存器堆

寄存器模型驗證流程如圖6 所示，首先寄存器序列spi_reg_sequence 攜帶寄存器信息放到uvm_reg_item 實例中，并送到adapter。然后adapter 抽取出信息，生成總線所需的Wishbone_seq_item 類型，通過總線上Agent 實例發(fā)送到DUT內，完成寄存器的配置。

圖6 寄存器模型驗證

2.3 平臺測試用例

為了對SPI 特性全面測試，編寫如測試用例。測試用例列表及父子類關系如表3 所示。1 號測試用例是為了測試Wishbone 是否按照總線協(xié)議進行讀寫。2 號測試用例繼承于1 號測試用例，它對總線地址進行約束，限定訪問地址在SPI 寄存器地址范圍內，且檢測寄存器的讀寫方式，如狀態(tài)寄存器只能讀不能寫。3～7 號測試用例均繼承于2號，其中3 號是測試SPI 開啟和關閉的激勵，是發(fā)送或接收SPI 數(shù)據(jù)的基礎。4 號用來測試通信故障，如數(shù)據(jù)溢出、CRC 錯誤。5 號檢測NSS 信號片選引腳在主機模式下是否拉低指定的從機設備引腳。6 號測試用例檢測復位時SPI 各個寄存器是否是設定值。7 號關注SPI 在不同傳輸模式下MISO 和MOSI 引腳的時序是否與協(xié)議一致。

表3 測試用例列表及父子類關系

2.4 功能覆蓋率組

設計自動統(tǒng)計功能覆蓋率的模型來評估驗證結果是否滿足預期要求，通過覆蓋組實現(xiàn)覆蓋率的統(tǒng)計模型，如表4 包含驗證平臺不同覆蓋組，以著重驗證SPI 各個基本功能。

表4 SPI 測試覆蓋組和描述

3 功能覆蓋率統(tǒng)計及分析

使用Questasim 工具運行驗證平臺，激活測試用例，實例Wishbone 和SPI 接口并對接口信號分別進行采集。運行時，先通過受約束的隨機測試，然后對未覆蓋的地方進行定向測試，遍歷訪問空間，使功能覆蓋率達到100%。圖7 顯示了DUT 的功能覆蓋率結果，每一個覆蓋組的Coverage=100.0%，這說明驗證中每一種情況都已經(jīng)覆蓋，平臺已達到驗證目標。

圖7 功能覆蓋率仿真結果

4 結論

本平臺支持Wishbone-SPI 驗證，使用UVM 減少驗證平臺搭建時間，且功能覆蓋率達到100%，編寫高效率的測試用例配合腳本工具實現(xiàn)可移植復用的激勵。實際項目中，可依據(jù)項目實際情況改變接口代碼或配置代碼，而復用的代碼結構對于其他驗證工作起著積極的作用。后期在該驗證平臺上可以加上處理器外殼[9]，運行C 的測試用例[10]，做出訪問寄存器、處理中斷等行為，還可進一步實現(xiàn)驗證平臺的垂直復用，能大大縮短SoC 開發(fā)時間。