CN1549119A

CN1549119A - 逻辑仿真测试***和方法

Info

Publication number: CN1549119A
Application number: CNA031228852A
Authority: CN
Inventors: 王进成
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2003-05-07
Filing date: 2003-05-07
Publication date: 2004-11-24
Anticipated expiration: 2023-05-07
Also published as: CN100511149C

Abstract

本发明的逻辑仿真测试***，通过用户的主脚本文件来完成包含在仿真器模块中的待测试逻辑的测试，其中，该***包含有：控制模块，用来解释执行该主脚本文件和控制下述的各个模块；报文数据库模块，用来实现报文数据的存储和读取、检索和显示、保存到文件和从文件中加载；CPU配置模块，用来实现数据的读写和中断；若干个激励模块，用来构造激励报文；仿真器模块，用来对输入的激励报文完成仿真处理测试，并输出测试后的报文；若干个分析模块，用来分析测试后的报文，并将分析结果输出。本发明用户编写的测试代码比较简单并且代码量少，测试代码采用TCL脚本编写，不需要编译，搭建仿真***投入的时间大大减少。

Description

逻辑仿真测试***和方法

技术领域

本发明涉及设备测试领域，具体来说是涉及一种模块化的逻辑仿真测试***和方法。

背景技术

如今大量的通讯类大规模逻辑得到了广泛的使用，在投入使用前要对该种通讯类大规模逻辑的功能进行仿真测试，测试时大量的工作是编写由激励产生功能和结果分析功能组成的测试代码，然后进行测试。

现有的测试方法主要是首先由测试人员编写测试代码，然后将该测试代码输入非模块化的逻辑验证***来完成测试。如图1所示为目前应用非常广泛的Zaiq公司采用的逻辑验证***的结构框图，其包括有三部分：C测试代码部分、接口层部分、通用的HDL(Hardware Design Language：硬件设计语言)仿真部分。

C测试代码部分包括用户实现测试目的测试用例代码、实现数据传递交换的接口函数(包括：TX测试函数、RX测试函数、CPU测试函数)、环境控制、报文记录库。测试用例代码调用数据交换接口函数，实现数据的收发，调用TX测试函数发送激励数据，将产生的激励数据传递给被测试逻辑；调用RX测试函数实现数据接收，接收被测试逻辑传递过来的数据，完成接收数据分析；调用CPU测试函数实现CPU接口的数据读写和中断。数据交换接口函数，是用户根据特定激励数据格式的要求，调用接口层提供的编程接口，编码而成。报文记录库用于记录激励报文的相关信息，比如收发端口、收发时间、报文构造数据，报文序列号等。环境控制部分，实现模块之间的消息传递和同步，仿真器控制，消息记录等。

接口层部分，实现上述的C测试代码部分的数据和下述的HDL仿真部分数据的交换，存在于该逻辑验证***的内核，对于用户来说是一些编程接口。

HDL仿真部分，包含TX数据交换接口、RX数据交换接口、CPU数据交换接口、被仿真测试的逻辑。其中TX数据交换接口、RX数据交换接口、CPU数据交换接口是用户用HDL语言编写实现的，用于将数据转换成时序信号传递给被仿真测试的逻辑，或者从被测试逻辑接收时序信号转换成数据。HDL仿真部分的模块也是用HDL语言编码实现，在通用仿真器软件环境中运行，仿真硬件的行为。

该逻辑验证***提供了许多底层函数，比如报文数据结构定义、报文构造函数、同步机制函数等，测试人员使用这些函数编写C测试代码。

虽然上述现有技术在一定程度上达到了测试代码共享，提高了测试效率，但是其仍然存在许多不足。首先由于为一个通讯类大规模逻辑项目编写一套测试代码，现有技术没有形成模块化组件，只是提供了编程的底层函数，测试人员不得不熟悉很多函数；而测试代码和被仿真的逻辑相关，测试代码重用度很低、可重复性很差；另外，各功能模块没有明确的编程指导或接口规范，只是提出大概的分工，实现的功能主要由用户根据具体的项目要求进行设计，因此编程工作量很大。其次对逻辑测试人员的编程技术要求很高，可是通常逻辑测试人员是硬件工程师，对软件编程不是很擅长，这更增加了逻辑仿真测试工作的难度和不便，造成测试效率低下。

