嵌入式硬體和軟體設計工具的優缺點，通常建立在設計者對於IP能否有完整的掌握度和能見度，以及在開始設計的時候，這些IP是否能夠被完整的取得。本文將探討SoC的系統模型是如何設計和如何提供附加價值給軟體開發者，並提供早期的虛擬原型（prototype），使IP更彈性的嵌入到設計工具中。

系統層級設計和模型

自從半導體理論上可以將整個系統整合到單一模型之中時，IP設計公司已經達到平台式設計的一個新紀元，並且鼓吹此種設計趨勢多年。但迄今為何尚未見到以平台為基礎設計IP的大流行呢？其關鍵就在於平台的範圍不夠大。現階段只有包括系統層級的設計（system-level design；SLD），這包括：RTL硬體定義、BUS架構、電源管理策略、裝置驅動程式、作業系統通訊埠和應用軟體。

而研發成功關鍵在於一個平台仍須可區分差異性的必要元素，這包括先進的系統模型和驗證環境。開發者需要來自RTL、系統模型、軟體開發模型和真正的硬體開發主板所提供的完整平台。

平台的每個部份都對應到相同的系統架構，設計者在任何高階的地方都可使用測試軟體來做驗證。在這個環境下，方便求出系統的頻寬和性能需求。系統規模一定要能夠擴展，允許設計者充分利用既有且經檢驗過的硬體IP和軟體IP之外，亦能利用自行研發的IP，來設計自己獨具的應用功能。而每個設計工作都有不同的方法需求，SoC設計者需要在每個設計階段擴增IP，舉例如(表一)。

在系統層級中，軟體的必需性相對重要，在過去要求軟體開發人員花費時間等待原型系統完成，不甚合理。軟硬體同步驗證能夠縮短整合的時間，縱使如過去一樣，提前到RTL設計完成時，開始進行同步驗證，仍然會延誤軟體的整合，因為大多數硬體設計已完成，並無法更改。此時系統和軟體設計者仍然缺乏共同的環境。

新一代解決方法為，首先使用SystemC定義系統，規劃設計流程，然後區分硬體和軟體區塊，並交給不同的軟硬體小組。此對軟硬體系統整合而言，是一個重大突破。軟體工程師不僅擁有一個平台可發展其軟體，亦擁有一個C++虛擬環境，可重覆使用既有的程式庫。

系統層級的抽象描述

定義任何新系統，從定義正式的規格到最後製成矽晶片和軟體執行檔（image），通常使用不同的抽象層來描述。共有五個抽象層用來涵蓋一個完整的系統。系統功能描述越詳細，產生的硬體功能越能滿足需求。這些抽象層與OSCI（Open SystemC Initiative）的技術提案有許多相似之處，其中不同之處，如(圖一)所示。

《圖一　SoC設計的五個抽象層》

在(圖一)中，平台設計的RT抽象層是用藍色描述，在這個層級上使用的語言是VHDL和Verilog，用以實現硬體。在RT層上方顯示的是交易層（transaction level），在此抽象層中，對共通開放標準的落實提供一種語言模型，主要是SytemC。平台模型本身可能使用對內核心模擬上更具效率的特殊模型格式（非SystemC），但是它們皆可以透過介面連接到SystemC的模擬核心。

在抽象的系統模型環境中﹐一定要支援下述的三個抽象層：

在系統層級建模的方法

沒有一種方法能完全適用於所有的系統，但是上述的抽象層方法對於一個系統的不同表示已盡可能達到。一個系統要在哪一個抽象層被實現，大部份是由系統設計者對此系統架構的信心，以及針對特殊的演算法開發出新架構的可行性而定。

對一個已知架構的系統，其中的實現細節，例如：不同匯流排的性能，並不為常人所知，下述方法可被利用。業界早已關注此方法，該方法是由RTL設計自然演進而來，而且硬體設計師對模型環境特別放心。

使用該方法，系統設計者能夠容易地將軟體和硬體區分。並且能夠從CC抽象層開始，對系統的性能做深入的調查。雖然演算法設計工具可能無法以正規方式獲取所需的規格，然而AL的主要任務並不一定是描述系統，因此演算法超出在系統層級使用IP來設計的討論範圍之外，在此將不涉及演算法設計工具。

微結構的設計

在CC層級建立系統模型，能夠讓設計者藉由粹取信號層級的細節內容導入每個交易中，因而能更有效率建立系統架構模型中每一細微部份。對一個完整的系統模擬，利用諸如SystemC這樣的建模語言和抽象技術，可以達到10～100KHz的速率。從單一的匯流排傳輸週期到一整個匯流排通訊協定週期，針對每一個時脈週期（cycle-by- cycle）CC層級都提供映射。在這個環境下，結合一些高價值的IP模型，並在單一週期到一整個通訊協定週期中，減少一些信號事件，這使模擬效率提高，處理速度可以加快。

