569
芯片驗證是為了發(fā)現(xiàn)芯片中的錯誤而執(zhí)行的過程，它是一個破壞性的過程。完備的驗證激勵可以更有效地發(fā)現(xiàn)芯片錯誤，進而縮短驗證周期。合格的驗證激勵必須能產(chǎn)生所有可能的驗證場景(完備性)，包括合法和非法的場景，并保持最大的可擴展性和可控性。
激勵構(gòu)造一直都是芯片驗證的一大難點。本文將從完備性、可拓展性和可控性三方面展開闡述如何系統(tǒng)地思考和構(gòu)建驗證激勵。
? ? ? 1. 完備性
完備性可以從接口類型、內(nèi)部結(jié)構(gòu)和激勵審查三方面分析。分析接口類型是為了從待測模塊與其它模塊的交互信號上提取出驗證場景。分析內(nèi)部結(jié)構(gòu)是為了從待測模塊內(nèi)部實現(xiàn)細節(jié)上來調(diào)整激勵，使激勵多產(chǎn)生可能發(fā)現(xiàn)錯誤的場景。激勵審查用于查缺補漏，從自己、他人以及項目等各個環(huán)節(jié)上對激勵進行完善。
1.1 接口類型
對于待測設計的輸入輸出接口，可以通過接口類型進行劃分，根據(jù)接口類型的特性構(gòu)造對應的驗證組件來產(chǎn)生激勵。常見接口類型有：
系統(tǒng)控制接口：主要是時鐘、復位、電源開關、時鐘門控、時鐘分頻等，這類信號行為都會有詳細的規(guī)定，遵循實際集成關系做控制即可。例如：時鐘和復位的時序，多個時鐘是不是同步關系，多個復位信號是否可以單獨控制等。
標準總線接口：行業(yè)公開的標準總線協(xié)議，例如AMBA系列協(xié)議。這類協(xié)議通常有現(xiàn)成的驗證IP，只需配置它們來產(chǎn)生預期的場景。
非標準總線接口：公司內(nèi)部定義的接口，或者根據(jù)模塊功能需求定義的接口。這類接口需要從相鄰設計了解各信號的準確信息。
其它接口：DFT等。通常來說，這類接口與驗證關系不是很大，只需要把它們接固定值即可。
在對接口類型進行分析要產(chǎn)生的激勵時，可以先從單一接口類型進行分析，然后再看多個接口交互上有什么需要重點關注。關于如何進行測試點分解，可以看這個系列視頻《芯片驗證分享系列總結(jié)及PPT分享》。
1.1.1 單一接口類型
單一接口類型分析可以按基本顆粒、高級顆粒和非法行為順序進行。
基本顆粒：基本顆粒面向信號層，提供基本顆粒生成方法。
每根信號：信號來源和功能、使能極性、脈沖有效或電平有效、時序、信號的取值范圍和格式等。
信號之間：不同信號之間的關系，是否存在握手和時序關系，無關信號是否處理成隨機值還是固定值等。
高級顆粒：高級顆粒面向場景層，它封裝了多個基本顆粒，較少考慮底層信號。
序列：傳輸包的序列有哪些。
密度：傳輸包的密度分布有哪些。
非法行為：用于驗證待測設計的魯棒性，出現(xiàn)非法行為，待測設計是否可以正常處理。
數(shù)值：信號值可能出現(xiàn)哪些非預期的值。
行為：信號時序、協(xié)議等行為可能出現(xiàn)哪些異常行為。
1.1.2 多個接口交互
對于具有多個接口的待測設計，我們也需要考慮接口之間可能存在的交互或同步，以及接口之間是否使用共同資源。比如，為了測試兩個接口相同地址hazard，可以讓這兩個接口共享一個地址產(chǎn)生器。
不同接口對應不同的驗證組件，組件之間的協(xié)調(diào)有用多種方式：
中心統(tǒng)籌式：通過集中式控制、分配和協(xié)調(diào)，在上層將任務分解成每個接口組件的任務，并統(tǒng)一分派給各個接口組件去執(zhí)行，進而產(chǎn)生不同的激勵組合場景。比如UVM中的virtual sequence角色。
分布事件驅(qū)動式：每個接口組件有自己的控制權(quán)，各個組件直接進行交互。比如使用SystemVerilog中的event、mailbox、semaphore和全部變量等方式實現(xiàn)通信交互。
混合式：上述兩種方式并存。這需要根據(jù)具體場景來使用。
1.2 內(nèi)部結(jié)構(gòu)
激勵設計除了看接口信號外，還需要結(jié)合待測設計的內(nèi)部結(jié)構(gòu)和功能去分析，調(diào)整激勵約束，從而有更大的概率產(chǎn)生有效場景。
可以沿著控制流(control flow)方向去分析待測設計的內(nèi)部結(jié)構(gòu)和功能，具體以下幾個地方需要重點關注：
觸發(fā)功能點：觸發(fā)內(nèi)部某個功能的激勵序列有哪些，比如Prefetch、flow-control、address hazard等。觸發(fā)內(nèi)部某個功能的敏感值有哪些，比如ALU、內(nèi)部錯誤(cache ecc error, slave error, etc)、barrier、exclusive monitor、address hazard等。
觸發(fā)資源瓶頸和爭搶：如何觸發(fā)內(nèi)部資源瓶頸和爭搶。比如FIFO空滿、Buffer空滿、多請求源仲裁、數(shù)字運算上下溢等。
1.3 激勵審查
審查(Review)環(huán)節(jié)對完善激勵起著至關重要的作用，可以提高激勵質(zhì)量，并減少漏驗特性、無效激勵的概率，對個人成長也有很大幫助。
建議以下這些審查方式都要按順序進行：
個人審查：由自己進行，對照歷史錯誤清單進行，舉一反三，避免犯類似錯誤。
同組審查：由組內(nèi)更有經(jīng)驗的人進行，對激勵完備性、設計結(jié)構(gòu)、假設、代碼實現(xiàn)進行檢查。
跨組審查：由待測模塊的設計人員進行，對激勵完備性、設計顧慮、易錯特性、局限性和各種激勵假設進行檢查。
? ? ? 2. 可擴展性?
可擴展性也包括可復用性。為了處理驗證周期縮短、待測RTL規(guī)格頻繁變動等各種情況，我們需要在設計激勵時提前構(gòu)思如何讓激勵更容易擴展?；诖?，我們可以從模塊化和層次化方面去思考。
2.1 模塊化
模塊化需要將設計輸入輸出信號劃分為不同的接口類型，并創(chuàng)建出對應的接口驗證組件，確保各個組件之間的獨立性，各個組件才會最大程度地不受其它組件的制約。并定義好模塊之間的交互方式，這樣一個模塊的改動對其它模塊的影響就很小，而且模塊也更容易的復用到其它地方。例如，如果有兩組相同接口，則應該引入兩個組件分別控制，而非建立一個組件卻擁有兩套接口，這樣后期維護起來會很麻煩的。
另外把常見的功能封裝成公共庫，這樣在多個地方都可以直接使用，如果功能需要改動，只需要改動一處代碼即可。在寫代碼時，多留一些后門(callback)，方便實現(xiàn)多樣化的激勵和后期增加新功能。
2.2 層次化
層次化需要將激勵抽象出各個層次，越高的抽象層次越不關注底層的時序，而是更重視驗證場景構(gòu)造。這樣底層信號時序或功能的改動也不容易影響到上層的激勵，而且上層的激勵說不定也可以復用到其它地方。
以UVM為例，uvm_driver應只關心接口驅(qū)動，負責把收到的uvm_sequence_item內(nèi)容直接驅(qū)動到接口信號；uvm_sequence負責場景的構(gòu)造，當然uvm_sequence也可以繼續(xù)分層，更上層的uvm_sequence產(chǎn)生更宏觀的驗證場景，然后逐層分解成小的場景。
? ? ? 3. 可控性?
可控性用于表征是否容易控制激勵產(chǎn)生預期的驗證場景。比如驗證ECC模塊功能時，在最開始時，我們需要不注入任何ECC錯誤的激勵，側(cè)重于驗證ECC模塊功能是否正常。隨后才會打開ECC注錯激勵，驗證ECC模塊是否可以檢查出來。這需要提供一些方式可以控制是否打開ECC注錯激勵?；诖?，我們可以從局部和全局方面去思考。
3.1 局部
可控性局部的意思是驗證激勵可以單獨控制局部激勵的行為，通常來說面向單個接口驗證組件。這層控制的特點是偏向于接口，可以細致到控制接口每根信號的行為。
比如，待測對象有兩個ECC模塊，我們可以控制其中一個有ECC注錯，另一個沒有。
3.2 全局
可控性全局的意思是驗證激勵可以一同控制所有激勵的行為，通常來說面向一個驗證環(huán)境中的所有接口驗證組件。這層控制的特點是偏向于特性，是把所有局部控制參數(shù)整合起來，提供和驗證特性相關的控制參數(shù)。
比如，待測對象有兩個ECC模塊，我們可以同時控制兩個都有ECC注錯，或都沒有等。又或者待測對象的某個特性還未開發(fā)完成，我們可以控制不讓所有激勵發(fā)出與未完成特性相關的場景。
? ?總結(jié)? ? ??
綜上所述，激勵設計可以按照“完備性->可拓展性->可控性”方向去分析。在完備性中，可以按照“接口類型->內(nèi)部結(jié)構(gòu)->激勵審查”方向去分析。在可拓展性中，可以按照“模塊化->層次化”方向去分析。在可控性中，可以按照“局部->全局”方向去分析。
另外很重要的一點是：要經(jīng)常對驗證結(jié)果進行復盤分析，并優(yōu)化激勵。
總得思維導圖如下：
