SoC芯片設(shè)計驗證詳解

來源：汽車電子與軟件

前言

芯片的功能安全曾是非常小眾的領(lǐng)域，只有少數(shù)汽車、工業(yè)、航空航天和其他類似市場的芯片與系統(tǒng)開發(fā)商關(guān)注。然而，隨著汽車行業(yè)過去幾年各類應(yīng)用的興起，情況已經(jīng)發(fā)生巨大變化。同時，除了汽車外，還有很多其他行業(yè)也能從電子器件的增加受益，當然保障功能安全是大的前提。本文討論SOC芯片設(shè)計驗證、驗證計劃和策略以及驗證方法。它定義了功能模擬、功能覆蓋、代碼覆蓋以及設(shè)計驗證中使用的重要術(shù)語。本文還涉及FPGA驗證及其在SOC驗證中的作用。

01、驗證的重要性

由于開發(fā)和制造成本過高，一次成功是SoC設(shè)計的首要要求。幾十年來，人們一直致力于提高SoC驗證的有效性和效率。評估驗證有效性的最有效指標是SoC設(shè)計通過現(xiàn)場測試的次數(shù)。除此之外，SoC設(shè)計越來越復(fù)雜，需要有效的驗證方法來改善這些統(tǒng)計數(shù)據(jù)。這種對ASIC/SoC設(shè)計的有效驗證的需求在2000年出現(xiàn)，開始設(shè)計許多創(chuàng)新的方法來驗證SoC設(shè)計，但仍有更多的空間。

SoC驗證是用于確認SoC設(shè)計的功能正確性的過程。典型的SoC設(shè)計周期(從規(guī)格開始到設(shè)計流片)從六個月到三年不等，具體取決于技術(shù)、系統(tǒng)的復(fù)雜性以及SoC設(shè)計構(gòu)建模塊的可用性。制造過程、封裝、ATE測試和獲取工程樣品進行現(xiàn)場驗證(芯片交付給客戶進行產(chǎn)品試驗)通常需要6個月的時間。因此，所有的SOC只有在工程樣品在確定的產(chǎn)品用例場景中被驗證之后才可用于生產(chǎn)。如果這是成功的，SoC設(shè)計被考慮用于批量生產(chǎn)。這是設(shè)計的一次成功。開發(fā)周期中任何一個步驟的失敗都會成倍地影響設(shè)計時間，有時需要新的金屬流片和設(shè)計修正。使設(shè)計一次成功的另一個驅(qū)動因素是納米技術(shù)的制造成本。采用40納米CMOS FinFET技術(shù)的36平方毫米芯片設(shè)計的典型制造成本約為80萬至100萬美元。SoC工程樣品開發(fā)期間產(chǎn)生的高額非經(jīng)常性工程(NRE)和制造成本將在大量生產(chǎn)中攤銷。因此，如果NRE要求對工程樣品進行多次流片，那么它可能會對業(yè)務(wù)產(chǎn)生很大影響，在商業(yè)上根本不可行。因此，在片上系統(tǒng)開發(fā)中，一次成功是絕對必要的。

SoC設(shè)計驗證的可行性取決于在預(yù)硅階段確定系統(tǒng)的一組“最常見的用例場景”。這是一個非常復(fù)雜和具有挑戰(zhàn)性的現(xiàn)象，因為可能有無數(shù)的用例場景。例如，人們可以很容易地想象智能手機移動SoC的無數(shù)用例場景，其主要功能是通話電話。但是智能手機被用于許多應(yīng)用，例如發(fā)送信息、購物、跟蹤人體健康、銀行和信息娛樂。將會有大量的應(yīng)用場景來測試和驗證移動SoC對這些應(yīng)用場景的設(shè)想來識別和驗證它們。在開發(fā)周期中，隨著設(shè)計從一個階段進入下一個階段，調(diào)試SoC問題的成本會增加10倍。也就是說，設(shè)計階段的驗證成本比在晶片階段驗證相同功能的成本低10倍，比在芯片階段驗證的成本低10倍。這比在客戶現(xiàn)場進行驗證要便宜十分之一。這是因為與開發(fā)的高級階段相比，設(shè)計人員在設(shè)計階段獲得了更高的調(diào)試權(quán)限和工具支持。因此，在預(yù)芯片階段，一組接近實際應(yīng)用用例的關(guān)鍵場景將被識別和瞄準，以獲得SoC首次成功的良好信心。SoC設(shè)計是通過集成不同類型的設(shè)計模塊或IP核(軟、硬核)來完成的，這進一步挑戰(zhàn)了設(shè)計驗證。SoC設(shè)計過程還包括從RTL到網(wǎng)表再到布局結(jié)構(gòu)的一系列設(shè)計轉(zhuǎn)換，然后轉(zhuǎn)換為掩模數(shù)據(jù)。當設(shè)計經(jīng)歷這些轉(zhuǎn)換時，需要驗證設(shè)計意圖在所有層次上都得到了保留，直到完成為止。

總而言之，驗證對SoC設(shè)計如此重要的原因如下:

過高的制造成本要求首次成功，因為多次重復(fù)可能使其在商業(yè)上不可行。

隨著開發(fā)周期中設(shè)計的進展，驗證成本增加10倍。因此，早期驗證將增強首次獲得正確SoC設(shè)計的信心。

• 由于SoC設(shè)計涉及到使用EDA工具對數(shù)據(jù)庫進行一系列轉(zhuǎn)換，因此有必要驗證這些轉(zhuǎn)換是否正確實現(xiàn)，這需要通過驗證來完成。