通訊架構是由三個基本模型構成的：階級化的通道模型，負責管理每個元件的連接狀態；仲裁者，負責接受請求，並按照請求者的優先順序分配通道資源；解碼器，負責將位址解碼，進入特定的連接區段（傳入或送出）。仲裁者和解碼器本身雖然是硬體，但一般是希望能用SystemC模組來建立其模型，且每個SystemC模組之間是由單一介面相通。

此系統的主宰者（host）可能是處理器模型或記憶體控制器，而從屬者（slave）可能是周邊設備，例如：UART。主宰者是時脈模型，它產生資料結構形成匯流排的交易內容；處理器傳送這些資料到匯流排。從屬者也是時脈模型，它被匯流排驅動，接受由匯流排傳來的資料結構，並處理之。

此方法的重要部份是：轉換到RTL設計的能力和對整個系統保有一個驗證的基礎。利用SystemC模型的CC介面，可以進入RTL模型。以ARM為例，在SystemC模型中已經存在一個AHB匯流排之間交易的映射，和一個AHB硬體的各種信號，這個介面通常是通用型的（generic），並保證裝置能正確運作。

軟體的實現

微架構的主要優點是能夠將它當作韌體和中間軟體（middleware）的開發雛型（prototype）。一般而言，這是屬於指令集模擬（instruction set simulation；ISS）的範疇，但是在複雜的裝置裡面，軟體和硬體之間存在著即時的互動關係，很難利用ISS技術來觀察。典型的現代ISS包括簡單的周邊裝置之架構模型，它們在PV抽象層上操作，因此無法提供真實的系統層級資訊。

隨著硬體和軟體複雜性的增加，一個可替代ISS的技術逐漸流行，即利用FPGA來建立系統原型。這些工具可在真正的硬體上高速地執行軟體，通常允許硬體裝置，例如：網路裝置，彼此相互連接，傳輸真正的資料。針對正在目標板中執行的軟體，軟體開發者使用硬體除錯和追蹤工具，就能夠得到絕佳的偵錯能見度。當軟體開發者需要針對與作業系統緊密相關韌體做除錯時，則除錯工具必須提出作業系統的現況資訊，並提供作業系統層級的原始資訊，例如：執行緒（thread）和號誌（semaphore）等。

然而，這種原型系統的基本缺點是，在需要許多軟體工程師一起開發時，是很昂貴的。並且當硬體廣泛地完成後，軟體在開發週期上相對比較緩慢。和傳統的軟體開發工具相比較，在CC抽象層上建立系統模型不失為一個好方法，其優點有：@內標:(1)用來開發硬體微架構的工具，提供一個早期的系統原型，可執行完整的系統軟體。

(2)和軟體模型一樣，虛擬的原型能提供給許多軟體工程師使用。

(3)在CC層級上可以達到100KHz的速度，通常這對低階軟體開發是適合的，並且對於大型的開發，譬如作業系統的啟動（bring-up）也是適用的。

IP模型

對一個完整的系統模擬而言，想要能夠達到100KHz的速度，高品質IP模型是重要關鍵。業界已將SystemC當成系統層級的建模語言，現在的IP供應商已能提供標準模型給使用多種不同EDA工具的設計者。使設計者能夠結合最好的模型與最好的工具。

以ARM為例，它的微架構SystemC模型如(圖二)所示，ARM RealView模型程式庫結合ARM週期呼叫模型技術和最新的AMBA AHB週期層級介面（AHBCLI）

和ARM RealView除錯器。AHBCLI允許設計者在CC抽象層上建立完整的AHB模型，同時確保能完全遵守AHB通訊協定。

《圖二　ARM的微架構》

依據AHBCLI建模，界於ARM核心模型和AHB匯流排架構之間的傳輸完全是週期精確（cyclic-accurate）的，ARM核心模型和匯流排架構都是以共同的系統時脈來計時。AHBCLI可以將週期時脈映射到實際的電路轉換成接腳（pins），故允許RTL SystemC模型的直接連接，或可以和硬體描述語言（HDL）或邏輯閘模型一起模擬。這工具提供下列優點：

(1)驗證SystemC模型時，能夠對RTL週期性的檢驗。這對由上而下的設計方法是必需的。它亦支援由下而上的自動產生系統，這可由HDL-SystemC模型中自動抽取出來。

(2)能夠混合各種不同層級的模型。例如，將一個新功能區塊的系統層級模型置於RTL- SC（SystemC）中「精鍊」，同時維持系統的其它高層級和快速模型不變。此在「單元替換（unit-substitution）」的驗證方法中是很重要的。

(3)對ARM和AMBA用戶而言為簡單之事，實因介面的內涵容易映射到真正的硬體上。

架構的探索和開發

虛擬系統的原型

在(圖三)中，PV抽象層的輸出是一個虛擬系統的原型。它完整地將系統的功能模型化，而且針對一個軟體應用，提供程式設計者所必需的硬體。為達到這個目標，裝置的整個硬體功能都要在PV層上被模擬出來。