发明内容

本发明的主要目的是提供一种测试人员只需编写和待测试逻辑相关的少量代码的主脚本文件，以解决现有技术存在的测试代码重用度低、可重复性差、编程工作量大和测试效率低下等问题，就能自动完成仿真逻辑的测试和分析的模块化的逻辑仿真测试***和方法。

为实现上述目的，本发明的解决方案是：

一种逻辑仿真测试***，通过用户的主脚本文件来完成包含在仿真器模块中的待测试逻辑的测试，其中，该***包含有：

控制模块，用来解释执行该主脚本文件和控制下述的各个模块；

报文数据库模块，用来实现报文数据的存储和读取、检索和显示、保存到文件和从文件中加载；

CPU配置模块，用来实现数据的读写和中断；

若干个激励模块，用来构造激励报文；

仿真器模块，用来对输入的激励报文完成仿真处理测试，并输出测试后的报文；

若干个分析模块，用来分析测试后的报文，并将分析结果输出；

所述的仿真器模块中的HDL代码模块向控制模块发出测试激励请求，该控制模块转发该测试激励请求至相应的激励模块，该激励模块构造激励报文，将报文数据信息存储至所述的报文数据库模块，且将该激励报文发送至所述的仿真器模块，由在仿真器模块中运行的HDL代码模块读取并处理输入报文，并输出处理后的报文至相应的分析模块，该分析模块分析被测试逻辑处理后的报文，将分析结果在所述的CPU配置模块的控制下保存到报文数据库模块。

其中，所述的激励模块包含有相应的含有TCL脚本的报文构造器。该激励模块通过调度内部数据流，得到被选中的数据流的参数，再调用该报文构造器，即产生所述的激励报文。

该***还进一步包括：用于进一步验证待测试逻辑对激励报文的处理的用户验证模块，所述的激励模块将激励报文传递给用户验证模块，得到该报文的预期处理结果，激励模块将预期处理结果保存到报文数据库；所述的分析模块将原始的激励报文和测试后的报文传递至该用户验证模块，该用户验证模块完成待测试逻辑对激励报文处理的进一步验证，并将验证结果返回给所述的分析模块。所述的分析模块根据报文库中报文的记录数据，自动完成对报文的一些行为的分析。

所述的控制模块和所述的激励模块、分析模块、CPU配置模块之间的连接是通过基类模块来进行的。而所述的用户验证模块和所述的激励模块、分析模块之间的连接是通过基类模块来进行的。

另外，本发明的一种逻辑仿真测试方法，通过用户的主脚本文件来完成包含在仿真器模块中的待测试逻辑的测试，其中，该方法包含如下步骤：

a、解释执行主脚本文件，然后根据主脚本文件建立激励模块对象和分析模块对象，并按照其中的参数对该激励模块对象和分析模块对象进行配置；

b、仿真器模块发出测试服务请求，且送至该激励模块对象；

c、该激励模块对象根据该测试服务请求构造激励报文，将该激励报文送至仿真器模块；

d、仿真器模块对输入的该激励报文根据HDL代码描述的硬件行为完成仿真处理，将处理后的报文送至相应的分析激励模块对象；

e、该分析模块对象分析该处理后的报文，并将分析结果输出。

其中所述步骤a中的建立激励模块对象和分析模块对象是指建立若干个相应的激励模块对象和分析模块对象。

所述步骤c中的构造激励报文是通过调度各激励模块对象内的激励数据流，再调用相应的TCL脚本进行报文构造，来产生所述的激励报文。

所述步骤e中的分析该测试后的报文更具体包括：

