????????RapidIO标准定义为三层：逻辑层、传输层和物理层。逻辑层定义了总体协议和包格式。它包括了RapidIO设备发起和完成事务的必要信息。传输层提供了RapidIO包传输过程中的路由信息。物理层描述设备级接口细节，例如包传输机制、流控、电气特性和低级错误管理。这种划分不需要对传输层或物理层规范进行修改，就可以灵活的给逻辑层规范添加新的事务类型。

????????RapidIO核的设计标准来源于RapidIO Interconnect Specification rev2.2，它支持1x，2x和4x三种模式，每通道的速度支持1.25Gbaud，2.5Gbaud，3.125Gbaud，5.0Gbaud和6.25Gbaud五种。

????????RapidIO核分为逻辑层（Logical Layer），缓冲（Buffer）和物理层（Physical Layer）三个部分。

???????1.2?SRIO核架构

RapidIO核分为逻辑层（LOG），缓冲（BUF）和物理层（PHY）三个部分。如下图所示：

二、接口介绍

RapidIO核把三个子核封装在一起，它提供了一个高层次，低维护的接口。

先放一张总结性的脑图：

接下来我们详细介绍SRIO各子层的各个接口。

2.1逻辑层接口（重点）

????????逻辑层（LOG）被划分成几个模块来控制并解析发送和接收数据包。逻辑层（LOG）有三个接口：用户接口（User Interface），传输接口（Transport Interface）和配置接口（Configuration Fabric Interface）。

　　下图是逻辑层接口的示意图：

?用户接口包括能发起和接收包的端口。当生成IP核的时候可以配置端口的数目和事务类型，同时也能通过AXI4-Lite接口发起维护事务对本地或者远程的寄存器进行访问与配置。

传输接口包含发送和接收两个端口，它是用来连接中间的Buffer，对于RapidIO的顶层模块来说，这两个接口不可见。

配置接口也包含两个端口。其中配置主机端口（Configuration Master Port）用来读写本地配置空间。逻辑配置寄存器端口（LOG Configuration Register Port），它可以用来读写一部分逻辑层或传输层配置寄存器。

　对于RapidIO IP核来说，用户最需要关注的就是用户接口，下面着重介绍用户接口的相关内容。

??用户接口包含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核的配置中未使能，那么用户自定义的包会被丢弃。

2.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端口的示意图如下图所示，其中灰色的箭头表示请求事务，黑色的箭头表示响应事务。

????????本地设备（Local Device）生成的请求（Requests）通过ireq通道发送，远程设备（Remote Device）产生的响应包通过iresp通道接收来完成整个事务的交互过程。

??远程设备（Remote Device）生成的请求（Requests）通过treq通道接收，本地设备（Local Device）产生的响应包通过tresp通道发送来完成整个事务的交互过程。

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

????????s_axis_ireq* 对应于ireq通道

????????m_axis_iresp* 对应于iresp通道

????????m_axis_treq* 对应于treq通道

????????s_axis_tresp* 对应于tresp通道

2.1.2消息端口

????????消息端口是一个可选的接口，消息事务既能在I/O端口上发送，也能在独立的消息端口上发送。独立的消息端口类型为Initiator/Target类型。下图是消息端口的示意图：

????????????????本地设备（Local Device）生成的请求（Requests）通过msgireq通道发送，远程设备（Remote Device）产生的响应包通过msgiresp通道接收来完成整个事务的交互过程。

????????远程设备（Remote Device）生成的请求（Requests）通过msgtreq通道接收，本地设备（Local Device）产生的响应包通过msgtresp通道发送来完成整个事务的交互过程。

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

????????s_axis_msgireq* 对应于msgireq通道

????????m_axis_msgiresp* 对应于msgiresp通道

????????m_axis_msgtreq* 对应于msgtreq通道

????????s_axis_msgtresp* 对应于msgtresp通道

2.1.3用户自定义端口

????????用户自定义端口是一个可选的端口，它包括两个AXI4-Stream通道，一个用于发送另一个用来接收。用户自定义端口仅仅支持SRIO Stream格式的事务。下图是用户自定义端口的示意图：

?　　在顶层模块中，变量名与接口的对应关系如下：

