實現具備軟體意識的SoC設計方式

System Realization產生立即可供應用軟體部署使用的完整硬體/軟體平台，SoC Realization確保單一SoC的成功開發以滿足系統需求。通常，晶片完成時，SoCs就會被視為「完成」。然而除非各硬體子系統的軟體裝置驅動程式完成，否則SoC Realization就不算完成。這些驅動程式應該與SoC一起開發，而不是稍後再開發，這會改變對於如何提供晶片IP的新看法。

與其將IP視為獨立「區塊」，建議IP集合應該包含「bare-metal」和硬體IP。Bare-metal軟體就是OS層以下的一切，而bare-metal軟體最重要的功能就是裝置驅動程式。以下所述IP集合也包含驗證IP功能與整合的驗證IP (VIP)。該集合也可包括有固定布局的硬體巨集(hard macros)搭配可合成的register-transfer level (RTL)或transaction-level modeling (TLM)層次IP；也包含設計限制。

在傳統的SoC設計方法中，首先建立硬體後再撰寫驅動程式，通常由不瞭解硬體詳情的人撰寫。因此造成兩個很壞的情況：其一是昂貴的客製化驅動程式開發工作，由很少硬體知識或者鮮少或沒有OS知識的硬體人員來負責；其二是購買一般性驅動程式，由對特定硬體與OS之間關係只有一般性瞭解的人員撰寫，而無法發揮硬體的全部功能。

無論哪種狀況，應用軟體都與基本硬體系統沾不上邊。結果應用軟體與硬體之間的連結非常脆弱。雖然最後建立的系統或多或少有些作用，但或許是次佳的、過度設計或設計不足的、延誤，並且因太過於昂貴而無法獲利。若驅動程式是IP集合的一環，就應該將完整的基本硬體功能呈現給作業系統。這樣可讓OS更容易直接控制或架構硬體資源，以滿足應用軟體之需。

同時，設計限制納入IP集合也很重要。最常見的限制在於功耗、時序與面積。這些限制來源各異，包括功耗的共通電源格式(Common Power Format；CPF)檔案、邏輯合成的時序腳本，和類比區塊的實際佈侷限制。限制就是設計意圖的表達，應該是在設計循環的非常早期就已經開發了。

為了維護設計意圖，限制必須涵蓋到整個設計、驗證與設計實現階段，才能夠填補生產力鴻溝。如果沒有徹底瞭解設計限制，將IP整合到SoC的過程就會變得很困難，而且錯誤百出。Bug很可能出現在IP子系統之間的介面中，可能會危及整體系統功能或者故障，而且驗證成本更加昂貴。所以，妥善規範的全套設計限制就是「立即可供整合」IP的重要關鍵。應該為集合中的所有部分備妥限制，包括類比硬體巨集、可合成的數位IP和驅動程式軟體。

更廣泛的SoC定義

考慮到當今的SoCs越來越複雜，確保子系統之間的高效率通訊，更為重要。如果通訊架構不能勝任，就很難在設計實現階段將這些子系統連結在一起。因此需要更加理解SoC Realization架構階段的通訊網路。更新的晶片通訊做法稱為「晶片上網路系統(network on chip，NoC)」實現更高的多核心SoCs彈性。

目前為止一直都使用傳統SoCs定義。但在軟體定義的SoC Realization，驅動程式是配合各子系統而提供的。驅動程式讓OS能夠直接駕馭各子系統中專屬的硬體功能，包括晶片上通訊網絡。當眾多IP集合組裝成為IP子系統時，SoC Realization最有效率。反之，這些也支援主要的硬體子系統，例如I/Os、CPUs或記憶體。IP必須也為整合而最佳化。設計限制是這種最佳化中重要的一環。

IP集合的內部

傳統上，大部分數位晶片IP都包含控制器層與實體層(PHY)。對於PCI Express或USB等以標準為基礎的IP而言，控制器通常是「軟性」或可合成的IP，而PHY通常是「硬性」的，表示合成與布局都已經完成。現在軟性IP通常建立在RTL；越來越多轉移更高階的abstraction、TLM，容許更快速的設計與驗證，以及微架構的選擇。TLM也能夠用來建立虛擬原型，實現早期軟體驗證。能夠獲得高品質成果的SystemC高階合成最近開始供貨，移植到TLM所需的必要工具已經齊備了。

以TLM為基礎的數位IP只是其中一環而已，驗證IP更應該納入為IP集合的一環。VIP提供驗證IP組態與整合時必要的複雜testbench。除了testbench之外，現在還有VIP可搭配protocol相符管理，支援assertion、以transaction-based的加速，以及模擬用的速率轉接器(rate adapters)。

由於幾乎所有SoCs都是混合訊號的，IP集合可能也會包含一些類比硬體巨集。晶片層、混合訊號驗證是SoC與系統設計人員當前所面對的最嚴苛挑戰之一。藉由開放整合平台(Open Integration Platform)的全新觀念。當IP建立者提供驅動程式時，就不再需要或只需要極少硬體知識即可在事後建立硬體。當IP供應商納入限制時，SoC整合者就能夠自信滿懷地組裝IP集合與子系統了。

