設計人員預測完成設計所需的時間和資源、設備的性能以及何時可以交付給客戶的能力受到影響。即使使用最好的工具，一些 SoC 設計趨勢也會極大地影響可預測性，從而影響總體開發成本，如圖 1 所示。

圖1

導致這種不可預測性危機的問題分為四大類：

系統復雜性：盡管設計人員了解各個 IP 內核，但他們仍與系統復雜性作斗爭，這來自 IP 內核交互的乘法效應以及與其操作相關的信息流。

抽象級別不當：用于描述功能塊的語言和技術沒有規定來描述系統中的這些功能交互以及這些交互如何影響整個系統。

先進的電源管理技術：使用動態電壓和頻率縮放對傳統設計方法施加了額外的限制。

工藝可變性：隨著技術下降到 65 nm 以下，處理工藝可變性是非常不可預測的，特別是對于傳統技術。

系統復雜性

復雜性看似隱蔽，因為鑒于先進工藝技術的能力，它似乎是一個容易解決的問題。隨著今天大量可用的晶體管，似乎可以構建任何可以想象的東西。那么為什么處理系統復雜性如此困難呢？原因是，雖然可用晶體管的數量大致呈線性增長（不考慮利用率），但引入不確定性并因此帶來可預測性挑戰的系統交互會因乘法效應而增長。這種乘法效應基于 SoC 設計中的幾種復合趨勢。

多處理器

首先，從單處理器系統到多個異構和同構處理器的轉變正在增加系統交互，從而增加了復雜性。現代 SoC 通常包含一個或兩個以上的處理器。除了編程挑戰之外，協調這些多處理器硬件驅動的活動給設計人員帶來了困難。設計團隊必須了解一些問題，包括：

對共享資源的真正需求是什么？

使用這些共享資源的合理目標是什么？

是否有可能讓處理器忙于一組資源限制？

本地高速緩存過多或過少的總體影響是什么？

是否對所有預期應用程序進行了充分建模，以確保它們在所需的處理器和共享資源集合上按預期運行？

為了了解并隨后預測更改對共享資源的影響，一些最先進的 SoC 設計團隊已經使用 SystemC 或類似語言構建了完整的系統模型。建立和維護這種復雜程度的投資可能超出了主流 SoC 設計團隊的能力范圍。即使使用這種方法，預測底層硬件的實際行為的能力（避免因后期實施意外而導致的昂貴的迭代周期所必需的）也由于這些建模環境（有限的準確性）而受到限制。

接口

傳統的 SoC 由人類交互時間和低性能數據移動驅動的輸入和輸出發生了巨大變化。SoC 上的接口數量、I/O 流量類型以及與系統中其他功能的 I/O 交互變得更加復雜。

例如，用于聯網家庭的設備可能具有無線網絡、傳統有線網絡、進出外部存儲的數據移動以及同時運行的視頻和音頻輸出服務。為每種可能的用途提供最大的能力——全速率千兆以太網，同時全速率訪問磁盤控制器、無線以太網控制器和 USB 2.0——并非不合理；問題是這些接口將如何與復雜的處理功能交互？在此示例中，將 I/O 與處理功能相結合可能涉及 16 個 I/O 流與六個主要處理功能同時運行，所有這些都共享公共 DRAM。這種情況比任何一種交互本身都復雜 100 倍。

IP復用

SoC 設計團隊可以奢侈地為設計中的所有 IP 使用單一標準接口的日子已經一去不復返了。幾乎所有 SoC 團隊都面臨著解決內部開發的舊 IP、內部開發的新 IP（通常由不同的組或部門）以及可能遵循不同接口標準的外部來源 IP 的互操作性問題的挑戰。

要使 IP 重用策略取得成功，各種標準之間的自動轉換至關重要。實現 IP 重用，包括測試套件、制造設計/良率設計和可靠性，排除了針對每個系統使用修改 IP。修改 IP（包括接口）會給設計進度增加太多風險。設計團隊必須保留大部分 IP，而是對系統中的其他 IP 進行調整，通常在自定義橋接器和總線適配器中。但是，手動執行此操作會使過程不可預測且不可擴展。一旦接口達到大于 1:1 的對應關系，交互復雜性就會迅速上升。

具有三種類型接口的簡單系統（對于大多數 SoC 團隊來說是典型的）涉及六種轉換：三種用于請求，三種用于響應。任何界面特征的變化都會將六種轉換乘以必須考慮的不同特征的數量。人為地限制這些特性是不現實的，因為這樣做會導致簡單功能的過度設計或妨礙復雜功能的性能。處理這種復雜性增加了可預測性的挑戰。

流量和帶寬

