目录
5.3 Xilinx的HELLO格式
HELLO即Header Encoded Logical Layer Optimized。这种格式可以使我们不按照srio协议格式编码组帧，而是采用xilinx提供的这种（HELLO）数据格式，这种格式更简单，更易编码，且与rapiodio协议有一定的映射关系，会在逻辑层自动完成，无需用户操心。这种格式把包的包头（Header）域进行标准化，而且把包头和数据在接口上分开传输，这将简化控制逻辑并且允许数据与发送边界对齐，有助于数据的管理。
HELLO格式的包如下图所示RapidIO协议定义了七种事务类型，每种事务类型执行不同的功能。RapidIO包格式中的FTYPE字段与TTYPE字段共同确定了事务的类型，与标准RapidIO协议不同的是，RapidIO核中定义了第9类事务（FTYPE=9）——DATA STREAMING事务，它是一类带有数据负载的写事务，标准RapidIO协议中第9类事务是保留事务。
我们可以和srio协议对比下，源协议是没有固定长度帧头的，这样编程就没有HELLO格式方便，当然我们也可以采用非HEIILO格式方式，在核配置中配置即可。
其中HELLO格式的各个字段的定义如下表所示
| 字段 |
位置 |
描述 |
| TID |
[63:56] |
包的事务ID（Transaction ID） |
| FTYPE |
[55:52] |
包的事务类 (Format Type)，可以理解为格式类型 |
| TTYPE |
[51:48] |
包的事务类型（Transaction Type），可以理解为功能类型 |
| Priority |
[46:45] |
包的优先级。请求包的优先级值为0~2，响应包的优先级值为请求包的优先级加1 |
| CRF |
[44] |
包的关键请求流标志（Critical Request Flow）与prio字段共同决定包的优先级 |
| 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）长度 |
对FTYPE和TTYPE的理解可参考下图所示，FTYPE是Format Type的缩写，是按格式分类的方式进行大类区分，TTYPE是Transaction Type的缩写，是按照功能分类，这种分类方式便于编程。
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字节。
1、传输的数据量小于8字节（Sub-DWORD Accesses）：
对于传输的数据量小于8字节的情况，address字段和size字段用来决定有效的字节位置（tkeep信号必须为0xff），但是仅仅能导致RapidIO包中rdsize/wrsize和wdptr为有效值的address和size值组合才是被允许的，下图是HELLO格式中address和size两个字段与有效字节位置的对应关系示意图（图中灰色部分为有效字节位置）
也就是说，HELLO格式的地址是以字节为单位不允许出现跨行情况的出现，例如，对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这种组合就属于非法的组合。
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字节的包。
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》的第80页到82页。
5.4 缓冲区的流控机制
注：本节内容为《PG007》P110的翻译。
串行RapidIO缓冲区设计（BUF）设计提供了可配置的缓冲区解决方案以处理时钟域交叉，重传，流控制和响应优先级。TX和RX缓冲区大小可分别配置为容纳8、16或32个数据包。串行RapidIO是一种无损协议。BUF使用重传来保证数据包的传递。当数据包从BUF传输到PHY时，它们会用确认标识符（ackID）进行标记。PHY在传输之前将ackID附加到数据包上，以供链接伙伴进行跟踪。如果链接伙伴有足够的空间容纳接收到的数据包，并且发现它没有错误，那么它将发出一个数据包接受（PA）控制符号。否则，链接伙伴会指示该数据包应重试或错误。
PHY向BUF提供phy_next_fm，指示哪个ackID应该与发送数据包相关联。当PHY接收到PA控制符号时，phy_last_ack总线会更新，指示已成功发送数据包，并且可以从发送缓冲区中删除该数据包。在链路伙伴出于某种原因不接受数据包的情况下，PHY会中断当前传输并倒回数据包计数器。为了向BUF发出倒带事件信号，PHY在更新phy_next_fm和phy_last_ack指针时会断言phy_rewind。无论是否正在传输帧，都会发生phy_rewind断言。但是，当在数据包中时，phy_rewind信号保持有效，直到BUF在接口上完成该数据包为止。不在数据包中时，phy_rewind可以保持断言至少两个周期在释放phy_rewind之后，更新phy_last_ack值将用于确定可以从缓冲区中删除哪些数据包，然后开始传输/重新传输数据包。
当发生倒带事件时，不能保证BUF以与倒带事件之前相同的顺序发出数据包。当数据包在BUF设计中累积时，它将根据优先级和事务类型对数据包进行仲裁，如下所示：
正常操作条件下，SRIO Gen2端点以与接收数据包相同的速率传输数据包，因此缓冲区中的数据包之间的仲裁不会发挥作用。但是，当发生错误或缓冲区开始填充并且流控制开始起作用时，BUF开始备份，必须仲裁多个数据包。
重要说明：在考虑系统设计问题（例如如何确定数据包的优先级）时，必须考虑仲裁机制及其对使用模型的影响。
如果系统使用SRIO Gen2端点作为启动器来生成稳定的流量，则建议对所有请求流量使用相同的优先级，以使没有一个流量饿死。但是，如果系统使用1或2个高优先级流中的数据突发，则分层优先级方法可能会有所帮助，因为较低优先级的流具有不活动状态，可以在其中完成。串行RapidIO规范[Ref 13]支持两种不同形式的流控制，即发送器（TX）和接收器（RX）。BUF支持两种形式。此外，您可以选择生成仅RX控制的缓冲区，以节省资源，这可能会占用带宽。
使用接收器控制的流量控制时，BUF依赖PHY重试协议来限制链路流量。串行RapidIO规范要求接收缓冲区为每个优先级跳转保留一个空间，为响应保留1个空间。随着接收缓冲区填满这些点，它应该开始重试表3-10中所示的较低优先级的数据包。
当优先级太低的数据包被重试时，BUF通过重新排队所有内容进行仲裁来倒回它发送的数据包。如果重试的数据包是响应数据包，则重新发出相同的数据包；否则，将重新发出该数据包。但是，数据包优先级增加了1。RapidIO协议允许端点使用此功能，以防止出现死锁情况，在死锁情况下，响应事务将备份并最终阻塞接收者队列。其余的数据包将被仲裁，如表3-10所示。
图3-22至3-26显示了重传如何影响数据包排队的示例。
图3-22显示了基本的优先级凹凸
发送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，推荐加上跨时钟域逻辑。