一、前言

近期疫情嚴重，身為社畜的我只能在家中繼續鉆研技術了。之前寫過一篇關于搭建FIFO驗證平臺的博文，利用SV的OOP特性對FIFO進行初步驗證，但有很多不足之處，比如結構不夠規范、驗證組件類不獨立于DUT等問題。此次嘗試驗證更復雜的IP，并利用SV的更多高級特性來搭建層次化驗證平臺。

二、APB_I2C IP概述

實踐出真知，于是在opencores網站上下載了個APB_I2C的IP核，便著手展開驗證工作。第一步是理清楚這個IP的整體功能、引腳作用以及頂層結構。整體功能從模塊名稱便可得知是帶有APB總線接口的I2C_master。要了解引腳作用與時序，直接截取SPEC上的示意圖查看：

APB_WRITE:

APB_READ:

I2C_PROTOCOL:

接口和協議這里就不細說了，感興趣的朋友查找相關的資料。至于頂層結構這方面，最好還是交給工具方便點。無奈回家沒有帶回我的虛擬機硬盤，只能下載個WINDOW版本的EDA工具了。本文使用QuestaSim，原理圖如下：

很容易看出該模塊頂層包含APB接口模塊APB、分別用于緩存發送和接收數據的FIFO_TX和FIFO_RX，以及I2C協議轉換模塊I2X_INTERNAL_RX_TX。master通過APB總線訪問該IP核內部的數據緩存區和配置寄存器，無需關注內部實現。

除了這幾個方面，配置寄存器的訪問也非常重要。IP核必須做出正確的配置和使能才可以按照需要正常工作。配置寄存器見下表：

三、QuestaSim常用指令

QuestaSim工具的WINDOWS/LINUX版本很容易下載到，和Modelsim的主要區別是對SV UVM的支持性較好，這一點非常符合本文的意愿。但仿真過程中一次次點擊鼠標很麻煩，只好學習學習操作命令了，寫個腳本配合SV實現自動化仿真。以下是在官方文檔user manual和tutorial中截取的常用指令及解釋。

1 Compile the source files. vloggates.v and2.v cache.v memory.v proc.v set.v top.v

2 Use thevoptcommand to optimize the design with full visibility into all design units

vopt +acc -o -debugdb

The+accargument enables full visibility into the design for debugging purposes. The-oargument is required for naming the optimized design object. The-debugdbargument collects combinatorial and sequential logic data into the work library.

3 Use the optimized design name to load the design with thevsimcommand: vsim testcounter_opt -debugdb

4set WildcardFilter "Variable Constant Generic Parameter SpecParam Memory Assertion Endpoint ImmediateAssert" With this command, youremove “CellInternal”from the default list of Wildcard filters. This allows all signals in cells to be logged by the simulator so they will be visible in the debug environment.

5Add Wave*

6add log /*

This will provide the historic values of the events of interest plus its drivers

7 run 500

四、搭建驗證環境

這一節是本文的核心內容了。通用的驗證環境的結構和組件如圖：

Stimulus將測試激勵送入待測試模塊DUT，Monitor觀察響應并發送給檢Checker。遇到復雜的設計還需要設計Reference model，進而對比實際響應與黃金參考的響應區別。并且當Monitor無法簡單直接地收集DUT響應時，還需要設計VIP來解析復雜的響應信號時序。這幾天參照工具書和網上的教程視頻，根據APB_I2C模塊的特性構思出基本的驗證環境。

APB_I2C模塊并不復雜，所以沒必要設計reference model。若想利用Monitor組件獲取DUT響應需要解析I2C協議時序，這里編寫個VIP來幫助它解析出有效數據，進而與Stimulus數據對比。Monitor因VIP的存在得到了很大程度上的簡化，主要的功能為將等待觸發事件發生后，將數據通過MAILBOX傳輸給Checker進行比較。

另外，為了讓Stimulus脫離具體接口信號操作，建立Generator和Initiator類分別用于產生讀寫訪問和將讀寫訪問轉換成讀寫操作對應的具體信號邏輯。為了實現OOP特性中的“細節隱藏”，建立配置類Config來配置驗證環境，這里主要是配置Generator發送特定場景的讀寫請求。想要測試不同的功能特性，只需改動傳入Config的參數即可。到此驗證環境包含了Generator Initiator Monitor Checker Config五個驗證組件，這里再建立Environment類將這些組件包在一起，方便調用方法。還是上圖更直觀些（有點丑，湊活看吧）

除了驗證環境結構，好的代碼結構也能極大提高平臺的重用性。這里將所有類及對應的屬性方法封裝到Package components中，方便被import到testbench中。驗證過程中用到的所有變量類型、參數放置在defines.sv中。

五、仿真分析

當Config類對象的配置參數為CONFIG_WR_DATA時，generator發起寫請求。波形如下：

觀察打印的Log可以看出每個SCL時鐘周期采集到一個bit，MAILBOX正確傳輸，checker對比正確，故而仿真PASS。

驗證過程中發現該模塊有很多BUG！！這里舉兩個例子。

1 SDA為雙向端口，但當sda_enable為0時，并沒有賦值為高阻態，即釋放信號線控制權給slave。做出如下修改并讓VIP在ACK階段拉低SDA。

2 SCL在讀操作狀態機中沒有被toggle，因此config的配置參數為CONFIG_RD_DATA時SCL沒有翻轉。在讀操作狀態機中添加翻轉邏輯，使BR_CLK_RX_O信號在counter_receive_data == clk_t_1_4時拉高，counter_receive_data==clk_t_3_4時拉低。

波形顯示在讀操作時SCL正常翻轉。

該模塊的讀操作很多地方不正確還有待修改，就不一一贅述了。總的來說就是根本不能用o(╥﹏╥)o 不抱希望了，之后我還是自己寫一個吧。

六、總結

本文利用APB_I2C模塊為例搭建了層次化驗證平臺，但還有待改善。這里列出幾點：

1 沒有完全做到測試用例與環境分離

2 沒有構建場景層給予豐富的pattern