近期，芯華章正式發(fā)布了基于創(chuàng)新架構(gòu)的數(shù)字驗證調(diào)試系統(tǒng)——昭曉Fusion Debug?。在研討會暨新產(chǎn)品發(fā)布會上，中興微電子有線系統(tǒng)部部長賀志強、平頭哥上海半導(dǎo)體技術(shù)IP驗證及軟硬協(xié)同驗證負責人張?zhí)旆?、燧原科技資深架構(gòu)師鮑敏祺，與芯華章科技產(chǎn)品和市場戰(zhàn)略總監(jiān)黃武，通過圓桌對話的方式，圍繞當前集成電路驗證挑戰(zhàn)及未來EDA發(fā)展趨勢，展開了一場精彩交流。

對話中，三位嘉賓均從不同角度指出：

伴隨集成度的增加，芯片設(shè)計日益復(fù)雜，系統(tǒng)級、場景級驗證需求不斷增加，系統(tǒng)級芯片驗證，對提升流片成功率，賦能芯片設(shè)計創(chuàng)新意義重大，也在其中扮演愈發(fā)重要的角色。但是，工具兼容性差、數(shù)據(jù)碎片化、工具缺乏創(chuàng)新等痛點，也在限制著EDA的進一步發(fā)展。

良好的調(diào)試工具，對于提升復(fù)雜驗證效率有重要作用，是非常關(guān)鍵的驗證手段。業(yè)界認為一款優(yōu)秀的調(diào)試工具，需要具備高效的性能、可開放的接口、支持圖形化呈現(xiàn)等特質(zhì)。

展望未來，國產(chǎn)EDA優(yōu)勢在于沒有歷史包袱、創(chuàng)新以及貼近用戶。下一代EDA設(shè)計以及驗證工具，需要加強流程的自動化及智能化，建立統(tǒng)一標準，提供更好的兼容性，從而全面提升驗證效率及精度。

以下為嘉賓對話實錄，經(jīng)編輯整理，我們將分為“挑戰(zhàn)篇”、“調(diào)試篇”、“展望篇”三期，以饗讀者，本篇為挑戰(zhàn)篇。

挑戰(zhàn)篇：驗完了沒有？

黃武：目前前端驗證發(fā)展了20~30年，大家認為在做 SoC設(shè)計驗證的時候，最大的難點和挑戰(zhàn)在什么地方？

鮑敏祺：

首先，芯片的設(shè)計現(xiàn)在逐漸從10、12納米走到了7納米，特別是在AI芯片領(lǐng)域，它會變得越來越大，我們可能已經(jīng)超過50億門，甚至更多比如說像M1最新一代ultra的話，它已經(jīng)超過了1100億個晶體管。

伴隨著激烈的市場競爭，還會壓縮開發(fā)周期。以往，這樣一個大芯片通常需要一年半的時間完成，而現(xiàn)在我們可能需要壓縮到一個更短的時間。因此，如何完成更多功能驗證的工作，成為一個非常大的挑戰(zhàn)。

另外一個挑戰(zhàn)是：隨著芯片的增大，它不僅是在功能上的驗證，就像之前在做的一些功耗相關(guān)的驗證；現(xiàn)在驗證的問題更多的是要伴隨場景，去看整體power analysis、信號完整性等這樣一個驗證的工作。這對于整個驗證來說，就從一個單純的功能需求，轉(zhuǎn)變?yōu)檎麄€系統(tǒng)級、場景級的驗證的需求。

賀志強：

我想在座的鮑總、張總、包括黃武，相信作為驗證團隊的負責人，可能會經(jīng)常被問到兩個問題，第一個就是“你驗完了沒有”，第二個問題就是“芯片還存不存在bug”。這兩個問題雖然字數(shù)不多，但我覺得都是直擊靈魂的一個拷問。其實如何回答這兩個問題，我覺得應(yīng)該是驗證工作最大的難點和挑戰(zhàn)。

我們都知道驗證是一個證偽非證明的過程，我們能夠證明是有bug的，但是卻很難證明沒有bug，但是項目組可不接受這樣的回答。

隨著芯片規(guī)模的越來越大，復(fù)雜度也不斷提升，芯片的一版成功其實也成為了我們的最低要求。驗證不僅在質(zhì)量上，還要在挑戰(zhàn)的時間窗內(nèi)去完成這個工作，應(yīng)該說肉體和靈魂都在雙重的折磨下。但是，我們還是要給予正面的回答，因此對驗證效率、驗證質(zhì)量的度量就非常的有必要，也很重要。

那么我們，對于質(zhì)量的度量，對于效率的度量，其實又是一個問號。

