999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

軟硬件混合的高效CHI協議分析

2024-02-28 01:26:12趙祉喬荀長慶潘國騰鐵俊波王偉征
計算機工程與科學 2024年2期

趙祉喬,周 理,荀長慶,潘國騰,鐵俊波,王偉征

(1.長沙理工大學計算機與通信工程學院,湖南 長沙 410114;2.國防科技大學計算機學院,湖南 長沙 410073)

1 引言

從芯片設計到正式上市的整個階段中,片上系統SoC(System on Chip)的驗證是一項非常繁復的任務[1]。投入到SoC驗證的時間和精力,可以占據整個系統開發設計時間的60%甚至更多[1,2]。只有在硅前驗證階段有了足夠充分的驗證結果支持,才有信心進行流片。然而在系統級驗證階段,對于芯片功能、性能等方面的高效驗證手段有限。在功能驗證方面,查錯時使用抓取波形等常規調試方法往往難以定位具體出錯的模塊,且可能會消耗一個月甚至數月的時間,極大地影響了效率;而在性能分析方面,當SoC性能未達到預期設計指標時,很難根據有限的全系統性能數據定位具體性能瓶頸[3]。因此,在SoC開發過程中,如何高效準確地進行功能驗證與性能分析,是亟待解決的難題。

互聯總線處在系統的核心地帶,為了試圖解決這些問題,有研究提出從總線協議入手,通過片上網絡協議分析獲取更多芯片內部的狀態信息,提高芯片可觀察性[2],進而高效地對問題進行定位分析和處理。Synopsys公司、Cadence公司也相繼推出驗證IP VIP(Verification IP)[4,5]用于標準片上網絡協議CHI(Coherent Hub Interface)、AXI(Advanced eXtensible Interface)等的驗證,采用通用的驗證方法學UVM(Universal Verification Methodology)實現,具有良好的可重用性和可擴展性。然而,這些工具都是使用不可綜合的System Verilog語言,只適用于軟件仿真驗證,不適用于在FPGA原型平臺驗證。UltraSoC公司針對CHI總線、片上自定義總線開發了可綜合的VIP和對應軟件[6],完成了對多類總線的同時監測,并可通過 USB(Universal Serial Bus)或JTAG(Joint Test Action Group)導出。然而,其全部可綜合的實現方法在實際的使用中存在數據導出緩慢、對FPGA原型平臺的硬件資源占用較大等問題。

因此,針對硅前驗證階段的需求和現有研究的不足,本文設計了一種軟硬件混合的高效CHI協議分析方法,通過DPI(Directed Programming Interface)連接C代碼,實現了一種適用于FPGA原型平臺,且硬件資源占用少、可重用性高的系統級驗證方法,能夠在FPGA原型平臺上實現對CHI協議的高效監測和分析,有效加速SoC問題的定位和性能分析,提升設計與驗證的效率。

2 待測SoC及CHI協議

2.1 待測SoC

如圖1所示,待測SoC包含多個處理器核CORE、數據存儲單元DDR(Double Data Rate)和輸入輸出單元IOU(Input and Output Unit)等。其中,片上網絡基于mesh結構實現,處理器核的L2 Cache與片上網絡通過CHI協議互聯,是一款高性能眾核SoC。

Figure 1 Basic structure of the SoC under test圖1 待測SoC的基本結構

2.2 CHI協議

CHI協議[7]是目前廣泛采用的一種片上協議規范,從其運行情況可以了解通過片上網絡互聯的多個部件的運行狀態,有助于問題的定位及分析。

如圖2示,以讀數據為例,處理器核要從主存儲器中讀取一個數據。處理器核作為請求節點RN(Request Node)發出一個讀請求ReadNotSharedDirty給下一級的主節點ICN(InterConNect),主節點ICN接收到請求后在目錄中查找。如果有該緩存數據則返回CompData給處理器核,處理器核收到全部數據之后再返回一個CompACK作為收到的回復;如果主節點ICN中沒有該緩存數據,則繼續向下一級的從節點SN(Slave Node)發送讀請求ReadNoSNP。

Figure 2 Read transaction flow圖2 讀請求事務流程

在數據片(Data Flit)中存在多個ID字段用于標識網絡路由。如圖3所示,以讀請求事務為例,通過TgtID尋址到主節點ICN及從節點SN,通過SrcID就可以將響應返回到請求節點及主節點。事務號TxnID用來唯一標識同一對節點的不同事務流,返回節點號ReaturnNID及事務序號ReaturnTxnID用于標識返回數據的目標節點及事務號,主節點號HomeNID標識該事務的主節點,即為反饋報文的目標節點號TgtID,數據緩存區號DBID用于標識數據的存放位置。

