目前在視頻芯片領域，H.264標準和高清電視都很熱門，這些芯片的設計人員需要完成數百次一致性數據流仿真，才能確保芯片可以出貨。在無線手持終端市場，固件則是關鍵。最終器件需要引導Linux系統並在LCD屏幕上運行Java應用程序。網絡路由的設計人員需要通過偽隨機交通加大芯片的負荷，從而得到像丟包率這些關鍵性能參數的基準。

所有這些任務都有一個共同點：他們需要數十億次的仿真循環。隻要設計人員認識到，他或者她無法像其他那些仿真那樣管理數十億次循環時，他們的情況就像撞到了牆，我把這種情況稱為“十億次循環挑戰。”

當然，第一個挑戰就是運行十億次仿真循環需要多長時間。對平均規模的設計來說，寄存器傳輸級（RTL）仿真需要大約10天的量級。如果在RTL代碼上修改一條連線，並且需要重新運行所有的測試來保証沒有問題，那麼所需的耗時就很不切實際了。花費幾分鐘倒還可以，難道不是這樣嗎？

第二個挑戰是在這麼多次循環中保持芯片繁忙所需的帶寬。讓我們用一個可以實時處理3 gigabit數據的HDTV芯片來做例子。如果設計團隊有十天時間用於十億次仿真循環，測試平台隻需要向該設計提供約10 kbit的數據--這是一個合理的數目。這也是為什麼每個人都容易忘掉帶寬的原因。如果目標是在幾分鐘內完成仿真，那就意味著向設計提供200 megabit量級的數據。要移動這樣量級的數據需要特殊種類的測試平台。

第三個挑戰是調試。設計人員如何在十億次循環中進行查找呢？如果，僅僅是一種可能，在像快速信號數據庫（FSDB）這樣的壓縮格式中進行完全RTL級追蹤，將會佔用硬盤上4 terabyte的數據。隻是從快速硬盤上讀取文件就需要數天時間。完全的數據查詢也同樣是不可能的。

跟房地產行業一樣，答案就是“位置，位置，位置。”設計人員希望能在不同的抽象層次之間進行查找。嵌入式軟件處在最高層，而可能產生問題的級別包括：

* 操作系統已經完成引導了嗎？

* 進程是否卡在某個中斷處理中？

* 為什麼設備的驅動器不能正確處理數據？

一旦設計人員完成了定位--在較高層次--發生問題的地方，他或她就可以開始對這個區域進行放大，並進入較低的抽象層次。接著可以在監控、檢查和斷言的幫助下縮小問題的范圍並跟蹤出可能的根源。隻有在設計人員在這兩個級別檢查了所有的信息之後，他們才可以進入信號級別，並獲得已完成識別的某段RTL波形。在不同抽象層次之間查找問題的能力，也就是從軟件開始逐漸進入硬件的過程，可以避免在大量的仿真中迷失方向。隻有同時解決了上述三個挑戰，設計團隊才算真正克服了“十億次循環挑戰。”

技術總監

EVE公司

Alain Raynaud