EETOP 論壇驗證分論壇網友 似水如煙 提問：

驗證人員應該以何種角度閱讀spec

在開發流程中，設計和驗證人員關注的點肯定是不一樣的，尤其在spec的理解上，驗證人員往往需要有自己獨立的理解。在拿到spec時，作為驗證人員，應該如何提煉其中的功能從而轉化為對應的inference model以實現和詳細設計的交叉驗證。大家有什么經驗能討論一下。

以下是網友解答：

jimbo1006：

我覺得驗證人員看spec中的功能點的時候，需要關注輸入，輸出以及從輸入到輸出所需要的時間。首先，“從輸入到輸出所需要的時間”，也就是RTL內部的延遲，我覺得這是設計reference model的最大的難點。因為你即使問寫spec的人，他也很有可能不知道。這個時候我們會去問設計人員或者看RTL代碼，但是這樣我們就很有可能被設計人員的思路影響，搭出來的ref model就有可能和RTL一起錯了，這樣你的驗證環境有可能永遠也查不到那個BUG。然后就是從輸入到輸出，這就好比一個真值表，我們需要做的就是按照隨機策略設計并約束激勵。但是隨著邏輯的復雜度的增加，這個真值表會越來越大，大到我們很難寫全。這個時候我們可以像設計一個很大的模塊一樣，把這個大的真值表分成若干小的真值表。說起來簡單，但是這里的工作量是隨著邏輯復雜度指數上升的。如果要做所謂的交叉驗證的話，不如再找一個設計人員，也設計這樣一個模塊，然后他們比一比結果，再磨合一下延遲，根本不需要驗證人員。最后再說下題外話，我在大學做設計的時候，是先設計reference model（用C++寫好，用軟件跑一下看看效果），然后再根據這個reference model去設計模塊，最后設計完模塊上FPGA跑一跑就結束了。這里如果加上驗證一步驟的話，就可以直接拿這個reference model去驗證了。所以我覺得應該是先有reference model, 再有需要被驗證的RTL，這才是最合理的流程。但是我在實際工作的時候，是先有RTL再有ref model, 樓主所在公司應該也是這樣，不然也不會問這個問題。我們分析一下，ref model雖然是根據spec寫的，但是卻要獲取RTL的內部延遲，然后我們再用這個部分邏輯來源于RTL的ref model 去驗證RTL。這里面稍有不慎，就會放過BUG, 因為一般情況下我們的scoreboard里面的auto_check是直接拿ref model的輸出用的，不會去驗它內部的邏輯的。

zxm92：

1.題主對于reference model的過度關注，側面反映了題主更多還是站在設計者的角度來做驗證，一開始我也執迷于reference model，自動對比給初做驗證的人很大的快感。2.樓上說的輸入到輸出的時間的驗證，我認為reference model更側重于數據流的對比，時序上面的checker可以使用assertion。個人認為設計人員和驗證人員看spec的角度是不同的：1.設計人員通常是站在功能實現的角度，而驗證人員應該更多站在使用者的角度，也就是說如何使用做出來的芯片2.如何使用芯片，決定了你的激勵，你的激勵決定了芯片所面臨的狀況，芯片在所有可能的狀況下都能保持正確，那這個芯片的quality就得到了保證，所以如何設計你的激勵是驗證的核心。

jimbo1006 回復zxm92:

我工作時間也不長，我現在對reference model也特別迷茫，感覺上如果寫了這個就把一部分邏輯交給ref model判斷去了，如果這部分邏輯和DUT錯成一樣可能會造成很糟糕的情況。 reference model更側重于數據流的對比這個我很贊同，因為我驗證過UART模塊，像這類驗證功能點的時候結果的時候主要關注寄存器里面的值，ref model搭起來得心應手。而且后來通過閱讀UVM_COOKBOOK發現，像這類數據流的對比連ref model都可以不要。只要在slave agent里設計好transaction,然后和master agent的transaction傳遞給scoreboard直接比對就夠了。 用assertion去驗證timing的做法我也嘗試過，但是后來我放棄了。因為寫assertion我需要知道2個事件發生間的時間。因為邏輯很復雜的時候，DUT有很多內部信號，對于某個功能點的驗證來說，整個信號的傳遞可以看做“輸入->內部信號a->內部信號b->...輸出”。輸入和輸出我們可以通過sepc看出來，但是輸入到輸出花的時間即使我們問寫spec的人，他很可能也不知道。這里我開始選擇寫assertion, 因為我不能信任內部信號，我只能直接去找從輸入到輸出的時間，結果我問設計人員的時候，發現他也是按照這些內部信號去推出來的，所以我只能選擇仿波形去確認。但是這么大的量，不能全靠看波形啊，所以我按照自己的理解設計了輸出波形，把這個波形去和dut實際的輸出波形去作比較，只要uvm報錯了，就去找系統工程師和設計人員確認。這個時候發現即使是SV的assertion，根本滿足不了我的要求，只能自己用SV甚至C++去搭自動check的邏輯。驗證中激勵很重要我也贊同，但是我不覺得它是核心。對于UVM驗證方法學來說，我覺得核心應該是如何去判斷激勵輸入以后的結果是不是對的以及覆蓋率的設計。覆蓋率設計就像一個大綱，激勵只不過按照那個大綱一步一步寫（這里分成2個人去做效果應該更好），而且SV真的很合適干這事。

