如果我們想自己建造房屋，那么在此之前，一定需要一份詳盡的設計藍圖，并精心規劃出每個房間、走廊和門窗的位置。但如果等房屋已經開始建造了，再進行更改，不僅代價高昂，而且非常耗時。芯片設計，包括Multi-Die系統的基礎構建，亦是如此，全部都需要細致入微的架構規劃。

對于復雜的Multi-Die系統而言，從最初就將架構設計得盡可能正確尤為關鍵。

Multi-Die系統的出現，是為了應對設計規模增加和系統復雜性給摩爾定律有效性帶來的挑戰。Multi-Die系統將多個異構裸片集成在單個封裝中，不僅能夠加快系統功能的擴展，而且能降低風險和系統功耗，縮短產品上市時間，有助于更快地打造新的產品版本。Multi-Die系統正逐漸成為高性能計算、汽車和手機等計算密集型應用的首選架構。

Multi-Die系統正逐步成為半導體行業的主流架構，因此需要在架構規劃階段采用新的方法。甚至在架構規范定義的早期（相當于繪制新房的藍圖時），芯片開發者也不能忽視布局、功耗、溫度以及IR-drop等物理效應的影響。本文將探討架構規劃方面的考量和挑戰，并針對成功實現Multi-Die系統的方法學和技術分享我們的見解。

Multi-Die系統涉及維度多，決策面廣

Multi-Die系統環環相扣，牽一發而動全身，芯片設計過程中的每一個選擇都應從整個系統的角度做考量，以消除可能對系統產生的不利影響。考慮到Multi-Die系統給架構設計空間帶來的新維度，必須從系統級的角度對功耗和性能進行分析。例如，在3D堆疊設計中，散熱會變得更加困難，因此熱傳遞和供電問題往往更加嚴重。開發者需要找到一種方法，將電力有效地從低層的裸片傳遞給頂層的裸片，以消除散熱問題。

Multi-Die系統有諸多因素需要考量，如接口的不同實現方式、協議的選擇、裸片是并排放置還是垂直堆疊、使用什么類型的封裝更為合適，等等。選擇正確與否，取決于目標應用在功耗、性能、功能、成本和散熱等方面的要求。

設計過程中需要做出的關鍵決策分為兩大類。第一類是Multi-Die系統架構方面的決策。在這方面，開發者可以選擇聚合方式，即由多個裸片（或小芯片）組裝成Multi-Die系統；也可以選擇分解方式，即將應用分解到多個裸片上。此外，開發者還必須選擇Die-to-Die接口的協議、位置和尺寸，以及每個裸片的工藝和封裝技術。第二類是SoC級架構方面的決策，涉及到硬件/軟件劃分，IP的選擇、配置和連接，為了實現共享的互連和存儲子系統需要的互連/內存的配置，以及系統級功耗分析等。

設計劃分體現了單片式SoC與Multi-Die系統的差異。在單片式SoC中，開發者必須決定各個組件包括哪些功能，哪個子系統處理哪個流程，以及添加哪些類型的IP來處理相應功能。此外，還需要對數據進行分區，確定將數據存儲在哪里，以及如何連接所有組件，從而能夠高效地訪問所需的數據。

Multi-Die系統則可以為設計空間增加更多的維度，并賦予更大的設計自由度。系統中不同裸片之間的分界線如果設計不當，可能會造成瓶頸，因為與不受約束的片上通信相比，裸片間通信會受到更高延遲和更低帶寬的影響。然而，在設計的早期階段，很難預知所有決策的影響。完成第一步劃分后，將得到頂層設計規范；然后便進入了實施階段，這一階段需要付出相當多的努力；而系統的最終性能只有在后續設計階段才會變得逐漸清晰起來。

虛擬原型工具如何提供有關架構設計的見解

在架構規劃階段，最大的一個挑戰是：在項目開始時，可供使用的設計數據少之又少，而此時又必須做出許多重要的決策。考慮到應用程序在有限的處理資源和通信資源上運行時，性能、功耗和熱學特性等諸多關鍵性能指標（KPI）的變化是動態的，因此僅僅依靠電子表格進行靜態分析同樣存在著巨大的誤判風險。

那么開發者該如何應對這一尤為棘手的挑戰？

