何 巍，賀 飛，顧 明

（1.清華大學 軟件學院，北京100084；2.清華信息科學與技術國家實驗室 （籌），北京100084；3.清華大學 計算機科學與技術系，北京100084；4.信息系統(tǒng)安全教育部重點實驗室，北京100084）

0 引 言

全系統(tǒng)仿真是指在宿主機的操作系統(tǒng)上運行一個模擬硬件的程序來仿真目標硬件，在其上可以運行真實的軟件棧（包括操作系統(tǒng)和應用程序）［1］?，F(xiàn)有的仿真工具［2－7］大多是基于單機架構的，在使用上，它們往往存在著配置復雜、對機器CPU、內存等配置要求較高，軟／硬件邏輯改動無法同步等不足。為此，我們考慮到了嵌入式系統(tǒng)軟／硬件開發(fā)人員位于分布式環(huán)境的特點，設計了一種基于B／S架構的分布式仿真平臺。分布式的架構解決了上述單機架構的不足，此外它通過開發(fā)人員對子模塊軟硬件邏輯的局部更新，實現(xiàn)對系統(tǒng)全局仿真模型自動和增量式的更新。我們基于開源嵌入式全系統(tǒng)仿真工具SimSoC［2，3］實現(xiàn)了該仿真平臺。同時，我們的工程經驗也闡釋了將單機架構的仿真工具改成了分布式架構的一般規(guī)律。本文首先討論了嵌入式仿真工具從單機架構改成分布式帶來的優(yōu)點，然后給出了一種基于B／S架構的仿真平臺的設計與實現(xiàn)。最后通過兩個典型的場景說明了該平臺的應用。

1 從單機架構到分布式

在這一部分，我們將比較分布式的仿真平臺和基于單機的仿真平臺，討論分布式架構可能帶來的優(yōu)點。

考慮這樣一種基于B／S架構的分布式仿真平臺：軟硬件開發(fā)人員位于分布式的環(huán)境中，即在不同的地方，使用不同的機器進行開發(fā)工作。開發(fā)者通過仿真平臺的Browser端提交軟硬件邏輯、提交仿真任務。仿真平臺的Server端負責構建仿真模型，進行仿真計算。如圖1所示。

圖1 仿真平臺的B／S模型

這樣的一種分布式架構，相比基于單機的仿真工具，會帶來一些顯而易見的好處：①無需在本地搭建仿真環(huán)境，通過瀏覽器即可使用；②將非常消耗計算資源的仿真計算從本地機器轉移到了Server端；③開發(fā)者對軟硬件邏輯的改動通過提交到Server可以及時反映給其他開發(fā)者；④對通常是命令行界面、較難上手的仿真工具進行了封裝，只將有用的功能通過Browser端的GUI暴露給使用者。

此外，相較于單機架構，分布式架構提供了更方便的構建仿真模型的方法。在使用基于單機架構的仿真工具時，最重要、也是工作量最大的任務是構建仿真模型。仿真模型的構建依賴于對于目標系統(tǒng)（尤其是軟硬件邏輯及其接口）有全面和深刻的理解。在一些規(guī)模較大、邏輯較為復雜的嵌入式開發(fā)項目中，單人很難做到理解整個系統(tǒng)。因此，在實際項目開發(fā)中，往往有專職的仿真人員。這些仿真人員獨立于軟硬件開發(fā)人員，他們需要在整個開發(fā)周期里同開發(fā)人員溝通，了解開發(fā)人員的開發(fā)進度，跟進并理解最新的軟硬件代碼，搭建／更新仿真模型，將仿真結果反饋給開發(fā)人員。仿真人員的存在毫無疑問會增加人力成本和溝通成本。

而在分布式的環(huán)境中，在待仿真系統(tǒng)完成了軟硬件功能劃分后，首先通過Browser端描述系統(tǒng)的架構。此后，在整個系統(tǒng)開發(fā)周期中，不同分工的軟／硬件開發(fā)者只需通過Browser端提交子模塊相應的代碼邏輯，進行局部仿真模型的構建與更新，與此同時，整個系統(tǒng)的仿真模型會進行自動地、增量式的更新。在嵌入式系統(tǒng)開發(fā)中，不同開發(fā)者的分工不同。除了軟硬件開發(fā)者之間的分工差異之外，不同的硬件開發(fā)人員可能分別負責FPGA硬件邏輯中不同的子模塊。在分布式的架構中，不要求有專人對整個系統(tǒng)有全局性的理解以構建仿真模型，每個人可以專注于他所負責的子模塊。

