CN103873448A - 一种嵌入式系统高速互联规范协议解析方法及系统 - Google Patents

Abstract

本发明公开了一种嵌入式系统高速互联规范协议解析方法及系统，克服目前完全通过软件解析RapidIO原始报文效率低下的不足，该方法包括：对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文并传递给应用程序；在应用程序收到封装报文后，为封装报文分配一个数据结构记录原始报文以及接口卡附加信息；根据接口卡附加信息解析出原始报文的时间及顺序信息；根据接口卡附加信息解析出原始报文的协议字段；根据接口卡附加信息及原始报文中字段值判断原始报文是否包含载荷数据，并在判断出所述原始报文包含载荷数据时解析出载荷数据。本发明可快速高效地解析种类繁多、长度可变的RapidIO报文。

Description

一种嵌入式系统高速互联规范协议解析方法及系统

技术领域

本发明涉及嵌入式系统高速互联规范(RapidIO)技术，尤其涉及一种嵌入式系统高速互联规范协议解析方法及系统。

背景技术

嵌入式系统高速互联规范(RapidIO)主要应用于嵌入式系统芯片和板间互联，具有协议灵活高效、便于硬件处理、打包效率高、支持多种拓扑结构和传输模式、支持极高传输速率等优点。但其报文种类繁多、长度可变，不同种类报文具有不同的协议字段，完全通过软件解析原始报文是一件极其复杂和困难的事，耗时长，效率低下。

发明内容

本发明所要解决的技术问题是克服目前完全通过软件解析RapidIO原始报文效率低下的不足。

为了解决上述技术问题，本申请提供了一种嵌入式系统高速互联规范(RapidIO)协议解析方法，包括：

对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文并传递给应用程序；所述接口卡附加信息包括所述原始报文的报文类型、输入端口信息、错误信息以及封装所述原始报文时的时间戳；

在所述应用程序收到所述封装报文后，为所述封装报文分配一个数据结构记录所述原始报文以及所述接口卡附加信息；

根据所述接口卡附加信息解析出所述原始报文的时间及顺序信息；

根据所述接口卡附加信息解析出所述原始报文的协议字段；

根据所述接口卡附加信息以及所述原始报文中字段值判断所述原始报文是否包含载荷数据，并在判断出所述原始报文包含所述载荷数据时解析出所述载荷数据。

优选地，对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文，包括：

对于控制报文，所述封转报文总长为16字节，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第4-7字节为原始报文内容，第8-15字节为所述时间戳；

对于数据报文，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第6个、第7个字节为报文总长度信息，第8-15字节为所述时间戳，从第32字节开始为原始报文内容。

优选地，根据所述接口卡附加信息解析出所述原始报文的时间及顺序信息，包括：

根据所述时间戳解析出所述原始报文与本次采集第一个原始报文的相对时间、与本次采集上一个原始报文的相对时间、参照所述应用程序本地时间的绝对时间，以及所述应用程序记录的从本次采集开始递增的报文序号。

优选地，根据所述接口卡附加信息解析出所述原始报文的协议字段，包括：

根据所述原始报文的报文类型以及所述原始报文的标识位宽字段值解析出所述原始报文的协议字段。

优选地，根据所述接口卡附加信息以及所述原始报文中字段值判断所述原始报文是否包含载荷数据以及在包含所述载荷数据时解析出所述载荷数据，包括：

根据所述原始报文的文件类型以及事务类型字段的值，判断出所述原始报文是否包含所述载荷数据；在所述原始报文包含所述载荷数据时，将所述协议字段及循环冗余校验码之间的内容解析为所述载荷数据。

本申请还提供了一种嵌入式系统高速互联规范(RapidIO)协议解析系统，包括：

封装模块，设置为对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文并传递给应用程序；所述接口卡附加信息包括所述原始报文的报文类型、输入端口信息、错误信息以及封装所述原始报文时的时间戳；

分配模块，设置为在所述应用程序收到所述封装报文后，为所述封装报文分配一个数据结构记录所述原始报文以及所述接口卡附加信息；

第一解析模块，设置为根据所述接口卡附加信息解析出所述原始报文的时间及顺序信息；

第二解析模块，设置为根据所述接口卡附加信息解析出所述原始报文的协议字段；

第三解析模块，设置为根据所述接口卡附加信息以及所述原始报文中字段值判断所述原始报文是否包含载荷数据，并在判断出原始报文包含所述载荷数据时解析出所述载荷数据。

