過去，邏輯驗證是大多數SoC研發業者所遇到的瓶頸。因為SoC電路設計的快速攀升，讓硬體驗證工作的複雜度呈現急速激增的現象。

現在，嵌入式軟體研發則是SoC研發業者在開發流程中所面臨的最大挑戰。目前SoC有超過五成的成本是使用在開發趨動程式、開機程式碼、與硬體相關的通訊協定堆疊、DSP演算法及其他嵌入式軟體。隨著軟體在新世代的設計中扮演愈來愈重要的角色，業者花在軟體上的成本也會愈來愈多(如圖1所示)。

《圖一　IC設計的軟體內容的花費成本》

SoC所面臨的難題，主要是實際晶片的開發與相關軟體設計兩者之間所存在的時間差問題。傳統的SoC軟體研發業者，必須等到硬體研發團隊設計出實體的原型元件後，才有可供參考的硬體環境。因此，軟體研發必須等到硬體工程師設計出完美的元件後才能動工。隨著市場上產品生命週期的縮短，以及激烈的競爭壓力，研發流程延遲不僅只是成本增加，更會影響產品獲利。

SoC研發業者需要的是能減低這種在軟、硬體設計上循序式進行的全新研發策略。這個策略可讓SoC研發業者能快速的將通過驗證的硬體IP整合到可量產的硬體核心系統。此外，它必須能建構在開放式架構上，讓SoC研發業者能很容易的將這些不同的IP供應商所推出最頂級的IP元件緊密整合到其設計中。最後，藉由同步的軟、硬體設計，能讓SoC研發業者在硬體設計完成之前，提早進行軟體撰寫與除錯作業，進而大幅減少研發成本與縮短上市時程。

平台式的設計流程

SoC與嵌入式系統的平台式設計方法，廣獲SoC研發業者與使用者的支持，平台式的方法提供許多吸引人的優勢。IC設計日趨複雜，加上65奈米以下微米製程衍生的許多物理效應，設計生產力逐漸落後， SoC設計的難度變得愈來愈高，導致SoC的設計成本大幅攀升。現在，設計大多使用可合成CPU核心，備有超過50萬個邏輯閘，並採用可撰寫數十萬行程式碼的Linux嵌入式系統。SoC研發業者迫切需要一個可協助他們在最短的週期內研發出第一次就成功的理想設計開發環境。

以平台為基礎的設計方式提供高度整合的共用架構，讓研發人員輕易且迅速開發SoC，並加入各項常見功能。此外，與其使用各種客制化的設計方法，不如運用預先設計與規劃的元件。藉此能加快設計流程，排除持續攀升的上市時程壓力。重複使用現有的IP模塊，讓元件成本可由多個SoC專案中均分，協助降低開發成本 。

平台化模式也協助SoC設計業者應付越來越複雜的設計趨勢，滿足市場需求。平台化的架構讓研發業者僅須加入或取代少量的IP元件，就能快速開發各種衍生產品。此外，預先整合的架構能減少在驗證上可能會大幅增加研發團隊工作量及不確定因素的風險。最後，在設計中運用其他已完成的模塊，讓研發人員能將資源投入在自己的核心技術上，專心發展與眾不同的獨特功能。

隔離硬體

加速軟體開發的其中一項關鍵，是使用基本硬體介面，或硬體抽象層(HAL)，讓軟體相容性不影響的情況下能在任意更換底層的硬體。在理想狀態下，也可以延伸至外部廠商提供的任何IP模塊。目前多數的平台式設計方法採用HAL，將硬體與作業系統合作加以隔離，並提供一致的硬體平台，讓應用軟體不論在何種硬體組態下都能順利運作。

在這個平台化模式中，HAL在軟、硬體間提供一個抽象層。抽象層元件都有基本硬體核心，並內建各項關鍵功能可提高系統效能。這些元件包括記憶體子系統、中斷、以及晶片內建互連介面。於硬體核心的最裏層，含有一個採用交叉交換匯流排架構的系統控制器。這系統控制器能針對低延遲與高頻寬應用進行最佳化調校。也為SDR與DDR/DDR2系統記憶體提供一個能以記憶體控制器連結到互連架構的高效能介面。此外，再搭配一個高度優化L2快取控制器，能降低記憶體傳輸延遲並降低系統成本(如圖2所示)。

《圖二　SoC-it的硬體核心》