e1、对该测试后的报文进行协议符合性分析，如果为切片报文，则进行报文重组，得到完整的报文；

e2、对该完整的报文进行解析，提取出***标签，获得报文净荷；

e3、验证该报文净荷，得到分析结果。

其中，所述步骤e的步骤e1中更进一步包括：如果该测试后的报文是待测试逻辑自动***的报文，则由用户辅助验证；否则继续。

本发明建立在对被测试对象的充分调研和充分分析上，提取出被测试对象的共性以及验证策略的共性，从而设计出固定的模块组件，并制订了模块间接口标准，使得***模块化，并且可以后期添加(或开发)新的模块补充进来，而不需要对平台原来的模块重新编译。激励模块和分析模块在激励产生和报文分析方面，容易在逻辑项目之间共享。用户编写的测试代码比较简单并且代码量少，测试代码采用TCL脚本编写，不需要编译。使用本发明设计的***，搭建仿真***投入的时间大大减少，使得测试人员可以将大部分精力主要投入到测试条目的设计上。

下面结合附图和具体实施例来详细描述本发明。

附图说明

图1为现有的逻辑验证***的结构框图；

图2是本发明所述的逻辑仿真测试***的结构框图；

图3是本发明所述的逻辑仿真测试方法的流程图；

图4是本发明所述的控制模块、激励模块、仿真器模块之间的数据交换示意图；

图5是本发明所述的激励模块的报文构造过程示意图。

具体实施方式

如图2所示本发明实施例所述的逻辑仿真测试***的结构框图，其主要由一控制模块、一报文数据库模块、一CPU配置模块、一激励模块、一仿真器模块、一分析模块和一用户验证模块构成，其中：

CPU配置模块，用来实现数据的读写和中断处理；

激励模块，用来构造激励报文；

仿真器模块，用来对输入的激励报文根据HDL代码描述的硬件行为完成仿真处理，将处理后的报文送至相应的分析模块；该仿真器模块是一个仿真环境，使用通用的第三方HDL仿真软件，用来仿真HDL代码描述的硬件行为，该部分实现的功能是仿真被测试逻辑处理输入激励报文，仿真该逻辑的输出响应。HDL代码包括被测试逻辑DUV和多个总线接口模块BFM。

分析模块，用来分析仿真器模块处理后的报文，并将分析结果输出；

用户验证模块，用来进一步验证待测试逻辑对激励报文的处理，为分析模块实现自动分析报文的某些行为，提供分析条件。

上述的控制模块、报文数据库模块是基础模块，是固定不变的，该控制模块包含有用于处理用户界面操作的用户界面服务模块和用于处理数据交换请求的数据交换服务模块，该用户界面服务模块可以在仿真过程中查看统计数据而不影响仿真的进行，该数据交换服务模块将数据交换请求转发给相应的激励模块或分析模块(即目标模块)，目标模块产生激励或处理接收数据；而CPU配置模块，***提供一个基本模块实现读写和中断，在实际的逻辑测试中，测试人员在此基本模块的基础上添加所需的功能，比如实现某种报文的收发、根据逻辑运行状态而对逻辑实施的动态控制等等。

报文数据库模块主要实现报文记录数据的存储和读取、检索和显示、保存到文件和从文件加载。核心是报文记录数据结构的定义，这些记录数据支持激励模块和分析模块完成结果的自动分析。

另外激励模块、分析模块可以有很多个，可以后期添加。对于一个逻辑项目测试，通常有多种不同的激励模块和多种不同的分析模块，用户根据需要例化出这些激励模块和分析模块的实体即可，本实施例只给出了一个激励模块和一个分析模块的情形。如果开发新的激励或分析模块可以在原来的模块基类上派生即可，但这些模块的基类定义，主要是定义了模块的接口，控制模块访问后期添加的模块能通过基类模块的接口进行。