优选地，所述封装模块配置为对于控制报文，所述封转报文总长为16字节，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第4-7字节为原始报文内容，第8-15字节为所述时间戳；并配置为对于数据报文，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第6个、第7个字节为报文总长度信息，第8-15字节为所述时间戳，从第32字节开始为原始报文内容。

优选地，所述第一解析模块配置为根据所述时间戳解析出所述原始报文与本次采集第一个原始报文的相对时间、与本次采集上一个原始报文的相对时间、参照所述应用程序本地时间的绝对时间，以及所述应用程序记录的从本次采集开始递增的报文序号。

优选地，所述第二解析模块配置为根据所述原始报文的报文类型以及所述原始报文的标识位宽字段值解析出所述原始报文的协议字段。

优选地，所述第三解析模块包括第一判断单元、第二判断单元以及解析单元，其中：

所述第一判断单元配置为根据所述原始报文的报文类型判断所述原始报文是否为数据报文；

所述第二判断单元配置为在所述第一判断单元判断出所述原始报文为数据报文时，根据所述原始报文的文件类型以及事务类型字段的值，判断所述原始报文是否包含所述载荷数据；

所述解析单元配置为在所述判断单元判断出所述原始报文包含所述载荷数据时，将所述协议字段及循环冗余校验码之间的内容解析为所述载荷数据。

与现有技术相比，本申请的实施例可以快速高效地解析种类繁多、长度可变的RapidIO报文，克服了目前完全通过软件解析RapidIO原始报文效率低下的不足。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1为RapidIO数据报文结构示意图。

图2为控制报文除头部特殊编码字节外另外3字节的定义示意图。

图3为本申请实施例的嵌入式系统高速互联规范协议解析方法的流程示意图。

图4为本申请实施例Ftype为5的报文确定载荷数据位置的示意图。

图5为本申请实施例的嵌入式系统高速互联规范协议解析系统的流程示意图。

具体实施方式

以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程能充分理解并据以实施。本发明实施例以及实施例中的各个特征在不相冲突前提下的相互结合，均在本发明的保护范围之内。

另外，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

与OSI互联模型类似，RapidIO也采用分层定义。

RapidIO协议分为三层：逻辑层、传输层和物理层。逻辑层定义了操作协议和包格式，传输层定义了包交换、路由和寻址机制，物理层定义了电气特性、链路控制和纠错重传等。

像以太网一样，RapidIO也是基于包交换的互连技术。不同于以太网的是，其报文分为数据报文和控制报文，各种类型数据报文长度不定，而控制报文固定为4个字节，其可位于数据报文头部、尾部以及中间(称为带内)，也可独立存在(称为带外)。

如图1所示，RapidIO数据报文主要由包头、可选的载荷数据和16位循环冗余校验码(CRC)组成。包头的长度因为报文类型不同可能是十几到二十几个字节。每个数据报文的载荷数据长度不超过256字节，这有利于减少传输时延，简化硬件实现。图中的结构加上头部、尾部各4字节的带内控制报文，组成了一个完整的链路传输帧结构。

控制报文也称为系统控制符号，其首个接收的字节以特殊编码(1c、7c)表示，用于标识数据包的开始、结束及用于流控、表示链路状态等。

图2显示了控制报文除头部特殊编码字节外另外3字节的定义，其接收位顺序自左向右，依次分为stype0、parameter0、parameter1、stype1、cmd以及CRC字段。

数据报文物理层、传输层以及逻辑层，每层都包括若干协议字段。有些报文类型还包括应用数据。数据报文整个帧结构还包括帧头、帧尾各4字节的标识(均属于一种带内控制报文)。鉴于几方面原因，数据报文长度不固定，部分协议字段及应用数据在整个报文中的位置也可变。

对于物理层：从报文头部开始依次为响应ID(AckID)、保留位(Reserved)、关键请求流(CRF)以及优先权(Priority)字段，这些字段在报文中位置固定。CRC为校验字段，位于报文尾部，在报文中位置不固定。

对于传输层：tt字段在报文中位置固定，其值为0或1，指示目标器件ID(destinationID)、源器件ID(sourceID)在报文中各占8位或16位，由此决定了destinationID、sourceID字段在报文中宽度、位置可变。

