RISC 指令集众核处理器功能验证与实现（二）

　　3 众核处理器验证策略及实现..

　　本节主要讲述Godson-T 众核处理器的验证策略和实现.对于该款众核处理器的验证工作，采用让处理器核主动地执行程序验证平台被动地调试适应处理器核的“被动式”思想，通过让小核与模拟器协同一起执行同样的测试程序的“软硬件协同验证”策略，终达到所有测试程序的每条指令都比对通过的验证结果.

　　3.1 普通指令的验证策略..

　　该款众核处理器的处理器小核采用顺序双发射方案设计，指令为乱序执行但顺序提交，在验证工程中，大部分执行后直接进行提交的指令都是可以采用普通指令的验证策略进行对比，即在提交阶段将小核运行情况与模拟器所执行的结果进行对比.

　　当待测小核core[x,y]的两条提交总线中任意有一条有效时， 此时平台需要通过调用test_xy_step（x[i],y[i]）函数让模拟器对应的小核core[x,y]也执行同样的一条指令，由于模拟器可以在瞬间执行完该指令，并将执行结果输出比较或写入固定专用的寄存器中等待比较.测试平台通过调用test_xy_read_pc（x[i],y[i]）函数来获得执行指令的PC 值，并以此来判断二者执行的是否为同一指令，PC 值相同则执行为同一指令，可以继续验证二者执行结果是否一致.FPR.GPR.FCC.FCR 为执行结果对比寄存器，对于普通指令的验证，验证平台只需根据不同情况调用以下6 个函数[11]就可以调出小核具体的执行结果，再通过上述信息和关联函数进行对比即可.

　　平台中对于普通指令比对过程中用到的六个主要函数包括：..

　　通过实验和具体实现过程发现，这样的对比策略能够覆盖Godson-T 众核处理器指令集中的大部分指令，很高，能及时发现在设计初期大部分的设计缺陷，从芯片的整体过程来看节约了开发周期，通用性强，不失为一种良好的众核处理器普通指令测试比对策略.

　　3.2 特殊指令的验证策略..

　　除了上述包括简单运算指令在内的大部分普通指令，一些比如Load/Store 指令等指令的执行结果在提交阶段需要通过片上网络或由于系统流水的原因不能马上提交，此时不能再运用普通指令的对比策略进行验证.针对这一现象和问题，验证环境中必须增加应对特殊指令的验证策略，这样才能终实现每条指令都对比通过的验证目标.

　　实际上，由于处理器小核对于指令是完全意义上的并行执行，而Transformer 在运行过程中是以串行来模拟并行，特殊指令流水执行到提交阶段并没有错，只是执行结果已经被刷掉或已无法同Transformer 的执行实现同步进行比较.小核与小核之间的互联需要消耗一定的时间，使得对于每个小核个体来说的顺序提交变成了整体全部小核的乱序提交，原本顺序的指令流从整体的角度来看不再是顺序的，所以此时如果仍按照普通指令的的比对策略，就会产生比对不通过，但这并不是小核本身产生的逻辑错误而造成的，所以对这些特殊指令进行特殊处理，增加特殊比对机制.

　　通过例子可以直观地说明特殊比对机制的实现过程，举例如下：..

　　现在假设对两个处理器小核 core[0,0]和core[0,1]进行一些包含特殊指令的操作.步，core[0,1]向本地数据缓存写入一个数据3,此时模拟器也调用相关store 函数完成写入数据3操作，此时平台检测到目标地址空间都为3,比对通过；第二步主核core[0,0]向core[0,1]发出一个读请求，请求将数值3 读走.读操作为特殊指令操作，读取的数据从从core[0,1]到core[0,0]需要经过片上网络的延迟才会返回提交.在这一延迟过程中如若主核core[0,0]的该Cache-line又完成了没有延迟的提交过程，比如core[2,0]向其中写入了数据4,那么此时提交后模拟器对应core[0,0]相应Cache-line 中的值就会变为4.

　　此时再比对由core[0,1]的读请求操作就会由于模拟器中的值已经被刷走而比对不通过.普通指令的对比策略就不再适用.

　　仔细的分析上述的对比过程我们不难发现，对于这类特殊指令，并不能再提交阶段再进行验证比对，而应在数据3 从core[0,1]中被取走时就启动平台进行比对，此时方能比对成功且不影响后续访存操作的比对.即在core[0,0]从core[0,1]将数值3 取走之后立即启动模拟器执行一条相应的Load 指令，比对就会顺利通过，这就是针对特殊指令而在普通指令验证基础上进一步优化的比对策略.

　　3.3 覆盖率导向的验证策略伴随着现代大规模集成的电路制造工艺的快速发展，设计工程是必须直面芯片制造过程中可能产生的物理缺陷，现今的可测试性设计DFT（Design for Test）应运而生，而覆盖率测试又是其重要的指标.

