SoC是IC設計的現在進行式

對於消費者而言，SoC設計方式的好處在於整合多顆晶片之功能至單一晶片，使產品更符合低功率消耗與縮小產品體積的需求；對於生產業者而言，藉由晶片製程上的進步，將數顆晶片整合至單一晶片將大幅節省晶片製作成本，使得該晶片更具經濟效益與競爭力，所以，SoC的設計方式為目前晶片設計不二法門。

然而，對晶片設計師來說，無論是業者或者學界皆發現發展SoC的挑戰其實很高，除了要將數顆晶片功能整合至單一晶片時要考量的功能複雜度，還有許多採用SoC設計方式時所需付出的風險與代價，都必須考慮在內，以下將列出數點主要的問題。

開發時程考量

在傳統的晶片設計?程上，軟體工程師必須等到硬體工程師提供硬體系統的樣本後，才能開始著手設計，這樣將延遲軟體設計的時間，不符合有效人力資源分配原則。

軟硬體共同設計、驗證的重要性

若只有設計該晶片的硬體工程師在早期獨立工作，除了有時程上的問題，常遇到的問題還有對於只有硬體工程師根據經驗法則所規劃出來的整體系統架構，軟體工程師的設計往往會陷進這些樣本的框架中，造成無法對整體系統做出最佳化的困境。於是在各項成本考?下，軟體工程師只好犧牲效能做為妥協，當情況嚴重的話，如在晶片設計開發後期才發現其晶片不符合設計規格要求或設計功能錯誤而導致系統因軟硬體無法配合，這將使得該系統整體必須重新開發甚至於直接宣告失敗。

開發成本考量

既然在系統級晶片複雜度如此之高，晶片設計業者為了確保開發的晶片符合需求，常會借助於FPGA幫助驗證，但由於FPGA本身的物理限制造成無法完整表達系統所有的功能，當然也就無法驗證其功能是否正確或者其演算法是否合乎需求。再者，由於高階的FPGA單價昂貴，若想要比較眾多不同系統架構下的系統效能，開發者可能要分段驗證或者所費不貲地支付高額的FPGA材料費。這些環境因素都會侷限設計者的做法導致原本的想法無法實現。

虛擬平台採用ESL Design設計方式協助SoC開發

對於開發SoC來說，上述的問題常常造成開發晶片失敗，或是開發的時間過長。為了解決上述的種種問題與現象，學者開始提出一種名為「電子系統級設計」（Electronics System Level Design；ESL Design）的方法學（Methodology）去建構一系統級的軟硬體共同設計虛擬平台。這個方法學是利用高階語言的抽象化的功能，將設計者所想要驗證的電路以模型化的形式包裝，並且提出為了要符合模擬硬體電路動作必須加入共同式電路行為模擬功能（Concurrent Behavior Simulation）。由於整個系統採取由軟體建構方式，所以把實現的系統稱之虛擬平台，當虛擬平台建構出來後，軟硬工程師們就能在這個平台上共同開發系統，並在短時間內方便地即建造多種系統模型找尋合適的系統架構。由於系統模型可以被虛構出來，對於許多本來不易建構的實體模型將能在低成本的方式下建立，所以軟硬體工程們能在早期即能完成系統晶片功能性上的驗證，這將大幅縮短晶片開發時程，解決軟硬體共同設計、驗證時的需求、符合兼具低成本與高彈性度的設計方式。

現有的虛擬平台產品的限制

由於ESL Design Methodology兼具如此多的優點，所以市面上有許多的公司都積極地開發這類型的軟體，舉例如說，如ARM SoC Designer、CoWare Platform Architecture都是解決上述問題的商業產品。但這些公司常基於商業考?與保護，造成工程師無法修改軟硬體元件的原始碼?符合特定的設計並探?系統的可調性，因此造成在做跨平台的工具整合時的發生?多困擾。此外，在學術上常使用的系統級模擬工具「QEMU」，由於無法任意?動硬體模型設定或變?系統架構，只能提供「軟體工程師」一個固定的系統平台，無法透過不同的系統架構測試，讓整體系統達到最佳化的設計。

建置屬於您的虛擬平台

踏出建置虛擬平台的第一步：開發軟體的取得（SystemC）

