Global Sources
電子工程專輯
 
電子工程專輯 > EDA/IP
 
 
EDA/IP  

仿真驗證加速Pre-Silicon軟體開發

上網時間: 2014年11月05日     打印版  Bookmark and Share  字型大小:  

關鍵字:仿真驗證  模擬  RTL  仿真器  Codelink 

作者:Russell Klein,Mentor Graphics公司仿真部門技術總監

系統單晶片(SoC)開發不再僅僅是簡單的晶片開發過程。現代設備大量使用了各種軟體,包括軟體堆疊、中介韌體、啟動程式碼和驅動程式。你大可悠然自若地等到晶片開發完成後,再將其放在電路板上開始進行軟體的開發。然而在激烈的市場競爭中,時間就是生命。在緊迫的日程裡,若能在晶片製作完成前先著手進行軟體開發,將成為一個巨大的競爭優勢。

為了實現這一點,必須滿足以下三個要求:首先需要一套可供暫存器傳輸級(RTL)設計高速執行、且在晶片或開發板準備就緒前就能在其上正常執行軟體的仿真系統(emulation);此外,還需要一個高速、基於交易的協同建模通道將仿真器(emulator)與基於工作站的軟體除錯工具進行連接;最後還必須提供符合軟體開發人員需求的軟體除錯環境。

Mentor企業級驗證平台
Mentor企業級驗證平台將先進的模擬解決方案、仿真資源技術以及強大的除錯環境整合在一個全球共用的高性能資料處理中心資源。

為一種硬體還沒有成型的產品開發軟體時,首先需要一個能執行程式碼的環境。通常有兩種選擇:實體環境或虛擬環境。大多數專案都是根據某個現有設計,在原有版本中添加某些功能,使原有版本功能更強、速度更快、性能更好。這種情況下,有可能從接手專案的原有設計版本中直接獲取現成的電路板,或者能取得該電路板的軟體環境以進行軟體開發,用自己的除錯環境來為其進行驗證。

截至目前為止,最簡單的做法就是在現成的電路板上執行。如果是開發一個全新的軟體,則可以使用一塊新的開發板,運氣好的話,或許還能找到類似的開發板。還有一種可行的方法,即在一個虛擬電路板上執行,如虛擬機器(QEMU)。QEMU是一個開放源碼的系統仿真器,可隨意模擬各種ARM主機板。ARM主機板也有一個虛擬平台,稱為‘基礎模型’(可在官網上免費使用),類似於QEMU,可執行ARM程式碼。二者都引進了除錯器工具。

  

有了可執行和除錯程式碼的環境,就可以展開程式設計了。在某些情況下,你將需要取得一些還未成型的全新週邊設備,因應此問題的一個解決方案是創造一個模型。我們先從一個非常簡單的例子入手:讀取這個新週邊設備的ID暫存器。

許多週邊設備都有ID暫存器,這是一個唯讀暫存器,讀取時返回固定的已知數值。這就好像讓驅動程式多了些許自信,讓其意識到設備在與正確的週邊設備通訊。很早以前,在驅動程式初始化時,讀取暫存器並將其與預期進行比較就是一件較為敏感的事情。以下是一個ARM pl011串列驅動程式的例子:

校驗一個新週邊設備的ID暫存器
校驗一個新週邊設備的ID暫存器

驅動程式碼使用巨集readl和writel對暫存器進行讀寫。這些在linux核心中定義的驅動程式被作為一種存取硬體的方式。但假如啟動了一個新的驅動程式,就可以在本地進行重新定義,以得到所需的反應。例如:

重新為新驅動程式定義讀/寫巨集指令
重新為新驅動程式定義讀/寫巨集指令

其實不必真的存取至實際硬體,就能開始進行軟體開發。當然,也可以採取極端的做法來建模一個完整的週邊設備,但無論如何請不要嘗試最簡單的週邊設備,因為那樣很容易產生故障。一旦出現基本的訊號交換失敗並且只能維持簡單的執行,那麼可能即將面臨收益遞減。

假如處於虛擬環境,如QEMU或ARM快速模型(AFM)—基礎模型的付費版本,就可以導入更加複雜的模型。AFM連接了 System-C,相較於存根程式碼(stub-code),這是一種更適宜於建模硬體行為的環境。QEMU也可以擴展模型,但經驗不是憑空而來的,需要經過多次實踐。與許多開放源碼專案一樣,程式碼即是文檔。若使用了QEMU,但又不想在一團糟的C程式碼中苦苦掙扎並嘗試理出頭緒,那麼一旦需要超越存根程式碼,可能就想要跳過這個階段。

  

