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

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

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

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

jimbo1006：

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

zxm92：

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

jimbo1006 回復(fù)zxm92:

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

似水如煙:

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

jimbo1006：

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

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

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

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

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

zxm92：

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

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

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

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

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

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

jimbo1006回復(fù)7#zxm92：

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

下面幾個(gè)point和你7樓的點(diǎn)對應(yīng)

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

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

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

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

5. 我很高新我們這個(gè)觀點(diǎn)是一致的。