在與數百位ASIC設計人員進行了長達數年的驗證策略討論之后,我終于醒悟了:我們正處在一個設計人員需要管理數十億次仿真循環的階段。

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

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

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

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

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

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

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

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

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

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

作者:Alain Raynaud

技術總監

EVE公司