這些度量里面，我相信有一些是主觀的數(shù)據(jù)，有些是客觀的數(shù)據(jù)，在各種數(shù)據(jù)之間如何佐證不同的流程、不同的方法，以及不同的工具之間又如何關(guān)聯(lián)，這個是留給驗證的問題，那也是給我們EDA廠家的問題。

希望我們未來的EDA廠家，像芯華章一樣能夠聚焦在驗證的痛點，跟著客戶一起，不僅在工具上提供更高性能更好用的工具，同時也把我們的痛點的解決方案能夠固化到流程里，沉淀到我們的經(jīng)驗里，最后集成到我們的工具里。

黃武：EDA工具很多時候都是一個集成的過程，有很多工具也是EDA公司不斷收購來的，這導(dǎo)致的一個問題就是這些工具之間數(shù)據(jù)的交互很多時候存在兼容性的問題。大家對工具導(dǎo)致的數(shù)據(jù)不統(tǒng)一的問題，有沒有什么看法？

鮑敏祺：

工具不統(tǒng)一，這個問題的確存在于很多領(lǐng)域。

比如舉個最簡單例子，關(guān)于覆蓋率。如果說有一個仿真驗證、有一個形式驗證的情況下，按照以前的流程，它是兩個完全獨立的體系。因為對于原型驗證來說，我可能看的是一個logic code，就是邏輯錐，但對于功能級的話，它看的code coverage或者是一個功能，是由他們自己去標定的。

這樣的話其實我們很多的功能驗證，已經(jīng)在形式驗證這頭覆蓋了，但是這兩個如果沒有融合的話，你會發(fā)現(xiàn)一邊覆蓋率很低，但是另外一邊也不知道。只是說因為形式驗證一般都是做的相對小的模塊，所以如果兩邊不能融合，就會帶來一個相對比較大的困難。

另外，其實我們現(xiàn)在整個芯片里面，其實不光是simulation，后面還有emulation，prototype，兩者的覆蓋率范圍怎么能夠合理地反標到前級，其實是對于前面的整個SoC sign-off會起到一個非常積極的作用。再則，對于Low power，它其實就是對UPF的理解，包括simulation工具也好，synthesis工具也好，它們的解析可能都會有一些不一致。一致性check，其實是一個非常重要的東西。

賀志強：

我覺得我們在驗證過程中經(jīng)常會遇到這些問題，因為數(shù)據(jù)的兼容性其實可以分成兩方面：第一方面就是我們不同的EDA廠家的工具的一個兼容性問題；第二個其實是我們自家工具的不同的驗證手段的兼容性。

目前我們可能用的比較多的simulation、formal這一塊，那么我們同一家的手段是不是能夠把我們的數(shù)據(jù)、把我們的覆蓋率信息能夠合并到一起，而不是孤立地去看我們的驗證工作的輸出，包括像emulation和prototyping的一些驗證手段的一些信息能不能集成進來。其實我覺得對于同一家工具，這個應(yīng)該是能夠去解決，沒有太多的技術(shù)壁壘，但是對于不同廠家的工具，它的解析、格式，實際上我覺得在過去30年，我們EDA工具被國外壟斷的這樣情況下，是很難做到統(tǒng)一的。數(shù)據(jù)的一些不兼容，其實給用戶帶來的體驗感也不是很好。

就像我們舉個例子，我們現(xiàn)在用的這種手機充電線也一樣，我們現(xiàn)在有Type-C的、還有蘋果的一些接口，那么目前看到的一些趨勢可能像安卓，它有趨向Type-C的統(tǒng)一，但是要和蘋果去統(tǒng)一，我覺得還是挺難的。那么像現(xiàn)在比較火的一個行業(yè)就是電動汽車，汽車從充電口來看的話，其實它一開始從規(guī)劃我覺得不管是哪一家的電動汽車，它的充電口慢充快充都是一樣的，其實這樣帶來的好處我覺得是不言而喻的。

回到EDA工具，其實從用戶的角度，是希望我們不同的工具之間，它的數(shù)據(jù)能夠兼容，能夠去解析，能夠提供一些API的接口，包括我們的覆蓋率信息能夠合并，這樣對我們的驗證效率的提升就存在更多的可能性。

我相信這是未來的趨勢，當然也需要一些國產(chǎn)EDA的崛起，驅(qū)動業(yè)界的改變。

黃武：驗證在芯片設(shè)計中時間消耗越來越大，那怎么樣通過一種方式高效量化判斷芯片驗證是處于收斂的趨勢？

賀志強：

這個問題其實我覺得還是挺難回答的，關(guān)于如何判斷我們驗證的效率和質(zhì)量，如何判斷我的驗證已經(jīng)收斂了，這個確實是驗證工程師一直在持續(xù)去做的一件事情。