????????s_axis_usrtx* 对应于user_io_tx接口

????????m_axis_usrrx* 对应于user_io_rx接口

2.1.4维护端口

　维护端口使用的是AXI4-Lite接口协议，AXI4-Lite接口允许用户访问本地或远程配置空间。下图是AXI4-Lite维护端口示意图：

?????? 上图中从右到左的黑色箭头表示请求（Requests）通道，从左到右的灰色箭头表示响应（Responses）通道。每个通道有独立的ready/valid握手信号。

2.1.5状态（Status）

　　用户接口的状态信号包括deviceid和port_decode_error，定义如下表所示

信号	方向	描述
deviceid[15:0]	输出	Base DeviceID CSR（偏移地址为0x60）寄存器的值
port_decode_error	输出	此信号为高说明用户自定义端口未使能，一个不支持的事务被接收并立即丢弃。当下一个支持的事务包在任意用户接口被接收以后此信号被拉低。这个信号同步于log_clk信号

2.2 Buffer接口

开门见山的说：所有Buffer层的接口对于RapidIO顶层都是不可见的。是不是松了一口气~

????????Buffer的目的是对发送和接收的包进行缓冲。Buffer对于保证包发送和流控操作是非常有必要的，Xilinx提供了一个可配置的Buffer解决方案，可以在系统性能和资源利用率之间权衡选择。

　　发送Buffer负责把将要发出去的事务放到队列中，并对发往物理层（PHY）的包流进行管理。接收Buffer和发送Buffer的大小可以在IP核中配置为8、16或32个包的深度。发送Buffer是一个存储和转发缓冲区，它是用来降低包到包的延迟以最大化流吞吐量。发送Buffer必须保存每个包直到包被接收方成功接收，当接收方成功接收包以后，发送Buffer才会释放包来给其他包腾出空间。当流控（Flow Control）发生时，通常会有多个未发送的包滞留在发送Buffer中，发送Buffer会根据包的类型与优先级进行重新排序，然后按照响应包先发送，请求包后发送的顺序把发送Buffer中的包依次发出去。Buffer的另一个作用是处理跨时钟域的问题，当生成IP核的时候可以根据需求添加或者移除跨时钟域逻辑。对于多通道的RapidIO来说，由于物理层的时钟在start-up场景和traindown场景是动态的，所以推荐把跨时钟域逻辑加上，这样可以保证用户逻辑工作在已知的速率上。

　　接收Buffer类似于一个FIFO，它用来存储和转发接收通路上发送给逻辑层的数据。接收Buffer也包含跨时钟域逻辑，这可以保证逻辑层和物理层工作在不同的速率上，和发送Buffer一样，对于多通道RapidIO，推荐加上跨时钟域逻辑。

????????Buffer层示意图如下：

?????? 由上图可知，在Buffer层的逻辑层与物理层两侧均有两个AXI4-Stream通道，一个为发送通道，另外一个为接收通道。还有一个AXI4-Lite通道用于去配置Buffer层的配置空间。所有Buffer层的接口对于RapidIO顶层都是不可见的。

2.3 物理层接口

???????物理层（PHY）用来处理链路训练（Link Training），初始化（Initialization）和协议（Protocol），同时还包括包循环冗余校验码（CRC）与应答标识符的插入。物理层接口与高速串行收发器相连。串行收发器在IP核中被设计为一个外部的例化模块以降低用户使用模型的难度。物理层接口的示意图如下图所示：

??????? 物理层与Buffer层通过两个AXI4-Stream通道相连，同时物理层有一个通道的AXI4-Lite接口与配置结构相连，可以通过这个通道访问物理层的配置空间。物理层还通过一个串行接口（Serial Interface）与串行收发器（Serial Transceivers）相连。

2.4 寄存器空间

RapidIO的寄存器空间包含：

能力寄存器空间（CAR）

命令和状态寄存器空间（CSR）

CAR和CSR的寄存器一样都在逻辑层LOG实现。

更多寄存器空间内容请查阅《PG007》P.51

我们继续介绍重点内容HELLO包格式！

三、HELLO包格式（重点）

