在製造設計IC的整個流程中，無論是廠商或工程師最不願聽到的一件事，應該是把設計好的IC Tap out出去，而回來的Test Chip 卻不能動作；這樣的結果對IC設計公司來說，將是計劃經費的無形增加、產品的上市時程（Time To Market）被延後，對計劃的參與人和設計工程師來說，也將是信譽的受損與沉重的負擔。

據一份統計研究報告指出，IC Tap out回來的晶片如果無法正常運作，大致可分為邏輯或功能上的錯誤、Timing問題、IC製造上的問題以及其他問題，而一顆IC回來不能正常動作，有時會同時有兩個以上的Bug，例如同時有Timing以及功能不正確的問題，由(圖一)的統計結果可以看到，在邏輯或功能上的錯誤竟然佔了74％左右，這一個高得嚇人的比率的確值得大家深思。

《圖一　IC／ASIC首次投片失敗主因比率》

系統驗證的重要性與困難

事實上邏輯或功能上的錯誤大部分是可以被避免的，而避免這個問題的方法不外乎就是做驗證（verification）。驗證在字面上看起來簡單，卻是在整個設計IC的流程中最不被重視，也往往被認為是最麻煩、最無聊的一項任務，但它卻佔了74％的Tap out fail，也是IC無法動作的主嫌，其原因大概有以下幾項：

1.系統驗證的工作需要太多的系統應用經驗

換一個專案就換一個應用方案，因此永遠有K不完的系統應用規格和做不完的驗證工作，事實上光是以一個手機的晶片來說，其驗證系統若真要架起來大概會要人命，如果再加一些周邊的應用介面，可想而知難度有多高。

2.背負重大責任卻沒成就感

做系統驗證的工程師如果沒有把功能完整驗證，其下場是背負驗證不完全、導致IC 功能錯誤的罪名，就算把IC的功能完整驗證，IC Tap out 成功的功勞卻只有IC 設計工程師而已，是IC 設計工程師把IC做的那麼完美，而驗證工程師只有苦勞。

3.大多數系統驗證工程師不被上級主管所重視

大多的主管還是停留在早期的IC的研發觀念，認為只要有IC 設計工程師就可以把IC做好、做出來。

4.IC的Gate Count越來越大，動輒數百萬門邏輯閘

在早期，IC設計公司能做的Gate Count並不大、功能也有限，但在現今SoC的趨勢之下，IP隨處可尋，數百萬門邏輯閘的IC設計也成為大多數公司的領域，當IC的Gate Count大到某一程度，其驗證工作也隨之複雜且困難。

(圖二)正說明若要做好驗證工作，當Gate Count慢慢增加，而軟體要測的情況以及測試向量卻是成指數成長，此時如果IC Gate Count到達一兩百萬，若還要用以前的驗證方法，已經不切實際了。(圖三)則說明了IC Gate Count增加對工作站模擬速度的影響，此時工作站也只能驗證單個模組的測試，無法執行整個IC的驗證，往往許多設計工作分開來測都沒問題，但整合在一起就發生了問題，這種情況實在值得深思。然而系統面需要數顆大型FPGA來組合驗證，不管在FPGA的分割、編譯時間、除錯環境及Probing Signal 都是大問題；因此大型Gate Count的IC功能驗證的確是一個挑戰。

《圖二　IC Gate Count的增加與測試向量的暴增》

《圖三　Design Size對工作站及Emulator的Performance影響》

新一代的系統驗證解決方案

針對以上諸多技術面的問題，其癥結在於沒有一個很好的驗證平台以及解決方案，來解決IC Gate Count太大、驗證環境不容易建立，以及模擬的速度太慢的問題，要解決這些難題，必須採用新一代的解決方案，以下將以Cadence的Palladium系統驗證工具為例，提出各項可行的驗證新技術。

CPU Base Emulator的技術及方法

Quickturn本身在早期就有兩種實現模擬器（Emulator）的技術，一種為被廣泛使用的FPGA架構，另一種則為CPU的架構，由於在早期CPU的時脈速度比較慢，因此CPU架構的Emulator在運行速度方面比FPGA架構的模擬器來得慢，但到了這幾年，整個局勢已經慢慢的改變了，原因是在客戶的設計Gate Count越來越大，模擬器要求的速度依然不變，雖然單獨一顆FPGA已經可以做到很大的Gate Count，但是它的接腳卻無法隨著Gate Count的增加而變多，這個特性要應用在模擬器確實有其困難，因為模擬器要求的是在除錯的時候，每一點的信號都必須能看得到，然而接腳數目不夠，內部的信號就無法送到記憶體，以便儲存偵錯時所需要看到的波形，此時FPGA便需要以多工的方式把信號送到IC外的記憶體，使用這個方法模擬器的速度會因此而大幅降低，更糟糕的是FPGA 架構的模擬器需要花非常久的時間做編譯，而且編譯時常常會發生Timing以及Clock處理的問題，導致不是需要重編譯就是編譯的結果運作不正常。

而Palladium為CPU Base Emulator帶來的創新技術包括：

較快速的編譯時間（Compile Time）