对于逻辑层：Ftype字段指示事务格式类型，其在报文中位置固定。Ftype字段是数据报文逻辑层包括的一种字段，所有数据报文都有，其在所有数据报文中位置相同，均占用整个帧结构按接收顺序第6个字节低4位(接收首个字节为第1个字节)。因tt字段的影响，位于destinationID、sourceID字段后面的逻辑层其他所有字段在报文中位置可变。除Ftype外，逻辑层所有其他字段只在一部分Ftype类型报文中存在，如Ftype等于2、5、13、8的报文才有事务类型(Ttype)字段，而其中Ftype等于2、5的报文才有事务数据长度编码(rd/wrsize)、源事务ID(srcTID)、扩展地址(extended addr)、基地址(Address)、字指针(wdptr)、扩展地址最高位(xamsbs)字段。而extended addr字段视现场情况可能为0或16或32位宽，由此决定了位于其后的Address、wdptr、xamsbs字段位置的变化。

如图3所示，本申请实施例的嵌入式系统高速互联规范(RapidIO)协议解析方法，主要包括如下内容。

S310，在串行RapidIO采集接口卡与应用程序之间，对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文传递给应用程序。其中接口卡附加信息包括原始报文的报文类型、输入端口信息、错误信息以及封装原始报文时的时间戳等等。

S320，在应用程序收到封装报文后，为封装报文分配一个数据结构。

S330，利用数据结构记录原始报文以及接口卡附加信息。

S340，根据接口卡附加信息解析出原始报文的时间及顺序信息并记录到数据结构中。

S350，根据接口卡附加信息解析出原始报文的协议字段。

S360，根据接口卡附加信息以及原始报文中字段值判断原始报文是否包含载荷数据，并在判断出原始报文包含载荷数据时解析出载荷数据。

本申请的实施例中，原始报文的时间及顺序信息主要包括根据时间戳解析得到的S310中所封装的原始报文与本次采集第一个原始报文的相对时间、与本次采集上一个原始报文的相对时间、参照应用程序本地时间的绝对时间，以及应用程序记录的原始报文从本次采集开始递增的报文序号。

本申请的实施例中，根据原始报文的报文类型及原始报文中的标识(id)位宽字段值解析出原始报文的协议字段。

本申请的实施例中，根据原始报文的报文类型判断原始报文是否为数据报文；在判断出原始报文为数据报文时，根据原始报文的文件类型以及事务类型字段的值，确定原始报文是否包含载荷数据；在原始报文包含载荷数据时，将协议字段及循环冗余校验码之间的内容解析为载荷数据。

RapidIO协议解析可应用在在线分析、协议测试、故障注入等一系列应用系统中，这些系统硬件上均要求至少一块串行RapidIO采集接口卡。该接口卡可提供2个以上RapidIO串行链路接口，采用输入端口信息来进行区分，用于连接被测RapidIO设备，其可以检测到任一输入链路上的RapidIO报文，并通过定义好的接口将报文发送给应用程序，协议解析即可对其进行进一步处理。

报文类型、错误信息由采集接口卡解析原始报文得到，输入端口信息标识报文由接口卡哪个端口输入。其中，时间戳为相对值，可取开机以来某个时钟连续计数。

对数据报文，包括包头各协议层、可能包含的载荷数据、CRC校验及头、尾各4字节带内控制结构。对独立的带外控制报文，包括头部的“1C”字节共4字节。

该内部接口要求接口卡在收到报文后经由驱动程序向应用程序发送前再进行如下形式的封装。

控制报文

数据报文

如上，控制报文封转后总长为16字节，原始数据报文长度可变，封转后总长也可变。

应用程序收到封装报文，检查出首字节(第0字节)是0x55，由此确认是封转报文。如果封转报文的第1字节为2，则封转报文是控制报文，收16字节即完成该控制报文，第4-7字节为原始报文内容。如果封转报文的第1字节是1，则封转报文是数据报文，此时第6个、第7个字节(分别为16位长度的高、低字节)表示封装报文总长度，由此可知该报文需要收多少字节，从第32字节开始为原始报文内容。

以上两种报文中，第1字节为报文类型，第2字节为错误信息，第3字节为端口信息，第8-15字节为接口卡所附加的时间戳，单位可精确到纳秒(ns)。两种报文均32位对齐以保证运行效率。

预定义数据

控制报文中各字段位置和宽度都是固定的，数据报文中各协议层字段中除扩展地址(extended addr)以后字段受实际扩展地址宽度影响外，在确定tt字段后，其他字段位置也就确定了(其中有些字段位置固定，其他字段位置在tt决定的ID位宽未知时有两种可能)。

在此基础上定义数组如下

RIO_PARAMETER s_rioPara[]＝

