SRIO IP介绍 （一） SRIO IP概述_srio接口

目录

1.总体介绍

2.SRIO 系统架构

2.1 逻辑层接口

2.1.1 I/O端口

2.1.2 消息端口

2.1.3 用户定义端口

2.1.4维护端口

2.1.5 状态

2.2 Buffer接口

2.3 物理层接口

3. AXI4-Stream SRIO接口使用

3.1 HELLO数据包格式

3.2传输数据量分组

3.2.1 传输数据量小于8字节

3.2.2 传输数据量大于8字节

3.2.3 HELLO包时序

3.3事务类型

---

1.总体介绍

        RapidIO互连架构旨在与最流行的集成通信处理器、主机处理器和网络数字信号处理器兼容，是一种高性能的分组交换互连技术。它满足了高性能嵌入式行业对系统内互连的可靠性、更高带宽和更快总线速度的需求。 SRIO Gen 2终端支持1x、2x和4x通道宽度，支持1.25、2.5、3.125、5.0和6.25 Gbaud的每通道速度。

        RapidIO标准分为三层：逻辑层、传输层和物理层。逻辑层定义整个协议和数据包格式。这是端点发起和完成事务所必需的信息。传输层提供数据包从一个端点移动到另一个端点所需的路由信息。物理层描述设备级接口的细节，如数据包传输机制、流控制、电气特性和低级错误管理。这种划分提供了向逻辑规范添加新事务类型的灵活性，而不需要修改传输层或物理层规范。

2.SRIO 系统架构

        SRIO Gen 2端点由以下部分组成：Serial RapidIO Gen 2物理层（PHY）、Serial RapidIO Gen 2逻辑层（I/O）和传输层、缓冲器设计（BUF）以及时钟、复位和配置访问的参考设计。如下图所示：

2.1 逻辑层接口

 逻辑层（LOG）被划分为多个模块，这些模块控制发送和接收数据包的连接和解析。LOG有三个接口：用户接口、传输接口、和配置接口。如图为逻辑层接口的示意图：

        用户接口包含可以发出或使用数据包的端口。当生成核时，可以配置端口的数量和与每个端口相关联的事务类型。还可以从这些端口发起对驻留在该SRIO Gen2端点设备中的配置寄存器或远程设备的配置读写访问。这些接口通过Serial RapidIO包装器输出，用于数据包生成。

        传输接口包含两个端口（接收和发送），旨在与RapidIO兼容的物理层或缓冲应用程序连接。这个接口在包装器模块外部是不可见的。

        配置接口包含两个端口：配置主机端口，它是通过配置结构向本地配置空间发出读和写操作。LOG配置寄存器端口，其是用于读取和写入被定义为逻辑层或传输层的一部分的任何配置寄存器的从接口。

2.1.1 I/O端口

        I/O端口可以配置为以下两种类型之一：Condensed I/O 或 Initiator/Target。可用的信号取决于在芯生成期间选择的样式。

        I/O端口由AXI 4-Stream通道构建。有两种数据包格式可用，分别是HELLO和SRIO Stream。

       Condensed I/O 样式减少了用于传输和接收I/O数据包的通道数。有一个AXI 4-Stream通道用于传输与I/O端口（iotx）相关联的所有数据包类型。类似地，存在用于所有接收到的I/O端口分组（iorx）的一个信道。下图为了Condensed I/O 端口。

        Initiator/Target端口允许将用于远程设备的事务（放置在启动器端口上）与针对本地端点的事务（放置在目标端口上）分离。如图所示，当使用启动器/目标端口样式时，有四个AXI 4-Stream通道用于I/O事务。请求通道以黑色显示，响应通道以灰色显示。

        由本地端点生成的请求被放置在发起者请求（ireq）信道上以在链路上传输。从远程设备接收的响应在发起方响应（iresp）通道上呈现给用户设计。由核心接收的源自远程设备的请求在目标请求（treq）信道上呈现给用户设计。由用户设计生成的对这些请求的响应被放置在目标响应（tresp）通道上。

        在顶层模块中，变量名与通道的对应关系如下：

　　s_axis_ireq* 对应于ireq通道

　　m_axis_iresp* 对应于iresp通道

　　m_axis_treq* 对应于treq通道

　　s_axis_tresp* 对应于tresp通道

