CN100514296C - 自动化仿真方法及系统 - Google Patents

Abstract

本发明公开了一种自动化仿真的方法，由具有信息处理能力的装置通过执行脚本完成仿真，该方法包括步骤：启动执行脚本开始验证项目；执行脚本启动激励脚本和配置脚本分别产生激励信号和生成配置文件；执行脚本启动仿真器运行仿真脚本对被测对象进行仿真，被测对象接收激励信号和读取配置文件，并保存仿真过程产生的响应数据；执行脚本启动数据对比脚本和结果分析脚本，将响应数据与预期值进行比较，输出分析结果。本发明同时还公开了一种逻辑自动化仿真系统。

Description

自动化仿真方法及系统

技术领域

本发明涉及仿真技术，特别涉及一种自动化仿真方法及系统。

背景技术

无线通信设备的基带部分处理主要采用数字方式实现的物理层协议和数字信号处理算法。根据实现方式的不同，可将现有技术中的实现方式分为：软件、硬件或软硬件混合三种实现方式。在软硬混合实现方式中，硬件部分实现主要采用专用集成电路(ASIC)/现场可编程门阵列(FPGA)方式。但是，由于ASIC/FPGA具有设计规模大，结构复杂，验证难度大的特点，所以，随着逻辑芯片的规模越来越大，复杂度不断提高，逻辑仿真验证的工作量呈指数倍增长，进而不利于实现且增加了成本。

在现有技术中，常用商用仿真器来完成逻辑仿真验证，该商用仿真器内部集成了脚本运行环境，例如：在Modelsim仿真器本身便嵌入了工具命令语言(TCL)脚本运行环境，并开发了一套专门用于仿真的宏命令集，用户可以在此环境中运行仿真脚本，可以实现一定程度的自动化，如图1所示。

但是，上述方案中，仿真环境是完全封闭的且功能有限，只能运行仿真脚本，没有针对逻辑验证的特点设计专门的逻辑仿真项目管理功能，无法实现对整个仿真项目、测试用例、回归测试等的管理，使得仿真效率及自动化程度很低。另外，由于仿真环境和具体的仿真器相关，对外接口不开放，与其它工具集成困难，其可扩展性、可移植性和可重用性都较差，进而使得用户在增加自己需要的功能时变得非常困难。

发明内容

本发明提供一种自动化仿真方法及系统，以解决现有技术中因不能实现逻辑验证的自动化而导致的效率低的问题。

为解决上述问题，本发明提供如下的技术方案：

一种自动化仿真方法，包括以下步骤：

A、启动执行脚本开始验证项目；

B、执行脚本启动激励脚本和配置脚本分别产生激励信号和生成配置文件；

C、执行脚本启动仿真器，由仿真器接收所述激励信号和读取配置文件；

D、仿真器运行仿真脚本进行仿真，并保存仿真过程产生的响应数据；

E、执行脚本启动数据对比脚本和结果分析脚本，将响应数据与预期值进行比较，输出分析结果。

一种自动化仿真系统，包括用于数据处理的处理器，用于存储程序和数据的存储器，以及仿真平台，该仿真平台包括：

验证脚本模块：由启动执行脚本的命令集构成，用于启动执行脚本来执行测试用例；

仿真器模块：由执行脚本启动，用于运行仿真脚本进行仿真；

验证项目管理模块：用于实现整个验证项目的目录管理、测试用例的执行和回归测试执行，并提供一用户界面供项目管理操作，其中，验证项目的目录用于组织验证过程所需要的相关文件。

其中：所述的仿真平台还包括用户扩展接口模块，通过该扩展接口模块向仿真平台增加工具。

本发明采用适合逻辑仿真自动化的验证项目管理方法，并为用户提供了一个方便的扩展接口，使得用户能够基于此平台完成整个逻辑项目的自动化仿真，大大提高了仿真的规范性和自动化程度，以及仿真项目之间的共享。

附图说明

图1为现有技术的仿真结构框图；

图2为本发明的仿真结构框图；

图3、图4为本发明的仿真平台结构图；

图5为本发明的仿真流程图；

图6为仿真过程示意图；

