CN114970411A - 一种仿真验证方法及系统 - Google Patents

Abstract

本申请实施例公开了一种仿真验证方法及相关设备，用于减少芯片仿真验证的工作量。本申请实施例方法包括：预先定义系统芯片端的一部分存储空间为目标交互空间；其中，功能模块包括多个用例，其中一个用例通过循环执行如下三个步骤完成激励输入：步骤一、验证平台端对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；步骤二、所述系统芯片端查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；步骤三、所述验证平台端等待所述目标交互空间中的读写完成标识后，跳转到步骤一。

Description

一种仿真验证方法及系统

技术领域

本申请实施例涉及一种芯片仿真领域，尤其涉及一种芯片仿真验证方法及系统。

背景技术

系统级芯片(SOC，system on chip)，也称为片上系统。SOC的定义是将中央处理器(CPU，central processing unit)、模拟知识产权(IP，intellectual property)核、数字IP核和存储器集成到单一芯片上，形成系统级芯片。当前随着应用的发展，SOC的性能越来越强，规模也越来越大，这使得SOC设计的复杂度大大提高。在SOC设计中，仿真与验证就成为SOC设计流程中最复杂、最耗时的环节。

目前针对SOC的系统验证方法主要有两种，一种是直接在SOC上开发测试激励，这对验证人员要求较高，而且很难实现带约束的随机激励，从而实现数据的自动比对。另外一种是将SOC中的CPU替换成总线功能模型(BFM，bus function model)，这样方便验证人员开发带约束的测试激励，但是到了前仿真或后仿真的测试激励的验证环节，由于网表的后仿真，不能使用前仿真的随机测试激励，需要重新再写测试激励，工作量较大。

发明内容

本申请实施例提供了一种仿真验证方法及系统，用于减少芯片仿真验证的工作量。

本申请实施例第一方面提供了一种仿真验证方法，包括：

预先定义系统芯片端的一部分存储空间为目标交互空间；

功能模块包括多个用例，其中一个用例通过循环执行如下三个步骤完成激励输入：

步骤一、验证平台端对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；

步骤二、所述系统芯片端查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；

步骤三、所述验证平台端等待所述目标交互空间中的读写完成标识后，跳转到步骤一。

本申请实施例提供了一种仿真验证方法，系统芯片端和验证平台端通过对交互空间进行赋值，执行对应的读写操作，从而实现系统芯片端的软件与验证平台端相互协同的仿真验证方法。

本申请实施例第二方面提供了一种仿真验证方法，包括：

预先定义系统芯片端的一部分存储空间为目标交互空间；

功能模块包括多个用例，其中一个用例通过循环执行如下三个步骤完成激励输入：

步骤一、验证平台端对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；

步骤二、所述系统芯片端查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；

步骤三、所述验证平台端等待所述目标交互空间中的读写完成标识后，跳转到步骤一。

可选地，所述目标交互空间包括：第一空间、第二空间、第三空间及第四空间；所述第一空间用于存储数据读写标识；所述第二空间用于存储读写数据地址，所述第三空间用于存储读写数据，所述第四空间用于存储读写完成标识。

可选地，

所述步骤二包括：

所述系统芯片端查询所述目标交互空间中的所述读写标识位；

若所述读写标识位为读，所述系统芯片端根据所述第二空间中的地址位，获取所述地址位对应的目标数据，并把所述目标数据写入所述第三空间，并设置所述第四空间存储的所述读完成标识为已完成；

可选地，

所述步骤二包括：

所述系统芯片端查询所述目标交互空间中的所述读写标识位；

若所述读写标识位为写，所述系统芯片端将所述第三空间的数据写入所述第二空间对应的地址，并设置所述第四空间存储的写完成标识为已完成；

可选地，

所述步骤一包括：

若针对一用例，当所述用例为前仿真时，所述验证平台端通过设计激励程序以对所述目标交互空间进行前仿真赋值。

可选地，

所述步骤一还包括：

若针对所述用例，当所述用例为后仿真时，根据所述目标交互空间找到所述前仿真和所述后仿真的路径关系；