2.1.2 消息端口

        消息传递端口是一个可选接口（消息也可以组合到I/O端口上，并使用Vivado集成设计环境（IDE）设置作为写入事务处理）。单独的消息传递端口遵循启动器/目标样式。允许将以远程设备为目标的事务与以本地端点为目标的事务分离。如图所示为消息传送端口：

        本地生成的请求被放置在消息发起者请求（msgireq）端口上，以便在链路上传输。从远程设备接收的响应显示在消息发起方响应（msgiresp）端口上。Serial RapidIO内核接收到的源自远程设备的请求在Message Target Request（msgtreq）端口上显示。由用户设计生成的对这些请求的响应放在消息目标响应（msgtresp）端口上。

2.1.3 用户定义端口

        用户定义端口是一个可选端口，具有两个AXI 4-Stream通道，其中一个通道用于发送方向，另一个通道用于接收方向。用户定义的端口仅使用SRIO流格式。如图显示了用户定义的端口。

        s_axis_usrtx* 信号与USER_IO_TX接口关联，

        m_axis_usrrx* 与该级别的USER_IO_RX接口关联。

2.1.4维护端口

        维护端口如果启用了维护端口，则使用AXI 4-Lite接口。AXI 4-Lite接口允许用户应用程序以本地或远程配置空间为目标。如图显示了与AXI 4-Lite维护端口相关的AXI 4-Lite通道。请求在以黑色显示的通道上进行通信（从右到左），AXI 4-Lite响应在以灰色显示的通道上返回（从左到右）。

        每个通道具有独立的就绪/有效握手信号。

2.1.5 状态

        状态信号包括deviceid和port_decode_error，如下表所示：

2.2 Buffer接口

        提供利用PHY生成的缓冲器设计（BUF）以考虑发送和接收分组缓冲。BUF是保证数据包传输和流量所必需的。.Xilinx提供了一种可配置的缓冲区解决方案，允许在系统性能和资源需求之间进行权衡。

        发送Buffer负责对传出事务进行排队，并管理这些分组通过链路接口流入PHY。TX和RX缓冲区大小可通过Vivado IDE配置为8、16或32个数据包的深度值。TXBuffe是被设计用于低分组到分组延迟以最大化流式传输吞吐量的存储和转发缓冲器。发送Buffe必须保持每个分组，直到其已被链路伙伴设备成功接收，在该点处，分组被释放以为附加分组腾出空间。在多个未发送的分组在缓冲器中累积的情况下（这在流控制发生时经常发生），BUF基于类型和优先级对分组进行重新排序，其中首先发出响应分组，然后发出请求。此外，BUF在必要时处理时钟交叉。当生成核时，可以添加或移除时钟域交叉逻辑。

        接收Buffer充当FIFO，用于将数据存储和转发到LOG接收路径中。接收缓冲器还具有允许逻辑层/用户设计和PHY以不同时钟速率运行的域交叉逻辑。与发送缓冲器设计一样，建议将此逻辑用于多通道内核。

        BUF的所有接口都在内部连接到<component_name>_block模块，并且从包装器层外部不可见。如图：

        在BUF的PHY侧和PHY侧的每个方向上都有两个AXI 4流信道。还有一个AXI 4-Lite接口到配置结构，允许访问BUF配置空间。

2.3 物理层接口

        物理层（PHY）处理链路训练、初始化和协议。包括在插入CRC和确认标识符到传出的数据包。PHY还连接到串行收发器。这些收发器作为核心的外部实例提供，以简化客户使用模型。然而，到串行收发器的PHY连接由两个封装器模块（PHY封装器和<component_name>_block）抽象。因此，到收发器的接口以及BUF接口从block的外部隐藏。

        在PHY的BUF侧上的每个方向上存在AXI4-Stream通道。还存在到配置结构的AXI 4-Lite接口，其允许访问PHY配置空间。在PHY的收发器侧上还存在串行接口。

3. AXI4-Stream SRIO接口使用

        用户接口端口由AXI 4-Stream接口构建。接口概述AXI 4-Stream协议使用就绪/有效握手将信息从主机传输到从机组件。它使用最后节拍指示符来指定分组边界。还存在具有字节使能信息的信号，其指示当前数据拍中的哪些字节是好的。最后，还有携带实际分组信息的数据和用户信号。