图2中的仿真器模块，是待测试逻辑DUV(Design Under verfica Tion)+testbench(测试平台)+仿真器，属于仿真器的控制范围；其中，待测试逻辑DUV是由硬件语言VERILOG或者VHDL编写出的程序，testbench主要由BFM(Bus Bunction Module：总线功能模型)组成，其完成的功能是从激励模块取得(行为级的)激励数据，将行为级的激励数据(相对于比特位流数据)变换成一组时序信号(或电平信号)，传递给DUV；BFM接收DUV输出的时序信号，转换成行为级的数据，将行为级的数据传递给分析模块。仿真器负责解释执行DUV+testbench，仿真逻辑的行为。

用户验证模块是测试人员根据具体的逻辑项目特点自己编写测试代码实现的模块，主要完成与被仿真逻辑特定行为有关的验证。比如逻辑修改了以太网报文的目的MAC地址，修改是否正确需要用户验证模块进行分析。该模块可以不作为仿真测试***组成的必备部件，此时仿真测试***只是对用户验证模块的接口进行了定义，如接口定义的描述如下：输入原始报文得到预期出口列表和预期拷贝数；输入原始报文和报文入口，输入接收报文和报文出口，得到验证是否通过的消息或出错信息。而用户验证模块与激励模块和分析模块的接口是一个标准化的接口，可以通过定义一个用户验证模块的基类，对于不同的逻辑测试项目，用户在此基类的基础上派生出具体的用户验证模块。用户可以通过主脚本文件中的脚本命令，命令用户验证模块加载配表数据或实现其它功能。

需要明确地是，这里传递给用户验证模块的报文，都是完整的报文，比如UTOPIA分析模块传递给用户验证模块的接收报文是信元重组后的AAL封装形式的报文，而不是信元或从AAL PAYLOAD中提取出的IP或以太网报文。

图2中的仿真器模块等效为一个可以工作的逻辑芯片，它能够处理输入数据，并输出结果数据。逻辑芯片有数个数据输入口，和数个数据输出口，每个数据输入口和数据输出口都有相应的BFM对接。BFM是实现行为级激励数据和时序级信号相互转换的功能，是连接逻辑芯片与激励模块和分析模块的接口桥梁。每个向逻辑芯片输送激励数据的BFM对应一个激励模块的实例，每个从逻辑芯片接收数据的的BFM对应一个分析模块的实例。逻辑芯片一般都有CPU接口，外部CPU通过该接口对逻辑芯片进行读写操作，因此有一个BFM与逻辑芯片的CPU口对接。CPU配置模块模仿逻辑芯片的外部CPU，对逻辑芯片进行读写操作。基本的CPU配置模块只实现读写接口，用户可以利用这些接口，实现对逻辑芯片的复杂控制。

本实施例中的逻辑芯片有自己特定的数据输入接口和数据输出接口，数据接口的类型有很多种，每一种接口类型都定义了一组接口信号和时序，比如UTOPIA L1 ATM接口、MII接口。每一种类型的数据输入接口，逻辑仿真测试***都需要提供一种对应激励模块；每一种类型的数据输出接口，逻辑仿真测试***都需要提供一种对应分析模块。

使用逻辑仿真测试***进行逻辑仿真测试之前，必须建立激励模块实例、分析模块实例、CPU配置模块实例，以及设置每个实例的参数，其称为配置操作。用户根据逻辑芯片的接口类型，在逻辑仿真测试***的图形界面上，选择激励模块类型建立激励模块实例，同样建立分析模块的实例、CPU模块的实例。每个实例在建立时，要求输入实例的名称，名称必须唯一，不能重名。

如前所述，激励或分析模块的实例是与BFM一一对应的，存在一个绑定关系，这个绑定是通过名称实现的，每个BFM内有一个参数，该参数的值就是对应实例的名称。完成激励和分析模块、CPU模块实例建立后，可以打开每个实例的图形界面，进行参数配置。逻辑仿真测试***可以将每个模块的参数，以及用户建立的激励模块实例、分析模块实例、CPU配置模块实例等相关参数保存成一个参数配置文件。当逻辑仿真测试***启动时，可以加载该参数配置文件，恢复以前的配置。

