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

朱博元，刘高辉，李政运，安述倩

1.西安理工大学自动化与信息工程学院，西安 710048

2.中国科学院计算技术研究所计算机体系结构国家重点实验室，北京 100190

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

朱博元1，刘高辉1，李政运2，安述倩2

1.西安理工大学自动化与信息工程学院，西安 710048

2.中国科学院计算技术研究所计算机体系结构国家重点实验室，北京 100190

众核技术已成为当前处理器体系结构发展的必然趋势，如何对众核处理器设计进行有效而充分的验证，成为当今IC设计验证领域的研究热点之一，也是众核处理器芯片能否成功流片的关键因素之一。目前工业界采用基于仿真的验证作为主要的验证方式，重点介绍了以覆盖率为导向的RISC众核处理器的功能验证环境的整体设计，提出了“被动式”的验证思想，并采用“软硬件协同验证”的策略，最终达到每条指令都比对通过的验证目标，辅以后期阶段所引入的时序验证策略和功耗评估策略，完整地提出了一套芯片验证平台搭建和验证功能实现的方法流程。

众核处理器；功能验证；覆盖率；时序验证；功耗评估

1 引言

随着集成电路制造工艺的进步和处理器设计水平的不断提高，众核技术已成为当前处理器体系结构发展的必然趋势。处理器的复杂度呈指数幅度上升，使故障的查找和修复变得越来越困难，如何对众核处理器进行有效而充分的验证，成为当今IC设计验证领域的研究热点之一，也是其能否最终流片成功的决定性因素。传统的功能验证方法主要采用监测并控制其地址与数据总线的方法，这对于高度集成化的众核芯片，其追踪系统总线的策略往往不能定位内部故障所在，从而不能进行下一步的分析和修改故障。

基于软件和硬件分别进行独立的仿真验证仍然是目前IC验证主要应用的功能验证方式，在此基础上，本文重点介绍了以覆盖率为功能验证导向的RISC众核处理器的验证环境的整体搭建，提出了“被动式”的测试验证思路，并采用“软硬件协同验证”的策略，最终达到了处理器运行的每条指令都对比通过的验证目标。再辅以相应基于成熟EDA工具的功耗和时序分析验证方式，完整地提出了一套芯片验证平台搭建和验证功能实现的方法流程。

2 众核处理器验证环境的搭建

2.1 软硬件协同验证的发展现状

软硬件协同验证与传统的数字系统仿真验证方法不同，它是针对软件和硬件系统模块进行的混合模拟仿真。传统的系统验证方法通常是将软件部分和硬件部分的设计验证分开独立进行，二者在确定了设计目标之后就很少再相互考虑。这样的设计验证方法在系统设计后期才会发现比如软硬件接口或在设计初期没有考虑到的系统功能方面的问题，导致设计资源的浪费与设计周期的延长和开发成本的不断增加。

软硬件协同验证技术的出现很好地改善了这一现状，它分为外围硬件模型验证和处理器核心验证两个部分。软硬件协同验证通常使用硬件模拟器作为验证工具，通过执行RTL级设计描述模拟设计的物理实现，其仿真结果取决于设计描述是否正确反映了设计的物理实现，验证时需要通过测试平台产生激励和开发人员检查响应的有效性[1]。

2.2 RISC众核处理器概述

本文选取一款名为“Godson-T”的RISC架构处理器芯片为研究对象和载体。该款芯片是由中国科学院计算技术研究所系统结构国家重点实验室设计的一款片上众核处理器芯片，主要面向电信应用、服务器、金融管理、医疗和大型数据库系统等领域的高性能计算。该款众核处理器目前已经顺利通过各项验证和测试，并成功Tape-out。

该款众核处理器的结构如图1所示，中间部分为四纵四横的十六单元阵列，每个单元由一个处理器小核和一个RT组成，两边各有两个L2-Cache，为二级数据缓存，为十六个独立小核共享。在示意图的上方，SYNC-ma模块（同步管理器）负责同步管理各独立小核间的互联与协调[2-3]。TAP端口负责与JTAG调试相关的接口进行通信的模块，IO模块负责向片外发送相关配置信息。

2.3 验证语言System Verilog概述

SystemVerilog简称为SV验证语言，是IEEE 1364 Verilog-2001标准的扩展增强，兼容Verilog HDL 2001，并已经成为硬件设计下一代验证仿真的主流编辑语言。SV语言结合了来自Verilog HDL、C语言、面向对象设计语言的部分概念，另外包含了Assertion语言和平台语言，完美结合了验证过程中使用频繁的高层验证性语言（HVL）和开发过程中使用较多的硬件描述性语言（HDL），对于进行当今高度愈加复杂的设计验证工作无疑是提供了一种有效的解决思路。它具有接口（interface）、断言（Assertion）、多线程（multiple threads）和函数和任务（Function and Task）等多种新的验证平台建模技术[4-6]。

图1 Godson-T众核处理器的结构示意图

2.4 验证环境的整体设计

Godson-T整体验证环境设计主要由六部分组成。包含处理器小核在内的其顶层实现模块作为待测硬件部分，参考验证模型模拟器Transformer作为测试软件部分，这两部分具体体现软硬件协同验证的策略；内存空间Memory由一段C代码负责维护和执行相关操作，容量为4 GB。输入输出接口模块（IOI）负责进行接口配置；两个同构的Memory Controller模块（MC）分置两侧，用来针对和控制访存操作；一个存放着在验证过程中可能出现故障信息的数据库Data_base和若干具有分选功能的选择器等共同组成验证环境中的附属模块。其结构示意图如图2所示。

图2 Godson-T验证环境结构示意图

