SRIO—IP核——4.SRIO配置与示例，协议解析_srio接口物理协议

4.SRIO IP核配置

4.1 Basic

4.1.1第一页配置（Basic）

1. Link Width：链路通道数量
2. Transfer Frequency：每条通道的波特率
3. Reference Clock Frequency：外部输入的参考时钟
4. Buffer Configuration：传输和接收缓存区的深度可以定制为8、16或32.这个数字表示缓冲区能够存储的数据包数量。选择较小的缓冲区深度可以节省资源（主要是块ram和lut），而最大的缓冲区深度可以获得最大的吞吐量
5. Component Device ID：配置设备ID
6. Device ID Width：设备ID宽度，应与链接伙伴的设备ID宽度匹配
7. Unified Clock：如果用户设计为log_clk（主用户时钟）和phy_clk，使用相同的时钟，请勾选此复选框。选择此选项可以显著降低延迟和资源利用率。
8. Flow Control：这些选项表明了变送器使用的流量控制类型

Transmitter Controlled：选择此选项，core首次尝试使用发射机控制的流控制，如果链接伙伴不支持这种方式，会切换到接收机控制

Receiver Controlled：仅接收控制流量控制时选择此选项。该模式采用盲目传输和重试协议的方式控制报文的流量。

1. Additional transceiver control and status ports：选中此框可启用额外的收发器控制和状态端口。这些端口对应于相应设备GTX/GTP用户指南中同名的收发器端口。这些端口在调试收发链路时很有用。

4.1.2第二页配置（Shared Logic）

Include Shared Logic in Example Design：MMCM，Reset logic和GT COMMON block作为共享逻辑被包含在example design。

Include Shared Logic in Core：MMCM，Reset logic和GT COMMON block作为共享逻辑被包含在core中。

4.2 Advanced

4.2.1第一页配置（Basic）

Mode：Basic/Advance；选高级，可以对I/O等内容进行配置；但是经验证，Basic模式也挺好，Basic+Share Logic in Core

系统配置：根据实际情况，选择通道数和每个通道的传输速率、以及参考时钟频率。

Buffer配置：选择发送/接收buffer的深度。深度越大，能缓存的数据包就越多；相应的消耗资源也就越多。

设备ID：也就是接口协议里面的源ID，可配为8bit或16bit，但收发双方的设备ID宽度应该相同。

设备ID的位宽：8/16

Unified Clock：选择后，log_clk必须等于phy_clk；选中这个选项可以减少延时和资源利用率。

流控：

transmitter-controlled发送器控制的流控：首先使用发送器控制的流控，接收器不支持再切换到接收器控制的流控；

receiver-controlled接收器控制的流控：若选择，则核只支持接收器控制的流控。

transmitter-controlled流控可以利用接收buffer的状态和水印最小化重试条件。receiver-controlled流控会随意的发包并使用重试协议。

4.2.2第二页配置（logic layer）

主要选择源端（source）和目的端（destination）支持的事务类型：

    默认除了最后的（data streaming）都勾选上的。因为data streaming是IP核定义的第九类事务类型而RapidIO协议中的第九类事务为保留。

    下面的支持维护事务要勾选上。

    Enable Arbitration：仲裁使能选项：用来使能逻辑层与输入端口之间的仲裁器。防止多个事务的拥堵，优先级如下所示:

LCSBA:启用后，内核将检查传入的I/O事务的高位地址，如果地址匹配，则将事务路由到维护端口。仅针对HELLO包格式。

4.2.3第三页配置（I/O）

Port I/O style：

    Condensed I/O：简要I/O，信号少；

    Initiator/Target：按请求/响应区分通道，各自使用一组AXI4-S接口通道

HELLO Format：

Messaging：

    Combined with IO：消息事务和I/O写事务采用相同的IO端口

    Separate Messaging Port：消息事务采用一个独立的端口传输。

Maintainance：维护端口类型只能为AXI4-Lite类型。

4.2.4第四页配置（BUF）

Request Reordering：

    若选择，发送Buffer会根据请求包的优先级重新排序。这里所说的优先级应该是Xilinx对事务类型自定义的优先级，如下图所示：

Flow Control Options：用于流控的选项

4.2.5第五页配置（PHY）

CRF：关键帧，关键请求流，用于扩展优先级映射，一般不使用。

IDLE：空闲模式，IDLE选择与传输速率有关

IDLE1：只支持每通道线速率小于5.5Gbps的情况，RapidIO使用的控制符号为短控制符号

IDLE2：6.25Gbps的线速率必须选择IDLE2

注意：当IDLE1和IDLE2均被选中时，每通道线速率仅支持小于等于5.5Gbps的情况。

4.2.6第六页配置（log reg）

指定了Device ID与Vendor ID设备标识CAR存储有关RapidIO设备的信息。

    CAR存储有关RapidIO设备子系统创建者/版本的信息等，不影响逻辑功能。

    为了简单，大多默认。

4.2.7第七页配置（PHY reg）

上面主要设置扩展功能地址空间和超时控制等，默认。

Port General Control CSR：

    HOST指示该设备是主机设备。如果未设置此位，则设备是代理或从设备。主使能位控制是否允许设备向系统发出请求。如果未设置“主机使能”位，则设备可能仅响应请求。

4.2.8第八页配置（Shared Logic）

一般选择放在Example Design中，一是为了学习理解，二是灵活操作。

主要是将时钟和复位（MMCM，复位逻辑和GTCOMMON模块）之类的共享逻辑放在示例设计中。

5.示例工程Example Design介绍

5.1示例工程架构组成

示例工程目录：

包含两个头文件和一堆子模块。

5.1.1子模块介绍

5.1.2工程结构