如图3所示，本发明实施例所述的逻辑仿真测试***是通过如下的步骤来实现测试的。

第一、解释执行主脚本文件，然后根据主脚本文件建立激励模块对象和分析模块对象，并按照其中的参数对该激励模块对象和分析模块对象进行配置。

主脚本文件的示例如下：

　　1.  Lcfg(cfg_filename)    --加载配置数据

　　2.  onbreak{              --参看仿真模块的控制模块详细设计
部分

　　3.  If{brkmsg＝＝″note″} {resume}else{

　　a)  Set result″error″

　　(b) Writechkmsg(result)   --将信息写入专用LOG文件和该用例
的LOG文件。

　　(c) Exit_test             --退出

　　b)  }

　　4.  run

　　5.  #改变配置参数的命令

　　6.  ..............  

　　7.  Run

　　8.  #改变配置参数的命令

　　9.  ..............

　　10. set result[auto_check]  --结果＝″ok″或″error″

　　11. #判断auto_check验证的结果是否正确，写成功或失败的信息到
记录文件。

　　12. Writechkmsg(result)     --将信息写入专用LOG文件和该用例的
LOG文件。

　　13. Exit_test               --退出

控制模块负责解释执行上述的脚本文件，控制逻辑仿真测试***内各个模块的行为。逻辑仿真测试***提供了许多TCL扩展命令，用户使用这些扩展命令和TCL固有命令编写仿真脚本。仿真平台的所有操作都可以通过扩展TCL命令实现。脚本文件并不直接负责建立激励产生和分析分析，但可以建立激励模块对象和分析模块对象，即建立激励模块和分析模块，所以每个脚本的代码并不多。重要的一点，在仿真逻辑测试执行完毕后，可以得到该测试用例是否通过的信息，并可以保存信息到指定文件。

脚本中onbreak的解释如下所述：

激励模块和分析模块在收发报文数目达到用户设定的上限数目时，会向控制模块发送消息，该消息的级别为”note”。控制模块在接收到消息时就执行onbreak语句体。激励模块和分析模块在分析报文时如果发现错误，也会向控制模块发送消息，该消息的级别为”error”。用户编写onbreak语句体，可以处理这些消息，并能判断发送消息的模块实例名以及具体的消息内容，从而执行相关命令，比如修改某个模块的参数，或者结束仿真。Onbreak在”note”级别的消息处理后，通常会结束run命令的执行，使其返回，于是脚本继续执行下一条脚本语句。

脚本中run命令的解释如下所述：

脚本中的run命令比较特殊，它不会自动结束或返回，它一直等待onbreak语句体中resume命令的执行完成。在run命令执行期间，BFM向仿真平台发起的服务请求能够传递到控制模块，进而被处理。在非run命令执行期间，BFM向仿真平台发起的服务请求被阻塞，仿真器的运行也同时被阻塞。

脚本中auto_check命令的解释如下所述：

该命令一般位于脚本的后部，在仿真结束时执行该命令。控制模块遍历每一个模块实例，调用它们的auto_check接口函数，每个模块实例进行内部状态检查，检查是否有错误。

第二、仿真器模块发出测试服务请求，且送至该激励模块对象。

仿真器模块按照控制模块的指令发出测试服务请求，即testbench的BFM发出报文请求，是通过调用PLI接口程序实现的。PLI接口程序将BFM传递的参数，写入图4中的参数数据结构，然后向控制模块发起请求，再等待该请求处理完成的消息。下面是该BFM调用PLI接口程序的一个示例：

$mii_read_pkt(modulename，framegap，tx_frame_len，tx_frame_data)；

如图4所示，PLI接口程序和激励模块(上式中的modulename)之间通过参数数据结构交换数据，PLI接口程序在填写报文请求参数数据结构中相关数据后，调用***提供的接口函数发出请求(该函数执行期间，仿真软件的执行停止)，控制模块的数据服务模块收到该激励请求后，控制模块从报文请求参数数据结构中得到目标模块(即激励模块实例)名，从而得到激励模块实例的句柄，然后调用激励模块实例的消息处理程序，将该激励请求送至该激励模块实例。

