瀏覽人次:【4180】
軟硬體相輔設計(Hardware-Software Codesign)這個名詞最早出現於1980年代的計算機輔助設計研究領域之中,而直到了1990年代中期才開始出現了一些相關研究的重要成果。當時這門學問興起的背景在於科學家們希望可以發展出一套流程,讓一個產品能自最初的設計開發時期開始,即可透過建立系統的模型來自動生成出最後的產品。而在整個過程之中,可以大致區分為建立系統模型、系統軟硬體功能區塊自動分割、軟硬體自動合成、軟硬體共同模擬以及驗證、以及最後系統雛型(prototype)之建立這幾個步驟。後來幾個相當著名的軟硬體相輔設計系統像是COSYMA、VULCAN、LYCOS等都是於該段時間所被發表。但由於相關的研究長期被局限在特定的應用領域中(如:嵌入式系統控制器),故並未受到太大的重視。直到最近系統單晶片的掘起,使得系統的設計開發工作越來越複雜。至此,人們才又開始對有別傳統設計流程的軟硬體相輔設計感到興趣。
在這篇文章之中,筆者首先會舉實例就軟硬體相輔設計的概念加以說明,其次會對一些早期軟硬體相輔設計工具內含的想法做簡單的介紹,緊接著談到這些想法對後來軟硬體相輔設計發展造成的影響以及相衍而生的功能──架構相輔設計(Function-Architecture Codesign)流程,最後會對現今SoC設計潮流之下為何這些設計方法又再度引起重視加以分析,並點出其未來所將面臨之挑戰。
軟硬體相輔設計之重要性與流程說明
在本段中,筆者首先要以一個MPEG影音解碼裝置 [1],來說明軟硬體相輔設計之重要性,其次再對完整的相輔設計流程加以介紹。
《圖一 傳統設計之MPEG影音解碼裝置》 |
《圖二 經軟硬體分割設計之MPEG影音解碼裝置》 |
(圖一)與(圖二)中分別展示了兩種不同的MPEG影音解碼裝置實作方式,前者是以全硬體控制的方式來完成,而後者則是結合了在處理器上執行之軟體程度以及硬體解碼元件來完成。兩者相較之下,前者的好處在於所有的設計工作都可按照傳統之設計流程來進行,而後者在透過軟硬體相輔設計之後卻增加了以下幾項優點:
(1)整個產品的設計變得更有彈性,透過修改軟體程式的內容便可增加系統功能,甚至在整個硬體規格都已確定後仍可透過軟體的更新來做某些程度之修正。
(2)多了一個中央處理器將可分擔較不耗資源之運算工作。
利用處理器來分配排程可提高各硬體之使用率,以及減少原需硬體之面積藉以達到降低成本之目的。而由於在現實的情況中,嵌入式處理器之選擇相當有限,所以在進行軟硬分割時,可以把問題視為該如何來分配工作給這些處理器同時又不會使它超過負載。雖然說有的時候可以很輕易地就看出那些功能適合給軟體做,那些又適合給硬體做,但也有些時候這種抉擇並不明顯,此時若沒有良好的電腦輔助工具來幫忙,設計者可能就無法讓處理器之利用率提升到最高,或是只能找到比較少的功能交給它來做。而軟硬體相輔設計最初的想法,就是希望可以透過工具軟體將整個系統做最佳化的設計,同時又可以縮短產品推出的時間,減少需要人力參與的部份以達到用最低的成本換取最高的效益的目的。
《圖三 使用電腦輔助工具之軟硬體相輔設計流程》 |
(圖三)所展示的是一個完整的軟硬體相輔設計流程,首先,設計者要先以系統描述語言來建立整個系統的分析模型,將這個系統用一個比較具體的方式來加以描述,比如說利用現有的硬體描述語言(VHDL、Verilog)、軟體程式語言(C/C++)、或專門用以描述系統的語言(如System C)等,接著再透過系統分割演算來對整個系統進行軟硬體功能區塊之自動分割,以及對系統初步分割的結果評估是否滿足所要求之設計限制。在軟硬體自動合成的步驟中,首先要決定系統內部所將使用之通訊協定(communication protocol),其次預留系統所需之共享記憶體,再來就是產生出能被處理器執行之軟體程式碼以及能做成ASIC之硬體語言描述檔。接著透過系統驗證的技術,可以建立出數學模型來對系統的行為做像是死結(dead lock)或是資源貧乏(resource starving)等排程方面的功能驗証,最後透過軟硬體共同模擬,設計者能對不同的系統實作方式作一比較,同時進行功能方面的除錯、追蹤各系統事件發生之時序等,來決定所需處理器之運算速度以及系統排程機制來建立出系統雛型(prototype)。
早期軟硬體相輔設計平台介紹
在軟硬體相輔設計剛被提出的前期,整體的開發概念尚不完整,每個開發平台僅會就自己的主要考量來進行系統的實作。在這一段介紹中筆者將對幾個比較具代表性的系統作介紹。
COSYMA
COSYMA(COSYthesis for eMbedded micro Achitecture )[2],是一個建立在模擬退火(simulated annealing)演算法上的軟硬體相輔設計平台,它是一個以軟體為設計導向(software-oriented)的系統開發平台。首先,它將整個系統以純軟體的方式來完成,但以純軟體的方式來完成系統必會使得整體執行速度相當緩慢,所以接下來它會不斷地從系統中擷取出幾塊適合用硬體來實現的部份,直到整個系統能滿足原來的時間限制(timing constraint)為止。
VULCAN
相較於以軟體為設計導向的開發平台,Gupta 以及 De Micheli 則提出一個以硬體為導向(hardware-oriented)的軟硬體相輔設計系統VULCAN[3]、[4]。 它是以一個純硬體實作的系統解決方案開始,不斷地將其中能以軟體實現的部份在能滿足所有設計限制的前提之下分割出來,直到不能再分割為止。在VULCAN系統中使用者必須提供系統設計之序列圖(sequencing graph),運算時脈限制,軟體、硬體以及介面之間的成本消耗模型(cost model),再來VULCAN能依據這些資訊並考慮處理器使用率、系統匯流排使用率、運算時脈限制等在滿足分割成本函數(partition cost function)的前題之下產生出最終系統硬體以及軟體之設計序列圖。
PACE
在COSYMA以及VULCAN之後的軟硬體相輔設計系統,則開始以各種不同的角度來設計分割演算法以及建立系統之軟硬體分割模型。當中比較著名的像是被LYCOS(Lyngby Co-Sythesis System)系統所採用的PACE(Partitioning Algorithm with Communication Emphasis)[5]演算法,PACE演算法考慮的情形是當同時把兩個系統元件(system component)一起放在硬體部份時,除了它們本身衍生自硬體實作上的執行運算加速之外,尚可得到因兩者已可直接傳遞資料而減少之通訊消耗上的額外加速。PACE演算法可以用在解決如何讓硬體使用面積最小而所得效益又最大的問題上。
另外,為了能準確的估計各個運算元件之間資料傳遞的時間,Niemann[6]將所有資料的傳遞都分為讀取(read phase)與寫入(write phase)兩個象限來模擬系統通訊消耗。如此對於分割後整體系統的執行時間便能做出更精準之估計。
GCLP
而在進行系統分割時,針對系統中每個運算單元究竟是該以硬體來實現以減少執行時間或是以軟體來實現以減少硬體所佔之面積,Kalavade與Lee則提出了GCLP(Global Critically/Local Phase)[7]演算法。在做系統分割時,往往需要同時要兼顧硬體面積最小化以及縮短整體運算時間兩個目的,但這兩者其實是互相矛盾的,因為想要縮短執行時間勢必需要更多運算單元以硬體的方式來實現,如此必將造成硬體所佔整體面積的增加。相對地,如果只注重在讓硬體所佔之面積最小化上設計出的系統則可能會造成整體運算時間無法滿足時間上的限制。GCLP演算法會針對系統內的每個運算單元之重要性,對該點到底是應以面積最小化為主要考量或是以縮短整體運算時間為主要考量來做最佳化之選擇。
功能──架構相輔設計
在軟硬體相輔設計概念被提出來之後,Tabbara等人針對大型系統的設計規劃則提出了另一種建立於其上的功能──架構相輔設計(Function-Architecture Codesgin ),[8]、[9]它是一種兼具由上而下(top-down)以及由下而上(bottom-up)特性的系統階層設計方法,其中最主要的三個觀念如下:
(1)系統功能之分解(decomposition):
在一個由上而下的設計流程中,若整個系統相當龐大的話事實上是很難在設計初期就決定好最終的特定目標架構(target architecture)為何。所以為了在系統功能與設計限制間取得最佳之平衡,在系統設計初期應先將整個系統功能先分解成不同區塊,同時也把設計的限制也分別對應到不同區塊內來考慮以降低設計上的複雜度。
(2)架構抽象化以及持續的推演:
在將系統功能及限制加以分析之後,接著要做的是將不同的系統功能在能滿足所有的設計限制前提之下對應到不同的子系統架構中。在這個步驟的剛開始,系統架構是單以一個抽象的架構模型來表示,其次經過不斷地推演來決定最終架構應該由那些硬體以及軟體區塊來組成。
@小標(3)目標架構探索與評估:
這塊是屬於由下而上設計的部份,在此將針對所選定之目標架構加以分析以及進行設計限制考量上的評估。當然,除非可以找到適當的分析方法來對該架構進行評估,否則是無法完成系統設計之最佳化的。
功能──架構設計流程的步驟
在以功能──架構為基礎的設計流程之中,主要分成兩個步驟,首先將是系統層次的功能分解與目標架構取捨,即(圖四)中的功能層(Function Level)及架構層(Architecture Level),第二個步驟則是將不同的功能分別對應到不同的架構之上,即圖四中的對應層(Mapping Level)。所謂目標架構的取捨是指決定像加法器、乘法器的數量以及種類,同時也包括決定如暫存器等記憶體大小等這些可參數化的設計。如果整個設計並無這些可調參數的話,則在此一步驟中能做的僅剩對系統功能做最佳化之分解。做完系統功分解及決定系統架構後接著要做的,就是將抽象的系統功能對應到實體架構上,而傳統的軟硬體相輔設計主要做的工作就是在這部份,但在傳統的流程之中因為在對系統進行分析時就先就將架構給限制住而少了系統功能抽象化的描述,如此將限制住其後系統軟硬體分割上的彈性與取捨且僅能得到一個系統設計上的次佳解。
《圖四 功能──架構相輔設計示意圖》 |
系統單晶片SoC
進入系統單晶片的設計時代之後,傳統的設計流程漸漸地受其影響而改變。當今最廣為看好的一項便是以平台為基礎(platform-based)的設計流程。在此流程下系統工程師主要做的事在於如何在既有的平台上增加更多的功能。此時如何選用事先經過驗證的IP(Intellectual Properties)在整個系統單晶片的開發流程內扮演著關鍵的角色。適當地使用經過驗證的IP不但可讓產品推出的速度加快,同時也有助於讓各種不同的功能全部整合到單一系統內,而IP本身的特性也使得系統內的功能在進行設計時可達到更高層次的抽象化以及模組化[10]。
《圖五 系統單晶片架構示意圖》 |
如(圖五)所示,在一個系統單晶片的架構之下可能會被囊括的部份有:處理器核心、數位數信號處理單元、內部記憶體(SRAM、ROM、Flash Memory等等)、類比混合訊號區塊,以及一些IP區塊與通訊界面。顯而易見的,在系統規劃的初期亦須先要做好軟硬體功能區塊分割的動作,而受限於目前在處理器核心的選擇上種類較少,故在進行軟硬體切割時主要的考量,應是如何能讓這個處理器能分擔最多的工作同時又不致於使它超過負載。所以在進行系統單晶片的設計規劃時,一個可行的作法即是套用既有的功能──架構相輔設計的流程。
SoC設計規劃流程
首先,在既有的架構平台之下,將所需新增加的不同功能需求找出來,將這些新增的功能予以抽象化以及模組化,進行系統層次之新增功能分解。其次,在功能及架構之映射的步驟中,所須進行的是傳統軟硬體相輔設計下的主要工作──決定系統最佳之軟硬體分割,此時所做的事在於評估這些新增的功能究竟該以軟體的方式來實現,交由處理器核心來進行運算,或是該透過第三者,購買或自行開發IP以硬體的方式來實現,以達到增進系統執行效能的目的。
而在此設計流程之下,所會牽扯到的問題又包括既有處理器核心能否承受新增的工作,匯流排的頻寬在增加功能後能否滿足軟硬間資料交換的要求,程式記憶體容量是否足夠,系統正常工作的排程會不會受到影響,購買新的IP是否讓成本大幅上升等等問題。在系統相當複雜之時,分析其中任何一個問題都需要透過精確的計算才能得到答案。如此,並不難以想像,若想要聰明地解決這些問題,還須依賴在不久的將來能出現合適的電腦輔助設計工具來幫忙。
(作者柯力群為資訊工業策進會副工程師,陳少傑為台大電子研究所暨台大系統晶片中心教授 )
<參考文獻:
[1]. Lippens, P.; Nagasamy, V.; Wolf, W., "CAD challenges in multimedia computing," 1995 IEEE/ACM International Conference on Computer-Aided Design, pp. 502 -508, 1995.
[2]. J. Henkel, Th. Benner, R.Ernst, W.Ye, N.Serafimov, and G. Glawe. "COSYMA: A Software-Oriented Approach to Hardware-software Codesign," The Journal of Computer and Software Engineering, 2(3), pp. 293-314, 1994.
[3]. Rajesh Kumar Gupta, Co-synthesis of hardware and software for embedded systems, Kluwer Academic Publishers, 1995.
[4]. R.K. Gupta and G. De Micheli, "Hardware-software Cosynthesis for Digital Systems," IEEE Design and Test of Computers, pp. 29-49, Dec. 1993.
[5]. P. V. Kundsen and J. Madsen. "PACE: A Dynamic Programming Algorithm for Hardware-software Partitioning," International Workshop on Hardware-software Codesign, pp.85-92, 1996.
[6]. R. Niemann, Hardware-software Co-design for Data Flow Dominated Embedded Systems, Kluwer Academic Plublishers, 1998.
[7]. A. Kalavade, E.A. Lee, "A Global Critically/Local Phase Driven Algorithm for the Constrained Hardware/Software Partitioning Problem," Internal Workshop on Hardware/Software Codseign, pp. 42-48, 1994.
[8]. F. Balarin, M Chiodo, P. Giusto, H. Hsieh, A. Jurecska, L. Lavagno, C. Passerone, Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki, and B. Tabbarra, Hardware- Software Co-design of Embedded Systems The POLIS Approach, Kluwer Academic Publishers 1997.
[9]. B. Tabbara, A. Tabbara, A. Sangiovanni-Vincentelli, Function/Architecture Optimization and Co-design of Embedded Systems, Kluwer Academic Publishers 2000.
[10]. Henry Chang, Larry Cooke, Merrill Hunt, Grant Martin, Andrew McNelly, Lee Todd, Surviving the SOC Revolution, Kluwer Academic Publishers 1999.>
|