（文章來源：中國電工儀器儀表信息網）

在當今競爭激烈的形勢下，使富含嵌入式軟件的復雜電子設備更快面市，但是同時確保其更便宜更可靠，是一種相當冒險的做法。未經徹底測試的硬件設計不可避免地導致返工，增加設計成本并延長布局流程的網表交付時間，并最終延遲上市時間目標，對收益源造成破壞性影響。推遲嵌入式軟件的測試也潛藏有錯過上市機遇的可能，會帶來更嚴重的后果。

正因為如此，項目周期的驗證部分極大地占用計劃時間變成了很常見的事情。其中的根本塬因，在于跟蹤和消除錯誤極為不易，尤其是在片上系統 （SoC） 的軟件內容以每年約 200% 的速度增長的情況下。與此相反，設計的硬件部分僅增長約 50%。

過去，硬件調試和測試是項目周期驗證部分的唯一工作，此作業由硬件描述語言 （HDL） 測試平臺驅動的邏輯軟件仿真進行管理。傳統的大箱式硬件仿真只用于最大型的設計。很多開發團隊已采用正式驗證對軟件仿真進行補充，以增加基礎覆蓋范圍并確保不遺漏特殊用例。但是，只有硬件仿真可以在比較可行的時間內完成 SoC 設計的全部驗證任務，并緩解與基于事件的軟件仿真相關的運行問題。

SoC 的軟件內容使協同驗證成為驗證策略中一個非常重要的部分，因為它可以在投片前確認一個嵌入式 SoC 的硬件和軟件部分同時得到驗證且正確交互。過去，如果設計流片后發生硬件問題，軟件開發者必須盡其所能設法圍繞問題進行編碼。在 SoC 完成之前驗證軟件，設計團隊可以在進入硅片階段之前解決硬件問題。如前所述，硬件仿真檢查用于確保嵌入式軟件根據規范在硬件上運行。

過去使用各種調試引擎進行軟件調試。每種引擎有一個核心，充分利用硬件對處理器內部工作的可視性和控制功能。雖然提供了部分調試功能，但由于處理器提供的接入方式，診斷問題的能力受限。此外，由于傳統軟件調試通常發生在實際系統中，軟件開發者以目標系統速度在實際硬件上執行實際代碼。這樣他們可以通過大量代碼迅速找到錯誤的程序。

這些傳統技術在調試 SoC 時無效，因為沒有實際硬件，無法以真實系統速度執行代碼。一般來說，只要執行代碼且軟件模擬器提供所有硬件可視性，即可仿真硬件。但問題是速度 - 調試代碼是很慢的一種方法。例如，如果 SoC 設計為在 Linux 上運行程序，軟件開發者必須以數十億時鐘周期完成 Linux 啟動，軟件才能開始執行。粗略估計這會以約 10 赫茲 （Hz） 的典型軟件仿真速度花費 28 年以上完成 Linux 啟動。

不管調試硬件還是軟件，傳統硬件和軟件調試工具都無法得知彼此的任何情況。如果采用復雜的大型 SoC 設計，嘗試找到問題時獨立完成兩種調試是效率低下的。兩者結合是最為理想的方法，這樣硬件仿真就可以節約時間。SoC 硬件通常在 FPGA 或其他可編程器件中實施，速度更快。在此設置中，根據運行速度，最快可以 15 分鐘的速度完成 Linux 啟動。硬件仿真可提供與硬件調試器相似的斷點和波形控制及可視性。

硬件仿真以其高性能（這是軟件需求推動的越來越重要的需求）在一眾驗證工具中脫穎而出。它能夠確認 SoC 設計按計劃工作，并適于處理大到十億 ASIC 等效門的復雜設計，且每月可完成超過一萬億驗證周期。即使是這樣，現階段使用硬件仿真進行徹底詳盡的功能驗證仍然是可用的最具成本效益且有效的調試方法。

引入事務級建模 （TLM） 和事務處理器可用性可將硬件仿真轉為一系列垂直市場的虛擬平臺測試環境。事務處理器作為驗證知識產權 （IP） 組合的一部分，是外設功能或協議的一種高級抽象模型。事務處理器通常作為現成 IP 提供，可用于各種不同的協議。典型的事務處理器通常包括 PCIe、USB、FireWire、Ethernet、Digital Video、RGB、HDMI、I2C、UART 和 JTAG 器件。

先前，硬件設計獨立于要在芯片上執行的軟件的開發。但今非昔比，由于 SoC 處理器數量翻倍且每代產品包含兩倍的軟件內容，軟件問題成為開發團隊和項目經理優先考慮的對象。現在，開發團隊證實預期軟件在硬件平臺正常工作后，SoC 才算完整。

SoC 是一個全面的嵌入式系統，需要進行硬件仿真來驗證其能否正常工作。通過硬件仿真，開發團隊可以更策略性地進行計劃，并根據多個抽象層面實施調試方法。他們可以同時在硬件和嵌入式軟件之間追蹤錯誤，確定問題所在。通過具有更高性價比且有效的方式，他們在這個過程中節約了時間，大幅降低錯過上市機遇的風險。

（責任編輯：fqj）