目前，基于RTL级（Register Transfer Level）的SoC（System-on-Chip）验证技术存在着许多局限性。这是因为：(1)SoC硬件部分的结构越来越复杂，致使在RTL级进行SoC验证的时间开销越来越大[1-2]; (2)在RTL级，SoC的硬件和软件部分需要分别采用硬件描述语言和高级语言进行描述，这不仅增加了软、硬件设计和验证人员间在交流上的困难，而且增加了系统设计人员对软、硬件划分方案进行评估的困难[3];(3)设计完成SoC硬件系统的RTL级模型后，才能进行SoC软、硬件系统的协同仿真和验证，增加了SoC系统产生功能性错误的可能性，延长了系统的开发周期[4-5]。因此，使SoC的验证工作从更高抽象级的系统级开始进行，从而尽早地发现功能性错误，缩短SoC系统的开发周期是十分必要的。

在SoC的验证工作中，最重要的问题是构建测试平台TB(Test Bench)，而构建测试平台的核心则是设计测试向量TC(Test Case)。因此，较短的测试向量的生成时间以及较高的测试向量的功能覆盖率就成为验证工作中最为关键的问题。目前，采用随机测试向量的验证方法被认为是解决这一问题最便捷和最有效的验证方法[2]，该方法的特征就是随机地从被验证对象DUV(Design Under Verification)测试激励输入域中任意地或适当加以控制地选取测试向量。因此，如何随机地生成测试向量是进行随机验证的关键。

SCV(SystemC Verification Standard)是OSCI(Open SystemC Initiative)组织公布的系统级验证标准，是一种基于SystemC类库的公开源代码的C++类库，SCV验证库可以提供直接随机测试、带权重的随机测试和带约束的随机测试三种向量的生成方法。因此，SCV标准允许用户在较高的抽象级上构建测试平台并允许用户随机地写入测试程序，具有灵活性高、测试平台可复用、验证周期短等特点。

本文将基于SystemC和SCV验证库来创建系统级的测试平台，通过对一个具有4×4包交换功能的系统级模型的验证，来研究基于随机向量的SoC系统级的功能验证方法。

1 系统级功能测试平台

SoC系统级的功能验证是针对SoC系统级的功能模型进行的验证，其目的是验证SoC系统级功能模型是否符合功能规范说明的要求。在进行功能验证前，首先应根据功能规范说明建立测试平台，其核心内容是设计测试向量。测试平台不仅能够将测试向量输入到被验证对象上，而且能够获取被验证对象产生的结果，该结果可以用来判定被验证对象功能的正确性，如图1所示。

为了验证随机测试在SoC系统级进行功能验证的有效性，在系统级构建以AMBA总线为核心、以CPU为主设备、以存储器和4×4包交换模块为从设备的SoC功能模型，并针对4×4包交换模块的功能进行测试。

系统级测试平台的核心由4个发送模块（Sender0～Sender3）、4个接收模块（Receiver0～Receiver3）和4×4包交换模块组成，如图2所示。其中发送模块用来随机地生成数据包并将数据包送入包交换模块；接收模块用来从包交换芯片中读取数据包。

4×4包交换模块主要由4个带FIFO的输入/输出端口（IN0~IN3，OUT0～OUT3）和4个移位寄存器（R0~R3）组成，待交换的数据包则由16位组成，分别为4位目的端口号、4位源端口号以及8位交换数据。该包交换芯片的主要功能规范如下：

(1)每个端口均可以正确地发送或者接收数据包。
(2)每个输入端口均可以正确地将数据包发送到多个不同的端口。
(3)移位寄存器能够从对应的FIFO中正确地读取数据包，并按R3→R2→R1→R0→R3的顺序进行移位。
(4)每个输出端口均可以正确地按设定的比例输出数据包。
(5)输入端口FIFO为空时，数据包可以送入该FIFO; 输入端口FIFO为满时，数据包不能送入该FIFO。

2 测试向量和验证结果

通常，基于SCV随机测试向量的验证工作分为随机验证环境配置、基于直接随机测试向量的验证、基于带权重的随机测试向量的验证以及基于带约束的随机测试向量的验证四个阶段。本文的验证环境建立在Sun Blade 2000工作站上，通过集成SCV验证库以及相应的编译、连接和调试工具构建而成。4×4包交换芯片系统级功能模型的验证工作在各阶段的时间开销分别为30h、15h、35h和45h。

2.1 基于直接随机测试向量的验证

针对规范1～规范3的验证，采用直接随机测试向量的验证方法。在描述中，包的数据部分被定义为sc_int8>的整数类型，它的有效数值范围是[-128，127]；包的目的端口号被定义为dest[0]～dest[3]的布尔变量类型，它的有效数值范围是[0，15]；而包的源端口号则在实例化的过程中被分别对应标记为0～3。因此，采用SCV生成直接随机测试向量用数据包的过程主要是随机化包的目的端口号和包的交换数据，如下所示：

