驗證復雜的SoC設計要耗費極大的成本和時間。據證實，驗證一個設計所需的時間會隨著設計大小的增加而成倍增加。在過去的幾年中，出現了很多的技術和工具，使驗證工程師可以用它們來處理這類問題。但是，這些技術中很多基于動態仿真，并依靠電路操作來發現設計問題，因此設計者仍面臨為設計創建激勵的問題。

　　設計者可以使用運行在處理器上的固件作為驗證仿真激勵的一部分，這也是目前通常采用的方法——使用全功能處理器模型。與在HDL中編寫激勵相比，固件作為激勵速度更快，并且更容易創建。在一個全功能處理器模型上執行代碼的缺點是模型運行較慢，因此只有少量軟件會使用這個技術執行。很多固件執行由取指令操作和內存讀寫周期組成，驗證價值很低。在邏輯仿真器中屏蔽這些低價值操作，而繼續執行寄存器和內存映射I/O周期，可以在最低限度減少驗證覆蓋率的同時，顯著提高執行速度。

　　在仿真環境中能夠更快速地執行代碼主要有兩個好處。首先，快速仿真意味著功能驗證仿真可以使用更多的代碼。診斷程序、驅動程序、固件以及某些情況下部分應用程序代碼都可用于驗證問題。其次，因為仿真運行速度加快，因此能夠執行更多的驗證。很多設計者會選擇運行附加測試，而不是運行較少的CPU仿真時間。大多數驗證都受到能夠用于運行仿真的CPU時間的限制。如果固件用來作為驗證的一部分，它將對設計起推動作用。這個激勵將是切合實際的，它通過典型的操作使設計得到測試。為設計創建激勵的挑戰之一是如何估算出典型的設計操作，并將其在測試平臺上編碼。使用實際的軟件可為驗證工程師排除這個問題。但是，運行作為測試平臺的代碼不可能提供大量激勵，特別是不能覆蓋大部分驗證空間。因此，設計者需要使用其它的技術提供額外激勵，以遍歷設計的所有邊界情況。

　　設計者使用傳統的直接測試和其它驗證技術能夠增加用固件作激勵源的情況。內存分區可用于過濾仿真過程中不必要的總線周期，從而提高性能。本文將介紹一個設計實例，使用作為激勵的代碼和基于斷言的驗證，通過該實例來描述使用傳統驗證技術無法發現的設計錯誤。

　　解決驗證挑戰

　　目前，電子工程師面臨的驗證挑戰不斷加劇。為了更好地闡明這些挑戰，本文中介紹了一個簡單的實例。該實例是一個在250×250像素矩陣上顯示RGB數值的圖形輸出設備。它包括一個映射到處理器的寄存器接口。相關寄存器有：“行”—包含待描繪像素行地址信息的一個8位寄存器：“列”—包含待描繪像素列地址信息的一個8位寄存器：“像素”：——包含待描繪像素RGB值的一個8位寄存器：“大小”——包含待描繪像素矩形大小的一個8位寄存器（其中1表示寫入單個像素，2表示描繪一個2×2的正方形，以此類推最大值為16）：“狀態”——能夠讀取和返回設備狀態信息的一個8位寄存器。

　　使用直接測試

　　驗證此樣本設備的第一步是測試所有行和列是否正確定址。要測試所有大小的像素是否能夠被寫入，還要測試不同顏色值的代表樣點。典型的像素組合也要被測試，如從右上方像素立刻變換為左下方像素。使用類似的方法可測試所有角對組合。還應該測試各種組合中有序和無序增減的行地址和列地址。所有這些測試可以通過編寫和編譯一個運行在全功能處理器模型上的簡單程序來完成，或者使用一個產生總線周期和BFM的簡單測試平臺。另外還要考慮測試那些可能影響設計的異常條件。測試時可將行地址或列地址設置為一個大于249的值，或是定義一個大小超過硬件支持的像素。

　　這些都是在接口級完成的明顯測試，在內部結構進行的類似驗證測試和在接口級實現的驗證策略是很類似的。顯然，要測試整個驗證空間，即使只是一個設計模塊的接口，也不可能像前述的樣本設備一樣簡單。可能的操作是250行×250列×224色×16大小，或16.7×1016.所有操作的組合數是這個數值的平方，或大于1034.這里真正的挑戰是創建那些能夠揭露設計問題的組合，并將這些問題標識為需要立刻關注的區方面。

　　使用斷言揭露早期問題

　　由于對設計驅動了激勵，因此斷言可以及早發現問題。要添加的斷言包括不能超過249（行地址和列地址的最大可能值）的行地址和列地址，以及不能超過16的大小字段。確定斷言并采用HDL覆蓋分析后，需要對設計驅動激勵。這可以通過約束隨機測試實現。約束隨機測試產生反饋到測試平臺的設備處理事務，表明被識別的測試點已被覆蓋。如果設計空間非常大，約束隨機測試就不能包含測試點沒有覆蓋的邊界條件。這種測試不用創建使用HDL覆蓋工具達到100%覆蓋的激勵。但是，在設計中遍歷所有狀態并覆蓋所有條件并不能保證設備被完全驗證。

　　軟件代碼作為激勵

　　對于一個超過1034個組合的驗證空間來說，讓實際的設備操作執行所有必需組合是不太可能的。應當把重點放在設備會運行的那些操作上，對那些理論上可能不會使用的操作要減少花費時間。最簡單快捷的方法是找到可驅動設備的現有代碼。這可能是診斷代碼，驅動程序代碼或應用程序級算法。每個這樣的代碼均提供了不同的驗證級別，并揭露了不同類型的問題，因此，應當嘗試獲得和使用所有類型的代碼。

　　對于新的設計，代碼很可能不存在，但對于下一代產品的設計，一些代碼常常可以得到。如果這些代碼存在，設計的激勵在幾乎不耗費精力或成本的情況下就可以得到。如果代碼不存在，但合作方愿意在設計周期前期創建代碼，那么也可以輕松地創建激勵。最后，如果驗證團隊需要創建代碼，通過編寫C代碼來為設計創建復雜多樣的激勵比使用任何其它語言都更容易。

　　假設顯示

　　使用假設顯示，需要運行描繪各種測試模式和色彩組合的診斷代碼以確保連接。也可以運行驅動程序代碼，它可以連接至一個簡單的畫圖應用程序，該應用程序可使用一些代表樣本的像素將驅動程序調整至適當位置。最后，采用最終使用這個設備的應用程序，并畫出幾幅圖像。每種類型的代碼會以不同的方式運用設計，從而能發現利用其他方法時不容易檢測到的問題。

　　硬件/軟件協同驗證

　　很多硬件和驗證工程師（甚至在某些方面軟件工程師）認為，運行應用程序的任何部分不會加快設計驗證。畢竟，如果針對設備測試驅動程序，并針對驅動程序測試了應用程序，就無需進行進一步驗證。但是這些工程師不會考慮在尚未系統地測試所有軟件的情況下發布產品，也不會接受在未經系統測試的情況下發布要去tapeou的硬件設計。系統級協同驗證測試全部的可選組件，包括硬件、軟件、或兩者的組合，從而揭露在分離情況下不會被發現的問題。