Figure 3 ID field transform of ReadNotSharedDirty transaction flow圖3 ReadNotSharedDirty事務流的ID域變換

如圖4所示,在CHI協議中,由主請求通道TXREQ、從數據通道RXDAT、從反饋通道RXRSP、從監聽通道RXSNP、主反饋通道TXRSP、主數據通道TXDAT 6個通道進行信號傳輸,每一個通道由4個信號來完成。

Figure 4 Channel and signal of CHI protocol圖4 CHI協議的通道及信號

以圖2中的讀數據為例子,讀請求在請求通道中傳輸,REQFLITPEND信號為傳輸到來前的聲明,表示在下面幾個時鐘周期該通道會有報文傳輸,用于低功耗模式;REQFLITV信號標識當前數據片是否有效;REQFLIT信號為完整的數據片報文;REQLCRDV信號為信用信號,當其值為1時,返回一個信用給請求報文的發送方。

3 軟硬混合監測方法

本文方法由軟硬件協同實現,包含離線模式與在線模式,具體流程如圖5所示。

Figure 5 Flow chart of protocol analysis圖5 協議分析流程圖

該方法由數據傳輸模塊、數據片解碼組碼模塊、協議分析模塊協同完成。數據傳輸模塊用于捕捉待測SoC中的CHI報文,并將其從FPGA原型平臺通過DPI-C接口傳輸到工作站中。數據片解碼組碼模塊處理CHI協議中的數據片,將數據片按照數據傳輸模塊中的配置信息解碼,將解碼后的數據片結構體中的事務流控制變量組碼。協議分析模塊可完成事務流的追蹤、報文的正確性檢驗和報文類型的覆蓋率監測。具體結構如圖6所示。

Figure 6 Structure of collaborative monitoring unit圖6 協同監測單元結構

3.1 數據傳輸模塊

本文方法在FPGA原型平臺中利用DPI-C接口傳輸數據[8],可綜合的硬件部分對共享函數體進行聲明,軟件部分共享使用的函數體也由此定義。不可綜合的軟件部分對共享函數體進行實例化,用以捕捉待測SoC中通過CHI協議各個通道的報文。

如圖7所示,數據傳輸模塊中可綜合的軟件部分使用System Verilog語言實現,包括:存儲參數配置部件、共享函數體聲明部件和監測器狀態控制部件。不可綜合的軟件部分使用C++語言實現,包括:數據片參數配置模塊、監測器數據管理模塊和監測器模式控制模塊。

Figure 7 Structure of data transmission module圖7 數據傳輸模塊結構

存儲參數配置部件用于設置監測器的數據存儲方式,包含離線模式中輸出的數據包DAT和在線模式中輸出的日志文件LOG的輸出位置、針對該待測SoC中CHI協議的參數配置文件位置、被監測節點句柄索引。在SoC中可能存在多個CHI協議節點需要綁定監測單元,因此該方法在不可綜合部分采用句柄列表的方法管理各個節點的生成數據。每個節點由唯一的句柄索引標識其在表中的位置。

共享函數體聲明部件通過導入(import)的方式在可綜合的硬件部分中聲明硬件部分與軟件部分共享函數體。監測器數據管理模塊完成共享函數體的實例化,并將2.2節中所述的6個通道中的數據傳輸給軟件部分。共享函數體列表見表1。

為了盡可能降低數據傳輸代價,監測器狀態控制部件用于控制監測器的使能。當存在監測器使用需求時,將監測器的使能信號置高,調用CreateDb函數使監測器開始工作。之后通過Db-Write函數將數據從硬件部分傳輸至軟件部分。當沒有監測器使用需求時,在FPGA平臺將監測器的使能信號置低,停止通過DPI-C接口向工作站傳輸數據,使用CloseDb函數關閉文件,減少資源的占用。如果總線已經在工作,開啟監測時應當忽略監測初期事務流中缺失的請求通道和監聽通道報文及其相關報文,以防止誤判。

由于CHI協議標準中的部分字段存在可配置的情況,各個待測SoC中實現的CHI協議字段的定義存在不同,本文方法的數據片參數配置模塊使用參數輸入的方法讀入CHI協議的可配置參數字段。此外,通過配置節點的最大信用這一參數,可以修改支持的最大未完成請求數目。

