ASIC設(shè)計何時停止驗證 FPGA和ASIC之間的驗證差異分析

根據(jù)威爾遜研究集團和西門子EDA的數(shù)據(jù)，即使在EDA工具的研發(fā)上花費了數(shù)十億美元，在驗證人工上又花費了數(shù)百億美元，但只有30%到50%的ASIC設(shè)計是第一次正確的。

即便如此，這些設(shè)計仍然有bug。只是它們的災(zāi)難性還不足以導(dǎo)致重新旋轉(zhuǎn)。這意味著需要更高效的驗證。在此之前，驗證團隊繼續(xù)用各種方式的刺激來挑戰(zhàn)設(shè)計。但并沒有一個確切的科學(xué)方法來表明何時停止驗證。

重旋在很多層面上都會造成痛苦。在28納米上的重旋可能會增加50萬美元的新掩模成本，而在較小幾何尺寸上的重旋可能會花費100萬美元。還有就是失去目標(biāo)市場的問題。如果一家芯片制造商服務(wù)的是一個價值數(shù)十億美元的市場，而在一個只有24個月的產(chǎn)品生命周期中卻晚了3個月，損失的收入可能是毀滅性的。但何時停止并不總是顯而易見的。

“要想讓驗證被認(rèn)為是完整的，首先必須對驗證覆蓋率有一個堅實的理解，”O(jiān)neSpin Solutions公司設(shè)計驗證解決方案產(chǎn)品經(jīng)理Nicolae Tusinschi說?！叭绻恢莉炞C中是否或在哪里存在差距，就很難達(dá)到IC完整性標(biāo)準(zhǔn)，也就是確保設(shè)計按預(yù)期操作，是安全、可信和可靠的。如果沒有精確的覆蓋率分析，你就無法放心地達(dá)到簽收。需要的是快速、精確地衡量進(jìn)度和覆蓋率的提高?！?/p>

根據(jù)開發(fā)人員在生態(tài)系統(tǒng)中的位置，驗證任務(wù)因不同程度的挑戰(zhàn)而變得更加復(fù)雜。“如果你是一家設(shè)計硅片、封裝、電路板、系統(tǒng)和軟件的系統(tǒng)公司，你實際上可以奢侈地完全控制，”Cadence的產(chǎn)品營銷總監(jiān)Michael Young說?！暗窍胂笠幌?，你是博通公司的客戶，或者你正在設(shè)計某款芯片，該芯片裝在插入計算機主板的PCIe卡中。要了解系統(tǒng)方案是非常困難的。為了降低風(fēng)險，以及重新旋轉(zhuǎn)的成本，以及發(fā)現(xiàn)客戶的bug，左移的概念已經(jīng)開始發(fā)揮作用。所有過去在硬件層面做的活動都被轉(zhuǎn)移到硬件/軟件中。而這種硬件/軟件的開發(fā)是在SoC層面進(jìn)行的，SoC的開發(fā)也在盡可能早的進(jìn)行。這里的挑戰(zhàn)是，仿真器并沒有像過去那樣提供同樣的速度提升，所以很多人都在左移仿真或原型系統(tǒng)來做額外的工作，并將更多的工作量轉(zhuǎn)移到驗證上?！?/p>

這需要對需要驗證的內(nèi)容有一個清晰的認(rèn)識?！澳阒荒芏x和驗證你能指定的東西，”Young說?！澳悴荒苤付ǖ臇|西是會殺死你的東西。一旦你開始規(guī)范，如果你做得不對--或者你的設(shè)備必須生活在一個不受你控制的外國環(huán)境中--你的風(fēng)險就會高很多?！?/p>

圖1：以系統(tǒng)為中心的SoC視圖。來源：Cadence

什么時候能完成？

那么，在驗證一個芯片或一個子系統(tǒng)或一個封裝時，“完成 ”究竟意味著什么？

“如今，采用功能和代碼覆蓋是必須的--你必須擁有它，而且你必須投資于它，”Vtool的CEO Hagai Arbel說。“越來越多的公司都在這樣做，并且相當(dāng)嚴(yán)格地遵循它，然而第一次正確的芯片的比例卻在下降。如果你檢查那些有bug或bug嚴(yán)重到需要重新打磨的芯片，他們遵循了驗證中‘完成’的最先進(jìn)定義，即功能覆蓋率和代碼覆蓋率100%。你會看到不少這樣的情況。這意味著它沒有幫助?！?/p>