02、驗證計劃和策略

為了SoC設(shè)計的一次成功（當它第一次被制造時，SoC按預(yù)期工作），在設(shè)計階段采用許多驗證方法是重要的。所使用的不同類型的驗證技術(shù)是基于仿真的驗證、形式驗證、時序驗證、FPGA驗證以及硬件仿真和驗證。仿真驗證是過去唯一采用的技術(shù)。但是隨著系統(tǒng)的日益復(fù)雜，有必要使用一切可能的方法來驗證SoC設(shè)計。

很難定義完成設(shè)計驗證的條件，因為幾乎不可能模擬SoC設(shè)計的所有設(shè)計場景?？紤]具有兩種狀態(tài)的單個觸發(fā)器的設(shè)計示例：測試觸發(fā)器所需的測試模式的數(shù)量是4，ARM Cortex M4內(nèi)核采用65納米技術(shù)，具有65 K個門，這些門可以有多個輸入輸出。為了簡化討論，假設(shè)所有的門只有兩種狀態(tài)，想象一下測試ARM cortex M4內(nèi)核所需的模式數(shù)量，將是65 × 1000 × 4 = 0.26萬個圖案。僅僅模擬所有這些（不考慮從主要輸入-輸出訪問它們的問題，為它們中的每一個尋找測試模式，等等）在不同的設(shè)計階段實際上是不可能的。

在系統(tǒng)層面，識別所有場景也是非常具有挑戰(zhàn)性的。這可能是因為無法預(yù)測和可視化用例場景本身，或者可能是因為環(huán)境中需要更多的模型或模塊來實現(xiàn)它。它可以是完整的軟件堆棧，也可以是移植整個設(shè)計數(shù)據(jù)庫的硬件平臺，或者是用于仿真的計算系統(tǒng)基礎(chǔ)設(shè)施。因此，需要將可實現(xiàn)的場景定義為驗證測試環(huán)境和一組測試用例，作為預(yù)芯片驗證的范圍。

這可以通過多種方式實現(xiàn)：

自上而下的方法

自下而上的方法

平臺級驗證

• 系統(tǒng)級或交易級驗證(TLV)

自上而下的方法在這種方法中，SoC從接口層級的最高層開始驗證，然后繼續(xù)到層級的下一個較低層，直到最小的葉級設(shè)計元素被驗證。傳統(tǒng)上，當SoC設(shè)計有一個或兩個層次時，這種方法被用作驗證計劃。

自底向上的方法

這是設(shè)計驗證中最常用的方法。它從驗證較小的設(shè)計塊開始；驗證小塊是簡單而實用的。此外，在塊級模擬中，查找錯誤并修復(fù)它們更容易。這是因為在較小的設(shè)計中更容易來回跟蹤信號，以便在發(fā)現(xiàn)問題時進行調(diào)試。當多個模塊被驗證時，它們被集成以形成芯片的頂層模塊，這由單獨的頂層測試設(shè)置來驗證。例如，由UART內(nèi)核、USB內(nèi)核和協(xié)議總線接口內(nèi)核組成的SoC中的內(nèi)核首先逐個內(nèi)核進行驗證，然后在芯片頂層進行驗證。平臺級驗證如果設(shè)計是基于標準的，如USB設(shè)備內(nèi)核，最好在安裝了標準對等設(shè)備(如USB主機設(shè)備)的標準平臺上進行驗證。同樣，SPI從內(nèi)核可以在帶有SPI主器件的平臺上進行驗證。這也將確認互操作性問題。基于系統(tǒng)接口級驗證如果SoC基于協(xié)議，則需要通過監(jiān)控對事務(wù)的響應(yīng)，使用標準驗證IP(知識產(chǎn)權(quán))內(nèi)核構(gòu)建驗證設(shè)置。例如，在具有WLAN接入點的環(huán)境中，通過觀察兩者之間的事務(wù)來驗證Wi-Fi設(shè)備核心。WLAN接入點核心是經(jīng)過預(yù)先驗證和確認的標準參考驗證IP。這也證明了制造時內(nèi)核的互操作性。

03、驗證計劃

驗證計劃是描述SoC設(shè)計驗證計劃和流片標準的文檔。它解釋了如何計劃驗證SoC設(shè)計的每個功能。它列出了模塊級和層次結(jié)構(gòu)頂層的驗證目標。它確定了必要的工具，如模擬器、波形查看器和用于驗證的腳本。它明確提到了成功完成驗證的覆蓋標準，作為設(shè)計流片的完成標準。

與SoC設(shè)計相關(guān)的不同驗證覆蓋有：

• 功能覆蓋
• 代碼覆蓋
• 有限狀態(tài)機(FSM)覆蓋

功能覆蓋通過編寫測試用例并設(shè)置模擬要實現(xiàn)的正確設(shè)計響應(yīng)來量化要驗證的功能數(shù)量。有一些工具可以通過測試用例以及功能(特性)列表來測量功能覆蓋率。由于識別功能并輸入到這些工具中是手動完成的，所以為了獲得高覆蓋率，功能的數(shù)量可能會不足。

還有一個通常使用的參數(shù)叫做“代碼覆蓋率”,它決定了在RTL級別的設(shè)計數(shù)據(jù)庫上模擬的測試用例所覆蓋的RTL語句的數(shù)量。這有助于識別設(shè)計數(shù)據(jù)庫中的冗余代碼，并有助于代碼清理。