第三、该激励模块对象根据该测试服务请求构造激励报文，将该激励报文写入前述报文请求参数数据结构中。

各种激励模块在构造激励报文机制上是类似的，都是首先通过对流的调度，将多条流混合形成激励报文流。通常可以将具有一定特征的报文序列，定义为一条流。比如具有相同VLANID的报文可以定义为一条流，具有相同源MAC地址的报文序列也可以定义为一条流，或者将同时具有某几个属性的报文序列定义为一条流。对于一条流可以设置一些属性(如乱序、带宽、延时、突发、报文丢弃率)，比如属于该流的所有报文经过逻辑的延时最大不能超过多少。

其次对多个报文流进行汇聚，即形成输送给待测试逻辑的报文。在逻辑仿真中，为了产生符合实际的激励数据，通常我们定义多个流(在激励模块实例的参数配置界面中，设置流的个数和每个流的参数，这些参数称为激励模块实例的配置参数)。当激励模块实例接收到申请报文的请求时，就按照一定的调度算法对这些流进行调度，调度出来一个流，从该流取出用于报文构造的参数(参看图5)，然后执行用户编写的报文构造脚本，同时传递前述的报文构造参数。用户编写报文构造脚本负责构造具体的报文，脚本本中必须使用仿真平台专用的报文构造命令，激励模块才能读取构造好的报文，脚本执行完毕，激励模块实例就得到了报文数据。调度出来的报文就可以作为激励报文输送给待测试逻辑。其中需要明确流的调度概念：并不是先产生流的报文序列，然后对各条报文流调度，而是根据流的属性数据，对流进行调度，当调度出一个流后，再根据流的部分具有编号性质的属性数据(即报文构造时所使用的参数)，调用报文构造器，产生调度出的报文。例如UTOPIA L2激励模块，有多个子端口，每个子端口内有多个流，此时该激励模块需要实现子端口的调度，每个子端口再实现流的调度，子端口的调度与流的调度有类似之处。

本实施例的激励模块包含有相应的含有TCL脚本的报文构造器，该激励模块通过调度各激励模块产生的所需的激励数据流，再调用该报文构造器，即产生所述的激励报文。更具体来讲，如图5所示为报文构造过程示意图，该激励模块经过调度算法调度出所需的激励数据流，并取出流的参数，产生静荷Payload部分，在其前部***一个标签，标签定义如下：

特征数据(F55F)(2个字节)+FSN(报文序列号)(3字节)+校验码(前5个字节累加的和)(1个字节)+净荷长度(2字节)+后面净荷的CRC32(4字节)；

其中流的属性参数是为了支持QOS(Quality Of Services：服务质量)属性(如乱序、带宽、延时、突发、报文丢弃率)的测试，用户在控制模块的用户界面服务模块或通过脚本命令可以设置各个流的属性参数，这些参数(如用户要求的带宽、突发)将控制流的调度，在分析模块进行结果自动分析时也会用到这些参数(如检查实际带宽、乱序、延时要求、报文丢弃率)。

接着将其参数和静荷Payload部分传递给外部的TCL脚本，通过TCL脚本报文构造函数然后返回，即得到所需的激励报文。其中产生报文的TCL代码可以采用如下的方式编写：

　　#------------------------------------------

　　#port_sn端口编号，假定编号1和2的端口是两个MII口，向逻辑发送
以太网报文

　　#last_txpkt_sn是报文在流内的序号。

　　#flow_sn是流在端口内的序号

　　#port_sn、last_txpkt_sn、flow_sn定义为TCL脚本全局变量，并和主
模块内的对应全局变量进行连接，激励模块将流的对应参数赋值给主模
块的这些全局变量。

　　#------------------------------------------

