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的缩写，是按照功能分类，这种分类方式便于编程。
快来扫描下方二维码关注公众号，领取站内所有相关资料，所有哦~
有建议、有需求、有疑问、联系我
