模擬環境及架構

在軟硬體開發早期階段，提供快速的效能量測與粗估是很重要的，尤其時常 需要評估特定應用程式跑在特定平台上的效果。我們了解到應用程式的行為特性 常常可以代表該應用程式，並且利用其行為特性達到模擬該應用程式的目的，這 樣抽象化的描述降低了模擬設計的複雜度。同樣的硬體結構也有相同的特性，具 有一些參數來代表該硬體結構的特性，例如頻率、頻寬、延遲等等，將之抽象化 再搭配抽象化之應用程式模型來做行為層級（Behavior Level）的模擬，比較起指 令層級模擬（Instruction Level）甚至是暫存器傳輸層級模擬（RTL Level），行為層 級模擬在準確度上雖不及其他較低層級的模擬，但是卻能省去低層級模擬必須花 費的冗長時間成本。如何建構出一個快速的模擬環境並且提供一個合理範圍之內 的準確度來滿足早期開發之需求是本章的重點。有鑑於此，我們利用獨立的應用 程式模型（Application Model）與結構模型（Architecture Model）來表示各自的行 為模式以及狀態，仿真應用程式與硬體結構，並利用訊號埠將兩者連結，達到協 同模擬的效果，如圖表 3-1 所示。

圖表 3-1 模型驅動模擬架構

整個模型的建置流程如圖表 3-2，接下來的下兩節將介紹應用程式模型與結構 模型的建置細節以及如何達成模型驅動模擬。

圖表 3-2 應用程式及硬體架構模型建構流程

3.1.1 應用程式模型

要簡單的建立一個應用程式模型，我們必須擷取出該應用程式的行為，例如 函數呼叫路徑、迴圈次數、以及相關的效能資訊等等，利用這些資訊抽象化應用 程式並且透過轉換的方式產生代表應用程式的模型。在這裡我們建立一個函數層 級（Function Level）的應用程式模型，將整個應用程式拆解成相互呼叫的函數，

在這條件之下，我們須蒐集函數呼叫路徑（Function Call Path）、以及各個函數平 均的所經歷的週期數、指令數、記憶體讀寫數等效能單位資訊（Performance Metrics）。

要蒐集這些資訊須對應用程式作深入的評測，可以透過 Intel Vtune Performance Analyzer[22]、Sun Dtrace[23]、GNU gprof[24]或是 Valgrind[25]等評測工具（Profiling Tools）取得，在這裡我們使用 ARM SoC Designer Simulator[26]的軟體評測工具，

並將得到的應用程式資訊紀錄成 xml 格式如圖表 3-3，以便於產生 SystemC 模型。

圖表 3-3 以 xml 格式紀錄應用程式函數行為與效能資訊

我們以 xml 的方式儲存效能資訊，主要是因為 xml 格式的可擴充性以及結構 化的表示方式，透過這樣的中介標記語言，日後便於我們的維護以及有效發揮資 訊利用的彈性度。有了這些函數層級的效能相關資訊，接下來任務即利用這些資 訊，將其打造成一個個函數任務區塊（Task Block），並建構成可執行的 SystemC 應用程式模型，這個應用程式模型仿真了每個函數的效能行為，包括上述所提的

<func_name>__Heap_Alloc</func_name>

<count>1</count>

<metric>

<cycles>66</cycles>

<mem_read>18</mem_read>

<mem_write>16</mem_write>

<inst_count>70</inst_count>

</metrics>

</function>

<function>

<func_name>__Heap_DescSize</func_name>

<count>2</count>

<metric>

<cycles>5.5</cycles>

<mem_read>0</mem_read>

<mem_write>0</mem_write>

<inst_count>6</inst_count>

</metrics>

</function>

</functions>

</path>

週期數、記憶體讀寫數等，並且也同時仿真呼叫的路徑，達成應用程式行為的模 擬，最後再透過 start 的函數啟動了應用程式的執行。資訊儲存於 xml 經轉換後產 生的 SystemC 應用程式模型範例如圖表 3-4。

圖表 3-4 根據 xml 紀錄的應用程式效能資訊轉換成 SystemC 模型

範例中顯示函數__Heap_Alloc()需要 66 個計算週期、18 個指令數、6 個記憶 體讀取及 3 個記憶體寫入，這些工作構成__Heap_Alloc 的任務區塊，待這些任務 區塊內的工作被模擬執行完畢後，才會呼叫__Heap_DescSize()，繼續下一個函數 級任務區塊的模擬。

3.1.2 硬體結構模型

將應用程式模型與硬體結構模型獨立分開，目的是希望在早期開發時期硬體 結構尚未成形的時候，透過改變硬體結構模型，搭配原本的應用程式模型進行協

void thread_test::__Heap_Alloc(){

cycles=(int)66;

inst_count=(int)18;

mem_read_count=(int)6;

mem_write_count=(int)3;

wait(suspended);

__Heap_DescSize }

void thread_test:: __Heap_DescSize(){

cycles=(int)5.5;

inst_count=(int)0;

mem_read_count=(int)0;

mem_write_count=(int)6;

wait(suspended);

}

型相仿，我們需要對目標的平台進行評測並且抽出參數，例如核心的數量、指令 擷取延遲、記憶體讀寫延遲、匯流排協定延遲等。圖表 3-5 是 ARM SoC Designer Simulator 模擬的嵌入式系統平台，也是我們的目標平台，圖表 3-6 左即為相對應 的 SystemC 模組，我們建立了處理器排程器、處理核心、匯流排仲裁、匯流排以 及記憶體模組，再利用 SystemC 提供的串接元件如埠與訊號，將各模組連成一個 網絡，達到溝通及任務轉移的功能，這些獨立的模組分別模擬出該元件收到要求 所產生的對應行為，例如 Processor Scheduler 負責接收任務並將之分配到 Core 中 進行處理，當多個 Core 同時發出記憶體存取的要求，Bus Arbiter 則是負責匯流排 主控權的仲裁，Bus 及 Memory 模組則模擬匯流排及記憶體的存取延遲時間。最後 利用 3.1.1 所提出的應用程式模型當作輸入進行交互模擬，如圖表 3-6 右圖。

圖表 3-5 ARM SoC Designer 的模擬平台

圖表 3-6 SystemC 硬體模組與應用程式模組