软硬件混合的高效CHI协议分析

赵祉乔,周 理,荀长庆,潘国腾,铁俊波,王伟征

(1.长沙理工大学计算机与通信工程学院,湖南 长沙 410114;2.国防科技大学计算机学院,湖南 长沙 410073)

1 引言

从芯片设计到正式上市的整个阶段中,片上系统SoC(System on Chip)的验证是一项非常繁复的任务[1]。投入到SoC验证的时间和精力,可以占据整个系统开发设计时间的60%甚至更多[1,2]。只有在硅前验证阶段有了足够充分的验证结果支持,才有信心进行流片。然而在系统级验证阶段,对于芯片功能、性能等方面的高效验证手段有限。在功能验证方面,查错时使用抓取波形等常规调试方法往往难以定位具体出错的模块,且可能会消耗一个月甚至数月的时间,极大地影响了效率;而在性能分析方面,当SoC性能未达到预期设计指标时,很难根据有限的全系统性能数据定位具体性能瓶颈[3]。因此,在SoC开发过程中,如何高效准确地进行功能验证与性能分析,是亟待解决的难题。

互联总线处在系统的核心地带,为了试图解决这些问题,有研究提出从总线协议入手,通过片上网络协议分析获取更多芯片内部的状态信息,提高芯片可观察性[2],进而高效地对问题进行定位分析和处理。Synopsys公司、Cadence公司也相继推出验证IP VIP(Verification IP)[4,5]用于标准片上网络协议CHI(Coherent Hub Interface)、AXI(Advanced eXtensible Interface)等的验证,采用通用的验证方法学UVM(Universal Verification Methodology)实现,具有良好的可重用性和可扩展性。然而,这些工具都是使用不可综合的System Verilog语言,只适用于软件仿真验证,不适用于在FPGA原型平台验证。UltraSoC公司针对CHI总线、片上自定义总线开发了可综合的VIP和对应软件[6],完成了对多类总线的同时监测,并可通过 USB(Universal Serial Bus)或JTAG(Joint Test Action Group)导出。然而,其全部可综合的实现方法在实际的使用中存在数据导出缓慢、对FPGA原型平台的硬件资源占用较大等问题。

因此,针对硅前验证阶段的需求和现有研究的不足,本文设计了一种软硬件混合的高效CHI协议分析方法,通过DPI(Directed Programming Interface)连接C代码,实现了一种适用于FPGA原型平台,且硬件资源占用少、可重用性高的系统级验证方法,能够在FPGA原型平台上实现对CHI协议的高效监测和分析,有效加速SoC问题的定位和性能分析,提升设计与验证的效率。

2 待测SoC及CHI协议

2.1 待测SoC

如图1所示,待测SoC包含多个处理器核CORE、数据存储单元DDR(Double Data Rate)和输入输出单元IOU(Input and Output Unit)等。其中,片上网络基于mesh结构实现,处理器核的L2 Cache与片上网络通过CHI协议互联,是一款高性能众核SoC。

Figure 1 Basic structure of the SoC under test图1 待测SoC的基本结构

2.2 CHI协议

CHI协议[7]是目前广泛采用的一种片上协议规范,从其运行情况可以了解通过片上网络互联的多个部件的运行状态,有助于问题的定位及分析。

如图2示,以读数据为例,处理器核要从主存储器中读取一个数据。处理器核作为请求节点RN(Request Node)发出一个读请求ReadNotSharedDirty给下一级的主节点ICN(InterConNect),主节点ICN接收到请求后在目录中查找。如果有该缓存数据则返回CompData给处理器核,处理器核收到全部数据之后再返回一个CompACK作为收到的回复;如果主节点ICN中没有该缓存数据,则继续向下一级的从节点SN(Slave Node)发送读请求ReadNoSNP。

Figure 2 Read transaction flow图2 读请求事务流程

在数据片(Data Flit)中存在多个ID字段用于标识网络路由。如图3所示,以读请求事务为例,通过TgtID寻址到主节点ICN及从节点SN,通过SrcID就可以将响应返回到请求节点及主节点。事务号TxnID用来唯一标识同一对节点的不同事务流,返回节点号ReaturnNID及事务序号ReaturnTxnID用于标识返回数据的目标节点及事务号,主节点号HomeNID标识该事务的主节点,即为反馈报文的目标节点号TgtID,数据缓存区号DBID用于标识数据的存放位置。

Figure 3 ID field transform of ReadNotSharedDirty transaction flow图3 ReadNotSharedDirty事务流的ID域变换

如图4所示,在CHI协议中,由主请求通道TXREQ、从数据通道RXDAT、从反馈通道RXRSP、从监听通道RXSNP、主反馈通道TXRSP、主数据通道TXDAT 6个通道进行信号传输,每一个通道由4个信号来完成。

