我的第一份vPlan衍变路线
在第一次寫vPlan的時候，對于其中的Verification requirements (Features to be tested)這一章怎么寫，腦子里沒有一個清晰的概念，只是朦朧地認為“這一章列出了所需要驗證的功能，應該把DUT的所有功能都寫出來”。于是就寫出了形如“DUT讀存儲器、DUT寫存儲器、DUT被FW配置、DUT解碼、FW讀取DUT的結果”（v1）之類的所謂功能（這里只是舉例子，寫得不完整也不精確），就好像告訴自己“以后在驗證的時候，要驗證這些功能都正常；在寫bench的時候，通過參考所列的功能我就能得到bench編寫的靈感”。但是仔細想一想，我發現我所列的上述功能簡直是太不具體了，幾乎起不到什么指導作用。
我下一個想法就是“把功能寫清楚，使之能夠更好地指導仿真”。于是我開始思考DUT(Rx)、FW、Tx_model在真實場景下的整個工作流程，我想到“如果我把系統運行時的行為描述得很具體，同時具體地標出涉及到的寄存器、信號線的名字，那么我就可以知道如何編寫bench以重現真實環境下的DUT及其周圍環境的運行情況了”。在此基礎上我又加入了一些必不可少的東西，比如每次發送給Tx的數據應該是隨機的，并且這個激勵的每一種情況都應該被嘗試一遍。于是我v2：“發給Tx_Model的13bit信號的每種情況都應該被遍歷到、FW通過寫寄存器A初始化DUT、FW通過寄存器B開啟DUT工作、DUT讀存儲器、DUT寫存儲器、DUT發出完成信號irq、FW讀取DUT運算結果、FW根據本次結果決定下一次對DUT的配置、等”（v2）。比之前的v1版本的要詳細得多，并且所描述的功能都是按照實際運行的時間順序來整理的。此時非常困擾我的是：若想讓仿真環境運行的和真實情況中的一樣，即模仿真實DUT和周圍環境的工作過程是難以利用bench實現的。因為系統的工作流程依靠一些DUT外部的邏輯設計，比如FW中的功能，甚至是更抽象的層面上的SW的功能所決定的。想要完全真實的模仿這些東西是不可能的或者說根本就不是DVer的工作（相關的內容我在《請專注于DUT的功能》中有描述）。在這個練習案例中，我根本沒必要想得那么復雜，沒必要把DUT外部提供的功能全都放到仿真環境中去。我在進一步修改vPlan時，著重區分哪些是DUT真正的功能，即真正應該被驗證的東西。而且，在Verification requirements這部分，我更應該關注要驗證什么，而不是怎么驗證，所以按照時間順序來寫Verification requirements可能本來就是錯誤或者不必要的。
DUT的功能其實很簡單：在某種寄存器配置狀態下，讀取某一段待譯碼的數據，DUT經過運算后返回一個結果和其它功能信號。至于v2中提到的“FW讀取DUT的結果、FW根據DUT結果決定下一次配置”等，都不能算作是DUT本身的功能，是不需要驗證的。至于DUT讀寫存儲器這一功能，是一個非常常見的功能，在design spec中并沒有強調讀寫過程有什么特殊性或者值得特別關注的地方，所以可以不寫在vPlan里面。 這樣看來似乎vPlan中的Verification requirements這一章沒什么功能好寫的了，但是，這一章在列出“Features to be tested”的同時還要定義“Verification Scope”，也就是對feature的特性作進一步的描述（約束）。所以在v3中我寫道：“輸入待解碼數據的可能范圍、輸入UEID碼的可能范圍、DUT寄存器的可能配置方案、配置方案存在的約束關系、DUT解碼的最長時間、等”（v3）。這樣似乎更符合“Verification requirements”的稱呼。
轉載于:https://www.cnblogs.com/sunmaoduo/p/4390465.html
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的我的第一份vPlan衍变路线的全部內容，希望文章能夠幫你解決所遇到的問題。
