加入星計(jì)劃,您可以享受以下權(quán)益:

  • 創(chuàng)作內(nèi)容快速變現(xiàn)
  • 行業(yè)影響力擴(kuò)散
  • 作品版權(quán)保護(hù)
  • 300W+ 專業(yè)用戶
  • 1.5W+ 優(yōu)質(zhì)創(chuàng)作者
  • 5000+ 長(zhǎng)期合作伙伴
立即加入
  • 正文
    • 01、前言
    • 02、完備性
    • 03、可拓展性
    • 04、可控性
    • 05、總結(jié)
  • 相關(guān)推薦
  • 電子產(chǎn)業(yè)圖譜
申請(qǐng)入駐 產(chǎn)業(yè)圖譜

如何寫出更系統(tǒng)的驗(yàn)證檢查器

10/08 10:40
140
閱讀需 10 分鐘
加入交流群
掃碼加入
獲取工程師必備禮包
參與熱點(diǎn)資訊討論

01、前言

芯片驗(yàn)證是為了發(fā)現(xiàn)芯片中的錯(cuò)誤而執(zhí)行的過程,它是一個(gè)破壞性的過程。有效激勵(lì)灌入待測(cè)模塊后,需要判斷出不符合功能描述的行為。檢查器(Checker)就是用于查看待測(cè)模塊是否按照功能描述文檔做出期望的行為,識(shí)別出所有的設(shè)計(jì)缺陷。

不同被檢查邏輯的層次,所需要的檢查方法不一致,本文主要側(cè)重于模塊級(jí)驗(yàn)證的檢查器設(shè)計(jì)。該層次需要檢查的范圍有:

待測(cè)模塊的所有輸入輸出信號(hào);

待測(cè)模塊的內(nèi)部設(shè)計(jì)細(xì)節(jié);

待測(cè)模塊在芯片系統(tǒng)級(jí)的應(yīng)用角色;

需要的功能描述文檔至少有:

項(xiàng)目產(chǎn)品文檔:描述本模塊的實(shí)際應(yīng)用場(chǎng)景。

項(xiàng)目需求文檔:將產(chǎn)品文檔轉(zhuǎn)換為技術(shù)人員可讀懂的技術(shù)文檔。

待測(cè)模塊設(shè)計(jì)文檔:將需求文檔轉(zhuǎn)換為實(shí)際RTL規(guī)范。

有些模塊還需要其它手冊(cè),比如ArmRISC-VCPU還會(huì)有架構(gòu)參考手冊(cè)。

對(duì)待測(cè)模塊行為的檢查,可以采用不同的檢查方法,主要有:

監(jiān)視器(monitor):可以用于信號(hào)級(jí)別的數(shù)值、時(shí)序和協(xié)議檢查;

參考模型+比較器(Checker):檢查包層級(jí)的信息;

斷言:主要依靠它檢查模塊的邏輯細(xì)節(jié)和時(shí)序信息;

定向測(cè)試:用于簡(jiǎn)單場(chǎng)景的檢查,一般自帶檢查器;

形式驗(yàn)證:用數(shù)學(xué)方式來證明功能是否正確;

根據(jù)情況不同,以上這些方法可以采用其中的一種或多種,一般很少只使用一種的。待測(cè)模塊使用什么樣的檢查方法以及檢查哪些內(nèi)容,也是芯片驗(yàn)證的一大難點(diǎn)。和激勵(lì)設(shè)計(jì)分析類似(如何寫出更牛更系統(tǒng)的驗(yàn)證激勵(lì)),本文也是從完備性、可拓展性可控性三方面展開闡述如何系統(tǒng)地思考和構(gòu)建驗(yàn)證檢查器。

02、完備性

檢查器的完備性是最基本要求,可以從接口類型內(nèi)部結(jié)構(gòu)、結(jié)束檢查(End of check)檢查器審查這四方面去思考。

2.1 接口類型

接口類型檢查主要是檢查輸入輸出信號(hào)是否符合文檔描述的行為,也就是與待測(cè)模塊連接的上下游模塊的互動(dòng)信號(hào)行為??梢詮?strong>單一接口類型和多個(gè)接口交互兩方向去分析。

2.1.1 單一接口類型

