Xilinx平台SRIO介绍（一）RapidIO协议介绍
前言
菜鸟到老鸟：会用工具；
老鸟到大佬：深入理解原理。
——FPGA大叔·沃自己硕得
汇总篇
一、RapidIO背景介绍
RapidIO是由Motorola和Mercury等公司率先倡导的一种高性能、 低引脚数、 基于数据包交换的互连体系结构，是为满足和未来高性能嵌入式系统需求而设计的一种开放式互连技术标准。RapidIO主要应用于嵌入式系统内部互连，支持芯片到芯片、板到板间的通讯，可作为嵌入式设备的背板（Backplane）连接。
RapidI0采用三层分级体系结构,该分级结的如下图所示
其中逻辑层位于最高层.定又全部协议和包的格式,它们为端点器件发起和完成事务提供必要的信息；传输层规范位于中间层,定义了RapidIO地址空间和在端点器件间传输包所需要的路由信息,物理层规范在整个分级结构的底部,包括器件级接口的细节,如包传输机制、流量控制、电气特性和低级错误管理等功能.
Rapid IO分为并行Rapid IO标准和串行Rapid IO标准，串行RapidIO是指物理层采用串行差分模拟信号传输的RapidIO标准。在Xilinx的一部分FPGA里面已经集成了GTP，GTX或GTZ等高速串行收发电路，这些是FPGA实现RapidIO高速传输的物理层基础。
二、RapidIO协议概述
2.1 包与控制符号
RapidIO操作是基于请求和响应事务的。
包是系统中端点器件间的基本通信単元。发起器件或主控器件产生一个请求事务,该事务被发送至目标器件。目标器件于是产生一个响应事务返回至发起器件来完成该次操作。 RapidIO事务被封装在包中,而包则包含确保将事务可靠传送至目标端点的所有必需的位字段。通常不会将RapidIO端点相互直接连在一起,而是通过介于其间的交换结构(fabric)连接。名词“交换结构”指的是提供系统互连的单个或多个交换器件的集合。
控制符号用于管理RapdIO物理层互连的事务流,也用于包确认、流量控制信息和维护功能。下图显示了如何在 RapidIO系统中传送事务。
上图中,系统中的发起器件(Initiator)通过产生一个请求事务(Request)开始一次操作。该请求包传送至交换结构器件(Fabric),通常是一个交换机,交换结构器件发出控制符号确认收到了该请求包,然后交换结构将该包转发至目标器件(Target),这就完成了此次操作的请求过程。目标器件(Target)完成要求的操作,产生响应事务(Response)。通过交换结构(Fabric)将承载该事务的响应包传送回发起器件(Initiator).传送时使用控制符号对每一跳(hop)进行确认。一旦响应包到达发起器件(Initiator)并得到确认，就可认为此次操作已经完成。
2.2 包格式
RapidIO包由代表3级规范体系结构的多个字段组成。下图显示了典型的请求包和响应包的格式,这些包的格式属于并行物理层包格式,串行物理层包的格式与此稍有不同。某些字段是依赖于具体的上下文的, 并不会在所有的包中出现。
请求包以物理层字段开始, S位指示这是一个包还是一个控制符号(S=0表示是一个包，S=1表示是控制符号), AckID表明交换结构器件将用控制符号来确认哪一个包。PRIO字段指示用于流量控制的包优先级。TT、目标地址( Target Address)和源地址( Source Address)字段指示传输地址的机制类型、包应被传送到的器件的地址和产生包的器件的地址。Ftype和事务(Transation)指示正被请求的事务。长度(Size)字段等于编码后事务的长度, RapidIO事务数据的有效裁荷(Payload)长度从1到256字节不等。SrcTID(源事务ID)指示事务ID, RapidIO器件在两个端点器件间最多允许有256个未完成的事务。对于存储器映射事务,跟随在srcTID后面的是器件偏移地址 (Device Offset Address ) 字段。写事务必须附带数据的有效裁荷,所有包以16位(2个字节)循环冗余校验码(CRC)结束。
响应包与请求包类似。状态(Status)字段指示是否成功完成了事务。目标TID(目标事务ID)字段的值与请求包中源事务 ID字段的值相等。下图是请求包与响应包的包格式示意图
对于用户来说，最需要关注的就是逻辑层（上图中蓝色部分）各个字段的含义，逻辑层中Ftype与Ttype(Ttype字段和上图中的Transaction字段是同一个字段，只不过叫法不同而已)两个字段唯一的确定了这个请求包的功能。下表列出了Ftype与Ttype所确定的包含义
| 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 | —— | Reserve | 无 |
| 10 | 4’bxxxx | DOORBELL | 门铃 |
| 11 | 4’bxxxx | MESSAGE | 消息 |
| 12 | —— | Reserve | 无 |
| 13 | 4’b0000 | RESPONSEno data | 不带有效数据的响应包 |
| 4’b1000 | RESPONSEwith data | 带有效数据的响应包 | |
| 14~15 | —— | Reserve | 无 |
2.3 事务格式与类型
RapidIO事务的类型大概有以下几种：
| 功能 | 事务类型 |
| I/O非一致功能 | NREAITED(读非共享存储器) |
| NWRITE、NWRITE_R、SWRITE(写非共享存储器) | |
| 原子(ATOMIC)(读-修改-写至非共享存储器) | |
| 基于端口的功能 | 门铃(DOORBELL)(产生中断) |
| 消息(MESSAGE)(对端口写) | |
| 系统支持功能 | 维护(MAINTENANCE)(读写配置、控制、状态寄存器) |
| 用户定义功能 | 对专用事务开放 |
| 高速缓存一致性功能 | 读(READ)(读全局共享高速缓存器) |
| READ_TO_DOWN(写全局共享高速缓存器) | |
| 抛弃(CASTOUT)(交出全局共享高速缓存器拥有权) | |
| IKILL(指令缓冲失效) | |
| DKILL(数据缓冲失效) | |
| 刷新(FLUSH)(返回全局共享高速缓存器至存储器) | |
| IO_READ(读非缓冲全局共享高速缓存器的副本) | |
| 操作系统支持功能 | TLBIE(TLB失效) |
| TLBSYNC(TLB强迫完成失效) |
2.4 消息传递
当数据必须被系统中的多个处理器件共享时,必须由协议维护和管理多个器件对共享数据的临时占用,许多嵌入式系统用软件机制实现该协议。如果存储器空间可被多个器件访问,可以使用锁或者信号量来保证器件间正确的访问次序。在其他情况下,处理部件可能只有访问本地存储器空间的权利,在这些“非共享”的系统中,需要一种机制把数据从一个处理器件传递到另一个器件。使用消息传递(Message Passing)信箱(Mailbox)可以实现这种机制。
RapidIO提供了一种有用的消息传递机制, RapidlO消息传递协议描述了支持信箱和门铃通信的事务。RapidIO信箱是一个端口，器件间可通过它发送消息。接收器件在消息到达后对其进行处理。RapidIO消息的长度从0到4096字节不等。一个接收器件有1~4个可寻址消息队列来捕获输人的消息。
RapidIO门铃 (Doorbell )是一种基于端口的轻量级事务,可用于带内(in-band)中断。门铃消息包括一个由软件定义的16位字段，该字段可用来在两个器件间传达多种不同意图的消息。
2.5 全局共享存储器
支持全局共享的分布式存储器系统是RapidIO协议的扩展功能之一。这意味着可以把存储器放到系统中不同的物理位置上, 可以正确地在不同处理器件间缓存。
RapidIO制定了一种基于目录的一致性解决方案来支持这种方法。使用这种方法，每个存储器控制器都有责任跟踪每个数据元素的当前副本在系统中位于什么位置，为一致域中的每个器件维护一个目录，跟踪每个器件的修改、共享、位置(MSL)等简単的一致性状态。
2.6 流量控制
流量控制是任何互连技术的重要内容。流量控制是指在任意时间互连技术采用某些规则和机制,根据这些规则和机制决定任意时间从可能获得的若干事务中选择哪一事务进行发送。流量控制的目的是使器件完成系统中的事务,避免被其他事务阻塞。基于总线的互连技术使用仲裁算法来确保器件进行恰当的转发操作,确保高优先级的事务优先于低优先级的事务得到转发。采用交换的互连技术,事务从系统的不同位置进入，从而无法使用集中式的仲裁机制。这就需要一种管理系统中的事务流的方法。RapidIO使用若干补充机制来获得系统中平稳的数据流并避免系统死锁。
2.7 串行物理层
RapidIO逻辑层的包被定义为一连串的比特，并且与物理层实现无关。这意味着RapidIO协议在串行与并行接口，铜线与光纤介质下都能正常工作。在Xilinx FPGA中已经集成了GTP，GTX或GTH等高速串行收发器，所以在FPGA实现RapidIO高速传输协议都是采用的串行物理层而并非并行物理层。串行物理层使用8B/10B编码用到的字符（K码）完成定界，利用这种方式，发送器件使用K码作为定界符，为接收器件指明包或控制符号的开始和结束。
串行RapidIO规范使用物理编码子层(PCS)和物理媒介附属子层(PMA)在发送方将包转化成串行比特流。并在接收方提取出该比特流。除了在发送前进行编码和在接收后进行解码操作，PCS层还负责空闲序列(idle sequence) 产生、通道分段(lane striping)、通道对齐(lane alignment)、以及接收方通道合并(lane destriping)的操作。PCS层使用8B/10B编码技术在链路上传送数据，8B/10B编码模块把8位数据编码转换为10位做据，编码后的数据包括原始数据和可恢复的时钟信息。PCS层还提供了一种机制，用于自动决定端口的工作模式是在单通道(1-lane)模式还是四通道(4-lane)模式。PCS层也可弥补发送方和接收方之间的时钟差。
PMA层负责逐个通道地将10位并行码组(code-group)数据串行化为串行比特流或将串行比特流并行化为10位并行码组数据。接收数据时, PMA层独立地、逐个通道地将接收到的比特流对齐到10位码组边界，然后向PCS层提供连续的10位码组流，每一通道分配一个码组流，10位码组对于PCS层以上各层是不可见的。
三、I/O逻辑操作与包格式
3.1 引言
I/O逻辑操作支持RapidIO存储空间的基本读写,它可以通过请求和响应事务对来完成。请求和响应事务对穿越 RapidIO交换结构运行, 但当事务穿越交换结构时RapidIO交换结构并不跟踪该事务。从交换结构的角度看, 请求事务和与之对应的响应事务间并没有明确的关系。虽然系统中可能存在多个中间交换器件和由此引起的多次包转发,但是从RapidlO逻辑层的角度来说，请求事务和响应事务只有一个(如果需要响应的话),中间交换器件不区分请求和响应事务,它们的作用只是转发事务到它们的最终目的地。
在 RapidIO体系结构中定义了6种基本的I/O操作, 下表给出了这6种基本的I/O操作、用来执行相应操作的事务和对操作的描述,
| 操作 | 使用的事务 | 描述 |
| 读 | NREAD、RESPONSE | 从目标器件中读数据 |
| 写 | NWRITE | 往目标器件中写数据 |
| 有响应写 | NWRITE_R、RESPONSE | 往目标器件中写数据，写完后等待目标的响应 |
| 流写 | SWRITE | 面向大数据量DMA传输优化写数据 |
| Atomic | ATOMIC、RESPONSE | 原子操作，读-修改-写，事务不能被打断 |
| 维护 | MAINTENANCE | 以RapidIO专用寄存器为目标的事务 |
3.2 请求包格式
RapidIO处理器发起一个请求包给目标器件(Target)，目标器件收到这个请求包以后给一个响应包到处理器（前提是这个请求包需要目标器件的响应），比如存储器读操作。一个典型的请求包的格式如下图所示
对于用户来说，最需要关注的就是逻辑层（上图中蓝色部分）各个字段的含义，Ftype与Ttype两个字段唯一的确定了包的类型，具体的对应关系请参考2.2节。逻辑层各个字段的含义如下表所示
| 字段 | 含义 |
| Ftype | 格式类型(Format Type)，与Ttype共同唯一的确定包的格式 |
| Ttype | 事务类型(Transaction Type)，与Ftype共同唯一的确定包的格式 |
| Wrsize/Rdsize | 此字段根据包的类型来决定是写事务数据的大小还是读事务数据的大小，这个字段配合wdptr(word pointer)字段一起使用 |
| Src TID | 包的事务ID(Transaction ID)号 |
| Extended Address | 扩展地址，这是一个可选字段，指定50-bit物理地址的高16-bit或者66-bit物理地址的高32-bit |
| Address | 29-bit的物理地址，由于RapidIO传输以一个双字(double-word)为基本单元，大多数嵌入式系统是32位的，所以一个字（word）占用4个字节，一个双字(double-word)占用8个字节，所以29-bit的物理地址指向的一个存储单元实际上是占用8个字节的，这样用29-bit的物理地址实际上可以访问4G(2^32)的内存空间 |
| Wdptr | 字指针(Word pointer),配合Wrsize/Rdsize字段来指明数据的大小以及对齐方式，详细的说明请查看RapidIO_Rev_2.2_Specification第33页 |
| Xamsbs | 扩展地址最高位(Extended address most significant bits)，把物理地址进一步扩展2位，由于29-bit的地址已经可以访问4G内存空间，在最高位扩展2位以后就可以访问16G的内存空间 |
| Data Payload | 要传输的数据 |
3.3 响应包格式
当一个RapidIO端点完成由另一个RapidIO端点发起的请求时,该端点就会发送一个响应事务。响应事务包总是以与请求事务包相同的方式被发送和路由。从广义上说,第12、13、14 和15类格式（Ftype=12表示的就是第12类格式）是响应类事务的格式。通常，第 12和14类是保留的,第15类由具体应用定义, 第13类才是主要的响应类事务。第13类包格式返回状态，数据(如果需要)和请求者的事务ID。带有“ERROR”状态或没有预期的数据裁荷的响应的RESPONSE包没有数据载荷。响应包使用第13类格式来响应除维护和无响应写之外的所有请求包。维护响应包响应维护请求。一个典型的响应包的格式如下图所示
逻辑层各个字段的含义如下表所示
| 字段 | 值 | 含义 |
| Ftype | 4’b1101 | 格式类型(Format Type)，与Ttype唯一的确定包的格式，对于一个有效的响应包来说，此字段的值固定为4’b1101，也就是16进制的d |
| Ttype | 4’b0000 | 不携带数据的响应 |
| 4’b0001~4’b0111 | 保留 | |
| 4’b1000 | 携带数据的响应 | |
| 4’b1001~4’b1111 | 保留 | |
| Status | 4’b0000 | DONE状态：表示请求事务得到了正确的响应 |
| 4’b0001~4’b0110 | 保留 | |
| 4’b0111 | ERROR状态：表示请求事务出现了不可恢复的错误，未能得到正确的响应 | |
| 4’b1000~4’b1011 | 保留 | |
| 4’b1100~4’b1111 | 用户自定义响应 | |
| Target TID | —— | 目标事务ID(Transaction ID)号 |
| Data Payload | —— | 响应包携带的数据，如果是不携带数据的响应，那么这个字段就不存在 |
3.4 常用的I/O逻辑操作事务
1、读操作（NREAD）
读操作由一个NREAD事务和一个RESPONSE事务组成，NREAD事务由请求方（Requestor）发起，目标方（Destination）正确的处理请求方发过来的响应以后会给请求方反馈正确的响应以及请求方读取的数据。整个操作的示意图如下所示
2、写操作（NWRITE）和流写操作（SWRITE）
写操作（write operations）和流写操作（streaming-write operations）分别由NWRITE和SWRITE事务组成。请求方可以用这两种事务往目标方指定的地址写入数据。NWRITE事务允许多个双字（double-word），字（word），半字（half-word）和字节（byte）作为数据负载（Data Payload）进行传输，但前提是必须对数据进行适当的补0（padded）并进行8字节边界对齐。而SWRITE事务相当于用NWRITE事务传输双字（double-word）的情况，并且SWRITE事务具有更少的头部开销（SWRITE事务的包格式中把Ttype，Rdsize/Wrsize和srcTID三个字段全部定义为了Extended Address字段的一部分，所以头部开销变少）。NWRITE事务和SWRITE事务不需要接收目标方的响应，所以当事务被目标方处理完以后并不会给发起方反馈任何信息。NWRITE事务与SWRITE事务的操作示意图如下图所示
3、带响应的写操作（NWRITE_R）
带响应的写操作（write-with-response operations）由NWRITE_R事务和RESPONSE事务组成。它的整个请求操作和NWRITE事务的请求操作完全相同，但是在目标方正确处理请求方的NWRITE_R事务以后，目标方会给请求方反馈一个响应包告诉请求方事务已经被正确的处理。这种机制可以有效的保证数据传输的稳定性。NWRITE_R事务的处理流程如下图所示
4、原子操作（Atomic Operations）
原子操作（Atomic Operations）又叫做读-修改-写操作（Read-modify-Write Operations），它是由ATOMIC事务和RESPONSE事务组成，许多协处理器单元使用该操作来执行非一致性（non-coherent）存储器的同步。它允许携带的数据量为一个字（4个字节），一个半字（2个字节）或者一个字节，其他数据量都是不被允许的。
原子操作既包含了读操作，也包含了写操作。目标方读取指定地址的数据，并把读取的数据返回给请求方，然后对数据执行相关的操作，最后在写回指定的地址。这个过程不会被任何其他的事务干扰或者打断。对数据执行的操作包括加1运算（increment），减1运算（decrement），测试和交换（test-and-swap），置1操作（set）和清0操作（clear），在这些操作中，只有测试和交换（test-and-swap），比较和交换（compare-and-swap）以及交换（swap）需要处理单元提供数据。原子操作的目标数据可以用NWRITE事务进行初始化。原子操作的整个操作示意图如下图所示
四、维护操作与包格式
第8类事务维护事务用于访问 RapidIO能力寄存器（CARs，Capability Registers）、命令和状态奇存器( CSRs，Command and Status Register) ，本地定义的寄存器（Locally-Refined Registers）以及数据结构（Data Structures）。与其他的请求格式不同,维护操作的请求和响应包格式都是第8类包格式。第8 类包不含地址字段,只含写请求和读响应的数据载荷。
WRSIZE字段规定了多双字事务数据载荷的最大长度。数据载荷的长度不能超过这个最大长度,但是如果需要的话,可以比这个最大长度小。维护读请求和维护请求都产生正确的维护响应 。
维护事务的请求包格式如下图所示
维护事务的响应包格式如下图所示
维护事务包格式中逻辑层各个字段（Hopcount字段不属于逻辑层，下表同样列出它的含义）的含义如下表所示
| 字段 | 值 | 含义 |
| Ftype | 8 | 第8类事务代表维护类事务，维护类事务中这个字段固定为8 |
| Ttype | 4’b0000 | 指定一个维护读请求 |
| 4’b0001 | 指定一个维护写请求 | |
| 4’b0010 | 指定一个维护读响应 | |
| 4’b0011 | 指定一个维护写响应 | |
| 4’b0100 | 指定一个维护写端口请求 | |
| 4’b0101~4’b1111 | 保留 | |
| Hopcount | 跳数是一个8-bit字段，用于确定维护事务的目标交换器件。RapidIO交换器件没有器件ID，跳数是可供选择的寻址交换器件机制 | |
| Config Offset | 用于读写CAR/CSR寄存器的双字偏移量 | |
| Src TID | 维护请求包的事务ID | |
| Target TID | 维护响应包的事务ID | |
| Status | 4’b0000 | DONE状态：表明请求的事务成功完成 |
| 4’b0001~4’b0110 | 保留 | |
| 4’b0111 | ERROR状态：检查到不可恢复的错误 | |
| 4’b1000~4’b1011 | 保留 | |
| 4’b1100~4’b1111 | 用户定义 |
维护操作由维护请求事务和维护响应事务组成，处理器可以通过这类事务访问CARs/CSRs等寄存器中的数据。如果发起的维护请求事务需要一个响应，那么目标方正确处理了维护请求事务以后会给请求方反馈一个维护响应包而不是由NWRITE_R事务或NREAD事务产生的正常响应包。它支持读取配置寄存器的操作执行长度是字(4字节),也可以是双字( 8字节)或设计者自已指定的双字的整数倍长,但执行长度最多不得超过64 字节。所有写配置寄存器的操作的执行长度规定与读操作相同。维护操作的示意图如下图所示
五、消息操作与包格式
5.1 引言
分布式处理系统的一般方法是使用连接到分布式存储器部件的紧耦合处理器。这些处理器可能运行在一个単独的操作系统下。例如,，一个单Linux系统可以在最多数十个处理器上有效地运行。通常一个单操作系统的任务是管理处理器组和存储器组。多数情况下，处理器可以高效地计算出通用硬件维护的一致性存储器空间。这允许处理器通过使用信号量(semaphores )、自旋锁(spin lock)和处理器间中断来解决任务的初始化和完成的通信问题。操作系统使用页保护方案集中管理存储器。这种多处理技术十分成熟，已经使用了几十年。
在其他分布式系统中,处理器和存储器的耦合度可能松一些。若干操作系统或者内核可能在同一系统中共存，每个内核负责整个系统的一小部分。这些内核可能来自不同的软件供应商，可能运行在不同的处理器体系结构上。在这些系统中使用简单的通信机制是十分有用的；内核可以使用该机制与系统内的其他内核通信。例如，运行Linux的PowerPC处理器可能与运行QNX的TigerSHARC数字信号处理器通信。对于一个给定的应用,可能没有理由在这些器件间共享存储器空间。在这种类型的系统中，需要一种在所有器件上可用的通用硬件和软件接口机制来简单、经济地完成高性能通信。在这些系统中,处理器之间通过消息传递进行通信。
在这些消息传递系统中,经常使用两种机制将命令或数据从一个器件移动到另一个器件, 第一种机制称为直接存储器访问(DMA)，第二种称为消息(Message)。这两种模型的主要差别是，DMA事务由源端操纵，而消息由目标端操纵。这意味着DMA源端不仅需要访问目标，还必须具有对目标的地址空间的可见性。消息的源端仅需访问目标，而不需要对目标地址空间的可见性。在分布式系统中，通常DMA和消息机制是结合使用的。
RapidIO体系结构包括一种可以用于消息的包传输机制。RapidIO消息模型应满足下列目标：
1、消息由一个或多个事务组成，这些事务可以通过无序的互连发送和接收。
2、发送者可以有多个正在排队等待发送的未完成的消息。
3、发送者可以在低优先级消息前发送高优先级消息，也可以为了发送一个高优先级消息而抢占低优先级消息，并在高优先级消息完成后恢复低优先级消息(基于优先级的并发性)。
4、发送者无需了解接收者的内部结构或存储器映射。
5、消息接收者控制它本身的本地地址空间。
6、如果需要，接收者可以有多个未完成的正在排队等待服务的消息。
7、如果需要，接收者可以接收多个并发的多事务（multiple-transaction）消息。
RapidIO消息传递逻辑规范定义了两种不同的包格式用于消息事务。第10类包格式用来发送非常短的16位数据载荷，第10类包也称为门铃(DOORBELL)事务，门铃事务很适合发送处理器间的中断。多事务消息用第11类包发送最多4096字节的数据载荷。下面将分别介绍两种事务,
5.2 门铃事务（DOORBELL）
第10类包格式是门铃事务格式。它没有数据载荷。门铃事务的请求包格式如下图所示
上图中Ftype字段固定为10，表示这是一个门铃事务，8位的Reserved字段应该置0，Source TID指的是请求方的事务ID， info(msb)表示的是发送信息的高8位，info(lsb)表示的是发送信息的低8位。如果信息是用数字表示的，而且长度大于8位，那么数据符合低地址存放高字节（big-endian）的格式。比特流中先到达的是高字节。门铃事务适合向处理器递送中断信息，在这种情况下，信息字段用来向接收者传递中断级别和目标信息，除此以外，还可以在处理器件间发送信号量。
一个完整的门铃操作由DOORBELL事务和RESPONSE事务(通常是DONE响应)组成。处理单元用这个操作将非常短的消息通过互连结构发送到另一个处理器部件。门铃事务包括用于保持事务信息的信息字段。该事务没有数据载荷。它的信息字段是由软件定义的，可以用子任何目的。通常，运行在处理器上的操作系统会定义门铃事务使用的信息字段的意义。收到门铃事务的处理器部件将包放进处理器部件中的门铃消息队列，该队列可以在硬件或者本地存储器中实现。一个完整的门铃操作如下图所示
5.3 消息事务
第11类包为消息事务格式包。第11类包总有数据载荷，并且数据载荷长度总是双字（64-bits或8-bytes）长度的整数倍。没有规定子双字(sub-double-word)消息，如果需要的话，可以由软件管理子双字消息。一个消息请求包的格式如下图所示
图中逻辑层各个字段的含义如下表所示
| 字段 | 值 | 含义 |
| Ftype | 11 | Ftype=11表示这是一个MESSAGE事务 |
| Msglen | 消息长度（Message Length）：指的是组成该消息的包的总数。值为0时表明该包是一个单包消息，值为15(4’b1111)时，表明这是一个由16个包组成的消息。 | |
| Ssize | 标准消息包数据大小(Stardard message packet data size)。该字段告诉消息接收者一个单独消息操作除消息中最后一个包外组成消息的所有包的数据载荷大小。这样可以防止发送者过度延长最后一个包的数据字段并允许接收者正确的将包放入本地存储器 | |
| 4’b0000~4’b1000 | 保留（Reserved） | |
| 4’b1001 | 8字节（byte） | |
| 4’b1010 | 16字节（byte） | |
| 4’b1011 | 32字节（byte） | |
| 4’b1100 | 64字节（byte） | |
| 4’b1101 | 128字节（byte） | |
| 4’b1110 | 256字节（byte） | |
| 4’b1111 | 保留（Reserved） | |
| Letter | 信件。该字段用来识别信箱（MailBox）中的一个槽（SLOT）。该字段允许发送方同时发送最多4个消息到接收方的同一个信箱中 | |
| Mbox | 信箱（MailBox）。该字段用来指定目标处理部件中的接收信箱 | |
| Msgseg | 消息段（Message Segment）。该字段用来表明该包是组成消息的包中的第几个包。值为0表明该包是消息的第一个包。值为15（4’b1111）表明该包是消息的第16个包。 | |
| Xmbox | 对于单包数据消息事务，该字段用来指明目标信箱的高四位。该字段与Msgseg占用相同的字段。Xmbox字段和mbox字段组合使用的定义如下：xmbox || mbox : mailbox number0000 00 ： mailbox 00000 01 ： mailbox 10000 10 ： mailbox 20000 11 ： mailbox 30001 00 ： mailbox 4……1111 11 ： mailbox 63 |
尽管RapidIO规范使用信箱(MailBox)、信件(Letter)和消息分段(Message Segment)之类的术语，但是这些字段在逻辑上指的是一个8位的消息标识符信息。消息标识符信息可以用来惟一的标识和管理任意两个处理部件之间最多256个不同的消息流。接收处理部件的消息传递硬件会根据该信息计算应该把事务数据存放在本地存储器的什么位置。
例如,假设接受处理部件的信箱0、信箱1、信箱2和信箱3的起始地址分别为地址0x1000、0x2000、0x3000和0x4000，处理部件接收到的消息事务带有下列字段:
A、消息长度为6个包(msglen = 4’b0110)
B、消息段是第3个包(msgseg = 4’b0011)
C、信箱为信箱2(mbox = 2’b10)
D、信件为1(letter = 2’b01)
E、标准大小为32字节(ssize = 4’b1011)
F、数据载荷为32字节(由于这不是最后一个事务, 所以数据载荷应该是32字节)
处理部件的消息传递硬件使用这些信息来决定将这部分数据消息所含32字节数据存放到本地存储器地址0x3040。
目标地址 = 信箱2基地址(Mailbox_2_base) + (消息分段x标准长度)
0x3040 = 0x3000 + (0x0002 x 0x0020)
这个简单的寻址结构使得接收处理部件很容易计算存储消息数据的目标存储结构的地址。不仅计算起来容易，而且接收者的目标存储器结构的位置对发送者也是不可见的。这允许仅在处理器部件间提供基于消息通信的安全系统研发工作。
消息的响应事务也是由第13类包产生，与NREAD事务和NWRITE_R事务响应包不同的是，消息事务的响应包中的target_info字段占用了普通响应包中的target ID字段的位置，具体的响应包格式见下图
其中消息响应包中逻辑层Ftype字段，Ttype字段，Status字段以及Data Payload字段的含义与普通响应包中各字段的含义完全相同， Target_info字段由letter，mbox和msgseg三个字段组成，这三个字段的含义与消息请求包中这三个字段的含义完全相同，这里不再赘述。
由消息和响应(一般是DONE响应)事务组成的数据消息操作如下图所示，处理部件的支持消息传递的硬件用它向另一个处理部件发送数据消息。完成一次数据消息操作最多需要16个单独的消息事务。消息事务数据载荷的大小是双字长度(8个字节)的整数倍。最大的消息操作载荷是4096字节，该载荷由16个消息事务组成，每个事务携带256字节的数据载荷。信件( letter)，信箱(mbox)和消息段(msgseg)组合在一起，惟一地标识系统中每个请求和响应部件对的消息包，与其他请求类型使用的事务 ID的作用一样。
六、总结
RapidIO的事务大致就上面几种，下图把所有的事务都放在一起以便于大家更快的查看相关的包格式与各个字段的位置。
这里有几点值得注意的是：
1、 每个包的逻辑层字段与上文所讲的各个包的逻辑层字段定义完全相同
2、 上图物理层字段的前10位所代表的字段ackID，rsvd，crf以及prio与正文中包格式的物理层字段有所出入，这是因为正文所讲解的包都是并行物理层的包格式，而上图中是串行物理层的包格式，所以物理层字段会有一点点区别，具体的内容请阅读下一篇博客。
3、 上图每个包CRC字段的后面还有一些字段是正文中包格式所没有讲到的。这里特地解释一下：由于RapidIO包的总长度大于80个字节以后，RapidIO包会对前80个字节生成一个2字节CRC码并补0使字节边界对齐。然后80字节以上的数据放在处理完毕以后的数据后面继续发送，发送完毕以后生成第二个CRC码并补0使字节边界再次对齐，其中第二个CRC校验码是第一个CRC校验码的延续。因此上图中会出现后面的那些字段。后面我会写一篇博客教大家怎么使用RapidIO核，到时候看完这种大于80字节传输的时序图就能明白这个过程了。