整个结构包括时钟模块，复位模块，配置结构以及产生RapidIO事务的激励模块。

    srio_quick_start.v模块在顶层srio_example_top.v中例化，它与IP核的维护端口相连用来产生维护事务，维护事务在maintenance_list.vh中进行定义，用户可以根据需要编辑maintenance_list.vh文件来添加，修改和移除维护事务。

    srio_request_gen.v模块也在顶层srio_example_top.v中例化，它用来产生I/O事务与消息事务。这个模块也存储了期望的响应并把接收的响应与期望值进行比较。

    srio_response_gen.v模块也在顶层srio_example_top.v中例化，它用来为接收到的请求事务生成对应的响应事务。

   

    通过上图可以看出，产生I/O事务有两种方式：（端口类型：AXI4-Stream类型）

    ·通过例子工程中自带的srio_request_gen.v产生I/O事务

    ·通过顶层模块中Initiator和Target的request/response接口自己编写代码产生I/O事务

    同样的，也有两种方式产生维护事务：（端口类型：AXI4-Lite类型t）

    ·通过例子工程中自带的srio_quick_start.v模块产生维护事务

    ·通过顶层模块中的维护接口自己编写代码产生维护事务

默认情况下，示例设计被配置为自动生成刺激（用于I/O和维护事务）并绕过外部接口。通过设置VALIDATION_FEATURES=1和QUICK_STARTUP=1，在srio_example_top.v模块中实现此默认值。此外，有必要注释外部接口以保存引脚并改善定时。

要使用外部接口进行I/O生成，请设置参数VALIDATION_FEATURES=0，并取消注释外部接口(axis_ireq_*,axis_tresp_*,axis_iresp_*,axis_treq_*,axis_iotx_*,和axis_iorx_*)在srio_example_top模块中。要将外部接口用于维护事务，请设置参数QUICK_STARTUP=0，并取消注释外部接口(axis_maintr_*)在srio_example_top模块中。srio_example_top包含有助于此过程的注释。

5.2示例工程仿真分析

5.2.1仿真分析

仿真目录：

仿真顶层例化了两个srio_top实体：一个primary，一个mirror：

    可以看到，primary的发送管脚tx与mirror的接收管脚rx相连接，也就是说由primary发给mirror；另一个方向同样，primary的接收管脚rx与mirror的发送管脚tx相连接。

    按照理解，primary的srio_request_gen.v产生的I/O事务，将由ireq接口发送出去,由mirror的treq接口接收。mirror实体的srio_request_gen.v产生的I/O事务，也由ireq接口发送出去，由primary的treq接口接收。

5.2.2仿真验证

Run Simulation:

添加信号，分组方便查看

然后就等初始化完成，port_initialized拉高，表示初始化完成。Link_initialized拉高，表示物理层接受了7个控制符号并发送了15个控制符号。

    仿真结果，使用第一包数据进行分析

    由图可知，包头信号为64’h006020fcd0000600

    换算成二进制为：64’b0000_0000_0110_0000_0010_0000_1111_1100_1101_16’b0_0110_8’b0

    首先判断事务类型：

    FTYPE=[55:52]=6，  TTYPE=[51:48]=0,

    可以判断，事务类型为SWRITE。（SWRITE没有TTYPE）

我们再把SWRITE事务类型格式拉出来进行对比一下

得知，size=15，意思就是这包请求包含16个字节的数据。而tdata为64bit，8byte；

    可以推论在发送数据的第二个有效时钟周期时，将会拉高tlast。如上图标红②所示。

6.SRIO接口通信协议

6.1 总线技术Rapid IO的含义

逻辑层定义整体协议和数据包格式。这是端点启动和完成事务所必需的信息。

传输层提供数据包从端点移动到端点所需的路由信息。

物理层描述了设备级接口细节，例如数据包传输机制，流控制，电气特性和低级错误管理。

这种划分提供了将新事务类型添加到逻辑规范的灵活性，而无需修改传输或者物理层规范。

6.2 SRIO协议解析

6.2.1 协议原理

1）SRIO协议是基于点对点的串行通信协议，通过高速差分信号进行数据传输。

2）SRIO协议采用虚拟通道的方式实现并行传输，每个虚拟通道都有独立的发送和接收缓冲区。

3）SRIO协议支持多种数据传输模式，包括可靠传输和非可靠传输，以满足不同应用场景的需求。

4）SRIO协议通过控制消息和数据消息进行通信，控制消息用于配置和管理通信链路，数据消息用于传输实际数据。

6.2.2 数据传输流程

SRIO协议的数据传输流程包括以下几个步骤：

a）发送端将数据划分为一系列的数据包，并添加头部信息。

b）发送端将数据包发送到接收端，通过SRIO链路进行传输。

c）接收端接收到数据包后，进行数据解析和处理。

d）接收端发送确认消息给发送端，表示数据接收成功。

e）发送端接收到确认消息后，将数据包从发送缓冲区删除。

6.2.3 帧格式

SRIO协议的帧格式包括以下几个字段：

a）控制字段：用于指示帧类型和传输模式。

b）目标ID字段：指示数据包的目标设备ID。

c）源ID字段：指示数据包的源设备ID。

d）虚拟通道ID字段：指示数据包所属的虚拟通道。

e）数据字段：实际的数据内容。

f）校验字段：用于校验数据的完整性。

6.2.4 性能要求

1）SRIO协议在传输速率、延迟和可靠性等方面有着严格的性能要求。

2）传输速率：SRIO协议支持多种传输速率，包括1.25Gbps、2.5Gbps、3.125Gbps等。

3）延迟：SRIO协议要求在数据传输过程中保持低延迟，以确保实时性能。

4）可靠性：SRIO协议通过重传机制和差错校验等方式，确保数据的可靠性。