電子發燒友App
利用基于SystemC/TLM的方法學進行IP開發和FPGA建模
隨著系統級芯片技術的出現，設計規模正變得越來越大，因而變得非常復雜，同時上市時間也變得更加苛刻。通常RTL已經不足以擔當這一新的角色。上述這些因素正驅使設計師開發新的方法學，用于復雜IP(硬件和軟件)以及復雜系統的驗證。ST公司建立了一個設計流，它從高級抽象開始，易于將模型寫入IP的精密周期或RTL模型中。當轉入低級抽象時，建模變得復雜，故IP驗證也復雜。我們的方案最適合于這種應用場景，因為它允許人們在各地相似的環境中運行相同的測試平臺和測試場景，因而允許在整個開發周期里高效地復用所有的測試范例和環境。
?
在半導體領域，開發產品的第一步就是以高級抽象開發規范的模型，通常用C/C++來實現。這里，SystemC和C++庫提供了很大幫助。它簡化了共存的硬件和軟件設計的概念化。再加上實現事務級模型間對口連接的TLM傳送庫，SystemC加速了整個驗證過程。另一個重要方面是所有不同抽象架構中經過增強的可移植性。同一測試配置可以無縫地用于不同抽象級的設計。
?
本文將討論一種此類的方法學。最終的目標是設計和實現UWB MAC(媒體訪問層)IP。出于架構開發的目的，決定用SystemC來實現整個IP。還開發了抽象級具有不同程度變化的不同架構。所付出的努力比較少，最后得到的仿真速度很快，軟件的實際編寫也可以在設計周期非常早的階段開始。該IP的RTL結果被移植到了SPEAr系列的FPGA中。除了ARM內核和相應的一系列IP，SPEAr還提供一個可配置邏輯塊，這為用戶在實現其邏輯功能時提供了無與倫比的靈活性。從而縮短了上市時間，同樣也實現了空前的成本節省。
?
設計開發方法學
?
圖1所示的該方法學實現了開發的內核中的事務級建模(TLM)。TLM是一種對數字系統進行建模的高級方案，這里將模塊之間的具體通信與功能單元或通信架構的具體實現分離開。把總線或FIFO這類通信機制模型化成信道，用SystemC接口類將這些信道提供給模塊和部件。這些信道模型的信令接口功能將取代事務請求，這將減少具體的低級信息交換。
?
圖1：IP開發方法學流程。
?
在事務級建模時，
* 更加注重數據轉移的功能-即轉移的是什么數據，從那里來，到那里去
* 不太關注實際的實現-即不太關注數據轉移所用的實際協議
該方案使得系統設計師的實驗變得更加容易，例如，可以利用不同的總線架構(所有都支持公共的抽象接口)，不一定需要對與任意總線進行交互的模型進行重新編碼，只要這些模型能夠通過公用接口與總線進行交互即可。
?
在我們的方法中，起始點是對整個功能系統平臺進行建模。這是利用SystemC并通過sc fifo接口實現的。為了描述通信接口間的數據流，采用了各種架構。這些架構基本上都是協議需要遵守的參數和幀格式信息。圍繞IP創建了一個測試環境，環境中開發了測試平臺，來傳輸分別來自兩側的輸入，即發送和接收。在這兩種范例中，利用這種配置產生了預期的結果或參考。在抽象層，與平臺一起使用來進行修改，快速并有效地做試驗時將變得很容易，不過精度會降低一些。
?
圖中所示為用于開發中下一級輸入的配置平臺。這里的核心思想是確定系統的瓶頸并執行軟硬件劃分。該方案在進行軟硬件劃分方面是有效并安全的，因為平臺提供能夠用來識別出整個系統瓶頸的原始統計信息。該階段中，實現了IP的功能模型，使其具備了具體的接口，并嵌入了功能性。而在軟硬件劃分階段將對該方法學中所用的方案進行具體化。附加到該平臺上的另一個是DMA-PL080的TLM模型，下一步是用MAC HW RTL替代整個MAC HW SystemC功能模型，如圖2所示。整個周邊環境是一樣的，因此測試注入與其他步驟中的注入一樣。與之前環境的變化是采用了負責到信號變換的事務處理適配器。由于該系統基于ARM，適配器的書寫必須遵從信號級AHB總線接口。實際上，該平臺將相同的環境表征為現實系統，不過與此同時，開始面對仿真性能方面的問題。顯然，我們還不能用該配置來執行廣泛的調試/驗證，不過可以運行簡單的測試(具有較短的仿真時間)。
?
?
圖2：從SystemC MAC HW向VHDL RTL MAC HW適配器的轉換。
?
由于在當前仿真環境中發現瓶頸，我們對基于硬件模擬XTREME服務器的平臺進行評估，該平臺基本提供了硬件所需的FPGA塊，并提供了軟件與整個環境的無縫集成。基于XTREME服務器中早期平臺的移植只需要很少工作量，并且相對于基于ncsim的仿真環境，實現了5倍的仿真速度。很顯然，這使得我們能夠調試并執行VHDL RTL設計的驗證，否則將會浪費過多時間。同時，基于Xtreme服務器的平臺還提供了同等調試能力。
硬件/軟件劃分
?
系統中軟硬件劃分決策是最為重要的一個方面。之所以硬件/軟件劃分變得如此關鍵，是因為如下一些因素，如系統的實時處理需求，應用軟件的存儲限制以及其他因素。許多時候，設計開發階段一些決策依賴于直覺判斷或者先前的經驗。但當某些事情發生錯誤時這將蘊含一個風險。隨著系統復雜度以及流片成本的增加，這種決策方法可能會鑄成大錯。強調需要一種有助于實現更好軟硬件劃分決策的方法學具有許多原因。
?
在UWB MAC系統開發范例中，具有很多必須很好遵守的時間約束，這是因為應用層完全依賴于空中——即來自射頻天線的全局廣播定時。實現決策的方案建立在我們從具體的系統級平臺的執行中所獲取的經驗。我們能夠分析流水線數據通道中的數據流，能夠有效地發現它們是否將對系統構成任何瓶頸。通常，當系統中的數據流發送時，數據幀必須從MAC發送到PHY，而對于接收，所產生的數據幀則從PHY到MAC，并存入到存儲器中由軟件進行進一步的分析。在仿真場景分析過程中，能夠識別出是否需要在硬件中進行一些協議解析以采取及時的措施。
?
?
圖3：系統中著重硬件支持需求的應用場景。
?
圖3中詳細給出了一個決策范例。根據協議的需求，接收數據中有一個控制包，它通知下次發送事件的通用定時，即何時發送下一個數據包。考慮到MAC硬件是一個典型的數據通道，并將控制幀傳送到存儲器中，軟件對控制幀進行處理并決定打開發送窗口。在發送窗口打開出現問題時，用這種方案就能發現瓶頸。系統平臺結果被用來確認這一理解，于是能夠做出更好決策來實現效率更高的系統。圖3中的另一個場景顯示了軟硬件劃分后的結果。
?
第一個范例中，當軟件處理控制幀時，全局定時如下：
?
窗口編程時間=T+t RP +tPM+tintr+tsw_lat>T+texp，故在系統中，SW沒有對及時打開發送窗口的指令進行編程。
?
在第二個范例中，當MAC HW處理控制幀時，全局定時為：
窗口編程時間=T+tprg_win
?
與此同時，現有的SPEAr板起到了很大的幫助作用，因為在板上測出了AES-CCM引擎的性能。因此能夠推斷出硬件中存在AES-CCM，因為AES-CCM軟件算法給不出所需要的性能。
?
挑戰
?
被測設計(DUT)或被測單元(UUT)的測試對任何設計方法學來說都是最關注的一個方面。在開發的初始階段，即架構評估階段，必須需要一個高性能的性能仿真環境。具有行為功能TLM平臺能夠滿足這一需求，并對將要執行的功能進行功能檢查。當進入到低級抽象設計階段時，仿真性能大大降低，這成為有效驗證IP的一個問題。
?
軟硬件的系統級仿真與軟硬件的協同仿真一塊進行。ST有自己的平臺，這是一個包含硬件(RTL)的混合平臺，軟件利用SystemC書寫(見圖2)。該平臺的瓶頸是環境中所引入IP的RTL，而且注意到這將大大地降低性能。正如預期，這是所遇到的約束，而且對是否能夠比主仿真運行更快的可能性進行了評估。該方案基于Xtreme服務器硬件仿真，使得運行速度至少要比NCSIM仿真快10倍。
?
?
圖4：配有軟件的Xtreme服務器配置。
?
圖4所示的該技術對第一次仿真特別實用，不需要任何有關環境配置方面的工作量。其概念是在Xtreme的FPGA中運行RTL IP。開始時，引入的時鐘為軟件時鐘，但結果相當可喜，還簡化了RTL的系統驗證和調試。配置過程中，整個仿真環境是類似的，僅有的改變是用VHDL RTL IP替代SysC IP。試驗結果是仿真速度快了10倍。因此，Xtreme服務器平臺滿足了RTL驗證/調試所用平臺的需求。最重要的方面是具有與ncsim同等水平的調適能力。還提供了與SystemC環境的無縫集成。
?
調試功能
?
硬件方面的一個更具挑戰性的問題是調試。當自檢失敗時，就需要一個相關的測試范例。為了驗證該測試范例，在檢查失敗原因時必須檢查所有的主要信號。所以需要對信號進行存放，驗證，從而找出具體的原因。利用基于XTREME服務器的平臺可以很容易地執行所有這些功能，無須額外的工作量。通過將實際硬件移入獨立的FPGA，可以很容易地改善仿真速度，不過這種方法提供的調試功能較少。因此，基于XTREME服務器的平臺不僅改善了仿真速度，還能提供非常好的調試功能。圖5給出了分析結果。
?
圖5：A）不同平臺上的仿真性能。B）不同平臺上的調試復雜性。
?
工商網監
評論