????????为了简化RapidIO包的构建过程，RapidIO核的事务传输接口（ireq，treq，iresp，tresp）可以配置为HELLO（Header Encoded Logical Layer Optimized）格式。这种格式把包的包头（Header）域进行标准化，而且把包头和数据在接口上分开传输，这将简化控制逻辑并且允许数据与发送边界对齐，有助于数据的管理。

3.1HELLO格式及字段定义

HELLO格式的包如下图所示：《PG007》P.76

保存，写包头数据的时候查阅~

?其中，各个字段的定义如下表所示：

字段	位置	描述
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）长度

3.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）传输的数据量小于8字节（Sub-DWORD Accesses）：

PS ：这种情况我们后文会对example design的仿真进行具体介绍。

??????????对于传输的数据量小于8字节的情况，address字段和size字段用来决定有效的字节位置（tkeep信号必须为0xff），但是仅仅能导致RapidIO包中rdsize/wrsize和wdptr为有效值的address和size值组合才是被允许的，下图是HELLO格式中address和size两个字段与有效字节位置的对应关系示意图（图中灰色部分为有效字节位置）《PG007》P.78

??????? 例如，（后文example design中的一个案例）对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）传输的数据量大于8字节（Large Accesses）：

????????对于传输的数据量大于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字节的包。所以我们发送数据的时候要注意自己拆分数据。

3.3HELLO格式传输时序图

????????HELLO格式数据的包头（Header）在用户接口的第一个有效时钟上，如果发送的事务携带数据负载，那么数据负载紧接着包头（Header）后面进行连续发送。包的Source ID和Destination ID放在tuser信号中并与包头（Header）一样，在第一个有效时钟下进行发送，发送完毕以后，tuser信号的数据被忽略。

? ?????下图是携带有数据负载HELLO格式包在用户接口上传输的时序图，这个传输有4个双字（32个字节）的数据负载，加上包头，整个传输一共花费了5个时钟周期。用户只需要把想要发送的数据按照下图的时序图送入RapidIO核的AXI4-Stream接口，RapidIO核就能把它转化为标准的RapidiO串行物理层的包发出去从而完成一次事务的交互。

基本的HELLO包传输时序图（重点掌握，会用这种就OK~）

《PG007》P.79

????????下图是一种更复杂的传输示意图。首先，有两个背靠背（back-to-back）单周期包（包不带数据负载，仅包含一个包头）。包的边界通过拉高tlast信号进行指示。在单周期包传输完毕以后，主机等待了一个时钟周期才开始发送下一个包。在发送第三个包的过程中，主机（Master）和从机（Slave）分别通过拉低tvalid和tready信号一个时钟周期来暂停数据的发送，由于第三个包的数据负载为2个双字，所以传输第三个包一共消耗了3个有效时钟，加上2个无效的时钟周期，一共消耗了5个时钟周期。

高级的HELLO包传输时序图

?3.4 AXI4-Stream协议　

????????RapidIO核事务收发接口采用的协议是AXI4-Stream协议。AXI4-Stream协议用ready/valid握手信号在主从设备之间传输信息。AXI4-Stream协议用tlast信号指示传输的最后一个数据从而确定包的边界，用tkeep字节使能信号指示数据中的有效字节，它还包括有效数据tdata信号以及用户数据tuser信号用来传输实际的包数据。

tkeep ?：规定只能为8’hff；

tvalid ：表示你的数据有效；

tdata ?：你要发送的数据（先发一个HELLO头，再发数据）

tready ：核输出，表示准备好接收你的数据了

tlast ?：表示最后一个数据

tuser ：一般发ID号，注意只在第一个时钟周期有效。

而对于我们逻辑设计而言，只需要设计这几个用户接口就OK，是不是超级简单！！！

四、SRIO Stream格式

????????因为HELLO格式比较简单，一般使用HELLO格式！所以SRIO STREAM格式没用过，放张图，有兴趣的去PG007具体研究。

?五、事务类型（重点）

开门见山的说：事务类型是重点，因为要安装事务类型组包，但是呢，保存以供查阅就就好~《PG007》P.168

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	RESPONSE no data	不带有效数据的响应包
13	4’b1000	RESPONSE with data	带有效数据的响应包
14~15	——	Reserve	无