對許多人來說，LSI、VLSI這些名詞，已如同真空管這個名詞一般走入了歷史。現在的IC設計這個領域，大家朗朗上口的都是SoC(System-on-Chip)、Embedded CPU、Embedded Memory這些名詞。隨著IC設計愈趨於複雜，驗證工作也如惡夢般地困擾著工程師們。本文主要探討在SoC的設計中，驗證工作所必須面對的問題與解決的方法。

RTL階段為成敗關鍵

由於邏輯合成工具和自動佈局繞線工具的使用，使得整個IC設計流程變得非常順暢。只要RTL階段的設計驗證工作能確實無誤，完全合乎規格書所規範的功能，那麼整個設計個案幾乎可以說已經完成了一大半。根據相關的研究數據，目前多數的IC設計個案中，RTL階段的設計驗證工作佔了整個設計流程約60%～80%左右的時間；而且絕大多數的資源也都放在設計驗證工作上，會造成如此大的比重不外乎是由於IC越設計越大和Embedded IP core的使用。

IC設計更複雜化

IC越設計越大，設計者需要驗證的功能也越來越多；加上各式各樣不同領域的應用規格、資料管理、網路、無線通訊，使得IC的規格也越來越複雜。目前IC設計工程師所面對的設計複雜度是10年前的100倍以上，雖然有邏輯合成工具來加速設計工作，但是如惡夢般的驗證工作卻依然尚未自動化。

面對千奇百怪的應用規格，IC設計工程師無法利用現有的硬體描述語言或程式語言，去開發其Testbench在檢查工作上；而必須靠人工的方式，去分析判斷模擬結果的資料與時序是否與規格書一致。最重要的是，沒有相關的數據讓IC設計工程師瞭解功能驗證的涵蓋率是否足夠？規格書中的所有功能是否都有達成？一些Corner Case是否有考慮到？甚至對於Error Case來說，IC設計工程師的設計是否反應得宜？所以如何將白紙黑字的規格書轉變成IC，不僅要做的對，也要做的完全；這是科學，也是藝術。

Embedded IP Core的應用

再來是Embedded IP Core的使用。這些IP Core也許是舊設計的延用，也許是由IP供應商提供；但無論如何，這些IP Core對IC設計工程師來說都是一個比較難以摸索，難以掌握的部分。因為它們未曾在目前的系統應用環境中被驗證過，當這些IP Core包含在整個SoC設計中時，增加了設計驗證工作的困難，因為當設計模擬有問題時，IC設計工程師很難去判斷到底是自己本身新的設計有問題？新的設計與IP Core之間的介面有問題？抑或是IP Core本身就有Bug？

工作界線模糊

另外一個造成設計驗證工作無法順利完成的原因是，"設計工作"與"驗證工作"的分工問題。有些公司基於人力問題的考量，往往是設計工程師兼驗證工程師，工程師根據規格書去完成設計工作。同一個工程師同時完成TestBench去驗證自己的設計，試想如果這位設計工程師對規格書內的某一條規格有所誤解(尤其是用英文寫成的規格書)，造成他的設計和TestBench都是錯的，但模擬的結果卻是合乎他的"預期"，於是一個有問題的IC就流出去了，解決這個問題的方法只有將"設計工作"與"驗證工作"真正分工。目前已經有些IC設計公司開始實施這樣的分工，由驗證工程師開發TestBench去驗證設計工程師的RTL設計，如此才不會造成有球員兼裁判的盲點。

IC設計流程改革重點

關於之前所提到的設計複雜度越來越高的問題，IC設計工程師不能再仰賴傳統的方法，必須要朝三個功能去改善：

更自動化的方式開發TestBench(Automatic Testbench Generation)，模擬過程自動檢查相關資料、時序---(Data Protocal Checking)，自動收集並分析功能涵蓋資訊(Functional Coverage Information)。

有了這三個改善功能的主要好處是，開發TestBench自動化後，驗證工作的生產力便提昇了。有了功能涵蓋資訊，IC設計工程師很容易知道那些功能沒有被驗證到，並加以改進，則IC驗證的品質便有所保證。而要解決驗證工作的困難，IC設計工程師就必須了解，開發TestBench是一件專門的工作，不再是附屬於設計工作旁的一個小環節。

如同當初的邏輯合成和自動佈局繞線一般，開發TestBench也必須要自動化，並往高階描述語言方向發展。高階描述語言的好處在於其可讀性，有利於不同之間的流通，維護上也比較容易。至於要使用何種高階描述語言來開發TestBench？Verilog HDL和VHDL有其不足之處，所以很多設計工程師才會使用像C、C++之類的程式語言去開發TestBench。

當然，有些EDA公司認為必須要新開發一種專門描述TestBench的高階語言。像最近才在美國NASDAQ公開上市的EDA公司「Verisity」，便提出了一個非常適合描述TestBench的高階語言"e-Lanuage"。並且將部分語法Donate給OVI這個組織，期望能使"e"更通行於IC設計領域。

至於Embedded IP Core對於驗證工作的影響，有些IP供應商的解決方式便是將Interface Protocal Checking和Functional Coverage的功能內含在此IP Core的Model中。當驗證工程師在模擬整個SoC設計時，便很容易得知新的設計與IP Core之間的介面是否有問題？由功能涵蓋率(Function Coverage)的資料，我們也可以判斷模擬工作是否足夠？那些功能沒有驗證到？

例如ARM就提供了ACT(AMBA Compliance Testbench)的功能。ARM是全世界IP core的主要供應商之一，該公司也提出了一套用於SoC內部資料匯流排的標準介面AMBA。為了確保ARM的客戶在開發AMBA相關的周邊元件時，不會有相容性不合的問題。ARM與Verisity合作，將Interface Protocal Checking和Functional Coverage的功能包含在內，如此當設計工程師在使用ARM的IP core時，就更容易掌握。

結論

最後必須強調的一點是，在SoC的領域中，驗證工作的份量絕對不比設計工作還要來得輕鬆。因為IP Core的大量被使用，新的設計其所佔的比例可能變得很小；但是要驗證的卻會是整個系統的整合部分，其複雜度可想而知。因此，驗證工作的自動化和驗證品質的提昇，當然是目前IC設計流程的改革重點。(本文作者任職於茂積電子)