所述验证平台端根据所述后仿真的所述路径关系对所述目标交互空间进行后仿真赋值；其中，所述后仿真赋值和所述前仿真赋值相同。

可选地，当所述功能模块的一个用例的激励输入完成后，所述方法还包括：

步骤四：所述验证平台端根据所述用例产生输出数据；

所述验证平台端通过接口模块，从所述系统芯片端的所述功能模块输出接口采集到所述输出数据。

可选地，所述方法还包括：

在对一个用例执行激励输入时，所述验证平台端会同时执行如下步骤：

在所述验证平台端为所述功能模块设计参考模型，并将同一用例的激励程序发送给所述功能模块的所述参考模型，以使得所述参考模型根据所述激励程序，计算参考结果。

可选地，所述方法还包括：

步骤五：所述验证平台端的比较器接收所述验证平台端的采集器采集到的所述功能模块的输出数据，并接收所述验证平台端产生的所述参考结果；

所述验证平台端将所述参考结果与所述输出数据进行比较，并输出比较结果，以完成所述功能模块的一个用例的仿真验证。

本申请实施例提供了一种仿真验证方法，验证平台端通过对系统芯片端的交互空间中的各个地址进行赋值，从而使得系统芯片端根据各个地址的赋值信息执行对应的读写操作，从而使得系统芯片端完成对应的前后仿真。然后将系统芯片端最终的仿真结果与验证平台端的仿真结果进行数据比对，从而实现最终的仿真验证。

本申请实施例第三方面提供了一种仿真验证系统，包括：

定义单元，用于预先定义系统芯片端的一部分存储空间为目标交互空间；

赋值单元，用于对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；

查询并执行单元，用于查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；

跳转单元，用于等待所述目标交互空间中的读写完成标识后，跳转到赋值单元。

本申请实施例第三方面提供的一种仿真验证系统用于执行第一方面所述的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例提供了一种仿真验证方法，通过在验证平台开发数据读写操作指令，以让系统芯片执行对应的数据读写操作，从而验证人员只需在验证平台上开发测试激励，减少了开发测试激励难度。与此同时，由于测试激励不需要考虑系统芯片是进行前仿真还是后仿真，因此，网表的前后仿真可以共用一套测试激励，减少了验证人员的工作量。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种仿真验证的架构示意图；

图2为本申请实施例公开的一种仿真验证的交互示意图；

图3为本申请实施例公开的一种仿真验证方法的流程示意图；

图4为本申请实施例公开的一种仿真验证系统的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

SOC称为系统级芯片，也称为片上系统。SOC的定义是将中央处理器CPU、模拟IP核、数字IP核和存储器集成到单一芯片上，形成系统级芯片。当前随着应用的发展，SOC的性能越来越强，规模也越来越大，这使得SOC设计的复杂度大大提高。在SOC设计中，仿真与验证就成为SOC设计流程中最复杂、最耗时的环节。

目前针对SOC的系统验证方法主要有两种，一种是用C语言直接开发测试激励，这对验证人员要求较高，而且很难实现带约束的随机，以及实现数据的自动比对。另外一种是将SOC中的CPU替换成BFM，这样方便验证人员利用System Verilog开发带约束的测试激励，但是到了后端的网表验证仿真，由于整个设计已被后端综合工具综合成网表，就不能用BFM模型去替换CPU，所以网表的后仿真就只能开发C语言的测试激励，这样就不能重用前仿真的随机测试激励，需要重新再写C程序激励，且工作量较大。

可以理解的是，System Verilog结合了来自Verilog、VHDL、C++的概念，还有验证平台语言和断言语言，也就是说，它将硬件描述语言(HDL，hardware descriptionlanguage)与现代的高层级验证语言(HVL，high-level validation language)结合了起来。使其对于进行当今高度复杂的设计验证的验证工程师具有相当大的吸引力。

还可以理解的是，BFM里面有需要主动触发的动作，以及被动接受的动作。主动触发的动作，你写成task，这样方便在test case中调用。