用于代碼覆蓋的工具也能夠給出測試用例所覆蓋的有限狀態(tài)機狀態(tài)。這是一個非常重要的措施，通過添加適當?shù)臏y試用例來覆蓋所有的狀態(tài)轉(zhuǎn)換。設(shè)計驗證范圍不僅用于評估一些公司的設(shè)計驗證狀態(tài)，還用于評估驗證工程師的表現(xiàn)。

驗證計劃文件根據(jù)設(shè)計范圍列出了設(shè)計驗證完整性的標準。驗證覆蓋率的剩余差距由其他驗證技術(shù)填補，如基于FPGA的驗證、仿真技術(shù)以及在開發(fā)板上測試SoC設(shè)計。例如，如果通過仿真實現(xiàn)的功能覆蓋率是98%，那么剩余的2%是通過將設(shè)計移植到FPGA上并在FPGA板上測試相關(guān)功能或任何其他適當?shù)臏y試技術(shù)來實現(xiàn)的。這些方法可能需要板上和FPGA上的額外電路，以使其成為適合SoC設(shè)計功能驗證的測試設(shè)置。它可能還需要在運行的軟件或與之接口的系統(tǒng)。

驗證計劃中包含的主要設(shè)計細節(jié)如下：

1. SoC設(shè)計首次成功的定義2. SoC的關(guān)鍵應(yīng)用場景。SoC測試對測試環(huán)境開發(fā)的要求3. 功能驗證環(huán)境和所需資源的開發(fā)計劃4. 將在模塊級和設(shè)計層級的頂層驗證的功能特性列表5. 區(qū)塊和頂層設(shè)計的主要驗證策略6. 設(shè)計RTL級別的測試平臺模塊：

• 總線功能模塊(BFM)和總線監(jiān)視器
• 信號監(jiān)視器
• 驗證參考模型

7. FPGA級驗證詳情：

SoC驗證對FPGA板的要求

FPGA驗證平臺需要附加模塊

將根據(jù)這一要求開發(fā)所需的軟件模塊、軟件開發(fā)和調(diào)試平臺

8. 所需的驗證工具和流程9. 對塊級仿真環(huán)境的要求10. 回歸測試環(huán)境和回歸測試計劃11. 確定驗證完成的明確標準，如目標覆蓋率、回歸測試向量的數(shù)量，以及門級模擬策略和期望

設(shè)計資源包括驗證工程師及其技能、硬件開發(fā)板、FPGA板、軟件要求、EDA工具環(huán)境、(工作站和服務(wù)器)模擬器(許可證數(shù)量)以及用于驗證的設(shè)計基礎(chǔ)設(shè)施。驗證VLSI SoC的策略因SoC的設(shè)計復(fù)雜性和使用場景而異。

理想情況下，其目標是使用RTL級測試平臺或FPGA驗證計劃，或使用開發(fā)板設(shè)置，或任意或全部組合，來仿真/模擬用例場景。使用這些資源，驗證SoC設(shè)計，以獲得預(yù)測其成功的高度信心。驗證策略包括子模塊級驗證的設(shè)計劃分和FPGA板上的芯片頂層驗證。

04、功能驗證

功能驗證的目標是確認SoC設(shè)計在功能場景及其應(yīng)用場景中的預(yù)期功能。一個用例場景可以映射到一個或多個功能測試場景。例如，為了驗證模塊的加法功能，可能有三種測試情況:第一種是驗證輸入操作數(shù)，第二種是驗證與輸入相對應(yīng)的輸出結(jié)果，第三種是檢查加法器的進位操作?；旧?，SoC設(shè)計包含不同功能的多個塊，這些塊彼此互連和/或共享總線，多個塊在該總線上交互，或者一個塊按照標準協(xié)議運行。在這種情況下，SoC的功能驗證包括模擬(a)塊到塊接口驗證，(b)總線爭用驗證，以及(c)協(xié)議和符合性驗證。

05、驗證方法

有三種類型的設(shè)計驗證。它們是黑盒、白盒和灰盒驗證。通過采用這些方法的不同組合來驗證SoC設(shè)計。

黑盒驗證

這是一種驗證方法，其中設(shè)計實現(xiàn)的內(nèi)部細節(jié)不會暴露給驗證。通過僅訪問暴露的接口信號而不訪問內(nèi)部狀態(tài)或信號來完成驗證，從而使其實現(xiàn)獨立。顯然，驗證對于設(shè)計的內(nèi)部實現(xiàn)細節(jié)或系統(tǒng)狀態(tài)是不可見的。這種方法最適合發(fā)現(xiàn)解釋級別的問題，如字節(jié)序檢查、協(xié)議誤解和互操作性測試。

白盒驗證

在這種驗證方法中，測試平臺模塊可以訪問設(shè)計的內(nèi)部狀態(tài)、信號和接口。在這種情況下，調(diào)試任何設(shè)計問題都非常容易，因為測試平臺可以根據(jù)預(yù)期跟蹤信號驅(qū)動器。這種方法最適合于檢查低層次的特定于實現(xiàn)的場景和設(shè)計角落，在那里他們可以針對具有潛在問題的場景進行設(shè)計并調(diào)試它們。這種情況的一個例子是FIFO指針翻轉(zhuǎn)、計數(shù)器溢出等。在這種方法中，斷言最適合檢查內(nèi)部設(shè)計行為。這種方法完全是對黑盒驗證方法的補充。

灰盒驗證