　　Synopsys 公司的VCS 工具能够通过监控和评估仿真过程中HDL 代码的执行轨迹来分析出该设计的哪些部分还未被测试到，同时也可能会发现测试平台的不足以及测试向量需要从哪些方面进行改进，从而可以有导向的将验证重点放在这些方面，有利于达到覆盖率百分之百的验证目标，这为芯片能够终成功流片打下了坚实的基础.

　　在对该款众核处理器的设计和验证过程中，各部分设计人员都需要首先对各自所设计的模块进行功能点的抽取，然后用System Verilog 语言对功能点进行功能覆盖率建模，开发人员需要在每个硬件模块中显示地写出所有功能覆盖点，以及需要覆盖的点和ignore 的点.用到的关键词包括：covergroup.coverpoint.ignore bins 和cross等.图3 是Godson-T 众核处理器前端流水线主要功能模块覆盖率.图4 是译码模块的功能覆盖率.

　　3.4 时序验证策略..

　　时序分析验证是除功能验证之外次重要的验证重点，其所包含的STA 和DTA 两种方式各有所长，可协调弥补，灵活使用.

　　STA 即套用特定的时序模型穷尽覆盖.通过提取设计电路中的所有显性和隐性的时序路径，分别计算每个信号信号在这些路径上的延迟，分析其是否违反设计者给定的时序限并找出违背约束的缘由.Synopsys 公司的Prime Time 工具为STA 提供了一个成熟的平台，该款众核处理器的静态时序分析同样基于这样一个平台.具体验证流程可概括为确定设计数据库（Specify data libraries）.确定互相联系（Specify interconnect）.建立时序约束（Specify timing constraint）和时序检查与分析（Timing check）等.

　　DTA 就是通常的后仿真.在设计的网表信息生成之后，通过相关工具将网表中包含的延迟信息和对应物理参数等提取出来，然后再进行仿真，检查电路在后期设计中是否满足设计期望.

　　DTA 相比于STA 来说不足之处在于产生的测试向量不够完整和详尽覆盖到每一条路径，因此DTA 无法做到显示一些潜在问题路径上的时序失真.它相对于静态时序验证来说比较，但分析速度很慢，同时对多个线程或多个测试程序进行DTA 的速度会是其一大瓶颈.

　　该款处理器的DTA 工作主要测试了功能模式.通路模式和JTAG 模式下进行的slow.fast以及typical 三个库文件的动态时序分析，都顺利通过.同样测试通过的还有芯片与外围硬件模块之间通信消息的模拟验证.

　　3.5 功耗评估策略..

　　功耗评估是衡量一个处理器性能重要的参考指标，随着市场对于处理器性能和成本考虑需求的不断增多，基于低功耗目标而设计开发的处理器受到越来越多用户的青睐.对于众核处理器来说，功耗大小优劣直接决定了其性能和未来发展趋势.因此，在芯片功能和时序的验证通过之后，努力降低设计的功耗比就是下一阶段的测试与继续验证的首要目标.

　　Synopsys 公司的Power Compiler 和PrimeTime 都是成熟的可用于系统功耗检测和优化的验证工具，在Godson-T 处理器功耗评估的初期，我们同样可以采用这两种工具和测试方式作为待测芯片功耗评估的有效手段.Power Compiler 能够报出平均功耗的优势可以被用来评估每个小核的设计是否具有差异，以及系统整体功耗的横向对比；而Prime Time 工具可以针对待测设计的部分给出更为详尽的功耗分析，可具体到每一个模块的某个寄存器，提供更为详实的改进和优化导向.

　　Power Compiler 多用于初期对于系统功耗的整体把握，可以通过整体评估确定需要把设计的功耗降到怎样一个标准.Prime Time 在后期的评估过程中使用较多，利用设计网表.标准库器件功耗列表.内部行为转换文件（SAIF）和值转换文件（VCD）可以细化和对每一个单元或模块进行功耗比优化.这些网标或文件都可以通过在功耗仿真过程中添加相应的系统文件和库文件得到.图5 给出了Prime Time 功耗评估的流程示意图.

　　4 结束语

      随着集成电路制造工艺水平的迅猛提高和计算机体系结构设计技术的发展和创新，微处理器已步入了多核并行的时代.在整个芯片的设计过程中，仿真和验证是耗时而又非常重要的一个环节.随着众核处理器设计规模的不断扩大，基于EDA 工具的纯软件仿真和基于FPGA 的原型验证都遇到了各自发展道路上的瓶颈.

　　本文的工作主要是基于EDA 工具的验证，以中国科学院计算技术研究所设计开发的Godson-T 众核处理器芯片为依托，在“被动式验证”的思想下，采用“软硬件协同验证”的策略，终达到“单条指令对比通过”的验证目标.再辅以覆盖率验证.时序验证和功耗评估策略，完整地提出了一套芯片验证平台搭建和验证功能实现的方法流程，为终的流片提供完备的验证方案.