功能區塊設計的一重要因素是介面的設計：在一個系統中的元件要如何與其他元件溝通。在PV系統模型化中，一系統僅由一群IP元件組合成的。在這個抽象層上，設計者唯一關心的是哪些元件是需要溝通，而不是何時溝通（雖然排序亦很重要）。為了確保只有系統的功能，而不是即時資料（timing critical data）被包含在這個虛擬原型中，有關系統中每個裝置的時間回應資訊，不應該由軟體程式設計者來決定。

《圖三　SoC設計流程》

主宰者模組（master module）可能對系統時脈很敏感，或對系統的其他任何事件很敏感。但是設計者必須了解：時間準確的觀念是無法維持的。因此一旦啟動一個程序（process），大量工作可能將會被執行。PV抽象層提供設計者所需的工作時間最小單位（granularity size）的提示，大約是數個時脈週期。一個PV模型必須盡全力符合這個最小時間單位，而不會在計算已經過去的週期數量上，花費任何重大成本。

對於從屬模組，一般的期望是：它的傳輸功能必須立即傳回（return）資料結構，在此資料結構中包含著任何回傳的數據。並不期望它對任何事件敏感，或真正產生任何事件。

因為硬體架構的功能是在系統層級（SystemC）完成的，它必須和系統的環境模型（例如：虛擬面板）結合，為軟體開發提供一個系統原型。然後，軟體的實作就能在一個完整的系統環境中被檢驗。而且也可以同時在硬體空間中，進行標的比較（benchmarking）和硬體實作。

系統的性能模型

除了驗證新架構的功能外，架構設計者需事先了解此架構被實現後的表現如何。新技術藉此功能模型利用時序資訊來描述，並對系統中的每一個元件提供性能數據。當每一個時序模型通訊時，這些資訊可以被收集和對照，如此一完整的系統性能就可以獲得。PVT方法被用來開發系統性能模型，因為其為PV模型的延伸。因此時序和PV無關。由PV建構的系統性能模型在功能上是正確的。PVT不添加任何需要被傳輸的資料，而只提供資料何時要被傳輸的額外資訊。

PV和PVT之間的不同，可以從AMBA通訊協定中看出來。PV抽象介面層將AHB-Lite看成位址、數據、保護資訊、訊爆（burst）長度的組合。AHB-Lite的時序通訊協定是由HREADY信號來描述。在AXI通訊協定中，程式設計者心中的系統架構沒有改變，但是介面的時序問題變得更複雜，並且需要引用額外的時序來描述此通訊協定（AREADY、AVALID、RREADY、RVALID、WREADY、WVALID、BREADY、BVALID）。

在系統中，複雜的時序模組可能含有對時脈邊緣（clock edges）或其他事件敏感的元素。這些時序和與它們通訊的功能對象，完全交由IP設計者針對每個元件逐一解決。當傳輸作業已經在某元件的介面上進行時，此通訊將會通知該傳輸元件上的時序模組，和與它們相關的內部狀態之重要變化。

該層級的模型化將提供一個機制，藉此時序模組和系統時脈之間能彼此同步。這與週期呼叫模型的輸入和輸出相似，唯一不同是沒有傳送數據。在一個CC模型中，數據是在指定的時間內傳送。在一個PVT模型中，數據已經由PV模型送出，在數據被送出的時間點上，即由時序模組負責管理輸入和輸出作業。為便利設計，一般希望PVT時序模型的範例和CC抽象層是相同的。

IP模型的範例

如同CC模型一樣，高品質的IP模型也需要確定能夠達到PV和PVT的性能目標。PV抽象層的點對點傳輸通訊協定結合高速模型，目前約可達1MHz的速度。這對大多數的軟體開發而言是足夠，但是應用軟體通常需要更高的速度。這需要更新的模型，但是在業界公認的SystemC環境裡，目前還沒有這種模型出現。

(圖四)是ARM架構SystemC模型，包含ARM RealView模型程式庫、ARM ISS技術整合高效率的點對點介面。在PV抽象層上的介面標準定義現在正由OSCI的TLM工作小組擬定中。

在此系統中，模型之間的傳輸是點對點。ARM核心模型的記憶體介面是透過一個SystemC通訊埠將交易內容直接傳輸到匯流排目標系統的介面上。當一筆交易從DMA控制器經由一個具單一傳輸功能（Rx FIFO）的記憶體，傳送到系統的主記憶體時，DMA控制器將「攔阻（block）」其它傳輸作業，直到此傳送作業完成，且記憶體傳回數據為止。

結語

因為SystemC的發明，SoC的設計已進入群雄競逐的階段。雖然OSCI所制定的標準，目前尚未被任何一個正式的國際組織所承認和採用，但是它已儼然成為業界事實上的（de facto）標準。

國內設計16-bit以上SoC的公司目前都面臨著軟體開發困難的苦惱，本文所介紹的系統層級設計方法將是解決此問題的方法。

《圖四　ARM架構SystemC模型》