《電子技術(shù)應用》
您所在的位置:首頁 > 嵌入式技術(shù) > 設(shè)計應用 > 基于模式的SoC設(shè)計方法研究
基于模式的SoC設(shè)計方法研究
摘要: SoC開發(fā)和設(shè)計存在一些問題,如描述語言不統(tǒng)一、抽象層次低、仿真速度慢、可重用性差、設(shè)計性能無法保障、RTL級發(fā)現(xiàn)的問題需要重新進行整個的設(shè)計流程才能解決,因此SoC的建模與設(shè)計的方法成為當前刻不容緩的課題。上述種種問題與曾經(jīng)困惑軟件業(yè)的“軟件危機”的表現(xiàn)非常類似,為了解決軟件危機,人們提出了軟件工程。因此,本文的思路是將軟件工程中應用最為廣泛的面向?qū)ο蠹夹g(shù)引入到SoC設(shè)計當中。
關(guān)鍵詞: SOC 模式 微處理器
Abstract:
Key words :

       引 言

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

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

  設(shè)計模式是面向?qū)ο蟮木?,在軟件中已?jīng)得到了廣泛的運用,在SoC設(shè)計中使用設(shè)計模式,可以降低軟硬件開發(fā)之間的鴻溝,對于軟硬件協(xié)同設(shè)計有很大的幫助,使系統(tǒng)得到更大的可伸縮性。

  SoC設(shè)計方法學

  傳統(tǒng)的設(shè)計方法

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

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

  基于模式的設(shè)計方法

  針對傳統(tǒng)設(shè)計方法的不足,新的SoC設(shè)計方法應該在行為級就開始建立仿真模型和進行行為與結(jié)構(gòu)的驗證,同時必須強調(diào)結(jié)構(gòu)化、封裝和重用硬件設(shè)計在高層次的抽象的重要性。

  因此,本文提出基于模式的SoC設(shè)計方法PBSOC ,如圖1所示,強調(diào)高層次的系統(tǒng)建模,更有利于設(shè)計的復用. 在需求分析階段,根據(jù)規(guī)格說明,使用面向?qū)ο蟮姆治龇椒?,給出用例的關(guān)系和順序圖. 在系統(tǒng)級設(shè)計階段,使用統(tǒng)一的語言SystemC進行軟硬件協(xié)同設(shè)計。SystemC是由Open SystemC Initiative (OSCI) 提出和維護的開放源代碼的基于C++統(tǒng)一軟硬件建模平臺. 軟硬件模塊都用C++ 描述,對不同軟硬件劃分方案的評估和權(quán)衡可以方便地進行。

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

圖1  PBSOC 設(shè)計框架

       SOC設(shè)計的設(shè)計模式

  設(shè)計模式

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

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

       SoC設(shè)計模式

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

  軟件設(shè)計模式中運用得比較多的面向?qū)ο蠓椒ㄊ抢^承,它同樣適用于SoC的設(shè)計模式當中,但必須考慮SoC系統(tǒng)中的物理約束。一些軟件設(shè)計模式,主要是創(chuàng)建型模式,能夠動態(tài)地生成系統(tǒng)的對象,而SoC系統(tǒng)中硬件部分結(jié)構(gòu)是靜態(tài)的,因此,它們不適合于SoC硬件部分設(shè)計模式,但是對于SoC系統(tǒng)中的軟件模塊還是可以適用的,例如原型模式和命令模式等。

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

  新的SoC設(shè)計模式的提出是PBSOC 最終的目標。它主要針對的就是高層次SoC設(shè)計中最常用的一些設(shè)計方法,以及構(gòu)筑SoC系統(tǒng)的基本組件和基本結(jié)構(gòu)
,如層適配模式(layeradapter pattern) 和包裝器模式(wrapper)。本文僅給出了模式的結(jié)構(gòu),具體的實現(xiàn)不在此贅述。

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

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

       圖2  狀態(tài)模式的系統(tǒng)結(jié)構(gòu)

       State 模式不指定哪一個參與者定義狀態(tài)轉(zhuǎn)換準則. 如果該準則是固定的, 那么它們可在Context 中完全實現(xiàn). 然而若讓State 子類自身指定它們的后繼狀態(tài)以及何時進行轉(zhuǎn)換, 通常更靈活、更合適. 這需要Context 增加一個接口, 讓State 對象顯式地設(shè)定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)相關(guān)的請求委托給它的BusState 實例state。BusProtocol 還提供了一個操作用于將這個變量設(shè)為一個新的BusState。BusProtocol 的構(gòu)造器將該狀態(tài)對象初始化為BusIdle 狀態(tài)。

  (2) 層適配模式

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

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

圖3  層適配模式結(jié)構(gòu)

       (3) 包裝器模式

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

圖4  包裝器模式的系統(tǒng)結(jié)構(gòu)

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

  結(jié)束語

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

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載。