芯片驗證工具等待人工智能「拯救」

驗證工程師是半導體行業(yè)的無名英雄，但他們正處于崩潰的邊緣，迫切需要現(xiàn)代化的工具和流程來應對快速增加的壓力。

驗證不再僅僅是確保功能在實現(xiàn)時得到精準呈現(xiàn)，單單這一點就是一項無解的任務，但驗證已承擔起許多新的責任。其中一些責任來自技術進步，這些進步帶來了更多問題，例如熱問題。汽車等新應用領域增加了對安全性和保密性的需求，并且參數(shù)問題急劇增加，遠遠超出了簡單的功率評估。除此之外，芯片行業(yè)正在接近另一個轉折點，這一轉折點是由向 2.5D 和 3D 封裝技術的遷移引發(fā)的。

現(xiàn)有的驗證工具和方法是 20 年前開發(fā)的。自那時以來，工具容量和性能只得到了緩步改進，而設計規(guī)模卻迅速增加。盡管便攜式刺激（一種為將驗證意圖與執(zhí)行驗證的引擎分離開而創(chuàng)建的 Accellera 標準）提供了一些緩解，但采用速度緩慢，缺乏全面的流程。

除了技術因素導致驗證過程壓力增加之外，還需要考慮人為因素。團隊需要用更少的時間完成更多工作，而人才短缺制約了該行業(yè)的發(fā)展。

接近極限

當今使用的工具是在區(qū)塊更小、系統(tǒng)規(guī)模與當今區(qū)塊相似的基礎上開發(fā)的。驗證永遠不可能百分百完成，這意味著團體必須謹慎決定將精力投入到何處，以及他們愿意承擔哪些風險。

Axiomise 首席執(zhí)行官 Ashish Darbari 表示：「由于 AI/ML 革命為我們正在構建的設計類型增加了新的維度，設計復雜性正在以前所未有的速度增加?！埂高@些系統(tǒng)具有嚴格的功率、性能和面積 (PPA) 要求。采用更好的流程和高級驗證方法（例如形式驗證）還不夠。該行業(yè)仍然嚴重依賴刺激的不完整動態(tài)模擬方法，這不僅允許易于捕獲的錯誤泄漏到硅片中，而且也沒有機會捕獲由于單時鐘或多時鐘域中的深狀態(tài)機并發(fā)交互而出現(xiàn)的復雜錯誤?！?/p>

更糟糕的是，IP 越來越模態(tài)化?！敢粋€模塊可能有 1,500 個規(guī)格項目，」Keysight 的業(yè)務開發(fā)、營銷和技術專家 Chris Mueth 說?！杆鼈冎械暮芏喽际窍嗷ヒ蕾嚨?，與操作模式緊密相關，但也有不同的電壓、不同的溫度等等。在 6G 模塊中，你有無數(shù)的模式和頻段可供傳輸，而且它們都是相互依賴的。從頻率、帶寬、數(shù)據(jù)傳輸速率的角度來看，它們正在達到極限。你可能認為設計已經(jīng)完成，但你仍然可能錯過其中一種模式。這最終可能會成為一個問題。即使在今天的數(shù)字時代，如果你沒有達到性能要求，就會失敗。一切都變成了性能模擬?！?/p>

有時參數(shù)故障會被忽略?！父嗟墓收鲜擒浌收?，有時也稱為參數(shù)故障，」Ansys 產品營銷總監(jiān) Marc Swinnen 說道?！感酒梢怨ぷ鳎鼞撘?1.2 千兆赫的速度運行，但最高只能達到 1.0 千兆赫。當你觀察任何大型芯片時，寄生元件的數(shù)量都會激增到數(shù)十萬?！?/p>

這增加了失敗的風險?！冈隍炞C IP 時，他們會詢問它將在何種環(huán)境下使用，」Synopsys 研究員 Arturo Salz 說?！杆麄儫o法驗證所有可能的排列，而是會等待系統(tǒng)準備就緒，并將大部分驗證工作推遲到系統(tǒng)級。這通常是一個誤區(qū)，因為 IP 級錯誤很難在系統(tǒng)級找到。這是一個更大的問題。對于多芯片，你將沒有這個選擇，因為該芯片 IP 可能已經(jīng)制造出來，你必須在開始將其集成到下一個系統(tǒng)之前對其進行驗證和測試?！?/p>

超越極限

約束隨機算法在首次推出時取得了巨大進步，但現(xiàn)在卻舉步維艱?！肝医?jīng)常將約束隨機算法比作泳池清潔工，」Synopsys 的 Salz 說道。「你一定不想對泳池的形狀進行編程，雖然它是隨機的，但泳池的周長是固定的。不要爬上墻壁，這是低效的。它會穿過泳池中心的次數(shù)比穿過角落的次數(shù)多得多，但只要有足夠的時間，它就能覆蓋整個泳池。由此引申，我們能掃蕩太平洋嗎？不，它太大了。你需要選擇合適的方法。在塊級別，有效地部署該方法。形式化方法也是如此，它可能沒有能力在系統(tǒng)級別進行形式化檢查?！?/p>