图7为用户界面示意图；

图8为测试用例与测试平台的对应关系示意图；

图9为验证项目的目录结构示意图；

图10为验证相关文件的目录结构示意图；

图11为脚本对应关系示意图；

图12、图13、图14、图15和图16为工具向导开发模板界面图；

图17A、图17B和图17C为开发工具过程中的流程示意图；

图18为WCDMA上行专用信道激励数据产生工具工作流程图。

具体实施方式

逻辑验证的过程就是对被测对象施加激励，并通过检测其响应来验证逻辑是否正确的过程，如图2A所示。对于简单的逻辑，只需在用硬件描述语言(HDL)编写的测试平台中即可实现激励的提供和响应的比较，因此对于自动化的要求并不高。随着技术的发展，逻辑设计越来越复杂，逻辑的验证难度也大大增加，激励的提供和响应的检测需要采用多种方式实现，例如通过编写C语言程序实现激励数据的产生。对于算法逻辑，激励的产生和响应的检测常常涉及复杂的算法，因此需要采用Matlab、Cossap等算法仿真工具或者自己编写应用程序实现复杂的算法。

实现自动化最常用的办法就是提供统一的工作平台，并实现过程的脚本化。如图2B所示，完成一个测试任务可能需要很多资源，而仿真过程执行包含很多步骤，以往这些资源和步骤之间是相对独立和零散的，管理和执行的效率很低。

参阅图3和图4所示，本发明的系统将资源有机的整合到一起，并通过脚本将仿真过程各个步骤串联起来，从而实现仿真过程的自动执行。

图3显示了一台计算机用它来实施本发明的方法。计算机具有一个处理器，它通过总线和存储器相连接，同时还通过总线连接输入输出接口。

存储器储存了仿真平台程序和相关数据。输入输出接口连接键盘、打印装置和显示器，验证结果和用户界面等通过显示器显示出来，验证结果还通过规定的格式由打印装置以文本形式输出。

图4为算法逻辑仿真平台结构，包括一个验证项目管理模块，该模块实现整个验证项目的目录管理、测试用例的执行和回归测试执行。测试用例的执行是通过调用TCL验证脚本实现的。在平台中，TCL脚本起到“粘贴”的作用，用来将各种应用程序、工具集成起来，从而实现整个验证过程的自动化。此外，平台提供了用户扩展接口，用户可以方便的将自己需要的功能扩展为工具，在验证脚本中调用。例如，用户需要增加产生某种激励数据的功能，可以采用C或其它语言实现该功能并扩展为TCL命令，这样就可以在验证脚本中调用。

算法逻辑自动化仿真平台采用的是TCL脚本语言。该平台不直接控制HDL仿真器，也不直接与仿真器进行数据交换，而是通过脚本间接调用仿真器达到仿真目的，因此可以兼容所有的HDL仿真器，作为通用的逻辑仿真平台。

参阅图7所示，算法逻辑测试平台的验证项目管理模块提供一用户界面。用户界面有三个主要区域：模式控制区、代码显示和编辑区以及状态区，另外还有菜单栏和工具栏。

模式控制区中有三种模式可供选择，分别是测试任务、工具箱和代码浏览，测试任务主要进行测试任务的创建和管理，测试用例管理等功能，采用符合算法逻辑集成仿真规范的目录结构。代码浏览可以显示TCL脚本的基本结构，如名字空间及其中定义的子程序名，双击子程序名可以在右边代码显示和编辑区显示该子程序的代码。工具箱则包含了为具体测试项目开发的各种工具，如WCDMA上行接入信道激励信号产生。工具箱中各种工具提供图形用户界面，为浮动的窗口，用户可以在窗口中进行相关的参数设定。三种模式均采用导航树结构。

参阅图5和图6所示，自动化仿真过程如下：

步骤10：启动执行脚本开始验证项目；

步骤20：执行脚本启动激励脚本和配置脚本分别产生激励信号和生成配置文件，

步骤30：执行脚本启动仿真器，由仿真器运行仿真脚本对被测对象进行仿真；

步骤40：被测对象接收激励信号和读取配置文件，并保存被测对象在仿真过程产生的响应数据；