這種方法介于黑盒和白盒驗證技術(shù)之間。在這種方法中，測試環(huán)境在接口層驗證系統(tǒng)，在頂層驗證IOs，并根據(jù)需要基本(如設(shè)計角)訪問測試和調(diào)試的設(shè)計內(nèi)部。通常，第一級測試使用黑盒方法作為目標，并評估功能覆蓋率。為了提高覆蓋率，如果需要，通過白盒方法，測試場景被測試。

06、驗證設(shè)計

隨著SoC設(shè)計方法向系統(tǒng)級或架構(gòu)級發(fā)展，在跨子系統(tǒng)的事務(wù)級驗證系統(tǒng)功能至關(guān)重要。然而，SoC設(shè)計主要是集成預(yù)先設(shè)計或預(yù)先驗證的IP核，這更像是內(nèi)部IP的黑盒驗證。此外，復(fù)雜的SoC設(shè)計正趨向于驗證友好，其中內(nèi)部狀態(tài)和關(guān)鍵信號被鎖存，并可供軟件通過主接口讀取，從而預(yù)測問題的根本原因。這在“黑盒”或“灰盒”驗證中很有用。功能驗證在不同的環(huán)境中以不同的方式進行。在RTL級別，開發(fā)了測試平臺和一組測試用例，并使用模擬器進行模擬，以查看SoC是否按預(yù)期運行。通過觀察接口或模塊/塊級輸入和輸出的波形來檢查功能正確性。

在基于FPGA的硬件驗證中，將RTL形式的待測設(shè)計移植到板上的FPGA，運行有限的軟件，將實際激勵饋入SoC輸入，并在開發(fā)環(huán)境中觀察輸出。

在開發(fā)環(huán)境上，基于子模塊的開發(fā)平臺設(shè)計開發(fā)了與最終SoC接近的接口，并用一些更復(fù)雜的軟件進行了驗證。

RTL級別的測試環(huán)境或測試臺代表SoC最有可能使用的環(huán)境。所有的環(huán)境都被開發(fā)來接受盡可能接近真實世界輸入的刺激。典型的RTL試驗環(huán)境(也稱為試驗臺)是一個封閉的系統(tǒng)，因為它代表了一個完整的環(huán)境，包括通過行為總線功能模型(BFM)的輸入刺激和輸出控制。

外圍模塊

這些模塊是在應(yīng)用環(huán)境中完成SoC驗證所需的支持模塊。它們是外圍功能的驗證IP或IP，如外部存儲器、數(shù)據(jù)轉(zhuǎn)換器和實時傳感器模型。輸入激勵和公共功能模型(BFM)輸入激勵代表在實際應(yīng)用場景中被驗證的SoC從外部世界饋入的輸入信號。它可以是系統(tǒng)設(shè)計信號，如來自參考晶振的時鐘、復(fù)位信號、傳感器輸入或來自SoC外部模塊或驗證IP的數(shù)據(jù)輸入。SoC所需的來自不同源的激勵的產(chǎn)生是自動的(當參考時鐘被饋送到PLL模塊時，它自動產(chǎn)生SoC所需頻率的系統(tǒng)時鐘，如所配置的)或半自動的，具有手動觸發(fā)或有條件的。它們通過接口饋入SoC設(shè)計，通過總線功能模型(BFM)遵循設(shè)計的時序要求。

輸出BFM

該輸出BFM通過其輸出接口捕捉特定激勵輸入時SoC的響應(yīng)。將響應(yīng)進行比較并寫入文件，以便與預(yù)期輸出進行比較，或者實時檢查預(yù)期。該模塊或者是具有文件比較功能的檢查器，或者是波形數(shù)據(jù)庫發(fā)生器，而SoC設(shè)計通過測試輸入條件受到特定場景的影響，設(shè)計人員在圖形查看器上查看這些輸入條件并判斷其正確性。

連續(xù)監(jiān)視器

這些是環(huán)境中的附加檢查點，它們是SoC正常運行的指示器。例如，在產(chǎn)生1-s時鐘的定時器SoC中，很容易連續(xù)監(jiān)控1-ms信號，該信號預(yù)計會連續(xù)滴答以產(chǎn)生1-s時鐘。在測試環(huán)境中，測試塊是非常模塊化的，結(jié)果被自動檢查，并作出通過/失敗的決定，因此它們是自動化友好的。測試環(huán)境能夠分析功能、代碼和FSM覆蓋率的設(shè)計。

測試環(huán)境模塊的簡要描述如下。SoC DUT

SoC DUT是待驗證的測試中的SoC設(shè)計。

設(shè)計和驗證斷言

測試中的設(shè)計和驗證測試環(huán)境可以有斷言來提高驗證的有效性。斷言是用于檢查設(shè)計中同步信號的時間關(guān)系以確保模塊正確運行的語句。設(shè)計斷言，如果被支持，由測試工作臺檢查器模塊跟蹤，以查看它是否已經(jīng)被觸發(fā)，并且被評估正確性。例如，考慮邏輯設(shè)計的一部分，其中功能是檢查接收的分組是否正確，并且接收的分組由packet_valid信號驗證。顯而易見，每當產(chǎn)生packet_correct或packet_error信號時，packet_valid信號應(yīng)被設(shè)置為高電平。在這種情況下，寫一個檢查packet_error和packet_valid或packet_correct和packet valid信號同時出現(xiàn)的設(shè)計斷言是有意義的，如果觸發(fā)了該斷言，則可以驗證設(shè)計意圖。在所示的例子中，設(shè)計斷言被寫入以查看packet_valid和packet_correct或packet_valid和packet_error信號是否不同時出現(xiàn)。如果這個斷言被觸發(fā)，那么這個設(shè)計就是有缺陷的。

