基于模式的SoC設計方法研究

　　SoC(system on chip) 是微電子技術(shù)發(fā)展的一個(gè)新的里程碑，SoC不再是一種功能單一的單元電路，而是將信號采集、處理和輸出等完整的系統集成在一起，成為一個(gè)有專(zhuān)用目的的電子系統單片。其設計思想也有別于IC，在一個(gè)或若干個(gè)單片上完成整個(gè)系統的功能。

　　SoC開(kāi)發(fā)和設計存在一些問(wèn)題，如描述語(yǔ)言不統一、抽象層次低、仿真速度慢、可重用性差、設計性能無(wú)法保障、RTL級發(fā)現的問(wèn)題需要重新進(jìn)行整個(gè)的設計流程才能解決，因此SoC的建模與設計的方法成為當前刻不容緩的課題。上述種種問(wèn)題與曾經(jīng)困惑軟件業(yè)的“軟件危機”的表現非常類(lèi)似，為了解決軟件危機，人們提出了軟件工程。因此，本文的思路是將軟件工程中應用最為廣泛的面向對象技術(shù)引入到SoC設計當中。

　　設計模式是面向對象的精髓，在軟件中已經(jīng)得到了廣泛的運用，在SoC設計中使用設計模式，可以降低軟硬件開(kāi)發(fā)之間的鴻溝，對于軟硬件協(xié)同設計有很大的幫助，使系統得到更大的可伸縮性。

　　SoC設計方法學(xué)

　　傳統的設計方法

　　在傳統SoC設計過(guò)程中，系統一開(kāi)始就被劃分為軟件和硬件2大部分，軟件和硬件獨立進(jìn)行開(kāi)發(fā)設計這樣隱含一些問(wèn)題，如軟硬件之間的交互受到很大限制、軟硬件之間的相互性能影響造成很難評估和系統集成相對滯后，導致設計質(zhì)量差、設計修改難和研制周期不能有效保障。

　　傳統SoC設計流程中，EDA設計方法只作用于SoC后級，缺乏SoC前級設計方法與系統驗證策略，從而導致了RTL電路模型中錯誤成分復雜化與驗證人工開(kāi)銷(xiāo)激增. 另外，軟件開(kāi)發(fā)者必須等到硬件的設計和結構都完成并通過(guò)驗證之后，才能開(kāi)始軟件的設計和實(shí)現，所以開(kāi)發(fā)的周期將會(huì )持續很長(cháng)，產(chǎn)品的競爭力會(huì )因此而下降.

　　基于模式的設計方法

　　針對傳統設計方法的不足，新的SoC設計方法應該在行為級就開(kāi)始建立仿真模型和進(jìn)行行為與結構的驗證，同時(shí)必須強調結構化、封裝和重用硬件設計在高層次的抽象的重要性。

　　因此，本文提出基于模式的SoC設計方法PBSOC ，如圖1所示，強調高層次的系統建模，更有利于設計的復用. 在需求分析階段，根據規格說(shuō)明，使用面向對象的分析方法，給出用例的關(guān)系和順序圖. 在系統級設計階段，使用統一的語(yǔ)言SystemC進(jìn)行軟硬件協(xié)同設計。SystemC是由Open SystemC Initiative (OSCI) 提出和維護的開(kāi)放源代碼的基于C++統一軟硬件建模平臺. 軟硬件模塊都用C++ 描述，對不同軟硬件劃分方案的評估和權衡可以方便地進(jìn)行。

　　PBSOC使用形式化方法和面向對象的Petri網(wǎng)對系統的行為和結構建模，不涉及任何結構和時(shí)間的細節，并通過(guò)實(shí)時(shí)UML進(jìn)行可視化的描述. 它不僅具備傳統面向對象方法所具有的風(fēng)格，而且具有Petri網(wǎng)直觀(guān)模擬系統動(dòng)態(tài)行為的優(yōu)點(diǎn)，從而能夠更加簡(jiǎn)潔、清楚地描述系統的靜態(tài)結構和組成元素之間的層次關(guān)系。將Petri網(wǎng)思想引入面向對象建模當中，可將系統看作是一些相互作用的對象組成的集合。集合中的每個(gè)對象都具有自己的屬性和任務(wù)，它們根據收到的消息、句柄等來(lái)完成相應的任務(wù)，從而實(shí)現系統的整體功能.在系統級建立面向對象的設計模式庫和IP復用庫，OO庫即面向對象數據庫，主要存放的是各種SoC設計模式(pattern) ，在SoC系統框架設計、IP設計以及IP通信設計中都可以使用模式。IP庫中存放的可以是普通的IP核，即其他廠(chǎng)商設計的成熟的IP；也可以是用面向對象的方法設計的一些IP 核，即IP 的設計過(guò)程也遵從于PBSOC。

圖1 　PBSOC 設計框架

　　SOC設計的設計模式

　　設計模式