單一接口類型分析由信號(hào)檢查協(xié)議檢查組成。

信號(hào)檢查:主要檢查每根信號(hào)的行為,包括信號(hào)值正確性和數(shù)據(jù)完整性。

協(xié)議檢查:主要檢查多根信號(hào)之間的行為,包括時(shí)序檢查、握手檢查,hazard檢查,order檢查,outstanding能力檢查和包傳輸流程檢查等。

信號(hào)值檢查、時(shí)序檢查和握手檢查通??梢杂脭嘌詸z查;outstanding能力檢查和包傳輸流程檢查通??梢杂帽O(jiān)控器檢查。數(shù)據(jù)完整性、hazard檢查和order檢查等復(fù)雜建模需求的通常需要使用檢查器檢查。

2.1.2 多個(gè)接口交互

多個(gè)接口交互由數(shù)據(jù)完整性、保序同步交互組成。

數(shù)據(jù)完整性:檢查信息傳輸沒有丟失。

保序:檢查有先后關(guān)系的傳輸包是否正確傳輸。

同步交互:檢查傳輸包是否有同步或者約定先后出現(xiàn)等關(guān)系。

多個(gè)接口交互的檢查通常需要檢查器檢查。

2.2 內(nèi)部結(jié)構(gòu)

內(nèi)部結(jié)構(gòu)檢查需要沿著數(shù)據(jù)流(data flow)方向分析,看看有哪些必須檢查的轉(zhuǎn)換(transformation)決策(decision)。主要有:

內(nèi)部功能點(diǎn):order、hazard、forward、sleep、replay邏輯、register讀寫等。

資源占用:FIFO、Buffer、Interface、流水線等。

資源仲裁:優(yōu)先級(jí)、死鎖等。

數(shù)據(jù)完整性:數(shù)據(jù)拆分、數(shù)據(jù)合并、數(shù)據(jù)保序等。

功能配置:待測(cè)模塊行為是否符合當(dāng)前寄存器和參數(shù)配置等。

異常檢查:復(fù)位值、內(nèi)部觸發(fā)fault、外部返回錯(cuò)誤響應(yīng)、中斷等。

異常事件是否合理;

異常處理是否正確;

異常處理完,待測(cè)模塊是否能恢復(fù);

內(nèi)部結(jié)構(gòu)的檢查經(jīng)常需要用到RTL內(nèi)部的輔助信號(hào),最好是在非常有必要或可以大大節(jié)省檢查器建模工作量的情況下,才使用這些輔助信號(hào)。而且檢查器用輔助信號(hào)之前,必須檢查輔助信號(hào)行為的合理性。

2.3 結(jié)束檢查

結(jié)束檢查主要用于在驗(yàn)證用例結(jié)束時(shí),檢查RTL和TB的狀態(tài),比如RTL是否處于非busy狀態(tài)、FIFO是否為空、請(qǐng)求是否全部處理完畢等。只要有預(yù)期某個(gè)功能在用例結(jié)束時(shí)必須處于某種狀態(tài),都可以放到結(jié)束檢查里。主要有:

TB/DUT狀態(tài)檢查:Counter、FIFO、Buffer、Queue、Busy等。

仿真日志檢查:可以通過腳本自動(dòng)提取。

波形檢查:通過腳本解析波形內(nèi)容來檢查。

2.4 檢查器審查

審查(Review)環(huán)節(jié)對(duì)完善檢查器起著至關(guān)重要的作用,可以提高檢查器質(zhì)量,并減少漏檢查特性的概率,對(duì)個(gè)人成長(zhǎng)也有很大幫助。

建議以下這些審查方式都要按順序進(jìn)行:

個(gè)人審查:由自己進(jìn)行,對(duì)照歷史錯(cuò)誤清單進(jìn)行,舉一反三,避免犯類似錯(cuò)誤。

同組審查:由組內(nèi)更有經(jīng)驗(yàn)的人進(jìn)行,對(duì)檢查完備性、檢查器設(shè)計(jì)結(jié)構(gòu)、假設(shè)、采用的RTL輔助信號(hào)、代碼實(shí)現(xiàn)進(jìn)行檢查。