可以在DUT事務(wù)的事務(wù)級別編寫類似的斷言，并對設(shè)計的正確性進行跟蹤。

時鐘/復(fù)位模塊

時鐘復(fù)位模塊根據(jù)SoC設(shè)計的要求產(chǎn)生所需的時鐘和復(fù)位信號。

配置該模塊將DUT和測試臺設(shè)置為需要測試DUT的配置。

激勵發(fā)生器

該模塊在測試臺中產(chǎn)生輸入激勵。通常，該模塊根據(jù)SoC功能以所需的順序和次序產(chǎn)生信號。這可能是一個復(fù)雜的IP驗證。

總線功能模塊(BFM)

總線功能模塊遵循接口規(guī)范向SoC DUT提供激勵?？偩€接口有多少，BFM就有多少。如果SoC設(shè)計支持UART、USB和PCI Express接口，則應(yīng)該有一個對應(yīng)于這些接口的BFMs來管理符合這些協(xié)議的事務(wù)。

郵筒

這些是系統(tǒng)Verilog測試平臺中的通信機制，允許在進程之間交換消息。希望與另一個進程對話的進程將消息發(fā)送到mailbox，mailbox將消息臨時存儲在系統(tǒng)定義的內(nèi)存對象中，然后將消息傳遞給所需的進程。創(chuàng)建的郵箱具有綁定或未綁定的隊列大小。當綁定郵箱包含的郵件達到定義的最大數(shù)量時，該郵箱就會變滿。試圖將郵件放入已滿郵箱的進程應(yīng)被掛起，直到郵箱隊列中有足夠的可用空間。基本上，郵箱是一種同步不同進程技術(shù)。該過程可以是checker，如本例所示。一旦郵箱有了一組預(yù)定義的消息，它們就可以啟動一個檢查器來檢查內(nèi)容并判斷其正確性。

棋子

Checker檢查所有過程，如將DUT響應(yīng)與預(yù)期、斷言和監(jiān)視器進行比較，以決定測試場景的通過/失敗標準。

測試程序接口(TPI)

這是用戶界面，它接受用戶輸入作為參數(shù)，并編譯選項來觸發(fā)測試場景和執(zhí)行模擬。TPI支持許多帶有可選參數(shù)的命令，以在測試場景中逐個執(zhí)行模擬，并生成合并的結(jié)果。這被稱為回歸測試。

07、驗證示例

在本節(jié)中，我們將介紹一個簡單的十進制計數(shù)器設(shè)計的仿真，以便更好地理解驗證過程。

十進制計數(shù)器的設(shè)計功能:十進制計數(shù)器在時鐘的每個有效邊沿計數(shù)數(shù)字0、1、2、3、4、5、6、7、8、9、0。設(shè)計要求每當計數(shù)器計數(shù)到5時就產(chǎn)生一個輸出信號。

設(shè)計文件保存為decade-counter.v，測試臺文件保存為tb_dcounter.v(。v代表Verilog文件)。為了模擬設(shè)計文件，使用了模擬器。大多數(shù)使用的模擬器是基于循環(huán)的模擬器?；谥芷诘?a href="http://wenjunhu.com/tags/仿真器/" target="_blank">仿真器對信號進行采樣，并在每個時鐘周期計算設(shè)計響應(yīng)。模擬器首先分析RTL代碼，并在模擬設(shè)計之前進行闡述。

執(zhí)行模擬時，觀察終端上顯示的錯誤和警告日志消息。如果有任何錯誤/警告，需要在設(shè)計文件中糾正它們。對于設(shè)計示例中的模塊，不應(yīng)該有任何警告或錯誤，模擬會成功終止。如果您在當前的工作目錄中觀察，會發(fā)現(xiàn)模擬運行生成了許多輸出文件。它們是命令日志文件、名為decade_counter.vcd的波形轉(zhuǎn)儲文件。decade_counter.vcd文件可以用波形查看器工具打開。當在波形查看器工具中打開該文件時，可以觀察到輸入輸出信號和內(nèi)部網(wǎng)絡(luò)的邏輯狀態(tài)變化。有關(guān)運行仿真和使用波形查看器工具的更多信息，可以參考相應(yīng)的用戶手冊。通過觀察設(shè)計信號clock，reset_n和out_5，count_out來驗證設(shè)計行為。

驗證流程可以擴展到任何復(fù)雜程度的設(shè)計。本節(jié)中解釋的下一個設(shè)計示例演示了這一點。闡述了利用擾碼器設(shè)計作為驗證IP的自同步解擾器在測試平臺上的驗證。考慮多項式g(x) = 1 + x13 + x33的自同步擾頻器的設(shè)計。如果輸入數(shù)據(jù)是具有零DC偏移的0或1的長序列，則在通信中使用自同步加擾器模塊來加擾輸入數(shù)據(jù)。在發(fā)送器使用相同的多項式對數(shù)據(jù)進行加擾，并在接收器端使用相同的多項式對數(shù)據(jù)進行解擾以恢復(fù)發(fā)送的原始數(shù)據(jù)。自同步解擾器中解擾器的功能屬性，因為它不需要由初始化向量初始化來實現(xiàn)同步。

加擾器-解擾器的同步被定義為加擾器和解擾器的LFSRs保持相同的模式，因此，當數(shù)據(jù)被饋送到解擾器時，它可以生成加擾器數(shù)據(jù)的輸入。

