基于SystemC/TLM方法學的IP開發及FPGA建模

　　圖中所示為用于開發中下一級輸入的配置平臺。這里的核心思想是確定系統的瓶頸并執行軟硬件劃分。該方案在進行軟硬件劃分方面是有效并安全的，因為平臺提供能夠用來識別出整個系統瓶頸的原始統計信息。該階段中，實現了IP的功能模型，使其具備了具體的接口，并嵌入了功能性。而在軟硬件劃分階段將對該方法學中所用的方案進行具體化。附加到該平臺上的另一個是DMA-PL080的TLM模型，下一步是用MACHWRTL替代整個MACHWSystemC功能模型，如圖2所示。整個周邊環境是一樣的，因此測試注入與其他步驟中的注入一樣。與之前環境的變化是采用了負責到信號變換的事務處理適配器。由于該系統基于ARM，適配器的書寫必須遵從信號級AHB總線接口。實際上，該平臺將相同的環境表征為現實系統，不過與此同時，開始面對仿真性能方面的問題。顯然，我們還不能用該配置來執行廣泛的調試/驗證，不過可以運行簡單的測試(具有較短的仿真時間)。

　　圖2：從SystemCMACHW向VHDLRTLMACHW適配器的轉換。

　　由于在當前仿真環境中發現瓶頸，我們對基于硬件模擬XTREME服務器的平臺進行評估，該平臺基本提供了硬件所需的FPGA塊，并提供了軟件與整個環境的無縫集成。基于XTREME服務器中早期平臺的移植只需要很少工作量，并且相對于基于ncsim的仿真環境，實現了5倍的仿真速度。很顯然，這使得我們能夠調試并執行VHDLRTL設計的驗證，否則將會浪費過多時間。同時，基于Xtreme服務器的平臺還提供了同等調試能力。

　　硬件/軟件劃分

　　系統中軟硬件劃分決策是最為重要的一個方面。之所以硬件/軟件劃分變得如此關鍵，是因為如下一些因素，如系統的實時處理需求，應用軟件的存儲限制以及其他因素。許多時候，設計開發階段一些決策依賴于直覺判斷或者先前的經驗。但當某些事情發生錯誤時這將蘊含一個風險。隨著系統復雜度以及流片成本的增加，這種決策方法可能會鑄成大錯。強調需要一種有助于實現更好軟硬件劃分決策的方法學具有許多原因。

　　在UWBMAC系統開發范例中，具有很多必須很好遵守的時間約束，這是因為應用層完全依賴于空中——即來自射頻天線的全局廣播定時。實現決策的方案建立在我們從具體的系統級平臺的執行中所獲取的經驗。我們能夠分析流水線數據通道中的數據流，能夠有效地發現它們是否將對系統構成任何瓶頸。通常，當系統中的數據流發送時，數據幀必須從MAC發送到PHY，而對于接收，所產生的數據幀則從PHY到MAC，并存入到存儲器中由軟件進行進一步的分析。在仿真場景分析過程中，能夠識別出是否需要在硬件中進行一些協議解析以采取及時的措施。

　　圖3：系統中著重硬件支持需求的應用場景。

　　圖3中詳細給出了一個決策范例。根據協議的需求，接收數據中有一個控制包，它通知下次發送事件的通用定時，即何時發送下一個數據包。考慮到MAC硬件是一個典型的數據通道，并將控制幀傳送到存儲器中，軟件對控制幀進行處理并決定打開發送窗口。在發送窗口打開出現問題時，用這種方案就能發現瓶頸。系統平臺結果被用來確認這一理解，于是能夠做出更好決策來實現效率更高的系統。圖3中的另一個場景顯示了軟硬件劃分后的結果。

　　第一個范例中，當軟件處理控制幀時，全局定時如下：

　　窗口編程時間=T+tRP+tPM+tintr+tsw_lat>T+texp，故在系統中，SW沒有對及時打開發送窗口的指令進行編程。

　　在第二個范例中，當MACHW處理控制幀時，全局定時為：

　　窗口編程時間=T+tprg_winexp，故系統中，HW對及時打開發送窗口的指令進行編程。

　　與此同時，現有的SPEAr板起到了很大的幫助作用，因為在板上測出了AES-CCM引擎的性能。因此能夠推斷出硬件中存在AES-CCM，因為AES-CCM軟件算法給不出所需要的性能。