HAL也支援大多數嵌入式系統使用的常見週邊元件，像即時時脈(RTC)、序列埠(UART)、以及各種通用型I/O(GPIO)。能讓設計人員選用不同廠商的週邊元件，卻還維持軟體的相容性。重要的是，硬體核心與HAL都是開放式架構，並為軟體提供穩定的移植平台。

這種設計方法與其他平台式開發策略最大的不同就是能簡化趨動程式的開發流程。大多數的HAL都能彌補系統CPU差異。在此平台中，經過優化設計的HAL，還能彌補週邊元件的差異。

以乙太網路控制器為例，在高階驅動程式的部份，都極類似。在低階驅動程式的部份，為讓特定的控制器能支援所需要的功能或達到最高的速度，程式撰寫的方法就有明顯的差異。在此新平台模式中，驅動程式的低層部份歸屬在HAL內。驅動程式被整合到平台的IP模塊中，軟體只需將上層部份的驅動程式移植到API，由API與低層的驅動程式元件進行互動(如圖3所示) 。

《圖三　MIPS的SoC-it開發平台》

此開發策略大幅簡化驅動程式的開發流程。由於軟體移植平台在HAL API方面都一致，只要控制器支援相同的作業環境，不論研發人員為了避免修改驅動程式而選擇何種乙太網路控制器，就不會有任何問題。針對每個支援的運作環境，研發人員僅須開發一個驅動程式即可。這不僅簡化驅動程式的開發流程，也藉此縮短產品上市時程，更確保硬體元件維持相容。

降低效能的下降幅度

SoC研發業者在運用整合不同廠商IP元件的平台化設計方法時，所面臨的一項重要問題就是在重複使用功能元件時，為了享受彈性與便利性，必須犧牲多少效能。在大多數平台式設計方法中，研發人員常得為了享受通用API所帶來的便利性與彈性，而犧牲可觀的效能。此新設計方法將針對不同種類的元件使用不同的API，藉此大幅減少效能下滑的幅度。例如，使用針對網際網路控制器進行優化設計的API，以及另一種針對DSP控制器進行優化的API，讓平台能透過一個特性化的模塊來滿足這些特殊功能的效能需求，並同時維持使用同一個API所帶來的便利性及加快研發流程的利益。在這項情況中，研發人員可將高階的元件驅動程式移植到HAL API中成為特定類型驅動程式。如此，針對每個作業環境，每個驅動程式僅須撰寫一次。自此之後，即可任意更換硬體，而不必修改任何軟體。

此法與其他設計模式間的重要差異，就是讓設計人員有機會運用一個SoC設計開發出多個衍生產品。以往，較高抽象層的軟體模型，都無法提供足夠的效能，來支援真正軟硬體共同設計的模式。但近來ESL技術的演進，讓業界克服這項限制。

有別於其他模式，這項平台能從設計流程的初期，一直到完成RTL的設計開發，全程支援虛擬系統模型的設計工作。同時，它也讓設計人員在各個研發階段，能將平台視為一個虛擬系統模型、模擬機板、或是實際的SoC。平台由可合成的RTL模式實現，或由SystemC 模型模擬抽象層中不同種類的元件。這些模型也相容於市面上常見的電子系統層級(ESL)工具。

能在不同抽象層級中存取相同IP模塊的內容，加上確保軟體不必修改就能繼續運作，是勝過現有平台設計方法的重要優勢。這讓硬體平台能在不同的研發階段中，提供穩定的軟體移植環境。更重要的是，將平台匯入到一個虛擬系統原型ESL模型中，讓研發人員能在軟體檢驗流程的初期就開始工作。透過這些模型，研發人員可檢驗系統模型的連結狀況，相較於傳統的設計方法，能提早在設計週期階段就展開軟體的設計工作，而且早在硬體完成設計之前就開始撰寫程式。

結論

隨著SoC設計日漸複雜，時脈速度不斷攀升，加上內建愈來愈多的功能，工程師必須在晶片開發週期中儘早取得設計平台。快速驗證架構，並確保IP能相容運作，是一項極為重要的優勢。此外，儘早展開軟體開發，研發人員能快速排除潛在錯誤、降低風險、以及加快產品上市時程。

這樣的平台式設計方法，讓設計業者朝這個目標邁進一大步。儘早發展出代表整體設計的原型方案，能早在硬體完成設計之前，就展開費時的軟體設計程序。此平台運用創新的模式來隔離軟、硬體的設計，並簡化不同廠商IP的整合工作，大幅加快軟體設計流程。

（作者為MIPS Technologies技術長）