協同驗證是一種相對較新的技術，它可以使軟件開發人員盡早接觸到硬件設計部分。而在該技術出現以前，嵌入式系統開發人員常常要等到硬件樣機做出之后才能編寫軟件，再把它放在系統上運行。隨著當今項目開發周期的縮短和復雜程度增加，迫使開發人員必須尋找新的途經，以便盡早開始編寫和調試軟件。本文以噴墨打印機控制器為例，介紹軟硬件協同驗證的一種實際應用。

    協同驗證就是在嵌入式系統模型上執行目標系統軟件，而該嵌入式系統則是在一個模擬器中運行。軟件執行時有一個專門的處理器模型通過普通的軟件調試器與硬件和軟件聯系，使軟件開發人員能看到二者的運行情況。為了提高性能，協同驗證使用了周期隱藏技術，以便在硬件模擬中去除總線訪問時間。周期隱藏雖然極大地提高了模擬的性能，卻會使硬件和軟件模擬失去同步，這對于依賴硬件定時器的驗證系統而言是一個嚴重的缺陷，使用實時多任務操作系統時這一點尤為明顯。事實上，許多開發人員認為在模擬硬件中運行實時操作系統(RTOS)是不可能的。

    美國In-System Design公司的開發人員使用協同驗證技術對噴墨打印機控制器(一個系統級芯片)用的VxWorks操作系統進行早期測試，測試使用Mentor Graphics的無縫協同驗證環境(Seamless CVE)和其它工具驗證硬件-軟件接口,并對RTOS在任務間的切換性能進行了研究。 

    硬件-軟件協同驗證

    協同驗證技術將一個專用處理器模型和一個運行于邏輯模擬器中的嵌入式系統模型結合在一起。硬件開發人員使用硬件描述語言(HDL)創建嵌入式系統模型，然后將可執行目標-系統軟件的鏡像文件加載到嵌入式系統模型存儲器中，就像在實際系統樣機上那樣運行，也就是把軟件放在一個“虛擬”的在線電路模擬器上運行，這樣就能在得到物理樣機以前對軟件進行測試。

    協同驗證中的嵌入式處理器模型有三個主要功能：首先當然是在執行指令時它必須能夠模擬出處理器的動作，做到這一點常用的方法是使用指令集模擬器；其次，它應使軟件設計人員能夠觀察和改變硬件和軟件的狀態，一般是通過圖形化調試器；，它要能夠與硬件進行交流，總線接口模型可提供這一功能。總線接口模型將處理器總線周期活動轉換成引腳狀態變更序列，在邏輯模擬器中模仿處理器總線的動作，總線接口模型還要能處理硬件設計中產生的復位、中斷和其它異步事件(圖1)。

    協同驗證將處理器模型和設計模型的其余部分聯系起來，使它們能夠協調運行，工作時一般從邏輯模擬器和軟件調試器開始，在硬件和軟件之間建立起通信聯系。設計人員首先啟動邏輯模擬，使設計運行起來，然后載入軟件的可執行鏡像文件(通常用軟件調試器)，再在調試器上進行硬件和軟件模擬。設計人員通過軟件調試器觀察處理器、寄存器及存儲器的內容和變動情況，邏輯模擬器和軟件調試器具有各自環境下所能提供的所有調試功能。

    帶有處理器和存儲器全功能模型的完整描述硬件設計雖然可以全部放在一個邏輯模擬器中運行，并從該設計的存儲器中執行代碼，但這樣做太慢了。實際的設計一般情況下每秒鐘運行5條指令，通過簡單的數學計算我們可以算出8個小時只能運行約144,000條指令。看一看大多數系統所含軟件的大小就可知道，這種執行速度做什么都顯得太慢，僅能驗證很小一段代碼。此外，只使用邏輯模擬器也無法得到軟件內部的調試可視性。

    增強模擬性能

    所有成功的協同驗證都利用了“周期隱藏”技術來改進性能，并且只執行軟件中起作用的部分。周期隱藏在主機系統存儲器陣列中直接處理某些存儲器的通信，而不通過邏輯模擬器。結果表明大多數總線周期都可以被抑止掉，并不會影響模擬的精度。讓我們看一個取指令的例子：當邏輯模擬器運行取指令時，需要將一個總線周期傳輸給存儲器控制邏輯和存儲器單元，存儲器然后把內容回傳給處理器，后者將它們解釋成下一條指令。為執行一個取指令操作，邏輯模擬器必須處理數以百計的模擬事件，這將消耗主機大量計算時間，然而取指令在硬件上并不會造成明顯的狀態變化，因此可從邏輯模擬器中安全地將其省略掉。

    為進行協同驗證，在硬件模擬外部設置一個簡單數據陣列，用以保持嵌入式軟件存儲器鏡像文件,這樣可使指令集模擬器以更快的速度取出操作碼，同時不影響模擬結果。指令集模擬器處理操作碼并確定需要產生什么樣的數據移動和總線周期，它將該信息傳送給協同驗證工具，后者決定是在數據陣列(“軟件”區)中還是在邏輯模擬內部的模型存儲器(“硬件”區)中進行處理。

    如果是硬件區，總線接口模型將從引腳接口驅動一系列信號轉換至邏輯模擬器中模擬總線周期。在讀周期里，數據隨任意中斷或其它總線周期處理過程中可能形成的禁止命令返回至指令集模擬器。如果我們將代碼空間放在軟件區中，也就是說它處在一個能快速訪問指令集模擬器的存儲器陣列中，這時硬件模擬只需要處理三個總線周期。大多數參考數據也可以屏蔽掉，此時還可以將硬件總線周期數減少到兩個。

    那么有多大比例的總線周期可從硬件模擬中隱藏掉呢？經驗顯示，嵌入式軟件產生的總線周期99.9%以上都能從硬件中屏蔽掉。直接訪問硬件模擬外部存儲器陣列的總線周期比邏輯模擬快10,000倍，假設一個程序產生1,000個總線周期，并且I/O周期相對于取指令和數據周期之比為1:1000，那么協同驗證要執行999個代碼和參考數據，速率為每秒鐘100,000次轉換，同時一個I/O周期每秒鐘發生5次轉換。這就要在I/O周期(硬件模擬)上加0.2秒，代碼和參考數據(軟件模擬)上加0.00999秒，總運行時間為209.99毫秒。

    很容易看到，邏輯模擬器是一個瓶頸，因為它占用了95%以上的時間。指令集模擬器相對也比較慢，但協同驗證本身的運行速度還要慢10倍以上。和一般人設想相反，用執行模式較快的軟件來替代指令集模擬器并不能對協同驗證性能作實質性的改變，即使在我們例子中將指令集模擬器性能提高1,000倍，其結果在總的工作時間上也只提高了不到5%(從209.99毫秒到200.00999毫秒)。

    我們可以得出結論，為了使協同驗證更為有效，大多數總線周期必須從硬件中屏蔽掉。幸好嵌入式代碼使我們能做到這一點，可將性能提高100倍。但它依賴于這樣一個事實，即硬件和軟件多數時候是對事件而不是對時間同步。像實時多任務操作系統之類硬件和軟件時間同步非常重要，此時實際驗證過程就需要用一些方法來處理周期隱藏所帶來的時間“偏差”。

    隱藏周期問題

    如上所述，由于所屏蔽的存儲器轉換類型并不影響被模擬硬件的狀態，所以協同驗證中隱藏總線周期對邏輯模擬幾乎或根本就沒有影響。但是假設設計要依靠由系統時鐘驅動的硬件定時器，那么當協同驗證禁止大多數總線周期的硬件模擬活動時時鐘將不再計時，定時器與運行在指令集模擬器中的軟件就會嚴重失去同步。

    協同驗證工具至少需要做兩件事來補償“時間偏差”。首先，必須仔細計算失去的總線周期時間，要考慮給定指令所用到的周期數，以及高速緩沖存儲器的時序、流水線效應、總線獲取次數和其它因素；第二，協同驗證工具應能對硬件設計中的定時器寄存器進行更新，并使邏輯模擬在任何重要事件發生時都立即做出響應，如像定時器發出的中斷等。

    模擬所需定時精度取決于要驗證的是什么。為使運行系統定時器保持狀態，我們可為每個總線周期假設一個時鐘數，然后簡單地對總線周期計數，這可使我們得到一個準確度約為10%或20%的粗略估算值。但為了具體描述系統性能，本例中的中斷等待時間需要更為準確的定時模型。我們用的是基于ARM的處理器，其模型包括用于內部流水線的定時模型，它同時考慮了等待狀態和總線獲取次數等情況。因為我們的處理器沒有數據高速緩沖存儲器，所以就沒有考慮高速緩沖存儲器。除了計算隱藏周期時間外，我們還必需確保定時器觸發中斷時，硬件沒有處在“隱藏”的總線周期內。這里的硬件設計是一個噴墨打印機用SoC控制器，使用PCL 3輸入子集并創建打印用光柵影像，它由一個ARM嵌入式處理器和ASIC邏輯組成，后者完成視幀-處理邏輯、存儲器控制邏輯和外部接口。外部接口包括串行、并行和USB接口，以及機械部分控制器(PMC)和前面板接口(圖2)。

    首先運行設計中的板級支持軟件包(BSP)，這是一個用于第三方鏡像應用的API(包括ASIC接口驅動器)，同時運行風河公司的VxWorks操作系統。為描述整體系統功能并觀察協同驗證工具的效果，我們創建了幾個小任務在RTOS中運行。

    協同驗證的目的是調試BSP及驗證系統是否能引導至VxWorks上。為做到這一點，需要證明中斷控制器及其驅動器以及串行口和定時器都工作正常，此外還要觀察協同驗證中任務的創建和調度情況，并判斷運行應用級代碼時性能是否足夠。

    無縫CVE運行協同驗證無需改變系統軟件。能夠運行實際的目標-系統軟件是很重要的，我們做了一些更改以便在沒有作硬件設計的地方也能工作，同時還對軟件進行修改以提高系統性能，為了使系統引導速度更快還將幾個存儲器測試縮短或省掉。將VxWorks標志打印至通用異步收發器(UART)要用一小段代碼，會占幾分鐘模擬時間，因此運行一次后也將其省掉；同時還修改UART驅動器，使其輸出一個可從總線上探測到的地址，并略去檢查所有可能波特率的UART測試；我們引用在大量存貯區域填零的C運行-時間庫，不使用調試宏初始化這些存儲器。

    運行協同驗證時硬件設計也需要作一些修改。我們用ARM提供的協同驗證模型替代處理器，這只需要增加一個新的VHDL結構和改變雙線配置即可。另外還需要用協同驗證模型代替幾個存儲器，該模型在邏輯模擬中不使用會降低速度的總線周期即能使軟件調試器訪問硬件存儲器，并使協同驗證工具從硬件和軟件的角度對存儲器得出的結論都一致。該方法非常直觀，不到的時間就能完成。

    硬件定時器可以與軟件同步，只要在定時器HDL描述中增加幾個函數調用，即可用軟件同步時間更新定時器狀態。我們改動了約40行HDL源代碼并在幾小時內完成了任務。

    ，在硬件中還要增加一個總線監視器，用來監視地址0x31000000處的寫入周期，也即在UART修改過的地址，從RTOS來的調試輸出就寫在這里。該項工作用ModelSim邏輯模擬器TCL/TK擴展語言編寫，總線監視器在Sun工作站上打開一個窗口，使我們看到RTOS執行時的輸出數據。 

    硬件-軟件同步

    在得到正確模擬結果之前，先要解決幾個時間同步問題。顯然，硬件定時器需要不斷更新，同時也要在所謂的“原子交換”期間保持同步，“原子交換”是一種相對于硬件和軟件而言非常小但必須執行的存儲器交換。設計中有幾個直接存儲器存取(DMA)通道傳送數據進出系統，我們要確保硬件有足夠的時間(或者模擬時鐘周期)完成所有DMA傳輸。，性能分析需要時間同步，而我們也對測量系統中斷等待時間很感興趣。

    設計中包含三個定時器，用于追蹤硬件時間和產生操作系統計時周期(16毫秒)。假設典型的隱藏與不隱藏周期之比為1000比1，則軟件在操作系統計時到達之前將經過約16秒鐘，我們希望將硬件操作系統計時減少為16微秒并且一切正常。當然如果某個任務所需要的硬件運行時間大于16微秒，系統就會失效，而這也是經常會發生的。將操作系統計時定為16微秒迫使任務調度算法采用“運行-完成”方式。由于我們許多任務只是簡單地一直運行下去，并且為了正確地驗證系統任務也需要運行一段時間，所以這里不支持“運行-完成”模型，我們的任務轉換模型為優先級搶先方式，同樣優先級的任務采用輪流方式。

    系統復位時，裝有系統引導復位代碼的ROM位于地址0x0處，但是VxWorks和嵌入式ARM處理器異常表運行也要用到這個地址的RAM，因此作為引導過程的一部分，我們將ROM從0x0移至0x800000，而將RAM從0x800000移至0x0，交換完成之后我們再執行ROM中的代碼。為了正確交換存儲器而不影響軟件，硬件和軟件必須處于不完全同步狀態，且協同驗證工具必須能夠在模擬期間重新配置存儲器區域。

    性能驗證

    軟件通過將指針和計數器值寫入DMA控制器的寄存器中建立DMA傳輸，它假定由硬件完成操作過程。為執行操作，硬件要運行一定數目的總線周期，但如果協同驗證屏蔽了大量周期，DMA操作就可能無法完成。有鑒于此，協同驗證工具必須能夠在DMA傳輸期間停止周期隱藏。我們可以在軟件中設置中斷點以便在DMA開始時停止周期隱藏；在硬件中則設置監視DMA完成的斷點，到時候使周期隱藏重新作用。這樣DMA就不需要手工干預就能正確運行了。

    我們的設計按協同驗證進行配置，并在Sun Ultra Sparc 60工作站上作了一系列測試，該工作站裝有2個360MHz處理器、2G RAM和Solaris 2.6操作系統。所有軟件工具均來自Mentor Graphics公司：硬件模擬器為ModelSim Version 5.4、軟件指令組模擬器/調試器為XRAY Version 4.4、協同驗證工具為Seamless CVE Version 4.0。軟件用C、C++和ARM匯編語言編寫，使用VHDL和Verilog兩種版本的寄存器-轉移級設計模型。時鐘節拍

    從復位到創建個VxWorks任務耗時約18分鐘，其中硬件初始化和自診斷占用了大部分時間。這時邏輯模擬器定時為1.6毫秒，系統的操作系統計時每16毫秒觸發一次。我們估計采用硬件時鐘連續運行模擬(即不直接進行定時器更新)而達到個操作系統計時點大約需要150分鐘(兩個半小時)，而達到第二個操作系統計時點差不多要3個小時。如果能直接更新定時器對隱藏的總線周期計數，我們就可抽出空的RTOS循環而不用在速度很慢的邏輯模擬器上慢慢爬行了。改造完成后操作系統計時的觸發速率可達每分鐘4次。

    我們創建并運行兩個任務，以便在RTOS于任務間切換時測量它的性能。任務很簡單，就是寫一個字符給UART，然后在工作站的窗口上將這個字符顯示出來，當字符送至UART時，任務就停止計時。通過監視字符的顯示情況，可測出系統在任務間切換時的性能。我們的結論是每秒鐘可以有16次切換。

    在另一個實驗中，我們將操作系統時段定為10個計時周期，總時間為160毫秒，然后讓RTOS在兩個簡單任務間切換，每個任務在一個時段內進行一個220,000次的簡單循環。將代碼分解開后，我們看到任務內部的循環含有11條指令，而總數約為2,200萬條指令，模擬結果發現每170秒鐘可完成一個時段。