Arbel說，事實上，即使在功能覆蓋率達(dá)到100%，代碼覆蓋率達(dá)到100%之后，高技能的驗證工程師也會發(fā)現(xiàn)關(guān)鍵的bug?！八麄兪侨绾伟l(fā)現(xiàn)它們的？他們怎么知道100%的覆蓋率它是不夠的？每個優(yōu)秀的驗證工程師都會產(chǎn)生這樣的預(yù)感：‘它說是覆蓋了，但我不放心。我覺得有些東西不對勁’。真正優(yōu)秀的驗證工程師對此有某種第六感。他們就是知道。而如果你是一個非常優(yōu)秀的驗證經(jīng)理，你就會對別人的驗證產(chǎn)生這種感覺。如果你回顧一下覆蓋面，我不是說它不重要。但是還不能確定，甚至還不能接近。除了代碼覆蓋率和功能覆蓋率之外，還應(yīng)該考慮其他指標(biāo)，比如驗證工作的質(zhì)量。不過，你做這些事情能有多安全呢？有些公司確實在努力解決這個問題。有些公司已經(jīng)設(shè)法制定了更好的流程和內(nèi)部流程，但作為EDA行業(yè)，我們甚至還沒有提供一個足夠好的解決方案。這里面有巨大的機會，我們要努力把記錄信息和做出結(jié)論的方法正式化?！?/p>

歸結(jié)到本質(zhì)，驗證是一項風(fēng)險管理工作?！叭绻憧纯?a target="_blank">FPGA和ASIC之間的差異，以及他們對待驗證的方式，從風(fēng)險管理的角度來看，你開始明白為什么他們對待事情的方式不同，”西門子EDA的IC驗證解決方案營銷總監(jiān)Neil Hand說?！霸贔PGA中，他們承擔(dān)更多的風(fēng)險，因為他們可以在事后修復(fù)它，而在ASIC中，你不能。因此，如果你開始把驗證看成是一項風(fēng)險管理工作，它就不再是一個何時完成的問題，因為你永遠(yuǎn)不可能完成。那么問題就變成了，”我什么時候達(dá)到了我的風(fēng)險承受能力？什么時候我已經(jīng)到了我覺得可以放心地簽下這個設(shè)計的地步？“

可以幫助的是擁有數(shù)據(jù)和工具來更快地完成覆蓋?！蹦阌懈采w率，這是今天很多人衡量風(fēng)險的方式，但覆蓋率不是全部，“Hand說?！蹦憧赡苡懈采w面的漏洞。你可能沒有定義覆蓋范圍?？赡苡泻芏嗖罹唷５绻幸惶啄愣x的指標(biāo)，你可以根據(jù)這些指標(biāo)進(jìn)行衡量。另外，可以利用工具和技術(shù)來確定這些指標(biāo)是否良好。你可以有一個覆蓋方法論，你已經(jīng)定義了1000個覆蓋點。你擊中了這1000個覆蓋點，但這1000個覆蓋點只擊中了你設(shè)計的10%。那么你的風(fēng)險暴露是什么？“

這些都是必須要解決的問題。但這并不是那么簡單。定義風(fēng)險邊界是一個移動的目標(biāo)，因為它取決于設(shè)計，以及該設(shè)計在系統(tǒng)內(nèi)的背景和與其他系統(tǒng)的交互。

”有一個權(quán)衡，但對于每個芯片來說，它是不同的，“他說?！笨山邮艿娘L(fēng)險對于每個設(shè)計都會不同。你要做的是給工具，不管是通過驗證管理、需求管理、覆蓋率可追溯性，還是通過機器學(xué)習(xí)，了解你看了什么與沒看什么。當(dāng)我們在某一個領(lǐng)域看的時候，我們往往會變得盲目。我們沒有看到右肩上那個準(zhǔn)備撲過來的怪物。我們可以利用機器學(xué)習(xí)技術(shù)來識別你做的都是正確的事情，但那個怪物還在那里?！?/p>

這在異構(gòu)系統(tǒng)中尤其如此，隨著摩爾定律的耗盡，異構(gòu)系統(tǒng)越來越常見。這迫使設(shè)計團隊使用新的架構(gòu)作為各種應(yīng)用和市場的差異化因素。這既為定制加速器打開了大門，也推動了RISC-V的部分發(fā)展勢頭。但這也使設(shè)計變得更加復(fù)雜，更難驗證。

”我們在使用開源內(nèi)核的設(shè)計中看到了這一點，其中有我們以前從未見過的新的角落案例，“Aldec的營銷總監(jiān)Louie de Luna說?！彬炞C也是如此。我們看到了新的UVM用例，我們也發(fā)現(xiàn)了很多錯誤?！?/p>

