文獻標識碼： A
DOI：10.16157/j.issn.0258-7998.2016.08.007
中文引用格式： 林慧，蔣武，熊熙，等. Verifier提高驗證完備性[J].電子技術應用，2016，42(8)：37-40，43.
英文引用格式： Lin Hui，Jiang Wu，Xiong Xi，et al. Verifier-Improve the simulation verification completeness[J].Application of Electronic Technique，2016，42(8)：37-40，43.
1 介紹
ADE Explorer、ADE Assembler是Cadence Virtuoso ADE一系列產品的重要模擬設計驗證工具，將驗證技術可視化，能夠很好地支持工程師子模塊的模擬設計驗證，大大提高了驗證效率。現有的驗證直接根據仿真結果來決定驗證設計的好壞與否。這種驗證流程簡單有效，但是也有其弊端——規格無標準可循、難以覆蓋更高層的設計，導致難以及時發現并規避設計更深層的問題。在整合了ADE Explorer、ADE Assembler強大的簡單有效的驗證功能的基礎上，ADE Verifier在驗證流程上做了進一步的優化，能夠有效彌補現有模擬設計驗證存在的不足，很大程度上提高了模擬設計驗證的可靠性和完備性。ADE Verifier特性如圖1所示。
圖1 ADE Verifier特性
2 Verifier驗證流程
Verifier支持自頂向下、自下向上、混合的設計方法。本文描述Verifier自頂向下的設計方法。根據客戶需求、業務場景和條件等原始需求，項目管理者（PM/PL）整合原始需求，轉換成設計語言，細化、分解設計需求。然后將整個需求分配給不同的工程師。根據分配得到的需求，工程師深入理解設計需求，量化相應的設計規格，并設計仿真用例和測試用例，完成仿真。然后將需求設計和規格設計進行最后，工程師提交驗證數據，項目管理者就可以及時觀測驗證結果，跟蹤項目驗證進度。ADE Verifier驗證流程如圖2所示。
圖2 ADE Verifier驗證流程
2.1 項目管理者建立Requirement
需求的建立有兩種方式，一是項目管理者在verifier里面創建的，二是直接導入指定格式的需求表格，包括csv文件和excel文件。
需求的內容包括項目名稱，模塊名稱，指標的最大值與最小值、指標的單位、責任人、類型以及詳細的描述等。指標的最大值與最小值、指標的單位都是作為后續規格設計的約束。內容可以由中文、英文、日語、德語、北印度語5種語言組成。
需求的類型包括以下幾種：Note，Spec Pass，Ran OK，Manual。Note類型的需求是不需要仿真驗證；Spec Pass類型和Ran OK類型的需求是可以進行仿真驗證的，二者差別就是Spec Pass類型的需求要考慮需求設計的指標值來決定需求的狀態，Ran OK類型的需求只會根據仿真結果來決定需求的狀態；Manual類型的需求是指是要人為判斷設計的成功與否，而不是直接簡單地根據仿真結果來決定。
需求是Hierarchy結構的。從頂層模塊開始進行需求設計，細化到每個子模塊的需求設計，直到完成整個項目的需求設計。每個需求設計都會指定一個責任人，后續每個責任人都只需要對各自被分配到的需求負責人。
在現有的整個項目需求設計基礎上，可以新增需求、刪除現有需求、編輯現有需求。
2.2 項目管理者分配Requirement
根據需求責任人，可以將master verification分成幾個不同的owner verification。每個責任人只需要著眼于own verification，根據被分配到的需求進行規格設計。如圖3所示，Fred、Harry是master verification的責任人，分配需求時，會生成相應的verification_Fred和verification_Harry。之后，Fred和Harry只需要分別修改、完善verification_Fred 和 verification_Harry即可。
圖3 分配Requirement
2.3 工程師添加Implementation
根據需求設計，工程師進行相應的Implementation，支持adel、adexl、maestro類型的文件。如圖4所示。
圖4 工程師添加Implementation
2.4 工程師建立Mapping
工程師根據自己分配到的任務，建立testbench，和Requirement建立映射。Requiremment與SPEC之間可以是n：1或者1：n的關系。
需求的mapping有6種狀態：Pass，Fail，No Results，Mapped，Unmapped，Spec check failed。
Pass是指在requirement的specification與implementation的specification保持一致的前提下，requirement的specification和仿真結果保持一致。
Fail是指在requirement的specification與implementation的specification保持一致的前提下，requirement的specification和仿真結果不同。
No Results是指在requirement的specification與implementation的specification保持一致的前提下，implementation沒有仿真結果。
Mapped是指requirement的specification與implementation的specification保持一致。
Unmapped是指requirement還沒有建立mapping。
Spec Check Failed是指如果requirement的specification與implementation的specification不能保持一致。
2.5 工程師加載、提交個人Result
Verifier提供了兩種加載結果的方式：直接跑仿真和加載仿真結果。
Verifier呈現的結果包括整個項目的結果百分比，以及每個模塊、需求的結果。需求的結果狀態分為兩種：Requirement Status 和Specification Status。Specification Status是根據spec的結果而定；Requirement Status是根據spec結果以及map結果而定。加載個人Results如圖5所示。
圖5 加載個人Results
2.6 項目管理者查看項目Result
等到工程師提交了個人結果之后，項目管理者就可以查看整個項目的驗證進展和驗證結果。如圖6所示。
圖6 查看項目Results
3 Hisilicon Verifier
3.1 定制化特性
根據海思的業務需求，在原有ADE Verifier平臺上，添加了定制化特性，有以下兩點：
(1)導入的requirement表格形式：通過新增列數，直觀地呈現需求之間的Hierachy結構；
(2)結果的保存與呈現：通過收集工程師提交的結果，保存到數據庫。保存結果能夠讓現有項目傳承歷史項目的優良基因；展示結果從項目和owner的維度展示數據，能夠讓項目管理者直觀看到整個項目的驗證進展，讓工程師清晰認識到自己模塊的進度。Hisilicon Verifier Results如圖7所示。
圖7 Hisilicon Verifier Results
3.2 定制化流程
在工程師提交verification時候，結果數據就會被收集。為了適配定制化特性——收集結果數據，整理了使用verifier的三種流程，這三種流程都能夠保證收集到數據。為了能夠清晰描述三種流程的特點，假設背景如下：工程P，項目經理是M，工程師E1，E2，E3。M新建一個verification，設置result路徑為Current cellview，這樣結果文件就在相應的verification路徑下。分配任務，生成verification_E1, verification_E2, verification_E3。項目經理M check in verification，verification_E1, verification_E2, verification_E3。如圖8～圖11所示。
(1)流程1（如圖8）
圖8 項目背景
Step1：
E1 新建maestre_E1，搭建testbench，跑仿真；
Step2：
E1 Check out verification_E1，和maestre_E1建立Map，加載結果，check in verification_E1，這樣才能收集到數據；
Step3：
E1 Check in maestre_E1，這樣M，E2，E3才能看到E1的結果；
(2)流程2（如圖9）
圖9 流程1
Step1：
E1 新建maestre_E1，搭建testbench，跑仿真；
Step2：
E1 Check out verification_E1，和maestre_E1建立Map，加載結果，check in verification_E1，這樣才能收集數據；
Step3：
E1 Check out verification，load E1的結果，check in verification，這樣M，E2，E3才能看到E1的結果；
(3)流程3（如圖10）
圖10 流程2
Step1：
E1 新建maestre_E1，搭建testbench，跑仿真；
Step2：
E1 Check out verification_E1，和maestre_E1建立Map，加載結果，check in verification_E1；
這三個流程都能夠達到收集數據以及呈現最新結果的目的，但是流程1和流程2都有其弊端。
流程1中，要想工程師的結果被其他人看到，必須提交maestre。首先，maestre很大，提交很費時。其次，maestre保存的是過程配置信息，不適合提交。
流程2中，整個項目組都需要操作一份文件—verification，很容易產生寫沖突，不適合大項目、異地項目的合作。另外，工程師需要操作owner verification 和master verification，職責不夠分明。
流程3，只需要選擇HISILICON_VERIFIER為yes，這樣加載結果來源是結果的快照文件。提交owner verification，即可收集數據，也可以保證其他人都能看到結果。職責分明，操作簡單。
所以，Hisilicon Verifier采用流程3。
圖11 流程3
4 驗證完備性
4.1 完備性問題
以Hisilicon的驗證流程進行分析，從制定原始需求開始，到編寫測試用例，驗證完備性的突出問題如下。
(1)OR：遺漏、客戶自己不清楚；
(2)DR：功能/隱形需求遺漏；
(3)DS：內部規格未細化、規格條件不合理、非典電路規格不全。
4.2 Verifier方案
基于Verifier的驗證流程，驗證完備性問題能夠在很大程度上得到解決。
(1)需求設計、規格設計、仿真等整個驗證流程都是需求驅動的，保證了需求的可溯性。
(2)從上至下的驗證流程，既保證了各個模塊之間相互獨立，互不干擾，也保證了各個子模塊之間無縫契合。
(3)記錄仿真結果，自動復現仿真結果，將仿真過程變得更加可溯和自動化。
(4)當工程師改變了某個設計模塊，verifier具有聯想功能，能夠提示相關testbench需要重新進行仿真，進一步確保驗證完備性。
5 結語
通過使用ADE Verifier工具，我們將在電路設計中解決由于驗證不完備性的各種問題。這種問題在很大程度上是可以通過完善的驗證流程去規避的。在海思的驗證設計實踐中，Virtuoso ADE驗證工具技術與Virtuoso ADE組裝工具技術具備設計規劃能力，讓設計團隊更加高效，提升了模擬IP驗證效率將近30%，驗證發現的問題數量減少了一半。所以，ADE Verifier是驗證設計中不可或缺的工具之一。