被測模塊是解擾器。為了測試解擾器是否與加擾器同步，需要將解擾器LFSR重置為任何初始值。隨機模式通過加擾器輸入，加擾后的數(shù)據(jù)作為輸入激勵輸入解擾器。將驗證解擾器在某個時間點將能夠解碼輸入的數(shù)據(jù)。您可能會注意到，測試平臺沒有任何端口，因為這將是一個獨立的測試模塊環(huán)境。

試驗臺由以下部分組成：

測試平臺的第一部分是激勵產(chǎn)生，包括時鐘、復(fù)位、使能和數(shù)據(jù)產(chǎn)生。

第二部分是加擾器模塊，用作標準驗證IP。

第三部分是模塊實例化。

1. 第四部分是輸出讀取器和波形轉(zhuǎn)儲，用于調(diào)試和用戶驗證。

一個典型的SoC測試平臺將具有多個時鐘(OCC)生成模塊和標準PLL、多個所需的VIP，以及控制狀態(tài)機，這些狀態(tài)機將使這些模塊中的每一個能夠用于多種測試場景。輸出讀取器和波形轉(zhuǎn)儲部分可以是復(fù)雜的模塊，可以根據(jù)SoC驗證要求自動驗證功能的正確性。

08、驗證工具

有許多驗證工具可用于SoC設(shè)計的功能驗證。

它們是 : 1. 模擬器

2. 覆蓋工具

在上面列出的工具中，模擬器對于RTL功能驗證是必不可少的。模擬器是一種工具，通過在測試平臺中使用測試向量來理解大多數(shù)預(yù)期用例場景中的設(shè)計行為。它是一個軟件，能夠在用戶提供刺激的情況下，在要求的持續(xù)時間內(nèi)研究SoC設(shè)計狀態(tài)及其輸出，稱為測試向量。有不同類型的模擬器。它們是基于周期的模擬器、基于事件的模擬器和電路模擬器。要模擬的SoC設(shè)計稱為被測器件。模擬器使用測試平臺中的某些命令，可以在模擬期間監(jiān)控和寫出內(nèi)部邏輯電平、設(shè)計模塊中的信號狀態(tài)和輸入輸出。然后，在與圖形調(diào)試環(huán)境交互的波形查看器工具中打開該波形輸出文件?；赟oC設(shè)計的類型，使用不同的仿真器進行驗證?；谥芷诤突谑录哪M器是數(shù)字模擬器。大多數(shù)用于數(shù)字模擬的模擬器是基于循環(huán)的模擬器?；谥芷诘姆抡嫫髟诿總€周期評估設(shè)計的邏輯狀態(tài)。模擬器周期為皮秒或納秒量級，以便為用戶虛擬仿真硬件的并發(fā)行為。上述模擬器都是基于循環(huán)的模擬器。它們被稱為周期精確仿真器，因為它們在時鐘信號的輸入邊沿對SoC設(shè)計進行采樣?；谥芷诘哪M器比基于事件的模擬器快10-100倍，用于大多數(shù)SoC設(shè)計驗證。使用基于周期的模擬器的設(shè)計驗證需要STA分析，因為設(shè)計是以時鐘間隔驗證的。

每當電路中的任何網(wǎng)絡(luò)上發(fā)生邏輯變化時，基于事件的仿真器評估設(shè)計。這些模擬器也稱為定時精確模擬器，適用于小電路級驗證。它們提供了良好的調(diào)試環(huán)境，并且也不需要時序分析，因為在設(shè)計中的所有節(jié)點上的所有事件中，設(shè)計都被功能性地驗證。基于事件的模擬器需要運行模擬的大型計算機器。這是因為當今SoC設(shè)計中的網(wǎng)絡(luò)數(shù)量激增，在仿真過程中會有大量的邏輯轉(zhuǎn)換。監(jiān)控網(wǎng)絡(luò)上的大量邏輯轉(zhuǎn)換并評估它們的所有組合實際上是不可能的。在這樣的設(shè)計中調(diào)試故障是非常困難的。

當今的SoC設(shè)計包括模擬模塊，也需要對其進行驗證。使用模擬仿真器單獨驗證模擬模塊。模擬仿真器使用數(shù)學(xué)模型來表示設(shè)計的模擬功能。它們通過檢測并產(chǎn)生對設(shè)計的適當響應(yīng)來模擬模擬功能。很少有模擬和混合信號模擬器可用。

模擬器通常非常慢，并且不是自動化的。它們要求設(shè)計師很好地理解設(shè)計，并使用工具作為分析設(shè)計的輔助。因此，模擬模塊的詳細驗證是單獨進行的，然后進行模擬-數(shù)字混合信號仿真，只是為了在實踐中驗證集成。另一個用于驗證模擬過程或模塊的重要工具是提取覆蓋率分析器。覆蓋矩陣提供了對設(shè)計數(shù)據(jù)庫驗證的質(zhì)量或完整性的洞察。有三種類型的覆蓋:功能覆蓋、代碼覆蓋和狀態(tài)機覆蓋。通過比較和分析在SoC設(shè)計數(shù)據(jù)庫上運行的測試用例以及SoC設(shè)計的功能特征清單來獲得功能覆蓋。代碼覆蓋率是在SoC設(shè)計上運行仿真以跟蹤設(shè)計中被激發(fā)的代碼行時提取的指標。由于模擬運行中的測試情況，狀態(tài)機覆蓋范圍給出了設(shè)計FSM中狀態(tài)轉(zhuǎn)換的信息。所有這些矩陣都有助于驗證工程師最大化覆蓋度量，從而達到設(shè)計驗證目標。

