此外，為了讓虛擬平台更容易在系統晶片（System on Chip, SoC）上開發軟體，本文亦提出了適用於虛擬平台之作業系統快速開機法，加快作業系統開機速度並降低移植作業系統的困難，以提升軟體開發的效能與可重覆使用性。以上所有實驗皆在台灣大學電子所「設計驗證研究室」所自行研發之虛擬平台「QuteVP」上完成，採用SystemC與TLM在該虛擬平台上建置ARM Versatile SoC原型，並且成功執行諸多如多媒體應用、數學運算與作業程式開機等程式。目前在該平台上測得的結果是當套用資料相依性感測虛擬同步演算法時，其虛擬平台的模擬速度平均可增快約44倍，亦即達到每秒執行數百萬個ARM指令的速度，因此，當使用所提出的快速開機法搭配資料相依性感測虛擬同步演算法時，則可讓一個uClinux的作業系統在約14秒左右即可開機完成。

SoC虛擬平台的兩大障礙

為了增進系統晶片（System on Chip, SoC）設計的效率與成功率，目前許多SoC設計者已開始採用ESL（Electronics System Level）方法學。ESL方法學的優點在於利用軟體高階語言抽象化能力將設計者所想要驗證的電路以模型化方式包裝，並加入硬體電路的共同式行為模擬（Concurrent Behavior Simulation）功能，讓設計者能夠快速地在該虛擬平台上建制SoC原型，提供設計者在設計初期即能有效對軟、硬體共同開發、整合與驗證的能力，並且透過系統級層次之模擬以達成對系統整體的效能評估。然而，使用虛擬平台建制系統原型時常會遇到兩個主要的問題，分別為模擬速度的不足與移植作業系統對軟體開發時所造成的困擾，所以以下將會分別詳細介紹這個兩個問題與提出解決問題的方法。

模擬速度不足的原因在於模擬器以軟體方式模仿類似硬體的共同式行為時，為了在每個時脈週期內能確保模組間交易行為的正確性，模擬器會使用同步排程方式處理這些模組間交易行為的先後順序，所以必須對每個模組進行同步行為的探詢動作，當系統中模組的數量變多時，探詢動作的次數也將成線性成長，此外，當模組間的時脈週期不同時，模擬器又必須採用更小的時脈週期進行同步行為，如此一來，探詢動作的次數將會非常龐大因而耗費大量的模擬時間。當採用目前相關商業軟體（例如：CoWare、SoC Designer）所開發之虛擬平台建制如同ARM Versatile等級的系統晶片時，當模擬精確度被要求在時脈精準度（Cycle Accurate）的狀況下，實驗結果顯示其模擬速度通常只能達到數十 KIPS（Kilo Instruction Per Second）的模擬效果，這對現今應用程式的模擬而言，執行一次應用程式常必須使用數千萬至數百億之執行指令數，若以此換算模擬時間，則模擬一次該系統執行之應用程式將需耗費數天至數個月不等，根本無法做到大量有效或完整的模擬，所以虛擬平台所帶來的好處將因模擬速度緩慢因而大打折扣。

另外，由於軟體開發與測試常需要有作業系統（Operating System, OS）的協助以避免繁瑣的系統低階設定（例如：驅動程式的撰寫）、並提高軟體的移植性與可重覆使用率。然而移植OS其實是一件相當麻煩的事，其中又以OS開機程序最難，因為OS開機過程包括許多繁雜的程序，其中有些程序（例如：Boot Loader）不僅冗長並且需要獨特的硬體配合（驅動這些硬體裝置的設定又往往會牽涉到商業機密問題），因而造成作業系統移植上的困難，其次，模擬這些作業系統的開機過程對軟體開發而言並無實質的貢獻，所以如果無法有效降低作業系統開機程模擬的難度，冗長且繁雜的作業系統移植程序將對採用虛擬平台開發SoC的使用者帶來更多的不便。

《圖一　QuteVP所建立之虛擬系統架構圖》