本文提出的方法存在2種模式,通過宏定義的方法選擇離線或在線模式。如表2所示為離線模式與在線模式的對比,離線模式下對CHI報文不進行檢驗直接輸出;在線模式下對CHI報文進行解碼、組碼以及指定的協議分析處理后再輸出監測結果。離線模式的輸出數據如圖8所示。

Table 2 Comparison between offline mode and online mode

Figure 8 Data format of offline mode output圖8 離線模式輸出的數據格式

3.2 數據片解碼組碼模塊

數據傳輸模塊捕捉到的是CHI協議中的數據片。數據片解碼組碼模塊對6種通道的數據片分別進行字段的解碼,對其中事務流相關字段進行組碼。

解碼模塊按照配置的字段格式,將完整數據片通過移位和與或操作分解為各個字段信息,將解碼后的字段信息存儲在請求報文、監聽報文、反饋報文、數據報文4種結構體中。在解碼過程中為每一條事務流生成唯一的標識碼,用于定位單個事務流。

組碼模塊將數據片結構體中的數據解析為事務流控制變量。事務流控制變量具體包含是否為無數據類型報文、是否為可監聽類型報文、是否為原子類型報文、是否為緩存狀態設置相關報文、是否為DVM(Distributed Virtual Memory)類型報文等變量,這些變量按照操作碼字段的含義賦值。

3.3 協議分析模塊

協議分析模塊是本文方法的核心模塊,主要負責對協議的解析與正確性檢驗。如圖9所示,協議分析模塊包含事務流追蹤模塊、報文檢驗模塊、問題反饋模塊、覆蓋率監測模塊。

Figure 9 Schematic diagram of protocol analysis module圖9 協議分析模塊結構示意圖

事務流追蹤模塊按照時間順序依次讀取數據包中6個通道的報文,使用等待響應的事務表存儲未完成的事務,在事務表內通過目標節點號、事務號對事務進行追蹤。通過參數配置該SoC中支持的最大待完成請求數目,進而實現6種通道數據事務流的追蹤及基礎檢驗。具體流程如圖10所示。

報文檢驗模塊用于檢驗6種通道中報文的正確性,包含通道信用計數檢驗、報文字段檢驗、事務流的正確性檢驗等。通過對Opcode、AllowRetry、ExpCompAck和Order字段進行監測,實現多種不同類型的事務流程判定。當監測到問題發生時,通過問題反饋模塊上報錯誤,并將問題發生的事務流完整信息和基本錯誤提示輸出在監測日志中,根據用戶設置可以選擇停止或繼續仿真。具體流程如圖11所示。

Figure 11 Flow chart of packet verification module圖11 報文檢驗模塊流程圖

覆蓋率監測模塊,用于監測請求通道和監聽通道中的報文,統計CHI協議中的請求報文和監測報文中有多少報文類型已經被執行過。并使用計數記錄每種報文類型發生的次數。當監測到對應報文時,計數加1。監測完成時,輸出各個通道中各報文類型的發生次數、覆蓋率等統計信息。如表3所示為輸出的覆蓋率統計結果。

Table 3 Coverage statistics results and their explanations

4 實驗及結果分析

4.1 實驗設置

本文實驗基于FPGA原型平臺在Linux操作系統下實現,使用2.1節中所述基于4×4 Mesh實現待測SoC。監測單元與待測SoC的綁定方法如圖6所示。分別在單核、四核環境中設置綁定1個監測單元和4個監測單元的實驗進行測試。節點最大未完成事務數目設為16。

4.2 實驗輸出結果

離線模式下向工作站中輸出數據文件DAT,之后在工作站端對其進行解析,生成監測日志及覆蓋率統計結果。在線模式下向工作站輸出監測日志LOG,包含錯誤提示信息和錯誤發生報文完整事務流信息。如圖12所示為一次實驗的結果展示,其中圖12a為離線輸出數據DAT;圖12b為在線輸出監測日志LOG;圖12c為覆蓋率統計結果。

Figure 12 Display of experimental results圖12 實驗結果展示

4.3 在線模式與離線模式對比

如表4所示為單核環境中正常工作情況下離線模式與在線模式輸出數據大小對比。實驗結果表明,在正常工作狀態下在線模式不存在輸出數據,沒有存儲資源被占用。離線模式下輸出數據的大小隨仿真周期的延長線性增大,對資源占用較大。

Table 4 Size comparison of output data between offline mode and online mode

如表5所示為使用本文提出的監測器前后FPGA資源的占用情況對比。