這不僅是方法的規(guī)模不對，還占用了大量最寶貴的人力資源?！阜抡鏈y試平臺漏掉了這么多錯誤，這并不奇怪，」Axiomise 的 Darbari 說。「與正式的測試環(huán)境相比，即使對于中等復雜的設計，UVM 測試平臺也需要更多的時間來啟動。UVM 依賴大量的人力，因為 UVM 的基礎需要大量的人力投入來編寫序列，而這些序列最終不會對 DUT 進行嚴格的測試。這使負擔轉移到功能覆蓋上，以查看差距在哪里。在許多情況下，仿真工程師根本沒有時間去了解設計規(guī)范。驗證工程師沒有接受過 RTL 設計方面的教育，期望他們了解微架構和架構的細節(jié)要求太高了?！?/p>

簡而言之，問題已經(jīng)超出了工具的能力范圍?！肝也徽J為 UVM 已經(jīng)失去動力，」Fraunhofer IIS 自適應系統(tǒng)工程部門虛擬系統(tǒng)開發(fā)小組的 Gabriel Pachiana 說道?！笇τ谄漕A期用途而言，它仍然是一款出色的工具。我們需要的是充分利用它，在其基礎上構建更多驗證軟件，例如，解決硬件-軟件驗證的復雜性?！?/p>

Shift left

Shift left 這個術語在業(yè)界被廣泛使用，但驗證迫切需要 Shift left。這意味著要盡早在高性能的設計抽象層面進行驗證?，F(xiàn)有的模擬器或仿真器不具備必要的性能，等到 RTL 階段就太晚了。Breker 首席執(zhí)行官 Dave Kelf 表示：「在這個過程中，Shift left 意味著將驗證應用于 SystemC 算法模型或虛擬平臺。這極大地簡化了從規(guī)范到設計驗證的過程。因此，在虛擬平臺上制定系統(tǒng)驗證計劃，然后在仿真器或原型上進行系統(tǒng)驗證時重新應用，可能會提供足夠的方法精簡，使有效的系統(tǒng)驗證成為現(xiàn)實?！?/p>

然而，整個過程尚未完全開發(fā)?！溉绻摂M原型是黃金模型，你如何將它一路延伸到芯片并知道芯片仍然是正確的？」Siemens EDA 戰(zhàn)略驗證架構師 Tom Fitzpatrick 問道?！肝锢碓?、FPGA 原型或仿真等東西，無論底層引擎如何，都具有相同的系統(tǒng)視圖，這一點非常重要。驗證工程師將不得不開始以這種方式看待基礎設施。他們需要讓團隊中的每個人都看不到底層環(huán)境，這就是便攜式刺激的作用所在。由于它的抽象性，你可以從算法的角度來考慮測試，考慮你想要發(fā)生什么，以及數(shù)據(jù)的去向，而不必擔心底層實現(xiàn)?！?/p>

它必須從虛擬原型開始?！肝覀冃枰M早進行更好的架構探索，」Salz 說。「我們需要通過階乘排列來考慮功率、吞吐量和延遲。是將緩存與 CPU 一起保留，還是將其移出到單獨的芯片并增大？這些都是棘手的問題。過去，每家公司都有一個人，架構師，可以在餐巾紙上完成這項工作。但這已經(jīng)是人類的極限。一切都將被投入到虛擬原型中。你將投入虛擬模型、仿真、模擬，甚至可能是已經(jīng)構建好的 chiplets，你可以連接后硅片。虛擬原型會以 3 到 4 千兆赫的頻率運行，模擬器無法接近這個速度。你可以獲得更高的吞吐量，但代價是失去一些時間準確性?！?/p>

一些引擎已經(jīng)綁定在一起。Cadence 產品管理組總監(jiān) Matt Graham 表示：「進行混合建模的能力正在不斷增強。我們引入 C 模型和快速模型并將該平臺連接到模擬或仿真的能力正在不斷提高。更上一層樓的是數(shù)字孿生概念。模擬不會擁有 100 倍的容量，也不會變得快 100 倍，我們必須對此保持理智，必須找到創(chuàng)新有趣的抽象方法。虛擬平臺就是其中之一。我們需要通過將原型設計和仿真移到流程的早期來接受數(shù)字孿生概念，并找到提供抽象的不同方法?！?/p>

流程內的重復使用很重要。「另一個有希望的方向是將設計和驗證工作提前到開發(fā)流程的左側，即在開發(fā)初期就識別錯誤，」Fraunhofer 的 Pachiana 說?！窼ystemC 和 UVM-SystemC 在這方面很有用。雖然這又增加了一層開發(fā)工作，耗費了項目時間，但關鍵是要重用早期的工作成果，并展示其好處?！?/p>