有鑑於此，本文將介紹一種對於虛擬平台上改善模擬速度之演算法，這個演算法相較於模擬器（例如：SystemC simulator）所採用類似Clock-Step Method的傳統模擬方式，其模擬速度增進的效果，以平均值而言約有44倍之多；除此之外，本文亦提出對於虛擬平台上的作業系統快速開機法，搭配上述所提的演算法，可以讓一個類似Linux作業系統（uClinux, Kernel2.6）開機程序約10數秒內完成模擬。（執行模擬主機為一IBM x3400工作站，採用Intel Xeon，時脈為2.66GHz之處理器），此外，採用一個名為QuteVP（如圖一所示）的虛擬平台印證實驗結果，這個虛擬平台是由台大電子所計驗證實驗室所設計開發，建置該虛擬平台所使用的描述語言為OSCI（Open SystemC Initiative）機構公佈的SystemC2.2與TLM2.0的C/C++相容語言。QuteVP目前能夠完整呈現一個ARM Versatile虛擬平台原型，內容包括了一ARM v5t架構的指令集精準度（Instruction Set Simulator, ISS）的處理器模型，此外，Versatile平台所需的其它硬體模組皆以SystemC2.2與TLM2.0建構成具時脈精準度的硬體模型（如：Bus Model、ROM/RAM、Interrupt Controller Model，Timer Model等）；關於軟體開發的部份，QuteVP中的ROM Model可以自動導入使用者透過ARM v5t相容的編譯器所產生的二進制機械碼即可驅動該虛擬系統，透過此方式，該虛擬系統已成功驗證了許多應用程式（如：JPEG Encode、MPEG H.264 Decode等），其軟體架構與系統關係圖如圖二所示。

《圖二　 軟體架構與虛擬平台關係圖》

虛擬平台的模擬速度問題

傳統系統模擬方法造成模擬速度緩慢的原因有二點：第一，模擬器為了模擬硬體模組的共同式行為動作（Concurrent Behaviors），並且確保模組功能行為模擬的正確性，其做法通常採用像Clock-Step模擬方法，讓模擬器在每個時脈週期內檢查每個模組是否需要同步，所以當系統中的模組數量變多時，每個時脈週期內需要進行同步排程次數將呈線性增加，除此之外，由於每個模組採取的時脈週期可能不同，所以模擬器必須使用更細微的時間顆粒度（Time granularity）做為模擬採樣週期，目的是保證模組間交易行為的模擬不會發生漏失的狀況，結果則導致模擬器執行再次增加龐大次數的同步探詢行為，變成讓模擬速度更快速下降的加乘效果；第二，當模組要傳遞資料時，亦由於採用軟體方式模擬硬體交易行為的緣故，所以模組間資訊的交換必須透過模擬器才能完成，如圖三所示，這些資訊交換的行為相對真實電腦（Host Machine）的運作為記憶體讀寫的動作，由於在一個複雜的系統中，模組間交易行為會牽涉到的模組可能會有很多個，所以記憶體讀取的次數也會變得相當多，所以也耗費了許多模擬時間。上述二種的狀況說明了為什麼同步排程與記憶體讀取動作會耗費模擬器大量的模擬能量，但更重要的是這些大量的模擬能量並非使用於系統模組本身功能行為的模擬與驗證，所以這將大幅降低虛擬平台對於快速驗證其系統功能正確性或效能評估的價值。以下將提供真實範例，當QuteVP採用SystemC simulator所附加之Clock-Step模擬法做一JPEG Encode程式模擬，經由GNU Profiling Tool的分析（為精簡篇幅，本文展示實驗數據為部份內容，如圖四），從這些統計資料顯示SystemC 模擬器對於同步排程所使用的函式呼叫（function call），如sc_simcontext::cruch(bool)、sc_event_trigger()、sc_notify_time_compare其執行時間就佔了約整體模擬時間的一半，當做更進一步的統計分析後，結果顯示SystemC之模擬器對於同步問題時所有的相關執行函式所耗費時間竟佔整體模擬時間竟高達90%以上。

為了解決上述問題，將嘗試從另一個角度思考，是否有其它方法可以讓模擬器不必使用大量執行同步排程也能達到正確模擬模組功能行為的目的，針對這個想法，首先觀察模組資料交換時的行為，發現即使模擬器不在每個時脈與其它模組採取同步排程，其大部份模組功能行為的模擬結果並沒有錯誤，會有差異之處則是在於該虛擬系統所執行應用程式時所耗費的「虛擬系統時間」，換句話說，在模擬中，若使用者不需要時時刻刻查詢系統時間時，若能找到發生模擬錯誤的原因並且修正，那麼模擬器就有機會不需要採用大量的同步探詢動作，至於正確的虛擬系統時間則可在模組功能模擬完後再進行修正。

《圖三　 系統模組資訊交換範例：Processor Model對RAM Model讀取資料必須經過8次資訊交換》

《圖四　 模擬時間分析統計圖》