在Godson-T被动式验证的指导思想下，验证环境必须做到主动去适应和满足测试小核的对每个测试程序的执行操作和处理动作，而让待测小核能够在不受平台外部条件任何干扰和容错性相关的影响下自主完成自身设计功能体现。

验证环境中由C代码负责维护的内存空间只识别可执行文件，故在初始化时，程序列表中等待测试的程序需首先进行编译，再进行加载。向内存中加载可执行文件是通过调用加载函数实现的，该加载函数的功能是从程序列表中按照一定次序依次读取测试程序，直到所有测试程序都加载完毕。

编号为core[0，0]作为测试程序的主核，既是需要测试的小核之一，也是测试环境中负责向其余小核客户传递消息的起点。所有测试程序依次轮训每个小核首先需要将消息发送至core[0，0]，待测目标小核收到与之相匹配的调试编号开始进行取指、访存等操作，这样目标小核在调试状态下就进入了运行过程。如果是同时测试多个小核对与多线程程序运行的情况，主核会根据需求创建出多个线程，并通过片上网络进行资源调用和分配，使各个小核相继运行自身的线程任务，这样就实现了众核处理器测试环境地初步搭建。完成了验证环境搭建的首要工作[7]。具体的验证策略细节会在下一章进行详细的介绍

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个函数[7]就可以调出小核具体的执行结果，再通过上述信息和关联函数进行对比即可。平台中对于普通指令比对过程中用到的六个主要函数包括：

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

3.2 特殊指令的验证策略

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

实际上，由于处理器小核对于指令是完全意义上的并行执行，而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）应运而生，而覆盖率测试又是其最重要的指标[2，8]。

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

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

图3 前端流水线主要功能模块覆盖率报告

3.4 时序验证策略

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

图4 译码模块的代码覆盖率报告

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

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

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

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

3.5 功耗评估策略

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

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

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

图5 Prime Time的功耗评估流程图

4 结束语

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

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

[1]林明煌.多核处理器原型验证平台的研究与实现[D].北京：北方交通大学，2008.

[2]宋风龙.众核体系结构中高性能片上存储系统研究[D].北京：中国科学院计算技术研究所，2008.

[3]胡伟武，陈云霁，肖俊华，等.计算机体系结构[M].北京：清华大学出版社，2011.

[4]ASIC.The user guide[EB/OL].[2008-10-14].http：//www.asicworld.com.

[5]解咏梅.基于覆盖率的功能验证方法[J].计算机应用研究，2005（1）.

[6]李海忠.设计文档[Z].北京：中国科学院计算技术研究所先进微系统组，2010.

[7]林瞬婷.面向多处理器核SOC软硬件协同验证平台[D].杭州：浙江大学，2010.

[8]王立华.基于FPGA的系统芯片（SoC）原型验证研究与实现[D].济南：山东大学，2006.

[9]Fine S，Ziv A.Coverage directed test generation for functional verification using Bayesian networks[C]//Proceedings of the 40th Conference on Design Automation，2003.

[10]Synopsys.Coverage technology user guide[EB/OL]. [2011-04-02].http：//solvent.synopsys.com.

[11]夏宇闻，陈先勇.Syetem Verilog验证方法学[M].北京：北京航空航天大学出版社，2011.

[12]Emnett F，Biegel M.Power reduction through RTL clock gating[M].[S.l.]：Automotive Integrated Electronics Corporation，1999.

[13]闫沫.基于System Verilog的验证平台建模技术[J].现代电子技术，2009（18）.

[14]Synopsys.Prime time guide[EB/OL].[2011-01-10].http：//solvent.synopsys.com.

[15]Synopsys.The user guide[EB/OL].[2008-12-21].http：//solvent.synopsys.com.

ZHU Boyuan1,LIU Gaohui1,LI Zhengyun2,AN Shuqian2

1.School of Automation&Information Engineering,Xi’an University of Technology,Xi’an 710048,China
2.State Key Laboratory of Computer System Structure,Institute of Computing Technology,Chinese Academy of Sciences, Beijing 100190,China

Multi-core technology has become the inevitable trend of current processor architecture.It is an efficient and sufficient functional verification of the multi-core design that has become one of the hot points in IC design and verification fields,and also one of the key factors to the success final tape-out.Different from the common verification pattern based on emulation,this paper pays more attention in highlighting the overall functional verification environment design driven with the coverage functional verification strategy to verify RISC multi-core processor,and putting forward the idea of“passive authentication”with hardware and software co-verification strategy,ultimately achieves the goal of“single instruction comparison”.Timing verification and power evaluation strategies are also introduced in the later validation stage,providing a complete verification solution for the RISC multi-core processor.

multi-core processor;functional verification;coverage;timing verification;power evaluation

A

TP302.7

10.3778/j.issn.1002-8331.1211-0021

ZHU Boyuan,LIU Gaohui,LI Zhengyun,et al.Functional verification and implementation of RISC multi-core processor.Computer Engineering and Applications,2014,50（21）：54-58.

国家自然科学基金（No.61173007）；国家自然科学基金青年基金项目（No.61100015）。

朱博元（1986—），男，硕士研究生，主要研究方向：IC前端设计、计算机体系结构；刘高辉（1968—），男，副教授，硕士生导师，主要研究方向：数字移动通信、集成电路设计；李政运（1986—），男，硕士，主要研究方向：CPU小核设计、片上多核系统设计；安述倩（1986—），女，硕士研究生，主要研究方向：计算机体系结构。E-mail：liugh68@xaut.edu.cn

2012-11-01

2013-03-19

1002-8331（2014）21-0054-05

CNKI出版日期：2013-04-10,http://www.cnki.net/kcms/detail/11.2127.TP.20130410.1554.009.html