EETOP 論壇驗證分論壇網(wǎng)友 似水如煙 提問：

驗證人員應(yīng)該以何種角度閱讀spec

在開發(fā)流程中，設(shè)計和驗證人員關(guān)注的點肯定是不一樣的，尤其在spec的理解上，驗證人員往往需要有自己獨立的理解。在拿到spec時，作為驗證人員，應(yīng)該如何提煉其中的功能從而轉(zhuǎn)化為對應(yīng)的inference model以實現(xiàn)和詳細(xì)設(shè)計的交叉驗證。大家有什么經(jīng)驗?zāi)苡懻撘幌隆?/span>

以下是網(wǎng)友解答：

jimbo1006：

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

zxm92：

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

jimbo1006 回復(fù)zxm92:

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

似水如煙:

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

jimbo1006：

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

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

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

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

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

zxm92：

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

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

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

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

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

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

jimbo1006回復(fù)7#zxm92：

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

下面幾個point和你7樓的點對應(yīng)

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

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

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

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

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