為了在追求加速嵌入系統開發及維持其可靠性的同時，又能夠兼顧降低開發成本，產業界開始轉向可重組的設計架構，這種架構能夠適用於未來的任務要求，並且可以掌握系統失靈的狀況。這些可重組的子系統通常以資源受限的FPGA硬體、或者功能完善、帶有特定DSP的多核心處理系統為基礎。

以FPGAs做為目標硬體時，必須使用Verilog或VHDL來開發，而處理器的開發則是須透過C/C++。許多演算法與零件，特別是與通訊相關領域，會同時需要將以處理器為基礎與FPGA為基礎的兩種子系統作為目標。

美國桑迪亞國家實驗室（Sandia National Laboratories）與來自MathWorks公司的顧問展開一項計畫來評估這類應用的模型化基礎設計（Model-Based Design）。模型化基礎設計幫助他們從方塊圖產生C/C++或HDL，並將相同的演算法轉檔佈署到以處理器為基礎與以FPGA為基礎的兩種子系統上。這項計畫包含實現兩種標準化的通訊協定，Joint Architecture Standard Packet Protocol（JPP）與Joint Architecture Standard Reliable Data Delivery Protocol（JRDDP）。JPP與JRDDP為建立在SpaceWire-常用於嵌入式系統模組間通訊物理協定層級之上的高階協定。桑迪亞國家實驗室使用一個以手動編碼版本的協定來評估透過模型化基礎設計開發的執行成果。

本文將介紹這項計畫，聚焦於模型架構以及用來進行驗證的技術，證明了模型化基礎設計非常適合使用在協定的執行。

設計要求

JPP與JRDDP通訊協定指定了資料如何從來源節點傳輸至目標節點，並指定封包的格式與封包傳輸與再次傳輸的順序。

由於需要執行這些協定的活動是預先定義且有特定次序，使用狀態機因此成為一個合乎邏輯的選擇。我們決定使用Simulink和Stateflow來執行建立模型與產生C和HDL協定程式碼的狀態機。

模型架構

這項計畫包含利用Simulink和Stateflow開發JPP與JRDDP模型。作為一項詳盡的協定，JPP只需要一個發射器模塊與接收器模塊。JRDDP則比較複雜一些，由於它是一個可靠的封包傳送協定，擔保資料在應用程序之間的傳輸，因此必需具備傳送及接收資料封包與控制封包的模塊。

為了這項計畫而開發的模塊經過優化以執行在硬體上（FPGA）。使用者應用程序必須讓資料以運作時鐘頻率串流往返於模塊之間。發射器模塊提供了一個雙埠RAM模塊，使用者應用程序在觸發開始傳送的訊號之前先在這裡面串流資料。

接收器模塊維持兩組雙埠RAM，接收到的資料被串流為其抵達時候的樣子。當完整的資料封包形成，會以一個訊號脈衝通知使用者應用程序在對應的記憶體區域（bank）有一個完整的封包可以使用。

圖1 : 使用者應用程序與JPP之間的介面

所有的發射器模塊都有相同的架構。圖二為JPP發射器模塊的頂層架構。

圖2 : JPP發射器

這個發射器一端連結到使用者應用程序，另一端連結到SpaceWire介面

接收器模塊也有類似的結構（圖3）。

圖3 : JPP接收器

圖4為使用JPP協定傳送與接收資料完整應用程序。

圖4 : 以JPP為基礎的完整應用程序。發射器應用程序（左上）產生資料並使用JPP發射到接收器應用程序（右上）。JPP發射器與接收器（圖中）連接到SpaceWire介面。

執行更高階的JRDDP協定

JRDDP是一個高階的協定，因此建模會比JPP更有挑戰性。JRDDP定義了初始化階段發射端點與接收端點之間互相連結的通訊。一個節點可能具備多個發射和接收端點。完整的JRDDP端點必須將基礎JRDDP模塊組合在一起並為其安排計畫。

我們建立一個帶有兩個發射端點的範例發射器與帶有兩個接收端點的範例接收器來說明這個處理過程。

JRDDP定義了端點必須經過的幾種不同的狀態。在最初的狀態，端點是「關閉（Closed）」的。當使用者應用程序請求將端點打開，端點會轉換到「啟用（Enabled）」的狀態，在這裡端點發送一個打開的請求到遙控端點。接收到確認之後，端點轉換為「開啟（Open）」狀態。在「開啟」狀態，使用者應用程序可以發射資料到遙控節點。

模型化基礎設計讓我們能夠在一個Stateflow圖表裡面捕捉到整個複雜的過程（圖5）。

圖5 : JRDDP狀態圖

完整的JRDDP執行包含維持每一個端點的JRDDP狀態機，以及使用JRDDP來建立模塊：一個JRDDP發射模塊、一個JRDDP接收器模塊、一個JRDDP控制與確認封包模塊。我們需要建立Simulink和Stateflow模塊來把資料從SpaceWire介面引導到適當端點的狀態機，以及從端點的狀態機引導到SpaceWire介面。