其中，带约束的随机激励在本申请实施例中主要描述的是一段带有约束条件的程序激励。还可以理解的是，用C语言写测试激励时，因为C语言的程序特性，就需要写多个C-Code，也就是说，每一个模块都需要写一段对应的C程序，而且写多段C语言比较麻烦。于此同时，在同一模块下的随机性也不好做，同时数据结果的自动比对不好做。还可以理解的是，用SV语言写激励，因为C语言不能直接执行SV程序中的数据，就需要先用SV语言写一个虚拟的CPU以模拟BFM时序，从而用BFM替换CPU，以调用SV的数据，这样的做法是随机性好，而且自动比对好做，不难理解的，这是基于SV语言的特性，属于硬件描述语言。但在后端仿真验证时，使用SV语言在前端反正验证时写的用例，后端仿真不能使用，因为后端仿真针对的是网表数据，找不到CPU的位置，很难做替换。

由此，本申请实施例提供了一种仿真验证方法及系统，也就是通过C语言开发出来的程序与SV语言开发出来的程序共享一部分存储空间，SV语言通过C语言修改共享存储空间的内容，即使在后端仿真验证时，共享的存储空间是可以被找出来的，前端或后端验证，主体都是通过C语言程序实现的，但激励数据，是通过SV语言写进去的。所以，本申请结合C和SV两种语言的优势，且在前端和后端验证都能使用一套激励，编程工作量大大减少。

请参阅图1，图1为本申请实施例公开的一种仿真验证的架构示意图，包括验证平台端101与系统芯片端102。验证平台端101与系统芯片端102相连。

其中验证平台端101，是一个以System Verilog类库为主体的验证平台开发框架，验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境。换言之，验证平台端101是用通用验证方法学(UVM，universal verification methodology)和SV共同开发的。

可以从图1看到，验证平台端101还包括各模块的接口1011，各模块的采集器1012，各模块的参考模型1013及各模块的比较器1014等。

其中，该模块接口1011主要作为验证平台端101与系统芯片端102的连接接口，该模块接口1011主要用于收发数据的通道，不难理解的是，该模块接口1011也可以起到其他作用，例如，可以当验证仿真电路时，可以将电信号或者是模拟信号进行转化，转化为模拟信息或电信号，但最终，数据或信号都是需要通过模块接口1011进行收发操作。

各模块的采集器1012是负责收集系统芯片端102所输出的各种数据或信号的一种系统模块，在本实施例中，采集器1012主要是负责收集系统芯片端102所输出的前仿真或后仿真的仿真数据。当采集器1012收集到系统芯片端102的输出结果后，就会将该输出结果传输至各模块的比较器1014。

各模块的参考模型1013是一种根据激励程序，计算参考结果的系统模块。它通过接收验证平台端101所产生的激励数据，采用比SV语言更高一层级的语言对该激励数据进行验证，从而得到最终的计算结果。可以理解的是，本实施例并不对参考模型1013所运行的语言环境进行限制。当参考模型计算出激励数据的结果后，就会将最终的参考结果传输至各模块的比较器1014。

各模块的比较器1014是一种实现数据自动比对的系统模块，在本申请实施例中，比较器1014实现参考结果和实际待测设计的结果的自动比对。具体的，对两个或多个数据项进行比较，以确定它们是否相等，或确定它们之间的大小关系及排列顺序称为比较，能够实现这种比较功能的电路或装置称为比较器。在本实施例中，比较器1014比对两个结果的一致性，一般包括数据，时序等。

系统芯片端102在本实施例中为一种待测设计SOC，其中，系统芯片端102包括了中央处理器CPU1021，C-Code存储器1022及存储器1023，其中存储器有多个，存储器1023仅为其中一个存储器。在本实施例中，存储器1023仅为系统芯片端102的一部分存储空间，它作为验证平台端101与系统芯片端102的交互空间。可以理解的是，每个存储器运行SOC中不同模块的程序，CPU1021通过BUS总线控制每个存储器中所运行的程序。C-Code1022，在本申请实施例中就是执行程序空间，用于执行对应的C软件代码。为方便理解，后续对于C-Code1022的描述以执行程序空间进行描述，后续不再对此进行赘述。