De Luna指出，這也推動了很多相關(guān)的活動，比如虛擬建模和多核調(diào)試。實際上，工程師們正在利用一切可以利用的東西來應(yīng)對不斷上升的復(fù)雜性。

不像聽起來那么簡單

雖然這其中的大部分都取決于設(shè)計和用例，但也有越來越多的共識，即驗證需要是一個連續(xù)的過程，而不僅僅是設(shè)計流程中的一個單一步驟。

”這個問題的一個非常簡單的答案是，‘當(dāng)你證明設(shè)計沒有任何缺陷時，驗證就完成了’，“Valtrix系統(tǒng)公司首席執(zhí)行官Shubhodeep Roy Choudhury說?！边@時你就可以稱你的驗證完成了。但這是一個NP硬問題，永遠(yuǎn)也做不完。你有空間。測試的數(shù)量和覆蓋率是無限的，所以從技術(shù)上講，你永遠(yuǎn)無法真正完成你的驗證活動?！?/p>

還有一些其他因素需要考慮?！蹦惚仨毚_保功率和性能目標(biāo)得到滿足，并且你的最終用例向你設(shè)計的東西是按預(yù)期工作的，“Roy Choudhury說?！逼渲幸恍?biāo)準(zhǔn)可以用來判斷驗證已經(jīng)接近完成，比如當(dāng)你擁有所有的代碼，代碼覆蓋率和功能覆蓋率都達(dá)到了你的設(shè)計和驗證團隊可以接受的數(shù)字。通常情況下，所有這些設(shè)計都是在你已經(jīng)有的一些以前的設(shè)計之上的迭代，所以從驗證的角度來看，很多努力都花在了開發(fā)測試上，這些測試行使了設(shè)計三角洲，以及新功能與舊功能的交互。這意味著要花費大量的精力來編寫測試。你需要確保這些測試按照預(yù)期工作，沒有任何故障或失敗。你需要優(yōu)秀的驗證工程師來判斷是否滿足了意圖，以及設(shè)計是否按照預(yù)期進(jìn)行。有一些活動，比如在設(shè)計的某些部分，你可以應(yīng)用形式化模型，得到設(shè)計真的沒有任何缺陷的證明，也可以在任何可以應(yīng)用的地方使用?！?/p>

這可以一步步來?！痹诠δ茯炞C中，只要我們被要求驗證一個功能，一切都要從測試規(guī)劃開始?！八f?！币虼?，我們確定了設(shè)計中的不同變化，然后我們創(chuàng)建了數(shù)百個場景，這些場景是確保特定功能按照預(yù)期工作所需的。然后，我們在設(shè)計還沒出來之前，就會花一些時間來編寫測試，確保它們在虛擬模型或功能準(zhǔn)確的模擬器上工作正常。一旦測試人員準(zhǔn)備好，設(shè)計可用，我們就會讓它運行，并盡量確保沒有故障。在程序接近尾聲的時候，通常，設(shè)計錯誤率可以作為一個很好的指標(biāo)來衡量整體驗證的情況。當(dāng)你要完成整個驗證任務(wù)的時候，它會趨于平穩(wěn)?！?/p>

所有這些都必須與功能和代碼覆蓋工具相配合。每次新版本的設(shè)計，通常都會有涉及代碼和功能覆蓋分析的階段，以確保所有預(yù)期的方案都能被擊中。這些都是用來確保設(shè)計得到驗證的指標(biāo)。

這里的另一個考慮因素是決定衡量什么，以及如何衡量。Imperas軟件公司的首席執(zhí)行官Simon Davidmann以最近的一個RISC-V項目為例指出?！蔽覀儎倓偤蚈penHW集團一起參與了一個32位RISC核的項目，首先發(fā)生的一件事就是寫了一個測試計劃，說‘這些是設(shè)計中已經(jīng)測試好的位子，這些是新的位子，這些是我們擔(dān)心的位子，而這些位子可能有一些隱藏在翅膀上的東西，我們并不知道。他們提出了測試計劃，投入了資源，可以說，’這一點的設(shè)計我們要用定向測試，對于這一點我們要用隨機。對于這一點我們要用異步和比較測試，對于這一點其實我們要用正式的來測試東西如何進(jìn)入和退出調(diào)試模式，這在傳統(tǒng)上是相當(dāng)難的事情。你基本上要看你所面臨的設(shè)計挑戰(zhàn)，然后計算出你知道什么，不知道什么，以及風(fēng)險是什么。我必須達(dá)到什么水平才會對 “足夠好 ”感到滿意，因為你無法證明沒有bug？你只能說它足夠好，可以出貨?！?/p>