針對這個問題，目前有許多免費的開發軟體可供使用，其中最著名的為OSCI（Open SystemC Initiative）構機發展的SystemC，它提供類似硬體描述語言的模擬功能，除此之外，它的核心是由c++所建構而成，並且開發的語法與c++非常類似，對於軟硬體的開發來說，它既可以使用高抽象化的模擬方式建造系統模型，也可以採取低抽象化的模擬方式驗證系統中電路中的低階行為特性（例如時脈誤差所導致的電路行為，匯流排擁塞現象等）。由於OSCI是非營利組織，所有人皆可免費地從網路上下載原始碼（Source Code）。由於這個原始碼是開放性且相容於Linux與Windows兩大作業系統，使用者可以任意修改想要改良的地方，所以廣體許多的系統開發者所喜愛，有興趣的讀者可以參考網站：http://www.systemc.org/home。

建置虛擬平台時的核心概念（一）：系統模型的抽象化程度

如同前面提到的，虛擬平台的建構目的是模擬系統運作，所以模擬速度將是考量的重點，而影響模擬速度最主要的因素來自於物體抽象化程度，高抽象化模擬是表達物體的功能或演算法，忽略系統各功能模型間溝通時繁雜的交握訊號狀態，所以模擬速度較高，但對於時間上的精確度則較低；反之，低抽象化模擬如同之前所提，是模擬系統中電路的低階行為特性，針對在時脈準確度下的電路行為做解析，相較於高抽象化模擬來說需要考量較多次的同步行為，在相同時間單位下，能夠模擬的指令則較少，所以模擬速度相對為低。

建置虛擬平台時的核心概念（二）：採用有利的資訊交換方式（Transaction-Level-Modeling；TLM）

系統的模擬速度除了取決於抽象化程度外，另一方面取決於各功能模型間資訊的交換的頻率，由於模型的資訊交換會有訊號同步或交握情況，對於模擬器來說在相同時間單位下，資訊交換的頻率愈高則代表要代出愈高的資訊交換（Content Switching）代價。

為了解決這個無法避免的問題，則必須採用對於交換資訊較佳的模擬方式提升模擬的速度，這種模擬方式通常有兩種做法可供參考，第一為減少資訊交換的頻率，因為ESL模型所建立的系統是由軟體所構成，所以方便大量採用function calls並夾帶必要的參數變數將所需交換資訊透過『交易』（Transaction）用最少次傳輸的方式完成，這樣的做法雖然會?牲交握訊號時序的準確度，但卻能大幅增進模擬速度，然而，有關準確度與模擬速度之間的抉擇，則是得由使用者依據當時狀況的需求做判斷。

第二為採用軟體工程中常介紹的方法指標傳遞（Transfer-by-Pointer），由於使用軟體模擬交易的過程，常用到的方法是將欲傳遞物件（Object）資訊拷貝一份給對方，可以預想若有許多接收的模型或者是欲傳遞物品的資訊量很大時，採用資訊拷貝的將要付出相當大的代價（較多的時間與記憶體），對於這種狀況，工程師們常用指標傳遞做有效率的處理，雖然指標傳遞的方式很有效率，但這種做法對於硬體模擬將可能產生資料一致性的問題，這個問題將在本文中「虛擬平台的問題與挑戰」有較完整的介紹討論。

目前所要關心的是上述的主要兩個問題將會伴隨著系統建置愈大而愈明顯，這點專家學者們也注意到這個問題，所以提出了一些參考的方法，以OSCI為例，它提供了Transaction Level Modeling（TLM）的程式庫（SystemC extension library），這個程式庫提供許多的函式呼叫元件對應於不同的傳輸方式，但是這些元件的共通點都是讓各硬體模型間免除繁瑣的?輯電?溝通訊號增進傳輸效率，並且元件皆透過函式呼叫（Function Call）方式，搭配兩種資料傳遞方式（Transfer-by-Value or Transfer-by-Pointer）供使用者自由選擇以達到最有效?的資?傳輸；相較於目前大多數的硬體描述語言皆是以觀測模型間訊號變的模式以達到交換資訊的目的，TLM模擬方式將能大幅改善模擬的速?，有效的幫助系統開發者?使系統級的大?模擬，有興趣的讀者可以參考網站http://www.systemc.org/downloads/standards/tlm20/。

