前 言

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

01

驗證的重要性

//

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

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

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

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

1

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

2

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

3

由于SoC設計涉及到使用EDA工具對數據庫進行一系列轉換，因此有必要驗證這些轉換是否正確實現，這需要通過驗證來完成。

02

驗證計劃和策略

//

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

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

在系統層面，識別所有場景也是非常具有挑戰性的。這可能是因為無法預測和可視化用例場景本身，或者可能是因為環境中需要更多的模型或模塊來實現它。它可以是完整的軟件堆棧，也可以是移植整個設計數據庫的硬件平臺，或者是用于仿真的計算系統基礎設施。因此，需要將可實現的場景定義為驗證測試環境和一組測試用例，作為預芯片驗證的范圍。這可以通過多種方式實現:

自上而下的方法

自下而上的方法

平臺級驗證

系統級或交易級驗證(TLV)

自上而下的方法

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

自底向上的方法

這是設計驗證中最常用的方法。它從驗證較小的設計塊開始；驗證小塊是簡單而實用的。此外，在塊級模擬中，查找錯誤并修復它們更容易。這是因為在較小的設計中更容易來回跟蹤信號，以便在發現問題時進行調試。當多個模塊被驗證時，它們被集成以形成芯片的頂層模塊，這由單獨的頂層測試設置來驗證。例如，由UART內核、USB內核和協議總線接口內核組成的SoC中的內核首先逐個內核進行驗證，然后在芯片頂層進行驗證。

平臺級驗證

如果設計是基于標準的，如USB設備內核，最好在安裝了標準對等設備(如USB主機設備)的標準平臺上進行驗證。同樣，SPI從內核可以在帶有SPI主器件的平臺上進行驗證。這也將確認互操作性問題。

基于系統接口級驗證

如果SoC基于協議，則需要通過監控對事務的響應，使用標準驗證IP(知識產權)內核構建驗證設置。例如，在具有WLAN接入點的環境中，通過觀察兩者之間的事務來驗證Wi-Fi設備核心。WLAN接入點核心是經過預先驗證和確認的標準參考驗證IP。這也證明了制造時內核的互操作性。

03

驗證計劃

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

與SoC設計相關的不同驗證覆蓋有：

功能覆蓋

代碼覆蓋

有限狀態機(FSM)覆蓋

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

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

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

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

驗證計劃中包含的主要設計細節如下:

1. SoC設計首次成功的定義

2. SoC的關鍵應用場景。SoC測試對測試環境開發的要求

3. 功能驗證環境和所需資源的開發計劃

4. 將在模塊級和設計層級的頂層驗證的功能特性列表

5. 區塊和頂層設計的主要驗證策略

6. 設計RTL級別的測試平臺模塊:

總線功能模塊(BFM)和總線監視器

信號監視器

驗證參考模型

7. FPGA級驗證詳情:

SoC驗證對FPGA板的要求

FPGA驗證平臺需要附加模塊

將根據這一要求開發所需的軟件模塊、軟件開發和調試平臺

8. 所需的驗證工具和流程

9. 對塊級仿真環境的要求

10. 回歸測試環境和回歸測試計劃

11. 確定驗證完成的明確標準，如目標覆蓋率、回歸測試向量的數量，以及門級模擬策略和期望

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

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

04

功能驗證

//

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

05

驗證方法

//

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

黑盒驗證

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

白盒驗證

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

灰盒驗證

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

06

驗證設計

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

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

在開發環境上，基于子模塊的開發平臺設計開發了與最終SoC接近的接口，并用一些更復雜的軟件進行了驗證。

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

外圍模塊

這些模塊是在應用環境中完成SoC驗證所需的支持模塊。它們是外圍功能的驗證IP或IP，如外部存儲器、數據轉換器和實時傳感器模型。

輸入激勵和公共功能模型(BFM)

輸入激勵代表在實際應用場景中被驗證的SoC從外部世界饋入的輸入信號。它可以是系統設計信號，如來自參考晶振的時鐘、復位信號、傳感器輸入或來自SoC外部模塊或驗證IP的數據輸入。SoC所需的來自不同源的激勵的產生是自動的(當參考時鐘被饋送到PLL模塊時，它自動產生SoC所需頻率的系統時鐘，如所配置的)或半自動的，具有手動觸發或有條件的。它們通過接口饋入SoC設計，通過總線功能模型(BFM)遵循設計的時序要求。

輸出BFM

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

連續監視器

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

測試環境模塊的簡要描述如下。

SoC DUT

SoC DUT是待驗證的測試中的SoC設計。

設計和驗證斷言

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

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

時鐘/復位模塊

時鐘復位模塊根據SoC設計的要求產生所需的時鐘和復位信號。

配置

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

激勵發生器

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

總線功能模塊(BFM)

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

郵筒

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

棋子

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

測試程序接口(TPI)

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

07

驗證示例

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

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

設計文件保存為decade-counter.v，測試臺文件保存為tb_dcounter.v(。v代表Verilog文件)。為了模擬設計文件，使用了模擬器。大多數使用的模擬器是基于循環的模擬器。基于周期的仿真器對信號進行采樣，并在每個時鐘周期計算設計響應。模擬器首先分析RTL代碼，并在模擬設計之前進行闡述。

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

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

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

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

試驗臺由以下部分組成:

1

測試平臺的第一部分是激勵產生，包括時鐘、復位、使能和數據產生。

2

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

3

第三部分是模塊實例化。

4

第四部分是輸出讀取器和波形轉儲，用于調試和用戶驗證。

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

08

驗證工具

//

有許多驗證工具可用于SoC設計的功能驗證。它們是 :

1

模擬器

2

覆蓋工具。

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

每當電路中的任何網絡上發生邏輯變化時，基于事件的仿真器評估設計。這些模擬器也稱為定時精確模擬器，適用于小電路級驗證。它們提供了良好的調試環境，并且也不需要時序分析，因為在設計中的所有節點上的所有事件中，設計都被功能性地驗證?；谑录哪M器需要運行模擬的大型計算機器。這是因為當今SoC設計中的網絡數量激增，在仿真過程中會有大量的邏輯轉換。監控網絡上的大量邏輯轉換并評估它們的所有組合實際上是不可能的。在這樣的設計中調試故障是非常困難的。

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

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

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

09

驗證語言

//

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

10

自動化腳本

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

11

設計驗證

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

12

驗證中的斷言

//

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

13

驗證重用和驗證IP

//

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

14

通用驗證方法(UVM)

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

15

缺陷和調試

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

責任編輯：彭菁