很多情況下,無法使用存根程式碼進行驗證,甚至連為軟體執行所創建的更複雜System-C模型也無能為力。例如,你無從得知硬體團隊和軟體團隊在設備中使用的是否是同一個暫存器映射。透過一個不會做出任何意料之外反應的暫存器,根本無從驗證其設置是否正確。如果同時編寫驅動程式和相應的週邊設備模型,也只能證明對二者的理解是相吻合的。

虛擬原型系統可用於創建所需的更複雜化模型,如Mentor Graphics Vista。在一般情況下,這些模型的處理速度非常快,軟體執行也很順暢。如果硬體團隊創建了虛擬原型模型,那麼在該模型上執行軟體時,便能驗證軟硬體團隊的設計觀點是否相符。二者的設計觀點通常會存在差異,但若能儘早發現這些差異,則可在設計週期的後期避免不少麻煩。在一個軟硬體都易於除錯的工具中,要實現這一點並不難。

  

虛擬原型有一個開發軟體週邊設備的完整功能模型。設計者將能以實現終極目標系統同樣的方式來創建自己的軟體,還能存取週邊設備的暫存器,就像在真實的硬體上執行一樣。此外,透過虛擬原型可直接查看這些週邊設備暫存器,在無任何干擾的情況下,除錯過程變得更容易。設計者將能充分地編寫驅動程式並驗證其執行是否正常,甚至還可以粗略計算出所需要的時間。然而,精確的驗證時間計算還得等到與硬體更匹配的軟體問世。

值得注意的是,虛擬原型並不是真正的硬體,而只是一個模型。模型(以程式的形式)需要由人來編寫,但遺憾的是,由人手動編寫的程式偶爾會出現錯誤。還需要注意的是,硬體在一個抽象的層面上建模,可能引發實際硬體的至關重要的微妙差異。因此,即使驅動程式完全驗證了虛擬原型,設計者的工作仍未結束,還需要在更詳細的硬體環境中進行驗證。

硬體團隊已經創建了可執行的硬體模型,作為正常開發週期的一部分。他們在RTL使用一種硬體描述語言(HDL)來描述自己的設計。最終,透過一系列執行編譯器和分析器來執行該設計的HDL描述,創建模組以用於晶片製造。HDL可在模擬器上執行,並提供待生產硬體的時脈週期準確執行狀態。唯一的問題是,大部分以HDL描述的實體設計模擬器只能以幾十或幾百赫茲的頻率執行,無法達到兆赫,甚至連千赫都很困難──對於軟體程式人員來說,這種頻率低得幾乎毫無用處。

同樣地,HDL可用於編寫可程式設計邏輯器(FPGA)或仿真系統程式,如Mentor Graphics的Veloce。FPGA和仿真系統可執行相同的程式,作為HDL模擬,但它們的執行速度是兆赫級的。對於軟體工程師來說,這一速度仍然不夠,但至少是可用的。

  

一旦已經使用了存根程式碼和虛擬原型的全部功能,假如有一個是可用的,那麼下一步就是在一個更加精確的硬體模型上驗證所編寫的程式碼,具體來說,就是RTL。開始這一步驟的最佳方法是將虛擬機器(QEMU或AFM)與硬體的RTL模型結合起來,在模擬或仿真環境中執行。

Mentor Graphics的產品Warpcore將虛擬機器與RTL執行環境進行結合,僅在RTL被存取時才執行RTL模擬器或仿真器。將虛擬機器與模擬環境相結合,以幾百赫茲的頻率執行,如果在不過度執行硬體的情況下,這種做法是可行的。如果硬體只執行一百萬個時脈左右,還是非常可觀的。通常情況下,模擬器更易於建立、存取和除錯。一旦設計者必須使硬體執行超過一百萬個時脈週期,就必須使用仿真系統以實現更優良的性能。

  

執行虛擬機器和仿真系統的結合,或一些供應商所謂的‘混合仿真’(hybrid-emulation),可在精確硬體模型的一個時脈週期中快捷、簡便地執行軟體。一般這種配置的性能為100MHz,這並不是即時的,但是其速度足以執行和除錯完整的軟體堆疊。

仿真不再僅僅是模擬加速
仿真不再僅僅是模擬加速

可對週邊設備進行一些簡單的測試,但要對驅動程式進行徹底的驗證,週邊設備只進行‘環回’(loop-back)是不夠的。這意味著將其與外部世界相連接,無論是透過仿真器上的I/O埠,還是接取至仿真器連接的電腦模型或主機介面模擬器。Mentor的模擬系統中,將其稱為co-model主機。模擬co-model主機和仿真器之間快速有效的連接對於維持高水準的性能是至關重要的。

  