{

{RIO_FRAMETYPE_PKT，0|0x80000000，″自定义参数″，0，0，0，0，0，0，}，

{RIO_FRAMETYPE_PKT，1，″物理层-AckID，5b″，31，5，1，31，5，1，}，

{RIO_FRAMETYPE_PKT，2，″物理层-Reserved，2b″，26，2，1，26，2，1，}，

{RIO_FRAMETYPE_PKT，3，″物理层-CRF，1b″，24，1，1，24，1，1，}，

{RIO_FAMETYPE_PKT，4，″物理层-Priority，2b″，23，2，1，23，2，1，}，

{RIO_FRAMETYPE_PKT，5，″传输层-TT，ID宽度，2b″，21，2，1，21，2，1，}，

{RIO_FRAMETYPE_PKT，6，″传输层-源ID，8b/16b″，7，8，1，31，16，2，}，

{RIO_FRAMETYPE_PKT，7，″传输层-目的ID，8b/16b″，15，8，1，15，16，1，}，

{RIO_FRAMETYPE_PKT，8，″逻辑层-FType，4b″，19，4，1，19，4，1，}，

{RIO_FRAMETYPE_PKT，9，″逻辑层-TType，4b″，31，4，2，15，4，2，}，

{RIO_FRAMETYPE_PKT，10，″逻辑层-rd/wrSize，4b″，27，4，2，11，4，2，}，

{RIO_FRAMETYPE_PKT，11，″逻辑层-srcTID，8b″，23，8，2，7，8，2，}，

{RIO_FRAMETYPE_PKT，12，″逻辑层-TargetTID，8b″，23，8，2，7，8，2，}，

{RIO_FRAMETYPE_PKT，13，″逻辑层-Status，4b″，27，4，2，11，4，2，}，

{RIO_FRAMETYPE_PKT，14，″逻辑层-Msglen，4b″，31，4，2，15，4，2，}，

{RIO_FRAMETYPE_PKT，15，″逻辑层-Ssize，4b″，27，4，2，11，4，2，}，

{RIO_FRAMETYPE_PKT，16，″逻辑层-Letter，2b″，23，2，2，7，2，2，}，

{RIO_FRAMETYPE_PKT，17，″逻辑层-Mbox，2b″，21，2，2，5，2，2，}，

{RIO_FRAMETYPE_PKT，18，″逻辑层-Msgseg，4b″，19，4，2，3，4，2，}，

{RIO_FRAMETYPE_PKT，19，″逻辑层-InfoMsb，8b″，15，8，2，31，8，3，}，

{RIO_FRAMETYPE_PKT，20，″逻辑层-InfoLsb，8b″，7，8，2，23，8，3，}，

{RIO_FRAMETYPE_PKT，21，″逻辑层-Hopcount，8b″，15，8，2，31，8，3，}，

{RIO_FRAMETYPE_PKT，22，″逻辑层-Xon_Xoff，1b″，31，1，2，15，1，2，}，

{RIO_FRAMETYPE_PKT，23，″逻辑层-FlowID，7b″，23，7，2，7，7，2，}，

{RIO_FRAMETYPE_PKT，24，″逻辑层-Soc，1b″，16，1，2，0，1，2，}，

{RIO_FRAMETYPE_CTL，32|0x80000000，″自定义参数″，0，0，0，0，0，0，}，

{RIO_FRAMETYPE_CTL，33，″物理层-stype0，3b″，23，3，0，23，3，0，}，

{RIO_FRAMETYPE_CTL，34，″物理层-parameter0，5b″，20，5，0，20，5，0，}，

{RIO_FRAMETYPE_CTL，35，″物理层-parameter1，5b″，15，5，0，15，5，0，}，

{RIO_FRAMETYPE_CTL，36，″物理层-stype1，3b″，10，3，0，10，3，0，}，

{RIO_FRAMETYPE_CTL，37，″物理层-cmd，3b″，7，3，0，7，3，0，}，

{RIO_FRAMETYPE_CTL，38，″物理层-CRC，5b″，4，5，0，4，5，0，}，{0，0，″\0″，0，0}，

}；

RapidIO报文接收顺序先高位后低位。