2 分布式仿真平臺設計與實現(xiàn)

這個仿真平臺的重點是分布式框架，而非工具本身。因此在實現(xiàn)上，我們希望盡可能地集成現(xiàn)有的仿真工具，而非重新開發(fā)一個仿真工具。

我們選擇將開源全系統(tǒng)仿真工具SimSoC變成從單機架構變成分布式。本節(jié)將討論仿真平臺實現(xiàn)的技術細節(jié)。

2.1 B／S架構

在實現(xiàn)上，我們決定使用Flex［8］來開發(fā)Browser端。Flex是Adobe公司發(fā)布的基于Flash平臺開發(fā)富互聯(lián)網應用（rich internet applications，RIA）的技術。Browser端允許用戶通過GUI界面完成以下操作：編輯系統(tǒng)架構；提交／更新軟硬件邏輯；提交仿真任務，查看仿真結果。

Server端則起到了信息和控制中樞的作用。它負責：維護仿真資源庫；運行用戶提交的仿真任務；管理提交的軟硬件邏輯。

我們使用Java Servlet［9］作為Browser端與Server端的中間層。Servlet由Tomcat服務器進行加載，運行在Server端，它可以將來自于Browser端的Http請求翻譯成對Sim－Soc的調用命令。Java Servlet的存在，使得Browser端同Server端的仿真工具解耦，當使用非SimSoC的其它仿真工具時，只需要在Java Servlet重新定義Http請求到仿真工具調用命令的映射即可。

2.2 配置系統(tǒng)架構

用戶在使用Browser端配置系統(tǒng)架構時，并不需要從零開始搭建，而是可以復用一些預定義的仿真資源模塊。由于我們使用SimSoC作為Server端的仿真工具，因此這些仿真模塊會分別對應SimSoC里一些已經實現(xiàn)的SystemC類。這些預定義的仿真模塊包括各種體系架構的嵌入式處理器，內存、總線、各種外設等。當Browser端初始化時，會從Server獲得一個描述仿真資源庫的XML文件。在該文件里，定義了各個模塊的描述、端口、屬性等信息。

我們也可以參照SimSoC里現(xiàn)有的類來實現(xiàn)一個自定義模塊，然后修改SimSoC的Makefile文件，將自定義模塊加入其中后對SimSoC重新編譯，并且在描述資源庫的XML文件里添加對自定義模塊的描述。

為了方便用戶快速地描述系統(tǒng)架構，我們在Browser端提供了系統(tǒng)架構圖的畫圖工具。用戶可以通過畫圖工具以拖拽的方式將資源庫里模塊加入到系統(tǒng)架構中，并使用連接符來指定各個模塊的連接關系。圖2是配置系統(tǒng)架構圖時的用戶界面，它描述了ARM CPU、Memory和總線3個模塊，其中CPU和Memory的rw＿port端口與總線的target＿sockets端口相連，代表著將CPU和Memory綁定在了總線上。

此外，我們需要為每一個加入系統(tǒng)架構的模塊指定屬性。有些屬性是固定值。而有些屬性需要用戶指定，比如Memory模塊的大小或者CPU是大端或者小端。為此，我們?yōu)槊恳粋€模塊關聯(lián)了一個key－value鏈表。鏈表里的每一對key－value指定了該模塊需要在運行時確定的屬性。在Browser端選擇某模塊時，可以通過GUI界面來編輯模塊屬性。

圖2 架構：CPU和Memory綁定到Bus上

當在GUI界面完成對系統(tǒng)架構的描述后，我們需要將架構以XML的格式上傳并保存在Server端。描述系統(tǒng)架構主 要 有 純 文 本［5］和 XML［4，6，7］兩 種 方 式。 之 所 以 選 擇XML而非純文本格式，是因為XML在描述不可預見的數(shù)據和屬性時更具有優(yōu)勢。比如，資源庫里某模塊新添加了需要在運行時確定的屬性時，不需要更改XML格式的Schema，即可為XML增加描述該新屬性的能力。某個模塊對應的XML結點component主要有兩個子結點組成，第一個子結點nodes描述了架構中各模塊的類型、ID及其各自屬性，第二個子結點connections描述了各模塊端口之間的連接關系。圖3是圖2中架構對應的XML描述。

