一、軟件平臺與硬件平臺

軟件平臺：

操作系統：Windows 8.1 64-bit

開發套件：Vivado2015.4.2

硬件平臺：

評估板：ZYNQ-7 ZC706 Evaluation Board

二、介紹

上篇文章的最后一小節已經對例子工程進行仿真并通過命令 log_wave –r /* 記錄了所有信號的波形，這篇文章主要介紹RapidIO核的仿真以及包時序的分析。

調試SRIO核時必須對包在不同接口的傳輸過程有一個清晰的了解，能夠識別出不同接口上包的類型并正確的解析出包的內容。

本文詳細的介紹了SRIO包（控制符號與數據字符）在不同接口上的組成與傳輸過程，并深入到邏輯層、傳輸層以及物理層來觀察RapidIO串行物理層包的傳輸細節。整個包與信號分析的過程完全基于RapidIO提供的例子工程，例子工程的產生與源代碼的分析已經在上一篇文章《Xilinx RapidIO核例子工程源碼分析》（鏈接：https://www.cnblogs.com/liujinggang/p/10091216.html）提到過，這里不再贅述。最后，本文會利用RapidIO核做一個回環測試（Loopback Test）的工程在ZC706上運行，由于RapidIO是一個付費的IP核，所以生成bit文件需要License，沒有License的可以在官網（https://www.xilinx.com/products/intellectual-property/ef-di-srio-gen2.html#overview）申請一個30天的評估版License試用，評估版的License生成的bit文件運行一段時間以后會自動失效，要想永久使用必須購買官方的License。

三、例子工程結構

下圖整個例子工程的結構層次

它由一個仿真頂層的testbench和兩個SRIO核頂層組成。其中頂層的testbench文件srio_sim.v連接了兩個srio例子設計頂層，其中一個例子設計頂層叫做srio_example_top_primary，它代表請求方的RapidIO設備；另一個例子設計頂層叫做srio_example_top_mirror，它代表響應方的RapidIO設備。

SRIO例子工程頂層文件srio_example_top.v例化了SRIO核的所有組件以及需要在硬件上執行的必要模塊。這些模塊包括：

1、時鐘域復位模塊（srio_clk.v和srio_rst.v）

2、配置結構（cfg_fabric.v）

3、請求事務與響應事務生成模塊（srio_resquest_gen.v和srio_response_gen.v）

4、維護事務生成模塊（srio_quick_start.v）

頂層模塊srio_example_top中例化了srio_quick_start模塊，它與SRIO的維護端口相連，用來生成維護事務（Maintenance Transactions）。這個模塊用來向本地（Local）或遠程（Remote）的配置寄存器空間發送一組固定的指令集，用戶可以編輯maintenance_list.v來添加、修改或移除維護事務。

srio_request_gen在頂層模塊srio_example_top進行例化，它用來產生I/O事務或消息（MESSAGE）事務，但僅僅SRIO核支持的事務類型能被產生，這個模塊也存儲了期望的響應事務并與實際接收到的響應事務進行對比用來確定整個事務交互過程的正確性。

srio_response_gen也在頂層模塊srio_example_top進行例化，它用來產生請求事務對應的響應事務。

整個例子工程結構層次的軟件框架如下圖所示，其中左邊的srio_example_top模塊表示請求方的RapidIO設備，而右邊的DUT Mirror表示響應方的RapidIO設備，它們的內部結構完全相同，區別僅僅在于一個作為請求方而另一個為響應方。

SRIO核的原理框圖以及接口如下圖所示

為了方便說明，上圖每一個接口都用相應的數字標注出來。它們分別為

Initiator/Target IO Port（接口1）

例子工程中SRIO核全部為默認參數，所以端口類型默認被配置為Initiator/Target，在Initiator/Target接口類型中請求事務與響應事務在不同的AXI4-Stream通道上進行傳輸。SRIO核的端口類型也能被配置為Condensed I/O類型，在Condensed I/O接口類型中請求事務與響應事務在同一AXI4-Stream通道上進行傳輸，所以Condensed I/O相比于Initiator/Target類型來說接口更加精簡。本文仍然采用默認的Initiator/Target接口類型來分析每個包的傳輸過程。

接口1的數據傳輸協議為AXI4-Stream協議，它的接口定義如下：

s_axis_ireq_* 表示Initiator請求事務的傳輸通道（i = initiator ,req = request）

m_axis_iresp_* 表示Initiator響應事務的傳輸通道（i = initiator ,resp = response）

m_axis_treq_* 表示Target請求事務的傳輸通道（t = target ,req = request）

s_axis_iresp_* 表示Target響應事務的傳輸通道（t = target , resp = response）

Maintenance Port（接口2）

接口2的數據傳輸協議為AXI4-Lite協議，用來傳輸維護事務。它的接口定義如下：

s_axi_maintr_* 表示維護事務的傳輸端口（maintr = maintenance）

LOG Configuration Fabric（接口3）

接口3的數據傳輸協議為AXI4-Lite協議，它是邏輯層的配置結構端口，包括本地（Local）配置端口和遠程（Remote）配置端口。它的接口定義如下：

s_axi_cfgl_* 表示本地配置端口（cfg = configuration，l = local）

m_axi_cfgr_* 表示遠程配置端口（cfg = configuration，r = remote）

LOG Transport Interface（接口4）

接口4的數據傳輸協議為AXI4-Stream協議，它是邏輯層與Buffer的數據傳輸接口，包括發送和接收兩個通道。它的接口定義如下：

m_axis_buft_* 表示發送端口（buf = buffer，t = transmit）

s_axis_ bufr_* 表示接收端口（buf = buffer，r = receive）

BUF Link Interface（接口5）

接口5的數據傳輸協議為AXI4-Stream協議，它是Buffer層與物理層的數據傳輸接口，包括發送和接收兩個通道。它的接口定義如下：

m_axis_phyt_* 表示發送端口（phy= physical，t = transmit）

s_axis_ phyr_* 表示接收端口（phy = physical，r = receive）

BUF Configuration Fabric（接口6）

接口6的數據傳輸協議為AXI4-Lite協議，它是Buffer層的配置端口。它的接口定義如下：

s_axi_bcfg_* 表示Buffer層配置端口（b = buffer，cfg = configuration）

PHY Serial Interface（接口7）

接口7為物理層串行鏈路接口，它是物理層數據與串行收發器（Serial Transceivers）數據交換通道，它的接口定義如下所示：

信號	方向	功能
gttx_data[32*LW-1 : 0]	Output	發送給串行收發器（Serial Transceivers）的數據
gttx_charisk[4*LW-1 : 0]	Output	gttx_data信號中有效字節指示信號。當這個信號某一位為0時，gttx_data中對應的字節為包的有效字節。
gttx_inhibit[LW-1:0]	Output	串行收發器的通道使能位。如果最低位（bit-0）為1，表示發送通道0（Lane0）不使能，其余依次類推
gtrx_data[32*LW-1:0]	Input	從串行收發器（Serial Transceivers）接收的數據
gtrx_charisk[4*LW-1:0]	Input	gtrx_data信號中有效字節指示信號。當這個信號某一位為0時，gttx_data中對應的字節為包的有效字節。
gtrx_chariscomma[4*LW-1:0]	Input	gtrx_data信號中comma指示信號。如果最低位（bit-0）為1，表示gtrx_data[7:0]是包含comma的字符，其余依次類推
gtrx_disperr[4*LW-1:0]	Input	gtrx_data信號中不一致錯誤（Disparity Error）指示信號。如果最低位（bit-0）為1，表示gtrx_data[7:0]中存在不一致錯誤，其余依次類推
gtrx_notintable[4*LW-1:0]	Input	gtrx_data信號中not-in-table錯誤指示信號。Table指的是8b/10b編碼解碼表。如果最低位（bit-0）為1，表示gtrx_data[7:0]中8b/10b解碼錯誤，其余依次類推
gtrx_chanbondseq[LW-1:0]	Input	串行收發器每個鏈路的通道綁定序列（Channel Bonding Sequence）指示信號，如果最低位（bit-0）為1，表示鏈路0（Lane0）收到了一串通道綁定序列，其余依次類推
gtrx_chanisaligned[LW-1:0]	Input	串行收發器每個鏈路的通道對齊（Channel Alignment）指示信號，如果最低位（bit-0）為1，表示鏈路0（Lane0）已經實現了通道對齊，其余依次類推
gtrx_chanbonden	Output	串行收發器通道綁定使能信號
gtrx_reset_req	Input	串行請求復位信號。例如，由于串行收發器接收通路彈性FIFO的上溢（overflow）或下溢（underflow），
gtrx_reset	Output	串行收發器的復位信號
gtrx_reset_done[LW-1:0]	Input	串行收發器每個鏈路的復位完成指示信號，如果最低位（bit-0）為1，表示鏈路0（Lane0）已經復位完成，其余依次類推

PHY Configuration Fabric（接口8）

接口8的數據傳輸協議為AXI4-Lite協議，它是物理層（Physical）的配置端口。它的接口定義如下：

s_axi_cfgp_* 表示物理層配置端口（cfg = configuration，p = physical）

Transceiver Interface（接口9）

接口9為串行收發器高速數據傳輸接口，每條串行數據傳輸線均為一對差分信號。它的接口定義如下：

srio_rxpN ，srio_rxnN：N為通道號，接收鏈路差分對，N的值為1、2或4。

srio_txpN ，srio_txnN：N為通道號，發送鏈路差分對，N的值為1、2或4。

四、SRIO核包時序分析

上篇文章《Xilinx RapidIO核例子工程源碼分析》（鏈接：https://www.cnblogs.com/liujinggang/p/10091216.html）的最后一小節已經詳細介紹了仿真的全部流程以及利用log_wave –r /*命令記錄所有信號波形的方法，這里不再贅述。這一節默認大家已經仿真完畢（仿真結束大約需要20min左右時間，仿真完畢記得保存波形），并得到了仿真的波形，下面就對其中重要的波形進行分析。

在分析之前，在重新回顧一下RapidIO串行物理層的包與控制符號的格式

串行物理層的包：

控制符號：

4.1 鏈路初始化與控制符號

調試SRIO的第一步是去檢測SRIO頂層模塊（srio_example_top_primary）中的各個關鍵的控制信號是否正確切換。這些信號包括：復位信號、時鐘鎖定信號（clk_lock）、端口初始化信號（port_initialized）、鏈路初始化信號（link_initialized），端口錯誤信號（port_error），mode_1x信號（在2x和4x模式下，這個信號為高表示SRIO核已經被訓練為1x模式，在1x模式下，這個信號一直為高，當port_initialized為高時，這個信號才有效）與端口解碼錯誤信號（port_decode_error）等（除了這幾個信號以外，其他信號也可以觀察一下）。

Step1、把srio_example_top_primary中的所有信號全部選中，然后直接拖到右邊的波形窗口

Step2、找到上面提到的幾個關鍵控制信號，觀察它們的波形

由上圖可以看出，控制信號的波形均切換正確，其中最關鍵的兩個信號是port_initialized信號與link_initialized信號，當它們為高時，分別表示端口和鏈路被成功初始化。

下圖是時鐘信號和復位信號的時序細節，顯然，時鐘信號與復位信號的時序均正確。

Step3、pg007_srio_gen2.pdf第119頁提到，當7個連續的error free控制符號被接收，并且15個連續的符號被發送的時候，link_initialized信號才被拉高，所以接下來看看link_initialized信號拉高之前物理層是否接收了7個控制符號并發送了15個控制符號。

首先選中最左邊的srio_gen2_0_block_inst，然后把中間列出的以gt開頭的接口7的所有信號拖到最右邊的波形窗口中，如下圖所示

在link_initialized拉高之前，觀察gttx_data，gttx_charisk與gtrx_data，gtrx_charisk總線上的數據，建議把gttx_charisk與gtrx_charisk用二進制顯示，當gttx_charisk與gtrx_charisk對應的位為0時，表明gttx_data與gtrx_data上的數據為有效數據（控制符號與包屬于有效數據）。當gttx_charisk與gtrx_charisk對應的位為1時，gttx_data與gtrx_data上的數據為空閑序列。如下圖所示，當link_initialized拉高之前gttx_data上發送了15個連續的控制符號，gtrx_data上接收了7個連續的控制符號。

下面把控制符號波形放大觀察控制符號各個字段的細節,發送與接收總線上的控制符號分別如下圖所示（gttx_charisk與gtrx_charisk對應的位為0時, gttx_data與gtrx_data上的數據為控制符號）

上圖表明在link_initialized拉高之前，發送與接收的控制符號為80f713，控制符號80f713前面的1c是/K28.0/，表示控制符號的起始位置。由于SRIO核默認使用的是短控制符號，所以這里控制符號為24-bit。

把80f713轉化為二進制：80f713 = 1000_0000_1111_0111_0001_0011，各個字段的對應關系如下圖所示

當gttx_charisk與gtrx_charisk對應的位為1時，gttx_data與gtrx_data上的數據為/K/，/R/，/A/組成的空閑隨機序列（前面幾篇文章解釋過這個知識點），它們分別為特殊字符/K28.5/，/K29.7/，/K27.7/，轉化為16進制為bc，fd，fb，下圖是它們的波形

整個初始化的過程著重需要關注的兩個信號就是port_initialized和link_initialized，如果初始化失敗（port_initialized和link_initialized沒有被拉高），那么首先必須檢查gttx_data與gtrx_data上是否收到了空閑序列/K28.5/，/K29.7/，/K27.7/，同時需要檢查是否存在編解碼錯誤，編解碼錯誤的判斷標志是gtrx_notintable信號，當它為1時表明存在編解碼錯誤。

4.2 SWRITE事務

上篇文章已經分析過，例子工程會把instruction_list.vh中定義的事務按順序依次發出去。其中最先發送的是37個SWRITE事務，然后是19個NWRITE_R事務、 19個NWRITE事務、26個NREAD事務，2個DOORBELL事務，最后是17個MESSAGE事務。其中第一個發送的事務是instruction_list.vh中第50行定義的SWRITE事務。如下圖所示

下面以上圖第50行的SWRITE事務為例來說明整個SWRITE事務的傳輸過程。這個事務表示的是利用SWRITE事務往地址36’hCD0000600發送16個字節的數據。

Step1、選中srio_example_top_primary，把中間列出的所有信號全部拖到波形窗口中（拖到波形窗口前可以把之前波形窗口中的信號全部刪掉）

Step2、找到請求事務的傳輸通道ireq，并抓出事務的波形如下圖所示

由于僅當tvalid和tready同時為高時，tdata上的數據才為有效數據，所以這個SWRITE一共消耗了三個有效時鐘周期，其中第一個時鐘周期發送的是HELLO包頭，后面兩個時鐘周期分別發送8個字節的數據（第一個時鐘發送的數據是0000000000000000，第二個時鐘發送的數據是0101010101010101），一共16個字節的數據，和instruction_list.vh中第50行定義完全一致，整個時序也與HELLO格式的時序完全吻合。

Step3、對照HELLO格式解析包頭。包頭為006020fcd0000600，轉化為二進制后與HELLO格式各個字段對應關系如下所示：

由上圖可知FTYPE字段的值為6，表明確實是一個SWRITE事務

Step4、SWRITE事務通道ireq通道（接口1）傳輸給SRIO核以后進入SRIO的邏輯層，邏輯層會給包添加傳輸層的信息發送給Buffer（接口3），然后Buffer會把數據發送給物理層（接口5）。

選中srio_gen2_0_block_inst，把中間的buft_*通道、phyt_*通道與gttx_*通道的信號拖到右邊的波形窗口中，如下圖所示

整個從邏輯層到傳輸層到物理層到吉比特收發器（Gigabit Transceiver）的波形如下圖所示，波形的細節這里不再展開，大家可以自己抓出來觀察。

Step5、ireq通道的SWRITE請求事務經過邏輯層，傳輸層和物理層到達吉比特收發器（Gigabit Transceiver），吉比特收發器的數據通道gttx_data[31:0]（接口7）波形如下圖所示

由上圖可知，整個串行物理層的包為：7c96f004_b04600ad_d0000600_00000000_00000000_01010101_01010101_e8d30000_7c96f203。（00000000和01010101的寬度為兩個有效時鐘）這個包的含義如下：

7c96f004中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），96f004轉化為二進制為：

96f004 = 1001_0110_1111_0000_0000_0100

它是一個包起始控制符號，各個字段的對應關系如下圖所示

b04600ad_d0000600_00000000_00000000_01010101_01010101_e8d30000是SWRITE事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

上圖中data字段是傳輸的00000000_00000000_01010101_01010101這16個字節數據的二進制碼，因為它的二進制碼太長了所以我直接用data替代。由于本次傳輸的字節小于80個字節，所以SWRITE事務的最后面的三個字段不存在，大家可以抓一下數據量為256個字節的SWRITE包，當數據量大于了80字節，后面的三個字段也會有數據。

包最后面的7c96f203中7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），96f203轉化為二進制為：

96f203= 1001_0110_1111_0010_0000_0011

它是一個包結束控制符號，各個字段的對應關系如下圖所示

至此，SWRITE事務全部分析完畢。

4.3 NWRITE_R事務

本小節以instruction_list.vh中第72行定義的NWRITE_R事務為例來說明整個NWRITE_R事務的傳輸過程。如下圖所示，這個事務表示的是利用NWRITE_R事務往地址36’ h004550002發送6（size+1）個字節的數據。

Step1、為了方便快速的找到上圖的NWRITE_R事務，建議選中srio_request_gen模塊，并把request_address變量拖到波形窗口中，并把這個變量用Unsigned Decimal（無符號10進制）格式顯示。看過上篇《Xilinx RapidIO核例子工程源碼分析》文章的應該知道這個變量是instruction的索引值，當這個變量為37的時候就表示37（0~36）個SWRITE事務全部發送完畢，下個事務就是instruction_list.vh中第72行定義的NWRITE_R事務。

Step2、鎖定request_address為37的位置，找到請求事務的傳輸通道ireq，并觀察事務的波形如下圖所示

由上圖可知第一個有效時鐘傳輸的HELLO格式包頭數據為：2555205004550002。發送的數據是afafafafafafafaf。包頭與HELLO包格式的對應關系如下圖所示

由上圖可知FTYPE = 5，TTYPE = 5，這兩個字段唯一的確定了這是一個NWRITE_R事務。

Step3、ireq通道的NWRITE_R請求事務經過邏輯層，傳輸層和物理層到達吉比特收發器（Gigabit Transceiver），吉比特收發器的數據通道gttx_data[31:0]（接口7）波形如下圖所示

由上圖可知，整個串行物理層的包為：7c98f009_d84500ad_59250455_0000afaf_afafafaf_afafad15_7c17f21e。這個包的含義如下：

7c98f009中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），98f009轉化為二進制為：

98f009= 1001_1000_1111_0000_0000_1001

它是一個包起始控制符號，各個字段的對應關系如下圖所示

d84500ad_59250455_0000afaf_afafafaf_afafad15是NWRITE_R事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

上圖中data字段是傳輸的afafafaf_afafafaf這16個字節數據的二進制碼，因為它的二進制碼太長了所以我直接用data替代。由于本次傳輸的總字節數為8字節的整數倍，所以NWRITE_R事務的后面可選的logical 0 pad（opt）沒有數據。

細心的人在這里可能發現了一個奇怪的現象：在HELLO格式中，address字段為36’ h004550002，其中高兩位為保留位，所以address一共只有34-bit有效位，size字段為5，表示往36’ h004550002地址中寫6（size+1）個字節的數據。但是上面串行物理層的包中address字段的值為0000_0100_0101_0101_0000_0000_0000_0，發送的數據個數為8個字節（afafafaf_afafafaf）。出現這種現象的原因為：

HELLO格式address字段指向的存儲空間的最小單元是1個字節，而串行物理層中的address字段指向的存儲空間最小單元實際上是8個字節，address后面的xambsb字段是串行物理層的最高兩位地址擴展字段，所以串行物理層的包可訪問的存儲空間大小為2^34=16G，這也是HELLO格式中address字段位寬為34-bit的原因（關于這部分的內容我在《RapidIO協議概述》也提到過）。正因為HELLO格式address字段與串行物理層address字段所指向的存儲空間最小單元不同，所以pg007_srio_gen2.pdf中第78頁才給出了一個HELLO格式size，addr與有效字節的對應關系表，如下所示

本例中size=5，addr[2:0] = 2，對應于上圖中紅框圈出來的情況。所以往36’ h004550002地址中寫6（size+1）個字節的數據對串行物理層來說就是往36’ h004550000地址中寫8個字節的數據，高6個字節（上圖中灰色區域）為有效數據。

包最后面的7c17f21e中7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），17f21e轉化為二進制為：

17f21e = 0001_0111_1111_0010_0001_1110

它是一個包結束控制符號，各個字段的對應關系如下圖所示

Step4、例子工程中例化了srio_example_top_primary與srio_example_top_mirror兩個實體，srio_example_top_primary實體的srio_txp0和srio_txn0連接到srio_example_top_mirror實體的srio_rxp0和srio_rxn0。因此，srio_example_top_mirror的gtrx_data上的數據應該和上一步分析的srio_example_top_primary實體的gttx_data完全相同。

選中srio_example_top_mirror的srio_gen2_0_block_inst,把gtrx_data與gtrx_charisk兩個信號拖到右邊的窗口中，如下圖所示

觀察srio_example_top_primary的gttx_data與srio_example_top_mirror的gtrx_data，如下圖所示，可以看到兩者完全相同，僅僅存在一個延時。

Step5、srio_example_top_mirror模塊的grrx_data接收到數據以后，將會把grrx_data的數據按照與發送過程完全相反的操作傳到邏輯層，最終邏輯層的數據將會通過srio_example_top_mirror模塊的treq接口輸出。

選中srio_example_top_mirror，把treq通道的所有信號拖到右邊的波形窗口中

下圖是srio_example_top_mirror模塊treq通道的波形

可知treq通道的包頭數據為2555205004550002，與srio_example_top_primary模塊ireq通道發送的包頭數據完全一樣。這也證明整個鏈路工作正常。

4.4 NWRITE_R的響應事務

由于NWRITE_R事務是一個有響應的寫事務，所以當發起方（Initiator）往目標方（Target）發送一個NWRITE_R事務以后，發起方（Initiator）還要接收目標方（Target）的發回響應事務。響應包的數據會出現在srio_example_top_primary模塊的tresp通道，下圖是srio_example_top_primary模塊的tresp通道的時序圖

由上圖可知iresp_tdata的數據為：25d0400000000000。與HELLO包格式的對應關系如下圖所示

由上圖可知FTYPE = 13，所以這是一個響應事務，prio字段變成了2，而NWRITE_R字段的prio字段為1，這是因為響應事務的prio為請求事務的prio+1,（這個知識點前兩篇文章都提到過）

事實上，響應事務的一整套傳輸流程為：目標方（Target）發回的響應事務被srio_example_top_primary模塊的串行差分信號線接收到達Serial Transceivers，Serial Transceivers在把接收的數據通過gtrx_data通道（接口7）傳到物理層，物理層把接收的包經過處理以后通過phyr_*通道（接口5）把數據發給Buffer層，Buffer層對數據進行二次處理以后把數據通過bufr_*通道（接口4）傳給邏輯層，邏輯層再把數據傳輸給I/O端口（接口1），這樣就得到了上圖HELLO格式的響應包。大家可以把gtrx_data、phyr_*通道、bufr_*通道和I/O端口的波形全部抓出來觀察一下，方法和上節介紹發送流程的抓取過程完全一樣。這里我只抓一下gtrx_data通道的數據，并分析響應事務串行物理層包格式各個字段的含義。

gtrx_data通道的數據如下圖所示

由上圖可知，整個響應事務串行物理層的包為：7c83f00f_388dadad_00255540_7c83f208

7c83f00f中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），83f00f轉化為二進制為：

83f00f = 1000_0011_1111_0000_0000_1111

它是一個包起始控制符號，各個字段的對應關系如下圖所示

388dadad_00255540是NWRITE_R響應事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

由于NWRITE_R的響應事務不帶數據，所以沒有data字段。target TID字段的值為16進制的25，也就是10進制的37，與發送的NWRITE_R請求事務target TID值完全相同。FTPYE字段的值為13，說明這是一個響應事務，整個響應事務的包正是NWRITE_R事務的響應包。

7c83f208中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），83f208轉化為二進制為：

83f208= 1000_0011_1111_0010_0000_1000

它是一個包結束控制符號，各個字段的對應關系如下圖所示

4.5 NWRITE事務

本小節以instruction_list.vh中第94行定義的NWRITE事務為例來說明整個NWRITE事務的傳輸過程。如下圖所示，這個事務表示的是利用NWRITE事務往地址36’ hDE0000600發送16（size+1）個字節的數據。

Step1、為了方便快速的找到上圖的NWRITE事務，建議選中srio_request_gen模塊，并把request_address變量拖到波形窗口中，并把這個變量用Unsigned Decimal（無符號10進制）格式顯示。看過上篇《Xilinx RapidIO核例子工程源碼分析》文章的應該知道這個變量是instruction的索引值，當這個變量為56的時候就表示37（0~36）個SWRITE事務全部發送完畢，19個NWRITE_R事務也全部發送完畢，下個事務就是instruction_list.vh中第94行定義的NWRITE事務。鎖定request_address為56的位置，找到請求事務的傳輸通道ireq，并觀察事務的波形如下圖所示

由上圖可知第一個有效時鐘傳輸的HELLO格式包頭數據為：385420fde0000600。后兩個有效時鐘發送的數據分別是c2c2c2c2c2c2c2c2和c3c3c3c3c3c3c3c3。包頭與HELLO包格式的對應關系如下圖所示

由上圖可知FTYPE = 5，TTYPE = 4，這兩個字段唯一的確定了這是一個NWRITE_R事務。srcTID的值為16進制的38，也就是10進制的56，與request_address的值相等，因為代碼里面就是直接把request_address的值賦給了srcTID。

Step2、ireq通道的NWRITE請求事務經過邏輯層，傳輸層和物理層到達吉比特收發器（Gigabit Transceiver），吉比特收發器的數據通道gttx_data[31:0]（接口7）波形如下圖所示

由上圖可知，NWRITE串行物理層包的數據為：

7c93f010_c84500ad_4b38e000_0605c2c2_c2c2c2c2_c2c2c3c3_c3c3c3c3_c3c362a2_7c13f20e。包的各個字段解釋如下：

7c93f010中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），93f010轉化為二進制為：

93f010= 1001_0011_1111_0000_0001_0000

它是一個包起始控制符號，各個字段的對應關系如下圖所示

c84500ad_4b38e000_0605c2c2_c2c2c2c2_c2c2c3c3_c3c3c3c3_c3c362a2是NWRITE事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

細心的同學馬上會發現wrsize字段的值居然為11（2進制1011，16進制b），address字段的值為e000_0600。而instruction_list.vh中第94行定義的size字段的值為15，address字段的值為36’hDE0000600。似乎邏輯層的包到達物理層以后size字段和address兩個字段都出現了錯誤。出現這種現象的原因如下：

前面幾篇文章也多次提到過，address后面的兩個字段wdptr和xamsbs兩個字段是有作用的，xamsbs字段是地址字段的高兩位擴展位。由于HELLO格式address字段的有效位數是34-bit，所以在當address字段的值為36’hDE0000600，有效的address字段的值為34’h 1E0000600，當我們把串行物理層xamsbs字段的01拼接在串行物理層address字段前面得到的地址就和先前定義的地址是一致的了。

至于wrsize字段的值為11，這是因為后面的wdptr字段的值變成了1，RapidIO_Rev_2.2_Specification的第35頁表4-4已經列出了所有wrsize與wdptr字段的組合，當wdptr=1，wrsize=11是，字節的總個數是16，這也和我們之前在instruction_list.vh中的定義是一致的。

7c13f201中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），13f201轉化為二進制為：

13f201= 0001_0011_1111_0010_0000_0001

它是一個包結束控制符號，各個字段的對應關系如下圖所示

4.6 NREAD事務

本小節以instruction_list.vh中第120行定義的NREAD事務為例來說明整個NREAD事務的傳輸過程。如下圖所示，這個事務表示的是利用NREAD事務往地址36’ h0000023F0發送8（size+1）個字節的數據。

Step1、為了方便快速的找到上圖的NREAD事務，建議選中srio_request_gen模塊，并把request_address變量拖到波形窗口中，并把這個變量用Unsigned Decimal（無符號10進制）格式顯示。看過上篇《Xilinx RapidIO核例子工程源碼分析》文章的應該知道這個變量是instruction的索引值，當這個變量為78（37+19+19+3=78）的時候就表示發送的是上圖第120行的NREAD事務（之所以不選擇第123行的讀事務是因為它讀的數據量太大了，截圖的時候不方便）。鎖定request_address為78的位置，找到請求事務的傳輸通道ireq，并觀察事務的波形如下圖所示

NREAD請求事務不帶任何數據，只包含一個HELLO格式的包頭，包頭的數據為：4e242070000023f0。各個字段的對應關系如下圖所示

FTYPE=2，TTYPE=4,這兩個字段唯一的確定了這是一個NREAD事務包。其他字段也與之前在instruction_list.vh中第120行定義的完全相同。

Step2、接下來再看看NREAD事務串行物理層的包格式，這個包在155610ns的位置，下圖是NREAD事務串行物理層包格式的時序圖

由上圖可知，整個串行物理層的包為：7c92f014_b84200ad_4b4e0000_23f09c5a_7c92f213。這個包的含義如下：

7c92f014中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），92f014轉化為二進制為：

92f014= 1001_0010_1111_0000_0001_0100

它是一個包起始控制符號，各個字段的對應關系如下圖所示

b84200ad_4b4e0000_23f09c5a是NREAD事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

FTYPE = 2，TTYPE = 4，這兩個值確定了這個包是一個NREAD事務包。rdsize=11（二進制的1011），wdptr=0，通過查RapidIO_Rev_2.2_Specification第34頁的表可知數據量為8個字節，與instruction_list.vh中第120行定義的完全相同。wdptr與rdsize的對應關系表如下所示

7c92f213中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），92f213轉化為二進制為：

92f213= 1001_0010_1111_0010_0001_0011

它是一個包結束控制符號，各個字段的對應關系如下圖所示

4.7 NREAD響應事務

由于NREAD事務是一個有響應的事務，且響應事務中攜帶讀到的數據。所以當發起方（Initiator）往目標方（Target）發送一個NREAD事務以后，發起方（Initiator）還要接收目標方（Target）的發回響應事務。響應事務通過gtrx_data通道接收。響應事務串行物理層包時序如下圖所示，這個響應包在157370ns的位置

由上圖可知，00000000這個數據傳輸了2個時鐘周期，所以整個響應事務串行物理層的包為：7c8af01e_708dadad_804e0000_00000000_0000469c_7c8af219

7c83f00f中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），83f00f轉化為二進制為：

83f00f = 1000_0011_1111_0000_0000_1111

它是一個包起始控制符號，各個字段的對應關系如下圖所示

708dadad_804e0000_00000000_0000469c是NREAD響應事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

FTYPE=13表示這是一個響應事務，TTYPE=8表示這個響應事務攜帶數據，target TID的值為16進制的4e（10進制的78），與請求事務剛好對應上，data字段是8個字節的00，由于并沒有存儲器，所以讀出來的數據全部是0。

7c8af219中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），8af219轉化為二進制為：

8af219= 1000_1001_1111_0010_0001_1001

它是一個包結束控制符號，各個字段的對應關系如下圖所示

響應事務串行物理層的包經過物理層、傳輸層和邏輯層到達iresp通道，iresp通道的時序如下圖所示

iresp通道一共有兩個有效數據，分別為HELLO格式包頭4ed8400000000000和0000000000000000。HELLO格式包頭4ed8400000000000各個字段的對應關系如下圖所示

FTYPE = 13，TTYPE = 8表示這是一個攜帶數據的響應事務，響應事務的prio字段的值為請求事務prio字段的值加1。

4.8 MAINTENANCE事務

頂層模塊srio_example_top.v中例化的srio_quick_start模塊與SRIO IP核的維護端口相連用來產生維護事務。維護事務在maintenance_list.vh頭文件中定義，用戶可以通過編輯maintenance_list.vh頭文件來添加、修改或移除維護事務。下圖是例子工程中定義的所有維護事務

維護事務有本地（Local）和遠程（Remote）兩種類型，區分這兩種維護事務是通過maintr_araddr信號的高八位的值來確定的。如下圖所示

由上圖可知，maintr_araddr的[31:24]位用來區分本地維護事務和遠程維護事務，

當 maintr_araddr=01xxxxxx，表示的是遠程（Remote）維護事務。

當 maintr_araddr=00xxxxxx，表示的是本地（Local）維護事務。

maintr_araddr的[23:0]位是讀操作的偏移地址。

下圖是一個維護事務的時序圖

由上圖可知，紅色框出來的部分是一個讀維護事務，由于maintr_araddr的高8位[31:24]為8’h00，所以這是一個本地（Local）讀維護事務。maintr_araddr的[23:0]位為24’h000000，所以這個本地（Local）讀維護事務訪問的是邏輯層的能力寄存器（Capability Register Space）空間，且寄存器的偏移地址為24’h000000。

SRIO核寄存器空間的分布如下圖所示

下圖是維護端口（接口2）和邏輯層配置端口（接口3）的時序圖

當 maintr_araddr=01000000，表示的是邏輯層的遠程（Remote）維護事務。邏輯層I/O端口發起的維護事務會通過邏輯層、傳輸層到物理層轉化為串行物理層的包通過高速串行收發器（Serial Transceiver）發出去。下圖是一個遠程維護事務串行物理層包的時序，這個包在96680ns的位置

由上圖可知，維護事務串行物理層的包為：7c82f00b_104800ff_18010000_0060dead_beefdead_beefbe6e_7c82f20c

7c82f00b中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），82f00b轉化為二進制為：

82f00b = 1000_0010_1111_0000_0000_1011

它是一個包起始控制符號，各個字段的對應關系如下圖所示

104800ff_18010000_0060dead_beefdead_beefbe6e是維護事務串行物理層的包，把它轉化為二進制后各個字段的對應關系如下圖所示

FTYPE = 8，TTYPE = 1，表明這是一個寫請求的維護事務。上圖中data字段表示的是dead_beefdead_beef這8個字節的數據。

7c82f20c中的7c是特殊字符/K28.3/，它是一個包界定符（Packet Deliminator Control Symbol），82f20c轉化為二進制為：

82f20c = 1000_0010_1111_0010_0000_1100

它是一個包結束控制符號，各個字段的對應關系如下圖所示

4.9 DOORBELL事務與MESSAGE事務

門鈴（DOORBELL）事務與消息（MESSAGE）事務的分析方法與之前幾種方法完全一樣，大家可以自己按照上面的流程先找到HELLO格式的包，對照HELLO格式各個字段的定義進行分析，然后找到串行物理層的包對照串行物理層的包格式再次分析就能明白整個事務的交互過程了。其實對于用戶來說，串行物理層是SRIO IP核幫我們設計好的，所以在實際項目中使用的時候只需要關注HELLO格式的包與時序就可以了。

五、（選讀）SRIO核在ZC706上回環（Loopback）測試

通過Vivado仿真以后大家應該對使用SRIO核有了一個基本了解。如果你手頭有自己做的開發板并且有SRIO的License的話你可以利用SRIO在硬件上做一個回環測試。

所謂SRIO的回環測試就是把SRIO的srio_txp0和srio_rxp0在硬件上連接起來，把srio_txn0和srio_rxn0在硬件上連接起來，讓SRIO的包自發自收。如下圖所示

由于我手頭有一塊Xilinx的ZC706評估板，所以這個回環測試我會在ZC706上完成。

ZC706上的FPGA型號為XC7Z045，它的上面BANK109、BANK110、BANK111和BANK112為MGT BANK，如下圖所示

其中BANK112與PCIe接口相連（后面有空會寫PCIe接口），所以RapidIO不能使用這個BANK。BANK109與BANK110與FMC接口相連，無法使用同軸線或光纖環回，所以這兩個BANK也不能使用。因此RapidIO只剩下BANK111可用，而且BANK111有一個通道已經通過C653和C652環回上了，這樣就省去了自己用光纖或同軸線去環回。接下來最重要的就是給BANK111輸入一個125MHz的參考時鐘。

這個125MHz的時鐘可以從臨近的BANK“借”一個，比如可以通過軟件配置SI5324產生一個125MHz時鐘，盡管SI5324輸出的時鐘并不在BANK111上，但是這個125MHz仍然可以被BANK111“借”用。但是這種方法需要寫軟件配置SI5324，比較麻煩，所以不推薦。

下面介紹另外一種得到這個125MHz時鐘的方法：由于BANK111上有一路時鐘是連接到SMA接口上的，所以這個125MHz時鐘可以用外部的信號源接入，但是如果你沒有信號源的話也沒事，這個125MHz時鐘可以通過FPGA內部的Clocking Wizard產生。

ZC706評估板的結構圖如下圖所示

可以看到上圖用紅色橢圓圈出來的9號和10號兩個SMA接口對，10號SMA接口就是連接到BANK111上的一個參考時鐘，所以我們只需要用FPGA中的Clocking Wizard IP核用ZC706的200MHz系統時鐘得到125MHz的時鐘輸出到9號SMA接口對，然后用同軸線把9號SMA接口對和10號接口對相連就可以了。由于Clocking Wizard IP核輸出的時鐘是單端時鐘，所以還必須用OBUFDS原語把這個125MHz單端時鐘變成差分時鐘輸出到9號SMA接口對。

有了125MHz的參考時鐘以后，接下來就只需要修改例子工程的頂層srio_example_top_srio_gen2_0代碼，添加9號SMA接口對的引腳定義，修改例子工程的物理約束就可以了。還有一個信號就是srio_example_top_srio_gen2_0頂層代碼中的sim_train_en在硬件上執行時必須置0。修改完成以后就可以生成bit文件下載到ZC706上觀察現象了，還可以用ILA抓一下I/O通道的波形，沒有問題的話抓出來的波形和之前仿真的波形是完全一樣的。

六、總結

整個RapidIO系列博客到此就全部寫完了，最后提供兩個仿真的建議：

1、上文我抓的包傳輸數據量都比較少，主要是方便我截圖，傳輸的數據量比較大的時候，整個包的總字節數會超過80個字節，在數據量超過80字節的情況下包中會出來兩個循環冗余校驗碼（CRC碼），這個在《RapidIO串行物理層的包與控制符號》提到過，大家可以自己把包的數據量改的大一點觀察一下數據量大于80字節的情況。

2、由于例子工程中測試的比較全面，所以一共發了很多包，這樣導致找包的時候非常難找，這里提供一個小技巧，你只需要把srio_request_gen_srio_gen2_0.v模塊中的第359行instruction的索引值request_address改成一個固定的數，那么就只會連續不斷的發一種包，看波形的時候就會非常方便，缺點是每修改一次就需要重新仿真，所以比較耗費時間。

審核編輯 ：李倩