用虛擬平台開發一個嵌入式系統的實例

在介紹了許多有關虛擬平台建置的觀念後，接下來將以本實驗室團隊 （http://dvlab.ee.ntu.edu.tw）所建置的虛擬平台（Qute Virtual Platform；QuteVP）為實際範例，分享我們的實際經驗，並探討建置過程所遇到的問題與挑戰。

處理器模型的建置

這個虛擬平台目前提供了以ARM v5Te處理器（ARM 9 & 11相容）模型為核心的完整系統設計架構，如圖一，並且使用SystemC語言所撰寫的指令集處理器模型（Instruction Set Architecture；ISA）。除了支援ARM 9/11所有的指令之外，因其高抽象階層的描述特性，與傳統暫存器轉換層的週期正確性模型相較，擁有絕對的模擬執行速度的優勢。

《圖一　QVP系統架構圖》

周邊模型的建置

此虛擬平台其中亦包含了要安裝作業系統所需要的周邊模型，如：計時器模型（Timer Controller）、中斷控制器模型（Interrupt Controller）、直接式記憶體存取控制器模型（Direct Memory Access Controller）等，所以該虛擬平台其實已為使用者做好「作業系統」移植的準備，讓使用者擁有更多的時間專注於軟體程式或系統架構的開發。

快速擴充系統模型的樣版

有關系統擴充性的方面，本虛擬平台提供一組Wrapper Class，可透過物件導向程式語言的繼承方式，簡單地完成硬體模型的Bus Functional Wrapper，讓使用者能方便地自行建構各類硬體模型於平台的系統上，因此提高了矽智財的重複利用性（IP Reuse）。在此種模型的計算與通訊分離設計（Computation-Communication Separation）下，各類硬體模型更可透過只抽換Wrapper Class，便可以在溝通的行為模式上達到不同階層的模擬。

模型間的溝通方式

有關模型間傳輸的部份，本虛擬平台採用Transaction Level Modeling（TLM)做為硬體模型間溝通的行為模式，加速彼此的訊息傳輸。由於採用TLM的行為模式，讓各硬體模型間免除繁瑣的邏輯電路溝通訊號，使用者也可搭配使用不同的資料傳遞方式配合函式呼叫（Function Call）的方式進行有效率的資料傳輸。此外，我們也提出了一個考慮傳輸資料相依性的模擬加速演算法，利用虛擬同步（virtual synchronization）的機制，將SystemC模擬核心引擎在做context switch的overhead由原先佔整個模擬將近90％的時間，大大的降低到1％左右，詳細的演算法請見我們今年在International SoC Design Conference（ISoCC）所發表的文章。

應用軟體開發與效能評估

關於產品開發應用的部份，本虛擬平台接受由ARM Compiler、Linker編譯、連結後的無格式二進製文件（Plain Binary File），並透過指令輸入介面，讓軟體工程師選擇欲測試的執行檔。免除傳統流程中，軟體工程師將執行檔燒錄於相對應的唯讀記憶體（ROM）時，所需的一連串繁雜程序，提供系統開發時的便利度。除此之外，在執行系統模擬時，本虛擬平台可以自動記錄在BUS上所有的傳輸過程，例如：封包傳送時間、封包傳送個數、系統模型使用率（如指令的執行總數、記憶體最大使用量等）之相關資訊，並在軟體程式執行結束後，自動儲存為文字檔案，供使用者參考。有關系統評估的部分，本平台亦提供一個基礎的工具程式讓使用者可依照自己的需求稍做修正以達到各項的系統評估。目前此虛擬平台的模擬速率在一般的Linux工作站上可達3.66MIPs（million instructions per second）。

虛擬平台的問題與挑戰

前面介紹了虛擬平台建置的方法與範例，接下來要討論的是如何在真實生活中實現建置好的虛擬平台，這是一個目前許多學者、專家、業者們都還沒有一個統籌式解決方案，甚至有些問題都還未被挖掘出來，所以接下來，本文將歸納三個在建置與實現虛擬平台時遭遇到問題與期待解決的問題。