似水如煙:

大家感觸都很深啊，也能看出來，都在驗證的這條路上摸索。比較同意樓上的說法，黑盒驗證無疑是相對比較省工作量的，只需要關注輸入輸出，更多精力放在如何判斷對錯以及根據覆蓋率構建激勵。但這些問題的根其實還是在對spec的理解上，這個我估計除了好的方法外，還是注重積累，就這方面大家沒有好的經驗傳授。

jimbo1006：

1. 在閱讀spec的時候，每句話看完都要仔細推敲下，把自己當做客戶，想想客戶在看到這句話時會怎么想。會怎么用。

2. 仔細推敲每個功能點，要多個角度去想想。例如，當某個enable信號打開時，某個輸出為1。但是當這個enable信號關閉時，這個輸出是多少，0,1還是donot care。如果spec沒有明確表示，我們需要找系統工程師（寫spec的人）確認。

3. 系統工程師和設計人員在設計模塊的階段，因為長時間合作，很有可能會有一些默契。比如說，某個開關打開以后，dut需要幾個時鐘采一下這個信號。而spec里面卻是按照理想的情況描述的。這個默契可能會提高設計模塊的效率，但是對于我們驗證人員來說卻是一個大麻煩。

因為spec每句話都有可能藏這么一個默契。而這個默契不僅會影響驗證的效率，還有可能影響驗證的可靠性。比如我按照理想的spec為了某個功能點寫了自動比對代碼，仿真以后發現結果不對，結果系統工程師告訴我有這么個默契在，我只能自動比對代碼里面慢慢去找哪里涉及到了這個點，然后改回來。

但是這里其實有個風險，假設我的自動比對代碼某個地方漏了這幾個時鐘，導致某個配置下的輸出一直在輸出默認值0（正確的輸出應該是1），而DUT這個配置下正好也出錯輸出為0，這樣我為認為自動比對和DUT都是對的，導致漏掉BUG。

zxm92：

1.寫assertion我需要知道2個事件發生間的時間-->我覺得這句話應該換成spec沒有定義2個事件發生的時間，如果沒有定義時間的標準，又要去check，并不是assertion辦不到，而是別的都辦不到。假設我擔心輸入到輸出的響應時間太長，又沒有spec，我會記錄下來輸入的時間，記錄輸出的時間，拿對應的輸入輸出時間去計算兩者的時間，得到最大值，再去考量這個最大值是否過大。

2.按照自己的理解設計了輸出波形，把這個波形去和dut實際的輸出波形去作比較，只要uvm報錯了，就去找系統工程師和設計人員確認-->不理解怎么設計輸出波形，如果輸入到輸出的時間在3us～5us這樣一個范圍都是正確的，你要怎么設計輸出波形。

3.覆蓋率設計就像一個大綱，激勵只不過按照那個大綱一步一步寫-->如果你說的是function coverage，我認為覆蓋率和激勵不應該同一個人來寫，出考題和參加考試不應該是同一個人。激勵和覆蓋率是scenario的兩種表現形式，并不是先有了覆蓋率，才去做激勵覆蓋它，也不是有了激勵，才去寫覆蓋率。假設dut有十種function，這十個function是必須串行去做，還是可以并行去做？串行去做的話有沒有順序的限制？并行去做的話哪些需要sync？往往error會出現在那些沒有想到的scenario下。

4.核心應該是如何去判斷激勵輸入以后的結果是不是對的-->判斷激勵輸入以后的結果，先有激勵輸入，才有結果，才有判斷。激勵都不夠完善，判斷正確不代表dut正確

5.在閱讀spec的時候，每句話看完都要仔細推敲下，把自己當做客戶，想想客戶在看到這句話時會怎么想。會怎么用。

-->這句話和我之前回復的這句是一個意思吧"設計人員通常是站在功能實現的角度，而驗證人員應該更多站在使用者的角度，也就是說如何使用做出來的芯片"