　　proc mii_pkt_build{}{

　　if($port_sn＜3){

　　#to_hex扩展命令用于将输入的十进制参数，形成16进制字符串，
返回的字符个数，由第二个参数控制。

　　set temp1[to_hex $last_txpkt_sn 6]

　　set temp2[to_hex $flow_sn 6]

　　set dmac $temp2$temp1

　　set smac[to_hex $port_sn 12]

　　#create_mac是扩展的报文构造命令。未指定的参数，按照缺省规
则构造报文。参看MII激励模块使用手册。产生后的报文保存在主模块的
全局报文缓冲区中，激励模块可以从该缓冲区读取产生的报文。

　　create_mac-dmac Ox$dmac-smac Ox$smac

　　#如果将create_mac产生的报文封装为AAL5，则继续：

　　create_aal5
        <!-- SIPO <DP n="13"> -->
        <dp n="d13"/>
　　#create_aal5扩展命令能够识别create_mac产生的报文类型，并产生
合适的封装。

　　}

　　}

　　#--------------------------------------------------

上述的这种报文构造方法，对于构造异常报文和多层协议封装的报文是很方便的。可以将流调度和报文构造做成一个基类，然后在此基础上可以派生出多种激励模块，这样简化了开发新的激励模块的工作量。

报文产生后，激励模块向报文数据库模块注册报文相关信息：如产生报文时用的各个参数、报文产生时间；激励模块也可以调用户验证模块，得到报文的预期处理结果。

激励模块构造完成激励报文后，向报文请求参数数据结构中写入激励报文，PLI接口程序调用***接口函数返回，从报文请求参数数据结构中取出仿真***处理完成后的激励报文，将该激励报文送至仿真器模块中的BFM。

第四、仿真器模块对输入的该激励报文完成测试，将含有测试结果的测试后的报文送至相应的分析模块对象。

仿真器模块中的输入激励数据给逻辑芯片的BFM得到该激励报文后，其将该激励数据变换成时序信号，传递给DUV。在仿真期间，DUV处理激励数据，并输出结果数据。逻辑芯片数据输出口的BFM将该DUV输出的信号，转换为行为级的数据，即结果报文(或待分析报文)。

逻辑芯片数据输出口的BFM发出服务请求，也是通过调用PLI接口程序实现的。PLI接口程序将BFM传递的参数，通过上述的报文请求参数数据结构向控制模块发起请求，然后等待该请求处理完成的消息

PLI接口程序和分析模块之间通过报文请求参数数据结构交换数据，PLI接口程序在填写报文请求参数数据结构中相关数据后，调用逻辑仿真测试***提供的接口函数发出请求(该函数执行期间，仿真软件的执行停止)，控制模块的数据服务模块收到该服务请求后，控制模块从报文请求参数数据结构中得到相应的目标模块(即分析模块实例)名，从而得到分析模块实例的句柄，然后调用分析模块的消息处理程序，将该分析请求送至该分析模块，即分析模块对象中，该分析模块即可从报文请求参数数据结构取出所述的待测试的报文。

第五、该分析模块对象分析该待测试的报文，并将分析结果输出。

分析模块从BFM收到待测试的报文后进行分析，直到提取出仿真平台***到报文中的标签，并完成报文静荷的验证。这一分析过程是标准化的，是可以程序化的，其更具体包括：

1、对该测试后的报文进行协议符合性分析，如果为切片报文，则进行报文重组，得到完整的报文；

如果该测试后的报文是待测试逻辑自动***的报文，则由用户辅助验证；否则继续。

当分析模块在收到待测试逻辑自动***报文，如管理报文、管理信元，这些报文不含有报文序列号，不是仿真测试***产生的报文，这类报文，分析模块无法进一步分析其正确性，将这些报文传递给用户验证模块，让用户验证模块判断正确性。