　　模式是解決某一類(lèi)問(wèn)題的方法論，它把解決某類(lèi)問(wèn)題的方法總結歸納到理論高度。雖然模式起源于建筑，但其思想也同樣適用于面向對象設計模式。指導模式設計有3個(gè)重要概念，即重用( reuse) 、接口與實(shí)現分離和低耦合(loose couple)。重用是系統的設計目標，主要通過(guò)繼承(inheritance) 和對象復合(composition) 實(shí)現. 接口與實(shí)現分離指接口保持不變，用分離帶來(lái)靈活性，主要表現形式為多態(tài)性(polymorphism)。低耦合可以降低復雜性。

　　現存的硬件設計模式和重用方法主要是處理RTL(寄存器傳輸級) 設計和編碼的。這種在設計過(guò)程中積累的經(jīng)驗在設計重用時(shí)是非常重要和有用的，然而并沒(méi)有涉及系統級設計的問(wèn)題。因此在系統級應用面向對象的方法可以克服這些鴻溝，使用設計模式還可以更快速和直觀(guān)地捕捉設計的內容，提高設計的可理解性，將抽象的級別上升到系統級，能夠處理更復雜的硬件設計。

    SoC設計模式

　　SoC的設計模式與軟件的設計模式的不同，主要在于軟件和硬件的設計差別。SoC的設計不僅包括軟件，還有硬件以及軟硬件的協(xié)同設計，因此，它涉及物理約束、實(shí)時(shí)性和并發(fā)等關(guān)鍵問(wèn)題。所以要將軟件的模式進(jìn)行改造，并使用軟硬件通用的描述語(yǔ)言進(jìn)行描述。

　　軟件設計模式中運用得比較多的面向對象方法是繼承，它同樣適用于SoC的設計模式當中，但必須考慮SoC系統中的物理約束。一些軟件設計模式，主要是創(chuàng )建型模式，能夠動(dòng)態(tài)地生成系統的對象，而SoC系統中硬件部分結構是靜態(tài)的，因此，它們不適合于SoC硬件部分設計模式，但是對于SoC系統中的軟件模塊還是可以適用的，例如原型模式和命令模式等。

　　大部分的結構型模式只需要稍做修改就可以應用到SoC設計中，主要是實(shí)現方式的問(wèn)題，即用軟硬件通用的語(yǔ)言來(lái)重新描述它。而行為型的模式，需要加入實(shí)時(shí)系統中一些約束。對于典型軟件模式改造的前提和目標是設計的可重用性，主要是SoC系統級設計的可重用。在SoC中FSM(有限狀態(tài)機) 是最常用的一種行為表達方式，因此狀態(tài)轉換的頻率是非常多的.如下面的狀態(tài)模式，通過(guò)改造，可以用于描述硬件設計。

　　新的SoC設計模式的提出是PBSOC 最終的目標。它主要針對的就是高層次SoC設計中最常用的一些設計方法，以及構筑SoC系統的基本組件和基本結構

　　(1) 狀態(tài)模式(state pattern)

　　狀態(tài)模式的意圖是使一個(gè)對象在內部狀態(tài)改變時(shí)可以改變自己的行為，從客戶(hù)看來(lái)，好像對象改變了它的類(lèi)。即不同的狀態(tài)，不同的行為；或者說(shuō)，每個(gè)狀態(tài)有著(zhù)相應的行為.考慮SoC片上總線(xiàn)協(xié)議， 片上總線(xiàn)總是有3 個(gè)狀態(tài): 閑( IDL E) 、忙(BUSY) 和關(guān)閉(CLOSE) . 而各個(gè)狀態(tài)的處理過(guò)程不一樣. 如圖2 所示，BusProtocol 類(lèi)維護一個(gè)表示總線(xiàn)當前狀態(tài)的狀態(tài)對象(一個(gè)BusState 子類(lèi)的實(shí)例) . BusProtocol 類(lèi)將所有與狀態(tài)相關(guān)的請求委托給這個(gè)狀態(tài)對象. BusProtocol 使用它的BusState 子類(lèi)實(shí)例來(lái)執行特定于連接狀態(tài)的操作. 一旦總線(xiàn)狀態(tài)改變， BusProtocol 對象就會(huì )改變它所使用的狀態(tài)對象. 例如，當片上總線(xiàn)從閑置狀態(tài)轉為忙狀態(tài)時(shí)，BusProtocol 會(huì )用一個(gè)BusBusy 的實(shí)例來(lái)代替原來(lái)的BusIdle 的實(shí)例。

圖2 　狀態(tài)模式的系統結構

　　State 模式不指定哪一個(gè)參與者定義狀態(tài)轉換準則. 如果該準則是固定的， 那么它們可在Context 中完全實(shí)現. 然而若讓State 子類(lèi)自身指定它們的后繼狀態(tài)以及何時(shí)進(jìn)行轉換， 通常更靈活、更合適. 這需要Context 增加一個(gè)接口， 讓State 對象顯式地設定Context 的當前狀態(tài)。