存储器1023作为系统芯片端102中一部分的存储空间，里面主要包含了4个地址，分别是RW_FLG；RW_ADDR；RW_DATA；RW_DONE。每个地址根据对应的程序执行对应的程序动作。CPU1021一直循环查询存储器1023的运行情况和运行结果。但需要注意的是，存储器1023不能作为CPU1021运行软件的数据和程序空间。

还需要理解的是，总线(Bus)是计算机各种功能部件之间传送信息的公共通信干线，它是由导线组成的传输线束，按照计算机所传输的信息种类，计算机的总线可以划分为数据总线、地址总线和控制总线，分别用来传输数据、数据地址和控制信号。总线是一种内部结构，它是CPU、内存、输入、输出设备传递信息的公用通道，主机的各个部件通过总线相连接，外部设备通过相应的接口电路再与总线相连接，从而形成了计算机硬件系统。在计算机系统中，各个部件之间传送信息的公共通路叫总线，微型计算机是以总线结构来连接各个功能部件的。

由此，可以看出，验证平台端101通过后门操控系统芯片端102中的存储器1023，以达到控制系统芯片端102的作用。

请参阅图2，图2为本申请实施例公开的一种仿真验证的交互示意图。该交互示意图主要包括三大模块。CPU，交互空间及SV/UVM验证平台。

其中，CPU和交互空间在待测设计SOC上，也就是本申请实施例所描述的系统芯片端上，SV/UVM验证平台即为本申请实施例所描述的验证平台端。

交互空间主要包含4个地址，其中地址1定义为数据读写标识(RW_FLG)，地址2定义为读写数据的地址(RW_ADDR)，地址3定义为读写的数据(RW_DATA)，地址4定义为读写完成标识(RW_DONE)。CPU通过对应的C软件代码，并根据对应的地址进行操作。需要说明的是，该数据读写标识或读写完成标识即为前述部分中所描述的数据读写标识或读写完成标识，为方便描述，后续若出现标识字样即可以标识代替，即数据读写标识或读写完成标识代替为数据读写标识或读写完成标识，后续不再对此进行赘述。

SV/UVM验证平台可以通过后门直接操作交互空间，通过编译SV语言，将操作进行封装，封装成读写两个任务，以让交互空间的地址执行对应的读写任务。

请参阅图3，图3为本申请实施例公开的一种仿真验证方法的流程示意图。根据本申请实施例公开的一种仿真验证方法，可以有效减少验证人员的工作量，方便维护验证平台和测试激励；更便捷的实现激励的随机和结果的自动比对；随机测试激励完全不用C语言开发，有效降低了对验证的要求；网表后仿真和前仿真可以共用一套随机测试激励，减少重复开发工作。

具体的，包括步骤301-步骤307。

301、定义系统芯片端的一部分存储空间为目标交互空间。

在对SOC进行仿真验证之前，也就是对SOC软硬件协同验证之前，需要先定义CPU的存储空间，因为CPU是需要跑程序，同时还有处理数据的时候都需要运用到存储空间。CPU上运行的是C软件代码，但是C语言程序是不能运行SV语言的，因此，需要定义CPU上的一部分存储空间，使得SV语言能够在SOC上运行。需要注意的是，本实施例中，系统芯片端即为SOC，为方便描述，以SOC对系统芯片端进行描述，后续不再对此进行赘述。

具体的，定义CPU的一部分存储空间作为软硬件交互空间，需要注意的是这片空间不能作为CPU运行软件的数据和程序空间。其中，SOC将地址1定义为数据读写标识(RW_FLG)，地址2定义为读写数据的地址(RW_ADDR)，地址3定义为读写的数据(RW_DATA)，地址4定义为读写完成标识(RW_DONE)。具体的，数据读写标识包括数据读标识及数据写标识；读写数据的地址包括读数据的地址及写数据的地址；读写的数据包括读数据及写数据；读写完成标识包括读完成标识及写完成标识。