数据报文各协议层字段定义：1、ackid字段位置固定，位置在原始报文接收第1个32位字31-27位共5位(第0个字为头部带内控制结构)。2、Reserved字段位置固定，位置在原始报文接收第1个32位字26-25位共2位。3、CRF字段位置固定，位置在原始报文接收第1个32位字24位共1位。4、Priority字段位置固定，位置在原始报文接收第1个32位字23-22位共2位。5、TT字段位置固定，位置在原始报文接收第1个32位字21-20位共2位。6、源ID字段在id位宽为8时位置在第1个32位字7-0位共8位，在id位宽为16时位置在第2个32位字31-16位共16位。7、目的ID字段在id位宽为8时位置在第1个32位字15-8位共8位，在id位宽为16时位置在第1个32位字15-0位共16位。8、FType字段位置固定，在第1个32位字19-16位共4位。9、TType字段在id位宽为8时位置在第2个32位字31-28位共4位，在id位宽为16时位置在第2个32位字15-12位共4位。10、rd/wrSize字段在id位宽为8时位置在第2个32位字27-24位共4位，在id位宽为16时位置在第2个32位字11-8位共4位。11、srcTID字段在id位宽为8时位置在第2个32位字23-16位共8位，在id位宽为16时位置在第2个32位字7-0位共8位。12、TargetTID字段位置同srcTID字段。13、Status字段在id位宽为8时位置在第2个32位字27-24位共4位，在id位宽为16时位置在第2个32位字11-8位共4位。14、Msglen字段在id位宽为8时位置在第2个32位字31-28位共4位，在id位宽为16时位置在第2个32位字15-12位共4位。15、Ssize字段位置同Status字段。16、Letter字段在id位宽为8时位置在第2个32位字23-22位共2位，在id位宽为16时位置在第2个32位字7-6位共2位。17、Mbox字段在id位宽为8时位置在第2个32位字21-20位共2位，在id位宽为16时位置在第2个32位字5-4位共2位。18、Msgseg字段在id位宽为8时位置在第2个32位字19-16位共4位，在id位宽为16时位置在第2个32位字3-0位共4位。19、InfoMsb字段在id位宽为8时位置在第2个32位字15-8位共8位，在id位宽为16时位置在第3个32位字31-24位共8位。20、InfoLsb字段在id位宽为8时位置在第2个32位字7-0位共8位，在id位宽为16时位置在第3个32位字23-16位共8位。21、Hopcount字段在id位宽为8时位置在第2个32位字15-7位共8位，在id位宽为16时位置在第3个32位字31-24位共8位。22、Xon_Xoff字段在id位宽为8时位置在第2个32位字31位共1位，在id位宽为16时位置在第2个32位字15位共1位。23、FlowID字段在id位宽为8时位置在第2个32位字23-17位共7位，在id位宽为16时位置在第2个32位字7-1位共7位。24、Soc字段在id位宽为8时位置在第2个32位字16位共1位，在id位宽为16时位置在第2个32位字0位共1位。

控制报文各协议层字段定义：1、stype0字段位置固定，位置在原始报文接收第0个32位字23-21位共3位。2、parameter0字段位置固定，位置在原始报文接收第0个32位字20-16位共5位。3、parameter1字段位置固定，位置在原始报文接收第0个32位字15-11位共5位。4、stype1字段位置固定，位置在原始报文接收第0个32位字10-8位共3位。5、cmd字段位置固定，位置在原始报文接收第0个32位字7-5位共3位。6、CRC字段位置固定，位置在原始报文接收第0个32位字4-0位共5位。

该数组数据在解析报文时会用到。

在应用程序中可以定义一个结构，其成员记录原始报文以及原始报文的报文类型、输入端口信息、错误信息以及封装原始报文时的时间戳(即步骤S310中的时间戳)，并记录根据时间戳解析得到的与本次采集第一个原始报文的相对时间、该原始报文与本次采集上一个原始报文的相对时间、该原始报文参照应用程序本地时间的绝对时间，还记录应用程序记录的该原始报文从本次采集开始递增的报文序号。

每接收一个封装报文，就分配一个数据结构并对其成员进行设置。对数据报文可以另分配一块内存保存原始报文部分，在该结构中用一成员记录这块内存地址。这样在对该报文解析时，只要读取该结构的成员即可获取相应的信息。

可以根据时间戳解析计算出原始报文之间的相对时间及参照本地时间的该原始报文的绝对时间。其中与本次采集第一个原始报文的相对时间以及与本次采集上一个原始报文的相对时间直接由时间戳计算得到，绝对时间由时间戳参照应用程序本地时间解析得到。

以下介绍如何对报文时间、协议字段、载荷数据进行解析。

RapidIO协议解析可以多种格式显示报文时间，比如与第一个报文时间间隔格式、与前一报文时间间隔格式、原始格式或者绝对时间格式。

其中与第一个报文时间间隔格式以及与前一报文时间间隔格式在创建报文结构时已经计算并设置，直接格式化输出即可。原始格式可以直接从报文结构中记录的接口卡上传的原始时间戳输出即可。本次采集收到第一个报文时，用本机本地当前时间(秒数)减去原始时间戳，可以得到一个时间差，每个接收报文原始时间戳加上该时间差，即得到该报文本地绝对时间，该时间也记录到该报文结构中，可以显示出来。