知識共享

Vtool的Arbel說，另一個障礙是如何與其他團隊成員分享，這是整個設(shè)計和驗證過程中的一個重要方面?！蓖ǔＧ闆r下，不止一個人參與。我是一名驗證工程師，我認(rèn)為我有一個問題。我把它發(fā)給設(shè)計師。他要把它發(fā)回來。架構(gòu)師在中間，軟件團隊也會參與進(jìn)來。參與的人很多，大多是互相推諉，不能真正協(xié)作，共同解決這個問題。驗證工程師必須學(xué)會如何利用他們的綜合知識來提高工作效率。如今，調(diào)試是一條孤獨的路--孤獨在于很難讓人幫你，但也很難教你?！?/p>

對于這一點，Roy Choudhury表示，徹底記錄下所做的任何事情都是有幫助的?！比绻銓φ麄€驗證活動有很好的記錄，就會有相當(dāng)大的幫助。在我以前的一家公司里，我們曾經(jīng)保留了整個硅后驗證過程的日志，這些日志曾經(jīng)在我們用來驗證的服務(wù)器設(shè)計上完成。這是非常詳細(xì)的。例如，我們曾經(jīng)為負(fù)載存儲單元、為CPU測試等設(shè)置了區(qū)域負(fù)責(zé)人，每個人都有一大套遺留測試，只要測試人員有空，就會給他們分配N個小時的時間來測試設(shè)計。隨著時間的推移，我們對所有這些驗證活動都有記錄。根據(jù)新功能的到來，例如，如果有很多功能發(fā)生，那么負(fù)載存儲單元區(qū)的所有者，將獲得更多的測試小時數(shù)。在這一點之后，如果你把所有的東西都記錄得非常清楚，如果你有整個歷史計劃在身邊，那么就會變得非常無縫?！?/p>

當(dāng)然，他指出，需要一定量的知識?！蹦阈枰拦ぞ?，并有方法論來做得更好，以及可以投入的效率，如功能驗證。這是一個很大的領(lǐng)域，我們所有人都對它感興趣，以確保我們擁有的整個刺激是完全可移植的，這樣我們就可以在設(shè)計的多個階段無縫地使用它，無論是硅的模擬還是其他方面。這將實現(xiàn)大量的重復(fù)使用，當(dāng)然也會帶來更高的效率?！?/p>

OneSpin的Tusinschi指出，通過基于形式的突變分析、基于模型的故障注入以及對源代碼的精確映射，可以快速、精確地衡量進(jìn)度和覆蓋率的提高?！逼浣Y(jié)果是可靠地識別驗證差距和盲點。當(dāng)然，最佳的解決方案是將所有的驗證指標(biāo)，如來自仿真和形式化的指標(biāo)納入一個視圖，以便更好地了解整體的驗證工作和進(jìn)度?！八f。

結(jié)語

當(dāng)你覺得你已經(jīng)完成了，Imperas的Davidmann說：”你必須把測量到位，你必須分析。當(dāng)有問題時，你需要了解流程是什么。這都是關(guān)于經(jīng)驗的。你需要大量的經(jīng)驗來研究如何做到這一切。此外，新的技術(shù)正在出現(xiàn)，希望在生成測試時使用AI的團隊正在涌現(xiàn)新技術(shù)。您可以使用AI來查看測試的有效性，查看測試在設(shè)計中的位置以及什么是做事的更好方法，以便它可以幫助改善正在執(zhí)行的測試的質(zhì)量。如果做得正確，這可以節(jié)省完成所有測試和回歸測試以及改善事物質(zhì)量所花費的時間。目前，我們正處于使用AI協(xié)助我們進(jìn)行驗證的初期階段?！?/p>

最后，Cadence的Young強調(diào)，要確定何時完成驗證。你基本上要盡量讓覆蓋率達(dá)到100%，在你的老板告訴你，如果你不帶出去，團隊就會有危險之前，盡可能多地跑。這顯然是基于經(jīng)驗的，但你需要使用基于規(guī)格的覆蓋模型。你需要運行盡可能多的回歸測試。你要確保即使發(fā)現(xiàn)了一些勘誤，也可以通過軟件來處理，而不是要重新做一次測試。

編輯：hfy