為了找出發生模擬錯誤的原因，將更進一步對交易行進行分析，結果發現模組功能行為模擬的正確性其實是建立在模組間所交換的資料是否存在相依性問題的基礎上，所以提出了名為「資料相依性感測虛擬同步演算法」（Data-Dependency Aware Virtual Synchronization Algorithm – DAVSA，如圖五所示）去改善傳統Clock-Step模擬法造成模擬速度緩慢的問題，其演算法的特點有二：第一，如圖五中的第7~20行，是讓Simulator有能力感測模組間資料交換時的內容是否有相依性，如果交易的內容具有相依性問題才通知模擬器進行同步排程，相反狀況則予許模擬器針對模組功能持續模擬，其模組內部時間可以不跟系統總體時間（System Global Clock）相同，直到該模組之交易內容具相依性問題或模擬結束而停止，這個方法最大的優點就是避免模擬器執行大量的同步排程而有效增進模擬效率並且仍然能夠維持模組功能模擬的正確性；第二，如圖五中的第21~26行與上段文章所提及的時間修正問題，主要是計算模擬器模擬時沒有考量系統中在同時間可能有其它多個模組也在進行交易而導致的延遲時間，採取這個措施的目的是讓模擬器在功能行為模擬完成後能將正確地將系統到底耗費多少虛擬系統預估出來以維持模擬的精準度。

《圖五　 DAVSA (Data-Dependency Aware Synchronization Algorithm)》

如同上述所說要完成上述DVASA則需要完成偵測資料交換時內容的相依性、直接式模組資料讀取法與完成延遲時間修正的三件工作，以下將分別詳細介紹。

第一步

為了讓模擬器辨認一般的虛擬嵌入式系統中模組間資料交換時內容是否存在相依性問題，主要要注意兩種資料相依性，分別為靜態資料相依性與動態資料相依性。所謂的靜態資料相依性指的是針對嵌入式系統中會主動發出要求進行資料交換的模組建立其分享式記憶體資料相依性表格（Shared Memory Data-Dependency Table），這些表格的資料只需要參照系統規格在模擬前就可以標記完成會造成資料相依性問題的記憶體區域（如：RAM Module的記憶體位置或一般週邊模組所使用暫存器的位置）；對動態資料相依性來說則較為麻煩，重點模擬器除了要標計模擬時的造成資料相依性問題的記憶體位置，還必須額外記錄資料相依性問題發生的時間點，這樣才能正確還原時間以達成時間修正的目的。為了讓讀者更容易瞭解，以下將用一嵌入式系統中常會用到的Processor Module與DMA Module對於資料搬移做為範例，如圖六所示。

當Processor Module需要DMA Module協同合作搬移資料時，Processor Module會先在DMA Module的暫存器分別設定資料搬移的來源與目的地之記憶體起始位置與結束位置，最後才致能DMA Module進行資料搬移之功能，當致能DMA功能後，則代表Processor Module與DMA Module可能在圖中重疊之記憶體位置內，產生資料相依性問題，但Processor Module會跟DMA Module在這重疊之記憶體位置內，對「相同記憶體」「同時」存取資料而造成資料相依性問題的機會其實不高，所以比對時間與動態式資料相依性表格後，依照實驗的統計數據而言，會造成模擬器需要進行同步排程的次數將會大幅減少，減少的幅度通常對數千萬指令集的應用為單位時，平均可達數10４~10５之等級。

《圖六　 造成資料相依性之重疊記憶體示意圖，以Processor Module與DMA Module為例》

第二步

直接式模組資料讀取法指是模擬模組間資料交換時，如何讓發出要求的主動式模組能直接得到目標模組（Target Module）的資料以減少模擬器對真實電腦之記憶體所做的存取動作，如圖三所示，依照傳統的方法，若一個簡單的Processor Module對於RAM Module的資料交換行為要求就需要要求8次的資料拷貝(Data Copy)動作而引發記憶體存取，當模擬對象為一複雜系統時，這種資料拷貝所引發真實記憶體讀寫動作的次收也將大量增加，但是對於虛擬系統來說，由於所有模組都是由軟體所構成的模型，其實資料交易行為可以利用指標（Pointer）並配合函式呼叫方式，讓要求交易的模組（例如：Processor Module）可以直接存取目標模組的資料，所以許多原本需要經由模擬器傳遞資料動作將能大幅減少，因而減少大量的因記憶體存取所耗費的模擬時間。

第三步