当对CPU的存储空间进行定义后，需要编译相对应的C软件代码。具体的，该C软件代码所需要执行的具体步骤为：

CPU一直循环查询地址1数据读写标识，当地址1数据读写标识为读标识，就对地址2数据读的地址读出数据，并将读到的数据存储到地址3上，然后将地址4读完成标识设置为1，该步骤即为读程序执行的步骤，即读操作。

如果查询到地址1上的数据读写标识是写标识，就将地址3的需要写的数据，写到地址2数据对应的地址上去，然后把写完成标识设置为1，该步骤即为写程序执行的步骤，即写操作。

不难理解的是，数据读写标识是需要自己去定义，比如可以定义'h55为读标识，定义'haa为写标识。只要自己能区分读写标识就行。

还可以理解的是，读完成标识1或写完成标识1中“1”的意思就是表示对应的读写操作完成，及对应的读写程序完成，为方便描述，后续不再对“1”的意义进行描述。

当编译好在交互空间运行的C软件代码后，利用编译工具编译成bin文件，然后转成hex文件。在验证平台端将hex文件通过后门装载到CPU执行程序空间，以使得CPU根据该程序在交互空间中执行对应的读写操作。

可以理解的是，hex文件格式是可以烧写到单片机中，被单片机执行的一种文件格式，生成hex文件的方式有很多种，可以通过不同的编译器将C程序或者汇编程序编译生成hex。在本实施例中，hex文件是C程序通过编译工具(如keil)生成的。

还可以理解的是，在验证平台端将hex文件通过后门装载到CPU执行程序空间就是将hex文件导入到memory存储空间，这里后门指的是，通过$readmemh系统函数，把这个文件导入到memory存储空间中，即执行程序空间。

302、验证平台端对目标交互空间进行赋值。

验证平台端对目标交互空间进行赋值，目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位。

具体的，在验证平台端，可以通过后门直接操作软硬件交互空间，也就是将操作方式封装成读写两个任务。换言之，利用SV程序直接操作memory存储空间，也就是直接给memory特定地址直接赋值，封装成读写两个task。

需要理解的是，若针对某一个具体的测试激励，该测试激励在SV程序中编译的是前仿真测试激励时，那么验证平台端通过设计激励程序对交互空间进行前仿真赋值。若针对某一个具体的测试激励，该测试激励在SV程序中编译的是后仿真测试激励时，系统芯片端根据交互空间找到前仿真和后仿真的路径关系，其中，在本实施例中，路径关系就是地址2的值。然后验证平台端根据该路径关系对交互空间进行后仿真赋值；其中，在本实施例中，后仿真的赋值和前仿真的赋值可以相同。还需要理解的是，后仿真的赋值与前仿真的赋值也可以不同，但本实施可以通过相同的赋值，进行仿真验证。

由于在本实施例中，前仿真和后仿真的赋值相同，只是对应的程序不同，由此本实施中，验证平台端对目标交互空间进行赋值，具体的，其中一个实施例为：

当是读task时，对地址addr，读数据：先对地址2的读写数据的地址赋值为addr，再对地址1的数据读写标识赋值为0x55(读标识)，该步骤即为读任务。

当是写task时，对addr，写数据data：先对地址2的读写数据的地址赋值为addr，再对地址3的读写的数据赋值为data，然后对地址1的数据读写标识赋值为0xAA(写标识)，该步骤即为写任务。

可以理解的是，对于地址1，地址2，地址3的赋值还可以是其他数值，本实施例所描述的具体数值仅为其中一个具体的实施例，还需要理解的是，对应地址1或地址2或地址3赋值的步骤，可以不分先后，例如，对于写task，可以先对地址1赋值，再对地址2赋值，最后对地址3赋值；还可以先对地址2赋值，再对地址1赋值，最后对地址3赋值。为方便描述，后续不再对赋值的步骤先后进行赘述。

