論開發model對設計dut的重要性
最近在設計乙個模組。
時間緊，任務重。一開始，覺得為了節約時間，沒有先開發model，直接去寫dut。
整個模組分成三部分。
在分別完成三個部分時，由於並不十分複雜，故都是手算的計算結果，然後驗證dut的功能。
但是在三個模組一起聯合除錯時，由於前期理解不充分，設計需要修改，然後計算結果就變了，造成之前手算的結果報廢。
如果重新手算，就增加了不少的工作量，而且，感覺這都是重複低效的工作量。
怎麼辦？
決定給各個模組新增c語言寫的model。
優點：一勞永逸，類似uvm那樣，直接去比較model與dut的輸出，不用每次都要人工去計算比對。
缺點：需要暫停除錯dut，改而研究如何開發乙個model，並自動對比，之前完全沒有做過類似工作，不知道需要花多少時間，能否成功，心中沒底。
為了一勞永逸，決定還是幹！
下面是實現的主要模組。
主要分兩步：
首先用c語言寫乙個model，能夠正確執行dut需要的功能。這個的開發比較快，因為採用的高階語言，有許多的庫函式可以用，而且高階語言比較靈活，自由度大，開發速度快。這個都還比較快。
接下來才是難點。
如何將c語言寫的model與sv寫的dut聯合起來，進行結果的check？
對比dut與model的結果，單獨寫乙個module來完成check功能。
module check(
// module的輸入訊號來自dut
input clk,
input resetn,
input start,
input valid,
input[15:0] result
);... ...
import "dpi-c" context task c_model(output bit[15:0] ref_data[10000]);//引入model，從介面上得到參考結果
bit[15:0] ref_data[10000];//宣告乙個足夠大的陣列訊號來存放來自model的參考結果
logic[31:0] cnt;
... ...
// 假設start訊號是dut開始計算的訊號，而valid訊號是dut輸出有效的訊號，因為dut需要一定週期去計算出結果，所以start訊號必定比valid訊號早很多個週期到達。
// 這裡為了簡單，假設start的訊號只是乙個週期有效
// 當start有效時，就從model計算得到參考結果
always @(posedge start) begin
ref_data(ref_data);//從model得到參考結果，一般model計算都很快，當作乙個週期就計算完成就行了
end// 下面是去檢測valid訊號，當valid有效，就去對比dut結果與參考結果的值
always@(negedge clk or negedge resetn)begin
if(!resetn) begin
cnt <= #1 0;
endelse begin
if(valid) begin
if(result != ref_data[cnt]) begin
$dispaly("%t, error cnt = %d, dut = %x, ref_data = %x", realtime, cnt, result, ref_data[cnt]);
endcnt <= #1 cnt + 1;
endend
endendmodule
思路：從dut得到開始訊號和結果訊號，然後在dut的輸出有效時，就去比較dut與model的結果，如果不一致，就列印出來。
注意：必須在dut的結果到來前就計算完model。model的計算非常快，可以當作不花時間。
為了保持結果的一致性，最好是model和dut讀取相同的輸入檔案獲取輸入資料，避免因為輸入資料的不同造成的錯誤。
上面用到了model。
可以看到，dut的輸出是一串資料，可以看作是陣列一樣。
model將計算結果通過函式介面傳遞出來。
#include 「svdpi.h」 // 必須要引用這個標頭檔案，代表sv與c語言之間的交換介面
... ...
// 這是model的頂層
int c_model( int* ref_data)//介面上的輸出變數；
//注意，這是指向陣列的指標，而且，資料必須是32位的；
//如果是16位的，那麼在dut中就只有偶數字址的資料，奇數字址的資料就找不到，資料的個數也跟著減半。
//具體原因暫時沒有找到，猜測c語言的資料在記憶體中的儲存最小單位是word吧，猜測的，不確定。
好用！
磨刀不誤砍柴工
這是一句廣為流傳的俗語，表面意思就是磨刀並不會耽誤砍柴的時間，在軟體開發過程中，似乎也有同樣的情況出現。有的時候，專案為了趕進度，需要快速實現，於是我們就馬不停蹄的加班加點的去寫 了，其他周邊的功夫能少耽誤就少耽誤，但是是不是除了寫 其他什麼事情都可以省呢，舉自己切身遇到的2個例子。案例一 在實現過...
磨刀不誤砍柴工
再次驗證了磨刀不誤砍柴工，這次高體大作業，花了我乙個多星期，結果呢，卻是還是有問題，回過頭來再看書上分析，又懂了一點。歸根結底，是沒有做好準備工作，總覺得應該盡快編 這樣才能早點結束。學了物件導向分析與設計，發現這個確實很有用，而且了解到，在軟體開發中，寫 只是其中很小的一部分，前面還有很多準備工作...
磨刀不誤砍柴工
我的部門裡面有erp顧問，也有你們經常說的網管。顧問負責erp管理軟體的維護與管理，網管負責硬體與網路的管理。我發現管理軟體的顧問經常是辦公室裡上網找資源學習，而網管們則 不斷，不是這個部門來 說，電腦無法啟動，就是列印不了，或者是中毒了什麼。為什麼有這個差異呢？我發現了這麼乙個問題，管理軟體的顧問...