另外，报文的路由正确性、广播正确性、报文变换正确性需要用户验证模块提供辅助信息才能完成。分析模块提取出报文序号后，访问报文数据库模块，得到产生该报文的激励模块实例句柄，调用激励模块实例恢复原始报文，分析模块实例可以调用由用户自行编制的用户验证模块，将原始报文和接收报文传递给用户验证模块，用户验证模块完成报文变换正确性的分析，并给出预期出口列表信息，分析模块根据返回的预期信息，并根据报文数据库模块中该报文的历史记录，完成路由正确性、广播拷贝正确性的分析。分析模块将分析结果和接收报文的出口信息写入报文数据库模块。

2、对该完整的报文进行解析，提取出***标签，获得报文净荷；

3、验证该报文净荷，得到分析结果。

根据报文库中该报文的记录数据，自动分析报文的出口正确性、报文延时正确性和报文乱序正确性。

在前述的激励模块内，有流的一系列参数，描述流的QOS属性，分析模块在收到报文后，要通知激励模块，进行QOS符合性检查，比如，检查报文的延时是否超过设定值、检查是否存在乱序。

这样，测试人员就可以通过控制模块中的用户界面服务模块来检索、显示报文数据库模块中的分析结果和其他相关信息了。

Claims

1、一种逻辑仿真测试***，通过用户的主脚本文件来完成包含在仿真器模块中的待测试逻辑的测试，其特征在于，该***包含有：

CPU配置模块，用来实现数据的读写和中断；

若干个激励模块，用来构造激励报文；

2、如权利要求1所述的一种逻辑仿真测试***，其特征在于，所述的激励模块包含有相应的含有TCL脚本的报文构造器，该激励模块通过调度各激励模块产生的所需的激励数据流，再调用该报文构造器，即产生所述的激励报文。

3、如权利要求1所述的一种逻辑仿真测试***，其特征在于，该***还进一步包括：所述的激励模块将激励报文传递给用户验证模块，得到该报文的预期处理结果，激励模块将预期处理结果保存到报文数据库；所述的分析模块将原始的激励报文和测试后的报文传递至该用户验证模块，该用户验证模块完成待测试逻辑对激励报文处理的进一步验证，并将验证结果返回给所述的分析模块。

4、如权利要求3所述的一种逻辑仿真测试***，其特征在于，所述的激励模块可以调用所述的用户验证模块，将预期信息填入所述的报文数据库模块。

5、如权利要求1或3所述的一种逻辑仿真测试***，其特征在于，所述的控制模块和所述的激励模块、分析模块、CPU配置模块之间的连接是通过基类模块来进行的。

6、如权利要求3所述的一种逻辑仿真测试***，其特征在于，所述的用户验证模块和所述的激励模块、分析模块之间的连接是通过基类模块来进行的。

7、一种逻辑仿真测试方法，通过用户的主脚本文件来完成包含在仿真器模块中的待测试逻辑的测试，其特征在于，该方法包含如下步骤：

b、仿真器模块发出测试服务请求，且送至该激励模块对象；

8、如权利要求7所述的一种逻辑仿真测试方法，其特征在于，所述步骤b中的建立激励模块对象和分析模块对象是指建立若干个相应的激励模块对象和分析模块对象。

9、如权利要求7所述的一种逻辑仿真测试方法，其特征在于，所述步骤b、步骤c中的仿真器模块和激励模块对象的数据交换及步骤c中的仿真器模块和分析模块对象的数据交换是通过参数数据结构来进行的。

10、如权利要求7所述的一种逻辑仿真测试方法，其特征在于，所述步骤c中的构造激励报文是通过调度各激励模块对象产生的激励数据流，再调用相应的TCL脚本进行报文构造，来产生所述的激励报文。

11、如权利要求7所述的一种逻辑仿真测试方法，其特征在于，所述步骤e中的分析该测试后的报文更具体包括：

e3、验证该报文净荷，得到分析结果。

12、如权利要求11所述的一种逻辑仿真测试方法，其特征在于，所述步骤e的步骤e1中更进一步包括：如果该测试后的报文是待测试逻辑自动***的报文，则由用户辅助验证；否则继续。