步骤50：执行脚本启动数据对比脚本和结果分析脚本，将响应数据与预期值进行比较，输出分析结果。

其中，执行脚本可为多个，由验证脚本依次启动该复数个执行脚本，以完成需要进行多个测试任务的验证项目。

为了实现对验证项目的统一管理和规范验证过程，本实施例将验证项目的目录固定下来。每个验证项目都采用同样的目录结构，使用通用的目录结构最大的好处是可以使用相对路径，编写可移植的脚本，而且方便查找文件。

目录结构根据算法逻辑验证的特点来确定。在逻辑验证中，对测试用例进行分组，同组的测试用例使用同一个测试平台(Testbench)。将一组测试用例和其对应的Testbench称为一个验证程序组。对于一个验证项目，可能存在多个验证程序组。参阅图8，测试用例与Testbench的对应关系。

参阅图9，图中示出了验证项目的顶层目录结构：

其中，图中子目录SoC_N为验证项目，每个验证项目包含第一至第六6个子目录，功能分别如下：

第一子目录doc：存放相关的规格、设计和验证文档；

第二子目录beh：存放可重用行为模型、公共子程序和函数等；

第三子目录rtl：存放可综合的设计源代码；

第四子目录syn：存放综合脚本、网表以及综合产生的各种报告文件；

第五子目录phy：存放约束文件、布局布线脚本、烧片文件以及布局布线过程中产生的各种报告文件；

第六子目录verif：存放验证相关的文件，由验证程序组(verisuite)组成，一个程序组包括一组互相关联的测试文件，主要是testbench和与此testbench对应的一组测试用例(testcase)。每个testcase中又包括测试脚本、配置数据文件、激励数据文件、仿真结果数据文件和参考比对数据文件等。

第六子目录verif的目录结构如图10所示。该目录结构充分考虑了testbench的结构以及算法逻辑的特点。

验证程序组子目录verisuite：称为验证程序组，存放为了验证某一类特性所需的测试文件。该组中的所有testcase都使用相同的testbench，每个测试用例具有不同的配置、激励、响应和参考比对数据；

仿真工作子目录work：为仿真工作目录，存放仿真编译结果，并作为临时目录供仿真时进行文件拷贝操作；

脚本子目录scripts：存放仿真中需要被调用的脚本；

配置文件子目录config：存放配置文件；

激励文件子目录stimuli：存放激励数据文件；

仿真结果子目录result：存放仿真输出结果，仿真过程日志文件，代码覆盖率报告及缺陷跟踪表；

对比数据子目录reference：存放仿真参考比对数据；

执行脚本子目录run.tcl：该测试用例的执行脚本，回归测试时执行的也是该脚本；

说明文件子目录readme.txt：该测试用例的详细说明文件。

仿真平台的项目管理功能包括：

·验证项目的创建、删除、导入、导出

用户可以在测试根目录下，创建、删除、导入、导出验证项目。

·验证程序组的创建、删除、导入、导出

用户可以在verif目录下，创建、删除、导入、导出验证程序组。

·测试用例的创建、删除、导入、导出

用户可以在verisuite目录下，创建、删除、导入、导出测试用例。

利用以上功能，验证人员可以很方便的实现测试代码的共享、重用、移植和归档。

测试用例脚本调用关系如图11所示(将testcase作为当前目录)。每个测试用例只有一个执行脚本(run.tcl)，测试用例的执行通过运行该脚本实现。执行脚本将根据具体测试项目的情况，调用其它脚本。这些脚本包括仿真脚本、激励产生脚本、响应比较脚本和结果分析脚本等等。需要简单说明一下仿真脚本的调用方法，对Modelsim仿真器使用如下命令实现。

exec vsim-c-do./scripts/sim.tcl&

回归测试是逻辑验证过程必不可少的部分。使用算法逻辑仿真平台的测试调度器Scheduler，我们能够容易的将需要回归的测试用例加入回归测试组，并保存和自动运行。测试调度器允许用户按指定顺序建立回归测试组，并在指定的时间启动测试，顺序执行其中的测试脚本。