圖6說明了兩個發射端點的JRDDP端點執行。圖的上方為兩個JRDDP狀態機，對應到兩個端點。中間的Stateflow圖表是一個封包的路由器，將控制與資料封包從每一個狀態機引導到控制或資料發射器模塊。這張圖表包含了一個將接收到的封包引導到適當端點狀態機的資料接收器。

圖6 : 雙通道JRDDP發射端點

將SpaceWire介面整合為桑迪亞IP

桑迪亞開發了VHDL智慧財產（intellectual property,IP）來建立SpaceWire接收器與發射器端點。對於桑迪亞來說，評估將一個已經使用在生產多年的IP整合到從Simulink模型透過HDL Coder產生的HDL程式碼的難易度是相當重要的。

Simulink可以進行黑盒子處理，子系統的建立僅包含了用來將手動編寫的實體物實例化的介面連接埠。工程師可以將空的子系統關聯到一個外部的VHDL實體物或Verilog模組。我們使用黑盒子來將桑迪亞的SpaceWire IP與Simulink模型結合，來開發完整的JPP與JRDDP協定介面。我們也使用黑盒子來與桑迪亞的手動編碼JPP協定的執行成果相比較，測試Simulink產生的JPP介面。

驗證與測試

在Simulink進行協定開發有幾個優點，特別是在非常高的層級測試協定的能力。在這樣的階層進行除錯比起在硬體或硬體模擬器除錯的成本更低、更容易、而且更快速。我們透過以下五個步驟來完成驗證：

1.在Simulink模擬發射與接收訊息。為此，我們在Stateflow建立一個SpaceWire介面的函式模型。Simulink支援高階除錯，讓使用者可以在模塊層級、在Stateflow狀態、以及在狀態轉換時都可以設置中斷點。除此之外，Simulink能夠激發狀態的轉換，提供視覺上的驗證讓模型的表現可以如同期望。

2.利用HDL Verifier透過Simulink模型協同模擬產生出來的VHDL來證實從Simulink產生的VHDL與原始Simulink模型帶來相同的結果。因此HDL Verifier自動地對結果、圖表、錯誤進行比較。在這個步驟，我們使用Stateflow來模擬SpaceWire介面；沒有使用到真正的SpaceWire IP。

3.再一次使用協同模擬，以桑迪亞的SpaceWire介面IP取代SpaceWire函式模型。我們使用協同模擬模型在ModelSim產生測試輸入值並在Simulink得到結果。

4.將接收器替換為桑迪亞的手動編碼執行的JPP接收器

5.以桑迪亞VHDL JPP接收器替換掉在Simulink與Stateflow開發的JPP接收器，並執行另一個協同模擬測試。這項測試確認了兩個JPP接收器是可以互相取代的。

結論

這項計畫證實模型化基礎設計可以被用在軟體與硬體進行高階協定的建模與實現。以Simulink和Stateflow建立協定模型帶來多項好處。第一，模型針對該協定提供了一個清楚的可執行規格。再者，自動產生C/C++與HDL程式碼促進了參考執行的快速開發。

模型化基礎設計具有除錯以及驗證在高階軟體環境執行的能力，是另外一個重要的優點。Simulink與Stateflow容許在模塊與訊號層級的狀態之中與狀態轉換階段設置中斷點。Stateflow也藉由推動狀態轉換讓階層式的狀態機除錯更便利。在高階除錯之後，協同模擬與FPGA迴圈模擬提供了設計的除錯與驗證功能。

以JPP的執行來說，HDL在ML507（以Virtex 5為基礎的板子）的資源使用率大約為1%。而對於JRDDP協定，兩個端點執行的資源使用率大約是10%。更進一步的優化與調整可以再降低資源使用率。由於手動編寫的版本並不是執行在XilinlxR平台，因此無法進行直接的比較，但是從Simulink與Stateflow模型產生的HDL的資源使用率對桑迪亞來說是可以接受的。

在模型化基礎設計，同樣的Simulink模型可以為處理器的佈署產生C/C++，以及為硬體（FPGA或ASIC）的佈署產生HDL。不論是HDL還是C/C++，都可以從相同的模型產生出來，但是Simulink模型必須依每一種執行，利用Simulink不同子系統的功能分別經過優化。

對於以處理器為基礎的執行，使用者應用程序可能會建立資料框架並傳遞到協定層，在這裡以完整的框架而不是單一的位元流來處理。以硬體為基礎的執行從使用者應用程序以硬體的時鐘頻率一次一位元地接收資料。

建立像是Simulink與Stateflow等高階語言的模型讓非硬體專家的工程師也能夠建立硬體執行。不過，我們還是建議有硬體專家的加入，以針對進行設計優化及最終的目標硬體整合。

（本文由鈦思科技提供，作者Hung Nguyen、William Marchetto任職於美國桑迪亞國家實驗室; Roger Theyyunni、Babak Soheili任職於MathWorks公司）