在SoC設計中用SystemC虛擬平臺預覽USB的性能
加入技術交流群
當設計師們小心地在其它軟件工具幫助下完成這個任務時，這些平臺被證明是有效的方法，可以對很多重要性能的度量做出早期評估，如有關嵌入軟件功能好壞及其與現(xiàn)有硬件的互相影響。虛擬平臺可以預測 CPU 效率、數(shù)據(jù)傳輸率以及緩存失中率、中斷等待時間、功能性熱點，以及其它性能的度量。
為了便于理解和體會虛擬平臺的性質與價值，考慮這樣一個例子：評估一個 USB 系統(tǒng)軟件棧的性能。開發(fā)者的選擇是有相當?shù)睦碛?，因?USB 2.0 有 480 Mbps 的傳輸速率，是承載實時音、視頻數(shù)據(jù)的常見選擇。因此，USB 在多媒體產(chǎn)品中得到日益廣泛的應用，如機頂盒和手機。
由于 USB 的互動中包含有復雜的協(xié)議和軟、硬件之間大量的相互依賴，因此特別需要這種平臺的幫助。這種情況下，不僅要求軟件架構盡早確認 USB 系統(tǒng)軟件，而且要估算出軟件在 CPU 上的負載，
這種性能預估要求虛擬平臺能夠對實際硬件功能，包括處理器、緩存和系統(tǒng)內(nèi)存、USB 外設、USB EHCI（擴展型主控制器接口），以及 USB 設備等，建立非常接近的模型。此外，還需要一個剖析工具來尋找軟件棧中的功能熱點，精確地預測出完成功能所需時間。開發(fā)人員用平臺得到的結果，與理論預測值做對照調(diào)整，而平臺也可以檢驗 USB 棧在實際硬件上實現(xiàn)性能的穩(wěn)定性。另外，當開發(fā)人員修改軟件棧時，平臺還可以精確地反映出性能的變化。
在本例中，設計師想出一種評估 USB 系統(tǒng)軟件棧性能的方法，該軟件棧運行在嵌入機頂盒芯片中的 DVR（數(shù)字視頻錄像機）子系統(tǒng)中。DVR 含有一個錄/放音、視頻數(shù)據(jù)流的 USB 硬盤驅動器。USB 軟件棧包括一個單線程 DVR 應用實例，它用驅動器完成一系列讀、寫操作。
功能平臺非常詳盡地模仿 DVR 硬件的運作，揭示出重要的時序參數(shù)。特別是該平臺建立了一個 USB 主控制器、硬盤驅動器和系統(tǒng)內(nèi)存與緩存的模型。平臺有一個新穎的功能，它含有一個用 SystemC 寫成的事務級模型，以此證明該方案能夠用于建立評估復雜嵌入軟件的虛擬平臺。開發(fā)人員一般采用 RTL（寄存器傳輸級）模型建立系統(tǒng)硬件的模型，與事務級模型相比，這種方法的抽象層次較低。
平臺設置
虛擬平臺包括一個 USB 2.0 EHCI、一個 USB 硬盤驅動器、一個緩存仿真器、一個主處理器指令集仿真器，以及系統(tǒng)內(nèi)存。USB 2.0 EHCI 模仿主控制器的功能，提供 480 Mbps 數(shù)據(jù)速率下的精確時序值，以及基于內(nèi)存模型的內(nèi)存訪問時間，還有 EHCI 寄存器的讀、寫時間。EHCI 亦作為一個 DMA 主控，可以不通過緩存訪問系統(tǒng)內(nèi)存。
為了跟蹤所有的指令與數(shù)據(jù)存取，USB 軟件棧運行在一個在事務級硬件模型上建立的指令集仿真器上。指令與數(shù)據(jù)記錄通過虛擬平臺，測量CPU使用率、緩存失中率以及中斷等待時間等。另外，用一個高度可配置、可擴展和模塊化的剖析工具 Flexperf 判別功能熱點，幫助完成軟件棧的排錯。
系統(tǒng)在尋址硬盤驅動器時是按照劃分為扇區(qū)的 I/O 文件，符合海量存儲設備規(guī)格，包括USB實施者論壇的“bulk-only”規(guī)格。于是，它可以通過端點 0 執(zhí)行所有標準的設備請求。它還可以執(zhí)行一個 SCSI 命令的子集，通過端點 1 和 2 與 DVR 相關。
緩存仿真器對一個可配置的緩存建模，該仿真器包括一個環(huán)繞式處理程序 Dinero 、一個追蹤驅動的開放源緩存仿真器。作為系統(tǒng)處理器，圍繞指令集仿真器的處理程序為一個 216 MHz STMicroelectronics C2 CPU 內(nèi)核建模。仿真器將處理器的內(nèi)存訪問轉換為事務級模型。開發(fā)者將系統(tǒng)內(nèi)存建模為一個 RAM 陣列，所有模型的連接都通過一個大體上基于 ARM AHB（先進高性能總線）的精確事務通道和一個開發(fā)者在 USB 上松散建模的通道。
調(diào)用該平臺對軟件性能參數(shù)的評估是一個分兩步走的過程（圖 1）。第一步，USB 棧運行在 ST20指令集仿真器上。這個過程生成一個追蹤文件，它記錄了所有的指令內(nèi)存和數(shù)據(jù)內(nèi)存訪問，以及硬件啟動的任何中斷。第二步，有一個流量發(fā)生器對追蹤文件進行語法分析，并在一個精確事務的通道上生成等效的事務級操作。
兩步走的評估過程體現(xiàn)出芯片設計的一般步驟。在第一步中，設計師將設計分解為獨立的功能塊，它們并行運行實現(xiàn)所需的應用功能。因此，第一個平臺只包括功能模型，而沒有參考時間。設計師用相同的功能塊，可以有不同的實現(xiàn)方法（主要是時序和性能模型），這就是第二步完成的任務。這個方案可以讓用戶使用一組相同的基準功能，嘗試各種微架構的實現(xiàn)。
結果就是一個基于 SystemC 的公共平臺，它沒有外部依賴性，SystemC 仿真器的時間作為評估性能的基準。同樣，系統(tǒng)將指令與數(shù)據(jù)內(nèi)存抽象成為 SystemC 事務級模型，準確地仿真訪問時間。這種兩步走方案還簡化了緩存仿真器與流量發(fā)生器的連接，這是一種在硬件上對緩存影響建模的方法。
性能參數(shù)
虛擬平臺生成的性能值是從運行應用程序的 SystemC 仿真器上獲得的總時間，相當于在實際硬件上運行的總時間。應用程序的運行時間依次與指令訪問時間以及與 EHCI、緩存和其它功能相關的等待時間有關。從這些值中，可以確定重要的性能度量，如 CPU 占用率、數(shù)據(jù)傳輸率、緩存失中率，以及中斷的次數(shù)。
當然，CPU 占用率是評估棧性能的最重要參數(shù)，它是 CPU 在執(zhí)行軟件棧時所花費時間的百分比。它表示 CPU 無法運行其它應用程序的時間。但是，要確定 CPU 占用率，必須首先確定并減掉 CPU 空閑時間?？臻e時間是軟件棧在空閑線
在這個點上，可以調(diào)用 Flexperf 剖析工具來測量 CPU 花費在空閑線程上的時間。將輸入追蹤文件以及一個映像文件饋送給剖析工具，前者中包含程序計數(shù)器和相應的時間。映像文件定義了與空閑線程功能有關的起始和終止地址。從這些輸入內(nèi)容中，剖析工具可以計算出在空閑線程上花費的時間，接下來就可以從CPU時間中減去這些空閑時間，獲得準確的CPU占用率數(shù)字。
還可以將通過USB的總數(shù)據(jù)量（包括控制、批量和協(xié)議信息）除以運行應用程序的總仿真時間，計算出通過USB的數(shù)據(jù)傳輸率。但是，USB2.0的480 Mbps速率只是一個理論最大值。由于協(xié)議開銷問題加上從系統(tǒng)內(nèi)存獲取計劃表和數(shù)據(jù)也要消耗時間，尤其是當EHCI緩存較小時，所以實際的數(shù)據(jù)速率要低得多。軟件將數(shù)據(jù)提交給硬件的速率亦會限制數(shù)據(jù)的速率。
當你提供有內(nèi)存流量信息的 Dinero開放源緩存仿真器時，它會生成有關指令、數(shù)據(jù)和總失中率的統(tǒng)計數(shù)字。從這個數(shù)據(jù)中，可以確定最佳的緩存配置。為了在ST20主處理器追蹤文件中記錄中斷的次數(shù)，可以累計ST20回繞式處理器捕獲的中斷數(shù)。從這些基本性能數(shù)字可以得到一些其它參數(shù)，包括指令集仿真器報告的執(zhí)行指令總數(shù)、CPU的執(zhí)行時間（總時間減去空閑時間）、CPU的總指令執(zhí)行時間，以及總CPU讀、寫時間。
本例中虛擬平臺獲得的性能結果是超出了本文討論范圍的數(shù)學推導。但是，這些推導的內(nèi)容包含最大 SCSI 緩沖、讀/寫操作時傳輸?shù)臄?shù)據(jù)量、系統(tǒng)軟件為中斷服務花費的時間，以及處理與硬盤驅動器有關的 SCSI命令的時間等之間的關系。
使用虛擬平臺，可以得到塊的大小、總數(shù)據(jù)傳輸量、緩存參數(shù)、數(shù)據(jù)傳輸機制、棧尺寸、CPU占用，以及其它重要的性能數(shù)據(jù)等結果。通過虛擬平臺的預測與硬件結合起來，可以極大地簡化開發(fā)確定過程。
例如，虛擬平臺表明增加塊大?。疵看巫x、寫操作時傳輸?shù)臄?shù)據(jù)量）可以降低CPU占用率（表1）。但是，塊越大，降低的程度越少。平臺亦預測CPU使用率會隨數(shù)據(jù)傳輸量的增加而下降。平臺作這些預測的前提是采用216 MHz的ST20-C2內(nèi)核，10 ns緩存命中等待時間，160 ns 的單字內(nèi)存訪問時間，以及可在等待硬件中斷前緩沖最多256kB數(shù)據(jù)。該平臺亦假定緩存模型含有8kB、雙向、組合式指令與數(shù)據(jù)緩存，每個有16B的塊。另外，它還假定USB的傳輸速率為80 MB/s。
出人意料的是，平臺指出緩存大小對 USB 棧的性能影響不大。一次實驗改變了主要緩存的參數(shù)，如大小、組合以及塊大小。雖然不同參數(shù)對整個應用程序的請求丟失有很大的差異，但對 CPU 占用率的影響不明顯。在這個仿真階段，用初始化的 CPU 時間（包括設備計數(shù)）減去運行應用程序的總 CPU 時間，得到 CPU 占用率。結果清楚地顯示，硬盤的讀、寫操作包括對指令內(nèi)存和數(shù)據(jù)內(nèi)存的正常訪問，即由于讀、寫操作在時間和空間上的高度本地化，對硬盤驅動的丟失的總次數(shù)近似為恒定，而與緩存參數(shù)的變化無關。
表2總結了不同緩存大小的結果。在所有情況下（組合為2，塊尺寸為16kB），指令緩存和數(shù)據(jù)緩存都是一樣的。表3顯示同為16kB、8kB緩存不同組合值的結果。表4則是組合為2，塊大小為8kB緩存的結果。
這些結果均假定有一個5ns的緩存命中等待時間，四個字訪問，每個字花費時間為160 ns。
緩存大小對CPU效率的影響很小，與此相反，EHCI 將數(shù)據(jù)移入、移出內(nèi)存的方式之間則有很大不同。拷貝語義學（copy-semantics）方法將數(shù)據(jù)從緩存區(qū)移到一個EHCI可訪問的非緩存區(qū)。非拷貝語義學（Noncopy semantics）則假設EHCI可以訪問包含所需數(shù)據(jù)的內(nèi)存區(qū)。在這種方法中，內(nèi)存區(qū)是未經(jīng)緩存的，傳給EHCI 的是一個指向內(nèi)存位置的直接指針。
這兩種機制的性能數(shù)字有著很大的差異，因為在非拷貝語義學情況下，不用將數(shù)據(jù)從一個內(nèi)存區(qū)拷貝到另一個內(nèi)存區(qū)，這就省去了所有的移動指令，當移動大量數(shù)據(jù)時極大地減輕了工作量。例如，當重復64次以 256kB傳送32MB數(shù)據(jù)時，虛擬平臺顯示的數(shù)據(jù)速率和CPU占用率，拷貝語義學方式分別為5051 kB/s和6%，而非拷貝語義學方式分別為7700kB/s和40%。
在評估棧大小的效果時，一般預測認為較小的棧會減少CPU占用，而虛擬平臺得到與直覺相反的結果（表5）。除CPU占用以外，表中顯示較大的棧還會增加一個應用程序執(zhí)行的指令數(shù)。
但是，修改堆的大小時結果保持不變。（堆是一個內(nèi)存區(qū)，應用軟件可以作直
雖然虛擬平臺得到了有希望的結果，但它仍與硬件的工作有不一致的地方。例如，ST20 處理器流量發(fā)生器的模型過于簡單。它假定每條指令的執(zhí)行階段都是一個恒定的平均時間，但事實并不總是這樣。此外，流量發(fā)生器建模時既無處理器流水線停頓也無任何流水線停頓的情況。不過，這些因素之間有些相互抵消，得到的結果還算準確。
現(xiàn)在的工作重點集中在建立更復雜平臺和開發(fā)無縫的方法上，用于評估任何軟件棧的性能。例如，正在進行的是虛擬平臺與Flexperf這種剖析工具相結合，使軟件編程人員和系統(tǒng)架構師有一個統(tǒng)一的方法，能夠評估并增強嵌入式代碼的性能。
評論