当对交互空间的地址进行赋值后，CPU就会获取到对应地址的数据，然后将对应地址的数据通过BUS总线写入到执行程序空间，以使得执行程序空间根据对应地址的数据进行仿真。为方便描述，后续不再对此进行描述，但需要说明的是，交互空间地址的数据与执行程序空间地址的数据互相对应，也就是说，写入到交互空间的数据，对应的，执行程序空间也会获取到该数据，但是，该数据会在执行程序空间进行仿真，最后获取到仿真结果后，CPU就能将该仿真结果传输至交互空间，以让交互空间也获取该仿真结果。

303、系统芯片端查询目标交互空间中的读写标识位，根据标识位，在系统芯片端完成读写操作，产生读写完成标识。

系统芯片端中的CPU一直在查询交互空间中地址1的数据读写标识，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识。

具体的，当地址的数据读写标识被赋值为读标识后，CPU就对地址2数据读的地址读出数据，并将读到的数据存储到地址3上，然后将地址4读完成标识设置为1。需要注意的是，根据步骤302可知，地址1及地址2已被验证平台端赋值。

当地址的数据读写标识被赋值为写标识后，CPU就就将地址3的要写的数据，写到地址2写数据对应的地址上去，然后把写完成标识设置为1。需要注意的是，根据步骤302可知，地址1、地址2及地址3已被验证平台端赋值。

需要理解的是，当把读完成标识或写完成标识设置为“1”时，即代表读操作或写操作完成。

对应的，当进行写步骤时，由于交互空间不运行程序，当验证平台端对地址1、地址2及地址3赋值后，执行程序空间就会获取到地址1、地址2及地址3的值，然后根据对应的程序指令运行对应的程序步骤，即在步骤301中所描述的写程序步骤。

当进行读步骤时，由于交互空间不运行程序，当验证平台端对地址1及地址2赋值后，执行程序空间就会获取到地址1及地址2值，然后根据对应的程序指令运行对应的程序步骤，即在步骤301中所描述的读程序步骤。

304、验证平台端等待目标交互空间中的读写完成标识。若循环，执行步骤302；或，执行步骤305。

验证平台端会通过后门查询交互空间中的读写完成标识，若仍有激励输入。可继续执行步骤302，或，执行步骤305。在本实施例中，激励输入可以理解为验证平台端对交互空间进行赋值。

验证平台端会通过后门一直查询交互空间中的读写完成标识，具体的，当验证平台端查询到交互空间中的读完成标识为已完成后，就会获取地址3上存储的读数据。若验证平台端仍对交互空间进行激励输入，就可以执行步骤302，若验证平台端对交互空间不再进行激励输入，就执行步骤305。

当验证平台端查询到交互空间中的写完成标识为已完成后，若验证平台端仍对交互空间进行激励输入，就可以执行步骤302，若验证平台端对交互空间不再进行激励输入，就执行步骤305。

因为CPU一直在循环查询读写标识，当查询到读写标识后，就通过CPU完成相应的读写操作。

305、系统芯片端根据用例产生输出数据，验证平台端通过接口模块，从系统芯片端的功能模块的输出接口采集到输出数据。

在步骤302中，进行写任务后，由于地址1、地址2及地址3已被验证平台端赋值，由此，当CPU查询到交互空间的读写标识位为写标识时，CPU就将该操作翻译成写操作，将对应的操作指令写到BUS总线上去，然后BUS总线将对应的操作指令以及对应地址的赋值写入到执行程序空间，以让执行程序空间进行仿真验证，从而产生仿真结果。

对应的，在步骤302中，进行读任务后，由于地址1及地址2已被验证平台端赋值，由此，当CPU查询到交互空间的读写标识位为读标识时，CPU就将该操作翻译成读操作，并将对应的操作指令写到BUS总线上去，然后BUS总线将对应的操作指令以及对应地址的赋值写入到系统芯片端的对应的寄存器，完成之后把读到数据写到交互空间的地址3上。

由此，验证平台端可以读到地址3上的数据，具体的，该用例在本实施例中，可以理解为一种激励输入的数据。

