浮点整数混合运算单元验证平台的实现*

戴 程 李 涛 何星宏

（西安邮电大学电子工程学院 西安 710121）

1 引言

计算单元是现代计算机发挥强大能力的一个重要基石［1］，其可靠性验证也因此变得十分重要。自从20世纪80年代浮点标准IEEE754［2］提出以来，由浮点格式定义在运算中带来的复杂边界情况验证始终是一项复杂的挑战［3］。相对简单的整数运算也同样伴随着多种异常情况。本文正是针对这一需求，将浮点整数混合单元作为具体验证对象，提出一种可靠的验证方案。

面对当前复杂设计的验证需求，业界广泛而又成熟的应对策略是搭建验证平台，而本文在基本原型［4］的基础之上借鉴了Crossgroup（交叉覆盖组）［4］的思路，将计算任务根据数据类型、运算类型、取值区间、异常数据操作等属性进行分割，对应每个分割块建立完整的验证通道，然后以块为基本单位在上层进行合适的单项或者组合验证。这样在面对具体应用中的差异化设计时，可以灵活的选取调整其中的块以及添加新的块。最终形成底层固化若干基本块及其变化版本，上层直接调用底层基本块或者由基本快组成的高级块的形式，这种过程类似于软件应用程序库中函数使用的方法。

2 浮点整数混合运算单元［5～7］简述

该设计支持单精度（1.8.23）、单精度扩展精度（1.8.32）、整数3种数据类型。浮点运算支持乘加、乘、加、比较运算，执行一次需要3个时钟；整数运算支持乘加、乘、加、比较、移位运算，执行一次需要2个时钟。其整体结构如图1所示。

整个设计从上至下依次分为3级：第1级完成浮点运算阶码的对阶，乘加运算中乘运算全部和加运算一部分；第2级完成剩余部分的加运算以及前导0计算；第3级完成规格化、舍入以及格式化输出。

设计的核心处理通道实现的是浮点乘加运算（A*B+C），其余运算都是嵌入到主通道之中，共用主通道中的计算资源完成运算，沿着主通道进行数据流动直至产生最终结果。

3 验证平台综述

本论文采用SystemVerilog语言来设计验证平台［8］，整体验证结构如图2所示。

图2 验证平台结构框图

首先由Driver产生激励同时传递给Reference Model、DUV以及Monitor，其内部可以通过选择以及控制不同的激励约束文件（Packet）来对应不同的验证场景，也就是引言所提到的实现不同的基本块以及高级块的思想，同时在Environment配置环境时也有不同的Driver可供选择，本文实现了3个Driver分别对应3种数据类型。

其次DUV是待验证的设计，ReferenceModel是用SystemVerilog语言设计的参考模型［9］，两者接收并执行完全相同的激励，然后输出结果给Scoreboard；而Monitor用于保留激励以及ReferenceModel中的关键信息，供Scoreboard在结果比较时使用。

再次由Scoreboard接收并综合这些信息完成结果的比较判定，同时输出验证报告，其内容可分为两部分：本次验证测试激励以及执行结果等的统计信息；执行结果或者平台运行出错时刻保留的相关信息。

最后在Environment中完成整个环境的配置，保证每种测试块都拥有一条完整独立的验证通道，但是除了必要的独立部分，其余部分是共用的，这样可以优化平台的整体设计。在程序块Testcase中会完成验证平台与DUV的连接以及整个平台启动/终止的控制。

4 验证策略

若将某个设计所有可能的激励看做一个激励空间，在大多数情况下如果想要遍历这个激励空间是需要付出难以承受的计算代价以及时间代价，对于运算类设计尤其如此。因此比较切实可行的解决方案是通过约束选取整个激励空间的一个子空间来表征整个激励空间，当子空间随机覆盖充分时便可以较为充分的认为DUV功能验证通过。但是这样并不完备，理由有两点：一个是选取的子空间毕竟是部分，可能会忽略一些导致问题的激励；另一个是子空间中随机化生成激励的方式通常会出现个别激励很难覆盖到的情况，从而引出定向测试来作为必要的补充手段。

4.1 定向测试策略

定向测试核心在于定向激励，本文的定向激励分为浮点、整数两部分。浮点激励一部分来自IBM实验室开发的浮点定向测试包［10］，它们拥有特定的格式（见表1），包含操作数与验证过的结果，通过Python脚本将其转化为DUV所识别的激励格式后作为整个平台初始的校准测试；另一部分是补充激励，作为随机测试的补充。整数激励组成可以类比浮点激励，只是其校准测试所用激励是通过人为挑选若干边界与常规情况产生。

表1 激励格式解读（按位置对应）

此外本文还扩展定向激励部分实现了仿真问题的自动化［11］重现。当执行结果出错时通过脚本从验证报告中将错误时刻相关信息以及相关数据提取，然后作为新的激励重新运行仿真来重现目标问题。整个过程自动化进行，极大地方便了问题的仿真调试。

4.2 随机测试策略［12］

随机测试是整个测试的核心，在通过约束选取子空间之后，便按照引言所述思路根据数据类型、运算类型、取值区间、异常数据操作等属性将子空间分割成基本块、高级块的形式，每一块都进行基于功能覆盖率［13］统计的独立随机测试，同时通过定向测试的补充测试加以配合。所有块都拥有相同的随机测试流程，具体描述如下。

第一，从激励约束文件Packet内部约束描述，Packet的选取、多个Packet的控制，Driver的选取等多方面进行灵活配合来产生预期的激励。

第二，通过使用不同的随机种子来赋予激励更强的随机性。

第三，运行仿真，调试解决错误的情况。

第四，进行功能覆盖率检查［14］。该项的核心是设计了一系列Covergroup，采集输入、输出、部分功能类以及部分设计模块中的内部关键信息，然后通过自动、手动建仓以及交叉仓等方式实现对功能覆盖率的量化分析，对于随机化中难以覆盖的仓将转到定向测试环节进行补充测试。

第五，根据覆盖率分析反馈，从激励约束、随机种子、Covergroup等多方面进行调整，逐渐实现对子空间的全覆盖。

第六，按照以上4步反复迭代，直至在Covergroup较为充分的情况下功能覆盖率达到100%，结束随机测试。

5 验证结果分析

整个测试分为6项，分别对应3种数据类型的定向与随机两类测试。其中随机测试按照上文提到的多种因素分为不同的测试块［15］进行测试；定向测试完平台校准测试、问题重现以及补充测试。具体测试分类及规模如表2所示

表2 测试项目及规模统计

经过不断调试修正，完成所有测试项目。现摘录其中单精度运算的测试结果如图3、图4所示。

图3 单精度定向测试报告

图4 单精度随机测试报告

6 结语

本文综合利用多种测试方法来完成目标设计的功能验证任务，在此过程中验证了以划分基本块与高级块的方式将整个验证任务进行分割并各自验证的思路。也证明了该思路在应对复杂多样的运算类设计验证任务的可行性。

接下的工作中会通过进一步分析不同的运算设计，构建更为丰富的基本块与高级块，寻找更为合理的块间组合方式来应对不同的运算类设计，从而进一步完善和验证这一验证思路的有效性。