转自https://www.cnblogs.com/liujinggang/p/10072115.html
一、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）三个部分。其中逻辑层（Logical Layer）支持发起方（Initiator）和目标方（Target）同时操作；支持门铃事务（DOORBELL）和消息事务（MESSAGE），为维护事务（MAINTENANCE）设计了专用的端口；采用AXI4-Lite接口和AXI4-Stream接口，支持简单的握手机制去控制数据流；支持可编程的Source ID，支持16-bit的device IDs（可选）。缓冲层（Buffer）支持8，16和32包的独立可配置的TX和RX Buffer深度；支持独立的时钟，支持可选的发送数据流控制。物理层（Physical Layer）支持可配置的空闲序列1和空闲序列2；支持关键请求流（Critical Request Flow）；支持多播事件。
注意：上面的几个专业术语的解释都能在前几篇博客中找到解释，不明白的可以回过头去看看。
RapidIO互连架构，与目前大多数流行的集成通信处理器、主机处理器和网络数字信号处理器兼容，是一种高性能、包交换的互连技术。它能够满足高性能嵌入式工业在系统内部互连中对可靠性、增加带宽，和更快的总线速度的需求。
RapidIO标准定义为三层：逻辑层、传输层和物理层。逻辑层定义了总体协议和包格式。它包括了RapidIO设备发起和完成事务的必要信息。传输层提供了RapidIO包传输过程中的路由信息。物理层描述设备级接口细节，例如包传输机制、流控、电气特性和低级错误管理。这种划分不需要对传输层或物理层规范进行修改，就可以灵活的给逻辑层规范添加新的事务类型。
整个RapidIO核的架构如下图所示：
二、RapidIO核接口说明
RapidIO核把三个子核封装在一起，它提供了一个高层次，低维护的接口。本节介绍了RapidIO各个子核和接口的基本功能视图。RapidIO核的顶层框图如下图所示
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核的配置中未使能，那么用户自定义的包会被丢弃。
I/O端口（I/O Port）
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通道
消息端口（Messaging Port）
消息端口是一个可选的接口，消息事务既能在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通道
用户自定义端口（User-Defined Port）
用户自定义端口是一个可选的端口，它包括两个AXI4-Stream通道，一个用于发送另一个用来接收。用户自定义端口仅仅支持SRIO Stream格式的事务。下图是用户自定义端口的示意图
在顶层模块中，变量名与接口的对应关系如下：
s_axis_usrtx* 对应于user_io_tx接口
m_axis_usrrx* 对应于user_io_rx接口
维护端口（Maintenance Port）
维护端口使用的是AXI4-Lite接口协议，AXI4-Lite接口允许用户访问本地或远程配置空间。下图是AXI4-Lite维护端口示意图
上图中从右到左的黑色箭头表示请求（Requests）通道，从左到右的灰色箭头表示响应（Responses）通道。每个通道有独立的ready/valid握手信号。
状态（Status）
维用户接口的状态信号包括deviceid和port_decode_error，定义如下表所示
|
信号 |
方向 |
描述 |
|
deviceid[15:0] |
输出 |
Base DeviceID CSR（偏移地址为0x60）寄存器的值 |
|
port_decode_error |
输出 |
此信号为高说明用户自定义端口未使能，一个不支持的事务被接收并立即丢弃。当下一个支持的事务包在任意用户接口被接收以后此信号被拉低。这个信号同步于log_clk信号 |
2.2 Buffer接口
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层的接口对于RapidIO顶层都是不可见的。Buffer层示意图如下
由上图可知，在Buffer层的逻辑层与物理层两侧均有两个AXI4-Stream通道，一个为发送通道，另外一个为接收通道。还有一个AXI4-Lite通道用于去配置Buffer层的配置空间。
2.3 物理层接口
物理层（PHY）用来处理链路训练（Link Training），初始化（Initialization）和协议（Protocol），同时还包括包循环冗余校验码（CRC）与应答标识符的插入。物理层接口与高速串行收发器相连。串行收发器在IP核中被设计为一个外部的例化模块以降低用户使用模型的难度。物理层接口的示意图如下图所示
物理层与Buffer层通过两个AXI4-Stream通道相连，同时物理层有一个通道的AXI4-Lite接口与配置结构相连，可以通过这个通道访问物理层的配置空间。物理层还通过一个串行接口（Serial Interface）与串行收发器（Serial Transceivers）相连。
2.4 寄存器空间
RapidIO的寄存器空间如下表所示
能力寄存器空间（Capability Register Space）
能力寄存器空间的寄存器是只读寄存器，它们在逻辑层中实现。能力寄存器映射表如下表所示
命令和状态寄存器空间（Command and Status Register Space）
命令和状态寄存器空间的寄存器和能力寄存器一样都在逻辑层实现，命令和状态寄存器空间的映射表如下表所示
寄存器空间还包括Extended Feature Space与Implementation-defined Space两种，关于这两种寄存器空间的说明请查看pg007_srio_gen2.pdf。
三、使用RapidIO核
3.1 设计指南
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 |
不带有效数据的响应包 |
|
4’b1000 |
RESPONSE with data |
带有效数据的响应包 |
|
|
14~15 |
—— |
Reserve |
无 |
逻辑层AXI4-Stream串行RapidIO接口用法
RapidIO核事务收发接口采用的协议是AXI4-Stream协议。AXI4-Stream协议用ready/valid握手信号在主从设备之间传输信息。AXI4-Stream协议用tlast信号指示传输的最后一个数据从而确定包的边界，用tkeep字节使能信号指示数据中的有效字节，它还包括有效数据tdata信号以及用户数据tuser信号用来传输实际的包数据。
HELLO包格式（重点）
为了简化RapidIO包的构建过程，RapidIO核的事务传输接口（ireq，treq，iresp，tresp）可以配置为HELLO（Header Encoded Logical Layer Optimized）格式。这种格式把包的包头（Header）域进行标准化，而且把包头和数据在接口上分开传输，这将简化控制逻辑并且允许数据与发送边界对齐，有助于数据的管理。
HELLO格式的包如下图所示
其中，各个字段的定义如下表所示
|
字段 |
位置 |
描述 |
|
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）长度 |
HELLO格式的包中Size域的值等于传输的字节的总数减1，Size域的有效值范围为0~255，对应于实际传输的字节数量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字节。
传输的数据量小于8字节（Sub-DWORD Accesses）：
对于传输的数据量小于8字节的情况，address字段和size字段用来决定有效的字节位置（tkeep信号必须为0xff），但是仅仅能导致RapidIO包中rdsize/wrsize和wdptr为有效值的address和size值组合才是被允许的，下图是HELLO格式中address和size两个字段与有效字节位置的对应关系示意图（图中灰色部分为有效字节位置）
例如，对size=2，address=34’h1_1234_5675这两个组合来说，由于size=2，所以往address中写入的数据个数为3（size+1）个字节，而address的最低3位为5(3’b101)，通过上图可知，有效字节的位置是第7、6、5三个字节。对于size和address[2:0]值的组合不在上图中的情况都是非法的，这是应该避免的，比如，size=2， address=34’h1_1234_5673这种组合就属于非法的组合。
传输的数据量大于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字节的包。
HELLO格式数据的包头（Header）在用户接口的第一个有效时钟上，如果发送的事务携带数据负载，那么数据负载紧接着包头（Header）后面进行连续发送。包的Source ID和Destination ID放在tuser信号中并与包头（Header）一样，在第一个有效时钟下进行发送，发送完毕以后，tuser信号的数据被忽略。
下图是携带有数据负载HELLO格式包在用户接口上传输的时序图，这个传输有4个双字（32个字节）的数据负载，加上包头，整个传输一共花费了5个时钟周期。用户只需要把想要发送的数据按照下图的时序图送入RapidIO核的AXI4-Stream接口，RapidIO核就能把它转化为标准的RapidiO串行物理层的包发出去从而完成一次事务的交互。
下图是一种更复杂的传输示意图。首先，有两个背靠背（back-to-back）单周期包（包不带数据负载，仅包含一个包头）。包的边界通过拉高tlast信号进行指示。在单周期包传输完毕以后，主机等待了一个时钟周期才开始发送下一个包。在发送第三个包的过程中，主机（Master）和从机（Slave）分别通过拉低tvalid和tready信号一个时钟周期来暂停数据的发送，由于第三个包的数据负载为2个双字，所以传输第三个包一共消耗了3个有效时钟，加上2个无效的时钟周期，一共消耗了5个时钟周期。
SRIO Stream包格式
用户接口也能配置为SRIO Stream格式，在这种格式下，用户接口的包格式各个字段的定义与RapidIO手册中标准的RapidIO包中逻辑层和传输层各个字段的定义完全相同，但用户接口的包格式中还包括标准RapidIO包物理层的prio字段，整个SRIO Stream的包格式如下图所示
下图是SRIO Stream格式的包在用户接口上传输的时序图，整个传输的数据负载为5个双字，一共消耗了5个有效时钟周期，CRF/Response位在第一个有效时钟周期进行传输。
SRIO Stream格式用的不多，所以并非本文的重点，更多详细的内容请查看pg007_srio_gen2.pdf的第80页到82页。
访问配置空间
每个通过RapidIO连接的处理器单元都有能力寄存器（Capability Register，CARs）和命令状态寄存器（Command and Status Register，CSRs），可以通过访问这些寄存器去配置设备的Capability和Status等相关信息。配置寄存器的长度都为32-bits，所有的配置寄存器进行读写访问时的地址增量为4个字节，读写保留寄存器正常情况下不会导致设备进入错误状态，同理，写CARs（只读寄存器）正常情况也不会进入错误状态。
维护写操作例子
对于写事务，在发起写事务之前，写地址和写数据必须在它们各自维护端口通道上进行传输。当逻辑层接收到响应以后，维护端口会在写响应通道上返回一个状态。维护端口一次只能处理一个写事务，在响应发送完成之前，新的地址和数据不会被接收。下图是维护端口上完成两次写事务的时序图，因为地址和数据在不同的通道上，所以它们能在通道的任意时刻进行传输而不用考虑另外一个
维护读操作例子
当读地址在维护端口上进行传输后读事务被立即发起，逻辑层接收到响应以后，维护端口在读响应通道返回一个状态。维护端口一次只能处理一个读事务，在响应发送完成之前，新的地址不会被接收。下图是一个读事务的时序图
更多通过维护事务访问寄存器空间的内容请查看pg007_srio_gen2.pdf的第82页到91页。
3.2 时钟
物理层有两个时钟域，第一个是phy_clk，它是最主要的核时钟，第二个是gt_pcs_clk，它是用于串行收发接口（Serial Transceiver interface）。时钟gt_clk并未被物理层使用，而是被串行收发接口所使用。gt_pcs_clk的频率为gt_clk的一半。一般来说，phy_clk与gt_clk的关系如下：
phy_clk = （gt_clk * LW） / 4
其中LW指的是链路宽度（Link Width），所以对于操作在2x模式（二通道模式）的核来说，LW的值为2，phy_clk的频率是gt_clk频率的一半。串行收发器需要通过专用时钟引脚提供参考时钟refclk，参考时钟的频率需要在生成RapidIO核的时候进行配置，可选择的参考时钟频率取决于RapidIO核的结构与线速率。下表列出了参考时钟频率与线速率的关系
逻辑层工作在log_clk这个时钟域。为了保证最优的吞吐量，log_clk的频率应该大于或等于phy_clk的频率。下面列出了三种不同通道模式下线速率与时钟频率的关系
4x模式（4通道模式）
2x模式（2通道模式）
1x模式（1通道模式）
对于7 Series FPGAs来说，内部采用了一个MMCM从参考时钟refclk得到RapidIO核各个模块的时钟，整个时钟方案的框图如下图所示
MMCM的倍频值与分频值取决于参考时钟的频率与线速率。在4x模式（四通道模式）下，log_clk和gt_clk共享一个BUFG。在1x模式（单通道模式）下，log_clk和phy_clk共享一个BUFG（由于phy_clk的频率只有一种情况，所以不需要BUFGMUX）。除此以外，如果在RapidIO核的配置中选中了Unified Clock选项，则log_clk和phy_clk要求有相同的频率，这意味着与log_clk/cfg_clk相关的BUFG能被移除，log_clk/cfg_clk与phy_clk相连。
3.3 复位
每个时钟域都有相关联的复位信号。复位信号应该至少在各自的时钟域中保持4个时钟周期，如果RapidIO核的通道宽度减少导致phy_clk的时钟频率降低，那么复位信号仍然需要保持至少4个时钟周期。复位参考设计模块（srio_rst.v）有一个单复位输入sys_rst。这个信号同步于输入。这个模块同步复位信号到每个时钟域并对复位脉冲进行扩展以满足最小4个时钟周期的要求。
硬件复位应该被用户设计产生，当复位RapidIO核的时候必须要注意主机和从机必须同时复位以保证ackID字段对齐，推荐主机和从机的复位信号完全重叠以减少包和控制符号的丢失率。
3.4 RapidIO协议简介
RapidIO的协议已经在这个系列的前面几篇文章中做了很多介绍了，这里仅仅做一个总结。
第2类事务（FTYPE=2）为请求类事务，根据TTYPE字段的不同值，它包括NREAD事务（TTYPE=4’b0100），ATOMIC Increment事务（TTYPE=4’b1100），ATOMIC Decrement事务（TTYPE=4’b1101），ATOMIC Set事务（TTYPE=4’b1110），ATOMIC Clear事务（TTYPE=4’b1111）这几种。
第5类事务（FTYPE=5）为写类事务，根据TTYPE字段的不同值，它包括NWRITE事务（TTYPE=4’b0100），NWRITE_R事务（TTYPE=4’b0101），ATOMIC Swap事务（TTYPE=4’b1100），ATOMIC Compare-and-Swap事务（TTYPE=4’b1101），ATOMIC Test-and-Swap事务（TTYPE=4’b1110）这几种。
第6类事务（FTYPE=6）为SWRITE事务（流写事务），请求方可以利用流写事务往目标方的存储空间写入大块数据。与NWRITE相比，流写事务具备以下两个特点：1、流写事务传输数据的最小单位为双字（Double Word）；2、流写事务的包格式相对于NWRITE包格式具有更少的头部开销。
第10类事务（FTYPE=10）为DOORBELL事务（门铃事务），门铃事务不包含数据负载，它只能用来传输16-bit的信息，所以DOORBELL事务适合传输中断或者信号量。
第11类事务（FTYPE=11）为MESSAGE事务（消息事务），消息事务必须携带数据负载，完成一次数据消息操作最多需要16个单独的消息事务，其中每个消息事务携带的数据负载最大仍为256字节，所以消息操作的最大数据载荷为4096字节（16*256 Bytes）。
第13类事务（FTYPE=13）为响应类事务，根据TTYPE字段的不同值，它包括不带数据响应事务（TTYPE=4’b0000），消息响应事务（TTYPE=4’b0001）和携带数据响应事务（TTYPE=4’b1000）。
第9类事务（FTYPE=9）为Data Streaming事务，在标准的RapidIO协议中第9类事务为保留事务，所以第9类事务是一种自定义的事务。关于第9类事务的详细内容请查看pg007_srio_gen2.pdf的第106页。
四、RapidIO核配置
1、在IP Catalog中找到RapidIO
2、双击RapidIO核打开配置界面
3、选择Mode为Advanced
Component Name：IP的的名字，只能为字母，数字，下划线，其中首字符必须为字母。
Mode：IP的模式，有基本（Basic）和高级（Advanced）两种。
Link Width：链路宽度，可选值为1、2或者4，链路宽度越大，数据的传输带宽越大。
Transfer Frequency：传输频率，这个值表示的是每个串行链路的传输速率，可选值有1.25、2.5、3.125、5.0和6.25。传输频率越大，数据的传输带宽越大。
Reference Clock Frequency：参考时钟频率，可选值为125MHz或156.25MHz，它指的是外部时钟源（晶振或者锁相环芯片）送给FPGA串行收发器专用时钟引脚的时钟。
TX Buffer Depth：发送Buffer的深度，可选值为8、16或32。这个值表示的是发送Buffer中可存储的包的最大数目。
RX Buffer Depth：接收Buffer的深度，可选值为8、16或32。这个值表示的是接收Buffer中可存储的包的最大数目。
Component Device ID：这个参数是复位以后Base Device ID CSR寄存器的复位值。
Device ID Width：设备ID的宽度，收发双方的设备ID宽度应该相同，否则，由于包头的偏移可能会导致事务被错误的解释。大多数系统Device ID为8位，但是RapidIO核也提供了16位的Device ID供用户选择。
Unified Clock：如果用户设计中log_clk和phy_clk相同，那么可以选中这个选项，选中这个选项可以减少延时和资源利用率。
Transmitter Controlled：选中这个选项以后，RapidIO核会首先尝试用transmitter-controlled实现流控，但如果接收方不支持的话那么会自动切换为receiver-controlled。transmitter-controlled流控可以利用接收buffer的状态和水印最小化重试条件。receiver-controlled流控会随意的发包并使用重试协议。
Receiver Controlled：选中这个选项以后，RapidIO核仅能用receiver-controlled实现流控，在这种模式中，receiver-controlled流控会随意的发包并使用重试协议。
4、Logical Layer标签
Source （Initiator） Transaction Support：用来选择支持的发送事务类型。
Destination（Target） Transaction Support：用来选择支持的接收事务类型。
Enable Arbitration：用来使能逻辑层与输入端口之间的仲裁器。
Maintenance Transaction Support：这个选项应该保持一直使能。
Local Configuration Space Base Address：本地配置空间基地址，选中这个选项后，RapidIO会检查I/O事务的高地址位，如果地址匹配，那么会把事务发给维护端口。由于手册没有提供一种机制去关闭LCSBA，所以在这种情况下系统的行为是未定义的。
5、I/O标签
Port I/O Style：I/O接口可以配置为Condensed I/O和Initiator/Target两种类型。其中Condensed I/O接收和发送均使用一个AXI4-Stream通道。Initiator/Target接收和发送采用不同的AXI4-Stream通道。
I/O Format：I/O端口能被配置使用HELLO格式包或SRIO Stream格式包，一般情况下，强烈推荐使用HELLO格式
Messaging：用来选择消息事务的端口，可选的参数有Combined with IO和Separate Messaging Port两种。Combined with IO选项表明消息事务和I/O写事务采用相同的IO端口，Separate Messaging Port选项表明消息事务采用一个独立的端口传输，选中这个选项以后IP核会出现消息事务的AXI4-Stream通道。
Maintainance：用来选择维护端口类型，维护端口类型只能为AXI4-Lite类型。
6、Buffer层标签
Request Reordering：选中这个选项以后，发送Buffer会根据请求包的优先级重新排序。
Flow Control Options：用来选择优先级水印复位值，详细内容请查看pg007_srio_gen2.pdf
7、物理层标签
CRF Support：关键请求流（Critical Request Flow），一般不选中
Link Requests before Fatal：用来指定链路进入致命错误状态之前链路请求的个数，一般选择默认值
Software Assisted Error Recovery：RapidIO协议定义了3个CSRs用软件来辅助错误恢复。
IDLE Mode Support：空闲模式（IDLE Mode）的选择与传输速率有关，空闲序列1（IDLE1）仅仅支持每通道线速率小于5.5Gbps的情况，选择空闲序列1时，RapidIO使用的控制符号为短控制符号。空闲序列2（IDLE2）支持每通道线速率大于5.5Gbps的情况，6.25Gbps的线速率必须选择空闲序列2，空闲序列2提供了一些附加的功能，比如链路宽度，链路优先级信息以及一些用于改善均衡器性能，提高数据恢复率的随机数。当IDLE1和IDLE2均被选中时，每通道线速率仅支持小于等于5.5Gbps的情况。上一篇文章《RapidIO串行物理层的包传输过程》也介绍了空闲序列1和空闲序列2相关的内容。
8、逻辑层寄存器标签
Device Identity CAR：指定了Device ID与Vendor ID，这两个值不能修改。
Assembly Identity CAR：可通过设置这两个值唯一的确定RapidIO设备的标识符。这两个值不影响核的功能。
Assembly Information CAR：这个寄存器存储的是RapidiO子系统的版本信息，这个值不影响核的功能。
Processing Element Features CAR：选择存储器单元的主功能，默认为Memory，这个值不影响核的功能。
9、物理层寄存器标签
Extended Features Space：扩展特征空间，一般选择默认值。
Port Link Time-out Control CSR：指定链路控制符号丢失后的超时时间，最大值为0xFFFFFF，对应的超时时间约为4.5s，精确度为33%
Port Response Time-out Control CSR：指定链路包丢失后的超时时间，最大值为0xFFFFFF，对应的超时时间在3s到6s之间。
Port General Control CSR：Host选项表明RapidIO设备是主设备，这个选项不影响核的功能。Master Enable选项用来控制是否允许RapidiO核发起请求事务，如果未选中，RapidIO核只能发起响应事务而不能发起请求事务。Discovered选项表明RapidIO核能被处理器定位，这个选项不影响核的功能。
10、共享逻辑标签
当选中Include Shared Logic in Example Design选项时，MMCM、复位逻辑和GT COMMON块等共享逻辑被包含在例子设计中。当选中Include Shared Logic in Core选项时，MMCM、复位逻辑和GT COMMON块等共享逻辑被包含在IP核中。
五、总结
整个RapidIO核的介绍到此为止，文中大部分内容都是翻译的pg007_srio_gen2.pdf，由于自身水平有限，所以有些地方可能翻译的不太好，建议大家先粗略浏览对相关内容有一个大致印象，然后把不明白的地方对照pg007_srio_gen2.pdf原文做进一步理解。
整片文章的重点只有一个，就是设计指南那一节所提到的HELLO格式与HELLO格式的时序，强烈建议对照pg007_srio_gen2.pdf文档多读几遍。 事实上，在编写Verilog代码时，就是先根据事务类型组装对应的HELLO格式的包头（Header），然后按照HELLO格式的时序，在第一个有效时钟周期类把包头（Header）发出去，后面几个有效的时钟周期发送你的数据。在这个过程中，RapidIO核会自动把HELLO格式的包转化为标准的RapidIO串行物理层的包，并添加控制符号，空闲序列等必要信息发出去，接收过程则正好相反，RapidIO核接收到标准的RapidIO串行物理层的包，控制符号，空闲序列等信息后以后，会把接收的信息转化为HELLO格式的包给用户做后续处理。所以对用户来说只需要理解HELLO格式包的组成与HELLO格式的时序就可以利用RapidIO核实现数据的高速传输，而不需要关注RapidIO协议的过多细节。
最后，再来复习一下RapidIO串行物理层的包格式与控制符号来结束全文，下篇文章会教大家如何利用Xilinx官方提供的例子工程来理解请求事务与响应事务Verilog代码，并详细分析各个事务的时序细节。
RapidIO串行物理层包格式：
控制符号：
六、参考资料
1、pg007_srio_gen2，下载地址 https://china.xilinx.com/support/documentation/ip_documentation/srio_gen2/v4_0/pg007_srio_gen2.pdf
2、RapidIO™ Interconnect Specification，下载链接 https://pan.baidu.com/s/1ek-3AAhetLAcxTuOE2IyMg
标签：事务,Buffer,端口,接口,RapidIO,时钟 From： https://www.cnblogs.com/greatplans/p/16968822.html