具体的，验证平台端通过接口模块，从系统芯片端的功能模块采集到输出数据，即仿真结果数据。

可以理解的是，在验证平台端，用System Verilog可以直接可以调用步骤302中封装好的读写任务，这样就方便验证人员开发带随机的约束激励。带约束的随机激励通过读写task可以操作SOC内部的软硬件交互存储空间，CPU一直在轮询查询软硬件交互存储空间中的读写标识，将随机激励的相应读写操作转换成CPU发送到BUS总线上去，从而实现了通过后门操作到CPU真正软件操作。SOC中有一些模块还需要从接口输入数据，所以测试激励还可以通过接口模块发送激励数据给到待测的SOC模块中。本实施例并不对SOC接收激励数据的方式进行限制，后续也不再对此进行赘述。

还需要理解的是，在本实施例中，带随机的约束激励是一种带约束的随机变量。

307、验证平台端为功能模块设计参考模型，并将同一用例的激励程序发送给参考模型，以使得参考模型根据激励程序，计算参考结果。

在验证平台端为一功能模块设计参考模型，并将同一用例的激励程序发送给该功能模块的参考模型，以使得参考模型根据对应的激励程序，计算出参考结果。需要理解的是，该参考模型的运行语言相比较于SV语言，是更高级的语言，因此可以对激励程序进行对应的仿真验证。

对应的，当在验证平台端设计好激励程序后，也会将激励程序通过后门输出到系统芯片端中的交互空间，具体的，该输出方式主要将读写任务封装成读写两个task，从而对交互空间对应的地址进行赋值。当系统芯片端查询到对应的读写标识后，就进行读写操作，从而系统芯片端将根据激励程序进行仿真后的仿真结果输出到验证平台端的比较器。

不难理解的是，步骤307主要分为两个动作，一个是将激励程序输出至系统芯片端上的交互空间，也就是说步骤307可以在步骤301之后；另一个是将参考结果输出到验证平台端的比较器上进行比较，也就是说步骤307只需在步骤306之前。但需要说明的是，因为步骤302-步骤304进行循环，所述步骤307可以不与步骤302-步骤304存在先后关系。可以先执行步骤307，再执行步骤302-步骤304，也可以同步继续，此处不对步骤的先后顺序进行限定。

306、验证平台端对参考结果与输出数据进行比较，并输出比较结果。

当参考模型计算出参考结果后，会把该参考结果发送给比较器。同时，各模块通过各自的端口，采集待测设计SOC的计算结果，并发送到比较器。比较器实现参考结果和实际待测设计的结果的自动比对。这样无论是网表前仿真，还是网表后仿真，都可以用同一套C软件代码，而且由于开发验证的激励都是基于System Verilog，所以验证平台和开发的带约束的随机激励都可以在后仿真中得到重复使用，这样大大减少了验证的工作量，也方便后期的维护。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

若方案涉及敏感信息(如用户信息、企业信息)，则应当说明针对敏感信息的收集、使用和处理需要遵守相关国家和地区的法律法规和标准，且需要在相应主体(如用户或企业等)许可或同意的情况下进行。

由此，可以看出，通过本实施例提出的一种仿真验证方法，网表后仿真和前仿真共用一套随机测试激励和测试平台，大大减少验证工作量；验证人员不用单独开发C程序激励，只需开发带约束的随机激励和数据自动比对，这样能够充分利用带随机的测试激励，使验证能够更快收敛。通过大量带约束随机激励使验证更充分，更完备。相对于单纯写C程序测试激励，本方法将对硬件的操作转换为CPU软件操作，可以利用System Verilog验证语言实现更灵活的随机激励，同时也更方便实现数据的自动比对。

上面对本申请实施例中的一种仿真验证方法进行了描述，下面对本申请实施例中的一种仿真验证系统的结构进行描述，请参阅图4，一种仿真验证系统的结构包括：

定义单元401，用于预先定义系统芯片端的一部分存储空间为目标交互空间；

赋值单元402，用于对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；