開放整合平台(Open Integration Platform)

SoC整合涉及3大步驟：
1.分析架構：系統設計人員基於應用軟體需求，執行假設性分析(業務與技術)，開發SoC的整體計畫，並定義處理器、I/O與記憶體等組成要素。定義bare-metal軟體，讓OS層能夠控制硬體。現在已經有晶片規劃工具可以快速執行功耗、面積與成本的假設性分析，發揮一些助益。

2.開發或搜尋為整合而最佳化的IP：無論來自於內部或第三方廠商，設計人員都必須能夠從許多來源找到最適合於應用軟體的IP。這需要catalog或IP library，以便進行技術與成本比較，還要有工具，以便進行功耗、效能與成本的假設性分析。在某些狀況下，設計人員會決定建立為整合而最佳化的IP。為整合而最佳化的部分需求如下：

‧ 功能必須妥善定義並記錄
‧ 提供來源、合成與設計實現討裝以便整合
‧ 備妥含特性資料的晶片驗證IP
‧ IP符合規定的品質方針
‧ IP區塊已經參數化
‧ IP集合配備設計限制
‧ IP測試平台配備硬體與驅動程式用的完整驗證環境
‧ 交付事項包括所有必要腳本、指南、查檢表與文件

3.整合IP以實現SoC：運用個別的IP區塊，會使整合變成令人卻步的任務。當IP組織成為預先驗證、為整合而最佳化的子系統時，事情就會變得更容易了。生產力仍是SoC Realization流程中重要的一環，對彌補獲利鴻溝的工作也有貢獻。

益華電腦(Cadence)提出的「開放整合平台(Open Integration Platform)」提供一個框架，以便在其中執行這些步驟。這是由整合設計環境(Integration Design Environment)驅動，類似於軟體開發人員使用的IDE (Integrated Development Environment)，提供周延的全套功能以開發現代的SoCs，使生產力與獲利力雙雙臻於極致。這個環境以開放式標準為基礎，例如OpenAccess資料庫、開放試驗證方法(Open Verification Methodology，OVM)、IP描述用的IP-XA CT格式以及SystemC TLM 2.0建模標準。

設計人員從這個SoC-IDE (Integration Design Environment)開始，進入客戶專屬而且應用軟體專屬的需求，然後帶入來自於內部或外部的IP子系統。可能需要使用第三方客製化服務，以提供短期間所需的專業 — 例如，帶入一些類比專業知識解決以混合訊號子系統為核心的任何問題。整合者能夠設計、驗證和設計實現任何所需的其他IP，然後組裝和驗證完成的SoC，提供製造或交接(handoff)所需的全部資料。

SoC-IDE為基礎設計、驗證與設計實現工具提供「儀錶板」，因而充分發揮既有的功能，例如數據導向驗證、低功耗設計、混合訊號設計實現與驗證，以及硬體/軟體整合。這些功能將不斷地演進，以滿足SoC整合者的需求。這裡所述的SoC Realization吸引設計人員在需要的時候建立為整合而最佳化的IP，以整合內部建立和外部取得的IP，然後驗證SoC並使其最佳化，以滿足系統需求。因此，這些彌補獲利鴻溝的步驟「建立、整合、最佳化」也是SoC Realization的關鍵。

結論

SoC Realization的EDA 360視野需要更廣泛的SoCs定義，包括bare-metal軟體，搭配將IP視為「集合」的更周延方法，從實體層與通訊協定(控制)層到驅動程式，還有相關的驗證IP與設計限制。以鞏固軟體及硬體之間的脆弱連結，讓應用軟體能夠一路貫穿OS而作業，執行所需的恰到好處的硬體資源。

為了支援這個SoC Realization願景，需要新的技術。第一步就是讓IP建立者更容易建立驅動程式；第二步就是透過metric-driven IP驗證指出哪些IP重複驗證是不必要的。Cadence EDA 360提供開放整合平台(Open Integration Platform)，能夠執行假設性分析以判斷最佳的可能架構與整合，開發初始的SoC架構，並快速地整合驗證過的IP成為驗證過的SoCs。

因此，EDA公司、嵌入式軟體與OS供應商、IP供應商、晶圓廠與使用者公司必須通力合作，使IP定義擴及於bare-metal軟體與整個子系統。藉此將開啟邁向高獲利、應用導向System Realization的機會之門。不必花費時間與金錢僱用專家開發客製化驅動程式，或者忍受「一般性」驅動程式的不便，SoC整合者可擁有能夠發揮基礎硬體功能的驅動程式軟體。不必盲目奔忙於整合問題，SoC開發人員可以享用constraint-driven的整合方法。[嵌入式世界專欄每週二刊載]