圖3 圖2所示的架構對應的XML描述

當需要調用某具體的仿真工具進行仿真時，需要將XML格式的系統(tǒng)描述轉變成該工具可以識別的架構描述。對于SimSoC，架構是通過SystemC［10］頂層模塊來描述的。在該SystemC頂層模塊中，實例化了需要用到的SystemC子模塊，并且指定了子模塊間的端口［11］連接關系。

圖4是圖2中架構最終生成的SystemC頂層模塊。

圖4 圖2中架構生成的SytemC頂層模塊

從XML描述生成頂層模塊的SystemC文件是由Java Servlet完成的。在代碼生成開始時，首先要進行預處理，即為資源庫里各仿真模塊獲得它的頭文件路徑、類名等信息，以便接下來的代碼生成時用到。然后解析描述架構的XML文件，獲取所用到的模塊及各模塊之間的連接關系。接下來，依次生成include語句，常量定義，為頂層類生成成員變量聲明、構造函數(shù)和析構函數(shù)。在生成構造函數(shù)時，需要實例化各模塊對應的成員變量，以及綁定各變量相應的端口。

2.3 提交軟／硬件邏輯

Server端使用SimSoC作為仿真工具，由于SimSoC實現(xiàn)了全系統(tǒng)仿真，可以運行同真實情況下一致的軟件棧，所以軟件開發(fā)人員只需要提交真實開發(fā)中用到的編譯好的二進制文件即可：比如對于ARM嵌入式處理器，只需要提交通過ARM交叉編譯工具生成的elf文件。軟件開發(fā)人員并不需要為仿真平臺準備單獨的編譯工具。

硬件人員提交 “運行”在FPGA上的硬件邏輯相對復雜。因為仿真平臺不包含真實的FPGA，所以硬件開發(fā)人員并不能直接提交燒錄到FPGA上的二進制文件。受Giano［4］做法的啟發(fā)，我們設計了一種基于 “雙向內存抽象”的描述FPGA硬件邏輯的方式。它要求FPGA被看作滿足特定接口要求的 “總線從”：FPGA在虛擬總線上占據了一段內存，這是一段CPU和FPGA均能訪問的雙向內存。CPU可以向這段內存寫入控制信號，控制FPGA的邏輯。CPU也可以從這段內存中讀取數(shù)據，獲得FPGA的內部狀態(tài)。

這里的雙向內存的含義是抽象的，仿真平臺并不對這段雙向內存的具體位置或語義做任何預先的假定，它可以是實際中的設備寄存器文件，先進先出隊列（first－in firstout，F(xiàn)IFO），通 用 輸 入 輸 出 （general－purpose I／O，GPIO），或者是異步總線上的傳輸數(shù)據包。這樣的一種抽象可以在最大限度上描述FPGA和CPU之間的基于不同形式的交互。雖然SimSoC本身并不能仿真FPGA可編程硬件邏輯。但是在 “雙向內存抽象”的假設下，我們可以將FPGA視做虛擬總線上一個SystemC模塊。它在虛擬總線上占據了特定的地址，并且會對該段地址的讀寫操作做出相應的反應。這一點上，F(xiàn)PGA同其它連接到總線上的內存映射外設模塊沒有區(qū)別。

硬件開發(fā)人員在提交硬件邏輯時，需要將項目開發(fā)中的用到的Verilog／VHDL等HDL源碼，抽象出行為模型，改寫成SystemC代碼。在Browser端，提供了新建、修改、刪除SystemC文件的功能。需要說明的是，可以有任意多的SystemC文件負責描述FPGA硬件邏輯。不同的SystemC文件對應于FPGA中的某個功能子模塊。這樣，不同分工的硬件開發(fā)人員只負責提交、更新其負責的子模塊對應的SystemC文件即可。唯一的要求是所有SystemC文件編譯生成的目標文件滿足與總線的 “雙向內存抽象”的假定，即可以響應來自總線的讀寫操作。

下面我們通過圖5中的例子說明了如何將Verilog代碼改寫成SystemC代碼。圖5中test模塊的verilog代碼中，mem是test與CPU共享的一段4＊32字節(jié)內存。CPU向REG＿A寫入值為0或者1的控制信號，在每個時鐘周期的上升沿，test模塊會根據REG＿A值進行相應的操作。將test模塊改寫成圖5中的FPGA類后，該SystemC類通過rw＿socket與總線相連，需要實現(xiàn)的接口是read＿word和write＿word兩個方法，分別處理來自虛擬總線的讀寫操作。在read＿word和write＿word方法中，當CPU讀REG＿A傎或向REG＿A寫入傎時，會觸發(fā)相應的邏輯。

