來源：EETOP論壇
相關連結： http://bbs.eetop.cn/thread-662712-1-1.html
EETOP論壇驗證分論壇網友喜歡水和煙 問：
<h1>驗證器應讀取規範的角度</h1>
在開發過程中，設計和驗證人員必須關注不同的觀點，特别是在對規格的了解方面，認證人員往往需要自己獨立的了解。當您獲得幽靈時，作為驗證器，您應該如何優化功能以将其轉換為相應推理模型實作和詳細設計的交叉驗證。我們可以讨論哪些經驗？
以下是網友們的回答：
jimbo1006：
我認為，當驗證者檢視規範中的功能點時，他們需要注意輸入，輸出以及從輸入到輸出所需的時間。
首先，"從輸入到輸出所需的時間"，這是RTL内部的延遲，我認為這是設計參考模型的最大困難。因為即使你問寫這副花絮的人，他可能也不知道。在這一點上，我們将詢問設計人員或檢視RTL代碼，但随後我們可能會受到設計人員思維的影響，并且出現的ref模型可能與RTL有誤，是以您的驗證環境可能永遠不會發現該BUG。
然後從輸入到輸出，這就像一個真值表，我們需要做的就是根據随機政策設計和限制激勵。但随着邏輯複雜性的增加，真值表變得越來越大，使我們很難寫出所有内容。此時，我們可以将這個大真值表分成幾個小真值表，就像設計一個大子產品一樣。這很容易說，但這裡的工作負載随着邏輯複雜性指數的增加而增加。如果要做所謂的交叉驗證，最好找另一個設計人員，也設計這樣的子產品，然後他們比一對一的結果，然後跑過延遲，就不需要人員驗證了。
最後，我在大學設計的時候，設計了參考模型（用C寫好，用軟體運作看效果），然後根據這個參考模型來設計子產品，最後設計子產品，最後在FPGA上運作。如果在此處添加驗證步驟，則可以直接使用此參考模型進行驗證。是以，我認為這是最合理的過程，即有一個參考模型，然後需要驗證RTL。但是當我實際工作時，有RTL再參考模型，公司的所有者應該是一樣的，否則就不會問這個問題。讓我們分析一下，ref 模型雖然是根據規範編寫的，但它獲得了 RTL 的内部延遲，然後我們使用 RTL 的 ref 模型中的這部分邏輯來驗證 RTL。這種略帶粗心大意，會放開BUG，因為一般我們的記分牌裡面的auto_check是直接用來擷取ref模型的輸出，不會去檢查其内部邏輯。
zxm92：
1.被攝體對參考模型的過分關注，側面反映的是主體是否更站在設計師的角度做驗證，起初我也癡迷于參考模型，自動比較到第一人做驗證是一種極大的樂趣。2.樓上說時間輸入到輸出驗證，我認為源模型更側重于資料流的比較，時間序列上面的檢查器可以使用斷言。
個人認為設計師和認證機構對規格的看法不同：
1.設計人員通常從功能實作的角度出發，驗證者應該更多地從使用者的角度出發，即如何使用所制造的晶片
2.如何使用晶片，決定你的動機，你的動機決定了晶片面臨的情況，晶片在所有可能的情況下都能得到正确的維護，那麼晶片的品質就有保證，是以如何設計你的動機是驗證的核心。
jimbo1006 回複 zxm92：
我不會長時間工作，而且我現在對參考模型特别困惑，覺得如果我寫這篇文章，我會把一些邏輯留給參考模型來判斷，如果那部分邏輯與DUT不一緻，這可能是一個可怕的情況。
參考模型更側重于資料流的比較，這一點我都同意，因為我已經驗證了UART子產品，比如這種驗證功能點時的結果主要集中在寄存器内部的值上，參考模型放在一起很友善。後來，通過閱讀UVM_COOKBOOK發現，即使通過參考模型也可以避免像這些資料流的比較。隻需在 slack 代理中設計跟蹤操作，然後将其直接與主代理的事務傳遞到記分牌進行比較。
我試圖用斷言來驗證時間，但後來我放棄了。因為寫斷言我需要知道兩個事件之間的時間。由于邏輯複雜，DUT内部信号很多，對于一個功能點的驗證，整個信号的傳輸可以看作是"輸入>内部信号a>内部信号b->...輸出。輸入和輸出可以在秒内看到，但是即使我們詢問編寫規範的人，輸入到輸出所需的時間也可能是未知的。在這裡我開始選擇寫斷言，因為我不能信任内部信号，我隻能直接從輸入到輸出的時間，結果我問了設計師，發現他也按照這些内部信号推出，是以我隻能選擇模仿波形來确認。但是這麼大的量，不能靠一看波形啊，是以我根據自己的了解設計了輸出波形，這個波形到點實際輸出波形來比較，隻要uvm報告錯了，就去系統工程師和設計人員确認。這時發現，即使是SV的斷言，根本達不到我的要求，隻能用SV甚至C，才能騎上邏輯自動檢查。
驗證中的激勵很重要，我同意，但我不認為它是核心。對于UVM驗證方法，我認為核心應該是如何判斷激勵投入後的結果是否正确以及設計的覆寫範圍。覆寫設計就像一個大綱，激勵隻是根據這個大綱一步一步地寫出來（在這裡應該最好分成兩個人），SV确實很适合這樣做。
像水和煙一樣：
大家感覺很深啊，也能看到，都在驗證這條路上探索。
更認同樓上的說法，黑匣子驗證無疑是工作量相對較少，隻需要注意投入和輸出，更注重如何判斷是非，建立基于覆寫的激勵機制。但這些問題的根源其實在于對規範的了解，這我估計除了好的方法，還是注重積累，在這方面我們沒有很好的經驗來教。
1.在閱讀spect時，每一句話都要仔細考慮，把自己當成客戶，想想客戶看到這句話會怎麼想。它将如何運作。
2.仔細考慮每個功能點，并從多個角度思考。例如，當使能信号導通時，輸出為 1。但是當這個使能信号關閉時，輸出是什麼，0，1是不在乎的。如果規範沒有明确說明，我們需要從系統工程師（編寫規範的人）那裡得到确認。
3. 系統工程師和設計人員正處于子產品的設計階段，因為由于長期合作，很有可能會有一些默契。例如，當開關導通時，占空比需要幾個時鐘來拾取信号。規範以理想的方式描述。
這種默契可能會提高設計子產品的效率，但對我們的認證者來說卻是一個很大的麻煩。因為規範的每一個字都可能隐藏着這種默契。這種默契不僅影響核查的效率，而且可能影響核查的可靠性。
比如，我根據某個功能點的理想規格編寫了自動比較代碼，後來仿真發現結果不對，結果系統工程師告訴我有這樣一種默契，我隻能自動比較代碼慢慢找出涉及這一點的位置，然後再改回來。但這裡存在一個風險，假設我的自動比較代碼某處錯過了這些時鐘，導緻配置的輸出已經輸出預設值為0（正确的輸出應該是1），而DUT配置也完全是錯誤的輸出0，是以我認為自動比較和DUT是正确的，導緻缺少BUG。
1.寫斷言 我需要知道2個事件之間的時間 - >我認為這句話應該替換為spec不定義2個事件的時間，如果沒有标準來定義時間，并去檢查，不是斷言不可以做，但别的都做不了。假設我擔心從輸入到輸出的響應時間太長而沒有spect， 我會記錄輸入的時間，記錄輸出的時間，取相應的輸入和輸出時間來計算兩者的時間，得到最大值，然後考慮最大值是否過大。
2.根據自己對輸出波形設計的了解，将此波形與dut實際輸出波形進行比較，隻要uvm報告錯誤，就去系統工程師和設計人員确認——>不懂如何設計輸出波形，如果輸入到輸出的時間在3us到5us這樣的範圍内是正确的， 如何設計輸出波形
3.覆寫設計就像一個大綱，激勵隻是根據大綱一步一步地寫出來
- >如果你在談論趣味性報道，我不認為報道和動機應該由同一個人撰寫，問題和考試也不應該由同一個人撰寫。激勵和覆寫是兩種形式的情景，不是先用覆寫，然後做激勵覆寫，也不是用激勵，寫覆寫。假設dut有十個搞笑，這十個搞笑是必須連續完成的，還是可以并行完成？串行功能是否有順序限制？如果并行進行同步，則需要同步什麼？通常，錯誤會出現在您意想不到的場景下。
4.核心應該是激勵投入後如何判斷結果是否正确
-->在激勵投入之後判斷結果，在結果之前有激勵輸入，隻有然後判斷。激勵不完美，正确的判斷并不意味着dut是正确的
5.在閱讀規範時，每一句話都要仔細考慮，把自己當成客戶，想想客戶看到這句話會怎麼想。它将如何運作。
——>這句話和我之前回複的那句話是一個意思："設計人員通常都是從功能實作的角度出發，驗證者應該更從使用者的角度出發，即如何使用自制晶片"
Jimbo1006回複 7 s zxm92 ：
我很高興我們的大多數觀點是相同或相似的，因為我在這個論壇上讨論的主要目的是測試我的方法和一些想法。而我們意見不一的地方，我認為主要原因是上面的"自動比較"。正如你在3L中所說，作為我的第一個驗證，"自動比較"對我來說太誘人了，我目前的想法是"自動比較"是目前，至少是未來驗證者的主要價值，也是我們認證者的浪漫。我現在隻驗證了幾個子產品，其中大多數都是通過自動比較驗證的。我還發現了許多設計師和系統工程師驚歎于的錯誤，在審查會議上，當他們問我如何驗證這樣的特殊情況時，我産生的成就感和滿足感超出了我的承受能力。你嘗試自動比較我的驗證環境，以及我的一些想法，你可能會接受。
以下是與您在7樓的觀點相對應的幾個點
1.需要知道這兩個事件是什麼時候發生的，因為我正在設計自動比較的代碼，我發現如果沒有DUT的内部信号或我自己的中間信号的幫助，很難計算所有配置中DUT的輸出。這相當于設計人員設計一個大子產品，該子產品被劃分為一個小子產品。當我設計自動比較時，我需要這樣做。我将設計一個中點，因為有許多組輸入和對應的輸出，是以從中間到輸出的輸入不是簡單的線性結構，而是一個網格。網格的結構使我至少大緻知道每個配置中到這些中點的時間。當然，如果系統工程師能給我一個表格，列出所有輸入和相應輸出的組合以及它們之間的時間，那就沒問題了。但它們肯定不能，即使它們這樣做，也可以以不同的組合線性地将幾種配置饋送到DUT中，并且相應的輸出時間可能會有所不同。
2.輸出波形的自動比較是我驗證動機控制子產品（由許多PWM功能相關子產品組成）設計的做法。我設計了一個colect子產品，根據DUT的輸出信号和相應的輸出oe信号與從代理的螢幕連接配接，并設計了一個跟蹤動作，它對輸出波形的值（0或1）做出反應，其持續時間（采樣以确認系統時鐘采樣頻率下的輸出信号/ 2-1）， 輸出波形是否為高電阻（輸出oe信号為0）等。然後，我将此軌迹操作傳遞給 scoreborad，我輸入的附加組合通過主代理的螢幕傳遞給 socreborad。然後，我将進行所謂的自動比較，将理想波形與得分波的輸出波形進行比較。利用分叉連接配接功能，設計一條3段并發路徑，第一次随機，第二次将輸入配置的理想波形與實際輸出波形進行實時比較，第三次根據需要修改一些參數，如采樣頻率。你說的範圍是3us到5us是對的，在我的結構中有很多解決方案，為了标準化結構以提高可重用性，我可以在第二條路徑下再插入2個分叉連接配接，每2條并發路徑，第一次是3us和5us（5us下一個标志1），第二個是比較波形， 但對應于3us的最後一個放置另一個标志2，在一天結束時，我将設計一段代碼，以确認設計的所有謬誤。
3.報道和動機真的不應該由一個人來寫，而我确實這樣做了。但目前我們公司正在研究我自己研究UVM驗證，我将找到一個人來寫關于動機的文章。即使将來招聘個人，也不可能讓2個人做一個子產品驗證，畢竟了解規範會花費很多時間。然後你會想，如果我真的把覆寫率和自動比較的代碼設計，我可以找到幾個大學生，讓他們窮盡一切手段，隻有滿足覆寫要求，才通過我的自動比較，還行。這将節省大量的時間和勞動力成本。寫動機的人和寫報道的人自然對彼此都很好，經過仔細分析，真正的決定實際上掌握在寫報道的人手中。你說的10個搞笑并聯和串聯問題，我碰巧正在驗證MCM子產品也遇到了，解決方案參考了第2點。
4.正如我在第3點中提到的，隻要我設計了覆寫範圍，你模拟它，你可以随時檢查覆寫率情況（我使用的是VCS-verdi），在那裡你可以直接找出你沒有覆寫的點，寫動機的人可以遵循重新設計或添加新的激勵措施。當然，我并不是說寫激勵不重要，激勵不完善可以通過覆寫率回報，但覆寫設計不完善誰能回報（代碼覆寫率和功能覆寫率可以互相檢測，但這種可靠性真的不高）？
5. 我對我們的觀點很陌生，即我們是一緻的。