這個行業(yè)不喜歡革命?！笡]有人會徹底改變他們的做事方式，」Siemens 的 Fitzpatrick 說?！高@就是事實。這也是為什么到目前為止它依然是漸進式的，因為你能做的事情是有限的。這就是便攜式刺激裝置發(fā)揮作用的地方。它旨在成為進化框架中革命性的一步。能夠利用現(xiàn)有的基礎設施，并添加使用 UVM 無法實現(xiàn)的額外功能，這就是它成功的方式。」

然而，構建模型的挑戰(zhàn)仍然存在。Cadence 的 Graham 表示：「我們在構建模型時驗證模型的能力已經(jīng)提高了很多?，F(xiàn)在有更多的模型可用，當然是處理器模型、協(xié)議模型、CPU 子系統(tǒng)內的東西的模型，比如一致性和性能。這是下一個抽象層次，但要構建合適的數(shù)字孿生，你需要一種可靠的方法來構建模型。」

需要一些清晰的思考。「我們需要大膽地接受它——越來越多的模擬周期和盲目的功能覆蓋不會發(fā)現(xiàn)所有的錯誤，」Darbari 說。「我喜歡形式化，我堅信它比任何其他驗證技術都能提供最大的投資回報，因為它可以提供詳盡的證據(jù)和理由，說明是什么而不是如何。然而，我也看到盲目地應用形式化會導致產量低下?？紤]需求、接口規(guī)范、理解微架構與架構以及軟件/固件的關系，將使每個人更容易看到大局，同時也能掌握更精細的細節(jié)，從而獲得更好的驗證方法?！?/p>

人工智能來救場？

人工智能已融入設計和驗證的許多方面?！蛤炞C已經(jīng)抓住了人工智能突破帶來的興奮，」Graham 說?！缚蛻粼趩栁覀冇萌斯ぶ悄茏鍪裁?？我們如何利用人工智能？我們需要催化我們所有的工程師，因為我們沒有足夠的人手?！?/p>

有一些唾手可得的成果。Keysight 的 Mueth 說：「你沒有時間在合理的時間內模擬所有你想模擬的東西。你可以求助于人工智能，在模擬數(shù)據(jù)中繪制相關性，說『基于 a、b 和 c，不需要模擬 x、y 和 z?！贿@是一個典型的人工智能類型的問題，但你需要大量的數(shù)據(jù)來推動機器學習?！?/p>

有幾種方法可以優(yōu)化回歸。「當你在設計中做出改變時，哪些測試針對該區(qū)域，」Salz 說?！改阒恍枰\行測試的一個子集。強化學習可以修剪特定的測試。如果這與之前的測試非常相似，就不要運行它。這樣你就可以最大化測試多樣性。以前，你只有不同的隨機種子來創(chuàng)造測試多樣性。」

時間壓力越來越大，效率問題也越來越突出?！?0 年前，質量差距很大，」Graham 說。「總的來說，行業(yè)知道如何縮小質量差距?，F(xiàn)在，差距變成了效率。這就是為什么每個人都在談論 Shift left、生產力、上市時間和扭轉局面的時間。這促使人們開始尋找利用人工智能的方法。生產力的提高不會來自和 10 年、20 年前同樣的東西?！?/p>

巨大的收益將來自截然不同的方法。「許多問題都是由規(guī)范中的歧義引起的，」Salz 說?！肝蚁Ｍ覀兛梢允褂?GenAI 大型語言模型來解析規(guī)范，并安排它坐副駕駛。然后它可以詢問這是否是我們的意思。GenAI 缺少的是生成時序圖或生成 UML 的能力，以便設計師或架構師了解情況。我們希望可以讓工具從語言規(guī)范轉變?yōu)楦降男问揭?guī)范，并實現(xiàn)其中一些自動化。這不能使用人工智能來編寫設計，至少目前還沒有。」

但人工智能可以填補模型創(chuàng)建方面的空白?！肝铱催^幾篇關于使用人工智能構建這些模型的論文，無論是自上而下——我閱讀規(guī)范并為其生成 C 模型——還是自下而上的觀察型建模技術，即觀察 RTL 模型的作用，然后在更高抽象層次上統(tǒng)計地構建模型，」Graham 說?！肝覀冞€沒有到達那一步。但我認為這是人工智能的潛在用途之一，它可能真的有助于解決非常實際的問題?！?/p>

結論

驗證中的工具缺口越來越大?，F(xiàn)有工具無法處理系統(tǒng)級問題，而最復雜的問題就隱藏在這里。雖然正在開發(fā)一些新語言和工具來填補這一空白，但它們的采用速度很慢。業(yè)界似乎被困在 RTL 抽象上，這導致模型執(zhí)行出現(xiàn)瓶頸。

為了鼓勵開發(fā)團隊遷移到更高的抽象層次，需要新的工具以自上而下或自下而上的方式填補建?？瞻?。雖然人工智能可能能夠提供幫助，但這種能力目前還不存在。