除了HDL語言的基本語法和語義之外，Lint工具還根據(jù)為不同目標設(shè)置的規(guī)則，在RTL級別檢查SoC設(shè)計。這是一個靜態(tài)的RTL代碼檢查器。它通過編譯設(shè)計并為仿真、綜合和DFT仿真對其進行預(yù)處理來進行檢查。運行l(wèi)int的不同設(shè)計目標是針對仿真、可綜合性和可測試性的RTL設(shè)計的基本編譯。工具為每個目標定義了標準規(guī)則。這些規(guī)則集中的每一個都可以針對SoC特定的設(shè)計目標進行定制或增強。當在設(shè)計文件上執(zhí)行時，這些工具會寫出日志文件，根據(jù)定義的規(guī)則對設(shè)計進行詳細分析，并根據(jù)違規(guī)的嚴重程度對違規(guī)發(fā)出警告和錯誤警報。nLint和HAL是設(shè)計中心使用的少數(shù)幾種已知驗證工具中的兩種。

09、驗證語言

與設(shè)計語言相比，用于建模測試平臺或測試用例的語言更加寬松和靈活。這種靈活性的主要原因是需要在測試用例中創(chuàng)建更多的隨機性，并且這不需要是可合成的。Verilog是最古老的HDL之一，也是驗證語言。由于設(shè)計描述方法在體系結(jié)構(gòu)級別上升到更高的抽象級別，一些驗證語言，如SystemVerilog、Vera和System C，正在成為更高抽象層的主要硬件驗證語言(hvl)。這些語言支持類、面向?qū)ο?、類擴展和時態(tài)屬性，這有助于輕松定義系統(tǒng)級或事務(wù)級測試功能。在提到的語言中，SystemVerilog作為一種強大的斷言語言也越來越受歡迎，這是驗證中的一個主要特性。但它也提供了一些構(gòu)造，旨在確保合成和模擬之間的結(jié)果一致。此外，還有支持這些語言結(jié)構(gòu)的模擬工具，可以解釋結(jié)果，并根據(jù)測試覆蓋率進行分析。它們支持諸如直接編程接口(DPI)之類的接口到諸如C++和Java之類的高級軟件語言，這使得能夠構(gòu)建圖形用戶界面(GUI ),該圖形用戶界面可以使得驗證環(huán)境在更高的抽象級別上更通用和有效，直到層級的系統(tǒng)級別。這些的更多細節(jié)可以在參考文獻中提到的語言書籍中找到。模擬器工具現(xiàn)在足夠智能，可以忽略設(shè)計人員犯下的常見錯誤，并可以通過通知用戶警告來自行糾正錯誤。

10、自動化腳本

為SoC創(chuàng)建用例場景是通過一組具有隨機刺激的復(fù)雜測試用例來實現(xiàn)的，因為實時場景是隨機的。當刺激是隨機的，對這種刺激的反應(yīng)變得難以預(yù)測。因此，測試通常在這種情況下通過預(yù)測最終結(jié)果或狀態(tài)或分析系統(tǒng)的統(tǒng)計數(shù)據(jù)和穩(wěn)定性來進行，并且也在可預(yù)測的系統(tǒng)中間狀態(tài)進行。這需要輸入隨機性和系統(tǒng)狀態(tài)的某種一致性，它們或多或少都在變化。為了映射出這種對應(yīng)關(guān)系，測試用例是自動化的。自動化意味著測試期望，比如數(shù)據(jù)完整性、狀態(tài)，以及將控制移交給下一個隨機場景，被自動控制和評估。這是通過腳本語言實現(xiàn)的。最常用的腳本語言有Perl、Tcl、PHP等。因此，腳本語言是為特殊的運行時環(huán)境編寫的編程語言，這些運行時環(huán)境自動執(zhí)行原本可以由用戶一個接一個執(zhí)行的任務(wù)。EDA工具也理解這些結(jié)構(gòu)，因此可以集成到測試設(shè)置中。自動化也用于分析大數(shù)據(jù)的完整性檢查、統(tǒng)計分析，并批量運行測試用例以獲得期望的功能覆蓋。測試腳本是被解釋的，而不是編譯的。

11、設(shè)計驗證

設(shè)計驗證通過發(fā)現(xiàn)系統(tǒng)設(shè)計和架構(gòu)中的潛在錯誤來保證設(shè)計質(zhì)量。只有盡可能詳盡地模擬系統(tǒng)的所有功能，同時仔細研究任何可能的錯誤行為，才有可能做到這一點。這值得花費最多的時間、注意力和完整的設(shè)計用例知識。在大多數(shù)情況下，如果設(shè)計很復(fù)雜，這可能會變得非常具有挑戰(zhàn)性。這要求設(shè)計是可驗證的。設(shè)計師對功能的設(shè)計實現(xiàn)有完整的理解。如果設(shè)計者確定了設(shè)計的關(guān)鍵設(shè)計角和關(guān)鍵狀態(tài)，則驗證可以有針對性地監(jiān)控和檢查它們。有時在設(shè)計中，某些場景可能需要長時間的模擬運行來達到設(shè)計的極限，而驗證工程師可能不知道這一點。一個簡單的例子是32位計數(shù)器的溢出生成，它運行在一秒鐘的時鐘上。這需要很長時間來模擬，但在實際硬件中可能會很快發(fā)生。在這種情況下，如果設(shè)計人員提供預(yù)加載計數(shù)器的功能，32位計數(shù)器溢出是可行的。這樣的設(shè)計調(diào)整使得設(shè)計可以在更多的場景中得到驗證。設(shè)計師必須確定可以驗證的關(guān)鍵設(shè)計角。此外，系統(tǒng)的非功能特性，如可伸縮性、可擴展性和靈活性，需要額外的設(shè)計支持來驗證。這樣的例子是存儲器地址擴展、以非默認模式通過軟件寫入寄存器或存儲器的訪問、作為可能的錯誤解釋問題(例如小端或大端)的替代提供的額外配置等。