跨組審查:由待測(cè)模塊的設(shè)計(jì)人員進(jìn)行,對(duì)檢查器完備性、設(shè)計(jì)顧慮、易錯(cuò)特性、局限性和各種檢查器假設(shè)進(jìn)行檢查。

03、可拓展性

可擴(kuò)展性也包括可復(fù)用性。為了處理驗(yàn)證周期縮短、待測(cè)RTL規(guī)格頻繁變動(dòng)等各種情況,我們需要在設(shè)計(jì)檢查器時(shí)提前構(gòu)思如何讓檢查器更容易擴(kuò)展。基于此,我們可以從模塊化解耦性方面去思考。

3.1 模塊化

模塊化需要對(duì)待測(cè)模塊的每個(gè)功能點(diǎn)檢查都分別集中于一處,而不是將一個(gè)功能點(diǎn)的檢查分散到檢查器各個(gè)地方,且多個(gè)功能點(diǎn)檢查互相穿插耦合,這樣后期如果某個(gè)功能點(diǎn)改動(dòng)會(huì)影響檢查器的很多代碼,而且容易改漏。

把常見的功能封裝成公共庫(kù),這樣在多個(gè)地方都可以直接使用,如果功能需要改動(dòng),只需要改動(dòng)一處代碼即可。

不要把所有檢查器內(nèi)容都放到一個(gè)class類里解決,這樣會(huì)造成這個(gè)類代碼巨多,而且難以維護(hù)??梢园褭z查器根據(jù)待測(cè)模塊特性切割成多個(gè)小的建模單位,由這些小的建模單位共同組成整體檢查器,這樣結(jié)構(gòu)更清晰,而且待測(cè)模塊特性的改動(dòng),只會(huì)影響其中一些建模單位,不需要整體檢查器都修改。

3.2 解耦性

解耦性要求檢查器代碼盡量減少依賴于環(huán)境其它組件的代碼,不管是變量類型、方法還是類,最好使用自身定義的,方便修改、移植和重用。

比如monitor送過來的類內(nèi)容要轉(zhuǎn)換為檢查器自己內(nèi)部定義的類內(nèi)容,檢查器就可以減少依賴于monitor中類的改動(dòng)。

04、可控性

檢查器的可控性在這里主要是指是否方便控制檢查器的功能檢查范圍和消息打印內(nèi)容。

4.1 功能檢查控制

最常見的就是控制檢查器是否開啟,比如在調(diào)試激勵(lì)的時(shí)候,通常會(huì)先把檢查器關(guān)閉掉,避免造成不必要的干擾。

如果需要的話,功能檢查控制可以做到更細(xì)粒度的控制,按照待測(cè)模塊的規(guī)格、接口或某個(gè)功能來控制,這樣就方便根據(jù)實(shí)際情況,選擇打開或關(guān)閉哪些檢查。

4.2 消息等級(jí)控制

檢查器中會(huì)打印一些消息,跟蹤檢查器的內(nèi)部情況,方便出錯(cuò)時(shí)調(diào)試。有效的打印消息越多,仿真速度越慢,但對(duì)調(diào)試來說更友好些。因此,需要控制好不同消息的打印等級(jí),不要每個(gè)周期都打印大量信息。默認(rèn)情況下,只打印一些關(guān)鍵信息。只有需要更多調(diào)試消息時(shí),才調(diào)低等級(jí),打印更多的消息。

05、總結(jié)

綜上所述,檢查器設(shè)計(jì)可以按照“完備性->可拓展性->可控性”方向去分析。在完備性中,可以按照“接口類型->內(nèi)部結(jié)構(gòu)->結(jié)束檢查->檢查器審查”方向去分析。在可拓展性中,可以按照“模塊化->解耦性”方向去分析。在可控性中,可以按照“功能檢查控制->消息等級(jí)控制”方向去分析。

另外很重要的一點(diǎn)是:要經(jīng)常對(duì)驗(yàn)證結(jié)果進(jìn)行復(fù)盤分析,并完善檢查器。

總得思維導(dǎo)圖如下:

相關(guān)推薦

電子產(chǎn)業(yè)圖譜

分享Arm architecture, AMBA, 芯片驗(yàn)證, 腳本, EDA, Linux等知識(shí)。

微信公眾號(hào)