Figure 4 Channel and signal of CHI protocol图4 CHI协议的通道及信号

以图2中的读数据为例子,读请求在请求通道中传输,REQFLITPEND信号为传输到来前的声明,表示在下面几个时钟周期该通道会有报文传输,用于低功耗模式;REQFLITV信号标识当前数据片是否有效;REQFLIT信号为完整的数据片报文;REQLCRDV信号为信用信号,当其值为1时,返回一个信用给请求报文的发送方。

3 软硬混合监测方法

本文方法由软硬件协同实现,包含离线模式与在线模式,具体流程如图5所示。

Figure 5 Flow chart of protocol analysis图5 协议分析流程图

该方法由数据传输模块、数据片解码组码模块、协议分析模块协同完成。数据传输模块用于捕捉待测SoC中的CHI报文,并将其从FPGA原型平台通过DPI-C接口传输到工作站中。数据片解码组码模块处理CHI协议中的数据片,将数据片按照数据传输模块中的配置信息解码,将解码后的数据片结构体中的事务流控制变量组码。协议分析模块可完成事务流的追踪、报文的正确性检验和报文类型的覆盖率监测。具体结构如图6所示。

Figure 6 Structure of collaborative monitoring unit图6 协同监测单元结构

3.1 数据传输模块

本文方法在FPGA原型平台中利用DPI-C接口传输数据[8],可综合的硬件部分对共享函数体进行声明,软件部分共享使用的函数体也由此定义。不可综合的软件部分对共享函数体进行实例化,用以捕捉待测SoC中通过CHI协议各个通道的报文。

如图7所示,数据传输模块中可综合的软件部分使用System Verilog语言实现,包括：存储参数配置部件、共享函数体声明部件和监测器状态控制部件。不可综合的软件部分使用C++语言实现,包括：数据片参数配置模块、监测器数据管理模块和监测器模式控制模块。

Figure 7 Structure of data transmission module图7 数据传输模块结构

存储参数配置部件用于设置监测器的数据存储方式,包含离线模式中输出的数据包DAT和在线模式中输出的日志文件LOG的输出位置、针对该待测SoC中CHI协议的参数配置文件位置、被监测节点句柄索引。在SoC中可能存在多个CHI协议节点需要绑定监测单元,因此该方法在不可综合部分采用句柄列表的方法管理各个节点的生成数据。每个节点由唯一的句柄索引标识其在表中的位置。

共享函数体声明部件通过导入(import)的方式在可综合的硬件部分中声明硬件部分与软件部分共享函数体。监测器数据管理模块完成共享函数体的实例化,并将2.2节中所述的6个通道中的数据传输给软件部分。共享函数体列表见表1。

为了尽可能降低数据传输代价,监测器状态控制部件用于控制监测器的使能。当存在监测器使用需求时,将监测器的使能信号置高,调用CreateDb函数使监测器开始工作。之后通过Db-Write函数将数据从硬件部分传输至软件部分。当没有监测器使用需求时,在FPGA平台将监测器的使能信号置低,停止通过DPI-C接口向工作站传输数据,使用CloseDb函数关闭文件,减少资源的占用。如果总线已经在工作,开启监测时应当忽略监测初期事务流中缺失的请求通道和监听通道报文及其相关报文,以防止误判。

由于CHI协议标准中的部分字段存在可配置的情况,各个待测SoC中实现的CHI协议字段的定义存在不同,本文方法的数据片参数配置模块使用参数输入的方法读入CHI协议的可配置参数字段。此外,通过配置节点的最大信用这一参数,可以修改支持的最大未完成请求数目。

本文提出的方法存在2种模式,通过宏定义的方法选择离线或在线模式。如表2所示为离线模式与在线模式的对比,离线模式下对CHI报文不进行检验直接输出;在线模式下对CHI报文进行解码、组码以及指定的协议分析处理后再输出监测结果。离线模式的输出数据如图8所示。

Table 2 Comparison between offline mode and online mode

Figure 8 Data format of offline mode output图8 离线模式输出的数据格式

3.2 数据片解码组码模块

数据传输模块捕捉到的是CHI协议中的数据片。数据片解码组码模块对6种通道的数据片分别进行字段的解码,对其中事务流相关字段进行组码。

解码模块按照配置的字段格式,将完整数据片通过移位和与或操作分解为各个字段信息,将解码后的字段信息存储在请求报文、监听报文、反馈报文、数据报文4种结构体中。在解码过程中为每一条事务流生成唯一的标识码,用于定位单个事务流。

组码模块将数据片结构体中的数据解析为事务流控制变量。事务流控制变量具体包含是否为无数据类型报文、是否为可监听类型报文、是否为原子类型报文、是否为缓存状态设置相关报文、是否为DVM(Distributed Virtual Memory)类型报文等变量,这些变量按照操作码字段的含义赋值。