//生成包的目的端口号
sc_uint4> dest;
scv_smart_ptrd;
d->keep_only(1,15);
d->next();
dest=(sc_uint4>)*d;
pkt_data.dest0=dest[0];
pkt_data.dest1=dest[1];
pkt_data.dest2=dest[2];
pkt_data.dest3=dest[3];
//生成包的交换数据
scv_smart_ptrp;
p->keep_only(-128,127);
p->next();
pkt_data.data=(sc_int8>)*p;

从生成的10 000个随机数据包中任意截取10个，得到如表1所示的结果。由表1可以看出：

(1)包的目的端口号是随机的数字0～3，包的数据是随机的数据-128～+127。
(2)输入模块可以正确地将发送包送入各个输入端口，
输出模块可以正确地从输出端口读出输出包。
(3)发送包目的端口号的个数等于输出包的总数。
以上结果表明，4×4包交换芯片系统级模型的每个端口均可以正确地发送或者接收数据包，每个输入端口均可以正确地将数据包传送到多个不同的端口。
在某时间段内，采集R0～R3移位前后的数值，得到如表2所示的结果。 由表2可以看出：

(1)若FIFO中有新的数据包，则各个寄存器能够从对应的FIFO中正确地读取这些新的数据包；否则，各个寄存器将保持当前值。
(2)各个寄存器接收新的数据后就进行移位，移位的顺序是R3→R2→R1→R0→R3。

2.2 基于带权重的随机测试向量的验证

针对规范4的验证，采用带权重的随机测试向量的验证方法。在测试中，端口0作为测试向量的输入端口，端口0、1、2、3作为测试向量的输出端口。其中，端口0、1、2、3的包输出比例分别为70%、10%、10%和10%。因此，采用SCV生成Sender0带权重的随机测试向量用数据包描述为：

if(pkt_data.id==0)
{scv_bagdist; //定义含权重分布信息的包用于随机化

dist.add(1,70); //定义OUT0的输出比例
dist.add(2,10); //定义OUT1的输出比例
dist.add(4,10); //定义OUT2的输出比例
dist.add(8,10); //定义OUT3的输出比例
scv_smart_ptrd; //对带权重的包随机化
d->set_mode(dist);
d->next();
dest=(sc_uint4>)*d; //赋数据包目的端口号
pkt_data.dest0=dest[0];
pkt_data.dest1=dest[1];
pkt_data.dest2=dest[2];
pkt_data.dest3=dest[3];
}

使Sender0生成10 000个随机数据包，得到如表3所示的结果。可以看出：每个输出端口输出数据包数目的比例与设定比例基本一致。

2.3 基于带约束的随机测试向量的验证

针对规范5的验证，采用带约束的随机测试向量的验证方法。在验证中，采用的验证策略为：当FIFO1非空时，Sender1发送非正整数的数据包；当FIFO1为空时，Sender1发送正整数的数据包。因此，采用SCV生成Sender1带约束的随机测试向量用数据包的约束定义为：

class fifoconstraint: public scv_constraint_base{
public:
scv_smart_ptr data;
scv_smart_ptr fifo.in1.status;
SCV_CONSTRAINT_CTOR (fifoconstraint){
SCV_CONSTRAINT(*data=0!fifo.in1.
status);
SCV_CONSTRAINT(*data>0 fifo.in1.status);}
};

在某时间段内，从生成的10 000个随机数据包中，采集一部分FIFO1和各端口中的数值，得到如表4所示的结果。由表4可以看出，当发送包的数据部分为非正整数时，FIFO1无交换数据输入，输出端也无交换数据输出；当发送包的数据部分为正整数时，FIFO1读入交换数据，相应输出端也输出交换数据。即当FIFO1非空时，Sender1发送了非正整数的数据包，表示数据包不能送入FIFO1；当FIFO1为空时，Sender1发送了正整数的数据包，数据包可以送入FIFO1。

从SoC的RTL级开始进行的验证工作容易造成设计周期的长跌宕，因此，在更高层次的系统级寻求高效的功能验证方法具有十分重要的现实意义。实验结果表明，本文提出的基于随机向量的SoC系统级功能验证方法，不仅能够获得较好的功能覆盖率，而且能够尽早地发现SoC的功能性错误。此外，还说明：

(1)三种随机验证方法对功能规范的依赖程度、时间开销和验证效率不尽相同。直接随机测试向量生成方法对功能规范的依赖程度最低，但时间开销最高、验证效率最低；带权重的随机测试向量生成方法对功能规范的依赖程度较高，但时间开销最低、验证效率较高；带约束的随机测试向量生成方法对功能规范的依赖程度最高，但时间开销较高、验证效率最高。在实际的验证工作中可以选择其中一种或组合两种以上的方法进行验证。

(2)直接随机测试向量生成方法适用于做黑盒测试验证，适于对验证对象进行定性分析；带权重的随机测试向量和带约束的随机测试向量方法适用于做白盒测试验证，适于对验证对象做定量分析。