第一、二步驟主要的目的在於提升模擬效能，可是卻漏失了模擬精確度，為了克服這個缺點，在模擬系統模組交易行為採用DAVSA的同時也採用了Trace-Driven模擬技術，做法是在每個模組進行資料交換時記錄交易時間，雖然這種時間記錄似乎只能呈現每個模組對於本身交易的先後關係，但加入系統架構拓樸圖資訊與系統傳輸規則後（例如：匯流排傳輸協定），則可以將這些資訊、規則轉換成數學函式，與其它模組的時間記錄互相比較並計算其延遲時間（如：模組忙碌、匯流排阻塞(Bus Contention)等所造成的延遲等），不準的虛擬系統時間資訊將可被修正、還原，而模擬精確度也可獲得補償，所以其模擬的時間資訊依舊可以做為有意義的系統效能評估參數。

最後在圖七顯示DAVSA對於加速模擬的效果，所採用的實驗測試資料為一JPEG Encode應用程式，結果顯示模擬套用DAVSA與搭配Trace-Driven模擬技術後，主要的模擬能量可以被用在系統功能模擬上，其比例可從原先的12.70%提升至87.3%，而模擬速度的提升也高達約44倍並且維持在原始的模擬精確度。

《圖七　 以JPEG Encode應用程式為例，採用DAVSA加速模擬的實驗結果》

在虛擬平台上的作業系統快速開機法

軟體開發的能力通常決定了一個系統是否能夠快速推向市場，其中的關鍵因素就在於有無作業系統的協助，透過作業系統，軟體開發者能專注於應用程式開發，避免浪費時間在撰寫低階且繁瑣的系統設定程式；再者，有了作業系統的協助，軟體程式的移植性將能大幅提升而增加軟體的可重覆使用性（Reusability），進而強化軟體開發的能力，所以目前許多的嵌入式系統都會採用作業系統以支援軟體開發。

然而，要讓嵌入式的系統搭配作業系統增進軟體開發能力有二個重要考量因素，第一是如何減少作業系統移植的代價；第二為如何快速完成作業系統開機流程。由於作業系統移植通常必須撰寫許多系統底層的硬體設定程式（例如：低階assemble 硬體驅動程式），而且必須瞭解其硬體規格，可是有關硬體規格與設定又常會牽涉到廠商的商業機密，所以造成作業系統移植上的困難；其次，執行應用軟體測試必須等待作業系統開機程序完成，可是作業系統的開機程序包含了許多流程，而這些流程常常耗費數億至數十億的指令執行時間，這對於軟體開發常需要執行重啟動而言是相當沒有效率的。針對以上所述狀況，其實也會發生在虛擬平台開發系統上，因此本文將提出一個在虛擬平台的作業系統開機法以簡化開機時繁複的流程，達成快速開機的目的。

為了解釋如何簡化開機流程，先以Linux的作業系統說明作業系統的生成方式與開機流程中的幾個重要步驟，如圖八所示，圖的上方為作業系統的生成步驟，生成步驟為由右至左，有關於系統任務排程、檔案系統配置等作業系統核心程式在最右邊，透過其編譯器後則產生了「image」的bin檔，其後為了節省記憶體空間，所以會對image檔做一次壓縮而產生了「piggy.gz」，最後，則是加入硬體廠商所提供的硬體驅動程式而產生zImage，因此作業系統的開機程序其實就是上述作業系統的生成步驟倒過來執行（如圖八下方的流程所示），讓系統執行至作業系統中核心程式後再開始執行開發的軟體。由圖八可知，作業系統開機程序主要包含了四個部份，1. Bootloader：純粹由硬體控制將壓縮後的OS影像檔載入，2. Bootstrap loader：創造虛擬環境方便解壓縮作業系統之影像檔並重新定址linux kernel，3. Kernel vmlinux: 由linux kernel對系統掌控，偵側系統並設定對應系統參數，4. Kernel main.o：進入main.c，開始對所開發之軟體程式服務。

《圖八　 作業系統編譯過程與開機流程》

瞭解作業系統開機過程後，發現作業系統開機流程的前兩個步驟對於軟體開發來說其實是毫無意義的，因為它們的目的是讓系統在啟動電源後，硬體裝置在沒有作業系統協助下能夠自動將作業系統的影像檔載入系統記憶體（通常為ROM或Flash Memory）中，並且填入作業系統所需之系統參數資訊至預設記憶體內，再讓作業系統啟動並將系統控制權交由作業系統掌控，對此，我們的想法就是提出一個方法讓作業系統開機程序可以跳過這些繁瑣的流程，直接啟動作業系統，並讓作業系統可以直接對軟體開發之應用程式進行系統排程、記憶體管理、檔案管理等任務，達到幫助軟體開發之目的。

