文章目录
一、SRIO介绍
1.1、概要
参考1:https://www.ti.com.cn/general/cn/docs/gencontent.tsp?contentId=50741
参考2:https://blog.csdn.net/qq_33904382/article/details/130330299
串行RapidIO针对高性能嵌入式系统芯片间和板间互连而设计。
在嵌入式系统应用领域,DSP,FPGA,PowerPC等嵌入式处理器的出现后,工程师将多种处理器组合,形成模块。模块通过背板相连,形成整机,实现更大的系统应用。新的嵌入式系统互联结构必须具备以下特点:
- 架构独立,不依赖具体的硬件和软件。
- 灵活的拓扑结构,不局限于PC架构的星状结构。
- 传输速率高,并向下兼容。
- 具有流控功能,错误校验及广播功能。
- 具有分层结构,后续功能扩展不影响其他层次
针对以上需求,2000年,存储领域的OEM和FPGA/DSP/交换结构芯片制造商成立了RapidIO Trade Association 组织。提供了一种针对嵌入式运用的低延时的、基于包交换与分发结构的新型总线结构,被命名为RapidIO,又被成为SRIO。
SRIO支持3C连接:Chip-to-Chip、Card-to-Card、Chassis-to-Chassis。从灵活性的角度来说,SRIO协议可支持嵌入式系统的星状、网状、环状、树状及菊花链等多种拓扑结构。数据传输方式灵活多样。支持对等的数据交换。从架构独立性的角度来讲,SRIO协议是由硬件实现,所以对现存的操作系统和运用软件是透明的。它支持读、写、流、原子操作等及消息传递机制,应用层软件简单。从速率、带宽性能及可裁剪上讲,SRIO1.3版支持1.25、2.5、3.125Gbps。采用8B/10B编码,带宽利用率高。
1.2、RapidIO与传统嵌入互连方式的比较
随着高性能嵌入式系统的不断发展,芯片间及板间互连对带宽、成本、灵活性及可靠性的要求越来越高,传统的互连方式,如处理器总线、PCI总线和以太网,都难以满足新的需求 。
1.3、串行RapidIO协议(SRIO)
RapidIO行业协会成立于2000年,其宗旨是为嵌入式系统开发可靠的,高性能,基于包交换的互连技术。RapidIO协议的简要发展历史是:
2001年初,最初的标准被发布
2002年6月,1.2版标准发布
2005年6月,1.3版标注发布
串行RapidIO是物理层采用串行差分模拟信号传输的RapidIO标准。SRIO 1.x 标准支持的信号速度为1.25GHz、2.5GHz、3.125GHz、5GHz、6.25GHz。
SRIO (Serial RapidIO) 是一种串行通信协议,旨在实现高速数据传输和低延迟的通信。而 RapidIO 则是一个组织,致力于推广和发展使用 SRIO 技术的标准化互连架构。换言之,SRIO 是一种通信协议,而 RapidIO 是一个组织,它的成员使用 SRIO 技术来实现高速和低延迟的互连。RapidIO 组织负责制定和推广 RapidIO 互连标准,并支持 RapidIO 产品的开发和部署。
二、RapidIO协议结构及包格式
RapidIO分为3层:
逻辑层(Logical Layer):RapidIO的逻辑层定义了协议和交互规则,包括命名服务、配置管理、错误报告和事件通知等。逻辑层主要负责确保数据在传输过程中的正确性和可靠性,并提供基本的路由功能来寻址目标设备。
传输层(Transport Layer):RapidIO的传输层提供高效的数据传输机制,支持点对点和多点广播传输模式,并提供流控制和拥塞控制等重要功能。传输层还支持多队列机制,可以实现同时传输多个会话或数据流,从而提高带宽利用率和系统吞吐量。
物理层(Physical Layer):RapidIO的物理层定义了硬件接口和电气特性,包括传输速率、信号编码、差分信号传输和时钟同步等。物理层还支持多种不同的物理介质,包括高速串行器件、光纤和电缆等。
与以太网一样,RapidIO也是基于包交换的互连技术。如图3所示,RapidIO包由包头、可选的载荷数据和16bits CRC校验组成。包头的长度因为包类型不同可能是十几到二十几个字节。每包的载荷数据长度不超过256字节,这有利于减少传输时延,简化硬件实现。
2.1、逻辑层
RapidIO是基于包交换的互连技术,传输层定义了包交换的路由和寻址机制。
逻辑层协议包括控制、数据和管理三个子层。
在RapidIO中,控制子层负责建立和维护端到端的通信路径,并对数据传输进行控制。这个过程可以通过发送控制报文来实现,其中控制报文包含有关源地址、目标地址、传输类型、QoS(服务质量)等信息。
数据子层则负责实际的数据传输。数据报文由源节点打包成多个数据包,每个数据包都包含同步信息、错误控制信息和有效载荷数据。接收节点根据同步信息解包数据包,并使用错误控制信息检测和纠正任何传输错误。
最后,管理子层负责管理节点之间的连接和网络拓扑结构。管理报文用于发现新节点、确定节点状态、管理路由表和配置寄存器等。
逻辑层定义了操作协议和相应的包格式。RapidIO支持的逻辑层业务主要是:直接IO/DMA (Direct IO/Direct Memory Access)和消息传递(Message Passing)。
直接IO/DMA模式是最简单实用的传输方式,其前提是主设备知道被访问端的存储器映射。在这种模式下,主设备可以直接读写从设备的存储器。直接IO/DMA在被访问端的功能往往完全由硬件实现,所以被访问的器件不会有任何软件负担。SRIO(Serial RapidIO)带宽大,管脚少,传输方式更灵活。
对上层应用来说,发起直接IO/DMA传输主要需提供以下参数:目地器件ID、数据长度、数据在目地器件存储器中的地址。
直接IO/DMA模式又可进一步分为以下几种传输格式:
NWRITE: 写操作,不要求接收端响应。
NWRITE_R: 带响应的NWRITE(NWRITE with Response),要求接收端响应。
SWRITE:流写(Stream Write),数据长度必须是8字节的整数倍,不要求接收端响应。
NREAD: 读操作。
2.2 传输层
传输层是RapidIO协议栈的一个组成部分,位于物理层和消息层之间。其主要功能是提供可靠的数据传输和流控制。传输层使用虚拟通道(VC)概念来支持多路复用和分时复用,从而在单个物理链路上同时传输多个数据流。
传输层包括四个不同的子层:数据链路控制层(DLC)、流控制层(FLC)、可靠性层(RLC)和可选的直接存储器访问层(DAM)。DLC负责帧同步、检错和重传,FLC负责流量控制,RLC负责确认和重传丢失或损坏的数据包,DAM提供了一种直接将数据写入/读取到内存中的机制,以避免处理器的干预。
在传输层中,每个VC都有唯一的VC编号和优先级,以及一个独立的发送和接收缓冲区。这些缓冲区可以设置为固定大小或自适应大小,以提高数据传输效率。传输层还支持多种数据类型,包括消息、数据和DMA事务。
RapidIO网络主要由两种器件,终端器件(End Point)和交换器件(Switch)组成。终端器件是数据包的源或目的地,不同的终端器件以器件ID来区分。RapidIO支持8 bits 或 16 bits器件ID,因此一个RapidIO网络最多可容纳256或65536个终端器件。与以太网类似,RapidIO也支持广播或组播,每个终端器件除了独有的器件ID外,还可配置广播或组播ID。交换器件根据包的目地器件ID进行包的转发,交换器件本身没有器件ID。
RapidIO的互连拓扑结构非常灵活,除了通过交换器件外,两个终端器件也可直接互连。
2.3 物理层
Serial RapidIO的物理层规范定义了信号传输的电气和机械特性,包括信号编码、时钟同步、差分传输、信号模式匹配和错误检测等。
RapidIO 1.x 协议定义了以下两种物理层接口标准:
8/16 并行LVDS协议
1x/4x 串行协议 (SRIO)
并行RapidIO由于信号线较多(40~76)难以得到广泛的应用,而1x/4x串行RapidIO仅4或16个信号线,逐渐成为主流。
Serial RapidIO物理层使用差分传输技术,即在发送端将数据分成两部分,在接收端再将其合并,以减少噪声干扰和传输误差。Serial RapidIO还采用了多种信号编码方式,如8b/10b、64b/66b和128b/130b等,以实现数据的可靠传输和时钟同步。
串行RapidIO基于现在已广泛用于背板互连的SerDes(Serialize Deserialize)技术,它采用差分交流耦合信号。差分交流耦合信号具有抗干扰强、速率高、传输距离较远等优点。
为了支持全双工传输,串行RapidIO收发信号是独立的,所以每一个串行RapidIO口由4根信号线组成。标准的1x/4x 串行RapidIO接口,支持四个口,共16根信号线。这四个口可被用作独立的接口传输不同的数据;也可合并在一起当作一个接口使用,以提高单一接口的吞吐量。
三、IP核详解
参考xilinx手册pg007
RapidIO核分为逻辑层(LOG),缓冲(BUF)和物理层(PHY)三个部分。如下图所示:
3.1、逻辑层
逻辑层(LOG)被划分成几个模块来控制并解析发送和接收数据包。逻辑层(LOG)有三个接口:用户接口(User Interface),传输接口(Transport Interface)和配置接口(Configuration Fabric Interface)。
用户接口包括能发起和接收包的端口。当生成IP核的时候可以配置端口的数目和事务类型,同时也能通过AXI4-Lite接口发起维护事务对本地或者远程的寄存器进行访问与配置。
传输接口包含发送和接收两个端口,它是用来连接中间的Buffer,对于RapidIO的顶层模块来说,这两个接口不可见。
配置接口也包含两个端口。其中配置主机端口(Configuration Master Port)用来读写本地配置空间。逻辑配置寄存器端口(LOG Configuration Register Port),它可以用来读写一部分逻辑层或传输层配置寄存器。
着重介绍用户接口的相关内容: 用户接口包含I/O端口集和三个可选的端口,三个可选的端口分别为消息端口(Messaging Port),维护端口(Maintenance Port)和用户自定义端口(User-Defined Port)。这些接口都在模块的顶层,每种事务类型都在指定的端口上传输。其中,任何支持的I/O事务例如NWRITEs,NWRITE_Rs,SWRITEs,NREADs和RESPONSEs(不包括维护事务的responses)全部都在I/O端口上发送或者接收。消息(Message)事务能在I/O端口传输或者在消息端口传输,这取决于是否在IP核的配置选择分离I/O端口与Message端口。门铃(Doorbell)事务只能在I/O端口传输,而不能在Message端口上传输。维护事务包只能在维护端口上传输。如果事务是由用户自定义的一种不支持的类型,那么这类事务就可以在用户自定义端口上传输,如果用户自定义的端口在IP核的配置中未使能,那么用户自定义的包会被丢弃。
3.1.1 I/O端口
I/O端口能被配置为两种类型:Condensed I/O或Initiator/Target,这两种类型可以在IP核的配置中进行选择。I/O端口的数据流协议是AXI4-Stream协议,它支持两种类型的包格式,分别是HELLO格式与SRIO Stream格式。
Condensed I/O端口类型减少了用于发送和接收I/O包的端口数目。它只用一个AXI4-Stream通道来发送所有类型的包,同样,也只用一个AXI4-Stream通道去接收所有类型的包。Condensed I/O端口示意图如下:
Initiator/Target端口类型把请求事务与响应事务分别处理,所以一共有4个AXI4-Stream通道用于I/O事务的传输。Initiator/Target端口的示意图如下图所示,其中灰色的箭头表示请求事务,黑色的箭头表示响应事务。
Initiator即为发起者的意思,这里的 i 即表示Initiator,本地设备(Local Device)生成的请求(Requests)通过ireq通道发送,远程设备(Remote Device)产生的响应包通过iresp通道接收来完成整个事务的交互过程。
Target即为目的的意思,这里的 t 即表示Target,远程设备(Remote Device)生成的请求(Requests)通过treq通道接收,本地设备(Local Device)产生的响应包通过tresp通道发送来完成整个事务的交互过程。
在顶层模块中,变量名与通道的对应关系如下:
s_axis_ireq* 对应于ireq通道
m_axis_iresp* 对应于iresp通道
m_axis_treq* 对应于treq通道
s_axis_tresp* 对应于tresp通道
3.1.2 消息(Message)端口
消息端口是一个可选的接口,消息事务既能在I/O端口上发送,也能在独立的消息端口上发送。独立的消息端口类型为Initiator/Target类型。下图是消息端口的示意图:
其变量名与I/O端口命名规则类似。
3.1.3 用户自定义端口
用户自定义端口是一个可选的端口,它包括两个AXI4-Stream通道,一个用于发送另一个用来接收。用户自定义端口仅仅支持SRIO Stream格式的事务。下图是用户自定义端口的示意图:
3.1.4 维护端口
维护端口使用的是AXI4-Lite接口协议,AXI4-Lite接口允许用户访问本地或远程配置空间。下图是AXI4-Lite维护端口示意图:
3.1.5 Status状态接口
deviceid[15:0] : Base DeviceID CSR(偏移地址为0x60)寄存器的值
port_decode_error: 输出 此信号为高说明用户自定义端口未使能,一个不支持的事务被接收并立即丢弃。当下一个支持的事务包在任意用户接口被接收以后此信号被拉低。这个信号同步于log_clk信号
3.2、Buffer接口
该部分接口对于顶层而言是不可见的。他的功能也比较好理解,主要有里俩点:
- 处理跨时钟域的问题:当生成IP核的时候可以根据需求添加或者移除跨时钟域逻辑。对于多通道的RapidIO来说,由于物理层的时钟在start-up场景和traindown场景是动态的,所以推荐把跨时钟域逻辑加上,这样可以保证用户逻辑工作在已知的速率上。
- 发对送和接收的包进行缓冲:发送Buffer负责把将要发出去的事务放到队列中,并对发往物理层(PHY)的包流进行管理。接收Buffer和发送Buffer的大小可以在IP核中配置为8、16或32个包的深度。发送Buffer是一个存储和转发缓冲区,它是用来降低包到包的延迟以最大化流吞吐量。发送Buffer必须保存每个包直到包被接收方成功接收,当接收方成功接收包以后,发送Buffer才会释放包来给其他包腾出空间。当流控(Flow Control)发生时,通常会有多个未发送的包滞留在发送Buffer中,发送Buffer会根据包的类型与优先级进行重新排序,然后按照响应包先发送,请求包后发送的顺序把发送Buffer中的包依次发出去。
3.3、PHY物理层接口
物理层(PHY)用来处理链路训练(Link Training),初始化(Initialization)和协议(Protocol),同时还包括包循环冗余校验码(CRC)与应答标识符的插入。物理层接口与高速串行收发器相连。串行收发器在IP核中被设计为一个外部的例化模块以降低用户使用模型的难度。
四、HELLO包格式
为了简化RapidIO包的构建过程,RapidIO核的事务传输接口(ireq,treq,iresp,tresp)可以配置为HELLO(Header Encoded Logical Layer Optimized)格式。这种格式把包的包头(Header)域进行标准化,而且把包头和数据在接口上分开传输,这将简化控制逻辑并且允许数据与发送边界对齐,有助于数据的管理。
4.1、包头字段定义
详细含义请参考pg007
字段 | 位置 | 描述 |
---|---|---|
TID | [63:56] | 包的事务ID(Transaction ID),RapidIO手册规定在给定的时机,RapidIO包只能有唯一的TID与Src ID对。 |
FTYPE | [55:52] | 包的事务类(Transaction Class),HELLO格式支持的FTYPEs为2,5,6,A,B和D。 |
TTYPE | [51:48] | 包的事务类型(Transaction Type),当FTYPE的值为2,5或D时,不同的TTYPE值对应于包的不同功能。 |
Priority | [46:45] | 包的优先级。请求包的优先级值为0~2,响应包的优先级值为请求包的优先级加1 |
CRF | [44] | 包的关键请求流标志(Critical Request Flow) |
Size | [43:36] | 有效数据负载的字节数减1,如果这个字段的值为0xFF,那么表示有效数据为256(0xFF + 1)个字节 |
Error | [35] | 当这个字段为1时表示包处于错误状态 |
Address | [33:0] | 事务的字节地址 |
Info | [31:16] | 信息域。仅在门铃事务(DOORBELL)中包含此字段 |
Msglen-1 | [63:60] | 消息事务(MESSAGE)中包的个数。仅在消息事务(MESSAGE)中包含此字段 |
Msgseg-1 | [59:56] | 包中的消息段,仅在消息事务(MESSAGE)中包含此字段,如果是单段(signal-segment)消息,此字段保留 |
Mailbox | [9:4] | 包的目标邮箱,仅在消息事务(MESSAGE)中包含此字段,除了单段(signal-segment)消息以外,此字段的高四位是保留位 |
Letter | [1:0] | 包的信件,仅在消息事务(MESSAGE)中包含此字段,指示了邮箱中的一个插槽 |
S,E,R,xh,O,P | [63:56] | S:起始位,当此字段为1时表示这个包是新PDU(Protocol Data Unit)的第一个分段。E:结束位,当此字段为1时表示这个包是新PDU(Protocol Data Unit)的最后一个分段。当S和E均为1时表示PDU仅包含一个包。R:保留位。Xh:扩展头(Extended Header)。目前版本不支持O:奇数(Odd),当此字段为1时表示数据负载有奇数个半字。P:填充位(Pad)。当此字段为1时,一个填充字节用于去填充数据到半字(half-word)边界 |
Cos | [43:36] | 服务类(Class of service) |
StreamID | [31:16] | 点到点的数据流标识符 |
Length | [15:0] | 协议数据单元(Procotol Data Unit,PDU)长度 |
4.2、不同传输情况
HELLO格式的包中Size域的值等于传输的字节的总数减1,Size域的有效值范围为0-255(特别注意:size以字节byte为单位!),对应于实际传输的字节数量1~256。HELLO格式中的size和address域必须对应于RapidIO包中有效的size,address和wdptr域,所以HELLO格式的size和address字段的值存在一些限制条件。RapidIO核不能把Size域中的非法值修正为实际RapidIO包中Size域的有效值,所以需要对HELLO格式包的Size域提供一个正确的值。由于AXI4-Stream协议中tdata信号为8个字节,也就是一个双字(Double Word),所以Size域的值需要分两种情况讨论:传输的数据量小于8字节和传输的数据量大于8字节。
(1)Sub-DWORD Accesses :传输的数据量小于8字节
对于传输的数据量小于8字节的情况,address字段和size字段用来决定有效的字节位置(tkeep信号必须为0xff),但是仅仅能导致RapidIO包中rdsize/wrsize和wdptr为有效值的address和size值组合才是被允许的,下图是HELLO格式中address和size两个字段与有效字节位置的对应关系示意图(图中灰色部分为有效字节位置
例如,对size=5,address=34’h1_1234_5672这两个组合来说,由于size=5,所以往address中写入的数据个数为6(size+1)个字节,而address的最低3位为2(3’b010),通过上图可知,有效字节的位置是第7、6、5、4、3、2六个字节。对于size和address[2:0]值的组合不在上图中的情况都是非法的,这是应该避免的,比如,size=5, address=34’h1_1234_5673这种组合就属于非法的组合。
(2)Large Accesses :传输的数据量大于8字节
对于传输的数据量大于8字节,并且地址的起始字节偏移不为0的情况必须把数据分成多次进行传输,其中未对齐的小于8字节的段就可以通过上图中size和address的有效组合来确定有效字节的位置。另一种解决办法是,读操作的数据量大小可以被增加到下一个支持的大小,然后从对应的响应中剥离出必要的数据。
因此,对于数据量为1个双字(8个字节)或更大的情况,address的最低3位必须为0,RapidIO手册给读写事务定义了范围从1到256个字节的可支持的数据量。请求事务的数据量如果大于一个双字(8个字节),那么数据量应该通过四舍五入到最接近的支持的值。读写事务有效的HELLO格式的数据量为:7,15,31,63,95(仅支持读事务),127,159(仅支持读事务),191(仅支持读事务),223(仅支持读事务)和255。
对于写事务的数据量介于以上这些支持的数据量中间的情况,在通道的tlast信号为1之前应该给RapidIO核提供必要的数据量,仅仅提供的数据才能被发送。同理,用户的设计提供的数据可能少于期望的数据量,那么实际的数据量应该被写入,传输应该假设完成。
RapidIO协议不支持传输的数据量大于256字节的情况,并且逻辑层(Logical)也不能把大于256字节的数据量分割为小的数据量进行发送。如果不满足这个要求可能会导致致命的链路错误,在这种错误情况下,链路可能会不断重传数据量大于256字节的包。所以我们发送数据的时候要注意自己拆分数据。
五、事务类型
RapidIO协议定义了七种事务类型,每种事务类型执行不同的功能。RapidIO包格式中的FTYPE字段与TTYPE字段共同确定了事务的类型,与标准RapidIO协议不同的是,RapidIO核中定义了第9类事务(FTYPE=9)——DATA STREAMING事务,它是一类带有数据负载的写事务,而标准RapidIO协议中第9类事务是保留事务。详细的对应关系如下表所示:
Ftype(Format Type) | Ttype(Transaction Type) | 包类型 | 功能 |
---|---|---|---|
0~1 | —— | Reserve | 无 |
2 | 4’b0100 | NREAD | 读指定的地址 |
4’b1100 | ATOMIC increment | 先往指定的地址中传递数据,在把传递的数据加1,此操作为原子操作,不可打断 | |
4’b1101 | ATOMIC decrement | 先往指定的地址中传递数据,在把传递的数据减1,此操作为原子操作,不可打断 | |
4’b1110 | ATOMIC set | 把指定地址中的数据每个bit全部写1 | |
4’b1111 | ATOMIC clear | 把指定地址中的数据清0(每个bit全部清零) | |
3~4 | —— | Reserve | 无 |
5 | 4’b0100 | NWRITE | 往指定的地址写数据 |
4’b0101 | NWRITE_R | 往指定的地址写数据,写完成以后接收目标器件(Target)的响应 | |
4’b1101 | ATOMIC test/swap | 对指定地址中的数据进行测试并交换,此操作为原子操作,不可打断 | |
6 | 4’bxxxx | SWRITE | 以流写方式写指定的地址,与NWRITE以及NWRITE_R相比,此方式效率最高 |
7 | —— | Reserve | 无 |
8 | 4’b0000 | MAINTENANCE read request | 发起读配置,控制,状态寄存器请求 |
4’b0001 | MAINTENANCE write request | 发起写配置,控制,状态寄存器请求 | |
4’b0010 | MAINTENANCE read response | 产生读配置,控制,状态寄存器响应 | |
4’b0011 | MAINTENANCE write response | 产生写配置,控制,状态寄存器响应 | |
4’b0100 | MAINTENANCE write resquest | 端口写请求 | |
9 | —— | DATA Streaming | 数据流写,请求事务包含有效数据 |
10 | 4’bxxxx | DOORBELL | 门铃 |
11 | 4’bxxxx | MESSAGE | 消息 |
12 | —— | Reserve | 无 |
13 | 4’b0000 | RESPONSEno data | 不带有效数据的响应包 |
4’b1000 | RESPONSEwith data | 带有效数据的响应包 | |
14~15 | —— | Reserve | 无 |