那么首先我們說驗證效率，效率其實它直接影響到我們一個研發(fā)周期的長短，對于咱們芯片的流片以及芯片的商用，其實是起到了一個很關(guān)鍵的作用。

那么效率的提升或者說我們代碼的收斂，它不能單單的只看效率，我們所有的效率是在質(zhì)量的前提下去談效率才有意義。

那么效率的影響的因素有很多，從整個芯片的研發(fā)流程來看，包括我們方案的一些繼承性、前端代碼的一些IP化，包括我們驗證平臺的通用以及驗證用例的復(fù)用程度，其實都是效率提升的一些關(guān)鍵因素，但是驗證效率或者說我們代碼收斂，我覺得應(yīng)該是沒有一個直接的或者說單一的度量指標。

那么剛才提到的像一些覆蓋率，像assertion，包括formal，包括其他的驗證手段，我所有的這些指標它應(yīng)該是綜合的來去判斷我驗證是不是收斂的過程。

單純從效率來看的話，我覺得可以從幾點去看，第一個就是我們平臺的一個搭建周期，我是不是能夠快速地去復(fù)用我的平臺、用例的調(diào)試周期；其次，當然我們最經(jīng)常會關(guān)注到的就是用例的一些圖、增長曲線以及回歸周期，這是從過程來看的一些數(shù)據(jù)。

那么從驗證結(jié)果來看，我覺得還有一些bug的趨勢、覆蓋率的一些覆蓋情況，包括我們的驗證周期的綜合指標，來度量驗證效率和收斂情況。

所以這個問題我覺得還是挺難回答，當然不是說不能回答，比如我們現(xiàn)在業(yè)界有很多的方法，我覺得哪一種方法其實對于我們做驗證的質(zhì)量和效率來看的話都是有意義的，是要統(tǒng)籌或者說要去從整體上去考慮，而不是單單的一個指標。

張?zhí)旆牛?/p>

對于驗證，一般我們都會根據(jù)架構(gòu)和設(shè)計的規(guī)格制定驗證的策略，就是說在我們現(xiàn)有的資源下，這個資源既包括人力的資源，當然也包括EDA的資源，還包括時間的資源，用什么樣的驗證方法和方案，能夠在我們可以接受的風險度下達成質(zhì)量目標，讓芯片回來一版成功。

我覺得這是非常值得探討的一個課題，里面有非常多值得深挖的一些地方，無論是數(shù)據(jù)，還是經(jīng)驗，還是決策點等等。實際上我覺得在業(yè)界里面都很值得探討——我們有了這么多方法學，我們有了這么多數(shù)據(jù)，我們跑了這么多測試，最后我們的情況到底是怎么樣？

當然我們有很多的方法學可以使用，從DDV（Direct-test Driven Verification）到CDV（Coverage Driven Verification）再到MDV （Metric Driven Verification） ，那么我們到底應(yīng)該把它們用在什么地方？

實際上，我們知道現(xiàn)在有這么多的芯片的業(yè)務(wù)形態(tài)，這么多的產(chǎn)品特征，那么實際上每一類DUT的驗證策略都不盡相同。一般的做法可能是說對于unit level或者是某些比較小規(guī)模的，我們可能會考慮引入一些形式驗證的方法去把它做到充分的覆蓋。

那么對于block level的驗證，我們可能傾向于業(yè)界現(xiàn)在比較通用的，基于UVM的MDV的這種方法學。通過功能覆蓋率以及代碼覆蓋率這兩個重要指標，然后以及各家公司都可能定義的非常完備的質(zhì)量流程和check list，去保障研發(fā)質(zhì)量，降低風險。

那么對于sub system、IP level等規(guī)模比較大、較為復(fù)雜的DUT的驗證，從UVM角度一般會采用自底向上集成的方式，關(guān)注點一般會集中在各個block之間的interaction。此外，對于sub-system level和IP level的代碼覆蓋率策略，如果block level代碼覆蓋率已在checklist中，SS和IP level會重點關(guān)注各個sub-block以及自身的boundary toggle coverage。

而對于SoC level，斷言覆蓋率或者是必要的功能覆蓋率一般都會納入考量。

總之驗證策略（包括覆蓋率策略）、驗證測試計劃（包括功能覆蓋率計劃）都是驗證工作中非常重要的部分。我們?nèi)绾斡眠m配的方法學在現(xiàn)有的人力、EDA資源和時間資源的條件下，能夠達到什么樣的質(zhì)量標準并能承受怎樣的風險，然后做到一次流片成功，我覺得是個很值得探討的問題。