將抽象化的模型具體化

抽象化的用法與所帶來的優缺點在面的文章中已被提及，所以這裡要做的是更進一步討論實現抽象化模型時的困難與挑戰。其實，將抽象化的模型轉換成實體的電路早在硬體描述語言的合成流程（Synthesis Flow）中行之有年，當年成功的經驗在於業者們對於該語言語義解析有統一的標準方式，並且這些硬體描述語言的語法被區分成可合成與不可合成的部份，所以工程師們可以輕鬆分辨並且使用它們。

相較於虛擬平台所採用的語言則無法完全採用上述的方式解決，以SystemC為例，由於使用者常為了提升模擬速度而採取高抽象方式模擬，可是高抽象的描述物體方式帶給編譯器辨認語義時極高的複雜度，這個現象，造成編譯器區分可合成電路與不可合成電路時的困難，如果要解決這個問題，通常需要使用者自己增加或者刪減編譯器對於該語法上的辨認條件，然而，這個步驟無形中卻增加了使用者的負擔，甚至帶來人為錯誤判斷條件的風險，這點是學者專家們常常提及從虛擬平台至實體電路想要解決的主要問題。依照經驗來說，使用者必須在建置抽象化模型時考慮該模型的用途，一旦決定要建立的為可實現化的虛擬平台時，則採用的抽象層次可能就不能太高亦或者必須定義高低不同抽象層中相對應模型的電路功能、電路訊號、電氣特性等關係。

指標問題

指標通常對於軟體最大的貢獻在於分享一個物件所擁有的內容，而且透過對指標的運算，使用者可以從一大群資料中挑選到所需要的資料，這種方式將節省許多軟體工程上的資料拷貝時間與免除不必要的資訊交握訊號，所以增進了電腦模擬效能，但若把這個特性用於硬體模擬則可能導致資料不一致的問題，試想，若有二個模型同時內皆使用指標指定至相同記憶體位址並使用該記憶體所分享物件的內容，一旦有任何一模型更改記憶體位址內的內容，將可能對另一個模型造成資料存取錯誤的狀況而導致不可預期的後果。

為了修正這個問題，使用者必須在傳遞資料或使用資料時注意資料一致性的問題，所以在撰寫程式碼甚至得加上鎖（Lock）或門閂器（Semaphore）等同步元件，這樣的做法也會造成使用者的負擔而且降低模擬速度。

驗證問題

驗證對於虛擬平台的挑戰不在於只是確認功能性是否正確，它還包括了系統架構是否合適，因為採用適當的架構才能達到高效能、低功率消耗的要求，但對於驗證什麼是最合適的架構而言是相當困難的，常見的兩種驗證方式：模擬方式（Simulation-Based method）對於眾多系統級的架構模擬驗證需要用到大量的時間；正規方法方式（Formal Verification-based method）則是需要將抽象化的模型再次用正規語言轉換、描述，所以，困難點不僅在於描述方式的轉換，還包括無法明白知道要驗證的項目有多少與用何種正規方法才是最有效率的驗證方法，所以對虛擬平台的驗證來說，還有非常多的部份值得研究、探索。

虛擬平台的高投資報酬率

雖然建置虛擬平台以發展SoC存在許多的困難，但是它的投資報酬卻相當地高，除了前面所提及的高彈性度的設計方式、低開發成本外，專家學者們認為虛擬平台的可重覆利用性很好，因為，一旦虛擬平台建置完成後，往後要再開發新的系統都可以仿照原先虛擬平台的建置方式，甚至只需要像堆積積木一樣的方式抽換或增減所需要的功能模型即可，所以對於產品時程（Time-to-Market）而言將更顯其競爭力。另外，從現在就投入虛擬平台建置以開發系統級晶片就如同在1990年代就開始接受SoC設計方式一樣，因為這種設計方法學是一種設計上的趨勢，所以善加利用虛擬平台，將帶領工程師們能夠面對更高、更嚴峻的挑戰，創造出更大的晶片設計價值。

---作者葉昱甫為台大電子所博士班學生、黃鐘揚為台大電子所助理教授；兩人亦是台大電子所設計驗證實驗室成員---