查询并执行单元403，用于查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；

跳转单元404，用于等待所述目标交互空间中的读写完成标识后，跳转到赋值单元。

本实施例提供了一种仿真验证系统，通过对交互空间中的各个地址进行赋值，从而使得系统根据各个地址的赋值信息执行对应的读写操作，并使得系统完成对应的前后仿真。然后系统将最终的仿真结果进行数据比对，从而实现最终的仿真验证。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，read-onlymemory)、随机存取存储器(RAM，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种仿真验证方法，其特征在于，所述方法包括：

预先定义系统芯片端的一部分存储空间为目标交互空间；

功能模块包括多个用例，其中一个用例通过循环执行如下三个步骤完成激励输入：

步骤一、验证平台端对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；

步骤二、所述系统芯片端查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；

步骤三、所述验证平台端等待所述目标交互空间中的读写完成标识后，跳转到步骤一。

2.根据权利要求1所述的方法，其特征在于，所述目标交互空间包括：第一空间、第二空间、第三空间及第四空间；所述第一空间用于存储数据读写标识；所述第二空间用于存储读写数据地址，所述第三空间用于存储读写数据，所述第四空间用于存储读写完成标识。

3.根据权利要求2所述的方法，其特征在于，

所述步骤二包括：

所述系统芯片端查询所述目标交互空间中的所述读写标识位；

若所述读写标识位为读，所述系统芯片端根据所述第二空间中的地址位，获取所述地址位对应的目标数据，并把所述目标数据写入所述第三空间，并设置所述第四空间存储的所述读完成标识为已完成。

4.根据权利要求2所述的方法，其特征在于，

所述步骤二包括：

所述系统芯片端查询所述目标交互空间中的所述读写标识位；

若所述读写标识位为写，所述系统芯片端将所述第三空间的数据写入所述第二空间对应的地址，并设置所述第四空间存储的写完成标识为已完成。

5.根据权利要求1所述的方法，其特征在于，

所述步骤一包括：

若针对一用例，当所述用例为前仿真时，所述验证平台端通过设计激励程序以对所述目标交互空间进行前仿真赋值。

6.根据权利要求5所述的方法，其特征在于，

所述步骤一还包括：

若针对所述用例，当所述用例为后仿真时，根据所述目标交互空间找到所述前仿真和所述后仿真的路径关系；

所述验证平台端根据所述后仿真的所述路径关系对所述目标交互空间进行后仿真赋值；其中，所述后仿真赋值和所述前仿真赋值相同。

7.根据权利要求1所述的方法，其特征在于，当所述功能模块的一个用例的激励输入完成后，所述方法还包括：

步骤四：所述系统芯片端根据所述用例产生输出数据；

所述验证平台端通过接口模块，从所述系统芯片端的所述功能模块的输出接口采集到所述输出数据。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

在对一个用例执行激励输入时，所述验证平台端会同时执行如下步骤：

在所述验证平台端为所述功能模块设计参考模型，并将同一用例的激励程序发送给所述功能模块的所述参考模型，以使得所述参考模型根据所述激励程序，计算参考结果。

9.根据权利要求7所述的方法，其特征在于，所述方法还包括：

步骤五：所述验证平台端的比较器接收所述验证平台端的采集器采集到的所述功能模块的输出数据，并接收所述验证平台端产生的所述参考结果；

所述验证平台端将所述参考结果与所述输出数据进行比较，并输出比较结果，以完成所述功能模块的一个用例的仿真验证。

10.一种仿真验证系统，其特征在于，所述系统包括：

定义单元，用于预先定义系统芯片端的一部分存储空间为目标交互空间；

赋值单元，用于对所述目标交互空间进行赋值，所述目标交互空间包括读写标识位、读写地址、读写数据以及读写完成标识位；

查询并执行单元，用于查询所述目标交互空间中的所述读写标识位，根据标识位，在所述系统芯片端完成读写操作，产生读写完成标识；

跳转单元，用于等待所述目标交互空间中的读写完成标识后，跳转到赋值单元。

Images