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

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

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

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

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

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

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

* 操作系統(tǒng)已經完成引導了嗎？

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

* 為什么設備的驅動器不能正確處理數(shù)據(jù)？

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

作者:Alain Raynaud

技術總監(jiān)

EVE公司