2017年1月8日 星期日

SystemVerilog 裡的 UVM 驗證之概念以及 Cocotb (二)


前一篇文章中說明了用 trace-based simulation 會出現的問題
本篇會說明是怎麼從 trace-based simulation 變成 UVM 的
以及說明 UVM 的核心的想法

從前面的 trace-based 的驗證轉換到 UVM
我個人的理解是多了這兩種變化

  • Scoreboard 的概念
  • 資料是程式產生的結果
下面這張圖片是從 verificationacademy.com 取出來的
搜尋 SystemVerilog UVM 的前幾張圖片就有了
「systemverilog uvm」的圖片搜尋結果

比較一下上一篇中的模擬方式(如下圖)
可以看到其實蠻像的
最大的不一樣的地方是 scoreboard 的出現
本來 monitor 也負責檢查的部份
現在則交由 scoreboard 分離出來處理
Scoreboard 維持兩個 queue 的結構
一個 queue 是 monitor 真的觀察到的結果
另外一個是根據前一級觀察到的結果預期會有什麼
像下面這樣
假設第一級 monitor 看到一次 1 的傳輸
應該就會預期第二級會看到兩個 1
於是就會把兩個 1 塞到 scoreboard expected 的 queue 裡面
第二級 monitor 看到傳輸之後就會丟到 monitored queue 作比較
而如果有第三級的話,第二級 monitor 也會把預期的結果塞到第三級
有點像 callback 的想法,就是說 monitor 看到一筆資料可以
  • 塞到 scoreboard 的 monitored queue 裡面(必要)
  • 預期下一個(或多個) scoreboard 的會拿到什麼
當然也可依照心情加入其他的 callback,像是把值印出來之類的

這樣一來
只要自己寫完 Verilog 以及其他語言接口的部份
這樣就可以重用高階語言寫好的 model 了
例如下面的圖(從上篇拿來的例子)
我們觀察到的 Verilog 的 1'b1
把他轉為 Python 的 integer 之後丟給 Level2(1)
得到 [1,1] 之後轉回 Verilog 的兩個 1'b1 塞回 queue 裡面

聽起來有點麻煩
然而寫接口其實不是額外的負擔
因為本來 trace-based 的模擬下也是要把資料轉存成硬碟的檔案的
不管 trace-based 或是 UVM 的想法中
這件事情都躲不掉

--

回顧一下,透過 UVM 可以解決上一篇說的問題嗎?

  1. trace file 很大,或是難以收集真實系統的資料
  2. 效率考量上,不希望在每個層級都做那麼多的驗證

第一個問題因為我們的資料是動態檢查、產生的
所以只會用到記憶體的空間
甚至可以把模擬器假裝是真的硬體,跟實際的系統互動
第二個問題,因為我們可以 programmable 的產生資料
所以可以只產生一點點資料就結束模擬了
兩個問題都解決了

--

下一篇會說明 Cocotb 作為要如何用 Python 達到類似的功能
UVM 仍然是以 Verilog 為主體執行
需要高階語言的時候可以透過外部呼叫像是 VPI, DPI 等等
Cocotb 的則是以 Python 為主體
把 Verilog simulator 像是 ncsim, vcs 當作 slave 在呼叫
包裝了不同軟體 (vcs, ncsim...) 以及語言 (Verilog, VHDL)
細節我也不懂就是了

雖然 Cocotb 文件並不是太完整
也沒作到 100% 語法上的支援
作為商用應該還是略嫌不足
不我認為用來驗證已經數人規模的模組已經足夠了

沒有留言:

張貼留言