　　首先定義類(lèi)BusProtocol ，它提供了一個(gè)片上總線(xiàn)的基本協(xié)議通道并處理改變狀態(tài)的請求。BusProtocol 在state 成員變量中保持一個(gè)BusState 類(lèi)的實(shí)例。類(lèi)BusState 復制了BusProtocol的狀態(tài)改變接口。每一個(gè)BusState 操作都以一個(gè)BusProtocol 實(shí)例作為一個(gè)參數， 從而讓BusState 可以訪(fǎng)問(wèn)BusProtocol 中的數據和改變總線(xiàn)的狀態(tài)。BusProtocol 將所有與狀態(tài)相關(guān)的請求委托給它的BusState 實(shí)例state。BusProtocol 還提供了一個(gè)操作用于將這個(gè)變量設為一個(gè)新的BusState。BusProtocol 的構造器將該狀態(tài)對象初始化為BusIdle 狀態(tài)。

　　(2) 層適配模式

　　層適配模式為SoC通信建模提供分層的協(xié)議轉換，將不同架構的網(wǎng)絡(luò )協(xié)議通過(guò)接口的匹配，實(shí)現各層次的數據通信，提供事務(wù)級建模各層的適配方式。系統建模中通信機制可以分為4 層，其中事務(wù)級建模分為3 層，即除L0 之上的3 層為事務(wù)級。其中：L3 為消息層，這一層沒(méi)有任何的時(shí)間信息，系統行為是事件驅動(dòng)的，并建立點(diǎn)到點(diǎn)的通信. L2 為事務(wù)層，這一層的系統模型帶有時(shí)間信息，但并不是時(shí)鐘精確周期，系統是時(shí)間驅動(dòng)執行的。

　　事務(wù)層將理想的結構映射到需要考慮資源分配和設計約束的結構中，完成SoC體系結構的分析和建模，并開(kāi)始軟件的開(kāi)發(fā)。L1為傳輸層，它在RTL層之上，系統由精確到周期的行為組成，但比RTL 級的仿真速度要快。傳輸層建模一般對應一定的總線(xiàn)協(xié)議，將精確到周期的協(xié)議映射到給定的硬件接口和總線(xiàn)結構上，隱藏了接口的管腳，將事務(wù)直接映射到總線(xiàn)周期。層適配模式將通過(guò)適配完成各層次的模型轉換。如圖3 所示，TL1 Master Adapter通過(guò)適配TL1通道和TL2 通道，使TL1 Master 和TL2 Slave 通信。

圖3 　層適配模式結構

　(3) 包裝器模式

　　包裝器模式的目的是通過(guò)調整接口和IP 組件的行為來(lái)適應特定的應用環(huán)境，它屬于結構型模式.在SoC設計中，功能組裝正在逐漸代替功能設計，而成為主流的設計方法。因此，各個(gè)IP模塊的互連，以及與片上總線(xiàn)的通信成為研究的重點(diǎn)。IP的本質(zhì)特征是可重用性，通常必然滿(mǎn)足以下基本特征:通用性好，正確性有保證，可移植性好。因為許多IP在設計之初都是針對特定的應用，而很少考慮到要與外來(lái)電路搭配使用。IP的定義沒(méi)有一個(gè)通用的接口標準，因為芯片實(shí)現的功能千差萬(wàn)別，性能方面的要求也由于應用領(lǐng)域的差異而不同，即使同樣功能的IP模塊在速度、面積、功耗、對外接口等方面也表現各異包裝器模式的系統結構如圖4 所示。

圖4 　包裝器模式的系統結構

　　通過(guò)包裝器模式的封裝，能適配各種IP 接口。即使用包裝器模式來(lái)調整組件接口以適應于環(huán)境要求。包裝器模式的匹配程度，對IP Component 的接口與其他的接口進(jìn)行匹配的工作量各個(gè)WrapperModel 可能不一樣。從簡(jiǎn)單的接口轉換(例如改變操作名) 到支持完全不同的操作集合，WrapperModel 的工作量取決于Component 接口與需要轉

　　結束語(yǔ)

　　在SoC設計中，可重用性是應該考慮的一個(gè)很重要的因素. 除了IP復用，設計的可重用也是非常重用的。在討論將現有軟件設計模式應用到SoC設計當中后，提出了SoC設計模式，主要針對高層次的SoC設計中的最常用的一些設計方法，以及構筑SoC系統的基本組件和基本結構。除了上述的3 種模式，還提出的一系列的SoC設計模式中，總線(xiàn)模式屬于體系結構的模式，包裝器模式和層適配模式屬于結構型模式，總線(xiàn)協(xié)議模式、管道模式和FSM模式屬于行為型模式。下一步的工作是深入研究系統級設計方法，以及基于UML的軟件設計模式描述如何自動(dòng)地轉換為元(meta) 程序。