用户扩展接口(平台中称为工具向导或工具箱，以下简称工具向导)作为算法逻辑仿真平台的一部分，也是平台中用户可以进行二次开发的部分，它具有很好的可扩展性和可重用性，界面如图12A。因为在逻辑测试活动中，每个逻辑都有自已不同的特点，用户为了完成验证，需要自己开发一些工具，如激励产生工具、结果分析工具、过程控制工具、脚本生成工具等等。使用用户扩展接口，可以使用户以最少的时间完成向平台增加功能。

工具向导将一个工具需要配置的所有参数分成多个步骤配置，通过一步一步的参数配置来完成所有参数的配置。仿真平提供了工具向导的开发模板，按照此模板开发出来的工具向导，在界面风格、使用方法上都是一样的，这样任何人开发出来的工具向导都是标准的，别人都可以直接使用，而无须在使用方法上进行培训。工具向导完全采用TCL/TK语言开发的，可以在不同的操作系统上运行，具有很好的可移植性。

·工具向导的目录结构

在平台的根目录中有一个专门用来存放工具向导的文件夹ToolWizards，目录结构形式如图12B：

在平台的根目录下有一个目录ToolWizards，所有的工具向导都存放在这个目录中，在每个工具向导目录中又包括两个目录(存放流程图的images目录和存放实现工具的文件的目录pakcage)和两个文件(工具向导界面实现TCL文件和wordpro格式的帮助文件)，其中工具向导界面实现的TCL文件已做成模板文件，用户只需进行简单修改即可完成工具的开发。

·工具向导的界面说明

工具向导只包括三种不同的界面，分别是工具信息(起始步)、参数配置(中间步)和完成(结束步)的页面，其中参数配置可以包括多个页面。

工具信息界面是工具启动后显示的页面，主要显示一些工具的基本信息，使用户对该工具有一个基本的了解。点击左下方的按钮[Help]可以打开本工具帮助文档。工具信息界面如图13所示。

参数配置是工具向导的主要部分，这部分完成工具所有步骤的参数配置，每一个步骤对应一个页面。每个页面都由提示部分和参数配置部分组成，提示部分主要指示本步在整个工具工作流程中的位置，由用户提供所需的图片，嵌入到此页面中，让用户明白现在配置的参数对应工作流程的哪一部分；参数配置部分以可视化方式让用户对参数进行方便的配置。点击左下方的按钮[Help]可以打开本工具帮助文档；点击右下方的按钮[Next>>]可进入参数配置步的下一步参数配置；点击右下方的按钮[<<Back]可返回前一个页面；右上方的下拉式组合框是所有参数步骤的列表，它提供了一个进入其它参数配置页面的快速通道，选择不同的配置步骤可直接进入相应的步骤页面。参数配置界面如图14所示。

如图15所示，完成页面是工具向导的最后一个步骤，页面的左面是参数列表，是所有参数配置情况的一个汇总，将已经配置的所有参数值列出来，参数的值在这里是不能修改的，如果用户需要修改可返回相应的步骤进行修改，这里每个参数名称前都加了一个数字，指示该参数属于哪一步；右边是工具脚本命令编辑区，当用户点击下面的按钮[Make]时便将左边列表中的参数代入工具实现的命令里形成一个TCL脚本命令，显示在工具脚本编辑区里，用户可以在编辑区里对工具脚本进行修改，也可以直接复制和粘贴到验证脚本中；下面是一排命令操作按钮，依次为[Help]：打开本工具的帮助文档，[Clear]：清除工具脚本编辑区的内容，[Make]：生成工具脚本并显示在编辑区，[Insert]：将编辑区的内容插入到平台的脚本编辑。

·六种基本控件介绍

在每个参数配置页面里，提供了六种基本控件，这六种控件可以满足输入参数的所有情况，下面分别介绍：

A、下拉式组合框(ComboBox)，用于选择多个选择中的一个，选项在10个以下的情况，控件属性格式为{“第一个值”“第二个值”“第三个值”“第四个值”“第五个值”}

B、开关控件(checkbutton)，用于二选一的情况，控件属性格式为{“显示的内容”“打上勾时取值”“去掉勾时取值”}，如{“双天线打开”“1”“0”}