给定原始报文内容，指定是控制报文还是数据报文以及id位宽是8位还是16位，RapidIO协议解析即可计算出上面s_rioPara数组中列出的任一协议字段的值，RapidIO协议解析根据给出的字段名在s_rioPara数组中查找到相应的元素，再依据id位宽可知道该字段在当前报文中确切的位置：哪个字的第几位到第几位共多少位，经过对这个字进行移位等操作即可得到该字段值。

对于包含扩展地址字段的报文类型，可以根据当前设定值(0/16/32位)来由原始报文解析出扩展地址及位于其后其他字段的值。

给定某个字段，协议解析可以以在某几个字节中连续位的形式显示其二进制位，这种方式显示也便于相邻字段之间比较。

有些数据报文可以包含载荷数据或有效载荷(payload)，如Ftype为5、9、6的报文总是包含载荷数据，Ftype为8、13的报文有些类型有载荷数据有些没有载荷数据。不同Ftype的报文其逻辑层字段差异很大，不过总能通过报文结构及解析某些字段知道载荷数据的长度及起始位置(如果该报文有载荷)。

所有数据报文除头、尾各4位字节的带内控制结构外，按接收顺序从左到右依次为所有协议字段、载荷数据(可选)、CRC(16位)以及pad(补丁，16位，可选，如果需要可以给数据报文打16位全为0的补丁，结果是整个报文长度32位对齐)。

如果协议字段+载荷数据+CRC的总宽度32位字边界对齐，则没有pad，否则要附加16位的pad使整个报文能够对齐(协议保证了附加前总宽度至少是16位对齐)。而如果有载荷数据其一定位于协议字段和CRC之间。协议字段宽度在解析出tt字段的值及预知扩展地址宽度(有些报文中有此字段)后即可确定，这时就知道了整个载荷数据在报文中的起始位置。在确定了CRC在报文中确切位置后，就可以知道前面整个载荷数据区域的结束位置。

因为可能存在pad的原因，CRC在报文中可能位于最后16位也可能是这最后16位之前，只有知道了整个报文内容加上16位CRC是否32位对齐，才能推算出CRC在报文中的确切位置，为此除需要知道协议字段总的宽度，还要知道报文中整个载荷数据的宽度。

所有包含载荷数据的报文可以分为两类，一类报文中整个载荷数据宽度总是64位(双字)的整数倍，其自身本来就是32位对齐的，其宽度算不算在整个报文内容内都没影响，对这类报文只要计算所有协议字段+16位CRC是否32位对齐即可知道整个报文有无pad，大多数有载荷数据的报文都属于这一类。另一类报文整个载荷数据宽度总是16位(半字)的整数倍，其是奇数还是偶数倍对整个报文内容宽度影响不同，这时需要计算整个报文内容+CRC的宽度来确定整个报文有无pad。

可按以下步骤确定实际载荷数据位置：解析得到报文Ftype(文件类型)、Ttype(事务类型)字段的值，由此可知该报文是否包含载荷数据。

解析得到报文tt(器件地址宽度)字段值，由此知道destinationID、sourceID字段宽度，如果该类型(Ftype类型)的报文包含扩展地址字段，则取软件设置值。在此基础上，依据该类型报文定义即可计算出报文头部全部协议层字段的宽度，根据报文头部全部协议层字段的宽度确定整个载荷数据在报文中的起始位置。

如果属于以上介绍的第一类报文，计算所有协议字段+16位CRC是16位的多少倍，是偶数倍则整个报文最后16位即CRC，否则这16位之前的16位为CRC。如果是第二类，解析某些协议字段可知整个载荷数据宽度是16位的奇数还是偶数倍，计算整个报文内容+CRC的宽度是16位的奇数还是偶数倍就可以确定CRC的位置。这时也就能够确定整个载荷数据的结束位置。

对有些报文类型，整个载荷数据就是实际的载荷数据，对另外一些报文类型，还需要解析某些字段来确定实际的载荷数据在整个载荷数据中的起始字节偏移和结束字节偏移(由数据大小或是否在结尾有pad来决定)。整个载荷数据即为报文的数据部分；实际载荷数据即为应用程序实际传送的、真正使用的数据，其可能只占整个载荷数据中部分区域，也可能占整个载荷数据的全部区域。