jimbo1006回復7#zxm92：

我很高興我們的觀點大部分都相同或者類似，因為我來論壇討論的主要目的就是希望檢驗自己的方法和一些想法。而我們觀點不相同的地方，我認為主要原因是“自動比對”上面。像你3L所說的一樣，作為初做驗證的我來說，“自動比對”對我的誘惑實在是太大，我現在的想法是“自動比對”就是當前，至少是未來驗證人員的主要價值所在，也是我們驗證人員的浪漫。我現在只驗證過幾個模塊，每個模塊的大部分都是通過自動比對驗證的。而且我也找到很多設計人員和系統工程師很驚嘆的BUG，在review的會議上，當他們問我怎么驗證到這么特殊的case的時候，產生的成就感與滿足感讓我無法自拔。你嘗試把我的驗證環境都是自動比對的，我的一些觀點你可能就會接受。

下面幾個point和你7樓的點對應

1. 需要知道2個事件發生的時間是因為我在設計自動比對的代碼，我發現如果不借助DUT的內部信號或者我自己設計的中間信號，已經很難去統計所有配置下DUT的輸出的情況。這就相當于設計人員在設計一個大的模塊時，他會劃分成一個一個小的模塊。而我在設計自動比對時，也需要這么做。我會設計一個一個中間點，因為有很多組輸入和對應的輸出，所以輸入到中間再到輸出并不是單純的線性結構，而是網狀的。網狀的結構會導致我必須要知道每種配置下，到這些中間點的時間，至少是大致的時間。當然，如果系統工程師能給我一個表格，上面列出了所有的輸入的組合和對應的輸出以及他們之間的時間，也就沒這個事了。但是他們肯定做不到，即使做到了，幾種配置以不同的組合線性輸入到DUT，對應的輸出時間也可能有變。

2. 輸出波形的自動比對是我在驗證動機控制模塊（很多PWM功能相關的模塊組成的）設計的做法。我設計了一個collect模塊與slave agent的monitor的相連，以DUT的輸出信號和對應的輸出oe信號為依據，設計了一個transaction, transaction會反應輸出波形的值（0或者1），這個值的持續時間（以系統時鐘/2+1的采樣頻率去采樣確認輸出信號），輸出波形是否為高阻態（輸出oe信號為0）等。然后我將這個transaction傳遞給scoreborad，另外輸入的組合我也會通過master agent的monitor傳遞給socreborad。然后我就在scoreborad進行所謂的理想波形和輸出波形的自動比對。利用fork join函數，設計3段并發路徑，第一條隨機一個時間，第二條將輸入配置下的理想波形和實際輸出波形實時比對，第三條根據需要修改一些參數，例如采樣頻率。你所說的3us~5us這個范圍都是對的，在我這種結構下有很多種解法，為了規范結構提高重用性，我可以在第二路徑下再插入2個fork join，每個2條并發路徑，第一條的時間分別是3us和5us(5us下面發一個flag1）,第二條都是去比對波形，但是對應3us的那個最后放另外一個flag2，在最后我再設計一段代碼會對設計的所有falg進行確認。

3. 覆蓋率和激勵確實不該一個人來寫，我也是這個觀點。但是目前我們公司就我一個人在研究UVM驗證，我去哪找一個人寫激勵。就算今后招了個人，暫時也不可能讓2個人去做一個模塊的驗證，畢竟對spec的理解都要花很多時間。然后你想想，如果我真的把覆蓋率和自動比對的代碼設計好了，我完全可以找幾個本科的應屆生，讓他們用盡一切辦法，只有能夠達到覆蓋率要求并且通過我的自動比對，就OK。這樣會節約很多時間與人力的成本。寫激勵的人和寫覆蓋率的人互相check自然很美好，仔細分析下，真正的決定權其實還在寫覆蓋率的人的手里。你所說的10個function并行和串行的問題，我正好在驗證MCM模塊也遇到，解決方法參照point2.

4. 正如我第3點提到的，只要我設計好覆蓋率，你仿真完，隨時可以查覆蓋率的情況（我用的是VCS+verdi），里面你可以直接找到哪些點你沒有覆蓋到，寫激勵的人可以按照那個重新設計或者添加新的激勵。當然我不是說寫激勵不重要，激勵不完善可以通過覆蓋率的百分比去反饋，但是覆蓋率設計不完善誰能去反饋（代碼覆蓋率和功能覆蓋率可以互相檢測，但是這個的可靠性真不高）？

5. 我很高新我們這個觀點是一致的。