圖5 test模塊的Verilog代碼和對應的SystemC代碼

3 應用場景及實例

本節(jié)將通過示例來說明這個仿真平臺的使用。第一個例子仿真在AT91X40系列板卡上運行eCos［12］操作系統(tǒng)，通過這個例子，我們將展示該仿真平臺的基本應用場景。第二個例子仿真一個32位計數(shù)器，通過這個例子，我們將展示如何在仿真平臺上進行軟硬件邏輯的協(xié)同開發(fā)。

3.1 在AT91X40上運行eCos

AT91X40系列屬于Atmel公司AT91 16／32位微控制器家族。它包括ARM7TDMI處理器核，內存（包括RAM、ROM和FLASH）和外設等。其中，ARM處理器核，內存等對應的仿真模塊在SimSoC標準發(fā)行包里已提供。另外，我們參考AT91X40的官方文檔為它的一些外設如中斷控制器、通用異步收發(fā)傳輸 器（universal asynchronous receiver／transmitter，UART）、計時器等用SystemC代碼編寫了相應的仿真模塊，并且編譯到了SimSoC中。

通過仿真平臺的Browser端，新建一個工程，將需要用到的仿真模塊如ARM Processor、Memory、各種外設及虛擬總線以拖拽的方式添加到系統(tǒng)架構圖中，并指定模塊間的連接關系。Browser端的系統(tǒng)架構如圖6所示。

圖6 AT91X40微控制器架構

我們根據AT91X40的官方文檔，為各個模塊設置相應的屬性，比如分別設置3個Memory模塊的起始地址和大小，使之分別模擬RAM、ROM和FLASH。我們還需要將編譯好的eCos操作系統(tǒng)elf格式的啟動引導文件通過ARM Processor的屬性窗口上傳到Server上。接下來，我們在Browser端選擇編譯該工程，在編譯期間，Server端的Java Servlet會根據描述架構的XML生成SystemC頂層模塊代碼，并且將其編譯成可執(zhí)行文件topExecutable。編譯完成后，通過Browser端提交仿真任務，Java Servlet會調用SHELL命令“.／topExecutable pathOfElfFile”，開始運行topExecutable，并且將eCos啟動引導文件的路徑pathOfElfFile作為參數(shù)傳遞給它。

我們可以將運行時USART仿真模塊的I／O通過Socket重定向到Browser端。圖7是Browser端顯示運行eCos時USART串口輸出的界面，用戶也可以通過該界面向USART輸入指令。

圖7 通過browser端查看AT91X40的USART輸出

3.2 32位計數(shù)器

該示例來自于Giano［4］，它是一個32位計數(shù)器，系統(tǒng)架構如圖8所示。

圖8 32位計數(shù)器架構

在該示例中，我們將ARM處理器、內存和FPGA連接在虛擬總線上。此外，我們還在總線上連接了一個名為Debug Console的調試信息輸出控制臺。計數(shù)器控制邏輯和計數(shù)邏輯分別實現(xiàn)在FPGA和ARM上。ARM和FPGA上的C與Verilog核心代碼如圖9所示。

可以從圖9中的Verilog代碼看到，ARM處理器和FPGA之間共享了一段4＊32字節(jié)的內存。ARM通過向Counter＿Reset寫入Reset信號重置計數(shù)器的計數(shù)，通過向Counter＿State寫入Enabled信號通知計數(shù)器開始計數(shù)，通過向Counter＿Reset寫入Reset信號重置計數(shù)器的傎，通過讀取Counter＿Value得到計數(shù)器當前的計數(shù)值。顯然，這樣的ARM和FPGA交互的方式符合上文中 “雙向內存抽象”的假定。

C代碼的main函數(shù)的主要邏輯是，在開始時讀取計數(shù)器的值，向Counter＿State寫入Enabled讓計數(shù)器開始計數(shù)，然后執(zhí)行一個空循環(huán)，消耗若干個CPU周期，最后再讀取當前計數(shù)器的計數(shù)，并且把計數(shù)器計數(shù)的增加在Debug Console中打印出來。