復雜 SoC 中管理的流量的性質和數量也發生了很大變化。諸如視頻和音頻之類的速率關鍵流量通常與面向處理器的流量混合在一起，后者往往具有更嚴格的延遲要求并以突發形式出現。再加上任何實時要求，例如可能對網絡流量施加的要求（必須在可用時提供千兆以太網以避免丟失數據）。在相互交互的各種功能中為這些不同的流量類型提供服務是很困難的。

然后，數據量會加劇這種復雜性。高清視頻需要至少 6 倍標清視頻的帶寬。在真實硬件的環境中分析這一點非常耗時，例如，運行足夠長時間的模擬以確定一組特定的 IP 功能及其交互是否可以正確管理視頻幀是不切實際的。因此，SoC 設計團隊專注于他們認為是最壞情況的幾種情況，并希望一切正常。然而，希望在 SoC 設計中并不是一個可預測的數量。

操作模式

幾乎所有 SoC 都以不同的模式運行。這些操作模式通常涉及以獨特方式交互的各種關鍵 IP 功能。不同模式的數量增加了分析和確定如何正確操作一組特定交互的復雜性。

例如，機頂盒 SoC 可能具有媒體提供兩個多媒體流的模式：一個流向顯示和音頻系統進行處理，另一個存儲在磁盤上。這種模式不同于硬盤提供輸出功能的模式，其中一個媒體輸入被放入存儲信息內的圖片窗口中。另一種模式可能會在解碼和顯示一個或兩個媒體輸入時從本地磁盤向網絡端口提供信息。可以很容易地看出，模式的數量極大地擴展了互操作功能和數據流的集合。確保所有這些模式都能正常運行，這使 SoC 設計團隊面臨的任務更加復雜。

這些系統復雜性問題相互疊加。即使設計人員需要重復設計、實現或驗證的一部分的可能性很小，但在所有這些問題上累積的小百分比使得通過設計流程中的一個或多個步驟進行多次迭代幾乎是必然的要求。

抽象級別不當

SoC 設計社區繼續依賴于為描述由門組成的各個功能而構建的語言和工具。這是一個很大的限制，因為這些語言（Verilog 或 C/C++/SystemC）不包含描述 IP 功能所必需的語法、概念和結構，以及復雜 SoC 中的交互。

如前所述，系統是復雜功能的組合，這些功能以各種方式進行交互，具體取決于所提供的整體功能。為了正確描述和分析系統交互，設計人員必須有一種方法來描述對正確操作至關重要的系統級方面。這可能包括重要時間窗口中的帶寬特征、特定操作模式內的流量并發、構成操作模式的不同交互以及交互影響彼此的方式。缺乏將這些方面捕獲為可以驗證的需求的方法會導致手動解釋的硬件的低級表示無法按預期執行的可能性很大。

先進的電源管理技術

在 65 納米及以下部署的復雜電源管理方法專注于控制工作頻率，同時改變部分 SoC 的電源電壓。雖然這種能力有巨大的好處，但整個部分可能會完全關閉以消耗“零”功率，并且對系統級設計的影響提供了額外程度的復雜性。

這不僅使時鐘分配和管理變得困難，而且還對必須如何控制數據移動施加了限制，具體取決于設備的哪些部分可能正在運行、未運行或以降低的速率運行。除了關閉之外，可以以兩種不同速率運行的設備的一部分使系統交互設計和分析復雜化了三倍。至少，子系統隔離、時鐘管理、電源關閉和適當的子系統恢復所需的附加電路使設備設計的所有方面都復雜化。同時，補充操作點增加了系統分析的復雜性，類似于或與操作模式復雜性相一致。

過程可變性

隨著工藝技術繼續向 65 nm 以下移動，單個設備操作的可變性會在本地和整個設備上引入電路功能和性能的不確定性。雖然統計靜態時序分析和其他技術有助于分析可變性影響，但它們不能提供減少可變性影響的解決方案。

為了適應可變性，額外的余量用于確保電路在面對可變性時能夠正常工作。這種額外的余量會降低性能或功能增益，否則這些增益可能會通過更高級的流程實現。最終結果是設計團隊能夠滿足在設計開始時設定的目標的保證較少。當然，直到設計后期才知道這一點，這可能會導致設計流程中某些步驟的迭代成本高昂。

總之，這些問題在當前 SoC 設計中引入的復雜性將可能的交互和需要考慮的情況的數量增加了幾個數量級。這個因素，加上缺乏適當的方法來指定系統級交互并在適當的抽象級別對其進行分析，使得設計 SoC 成為一項非常冒險、不可預測且因此成本高昂的業務。

審核編輯：郭婷