由於虛擬平台所建構之系統全是由軟體所達成，所以可以讓系統中所有硬體模型皆能透過指標方式進行模組內資料的存取，善用虛擬平台的這個優點將所有作業系統啟動時所需要的預設記憶體資訊記錄起來後，再如同圖九所示，分別達成以下工作以快速完成作業系統開機程序：

• 一、將未壓縮過的作業系統影像檔（Image）複製在定義好的系統記憶體區塊內。





• 二、將ROM File System也複製在定義好的系統記憶體區塊，請注意此ROM File System存放著軟體開發之應用程式的執行檔，所以此步驟不能省略。





• 三、將處理器的程式計數器（Program Counter, PC）初始值調成作業系統影像檔所存放之記憶體位址，並啟動該系統，讓作業系統啟動後，再經由記憶體位址預設值找到對應的ROM File System，經由作業系統所支援指令的輸入後即可執行該應用軟體。

《圖九　 虛擬平台作業快速開機流程圖》

相較於傳統作業系統開機流程，本文的方法避開了如圖八的前兩個步驟，直接跳到與軟體開發之應用程式相關的部份，這種做法的好處是避開了繁雜的系統底層設定，並且不再需要依賴廠商所提供控制的Boot Loader相關硬體模組驅動程式，使得系統開發者能夠擺脫該驅動系統對於商業考量因素所造成的限制，進而便利且彈性地移植作業系統至想要發展的虛擬平台上。

除此之外，由於這種作業系統開機方式是直接跳到圖八中的第3階段，此階段對於大部份作業系統來說，其所需要驅動程式的編輯方式已經能夠被高階的語言所支援（如C語言），所以對軟體工程師來說將能更有效率的撰寫所需要的驅動程式。最後的一種好處是這種作業系統開機方法可以省略大量對解壓縮作業系統影像壓縮檔時所需要的模擬（此段模擬過程為如圖九中的傳統作業系統開機程序中的第一步驟與第二步驟），促使作業系統開機更加快速，依照實驗數據，若採用傳統方式的作業系統開機方法，所有的開機過程約需150~250百萬指令數（依照對應的BootLoader與作業系統所支援之驅動程式多寡而有所變動），相對的，本文對於虛擬平台上所提的作業系統開機方法，只需耗費約30百萬指令數，如圖十所示，配合DAVSA後，成功讓一uClinux的作業系統在約14秒時間內在一個仿照ARM Versatile的虛擬系統上完成開機程序。

《圖十　 uClinux作業系統開機完成與相關模擬資訊》

讓虛擬平台與真實SoC接軌

由於使用者可以利用虛擬平台快速建立SoC原型以達成系統功能驗證，並且在虛擬平台上輕易並彈性地調整其系統架構，找出對系統最佳的軟硬體配置（Hardware/Software Partition）方式，以提升SoC設計的正確率與效率。所以如何讓系統設計者有意願採用虛擬平台，第一個前提就是必須提升虛擬平台的模擬速度至MIPS（Million Instructions Per Second）等級，如同在採用FPGA所建置的系統原型一般。因此本文提出一個加速虛擬平台模擬速度的演算法（DAVSA），這個演算法讓系統模擬的精確度在時脈精準度的條件下，依然能達到3~5 MIPS的模擬速度，藉由DAVSA的幫助，讓相較於那些採用像RTL模擬方式（其模擬速度通常只有數KIPS，甚至不到）的SoC設計者，能夠在有限的時間裡進行更多的系統功能模擬。

除此之外，一個系統是否能夠快速且成功地推向市場，軟體開發能力是一個指標性的因素，為了提升軟體開發能力通常會採用作業系統，作業系統的功用是讓程式設計者能集中注意力在應用程式的開發而非花費大量時間在對付繁瑣的系統底層設定，因此本文亦提出一個在虛擬系統中對於作業系統的快速開機法，做法是善用虛擬平台優點去避開作業系統開機流程最繁瑣的部份，這種方法的優點在於不但可以加快作業系統開機的速度還可以降低作業系統移植的難度，另外，這種開機方法也可以配合前面所提的DAVSA讓整個作業系統開機模擬更加迅速，所以使用者就可以在有作業系統協助下並且具MIPS模擬速度等級的虛擬平台上去解決真正SoC設計時所須面對的問題。

---本文由台灣大學電子工程學研究所設計證驗研究室所提供，該研究室目前由黃鐘揚博士負責，主要研究領域包括正規方法驗證、電子系統層級設計與驗證等相關研究---