關鍵要點：
集成挑戰已不僅限於確保模組正確連接。語義問題是最大的麻煩來源，其中許多都源於規格說明不完整或質量不佳。
複雜性的增加（包括軟體內容的增長）使得追蹤設計中包含的一切內容變得更具挑戰性。
許多設計正在不斷逼近功耗和散熱極限，這就需要新增一層必須加以規定和追蹤的資訊。
IP集成
並非半導體設計中最光鮮亮麗的工作，但卻常常是最麻煩的環節之一。在模組級驗證與系統級交互的交匯處，錯誤往往極難被發現。
1996年虛擬插座接口聯盟（VSIA）的成立，對許多人而言，是通過整合第三方IP模組來設計系統這一理念首次成為現實的時刻。該聯盟的章程旨在統一和規範IP的構建、驗證、交付與支持方式。2008年該聯盟解散，原因是其認為工作已經完成，或者將部分工作轉交給了其他更專注於具體問題的組織。十八年過去了，這個問題仍在不斷演變。
其核心理念是，每家公司應專注於開發設計中新穎獨特的部分，貢獻自身的專業能力，而將其餘部分交由領域專家來開發。
"十年前，一個設計可能包含數十個IP模組，"是德科技EDA部門的SOS產品經理佩卓·皮雷斯（Pedro Pires）表示。"如今，一家公司可能擁有數千個IP，同一IP的數十個不同版本，你需要理清這一切。此外，它們比過去更具可配置性。隨著每個模組所需數據的數量和類型不斷增加，以臨時方式進行管理正變得十分困難。"
這給驗證工作帶來了巨大壓力。"最棘手的故障幾乎從不出現在單個模組內部，"Axiomise創始人兼首席執行官阿希什·達爾巴里（Ashish Darbari）表示。"它們會出現在模組之間——消息依賴性死鎖、逐漸泄漏的信用額度、被破壞的重排序緩衝區、跨橋接處被打破的排序規則。每個模組都通過了自身的驗證，但系統卻因為兩個團隊對同一協議規則的理解略有不同而發生掛起。"
隨著時間推移，跨IP問題的數量不斷增加。"從SoC的角度來看，可能涉及許多不同的問題，包括地址映射、中斷、一致性、服務質量（QoS）、安全性，"新思科技高性能計算IP產品組合技術產品管理高級總監瑪杜米塔·桑亞爾（Madhumita Sanyal）表示。"此外還有一些物理實現方面的情況，比如動態電壓頻率調整（DVFS），用於降低功耗的動態電壓調整。再加上軟體和作業系統的交互。如果考慮die-to-die的IP，還涉及互操作性。有已知良品裸片（known-good-die）封裝、信號完整性、電源完整性、配電網路、熱耦合、遙測等問題。"
雖然設計規模一直在穩步增長，但這本身並不能作為複雜性的指標。"我可能設計一款擁有32個核心的巨型CPU，但那只是同一個東西的32份副本，"IC Manage首席執行官迪恩·德拉科（Dean Drako）表示。"它可能帶有一個巨大的緩存，那只是一個單元重複了一億次。複雜性並不總是與晶片規模成正比。它們很複雜，但複雜性並未隨晶片規模線性增長。人腦難以應對這一點。"
真正重要的是一個模組對其周圍環境做出了多少假設，而這個數字的增長速度遠快於規模的增長。"一個UART只需要時鐘、復位和寄存器接口，僅此而已，"Axiomise的達爾巴里表示。"一個一致性緩存、CHI home node或NoC則攜帶數百項假設。其中有排序規則、信用契約、未完成事務的數量限制、復位和電源時序、地址映射預期以及安全屬性。除此之外，還有數據手冊往往無法完全解釋清楚其影響的配置參數。"
日益增加的壓力
許多方面都在加劇集成壓力，例如IP模組規格說明書寫得糟糕或不完整。在系統層面，軟體複雜性不斷增加，功耗和散熱問題日益突出——尤其是與chiplet相關的問題、模擬內容的增多，以及許可、地緣政治限制和出口管制帶來的額外複雜性。以下將簡要論及每一方面。
糟糕或不完整的規格說明：規格說明書向來難以做到毫無歧義或完整無缺。"這些資訊往往不夠完整，無法讓你準確了解系統在各種情況下將如何表現，"是德科技的皮雷斯表示。"了解系統將在何種條件下運行可能會對你有所幫助，這取決於你的IP文檔質量。也許這些IP所攜帶的資訊恰好與那組特定情況相關，從這個意義上說，了解系統的運行環境會對你有幫助，但也可能幫不上忙。"
這個問題通常是在出現漏洞逃逸時才被發現的。"架構師、設計師、軟體團隊、DV負責人和形式化驗證團隊都看著同一個故障，卻各自看到不同的東西，"達爾巴里表示。"沒有人能就系統本應做什麼達成一致，因為從來沒有人把它以一種大家共享的形式寫下來。這些分歧從第一天起就存在。它們只是在兩年後才浮出水面，而且往往是在流片後調試階段，這時修復成本最為高昂。"
軟體複雜性：雖然有些軟體是完全封裝並對任何外部接口隱藏的，但大多數並非如此。"即便是像PHY這樣簡單的東西，也包含大量軟體內容，"新思科技的桑亞爾表示。"有負責建立所有時鐘、復位和內存的引導固件。然後PHY還有校準固件，負責初始校準和自適應，並且會持續更新。該驅動程式需要與作業系統的中斷和DMA框架相連接，還要兼顧BIOS、管理程序或一致性、PCI控制器的IOMMU依賴關係等等。這些都將依賴關係延伸到了拓撲結構與作業系統服務以及電源管理框架之間的中斷上。"
這些問題棘手到UCIe標準都試圖加以解決。"UCIe 3.0標準化了固件在初始化早期的下載方式，"達爾巴里表示。"問題在於，硬體通常只有在某些軟體假設成立的條件下才是正確的。例如，寄存器可能必須按特定順序編程，或者在事務進行期間絕不能寫入某個欄位。這些規則很少被寫下來，而RTL驗證本身從不會檢查這些規則。"
硬體與軟體之間的鴻溝很大。"軟體的世界和硬體的世界截然不同，這意味著操作硬體的人和操作軟體的人是不同的，"皮雷斯表示。"這其中包括固件，即與IP緊密相連的軟體。這兩個團隊的工作流程和節奏也不相同。"
功耗與散熱：功耗控制正成為一個日益嚴重的問題。"電源管理已經成為一項功能性特性，也是功能性漏洞的主要來源，"達爾巴里表示。"每個電源域都會增加狀態、轉換、隔離和喚醒序列。一個模組在上電時可能完全正確，但當其鄰接模組在傳輸過程中斷電時，仍可能丟失事務或導致握手掛起。諸如'如果該域在響應未完成時關閉，該請求是否會丟失'這類問題，是典型的形式化驗證難題。仿真很少能恰好命中出錯的那個周期。"
功耗消耗會產生熱量，進而可能改變敏感電路的行為。"隨著功耗和散熱如今成為SoC的限制因素，模擬IP不能再只是被動地坐在那裡，"Agile Analog產品營銷副總裁克里斯·莫里森（Chris Morrison）表示。"我們必須設計它來主動管理晶片，使用嵌入式PVT傳感器、時序監測器、壓降檢測器和毛刺檢測器，將實時遙測數據反饋給電源管理單元，在問題影響運行之前就捕捉到它們。"
模擬內容：模擬內容向來面臨獨特的挑戰。"這些IP的運行範圍有限，並且是針對特定用例高度定製的，"皮雷斯表示。"雖然AI在許多領域都有所幫助，但我們發現在創建AI自動化來加速射頻和模擬設計方面存在巨大挑戰，原因在於數據的稀缺性。要獲得一個質量良好、數量足夠的數據集，用來訓練智能體完成你流程中的特定部分，並非易事。這些資訊更加定製化、聚焦且狹窄，而且往往是我們無法獲取的專有資訊。"
模擬模組的創建者正在尋找將其設計抽象到數位世界的方法。"客戶越來越多地要求提供完整的模擬子系統，而不願與十幾個獨立模組糾纏，"Agile Analog的莫里森表示。"在SoC層面用SPICE仿真大型模擬子系統耗時過長，因此可以通過用數字封裝包裹IP來簡化驗證。在內部完成繁重的混合信號處理工作，意味著數字SoC集成團隊可以儘早採用SystemVerilog實數模型（RNM），並在其數字環境中運行全晶片驗證。"
Chiplet：Chiplet可以被視為IP的一種新型物理交付機制。"Chiplet放大了這個問題，並使其也成為一個供應鏈集成問題，"新思科技系統解決方案戰略項目執行總監弗蘭克·希爾邁斯特（Frank Schirrmeister）表示。"你不僅要面對IP本身的問題，還要把設計從SoC邊界上移到封裝邊界。這就把IP集成變成了供應鏈集成。你不僅要集成各種設計，還要集成這些可能來自不同公司、不同製程節點和不同代工廠的組件，而它們各自在IP層面都有自己的驗證方法。"
所有的集成問題都不會憑空消失。"NoC如今正被拉伸跨越裸片邊界，因此幾個裸片看起來像一個整體結構，"達爾巴里表示。"UCIe很好地處理了物理層和鏈路層，跨廠商互操作性也已得到驗證。但一條能工作的鏈路並不等於一個能工作的系統。你仍然需要就地址映射、一致性模型和軟體達成一致，而這些恰恰正是標準所留下的語義層面的空白問題。目前的規範還涵蓋了可測試性設計（DFD）、可測試性（DFT）、可製造性設計（DFM）以及可管理性，因此chiplet開始看起來不再像一個被動的模組，而更像一個擁有自身管理固件的小型系統。"
Chiplet所需的資訊甚至比IP模組更多。"現在出現了多物理場的問題，這意味著你需要掌握關於所管理IP的更多資訊，"皮雷斯表示。"把所有這些數據整合在一起正變得越來越難以駕馭。這意味著伴隨你的IP一起流轉的複雜性在增加。例如，功耗意圖需要作為附加產物隨IP一同傳遞。"
驗證：對於IP而言，尤其是對chiplet而言，對模組內部的可見性使驗證變得更加困難。"大型IP越來越多地以加密形式交付，因此你無法讀取RTL來弄清楚它到底期望什麼，"達爾巴里表示。"你只能依靠文檔，而根據我的經驗，漏洞往往就藏在文檔里。這些模組現在也更多地是作為生成器而非固定設計來交付的。供應商驗證了某一組配置，但你流片的可能是另一種配置。當參數超過幾個之後，很容易碰上一種沒有人測試過的組合。"
好消息應該是，並非IP的每一項功能都需要驗證。"識別出功能的合法子集是一項架構和驗證任務，"桑亞爾表示。"這並非一刀切就能自動化完成的事情。如果你關注其驗證方面，現在已經有AI模型，我們在使用，我們的客戶也在使用，用以比以往更快地找到那些邊界情況。這正是進入驗證環節的部分。"
版本控制
很少有東西能一次就做到完美。初版發布後漏洞總是會被修復。"非AI的版本就是關於IP生命周期管理，"IC Manage的德拉科表示。"有了AI，這些生命周期可能會推進得更快，但你仍然需要管理這些生命周期。也許你可以讓AI替你完成，但你必須具備數據和系統來加以追蹤，知道你流片了什麼、構建了什麼、什麼被用在了什麼地方、哪個IP被用在了哪裡。"
硬體和軟體的發布與更新遵循不同的時間表。"現場的一次固件更新可能會改變晶片在簽核之後的行為方式，"達爾巴里表示。"中斷、電源狀態、DMA緩衝區和安全屬性是硬體與軟體共享的，而衝突往往在啟動調試階段浮出水面，那時第一個真正的驅動程式會執行一段沒有人規定過的序列。"
硬體和軟體通常使用不同的版本控制機制。"這個挑戰與將所有這些數據整合到單一系統中有關，"皮雷斯表示。"你硬體的某個特定版本需要對應軟體的某個特定版本，而這種關聯往往存在於Excel表格中，這既混亂又容易出錯。當你在集成一個系統時，你需要管理配置本身，比如特定系統的物料清單，即你系統中所擁有的組件的具體組合。每次你對其進行更改，都需要讓它持久保存下來。你需要保存它，以便具備可追溯性。"
結語
這看起來似乎是一個日益令人擔憂的問題。但正如EDA領域內大多數問題一樣，隨著問題的增長，它所受到的關注也隨之增加，而對該問題的投入最終會帶來更好的解決方案。
"管理問題正在增長，但解決該問題的機制也在隨之演進，"皮雷斯表示。"從相對意義上說，痛點保持不變，但其背後的問題卻在變得更大。"
編者註：本報告的第二部分將探討近期的改進情況，以及AI如何被用於改善IP的選擇、配置與集成。
相關文章
加速IP復用
如何將1000個IP模組放入一個晶片設計中並確保它們協同工作。
縱向集成日益普及
沒有對硬體和軟體的共同理解，任何系統都無法得到優化，而做出正確的架構選擇需要雙方的協作。