C、数值调整控件(SpinBox)，用于数值变化有规律的数据选择，一般选项超过10个以上，控件属性格式为{最小值最大值变化步长}，如{01005}

D、文本输入框(entry)，用于输入文本，包括数字，用于无规律的文本或数字输入，控件属性格式为空，即{}

E、收音机按钮(radiobutton)，用于从少量选项中选一的情况，选项不超过4个，控件属性格式为{“第一种情况”“第一种情况取值”“第二种情况”“第二种情况取值”“第三种情况”“第三种情况取值”“第四种情况”“第四种情况取值”}

F、文件选择框(entry)，用于选择文件名，如选择输入或输出文件，控件属性格式为{“I或O”}，I表示所选文件为输入文件，O表示所选文件为输出文件。

·控件位置

在每个参数配置页面里，有8个摆放控件的位置，其分布和位置编号如图16所示：图中的每个位置可以放一个短控件(控件A、B、C、D中一个)，位于同一行的两个位置(即1和2、3和4、5和6)可以放一个长控件(控件E、F中的一个)，这样在每个页面中最多可以放8个短控件或者4个长控件，如果既有长控件也有短控件，则其控件个数在4个至8个之间。所以在每个步骤中最多只能配置8个参数，如果有更多的参数，可以拆分为多个步骤进行配置。

·工具向导开发步骤

下面介绍在算法逻辑测试平台上开发工具的一般步骤。

首先，要实现工具，本平台的工具向导支持下面的三种实现形式的工具：

1)用C/C++实现并扩展为TCL命令的DLL二进制包；

2)用纯粹的TCL实现的包；

3)带参数的可执行文件(后缀为exe)。

然后，需要对的工具的配置参数进行模块划分，形成多个配置步骤，最好按照工具的工作流程进行划分，这样将需要配置的所有参数划分成多个步骤来配置。模块划分的原则是要能体现出工具的工作流程，划分成的各个步骤之间要有较紧密的联系。然后将这些步骤画成流程图，用于该步骤中的图片提示，例如分成两个步骤的流程图如图17A所示。

例如WCDMA上行专用信道激励数据产生工具工作流程图如图18所示：

接下来就要开始制作显示在每一个步骤中对应的图片，每个步骤中的提示图片可以是不一样的，基本的要求是要能起到提示的作用，让用户看了图片后知道这个步骤中要配置的参数是起什么作用的。在配置相应步骤的参数时，建议将上面画好的流程图中的该步以加强色彩的形式体现，这样制作起来简单，但有较强的提示作用。制作好的两个步骤中的提示图片如下面所示：

第一个步骤中的流程图(imagel.GIF)如图17B所示；第二个步骤中的流程图(image2.GIF)如图17C所示。

规划好工具的步骤和各个步骤中要配置的参数后，就可以开始修改工具向导界面实现的TCL模板文件，按照下面附件中提供的模板(DemoWizard.tcl，可改为自己的名字)进行修改。只需修改用户设置部分的变量取值，其它模块无须做任何修改。

本发明能够通过脚本将各种资源有机的结合到验证流程中，具有很好的扩展性、可重复性和可重用性，提高验证的效率和自动化程度。

Claims (14)

1、一种自动化仿真方法，其特征在于：该方法包括步骤：

启动执行脚本开始验证项目；

执行脚本启动激励脚本和配置脚本分别产生激励信号和生成配置文件；

执行脚本启动仿真器运行仿真脚本对被测对象进行仿真，被测对象接收激励信号和读取配置文件，并保存仿真过程产生的响应数据；

执行脚本启动数据对比脚本和结果分析脚本，将响应数据与预期值进行比较，输出分析结果。

2、如权利要求1所述的方法，其特征在于：所述执行脚本为复数个，由验证脚本依次启动该复数个执行脚本，以完成需要进行多个测试任务的验证项目。

3、如权利要求1或2所述的方法，其特征在于：验证项目均采用固定的目录结构组织相关文件。

4、如权利要求3所述的方法，其特征在于：验证项目的目录结构包括：

第一子目录，用于保存相关的规格、设计和验证文档；

