1. 概述

本文是用于記錄srio的學習情況，以及一些對xilinx的vivado 2017.4中生成srio例程代碼的解釋。

2. 參考文件

《pg007_srio_gen2》

3. SRIO協(xié)議介紹

本處將從SRIO的數(shù)據(jù)流，數(shù)據(jù)協(xié)議，常用FPGA支持模式，以及IP例程中的時鐘大小計算等部分介紹SRIO的情況。

3.1 SRIO的數(shù)據(jù)流

SRIO通過生成IP后，通常情況下主要使用的接口為四組：ireq，iresp，treq，tresp。每個IP生成后都有這四組接口，即可以同時用于發(fā)送數(shù)據(jù)，接收數(shù)據(jù)，發(fā)送響應數(shù)據(jù)，接收響應數(shù)據(jù)。而這些接口間的信號流向如下圖所示：

即其信號流為IREQ發(fā)出給TREQ，TRESP發(fā)出給IRESP。

3.2 SRIO的數(shù)據(jù)協(xié)議

SRIO傳輸與響應的包類型很多，具體看手冊P73-P74頁。

在使用Xilinx的ip核時，通常用的都是HELLO包，所以這里指給HELLO包的格式。如下圖所示。Packet 中的具體符號表示意義請查看手冊P76-P77頁。其中的size為一包傳輸byte的數(shù)據(jù)量，范圍為1-256 bytes。

其典型的傳輸數(shù)據(jù)的用戶接口代碼的波形協(xié)議如下圖所示：

3.3 SRIO常用FPGA支持的模式

3.4 SRIO例程代碼的時鐘計算

refclk可使用時鐘如下圖table3-3所示。其中典型的時鐘計算如Table3-4表頭所示。:

gt_clk = line_rate/20;

gt_pcs_clk = line_rate/40;

phy_clk = (gt_clk*link_width)/4;

log_clk = phy_clk;

cfg_clk = phy_clk;

4. SRIO的例程代碼結(jié)構

SRIO生成例程后，其例程結(jié)構如下圖所示?？粗?個文件，但常規(guī)情況下與我們相關的只有只有兩個文件，即下圖高亮的兩個文件：

srio_request_gen_srio_gen2_0（發(fā)送數(shù)據(jù)模塊）；

srio_response_gen_srio_gen2_0（接收數(shù)據(jù)模塊）

4.1 SRIO發(fā)送模塊詳解

SRIO發(fā)送模塊中主要有兩部分代碼，發(fā)送數(shù)據(jù)部分（ireq），發(fā)送響應數(shù)據(jù)部分（iresp）。接收部分端口如下圖所示：

4.1.1 發(fā)送數(shù)據(jù)部分代碼功能說明

發(fā)送的包頭數(shù)據(jù)的來源為“request_data_out = instruction[request_ address]”，即數(shù)據(jù)是從`include "instruction_list.vh"文件中調(diào)入的。而選擇其文件中的哪些數(shù)據(jù)則是根據(jù)request_address算來的，具體如下圖部分所示。

最終包頭的格式為：

而包中去掉包頭后傳輸?shù)臄?shù)據(jù)為每8位遞增數(shù)據(jù)數(shù)據(jù)，具體如下圖所示。

重點：發(fā)送用戶自己的數(shù)據(jù)與包頭時設置，將go的值設置為0x01。

4.1.2 接收響應部分的代碼功能詳解

接收響應部分主要功能是在期望的得到回應的包類型時，檢查是否回應的對應包頭類型。

而判斷包頭類型是否正確主要是根據(jù)預判的ftype(expected_ftype)時,檢查接收到的ttype是否為協(xié)議規(guī)定的類型。判斷的方式為下圖位置：

4.2 SRIO接收模塊詳解

SRIO接收模塊中主要有兩部分代碼，接收數(shù)據(jù)部分（treq），接收響應數(shù)據(jù)部分（tresp）。接收部分端口如下圖所示：

4.2.1 接收數(shù)據(jù)部分的代碼功能說明

接收部分主要是通過解析接收端口的信號，實時的解析如下圖的信息，以及first_beat（beat為1個時鐘的*_data），之后將每包數(shù)據(jù)去掉包頭后丟入“RAMB36SDP（local_data_store）”中，但是每一包丟入數(shù)據(jù)時的首地址是current_addr[10:3]。

4.2.2 發(fā)送響應部分的代碼功能說明

響應部分的代碼分兩部分，第一部分是響應的包頭信號部分，第二部分是響應的數(shù)據(jù)部分。

包頭信號部分信息與響應的包類型相關，如下圖所示，詳細信息參考《pg007》的p76頁。

數(shù)據(jù)部分的信息主要是提取treq中輸入的信號。但提取的方式是根據(jù)starting_read_addr = {1'b0, response_data_out[29:22]}開始提取數(shù)據(jù)輸出，即是根據(jù)current_addr[10:3]的地址提取數(shù)據(jù)。也就是說這個提取數(shù)據(jù)的位置是根據(jù)輸入數(shù)據(jù)包中的地址中的一部分作為首地址來定位的數(shù)據(jù)開始地方。

當然是否需要反饋數(shù)據(jù)部分得根據(jù)接收到的包頭類型而定，有些包只需要反饋包頭不需要數(shù)據(jù)，有些包不需要進行反饋，詳情參考手冊P73頁。

保證存入“RAMB36SDP（response_queue_inst）”的包頭判斷信息無誤的依據(jù)是RAMB36SB的寫使能WREN(generate_a_response)，generate_a_response是在接收到的first_beat時，且這個包頭是需要反饋數(shù)據(jù)的包頭時才會拉高使能。需要反饋的依據(jù)在《pg007》的Table 3-1，具體信息如下圖所示：

5. 疑點

疑點1：

雖然理論上來說反饋的數(shù)據(jù)提取數(shù)據(jù)是根據(jù)包頭信息在同一個位置提取的，那么反饋的數(shù)據(jù)就和接收的對應包數(shù)據(jù)相同。但是由于接收到的數(shù)據(jù)包頭的地址可能相同，至少current_addr[10:3]有很大幾率相同，那么就會存在數(shù)據(jù)覆蓋的現(xiàn)象，那么就會導致反饋的數(shù)據(jù)不是想要的數(shù)據(jù)，即返回的數(shù)據(jù)與接收到的數(shù)據(jù)不同。

疑點2：

為何把“current_addr[23:16] == 8'h12”作為pull_from_store（從存儲地址開始拉高）？

答：這個只是對應SRIO例程的發(fā)射數(shù)據(jù)，發(fā)射數(shù)據(jù)自定義的“真實起始地址”，參考手冊P161，如下圖所示。在自己使用時可以屏蔽掉與這個相關的信號。

原文鏈接：

https://openatomworkshop.csdn.net/67459da63a01316874d8e7a6.html