引 言
SoC(system on chip) 是微電子技術發(fā)展的一個新的里程碑，SoC不再是一種功能單一的單元電路，而是將信號采集、處理和輸出等完整的系統(tǒng)集成在一起，成為一個有專用目的的電子系統(tǒng)單片。其設計思想也有別于IC，在一個或若干個單片上完成整個系統(tǒng)的功能。
SoC開發(fā)和設計存在一些問題，如描述語言不統(tǒng)一、抽象層次低、仿真速度慢、可重用性差、設計性能無法保障、RTL級發(fā)現(xiàn)的問題需要重新進行整個的設計流程才能解決，因此SoC的建模與設計的方法成為當前刻不容緩的課題。上述種種問題與曾經困惑軟件業(yè)的“軟件危機”的表現(xiàn)非常類似，為了解決軟件危機，人們提出了軟件工程。因此，本文的思路是將軟件工程中應用最為廣泛的面向對象技術引入到SoC設計當中。
設計模式是面向對象的精髓，在軟件中已經得到了廣泛的運用，在SoC設計中使用設計模式，可以降低軟硬件開發(fā)之間的鴻溝，對于軟硬件協(xié)同設計有很大的幫助，使系統(tǒng)得到更大的可伸縮性。
SoC設計方法學
傳統(tǒng)的設計方法
在傳統(tǒng)SoC設計過程中，系統(tǒng)一開始就被劃分為軟件和硬件2大部分，軟件和硬件獨立進行開發(fā)設計這樣隱含一些問題，如軟硬件之間的交互受到很大限制、軟硬件之間的相互性能影響造成很難評估和系統(tǒng)集成相對滯后，導致設計質量差、設計修改難和研制周期不能有效保障。
傳統(tǒng)SoC設計流程中，EDA設計方法只作用于SoC后級，缺乏SoC前級設計方法與系統(tǒng)驗證策略，從而導致了RTL電路模型中錯誤成分復雜化與驗證人工開銷激增. 另外，軟件開發(fā)者必須等到硬件的設計和結構都完成并通過驗證之后，才能開始軟件的設計和實現(xiàn)，所以開發(fā)的周期將會持續(xù)很長，產品的競爭力會因此而下降.
基于模式的設計方法
針對傳統(tǒng)設計方法的不足，新的SoC設計方法應該在行為級就開始建立仿真模型和進行行為與結構的驗證，同時必須強調結構化、封裝和重用硬件設計在高層次的抽象的重要性。
因此，本文提出基于模式的SoC設計方法PBSOC ，如圖1所示，強調高層次的系統(tǒng)建模，更有利于設計的復用. 在需求分析階段，根據(jù)規(guī)格說明，使用面向對象的分析方法，給出用例的關系和順序圖. 在系統(tǒng)級設計階段，使用統(tǒng)一的語言SystemC進行軟硬件協(xié)同設計。SystemC是由Open SystemC Initiative (OSCI) 提出和維護的開放源代碼的基于C++統(tǒng)一軟硬件建模平臺. 軟硬件模塊都用C++ 描述，對不同軟硬件劃分方案的評估和權衡可以方便地進行。
PBSOC使用形式化方法和面向對象的Petri網對系統(tǒng)的行為和結構建模，不涉及任何結構和時間的細節(jié)，并通過實時UML進行可視化的描述. 它不僅具備傳統(tǒng)面向對象方法所具有的風格，而且具有Petri網直觀模擬系統(tǒng)動態(tài)行為的優(yōu)點，從而能夠更加簡潔、清楚地描述系統(tǒng)的靜態(tài)結構和組成元素之間的層次關系。將Petri網思想引入面向對象建模當中，可將系統(tǒng)看作是一些相互作用的對象組成的集合。集合中的每個對象都具有自己的屬性和任務，它們根據(jù)收到的消息、句柄等來完成相應的任務，從而實現(xiàn)系統(tǒng)的整體功能.在系統(tǒng)級建立面向對象的設計模式庫和IP復用庫，OO庫即面向對象數(shù)據(jù)庫，主要存放的是各種SoC設計模式(pattern) ，在SoC系統(tǒng)框架設計、IP設計以及IP通信設計中都可以使用模式。IP庫中存放的可以是普通的IP核，即其他廠商設計的成熟的IP；也可以是用面向對象的方法設計的一些IP 核，即IP 的設計過程也遵從于PBSOC。
圖1 PBSOC 設計框架
SOC設計的設計模式
設計模式
模式是解決某一類問題的方法論，它把解決某類問題的方法總結歸納到理論高度。雖然模式起源于建筑，但其思想也同樣適用于面向對象設計模式。指導模式設計有3個重要概念，即重用( reuse) 、接口與實現(xiàn)分離和低耦合(loose couple)。重用是系統(tǒng)的設計目標，主要通過繼承(inheritance) 和對象復合(composition) 實現(xiàn). 接口與實現(xiàn)分離指接口保持不變，用分離帶來靈活性，主要表現(xiàn)形式為多態(tài)性(polymorphism)。低耦合可以降低復雜性。
現(xiàn)存的硬件設計模式和重用方法主要是處理RTL(寄存器傳輸級) 設計和編碼的。這種在設計過程中積累的經驗在設計重用時是非常重要和有用的，然而并沒有涉及系統(tǒng)級設計的問題。因此在系統(tǒng)級應用面向對象的方法可以克服這些鴻溝，使用設計模式還可以更快速和直觀地捕捉設計的內容，提高設計的可理解性，將抽象的級別上升到系統(tǒng)級，能夠處理更復雜的硬件設計。
SoC設計模式
SoC的設計模式與軟件的設計模式的不同，主要在于軟件和硬件的設計差別。SoC的設計不僅包括軟件，還有硬件以及軟硬件的協(xié)同設計，因此，它涉及物理約束、實時性和并發(fā)等關鍵問題。所以要將軟件的模式進行改造，并使用軟硬件通用的描述語言進行描述。
軟件設計模式中運用得比較多的面向對象方法是繼承，它同樣適用于SoC的設計模式當中，但必須考慮SoC系統(tǒng)中的物理約束。一些軟件設計模式，主要是創(chuàng)建型模式，能夠動態(tài)地生成系統(tǒng)的對象，而SoC系統(tǒng)中硬件部分結構是靜態(tài)的，因此，它們不適合于SoC硬件部分設計模式，但是對于SoC系統(tǒng)中的軟件模塊還是可以適用的，例如原型模式和命令模式等。
大部分的結構型模式只需要稍做修改就可以應用到SoC設計中，主要是實現(xiàn)方式的問題，即用軟硬件通用的語言來重新描述它。而行為型的模式，需要加入實時系統(tǒng)中一些約束。對于典型軟件模式改造的前提和目標是設計的可重用性，主要是SoC系統(tǒng)級設計的可重用。在SoC中FSM(有限狀態(tài)機) 是最常用的一種行為表達方式，因此狀態(tài)轉換的頻率是非常多的.如下面的狀態(tài)模式，通過改造，可以用于描述硬件設計。
新的SoC設計模式的提出是PBSOC 最終的目標。它主要針對的就是高層次SoC設計中最常用的一些設計方法，以及構筑SoC系統(tǒng)的基本組件和基本結構
，如層適配模式(layeradapter pattern) 和包裝器模式(wrapper)。本文僅給出了模式的結構，具體的實現(xiàn)不在此贅述。
(1) 狀態(tài)模式(state pattern)
狀態(tài)模式的意圖是使一個對象在內部狀態(tài)改變時可以改變自己的行為，從客戶看來，好像對象改變了它的類。即不同的狀態(tài)，不同的行為；或者說，每個狀態(tài)有著相應的行為.考慮SoC片上總線協(xié)議， 片上總線總是有3 個狀態(tài): 閑( IDL E) 、忙(BUSY) 和關閉(CLOSE) . 而各個狀態(tài)的處理過程不一樣. 如圖2 所示，BusProtocol 類維護一個表示總線當前狀態(tài)的狀態(tài)對象(一個BusState 子類的實例) . BusProtocol 類將所有與狀態(tài)相關的請求委托給這個狀態(tài)對象. BusProtocol 使用它的BusState 子類實例來執(zhí)行特定于連接狀態(tài)的操作. 一旦總線狀態(tài)改變， BusProtocol 對象就會改變它所使用的狀態(tài)對象. 例如，當片上總線從閑置狀態(tài)轉為忙狀態(tài)時，BusProtocol 會用一個BusBusy 的實例來代替原來的BusIdle 的實例。
圖2 狀態(tài)模式的系統(tǒng)結構
State 模式不指定哪一個參與者定義狀態(tài)轉換準則. 如果該準則是固定的， 那么它們可在Context 中完全實現(xiàn). 然而若讓State 子類自身指定它們的后繼狀態(tài)以及何時進行轉換， 通常更靈活、更合適. 這需要Context 增加一個接口， 讓State 對象顯式地設定Context 的當前狀態(tài)。
首先定義類BusProtocol ，它提供了一個片上總線的基本協(xié)議通道并處理改變狀態(tài)的請求。BusProtocol 在state 成員變量中保持一個BusState 類的實例。類BusState 復制了BusProtocol的狀態(tài)改變接口。每一個BusState 操作都以一個BusProtocol 實例作為一個參數(shù)， 從而讓BusState 可以訪問BusProtocol 中的數(shù)據(jù)和改變總線的狀態(tài)。BusProtocol 將所有與狀態(tài)相關的請求委托給它的BusState 實例state。BusProtocol 還提供了一個操作用于將這個變量設為一個新的BusState。BusProtocol 的構造器將該狀態(tài)對象初始化為BusIdle 狀態(tài)。
(2) 層適配模式
層適配模式為SoC通信建模提供分層的協(xié)議轉換，將不同架構的網絡協(xié)議通過接口的匹配，實現(xiàn)各層次的數(shù)據(jù)通信，提供事務級建模各層的適配方式。系統(tǒng)建模中通信機制可以分為4 層，其中事務級建模分為3 層，即除L0 之上的3 層為事務級。其中：L3 為消息層，這一層沒有任何的時間信息，系統(tǒng)行為是事件驅動的，并建立點到點的通信. L2 為事務層，這一層的系統(tǒng)模型帶有時間信息，但并不是時鐘精確周期，系統(tǒng)是時間驅動執(zhí)行的。
事務層將理想的結構映射到需要考慮資源分配和設計約束的結構中，完成SoC體系結構的分析和建模，并開始軟件的開發(fā)。L1為傳輸層，它在RTL層之上，系統(tǒng)由精確到周期的行為組成，但比RTL 級的仿真速度要快。傳輸層建模一般對應一定的總線協(xié)議，將精確到周期的協(xié)議映射到給定的硬件接口和總線結構上，隱藏了接口的管腳，將事務直接映射到總線周期。層適配模式將通過適配完成各層次的模型轉換。如圖3 所示，TL1 Master Adapter通過適配TL1通道和TL2 通道，使TL1 Master 和TL2 Slave 通信。
圖3 層適配模式結構
(3) 包裝器模式
包裝器模式的目的是通過調整接口和IP 組件的行為來適應特定的應用環(huán)境，它屬于結構型模式.在SoC設計中，功能組裝正在逐漸代替功能設計，而成為主流的設計方法。因此，各個IP模塊的互連，以及與片上總線的通信成為研究的重點。IP的本質特征是可重用性，通常必然滿足以下基本特征:通用性好，正確性有保證，可移植性好。因為許多IP在設計之初都是針對特定的應用，而很少考慮到要與外來電路搭配使用。IP的定義沒有一個通用的接口標準，因為芯片實現(xiàn)的功能千差萬別，性能方面的要求也由于應用領域的差異而不同，即使同樣功能的IP模塊在速度、面積、功耗、對外接口等方面也表現(xiàn)各異包裝器模式的系統(tǒng)結構如圖4 所示。
圖4 包裝器模式的系統(tǒng)結構
通過包裝器模式的封裝，能適配各種IP 接口。即使用包裝器模式來調整組件接口以適應于環(huán)境要求。包裝器模式的匹配程度，對IP Component 的接口與其他的接口進行匹配的工作量各個WrapperModel 可能不一樣。從簡單的接口轉換(例如改變操作名) 到支持完全不同的操作集合，WrapperModel 的工作量取決于Component 接口與需要轉
換接口的相似程度。
結束語
在SoC設計中，可重用性是應該考慮的一個很重要的因素. 除了IP復用，設計的可重用也是非常重用的。在討論將現(xiàn)有軟件設計模式應用到SoC設計當中后，提出了SoC設計模式，主要針對高層次的SoC設計中的最常用的一些設計方法，以及構筑SoC系統(tǒng)的基本組件和基本結構。除了上述的3 種模式，還提出的一系列的SoC設計模式中，總線模式屬于體系結構的模式，包裝器模式和層適配模式屬于結構型模式，總線協(xié)議模式、管道模式和FSM模式屬于行為型模式。下一步的工作是深入研究系統(tǒng)級設計方法，以及基于UML的軟件設計模式描述如何自動地轉換為元(meta) 程序。