值得注意的是,在這個配置中完整的設計不是在RTL中。這意味著系統將正常作業,但不會表現出與最終產品相同的性能特徵。從這個配置中能夠看出某些方面的性能,如某些元件之間轉換的流量。但是詳細的性能分析則必須對系統進行更準確的表達。

當RTL代表整個設計時,將可取得整個系統一個時脈週期的準確模型。這可以用來進行詳細的時間分析並得出輸送量、延遲以及回應時間的具體資料。要使系統有效執行,必須將其放在一個仿真系統或FPGA原型中。一個完整的系統包含一個實際的軟體負載,實際上無法使用基於軟體的模擬建模。你可能還記得,即使在仿真過程中,也只能以幾兆赫的頻率執行。這遠遠超過了基於軟體的模擬速度,但與實際時間相比還是要慢得多。

  

進行仿真設計時,必須在嵌入式處理器中除錯軟體。一般這種除錯會使用系統可用的硬體介面(例如JTAG介面)連接硬體除錯探針來完成。但是有一個問題:儘管JTAG很適合除錯功能問題,但卻難以用來除錯性能和時序問題。因為‘混合’虛擬機器和仿真的性能更高一籌,你會想在這上面除錯所有的功能問題。因此,僅存的問題就是時序和性能相關的問題了。

JTAG和類似的除錯技術使處理器進入除錯模式,然後使用各種技術來從處理器和週邊暫存器中檢索資料。即使在最優情況下,這些操作至少也需要耗費成千上萬個時脈—通常是數以百萬計的時脈。而且這些除錯時脈通常只是處理器時脈的一小部分。由於在除錯時間點前後除錯工具導入了數以百萬計的操作時脈延遲,因此除錯性能和時序問題就變得極為困難。開發人員一般透過處理器追蹤來回溯除錯,以避免延遲。但即使收集處理器追蹤資料也會影響到正在觀察的系統的執行。

透過Mentor Graphics的Codelink產品,能夠收集在仿真中執行設計時的回溯資料,利用這些資料就能驅動傳統的軟體除錯。基本上,設計人員可獲得傳統軟體除錯中的所有功能──程式碼單步執行、設立中斷點、查看記憶體和變數。這樣就保留了仿真系統時脈週期的精確性,沒有任何副作用,而且還能具有完全的平行多核心能見度以及執行與回溯的能力。但許多性能問題很難在原始程式碼層面除錯,通常還需要一幅可對照硬體動作且在設計中執行的處理器動作時間軸視圖。Codelink收集這些追蹤資料,並導入Mentor的系統分析工具,便能對照顯示性能資料和硬體資料。要在這一開發階段對整個設計進行診斷,那麼這可能是視覺化性能問題和時序問題的最佳解決辦法。

FPGA原型通常比仿真執行得更快,因而更長的軟體執行時間是可實現的,還可能會發現更多設計上的問題。軟體除錯通常採用JTAG或者類似的技術來實現,但都存在上述的各種問題。在硬體除錯中,FPGA歷來都存在可視性有限的缺點。FPGA供應商提供的嵌入式邏輯分析儀只能提供有限的追蹤幅度、較淺的追蹤深度以及頻繁的重新測量,最終導致漫長且經常是突然的(回到原點)重新編譯(合成和P&R)。這使得在FPGA中除錯變得痛苦萬分,枯燥不已。

所幸新的技術上市了,不僅能提供成千上萬種訊號的可見視圖,並具備深入追蹤晶片與系統級動作的能力,還能提供前所未有的易用性和強大的執行時可配置性,透過消除大多數重新測量和反覆運算的需求,能大幅提高除錯效率。經過改善的除錯將對使用FPGA原型的體驗和效率產生正面的影響。

從簡單的存根程式碼開始,透過一系列更詳細和完整的硬體模型來推進,可在得到實際硬體晶片之前對軟體進行驗證。設計人員可以長時間保持最高性能和最易用的除錯環境,必要時使用詳細的模型驗證系統。此外,還需要一個通用的環境來產生、執行和除錯,以便和其他環境進行無縫轉換。而且這還將擴展到最終的晶片中,以便能對實際產品進行最終測試。

這意味著一旦取得了實體原型,需要做的就僅僅是確認所有功能都正常執行了。針對硬體的抽象模型和後期具有精確時脈週期的RTL硬體模型,最難的軟硬體互動問題將在設計階段就能解決。一旦實體原型就緒,就能大幅減少軟體開發的時間。





投票數:   加入我的最愛
我來評論 - 仿真驗證加速Pre-Silicon軟體開發
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首