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

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

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

“要想讓驗證被認為是完整的，首先必須對驗證覆蓋率有一個堅實的理解，”OneSpin Solutions公司設計驗證解決方案產品經理Nicolae Tusinschi說?！叭绻恢莉炞C中是否或在哪里存在差距，就很難達到IC完整性標準，也就是確保設計按預期操作，是安全、可信和可靠的。如果沒有精確的覆蓋率分析，你就無法放心地達到簽收。需要的是快速、精確地衡量進度和覆蓋率的提高。”

根據開發人員在生態系統中的位置，驗證任務因不同程度的挑戰而變得更加復雜?！叭绻闶且患以O計硅片、封裝、電路板、系統和軟件的系統公司，你實際上可以奢侈地完全控制，”Cadence的產品營銷總監Michael Young說?！暗窍胂笠幌拢闶遣┩ü镜目蛻?，或者你正在設計某款芯片，該芯片裝在插入計算機主板的PCIe卡中。要了解系統方案是非常困難的。為了降低風險，以及重新旋轉的成本，以及發現客戶的bug，左移的概念已經開始發揮作用。所有過去在硬件層面做的活動都被轉移到硬件/軟件中。而這種硬件/軟件的開發是在SoC層面進行的，SoC的開發也在盡可能早的進行。這里的挑戰是，仿真器并沒有像過去那樣提供同樣的速度提升，所以很多人都在左移仿真或原型系統來做額外的工作，并將更多的工作量轉移到驗證上。”

這需要對需要驗證的內容有一個清晰的認識。“你只能定義和驗證你能指定的東西，”Young說?！澳悴荒苤付ǖ臇|西是會殺死你的東西。一旦你開始規范，如果你做得不對--或者你的設備必須生活在一個不受你控制的外國環境中--你的風險就會高很多。”

圖1：以系統為中心的SoC視圖。來源：Cadence

什么時候能完成？

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

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

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

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

可以幫助的是擁有數據和工具來更快地完成覆蓋?！蹦阌懈采w率，這是今天很多人衡量風險的方式，但覆蓋率不是全部，“Hand說?！蹦憧赡苡懈采w面的漏洞。你可能沒有定義覆蓋范圍。可能有很多差距。但如果有一套你定義的指標，你可以根據這些指標進行衡量。另外，可以利用工具和技術來確定這些指標是否良好。你可以有一個覆蓋方法論，你已經定義了1000個覆蓋點。你擊中了這1000個覆蓋點，但這1000個覆蓋點只擊中了你設計的10%。那么你的風險暴露是什么？“

這些都是必須要解決的問題。但這并不是那么簡單。定義風險邊界是一個移動的目標，因為它取決于設計，以及該設計在系統內的背景和與其他系統的交互。

”有一個權衡，但對于每個芯片來說，它是不同的，“他說。”可接受的風險對于每個設計都會不同。你要做的是給工具，不管是通過驗證管理、需求管理、覆蓋率可追溯性，還是通過機器學習，了解你看了什么與沒看什么。當我們在某一個領域看的時候，我們往往會變得盲目。我們沒有看到右肩上那個準備撲過來的怪物。我們可以利用機器學習技術來識別你做的都是正確的事情，但那個怪物還在那里。“

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

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

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

不像聽起來那么簡單

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

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

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

這可以一步步來。”在功能驗證中，只要我們被要求驗證一個功能，一切都要從測試規劃開始?！八f。”因此，我們確定了設計中的不同變化，然后我們創建了數百個場景，這些場景是確保特定功能按照預期工作所需的。然后，我們在設計還沒出來之前，就會花一些時間來編寫測試，確保它們在虛擬模型或功能準確的模擬器上工作正常。一旦測試人員準備好，設計可用，我們就會讓它運行，并盡量確保沒有故障。在程序接近尾聲的時候，通常，設計錯誤率可以作為一個很好的指標來衡量整體驗證的情況。當你要完成整個驗證任務的時候，它會趨于平穩。“

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

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

知識共享

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

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

當然，他指出，需要一定量的知識?！蹦阈枰拦ぞ撸⒂蟹椒ㄕ搧碜龅酶?，以及可以投入的效率，如功能驗證。這是一個很大的領域，我們所有人都對它感興趣，以確保我們擁有的整個刺激是完全可移植的，這樣我們就可以在設計的多個階段無縫地使用它，無論是硅的模擬還是其他方面。這將實現大量的重復使用，當然也會帶來更高的效率?！?/p>

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

結語

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

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

編輯：hfy