Table 5 Comparison of FPGA resource usage before and after using monitor

本文監測器框架在硬件側只需要增加對協議信號進行傳輸的邏輯,而復雜的協議正確性檢查邏輯在軟件側得到了實現,因此軟硬件混合的監測單元對FPGA原型平臺的硬件占用僅占0.01%,在實際應用中可以忽略不記。

如表6和表7所示,分別為單核(單核 DDR4G 初始仿真頻率為1 380 KHz)、四核(四核 DDR16G 初始仿真頻率1 309 KHz)的環境中離線模式與在線模式下對于npb-omp[9]測試題目的實驗結果。

Table 6 Results of offline mode and online mode under single-core environment

Table 7 Results of offline mode and online mode under four-core environment

對于單核環境,監測單元的離線模式對仿真時間沒有影響,在線模式的仿真時間平均變長了1.13倍。對于四核環境,離線模式的仿真時間平均變長了1.03倍,在線模式的仿真時間平均變長了1.25倍。其中,對仿真時間沒有影響的離線模式實驗組占總離線模式實驗組的95.46%,對仿真時間沒有影響的在線模式實驗組占總在線模式實驗組的54.55%,最長的仿真時間變長了1.83倍。

實驗結果表明,離線模式對于仿真速率影響不大,在線模式對仿真速率的影響也在可接受范圍內,該監測方法可以達到對CHI協議監測不影響整體仿真速率的目的。

5 結束語

本文設計了一種軟硬混合的高效CHI協議分析方法,用于對CHI總線上的信號進行高效地監測與分析。該方法可以在多核SoC的原型系統平臺中使用,離線模式對仿真速率影響不大,在線模式對存儲資源占用較少、可重用性高,其DPI接口可以擴展,以對AXI等協議進行監測,應用于SoC的驗證過程可以加快問題出錯點的定位過程,具有一定的應用價值。

主站蜘蛛池模板: 久久99蜜桃精品久久久久小说| 日韩av电影一区二区三区四区| 国产福利免费在线观看| 成人午夜天| 中文成人在线视频| 草逼视频国产| 国产九九精品视频| 欧美性精品| 亚洲第一成年人网站| 午夜国产精品视频黄| 亚洲欧洲日产国产无码AV| 91福利一区二区三区| 欧美性天天| 国产地址二永久伊甸园| 四虎在线观看视频高清无码| 在线精品亚洲国产| 色综合成人| 爆乳熟妇一区二区三区| 五月丁香在线视频| 99re这里只有国产中文精品国产精品 | 午夜三级在线| 欧美精品在线观看视频| 99热这里只有精品2| 国产精品无码一二三视频| 亚洲高清中文字幕在线看不卡| 久久国产成人精品国产成人亚洲 | 国产午夜人做人免费视频| 综合色亚洲| 欧美视频免费一区二区三区| 色悠久久久| 欧美亚洲激情| 久草网视频在线| 久久亚洲国产一区二区| 欧美69视频在线| 无遮挡国产高潮视频免费观看| 成人国产一区二区三区| 99久久精品免费看国产电影| 九九香蕉视频| 毛片网站在线看| 99视频在线免费看| 毛片最新网址| 国产91小视频在线观看 | 中文成人在线| 一本综合久久| 四虎国产精品永久在线网址| 精品国产Ⅴ无码大片在线观看81| 国产一区成人| 67194亚洲无码| 国产毛片片精品天天看视频| 亚洲精品波多野结衣| 久久精品中文无码资源站| 91久久偷偷做嫩草影院| 国产美女免费| 亚洲一区二区视频在线观看| 亚洲国产91人成在线| 国产主播在线一区| jizz国产视频| 久久精品国产电影| 国产成人综合亚洲网址| 国内精品视频| 久久综合丝袜长腿丝袜| 国产在线小视频| 国产尹人香蕉综合在线电影| 岛国精品一区免费视频在线观看 | 日韩 欧美 国产 精品 综合| 秋霞国产在线| 黄色网页在线播放| 国产第一色| 99视频全部免费| 黄色网在线免费观看| 国产成人高清在线精品| 国产男人的天堂| 国产婬乱a一级毛片多女| 久久久国产精品免费视频| 国产香蕉在线| 国产乱子伦一区二区=| 中文字幕久久亚洲一区 | 亚洲精品国产精品乱码不卞| 国产XXXX做受性欧美88| 中文字幕2区| a免费毛片在线播放| 欧美一区二区人人喊爽|