3.3 协议分析模块

协议分析模块是本文方法的核心模块,主要负责对协议的解析与正确性检验。如图9所示,协议分析模块包含事务流追踪模块、报文检验模块、问题反馈模块、覆盖率监测模块。

Figure 9 Schematic diagram of protocol analysis module图9 协议分析模块结构示意图

事务流追踪模块按照时间顺序依次读取数据包中6个通道的报文,使用等待响应的事务表存储未完成的事务,在事务表内通过目标节点号、事务号对事务进行追踪。通过参数配置该SoC中支持的最大待完成请求数目,进而实现6种通道数据事务流的追踪及基础检验。具体流程如图10所示。

报文检验模块用于检验6种通道中报文的正确性,包含通道信用计数检验、报文字段检验、事务流的正确性检验等。通过对Opcode、AllowRetry、ExpCompAck和Order字段进行监测,实现多种不同类型的事务流程判定。当监测到问题发生时,通过问题反馈模块上报错误,并将问题发生的事务流完整信息和基本错误提示输出在监测日志中,根据用户设置可以选择停止或继续仿真。具体流程如图11所示。

Figure 11 Flow chart of packet verification module图11 报文检验模块流程图

覆盖率监测模块,用于监测请求通道和监听通道中的报文,统计CHI协议中的请求报文和监测报文中有多少报文类型已经被执行过。并使用计数记录每种报文类型发生的次数。当监测到对应报文时,计数加1。监测完成时,输出各个通道中各报文类型的发生次数、覆盖率等统计信息。如表3所示为输出的覆盖率统计结果。

Table 3 Coverage statistics results and their explanations

4 实验及结果分析

4.1 实验设置

本文实验基于FPGA原型平台在Linux操作系统下实现,使用2.1节中所述基于4×4 Mesh实现待测SoC。监测单元与待测SoC的绑定方法如图6所示。分别在单核、四核环境中设置绑定1个监测单元和4个监测单元的实验进行测试。节点最大未完成事务数目设为16。

4.2 实验输出结果

离线模式下向工作站中输出数据文件DAT,之后在工作站端对其进行解析,生成监测日志及覆盖率统计结果。在线模式下向工作站输出监测日志LOG,包含错误提示信息和错误发生报文完整事务流信息。如图12所示为一次实验的结果展示,其中图12a为离线输出数据DAT;图12b为在线输出监测日志LOG;图12c为覆盖率统计结果。

Figure 12 Display of experimental results图12 实验结果展示

4.3 在线模式与离线模式对比

如表4所示为单核环境中正常工作情况下离线模式与在线模式输出数据大小对比。实验结果表明,在正常工作状态下在线模式不存在输出数据,没有存储资源被占用。离线模式下输出数据的大小随仿真周期的延长线性增大,对资源占用较大。

Table 4 Size comparison of output data between offline mode and online mode

如表5所示为使用本文提出的监测器前后FPGA资源的占用情况对比。

Table 5 Comparison of FPGA resource usage before and after using monitor

本文监测器框架在硬件侧只需要增加对协议信号进行传输的逻辑,而复杂的协议正确性检查逻辑在软件侧得到了实现,因此软硬件混合的监测单元对FPGA原型平台的硬件占用仅占0.01%,在实际应用中可以忽略不记。

如表6和表7所示,分别为单核(单核 DDR4G 初始仿真频率为1 380 KHz)、四核(四核 DDR16G 初始仿真频率1 309 KHz)的环境中离线模式与在线模式下对于npb-omp[9]测试题目的实验结果。

Table 6 Results of offline mode and online mode under single-core environment

Table 7 Results of offline mode and online mode under four-core environment

对于单核环境,监测单元的离线模式对仿真时间没有影响,在线模式的仿真时间平均变长了1.13倍。对于四核环境,离线模式的仿真时间平均变长了1.03倍,在线模式的仿真时间平均变长了1.25倍。其中,对仿真时间没有影响的离线模式实验组占总离线模式实验组的95.46%,对仿真时间没有影响的在线模式实验组占总在线模式实验组的54.55%,最长的仿真时间变长了1.83倍。

实验结果表明,离线模式对于仿真速率影响不大,在线模式对仿真速率的影响也在可接受范围内,该监测方法可以达到对CHI协议监测不影响整体仿真速率的目的。

5 结束语

本文设计了一种软硬混合的高效CHI协议分析方法,用于对CHI总线上的信号进行高效地监测与分析。该方法可以在多核SoC的原型系统平台中使用,离线模式对仿真速率影响不大,在线模式对存储资源占用较少、可重用性高,其DPI接口可以扩展,以对AXI等协议进行监测,应用于SoC的验证过程可以加快问题出错点的定位过程,具有一定的应用价值。