在Browser端的GUI界面雙擊FPGA結點，進入FPGA硬件邏輯編輯界面，新建SystemC代碼文件，將圖9中的Verilog代碼改寫成SystemC代碼。編譯并運行該工程后，可以在browser端查看Debug Console的輸出，如圖10所示，可以看出在ARM中C代碼執(zhí)行spin函數(shù)時，F(xiàn)PGA中的計數(shù)器計數(shù)值增長了1999365。

圖9 計數(shù)器的ARM上的C代碼和FPGA上的Verilog代碼

圖10 Debug Console的輸出

4 結束語

為了更好地輔助嵌入式系統(tǒng)軟硬件協(xié)同開發(fā)，本文設計了一種基于B／S架構的分布式協(xié)同仿真平臺。該平臺適應了嵌入式系統(tǒng)開發(fā)人員位于分布式環(huán)境中的特點，在開發(fā)者各自更新子模塊邏輯的前提下，系統(tǒng)全局仿真模型可以實現(xiàn)自動、增量式的更新。開發(fā)者在Browser端通過GUI界面配置系統(tǒng)架構，提交軟硬件邏輯，而將仿真計算、管理仿真資源庫等功能轉移到了Server端，這樣的一種Browser端和Server端各有分工的架構，彌補了基于單機架構的仿真平臺在使用上的缺點。我們基于開源嵌入式全系統(tǒng)仿真工具SimSoC實現(xiàn)了該仿真平臺，并應用了兩個實例來說明該仿真平臺的使用。

未來的工作包括進行更多的案例研究以提高平臺的可用性。此外，我們將研究該仿真平臺中，如何對提交的軟硬件邏輯進行版本管理，以幫助快速定位帶來系統(tǒng)功能錯誤的代碼邏輯變動。

［1］KE Huacheng.Design and implementation of a framework of complete machine simulator for embedded systems ［D］.Hangzhou：Zhejiang University，2009：9－10 （in Chinese）. ［柯化成.嵌入式全系統(tǒng)模擬器框架設計與實現(xiàn) ［D］.杭州：浙江大學，2009：9－10.］

［2］Helmstetter V Joloboff.A SystemC TLM integrated ISS for full system simulation ［C］／／Macao，China：Proceedings of the IEEE Asia Pacific Conference on Circuits and Systems，2008：1759－1762.

［3］Helmstetter C，Joloboff V，Xiao H.SimSoC：A full system simulation software for embedded systems ［C］／／Guiyang，China：International Workshop on Open－source Software for Scientific Computation，2009.

［4］Forin A，Neekzad B，Lynch N L.Giano：The two headed system simulator ［R］.Technical Report MSR－TR－2006－130.Redmond，WA，US.Microsoft Research，2006.

［5］Skyeye Community.Skyeye user manual［EB／OL］.［2011－01－26］.http：／／skyeye.org.

［6］Beltrame G，Bolchini C，F(xiàn)ossati L，et al.ReSP：A nonintrusive transaction－level reflective MPSoC simulation platform for design space exploration ［C］／／ASP－DAC.Seoual：Korea，2008.

［7］Beltrame G，F(xiàn)ossati L，Sciuto D.High－level modeling and exploration of reconfigurable MPSoCs ［C］／／NASA／ESA Conference on Adaptive Hardware and Systems.Noordwijk：Nethe－rlands，2008.

［8］Adobe Flex Community.Using adobe flex 4.5 ［EB／OL］.［2011－04－29 ］. http：／／www.adobe.com／devnet／flex／documentation.html.

［9］Rajiv Mordani.Java Servlet specification V3.0 ［EB／OL］.［2010－12－01］.http：／／jcp.org／en／jsr／detail？id＝315.

［10］Open SystemC initiative（OSCI）.IEEE standard for standard SystemC language reference manual（IEEE Std 1666－2011）［S］.http：／／standards.ieee.org／getieee／1666／download／1666－2011.pdf，2012－01－09.

［11］Open SystemC Initiative（OSCI）.OSCI SystemC TLM 2.0，Draft 2for public review ［EB／OL］.［2008－06－06］.http：／／www.systemc.org／.

［12］JIANG Juping.Development and application of embedded configurable operating system，eCos ［M］.2nd ed.China Machine Press，2008 （in Chinese）. ［蔣句平.嵌入式可配置實時操作系統(tǒng)eCos開發(fā)與應用 ［M］.2版.北京：機械工業(yè)出版社，2008］