第二子目录，用于保存可重用行为模型、公共子程序和函数；

第三子目录，用于保存可综合的设计源代码；

第四子目录，用于保存综合脚本、网表以及综合产生的各种报告文件；

第五子目录，用于保存约束文件、布局布线脚本、烧片文件以及布局布线过程中产生的各种报告文件；

第六子目录，用于保存验证相关文件。

5、如权利要求4所述的方法，其特征在于：第六子目录进一步包括：

仿真工作子目录，保存仿真编译结果，并作为临时目录供仿真时进行文件拷贝操作；

验证程序组子目录，用于存放为了验证被测对象的某一类特性所需的测试文件。

6、如权利要求5所述的方法，其特征在于：验证程序组子目录包括多个目录结构相同的测试用例子目录，每一测试用例子目录进一步包括：

脚本目录，用于保存仿真中需要被调用的脚本；

配置文件目录，用于保存配置文件；

激励文件目录，用于保存激励数据文件；

仿真结果目录，用于保存仿真输出结果、仿真过程日志文件、代码覆盖率报告及缺陷跟踪表；

对比数据目录，用于保存仿真参考比对数据；

执行脚本目录，用于保存该测试用例的执行脚本；

说明文件目录，用于保存该测试用例的详细说明文件。

7、如权利要求1或2所述的方法，其特征在于：所述验证项目及验证过程由验证项目管理模块进行统一管理，并且该验证项目管理模块提供一个用户界面供用户进行验证项目管理操作。

8、如权利要求7所述的方法，其特征在于：验证项目管理模块通过用户界面提供一个用户扩展接口，用户通过该用户扩展接口开发工具以增加验证项目管理模块功能。

9、如权利要求8所述的方法，其特征在于：所述的扩展接口提供工具向导开发模板，以开发出标准的工具向导。

10、一种自动化仿真系统，包括用于数据处理的处理器，用于存储程序和数据的存储器，其特征在于：该系统还具有仿真平台，该仿真台包括：

验证脚本模块：由启动执行脚本的命令集构成，用于启动执行脚本来执行测试用例；

仿真器模块：由执行脚本启动，用于运行仿真脚本进行仿真；

验证项目管理模块：用于实现整个验证项目的目录管理、测试用例的执行和回归测试执行，并提供一用户界面供项目管理操作，其中，验证项目的目录用于组织验证过程所需要的相关文件。

11、如权利要求10所述的仿真系统，其特征在于：还包括用户扩展接口模块，通过该扩展接口模块向仿真平台增加工具。

12、如权利要求11所述的仿真系统，其特征在于：所述用户扩展接口模块包括工具向导开发模块，通过该模块开发出标准的工具。

13、如权利要求10至12之一所述的仿真系统，其特征在于：所述验证项目的目录结构包括：

第一子目录，用于保存相关的规格、设计和验证文档；

第二子目录，用于保存可重用行为模型、公共子程序和函数；

第三子目录，用于保存可综合的设计源代码；

第四子目录，用于保存综合脚本、网表以及综合产生的各种报告文件；

第五子目录，用于保存约束文件、布局布线脚本、烧片文件以及布局布线过程中产生的各种报告文件；

第六子目录，用于保存验证相关文件。

14、如权利要求13所述的仿真系统，其特征在于：第六子目录进一步包括：

仿真工作子目录，保存仿真编译结果，并作为临时目录供仿真时进行文件拷贝操作；

验证程序组子目录，用于存放为了验证被测对象的某一类特性所需的测试文件；

其中：验证程序组子目录包括多个目录结构相同的测试用例子目录，每一测试用例子目录进一步包括：

脚本子目录，用于保存仿真中需要被调用的脚本；

配置文件子目录，用于保存配置文件；

激励文件子目录，用于保存激励数据文件；

仿真结果子目录，用于保存仿真输出结果、仿真过程日志文件、代码覆盖率报告及缺陷跟踪表；

对比数据子目录，用于保存仿真参考比对数据；

执行脚本子目录，用于保存该测试用例的执行脚本；

说明文件子目录，用于保存该测试用例的详细说明文件。

Images