下面以如图4所示的Ftype为5的报文为例介绍如何确定载荷数据位置。如图4所示，Ftype为5的完整报文结构中包含扩展地址extended addr字段(视系统情况可能为0、16、32位)，整个载荷数据区域data宽度总是64位(双字)整数倍，属于以上第一类，rdsize/wrsize字段和wdptr字段的值共同决定了实际载荷数据字节数和其在整个载荷数据中起始字节偏移。

假设某个报文Ftype＝5，tt＝1，wrsize＝6，wdptr＝0，RapidIO协议解析设置当前系统使用16位扩展地址，结构如上图示意的整个报文长度为24字节，下面以此为例说明。

确定CRC位置。Ftype＝5的报文属于以上第一类即整个载荷数据宽度是64位整数倍，只需考虑所有协议字段宽度即可。所有协议字段宽度＝2(ackid-＞ftype两字节)+4(tt为1故器件id为16位宽，目标id和源id共4字节)+2(ttype-＞srctid两字节)+2(扩展地址16位)+4(其他地址字段共4字节)＝14，协议字段+CRC宽度＝14+2＝16字节，可以32位对齐，故CRC为报文中最后两个字节，即其首字节偏移在长度为24字节的报文中为22。

确定整个载荷数据。以上已知所有协议字段宽度为14字节，紧随其后整个载荷数据在长度为24字节的报文中首字节偏移为14，CRC起始字节为22，故整个载荷数据字节偏移从14到21。

确定实际载荷数据。以上报文字段wrsize＝6，wdptr＝0，按照协议文档定义可知共有2个字节实际数据，其首字节在整个载荷数据中字节偏移为2。

如图5所示，本申请实施例的嵌入式系统高速互联规范(RapidIO)协议解析系统主要包括封装模块510、分配模块520、第一解析模块530、第二解析模块540以及第三解析模块550。

封装模块510，设置为对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文并传递给应用程序；接口卡附加信息包括原始报文的报文类型、输入端口信息、错误信息以及封装原始报文时的时间戳。

分配模块520，与封装模块510相连，设置为在应用程序收到封装报文后，为封装报文分配一个数据结构记录原始报文以及接口卡附加信息。

第一解析模块530，与分配模块520相连，设置为根据接口卡附加信息解析出原始报文的时间及顺序信息。

第二解析模块540，与分配模块520相连，设置为根据接口卡附加信息解析出原始报文的协议字段。

第三解析模块550，与分配模块520相连，设置为根据接口卡附加信息以及原始报文中字段值判断原始报文是否包含载荷数据，并在判断出原始报文包含载荷数据时解析出载荷数据。

上述封装模块510配置为对于控制报文，封转报文总长为16字节，封转报文的第1字节为报文类型，第2字节为错误信息，第3字节为输入端口信息，第4-7字节为原始报文内容，第8-15字节为时间戳；并配置为对于数据报文，封转报文的第1字节为报文类型，第2字节为错误信息，第3字节为输入端口信息，第6个、第7个字节为报文总长度信息，第8-15字节为时间戳，从第32字节开始为原始报文内容。

上述第一解析模块530配置为根据时间戳解析出原始报文与本次采集第一个原始报文的相对时间、与本次采集上一个原始报文的相对时间、参照应用程序本地时间的绝对时间，以及应用程序记录的从本次采集开始递增的报文序号。

上述第二解析模块540配置为根据原始报文的报文类型以及原始报文的标识位宽字段值解析出原始报文的协议字段。

如图5所示，上述第三解析模块550包括第一判断单元551、第二判断单元552以及解析单元553。其中，第一判断单元551与分配模块520相连，配置为根据原始报文的报文类型判断原始报文是否为数据报文；第二判断单元552与第一判断单元551相连，配置为在原始报文为数据报文时，根据原始报文的文件类型以及事务类型字段的值，判断原始报文是否包含载荷数据；解析单元553与第二判断单元552相连，配置为在第二判断单元552判断出原始报文包含载荷数据时，将协议字段及循环冗余校验码之间的内容解析为载荷数据。

本领域的技术人员应该明白，上述的本发明实施例所提供的系统的各组成部分，以及方法中的各步骤，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上。可选地，它们可以用计算装置可执行的程序代码来实现。从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

虽然本发明所揭露的实施方式如上，但所述的内容仅为便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (10)

1.一种嵌入式系统高速互联规范(RapidIO)协议解析方法，包括：

对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文并传递给应用程序；所述接口卡附加信息包括所述原始报文的报文类型、输入端口信息、错误信息以及封装所述原始报文时的时间戳；

