2.1 SRIO IP核概述
2.1.1概述
RapidIO互连架构,与目前大多数流行的集成通信处理器、主机处理器和网络数字信号处理器兼容,是一种高性能、包交换的互连技术。它能够满足高性能嵌入式工业在系统内部互连中对可靠性、增加带宽,和更快的总线速度的需求。
RapidIO标准定义为三层:逻辑层、传输层和物理层。逻辑层定义了总体协议和包格式。它包括了RapidIO设备发起和完成事务的必要信息。传输层提供RapidIO包传输过程中的路由信息。物理层描述设备级接口细节,例如包传输机制、流控、电气特性和低级错误管理。这种划分不需要对传输层或物理层规范进行修改,就可以灵活的给逻辑层规范添加新的事务类型。
RapidIO核的设计标准来源于RapidIO Interconnect Specification rev2.2,它支持1x,2x和4x三种模式,每通道的速度支持1.25Gbaud,2.5Gboud,3.125Gboud,5.0Gboud和6.25Gboud五种。
RapidIO核分为逻辑层(Logical Layer),缓冲(Buffer)和物理层(Physical Layer)三个部分。
2.1.2 SRIO核架构
RapidIO核分为逻辑层(LOG),缓冲(BUF)和物理层(PHY)三个部分。如下图所示:
2.2接口介绍
RapidIO核把三个子核封装在一起,他提供了一个高层次,低维护的接口。
2.2.1逻辑层接口
逻辑层(LOG)被划分成几个模块来控制并解析发送和接收数据包。逻辑层(LOG)有三个接口:用户接口(User Interface),传输接口(Transport Interface)和配置接口(Configuration Interface)。
下图是逻辑层接口示意图:
用户接口包括能发起和接受包的端口。当生成IP核的时候可以配置端口的数目和事务类型,同时也能通过AXI4-Lite接口发起维护事务对本地或者远程的寄存器进行访问与配置。
传输接口包含发送和接收两个端口,它是用来连接中间的Buffer,对于RapidIO的顶层模块来说,这两个接口不可见。
配置接口也包含两个端口。其中配置主机端口(Configuration Master Port)用来读写本地配置空间。逻辑配置寄存器端口(LOG Configuration Register Port),它可以用来读写一部分逻辑层或传输层配置寄存器。
用户接口包含I/O端口集和三个可选的端口,三个可选的端口分别为消息端口(Messaging Port),维护端口(Maintenance Port)和用户自定义端口(User-Defined Port)。这些接口都在模块的顶层,每种事务类型都在指定的端口上传输。其中,任何支持的I/O事务例如NWRITEs,NWRITE_Rs,SWRITEs,NREADs和RESPONSEs(不包括维护事务的response)全部都在I/O端口上发送或者接收。消息(Message)事务能在I/O端口传输或者在消息端口传输,这取决于是否在IP核的配置选择分离I/O端口与Message端口。门铃(Doorbell)事务只能在I/O端口传输,而不能在Message端口上传输。维护事务包只能在维护端口上传输。如果事务是由用户自定义的一种不支持的类型,那么该事务就可以在用户自媒体端口上传输,如果用户自定义端口在IP核的配置中未使能,那么用户自定义的包会被丢弃。
2.2.1.1 I/O端口
I/O端口能被配置为两种类型:Condensed I/O或Initiator/Target。这两种类型可以在IP核的配置中进行选择。I/O端口的数据流协议是AXI-4Stream协议,它支持两种类型的包格式,分别是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通道发送来完成整个事务的交互过程。
在顶层模块中,变量名与通道的对应关系如下:
2.2.1.2消息端口
消息端口是一个可选的接口,消息事务既能在I/O端口发送,也能在独立的消息端口上发送。独立 的消息端口类型为Initiator/Target类型。下图是消息端口的示意图:
本地设备(Local Device)生成的请求(Requests)通过msgireq通道发送,远程设备(Remote Device)产生的响应包通过msgiresp通道接收来完成整个事务的交互过程。
远程设备(Remote Device)生成的请求(Requests)通过msgtreq通道接收,本地设备(Local Device)产生的响应包通过msgtresp通道发送来完成整个事务的交互过程。
在顶层模块中,变量名与通道的对应关系如下:
2.2.1.3用户自定义端口
用户自定义端口是一个可选的端口,它包括两个AXI4-Stream通道,一个用于发送另一个用来接收。用户自定义端口仅仅支持SRIO Stream格式的事务。下图是用户自定义端口的示意图:
在顶层模块中,变量名与通道的对应关系如下:
2.2.1.4维护端口
维护端口使用的是AXI4-Lite接口协议,AXI4-Lite接口允许用户访问本地或远程配置空间。下图是AXI4-Lite维护端口示意图:
上图中从右到左的箭头表示请求(Requests)通道,从左到右的箭头表示响应(Responses)通道。每个通道有独立的ready/valid握手信号。
2.2.1.5状态(Status)
用户接口的状态信号包括deviceid和port_decode_error,定义如下表所示
信号 | 方向 | 描述 |
deviceid[15:0] | 输出 | Base DeviceID CSR(偏移地址为0×60)寄存器的值 |
port_decode_error | 输出 | 此信号为高说明用户自定义端口未使能,一个不支持的事务被接受并立即丢弃。当下一个支持的事务包在任意用户接口被接收以后此信号被拉低。这个信号同步于log_clk信号 |
2.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层示意图如下:
由上图可知,在Buffer层的逻辑层与物理层两侧均有两个AXI4-Stream通道,一个为发送通道,另一个为接收通道。还有一个AXI4-Lite通道用于去配置Buffer层的配置空间。所有Buffer层的接口对于RapidIO顶层都是不可见的。
2.2.3物理层接口
物理层(PHY)用来处理链路训练(Link Training),初始化(Initialzation)和协议(Protocol),同时还包括包循环冗余校验码(CRC)与应答标识符的插入。物理层接口与高速串行收发器相连。串行收发器在IP核中被设计为一个外部的例化模块以降低用户使用模型的难度。物理层接口的示意图如下图所示:
物理层与Buffer层通过两个AXI4-Stream通道相连,同时物理层有一个通道的AXI4-Lite接口与配置结构相连,可以通过这个通道访问物理层的配置空间。物理层还通过一个串行接口(Serial Interface)与串行收发器(Serial Transceivers)相连。
2.2.4寄存器空间
RapidIO的寄存器空间包含:
能力寄存空间(CAR)
命令和状态寄存器空间(CSR)
CAR和CSR的寄存器一样都在逻辑层LOG实现。
2.3 HELLO包格式
为了简化RapidIO包的构建过程,RapidIO核的事务传输接口(ireq,treq,iresp,tresp)可以配置为HELLO(Header Encoded Logical Layer Optimized)格式。这种格式把包的包头(Header)域进行标准化,而且把包头和数据在接口上分开传输,这将简化控制逻辑并且允许数据与发送边界对齐,有助于数据的管理。
2.3.1 HELLO格式及字段定义
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,如果这个字段的值为0×FF,那么表示的有效数据 为256(0×FF+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)长度 |
2.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):
对于传输的数据量小于8字节的情况,address字段和size字段用来决定有效的字节位置(tkeep信号必须为0×ff),但是仅仅能导致RapidIO包中rdsize/wrsize和wdptr为有效值的address和size值组合才是被允许的,下图是HELLO格式中address和size两个字段与有效字节位置的对应关系示意图
例如,对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字节的包。所以发送数据的时候要注意拆分数据。
2.3.3 HELLO格式传输时序图
HELLO格式数据的包头(Header)在用户接口的第一个有效时钟上,如果发送的事物携带数据负载,那么数据负载紧接着包头(Header)后面进行连续发送。包的Source ID和Destination ID放在tuser信号中并与包头(Header)一样,在第一个又消失种下进行发送,发送完毕以后,tuser信号的数据被忽略。
下图是携带有数据负载HELLO格式包在用户接口上传输的时序图,这个传输有4个双字(32个字节)的数据负载,加上包头,整个传输一共花费了5个时钟周期。用户只需要把想要发送的数据按照下图的时序图送入RapidIO核的AXI4-Stream接口,RapidIO核就能把它转化成标准的RapidIO串行物理层的包发出去从而完成一次事务的交互。
基本的HELLO包传输时序图
下图是一种更复杂的传输示意图。首先,有两个背靠背(back-to-back)单周期包(包不带数据负载,仅包含一个包头)。包的边界通过拉高tlast信号进行指示。在单周期包传输完毕以后,主机等待了一个时钟周期才开始发送下一个包。在发送第三个包的过程中,主机(Master)和从机(Slave)分别通过拉低tvalid和 tready信号一个时钟周期来暂停数据的发送,由于第三个包的数据负载为2个双字,所以传输第三个包一共消耗了3个有效时钟,加上2个无效的时钟周期,一共小号了5个时钟周期。
高级的HELLO包传输时序图
2.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号,注意只在第一个时钟周期有效。
2.4 SRIO Stream格式
用户界面端口可以配置为使用SRIO Stream格式进行最大控制。在这种格式中,数据包完全按照RapidIO规范中的定义呈现,包括所有逻辑、传输层字段(加上规范定义为物理层字段的优先级)。
下图显示了在其中一个用户界面端口上使用数据的典型传输。此特定传输具有五个DWORD(32个字节)的数据有效负载。在接口上,总共需要五个周期,并在第一个周期设置适用的CRF/响应位。
下图显示了更复杂的交通流量。首先,下图中有一个单周期包,接着,主线等待一个周期连续发送连个周期的2-DWORD数据包。数据包的边界由LAST信号的断言表示。
在下图的数据包中,主服务器和从服务器都以不同的周期停止接口(分别通过取消断言TVALID和TREADY)。这个数据包有三个DWORD,因此在接口上只有三个活动周期,但由于停滞,总共需要五个时钟周期。
2.5事务类型☆
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(原子清除) | 把指定地址中的数据清零(每个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 resquest | 发起读配置,控制,状态寄存器请求 |
4’b0001 | MAINTENANCE write resquest | 发起写配置,控制,状态寄存器请求 | |
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 | —— | Reserve | 无 |