12、驗證中的斷言

在設(shè)計中實現(xiàn)斷言需要有意識地決定以不同的方式來看待設(shè)計過程。這是一個附加的設(shè)計和驗證聲明，用于監(jiān)控這部分設(shè)計的正確性。斷言肯定會減少調(diào)試時間和工作量。斷言本質(zhì)上充當模擬期間的早期警告，可以查明可能直接導(dǎo)致測試失敗或者未被通過的測試檢測到的故障。模塊接口上的斷言可以快速識別可能由行為模型或設(shè)計的不當使用(無效寄存器設(shè)置、無效操作模式等)引起的無效行為。).這種斷言失敗表明測試平臺可能存在問題，這有助于驗證工程師修復(fù)測試平臺中的問題。它有助于解決設(shè)計中的問題。設(shè)計斷言通過查看失敗所顯示的不正確的功能來幫助定位失敗的根本原因。例如，約束隨機模擬檢測FIFO操作的溢出和下溢處的設(shè)計角處的設(shè)計問題，這些問題通常不是定向測試的目標。FIFO接口信號上的簡單斷言檢測同時的讀和寫操作、讀的數(shù)量超過寫的數(shù)量等。將有助于在測試場景中找到實際失敗的根本原因，而無需冗長的調(diào)試會話。斷言更大的優(yōu)勢在于，它通過保留設(shè)計和驗證所有者之外的設(shè)計意圖，使設(shè)計和驗證測試平臺可重用。

13、驗證重用和驗證IP

就像可重復(fù)使用的設(shè)計模塊一樣，驗證模塊也可以在各代SoC設(shè)計中重復(fù)使用。由于多個接口協(xié)議模塊是SoC的一部分，如一些具有多個USB內(nèi)核、多個SPI內(nèi)核和多個UART內(nèi)核的SoC，相應(yīng)的測試模塊可以在測試臺中重用。測試平臺中的總線接口模塊(BFM)和接口內(nèi)核甚至可以用來驗證具有相同功能的SOC的數(shù)量。這也將解決上市時間縮短和設(shè)計生產(chǎn)率差距的問題。隨著SoC功能變得越來越復(fù)雜，許多集成內(nèi)核符合許多標準并需要具有互操作性，在過去幾十年中，這些模塊被開發(fā)為參考模型，以確保符合標準規(guī)范。這些被稱為驗證IP。這些都經(jīng)過預(yù)先驗證或認證，符合標準或協(xié)議規(guī)范。這些可以被許可，或者從知識產(chǎn)權(quán)開發(fā)者那里購買。這些VIP作為標準IP集成到測試環(huán)境中，SoC根據(jù)驗證IP進行測試，以證明合規(guī)性和互操作性。驗證IP的重用是SoC驗證中的常見做法

14、通用驗證方法(UVM)

通用驗證方法(UVM)是一種行業(yè)標準驗證方法，用于定義、重用和改進驗證環(huán)境，并降低驗證成本。它為驗證環(huán)境中的基本類庫(BSL)組件的使用提供了某些應(yīng)用編程接口(API ),使它們可重用且獨立于工具?；赨VM的驗證環(huán)境對于各種類型的測試創(chuàng)建、覆蓋分析和重用是足夠靈活的。UVM標準化提高了互操作性，降低了重新購買的成本，并且采用了為每個新的SoC設(shè)計或驗證工具重寫知識產(chǎn)權(quán)(IP ),以便更容易地重用驗證組件?？傮w而言，UVM標準化將降低整個行業(yè)的驗證成本并提高設(shè)計質(zhì)量。更重要的是，它可以使用復(fù)雜SoC設(shè)計驗證中最常用的SystemVerilog來實現(xiàn)。

15、缺陷和調(diào)試

bug是系統(tǒng)中的缺陷。SoC設(shè)計的質(zhì)量直接取決于其中隱藏的缺陷或錯誤。如前所述，較高設(shè)計或開發(fā)階段(RTL、物理設(shè)計、布局、芯片、電路板、系統(tǒng)、現(xiàn)場系統(tǒng))的測試成本至少比較低設(shè)計或開發(fā)階段的測試成本高十倍。在早期設(shè)計/開發(fā)階段發(fā)現(xiàn)缺陷或錯誤是明智的。Bug是特定場景中不需要的狀態(tài)或條件。它可以是暫時的，也可以是永久的。這可能是由多種原因造成的。最主要的原因是設(shè)計者沒有能力按照預(yù)期來解釋需求(參考圖中關(guān)于需求解釋問題的著名的tree swing例子),以及大量隱含的、未聲明的需求。由于驗證人員對系統(tǒng)需求的解釋以及他為整個用例場景創(chuàng)建測試用例的能力，設(shè)計缺陷也可能滲透進來。也可能是因為在設(shè)計階段用于進行設(shè)計轉(zhuǎn)換的人為錯誤和工具錯誤。在設(shè)計和開發(fā)階段或在現(xiàn)場，正式記錄和管理bug是很重要的，這樣bug就可以被修復(fù)，不會反復(fù)出現(xiàn)。

作者：鄭威，TüV北德功能安全總監(jiān)