在所述应用程序收到所述封装报文后，为所述封装报文分配一个数据结构记录所述原始报文以及所述接口卡附加信息；

根据所述接口卡附加信息解析出所述原始报文的时间及顺序信息；

根据所述接口卡附加信息解析出所述原始报文的协议字段；

根据所述接口卡附加信息以及所述原始报文中字段值判断所述原始报文是否包含载荷数据，并在判断出所述原始报文包含所述载荷数据时解析出所述载荷数据。

2.根据权利要求1所述的方法，其中，对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文，包括：

对于控制报文，所述封转报文总长为16字节，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第4-7字节为原始报文内容，第8-15字节为所述时间戳；

对于数据报文，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第6个、第7个字节为报文总长度信息，第8-15字节为所述时间戳，从第32字节开始为原始报文内容。

3.根据权利要求1所述的方法，其中，根据所述接口卡附加信息解析出所述原始报文的时间及顺序信息，包括：

根据所述时间戳解析出所述原始报文与本次采集第一个原始报文的相对时间、与本次采集上一个原始报文的相对时间、参照所述应用程序本地时间的绝对时间，以及所述应用程序记录的从本次采集开始递增的报文序号。

4.根据权利要求1所述的方法，其中，根据所述接口卡附加信息解析出所述原始报文的协议字段，包括：

根据所述原始报文的报文类型以及所述原始报文的标识位宽字段值解析出所述原始报文的协议字段。

5.根据权利要求1所述的方法，其中，根据所述接口卡附加信息以及所述原始报文中字段值判断所述原始报文是否包含载荷数据，并在判断出所述原始报文包含所述载荷数据时解析出所述载荷数据，包括：

根据所述原始报文的报文类型判断所述原始报文是否为数据报文；

在所述原始报文为数据报文时，根据所述原始报文的文件类型以及事务类型字段的值，判断出所述原始报文是否包含所述载荷数据；

在所述原始报文包含所述载荷数据时，将所述协议字段及循环冗余校验码之间的内容解析为所述载荷数据。

6.一种嵌入式系统高速互联规范(RapidIO)协议解析系统，包括：

封装模块，设置为对串行RapidIO采集接口卡采集到的原始报文以及接口卡附加信息进行封装，获得封装报文并传递给应用程序；所述接口卡附加信息包括所述原始报文的报文类型、输入端口信息、错误信息以及封装所述原始报文时的时间戳；

分配模块，设置为在所述应用程序收到所述封装报文后，为所述封装报文分配一个数据结构记录所述原始报文以及所述接口卡附加信息；

第一解析模块，设置为根据所述接口卡附加信息解析出所述原始报文的时间及顺序信息；

第二解析模块，设置为根据所述接口卡附加信息解析出所述原始报文的协议字段；

第三解析模块，设置为根据所述接口卡附加信息以及所述原始报文中字段值判断所述原始报文是否包含载荷数据，并在判断出所述原始报文包含所述载荷数据时解析出所述载荷数据。

7.根据权利要求6所述的系统，其中：

所述封装模块配置为对于控制报文，所述封转报文总长为16字节，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第4-7字节为原始报文内容，第8-15字节为所述时间戳；并配置为对于数据报文，所述封转报文的第1字节为所述报文类型，第2字节为所述错误信息，第3字节为所述输入端口信息，第6个、第7个字节为报文总长度信息，第8-15字节为所述时间戳，从第32字节开始为原始报文内容。

8.根据权利要求6所述的系统，其中：

所述第一解析模块配置为根据所述时间戳解析出所述原始报文与本次采集第一个原始报文的相对时间、与本次采集上一个原始报文的相对时间、参照所述应用程序本地时间的绝对时间，以及所述应用程序记录的从本次采集开始递增的报文序号。

9.根据权利要求6所述的系统，其中：

所述第二解析模块配置为根据所述原始报文的报文类型以及所述原始报文的标识位宽字段值解析出所述原始报文的协议字段。

10.根据权利要求6所述的系统，其中，所述第三解析模块包括第一判断单元、第二判断单元以及解析单元，其中：

所述第一判断单元配置为根据所述原始报文的报文类型判断所述原始报文是否为数据报文；

所述第二判断单元配置为在所述第一判断单元判断出所述原始报文为数据报文时，根据所述原始报文的文件类型以及事务类型字段的值，判断所述原始报文是否包含所述载荷数据；

所述解析单元配置为在所述第二判断单元判断出所述原始报文包含所述载荷数据时，将所述协议字段及循环冗余校验码之间的内容解析为所述载荷数据。

Images