|
作者：Russell Klein，硬件加速器仿真部門技術總監，Mentor Graphics公司 片上系統(SoC)開發不再僅僅是簡單的硅芯片開發過程。現代設備大量使用了各種軟件，包括軟件棧、中間件、啟動代碼和驅動程序。你大可悠然自若地等到硅芯片開發完成后，再將其放在電路板上開始進行軟件的開發。然而在激烈的市場競爭中，時間就是生命。開發進度日益緊迫，若能在硅芯片制作完成前便著手進行軟件開發，將成為一個巨大的競爭優勢。要做到這一點，需要滿足以下三個要求：首先，需要一套可供寄存器傳輸級(RTL)設計高速運行、且在硅芯片或開發板準備就緒前就能在上面正常運行軟件的仿真系統；此外，還需要一個高速、基于事務的協同建模通道將仿真器與基于工作站的軟件調試工具進行連接；最后，還需要提供符合軟件開發者需求的軟件調試環境。 為一種硬件還沒有成型的產品開發軟件時，首先需要一個能運行代碼的環境。通常有兩種選擇：物理環境或虛擬環境。大多數項目都是基于某個現有設計，即在原有版本中添加某些功能，使原有版本功能更強、速度更快、性能更好。這種情況下，有可能從接手項目的原有設計版本中直接獲取現成的電路板，或者能取得該電路板的軟件環境以進行軟件開發，用自己的調試環境來對其進行驗證。到目前為止，最簡單的做法就是在現成的電路板上運行。如果是開發一個全新的軟件，你可以使用一塊開發板，運氣好的話，或許還能找到類似的開發板。還有一種可行的方法，即在一個虛擬電路板上運行，如虛擬機(QEMU)。QEMU是一個開源系統仿真器，可隨意模擬各種ARM板。ARM公司也提供一個虛擬平臺，稱作“基礎模型”(可在其網站上免費獲得)，類似于QEMU，可運行ARM代碼。二者都有引入調試器的工具。 
圖1：Mentor公司驗證平臺將先進的仿真器解決方案、硬件加速器平臺以及強大的調試環境整合在一個全球共享的高性能數據處理中心資源里。 有了可運行和調試代碼的環境，就可以開始編程了。某些情況下，你將需要訪問一些還未成型的全新外圍設備，應對此問題的一個解決方案是創建一個模型。我們先從一個非常簡單的例子入手：讀取這個新外圍設備的ID寄存器。許多外圍設備都有ID寄存器，這是一個只讀寄存器，讀取時返回固定的已知數值。這就好像讓驅動程序多了些許自信，讓其意識到設備在與正確的外圍設備通信。很早以前，在驅動程序初始化時，讀取寄存器并將其與預期進行比較就是一件較為敏感的事情。以下是一個ARM pl011串口驅動程序的例子：
圖2：校驗一個新外圍設備的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)”，可在精確硬件模型的一個時鐘周期中快捷、簡便地運行軟件。一般這種配置的性能為100 MHz，這并不是實時的，但是其速度足以運行和調試完整的軟件堆棧。 可對外圍設備進行一些簡單的測試，但要對驅動程序進行徹底的驗證，外圍設備只進行“環回(loop-back)”，還遠遠不夠。這意味著將其與外部世界相連接，無論是通過硬件加速器上的I/O電纜，還是虛擬模型或硬件加速器相連的主機的接口。Mentor的硬件加速器系統中，將其稱為co-model主機。co-model主機和硬件加速器之間快速有效的連接對于維持高水平的性能是至關重要的。
圖3：重新為新驅動程序定義讀/寫宏指令 需要注意的是，在這個配置中完整的設計不是在RTL中。這意味著系統將正常工作，但不會表現出與最終產品相同的性能特征。從這個配置中你能看出某些方面的性能，如某些組件之間轉換的流量。但是詳細的性能分析則需要對系統進行更準確的表達。 當RTL代表整個設計時，你將得到整個系統一個時鐘周期的準確模型。這可以用來進行詳細的時間分析并得出吞吐量、延遲以及響應時間的具體數據。要使系統有效運行，你需要將其放在一個硬件加速器或FPGA原型中。一個包括實際軟件的完整系統，實際上是不可能基于軟件仿真進行建模的。甚至在硬件加速器平臺上也只能運行于一兆赫茲。這遠遠超過了基于軟件的仿真速度，但與實際時間相比，還是要慢得多。 在硬件加速器上運行設計時，需要在嵌入式處理器中調試軟件。一般這種調試會使用系統可用的硬件接口(例如JTAG接口)連接硬件調試探針來完成。但是有一個問題：盡管JTAG很適合調試功能問題，但很難用它來調試性能和時序問題。因為“混合”虛擬機和仿真的性能更高一籌，你會想在這上面調試所有的功能問題。因此，僅存的問題就是時序和性能相關的問題了。 JTAG和類似的調試技術使處理器進入調試模式，然后使用各種技術來從處理器和外圍寄存器中檢索數據。即使在最優情況下，這些操作也至少需要耗費成千上萬個時鐘—通常是數以百萬計的時鐘。而且這些調試時鐘通常只是處理器時鐘的一小部分。由于在調試時間點前后調試工具引入了數以百萬計的操作時鐘的延遲，因此，調試性能和時序問題變得極為困難。開發人員一般通過處理器跟蹤來回溯調試，以避免延遲。但即使收集處理器跟蹤數據也會影響到你正在觀察的系統的運行。 Mentor Graphics有一款產品叫“Codelink”，通過它能收集在仿真中運行設計時的回溯數據，利用這些數據就能驅動傳統的軟件調試。本質上說，你可以獲得傳統軟件調試中的所有功能—代碼單步執行、設立斷點，查看內存和變量。這樣做保留了仿真系統的時鐘周期的精確性，沒有任何副作用。你還具有完全的并行多核可見性和運行與回退的能力。但許多性能問題很難在源代碼層面調試，通常還需要一幅對比硬件動作的、在設計中運行的處理器的動作時間軸視圖。Codelink收集這些跟蹤數據，并導入Mentor的系統分析工具，便能對照顯示性能數據和硬件數據。要在這一開發階段對整個設計進行診斷，那么這可能是可視化性能問題和時序問題的最佳解決辦法。 FPGA原型通常會比硬件加速器運行得更快，因而更長的軟件運行時間是可以實現的，還可能會發現更多設計上的問題。軟件調試通常采用JTAG或者類似的技術來實現，但都存在上述的各種問題。在硬件調試中，FPGA歷來都存在可視性有限的缺點。FPGA供應商提供的嵌入式邏輯分析儀只能提供有限的跟蹤幅度和較淺的跟蹤深度以及頻繁的重新測量，最終導致漫長、且經常是突然的(“回到原點”)重新編譯(綜合的和P&R)。這使得在FPGA中調試變得痛苦萬分，枯燥不已。幸運的是， 新的技術面市了，不僅能提供成千上萬種信號的可見視圖，并具備深入跟蹤芯片及系統級動作的能力，還能提供前所未有的易用性和強大的運行時可配置性，通過消除大多數重新測量和回頭迭代的需求，能極大地提高調試效率。經過改進的調試將對使用FPGA原型的體驗和效率產生積極的影響。
圖4：硬件加速器正變得不僅僅只是加速仿真。 從簡單的存根代碼開始，通過一系列依次更詳細和完整的硬件模型來推進，可以在得到實際硬件芯片之前對軟件進行驗證。你可以長時間保持最高性能能和最易用的調試環境，必要時使用詳細的模型驗證系統的各個方面。你將需要一個通用的環境來生成、運行和調試，以便和其他環境進行無縫轉換。而且這也將擴展到最終的芯片中，因為你會需要對實際產品做一個最終的測試。這意味著一旦你拿到了實體原型，需要做的就僅僅是確認所有功能都正常運行了。針對硬件的抽象模型和后期具有精確時鐘周期的RTL硬件模型，最難的軟硬件交互問題將在設計階段就能得以解決。一旦實體樣機就緒，就能大大減少軟件開發的時間。 |