使用模擬器有一個產能的觀念，那就是使用這一台機器需要花多少時間才可以幫使用者找到設計的錯誤，這個時間應該是編譯時間、模擬時間與除錯時間的總合；當使用者找到錯誤並修正設計之後，必須把設計重新編譯一次再來驗證修改是否正確，而如果以一個4M的設計來說，在一般的FPGA Compile時間大約需要20個小時，而Palladium卻只需１個小時。

Full vision，讓Design中每一點都看得到

設計者在使用除錯工具時，首求是穩定及正確性，再來應該像是在用軟體工具一樣，設計中的每一個點都必須要看得到；當使用者Debug到一半想要加入新的信號時，不需要再花冗長的時間做重編譯。

RTL Debug，並保留RTL信號名稱

在Debug時Palladium可以做RTL Debug，不再只是看一堆看不懂的Netlist節點名稱，Palladium Compile時會保留RTL的原始信號名稱，讓設計者不會為了核對信號名稱而找了老半天，(圖四)為Palladium搭配整合互動式Source Debugger畫面。

《圖四　Palladium RTL Debug 環境》

讓多位使用者同時工作

一台模擬器的投資是可觀的，由於每一家公司的專案隨時在變，不太可能只是為了一個專案而購買一台機器，在成本效益來說並不高，然而站在客戶的角度來看，如何提高機台的使用率，也就相對的等於提高了機台的成本效益。Palladium提供Multi User功能，讓多位使用者能夠同時使用一台機器來提高機器的成本效益；Palladium所謂的Multi User Mode是指：在同一個時間只要機台的資源還沒有被用完，就可以有第二個人以上連到Palladium放入不同的設計工作，各自做不同的專案除錯，各個專案不限定要使用在Simulation Acceleration 或是In Circuit Emulation模式。以一台16M ASIC gate的機台來說，最多可以有16個人同時使用一台機器。

以事件為基礎的模擬加速功能

面對現在的設計容量越來越大，設計者要監看的信號也越趨大量與複雜，使用事件基礎驗證（Transaction Base Verification）是提高設計者效率的方法之一；舉例來說，現在的設計大多包含有CPU，而這個CPU也可能同時被使用在不同的專案中，每當設計者要監看CPU對某一個裝置或記憶體做讀寫時，設計者要一一核對位址、資料、控制信號，而如果使用事件基礎驗證，將這些重複核對的動作交給電腦來處理，把每一組發出的信號類似一個封包，一些細部的控制信號交由工作站檢查，而設計者只需要關心CPU發出的資料是否被周邊裝置收到了，工作站並以類似封包的方式顯示出來，讓使用者更容易且清楚的看出一組匯流排上的狀態。事件基礎驗證的功能當然不僅於此，不論對重新使用以及封包間的相對關係等，都有強大的功能，當Palladium操作在Simulation模式下時，當然就可以配合NC-Sim達到事件基礎的模擬加速，在這個模式下的速度不但比傳統的方式快且有效率，其速度大約每秒最快可以達執行約20KHz。

工作排程（Jobs scheduling）

在前面有提到所謂的機台使用率，如果一台事件基礎驗證有辦法24小時工作的話那使用率絕對是無庸置疑的，然而要提高機台的使用率的困難點是工程師並沒有24小時輪班，關於這點Palladium可以提供工作排程（Jobs scheduling）讓工程師只要在回家前把需模擬的程式排班起來，隔天早上回來上班的時候，結果就已經在工作站的硬碟中了。

Save and Restore

@內文;使用者可以把模擬器停下來並把狀態儲存到硬碟，操作在模擬加速（Simulation Acceleration）模式可以隨時中斷工作，方便使用者把時間做有效的安排，而使用在ICE模式亦可以跳過初始化動作以及重複性的測試或工作，利用這個功能可以讓模擬器適時釋放出來讓別人使用。

模擬速度與垂直解決方案

一台模擬器需要因應使用者不同的需求，而把功能做得非常強大，也為了達到使用者的需求模擬器的整個運行速度通常約1MHz左右，因為速度的關係有許多周邊的設計並無法正常的動作，例如影像（NTSC、PAL）信號、PCI、AGP介面、Ethernet網路介面等，這些信號介面的速度轉換對於第一次使用模擬器的人來說是一個很大的門檻，Palladium提供各種應用的橋接介面，不論是連接Gigabits Ethernet或是ARM、PCI等都有現成的解決方案。

接近真實世界的驗證趨勢

隨著業界趨勢發展的腳步，SoC以及IP的發展已經儼然成為兵家必爭之地，如果能夠有效率適當的使用模擬器，相信這一定能讓Design House如虎添翼般的順利完成這個夢想，試想IP將會由什麼型態呈現？RTL code， Netlist 還是Test Chip？這些都有可能，而只要是可合成（Synthesizable）的就能放到模擬器內部，又只要是能接硬體的那就可以以IP子板的方式，插到IP Rack內部與設計案做驗證，再以SoC的角度來看，完整的系統驗證該是包含軟體、硬體以及韌體，以最接近真實世界的方式來驗證才是一個好的驗證方法。

（作者為Cadence益華電腦資深技術工程師）