3.1 HELLO数据包格式

        在开始介绍HELLO包格式之前，先和大家强调一下HELLO包的重要性。我们都知道，SRIO IP的作用就是为了数据的传输，封装成一个IP，然后留出用户接口供我们更简单的使用。那么，数据传输的格式是什么呢，一般情况下，我们大多采用HELLO包的格式。

        为了简化数据包构造，可以将用户接口端口配置为使用报头编码逻辑层优化（HELLO）格式。该格式允许跨分组类型的报头字段放置的标准化。它还将报头和数据分段到接口上的单独传输中。这导致更简单的控制逻辑，并允许数据与传输边界对齐，以便于数据管理。

        HELLO格式的包如下图所示：

        看到这个表格，我们不需要全都记住，只需要保存即可，在后面使用的时候再进行查阅就好了。接下来我们就详细的介绍一下各个字段的含义。

        HELLO分组中的大小字段是传输中的字节数减1（有效范围是0到255，其对应于1到256字节的真实大小）。

3.2传输数据量分组

        由于AXI4-Stream协议中tdata信号为8个字节，也就是一个双字（Double Word），所以Size域的值需要分两种情况讨论：传输的数据量小于8字节和传输的数据量大于8字节。

3.2.1 传输数据量小于8字节

        对于少于8个字节的传输，地址和大小用于确定传输的活动字节通道（TKEEP总线必须连接到所有1）。只允许有效的rdsize/wrsize和wdptr的组合。如图显示了HELLO地址和大小的组合，这些组合会产生有效的字节通道（以灰色突出显示）。

        简单理解就是，通过HELLO SIZE和HELLO addr的组合，来确定8个字节中的某几个字节有效。比如地址第三位为101（5），HELLO SIZE为2，那么此时第7,6,5个字节有效，正好对应3个字节。

3.2.2 传输数据量大于8字节

         长度超过一个DWORD（八个字节）的LOG传输，如果起始字节偏移量不是零，则必须将其分解为多个传输，包括未对齐段的子DWORD事务。或者，可以通过将读取大小增加到下一个支持的大小并从相应的响应中提取必要的数据来处理读取。

        因此，对于一个DWORD或更大的事务，地址的三个最低有效位必须为零。RapidIO规范定义了支持的大小子集，范围从1到256字节，用于读写事务。大于DWORD的请求应向上舍入到下一个最接近的支持值。读写事务的有效HELLO大小为：7、15、31、63、95（只读）、127、159（只读）、191（只读）、223（只读）和255。

        对于这些大小中间的写入大小，在信道tlast信号断言之前，应当仅向核提供要发送的必要量的数据。仅发送提供的数据。RapidIO规范不支持大于256字节的数据传输大小，并且该规范不会将大型事务分解为较小的段。不遵守此要求可能导致致命的链路错误，其中链路伙伴不断重试过大的数据包。HELLO报头在用户接口端口上的第一次传输时出现。如果存在与事务相关联的数据，则在后续节拍上呈现该数据。分组的源和目的地ID被放置在用户信号上，并且在每个分组的第一次传送时被采样。在第一次搏动之后忽略用户信号。

3.2.3 HELLO包时序

        如图，显示了一个用户接口端口上的典型数据传输（basic）。该特定传输具有四个DWORD（32字节）的数据有效载荷。在接口上，包括报头的传输，总共需要五个周期。

        其实，我们掌握这种简单的时序就已经可以正常使用SRIO IP了，可以看到数据格式就是包头后面加上一包数据，包头的内容以及各个字段的含义在之前我们也已经介绍过了。下面介绍一个复杂点的时序（advanced）。如下图所示：

        首先，存在两个背对背单循环（仅报头）分组。分组边界由TLAST信号的断言来指示。在单周期数据包之后，主机在开始下一个数据包之前等待一个周期。在第三个数据包中，主机和从机均在不同的周期上暂停接口（分别通过取消断言TVALID和TREADY）。在单周期包传输完毕以后，主机等待了一个时钟周期才开始发送下一个包。在发送第三个包的过程中，主机（Master）和从机（Slave）分别通过拉低tvalid和tready信号一个时钟周期来暂停数据的发送，由于第三个包的数据负载为2个双字，所以传输第三个包一共消耗了3个有效时钟，加上2个无效的时钟周期，一共消耗了5个时钟周期。其实总的来说，该时序就是tvalid和tready同时置位，数据才有效。

3.3事务类型

        RapidIO协议定义了七种事务类型，每种事务类型执行不同的功能。RapidIO包格式中的FTYPE字段与TTYPE字段共同确定了事务的类型，用到的话直接查表就可以，同样不需要记住，参考《PG007》P.168