答案是采用虛擬原型設計Multi-Die系統架構。就像早期的電子數字孿生一樣，虛擬原型可以用來分析架構設計決策可能產生的影響。為此，首先要做的是定義工作負載和架構：需要執行哪些應用？有哪些非功能性的要求，比如端到端延遲和帶寬？應由哪些硬件組件來執行這個工作負載？它們的功耗和性能怎樣？

為了真實地估計上述問題的答案對Multi-Die系統的影響，需要將這些功能性和非功能性要求轉化為系統的物理硬件屬性，包括裸片的目標工藝技術、面積大小以及不同組件的深寬比。

完成上述初步評估后，開發者接下來可以對Multi-Die系統進行虛擬原型構建。在這一環節，需要考慮的重要問題有：這些系統組件如何劃分到不同的裸片？工作負載和數據結構是如何映射到這些組件上的？這些問題的答案共同決定了裸片邊界上的傳輸流量。

當然，也有許多因素需要權衡。例如，關于裸片面積，更大的片上存儲器和高速緩存意味著更高的價格，但這也有助于減少裸片間的流量傳輸。通過構建可執行的模型來展現工作負載在Multi-Die系統架構資源上的運行情況，芯片架構師便可以收集大量有關實際系統行為的數據。其中需要考慮的關鍵因素包括：

最終的資源利用率是多少？

執行某項任務的端到端延遲是多少？

需要在不同的小芯片之間傳輸多少數據？

基于所有這些分析，開發者可以對系統架構做出全方面的修改，以優化的方式快速得到符合產品要求且具有可行性的設計規范。

深入洞察根本原因

值得慶幸的是，有些來自單片SoC領域的技術可以應用于Multi-Die系統。例如，SoC架構分析和優化技術可用于Multi-Die系統的分析和優化。這些技術可以在早期階段通過建模模擬出預期性能，以幫助開發者得到可行的架構概念。這種早期的架構分析可以生成數據，指導芯片、封裝和軟件團隊后續的實現。

當然，在架構定義階段，必須盡早對功耗、溫度、IR-drop效應等進行系統化的分析。經典的SoC設計流程（各個設計階段相互獨立，可單獨考慮）在Multi-Die領域已不再適用。Multi-Die架構必須通過功能架構和物理架構的協同優化，從整個系統的角度進行設計和驗證。通過在架構規范階段的早期定義出物理架構，開發者便可以在功能架構中驗證所做的假設。如果最初的方案由于某種原因不可行，那么通過物理架構分析得出的結果和指導意見便可以反饋給功能架構師，以改進規范。

新思科技Platform Architect就是此類分析解決方案的典范，它可以為早期的架構分析提供虛擬原型環境。通過該解決方案，開發者可以分析Multi-Die系統的硬件資源，包括關鍵處理單元、互聯結構和內存層次結構。此外，該解決方案還可以分析Die-to-Die接口部分的性能，以反映小芯片之間的分界線對延遲和帶寬的影響。

Platform Architect會將最終應用的處理和數據傳輸要求轉化為工作負載模型。通過將工作負載模型映射到架構模型，可建立Multi-Die系統架構的可執行規范，從而使用KPI進行高效的分析。通過映射過程，開發者可以針對功耗和成本等KPI來優化系統。

系統性能模型模擬了可執行規范，而且是高度可配置的，其仿真速度要比RTL快1000-10000倍。用于更改系統劃分或IP配置的周轉時間很短，且多個仿真可以在普通計算主機上并行運行。而且，該解決方案提供了多種分析視圖來協助開發者找出性能和功耗問題的根本原因。

Platform Architect是新思科技Multi-Die解決方案的一部分，其他還包括EDA和IP產品，旨在實現快速的異構集成。借助該解決方案，可以全面構建、設計、驗證和測試Multi-Die系統，同時兼顧可能影響PPA的各種相互依賴關系。

結語

與單片系統相比，Multi-Die系統雖然復雜，但是通過精巧的設計，可以讓計算密集型工作負載獲得更好的PPA。因此，Multi-Die系統創建過程中的每一步（包括架構規劃）都必須從整個系統的角度加以考量。問題越早發現，就越有可能做出有影響力的改變來優化整個系統。由于有價值的設計數據通常要到設計流程的后期才能獲得，因此虛擬原型設計已成為分析早期架構決策影響的一種有效方法。借助虛擬原型技術，開發者可以更好地掌控功耗和性能，同時仍可以在設計過程中做出修正和優化，從而規劃出Multi-Die系統的理想藍圖。

審核編輯：彭菁