CN1549119A - Logic simulation test system and method - Google Patents

Abstract

The logic simulation test system of the present invention completes the test of the logic to be tested contained in the emulator module through the user's main script file, wherein, the system includes: a control module for explaining and executing the main script file and controlling The various modules described above; the message database module is used to realize the storage and reading, retrieval and display of message data, saving to and loading from files; the CPU configuration module is used to realize data reading and writing and interruption; A stimulus module, used to construct the stimulus message; an emulator module, used to complete the simulation processing test on the input stimulus message, and output the message after the test; several analysis modules, used to analyze the message after the test, and output the analysis results. The test code written by the user in the present invention is relatively simple and has a small amount of code. The test code is written by TCL script without compiling, and the time invested in building the simulation system is greatly reduced.

Description

Logic simulation test system and method

technical field

The invention relates to the field of equipment testing, in particular to a modular logic simulation testing system and method.

Background technique

Nowadays, a large number of large-scale communication logics are widely used. Before putting them into use, the functions of this large-scale communication logic should be simulated and tested. During the test, a lot of work is to write a program consisting of incentive generation functions and result analysis functions. Test the code, and test it.

Existing testing methods are mainly to first write test codes by testers, and then input the test codes into a non-modular logic verification system to complete the test. As shown in Figure 1, the structural block diagram of the logic verification system adopted by Zaiq Company, which is widely used at present, includes three parts: the C test code part, the interface layer part, and the general HDL (Hardware Design Language: hardware design language) simulation part .

The C test code part includes the test case code for the user to realize the test purpose, the interface function to realize the data transmission and exchange (including: TX test function, RX test function, CPU test function), environment control, and message recording library. The test case code calls the data exchange interface function to realize the sending and receiving of data, calls the TX test function to send the stimulus data, and passes the generated stimulus data to the logic under test; calls the RX test function to realize data reception, and receives the data passed by the logic under test, Complete the receiving data analysis; call the CPU test function to realize the data reading and writing and interrupt of the CPU interface. The data exchange interface function is coded by the user by calling the programming interface provided by the interface layer according to the requirements of the specific incentive data format. The message record library is used to record relevant information of incentive messages, such as sending and receiving ports, sending and receiving time, message structure data, message serial number, etc. The environment control part realizes message transmission and synchronization between modules, emulator control, message recording, etc.

The interface layer part, which realizes the data exchange of the above-mentioned C test code part and the following HDL simulation part data, exists in the core of the logic verification system, and is some programming interfaces for users.

The HDL simulation part includes TX data exchange interface, RX data exchange interface, CPU data exchange interface, and the logic to be simulated and tested. Among them, the TX data exchange interface, RX data exchange interface, and CPU data exchange interface are written and implemented by the user in HDL language, and are used to convert data into timing signals and transmit them to the logic to be simulated, or receive timing signals from the logic under test and convert them into data. The modules of the HDL simulation part are also coded in HDL language and run in the general simulator software environment to simulate the behavior of the hardware.

The logic verification system provides many low-level functions, such as message data structure definition, message constructor, synchronization mechanism functions, etc. Testers use these functions to write C test codes.

Although the above prior art achieves test code sharing to a certain extent and improves test efficiency, it still has many deficiencies. First of all, because a set of test codes is written for a large-scale communication-type logic project, the existing technology does not form modular components, but only provides the underlying functions of programming, and testers have to be familiar with many functions; and the test code is related to the simulated logic. , the test code reuse is very low, and the repeatability is very poor; in addition, there is no clear programming guidance or interface specification for each functional module, only a rough division of labor is proposed, and the realized functions are mainly designed by the user according to the specific project requirements, so programming Heavy workload. Secondly, the programming skills of logic testers are very high, but usually logic testers are hardware engineers and are not very good at software programming, which increases the difficulty and inconvenience of logic simulation testing, resulting in low testing efficiency.

Contents of the invention

The main purpose of the present invention is to provide a main script file in which testers only need to write a small amount of code related to the logic to be tested, so as to solve the problems of low test code reuse, poor repeatability, large programming workload and test efficiency in the prior art A modularized logic simulation test system and method that can automatically complete the test and analysis of simulation logic if problems such as inferiority are solved.

To achieve the above object, the solution of the present invention is:

A logic simulation test system, through the user's main script file to complete the test of the logic to be tested contained in the simulator module, wherein, the system includes:

The control module is used to explain and execute the main script file and control the following modules;

Message database module, used to store and read message data, retrieve and display, save to file and load from file;

CPU configuration module, used to realize data reading and writing and interrupt;

Several incentive modules are used to construct incentive messages;

The emulator module is used to complete the simulation processing test on the input stimulus message, and output the message after the test;

Several analysis modules are used to analyze the tested messages and output the analysis results;

The HDL code module in the emulator module sends a test stimulus request to the control module, and the control module forwards the test stimulus request to a corresponding stimulus module, and the stimulus module constructs a stimulus message, and stores the message data information in the message database module, and send the stimulus message to the emulator module, read and process the input message by the HDL code module running in the emulator module, and output the processed message to the corresponding An analysis module, which analyzes the message processed by the test logic, and saves the analysis result to the message database module under the control of the CPU configuration module.

Wherein, the incentive module includes a corresponding message constructor containing a TCL script. The incentive module obtains the parameters of the selected data stream by scheduling the internal data stream, and then invokes the message constructor to generate the incentive message.

The system further includes: a user verification module for further verifying the processing of the logic to be tested on the incentive message, the incentive module transmits the incentive message to the user verification module to obtain the expected processing result of the message, and the incentive module Save the expected processing result to the message database; the analysis module transmits the original incentive message and the tested message to the user verification module, and the user verification module completes further verification of the processing of the incentive message by the logic to be tested , and return the verification result to the analysis module. The analysis module automatically completes the analysis of some behaviors of the message according to the record data of the message in the message database.

The connection between the control module, the excitation module, the analysis module and the CPU configuration module is carried out through the base class module. The connection between the user verification module, the incentive module and the analysis module is carried out through the base class module.

In addition, a kind of logic simulation test method of the present invention, completes the test of the logic to be tested contained in the emulator module through the main script file of the user, wherein, this method comprises the following steps:

a. Interpret and execute the main script file, then establish the stimulus module object and the analysis module object according to the main script file, and configure the stimulus module object and the analysis module object according to the parameters therein;

b. The emulator module sends a test service request and sends it to the stimulus module object;

c. The stimulus module object constructs a stimulus message according to the test service request, and sends the stimulus message to the emulator module;

d. The emulator module completes simulation processing for the input stimulus message according to the hardware behavior described by the HDL code, and sends the processed message to the corresponding analysis stimulus module object;

e. The analysis module object analyzes the processed message, and outputs the analysis result.

The establishment of the incentive module object and the analysis module object in the step a refers to the establishment of several corresponding incentive module objects and analysis module objects.

The construction of the incentive message in the step c is to generate the incentive message by scheduling the incentive data flow in each incentive module object, and then calling the corresponding TCL script to construct the message.

The message after analyzing the test in the step e more specifically includes:

e1. Perform protocol compliance analysis on the tested message, if it is a sliced message, reassemble the message to obtain a complete message;

e2. Analyzing the complete message, extracting the inserted label, and obtaining the payload of the message;

e3. Verify the message payload, and obtain the analysis result.

Wherein, the step e1 of the step e further includes: if the tested message is a message automatically inserted by the logic to be tested, the verification is assisted by the user; otherwise, continue.

The present invention is based on the full investigation and analysis of the tested objects, and extracts the commonness of the tested objects and the commonness of the verification strategy, thereby designing fixed module components, and formulating the inter-module interface standard, so that the system is modularized, And new modules can be added (or developed) later without recompiling the original modules of the platform. Stimulus modules and analysis modules are easily shared between logic projects for stimulus generation and message analysis. The test code written by the user is relatively simple and has a small amount of code. The test code is written in TCL script and does not need to be compiled. By using the system designed by the invention, the time invested in building the simulation system is greatly reduced, so that testers can devote most of their energy to the design of test items.

The present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

Description of drawings

Fig. 1 is the structural block diagram of existing logic verification system;

Fig. 2 is the structural block diagram of logic simulation testing system of the present invention;

Fig. 3 is the flow chart of logic simulation testing method of the present invention;

Fig. 4 is a schematic diagram of data exchange between the control module, the excitation module, and the emulator module of the present invention;

Fig. 5 is a schematic diagram of the message construction process of the excitation module according to the present invention.

Detailed ways

The structural block diagram of the logic simulation test system described in the embodiment of the present invention as shown in Figure 2, it is mainly by a control module, a message database module, a CPU configuration module, an excitation module, an emulator module, an analysis module and a user authentication module, wherein:

The control module is used to explain and execute the main script file and control the following modules;

Message database module, used to store and read message data, retrieve and display, save to file and load from file;

CPU configuration module, used to realize data reading and writing and interrupt processing;

An incentive module, used to construct an incentive message;

The emulator module is used to complete the simulation processing of the input stimulus message according to the hardware behavior described by the HDL code, and send the processed message to the corresponding analysis module; the emulator module is a simulation environment, using a common third-party HDL simulation software is used to simulate the hardware behavior described by the HDL code. The function of this part is to simulate the logic under test to process the input stimulus message and simulate the output response of the logic. The HDL code includes the logic DUV under test and multiple bus interface modules BFM.

The analysis module is used to analyze the message processed by the emulator module and output the analysis result;

The user verification module is used to further verify the processing of the incentive message by the logic to be tested, and provides analysis conditions for the analysis module to automatically analyze certain behaviors of the message.

The above-mentioned control module and message database module are basic modules and are fixed. The control module includes a user interface service module for processing user interface operations and a data exchange service module for processing data exchange requests. The user interface The service module can view statistical data during the simulation process without affecting the simulation. The data exchange service module forwards the data exchange request to the corresponding stimulus module or analysis module (ie, the target module), and the target module generates stimulus or processes the received data; As for the CPU configuration module, the system provides a basic module for reading, writing and interrupting. In the actual logic test, the tester adds the required functions on the basis of this basic module, such as realizing the sending and receiving of certain messages and running according to the logic. State and dynamic control over logic, and so on.

The message database module mainly implements the storage and reading of message record data, retrieval and display, saving to and loading from files. The core is the definition of the message record data structure, which supports the automatic analysis of the results completed by the incentive module and the analysis module.

In addition, there can be many incentive modules and analysis modules, which can be added later. For a logic project test, there are usually many different stimulus modules and many different analysis modules. Users can instantiate the entities of these stimulus modules and analysis modules according to their needs. This embodiment only provides one stimulus module and The case of an analysis module. If a new stimulus or analysis module is developed, it can be derived from the base class of the original module, but the base class definition of these modules mainly defines the interface of the module, and the control module can access the modules added later through the interface of the base class module conduct.

The emulator module in Figure 2 is the logic to be tested DUV (Design Under verfica Tion) + testbench (test platform) + emulator, which belongs to the control range of the emulator; where the logic DUV to be tested is written by the hardware language VERILOG or VHDL Out of the program, testbench is mainly composed of BFM (Bus Bunction Module: bus function model), and its completed function is to obtain (behavior-level) stimulus data from the stimulus module, and convert the behavior-level stimulus data (relative to bit stream data) Transform into a set of timing signals (or level signals) and pass them to DUV; BFM receives the timing signals output by DUV, converts them into behavior-level data, and passes the behavior-level data to the analysis module. The emulator is responsible for explaining the behavior of executing DUV+testbench and simulating logic.

The user verification module is a module implemented by testers who write test codes according to the characteristics of specific logic projects. It mainly completes the verification related to the specific behavior of the simulated logic. For example, if the destination MAC address of the Ethernet message is modified logically, the user verification module needs to analyze whether the modification is correct. This module may not be used as an essential part of the simulation test system. At this time, the simulation test system only defines the interface of the user verification module. For example, the description of the interface definition is as follows: input the original message to obtain the expected export list and expected copy number; Input the original message and the message entry, input the received message and the message exit, and get the message or error message whether the verification is passed or not. The interface between the user verification module, the incentive module and the analysis module is a standardized interface. By defining a base class of the user verification module, for different logic test items, the user can derive specific user verification based on this base class. module. The user can order the user verification module to load the table data or realize other functions through the script command in the main script file.

It needs to be clear that the messages passed to the user verification module here are all complete messages. For example, the received message passed by the UTOPIA analysis module to the user verification module is a message in the form of AAL encapsulation after cell reorganization, rather than Cells or IP or Ethernet packets extracted from AAL PAYLOAD.

The emulator module in Figure 2 is equivalent to a working logic chip, which can process input data and output result data. The logic chip has several data input ports and several data output ports, and each data input port and data output port has a corresponding BFM connection. BFM is a function to realize the mutual conversion between behavior-level stimulus data and timing-level signals, and is an interface bridge connecting logic chips with stimulus modules and analysis modules. Each BFM that delivers stimulus data to the logic chip corresponds to an instance of the stimulus module, and each BFM that receives data from the logic chip corresponds to an instance of the analysis module. A logic chip generally has a CPU interface through which an external CPU can read and write to the logic chip. Therefore, a BFM is connected to the CPU port of the logic chip. The CPU configuration module imitates the external CPU of the logic chip, and performs read and write operations on the logic chip. The basic CPU configuration module only implements read and write interfaces, and users can use these interfaces to realize complex control of logic chips.

The logic chip in this embodiment has its own specific data input interface and data output interface. There are many types of data interfaces. Each interface type defines a set of interface signals and timing, such as UTOPIA L1 ATM interface and MII interface. . For each type of data input interface, the logic simulation test system needs to provide a corresponding stimulus module; for each type of data output interface, the logic simulation test system needs to provide a corresponding analysis module.

Before using the logic simulation test system for logic simulation testing, it is necessary to create instances of the stimulus module, analysis module, and CPU configuration module, and set the parameters of each instance, which is called configuration operation. According to the interface type of the logic chip, the user selects the stimulus module type on the graphical interface of the logic simulation test system to create an example of the stimulus module, and also creates an example of the analysis module and a CPU module. When each instance is created, it is required to enter the name of the instance, which must be unique and cannot be duplicated.

As mentioned above, the instance of the excitation or analysis module corresponds to the BFM one by one, and there is a binding relationship. This binding is realized through the name. There is a parameter in each BFM, and the value of the parameter is the value of the corresponding instance. name. After the stimulus and analysis module and the CPU module instance are established, the graphical interface of each instance can be opened for parameter configuration. The logic simulation test system can save the parameters of each module, as well as relevant parameters such as the excitation module instance, the analysis module instance, and the CPU configuration module instance created by the user into a parameter configuration file. When the logic simulation test system is started, the parameter configuration file can be loaded to restore the previous configuration.

As shown in FIG. 3 , the logic simulation test system described in the embodiment of the present invention implements the test through the following steps.

First, explain and execute the main script file, and then establish the stimulus module object and the analysis module object according to the main script file, and configure the stimulus module object and the analysis module object according to the parameters therein.

An example of a main script file is as follows:

           
1. Lcfg(cfg_filename) --load configuration data

2. onbreak{ --Refer to the detailed design of the control module of the simulation module
part

3. If{brkmsg=="note"} {resume}else{

a) Set result "error"

(b) Writechkmsg(result) -- write the information to the dedicated LOG file and the use case
LOG file.

(c) Exit_test -- exit

b) }

4. run

5. #Command to change configuration parameters

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

7. Run

8. #Command to change configuration parameters

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

10. set result[auto_check] --result = "ok" or "error"

11. #Judge whether the result of auto_check verification is correct, write success or failure information to
log file.

12. Writechkmsg(result) -- write the information into the dedicated LOG file and the
LOG file.

13. Exit_test -- exit

        

The control module is responsible for interpreting and executing the above-mentioned script files, and controlling the behavior of each module in the logic simulation test system. The logic simulation test system provides many TCL extension commands, and users use these extension commands and TCL intrinsic commands to write simulation scripts. All operations of the simulation platform can be realized by extending TCL commands. The script file is not directly responsible for creating stimulus generation and analysis, but it can create stimulus module objects and analysis module objects, that is, create stimulus modules and analysis modules, so there are not many codes for each script. The important point is that after the simulation logic test is executed, information about whether the test case is passed or not can be obtained, and the information can be saved to a specified file.

The interpretation of onbreak in the script is as follows:

When the number of sent and received messages reaches the upper limit set by the user, the incentive module and the analysis module will send a message to the control module, and the level of the message is "note". The control module executes the onbreak statement body when receiving the message. If the stimulus module and the analysis module find an error when analyzing the message, they will also send a message to the control module, and the level of the message is "error". The user writes the body of the onbreak statement, which can process these messages, and can determine the module instance name and the specific message content that sent the message, so as to execute related commands, such as modifying the parameters of a certain module, or ending the simulation. Onbreak usually ends the execution of the run command after processing the message at the "note" level, making it return, so the script continues to execute the next script statement.

The interpretation of the run command in the script is as follows:

The run command in the script is quite special, it will not end or return automatically, it has been waiting for the execution of the resume command in the onbreak statement body to complete. During the execution of the run command, the service request initiated by the BFM to the simulation platform can be transmitted to the control module and then processed. During the execution of the non-run command, the service request initiated by the BFM to the simulation platform is blocked, and the operation of the emulator is also blocked at the same time.

The explanation of the auto_check command in the script is as follows:

This command is generally located at the end of the script and is executed at the end of the simulation. The control module traverses each module instance, calls their auto_check interface function, and checks the internal state of each module instance to check whether there is an error.

Second, the emulator module issues a test service request and sends it to the stimulus module object.

The emulator module sends a test service request according to the instructions of the control module, that is, the BFM of the testbench sends a message request, which is realized by calling the PLI interface program. The PLI interface program writes the parameters passed by the BFM into the parameter data structure in Figure 4, then initiates a request to the control module, and waits for the message that the request is processed. The following is an example of the BFM calling the PLI interface program:

$mii_read_pkt(modulename, framegap, tx_frame_len, tx_frame_data);

As shown in Figure 4, the PLI interface program and the excitation module (modulename in the above formula) exchange data through the parameter data structure, and the PLI interface program calls the interface function provided by the system after filling in the relevant data in the message request parameter data structure Send a request (during the execution of this function, the execution of the simulation software stops), after the data service module of the control module receives the excitation request, the control module obtains the target module (i.e. the excitation module instance) name from the message request parameter data structure, thereby Get the handle of the stimulus module instance, then call the message processing program of the stimulus module instance, and send the stimulus request to the stimulus module instance.

Third, the stimulus module object constructs a stimulus message according to the test service request, and writes the stimulus message into the aforementioned message request parameter data structure.

Various incentive modules are similar in constructing the incentive message mechanism, they all first mix multiple streams to form an incentive message flow through convective scheduling. Usually, a packet sequence with certain characteristics can be defined as a stream. For example, packets with the same VLAN ID can be defined as a flow, a sequence of packets with the same source MAC address can also be defined as a flow, or a sequence of packets with certain attributes at the same time can be defined as a flow. Some attributes (such as out-of-order, bandwidth, delay, burst, packet discard rate) can be set for a flow, such as the maximum logical delay of all packets belonging to the flow.

Secondly, multiple message streams are aggregated to form a message sent to the logic to be tested. In logic simulation, in order to generate realistic stimulus data, we usually define multiple streams (in the parameter configuration interface of the stimulus module instance, set the number of streams and the parameters of each stream, these parameters are called stimulus module instance configuration parameters). When the incentive module instance receives the request of the application message, it will schedule these flows according to a certain scheduling algorithm, schedule a flow, take out the parameters used for message construction from the flow (see Figure 5), and then execute the user Write the message construction script, and pass the aforementioned message construction parameters at the same time. The user writes the message construction script to be responsible for constructing the specific message. The script must use the special message construction command of the simulation platform, so that the stimulus module can read the constructed message. After the script is executed, the stimulus module instance gets the message data. The scheduled message can be sent to the logic to be tested as an incentive message. Among them, the concept of flow scheduling needs to be clarified: instead of generating the packet sequence of the flow first, and then scheduling each packet flow, the flow is scheduled according to the attribute data of the flow. Part of the attribute data with the nature of numbers (that is, the parameters used in the construction of the message) calls the message constructor to generate the dispatched message. For example, the UTOPIA L2 excitation module has multiple sub-ports, and each sub-port has multiple streams. At this time, the excitation module needs to implement sub-port scheduling, and each sub-port implements flow scheduling. The sub-port scheduling is related to the flow scheduling. Similarities.

The incentive module of the present embodiment includes a corresponding message constructor containing TCL scripts, and the incentive module schedules the required incentive data streams generated by each incentive module, and then calls the message constructor to generate the incentive message. More specifically, as shown in Figure 5, it is a schematic diagram of the message construction process. The incentive module schedules the required incentive data flow through the scheduling algorithm, and takes out the parameters of the flow, generates the payload part, and inserts a Label, the label is defined as follows:

Feature data (F55F) (2 bytes) + FSN (message sequence number) (3 bytes) + check code (sum of the first 5 bytes) (1 byte) + payload length (2 bytes) byte) + CRC32 (4 bytes) of the following payload;

Among them, the attribute parameter of the flow is to support the test of QOS (Quality Of Services: quality of service) attributes (such as out-of-order, bandwidth, delay, burst, and message discarding rate). Script commands can set the attribute parameters of each flow. These parameters (such as the bandwidth required by the user, burst) will control the scheduling of the flow. These parameters will also be used when the analysis module performs automatic analysis of the results (such as checking the actual , delay requirements, packet discard rate).

Then pass its parameters and static load Payload to the external TCL script, and then return through the TCL script message constructor to obtain the required incentive message. The TCL code that generates the message can be written in the following way:

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

#port_sn port number, assuming that ports numbered 1 and 2 are two MII ports, send to the logic
Ethernet telegram

#last_txpkt_sn is the serial number of the packet in the stream.

#flow_sn is the serial number of the flow in the port

#port_sn, last_txpkt_sn, flow_sn are defined as TCL script global variables, and
The corresponding global variables in the module are connected, and the incentive module assigns the corresponding parameters of the flow to the main module
These global variables of the block.

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

proc mii_pkt_build{}{

if($port_sn<3){

The #to_hex extension command is used to convert the input decimal parameters into a hexadecimal string,
The number of characters returned is controlled by the second parameter.

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 is an extended message construction command. Unspecified parameters, according to the default rules
Then construct the message. Refer to the MII stimulus module user manual. The generated message is saved in the main module
In the global message buffer, the stimulus module can read the generated messages from this buffer.

create_mac-dmac Ox$dmac-smac Ox$smac

#If the packet generated by create_mac is encapsulated as AAL5, continue:

create_aal5
        <!-- SIPO <DP n="13"> -->
        <dp n="d13"/>
#create_aal5 The extended command can identify the message type generated by create_mac and generate
suitable package.

}

}

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

        

The above message construction method is very convenient for constructing abnormal messages and multi-layer protocol encapsulated messages. Flow scheduling and message construction can be made into a base class, and then various incentive modules can be derived on this basis, which simplifies the workload of developing new incentive modules.

After the message is generated, the incentive module registers message-related information with the message database module: such as various parameters used when generating the message, and message generation time; the incentive module can also call the user verification module to obtain the expected processing result of the message.

After the stimulus module constructs the stimulus message, write the stimulus message into the message request parameter data structure, the PLI interface program calls the system interface function to return, and takes out the stimulus message processed by the simulation system from the message request parameter data structure , and send the stimulus message to the BFM in the emulator module.

Fourth, the emulator module completes the test on the input stimulus message, and sends the tested message containing the test result to the corresponding analysis module object.

The input stimulus data in the emulator module is sent to the BFM of the logic chip, and after obtaining the stimulus message, it converts the stimulus data into a timing signal and transmits it to the DUV. During simulation, the DUV processes stimulus data and outputs result data. The BFM at the data output port of the logic chip converts the signal output by the DUV into behavior-level data, that is, a result message (or a message to be analyzed).

The BFM at the data output port of the logic chip sends a service request, which is also realized by calling the PLI interface program. The PLI interface program initiates a request to the control module through the above-mentioned message request parameter data structure for the parameters passed by the BFM, and then waits for the message that the request processing is completed

The PLI interface program and the analysis module exchange data through the message request parameter data structure. After filling in the relevant data in the message request parameter data structure, the PLI interface program calls the interface function provided by the logic simulation test system to issue a request (during the execution of the function , the execution of the simulation software stops), after the data service module of the control module receives the service request, the control module obtains the name of the corresponding target module (that is, the analysis module instance) from the message request parameter data structure, thereby obtaining the name of the analysis module instance handle, and then call the message processing program of the analysis module, and send the analysis request to the analysis module, that is, the analysis module object, and the analysis module can take out the message to be tested from the message request parameter data structure.

Fifth, the analysis module analyzes the message to be tested, and outputs the analysis result.

After the analysis module receives the message to be tested from the BFM, it analyzes until the label inserted into the message by the simulation platform is extracted, and the verification of the static load of the message is completed. This analysis process is standardized and can be programmed, which more specifically includes:

1. Analyze the protocol compliance of the tested message. If it is a sliced message, reassemble the message to obtain a complete message;

If the tested message is a message automatically inserted by the logic to be tested, the verification is assisted by the user; otherwise, continue.

When the analysis module receives the logic to be tested, it automatically inserts messages, such as management messages and management cells. These messages do not contain message serial numbers, and are not messages generated by the simulation test system. For such messages, the analysis module cannot Further analyze its correctness, pass these messages to the user verification module, and let the user verification module judge the correctness.

In addition, the routing correctness, broadcast correctness, and message transformation correctness of the message need the auxiliary information provided by the user authentication module to complete. After the analysis module extracts the serial number of the message, it accesses the message database module to obtain the instance handle of the stimulus module that generated the message, and calls the instance of the stimulus module to restore the original message. The instance of the analysis module can call the user verification module compiled by the user, and The original message and the received message are passed to the user verification module. The user verification module completes the analysis of the correctness of the message transformation and gives the expected export list information. The analysis module returns the expected information according to the report in the message database module. The historical records of documents are analyzed to complete the analysis of routing correctness and broadcast copy correctness. The analysis module writes the analysis result and the export information of the received message into the message database module.

2. Parsing the complete message, extracting the insertion tag, and obtaining the payload of the message;

3. Verify the message payload and obtain the analysis result.

According to the recorded data of the message in the message database, the correctness of the export of the message, the correctness of the message delay and the correctness of the out-of-sequence of the message are automatically analyzed.

In the aforementioned incentive module, there are a series of parameters of the flow, which describe the QOS attributes of the flow. After the analysis module receives the message, it will notify the incentive module to check the QOS compliance, for example, check whether the delay of the message exceeds Set values, check for out-of-order.

In this way, testers can retrieve and display the analysis results and other relevant information in the message database module through the user interface service module in the control module.

Claims (12)

1, a kind of logic simulation test system, complete the test of the logic to be tested contained in the emulator module by the main script file of the user, it is characterized in that, this system includes: The control module is used to explain and execute the main script file and control the following modules; Message database module, used to store and read message data, retrieve and display, save to file and load from file; CPU configuration module, used to realize data reading and writing and interrupt; Several incentive modules are used to construct incentive messages; The emulator module is used to complete the simulation processing test on the input stimulus message, and output the message after the test; Several analysis modules are used to analyze the tested messages and output the analysis results; The HDL code module in the emulator module sends a test stimulus request to the control module, and the control module forwards the test stimulus request to a corresponding stimulus module, and the stimulus module constructs a stimulus message, and stores the message data information in the message database module, and send the stimulus message to the emulator module, read and process the input message by the HDL code module running in the emulator module, and output the processed message to the corresponding An analysis module, which analyzes the message processed by the test logic, and saves the analysis result to the message database module under the control of the CPU configuration module. 2. A kind of logic simulation test system as claimed in claim 1, characterized in that, said stimulus module includes a corresponding message constructor containing TCL script, and said stimulus module generates the required The incentive data flow, and then call the message constructor, that is, generate the incentive message. 3. A logic simulation test system as claimed in claim 1, characterized in that the system further comprises: the incentive module transmits the incentive message to the user verification module to obtain the expected processing result of the message, The stimulus module saves the expected processing results to the message database; the analysis module transmits the original stimulus message and the tested message to the user verification module, and the user verification module completes the processing of the stimulus message by the logic to be tested Further verify, and return the verification result to the analysis module. 4. A logic simulation test system according to claim 3, wherein said incentive module can call said user verification module to fill in expected information into said message database module. 5. A logic simulation test system as claimed in claim 1 or 3, characterized in that the connection between the control module and the excitation module, the analysis module, and the CPU configuration module is through the base class module ongoing. 6. A logic simulation test system according to claim 3, characterized in that the connection between the user verification module and the excitation module and the analysis module is performed through a base class module. 7, a kind of logic simulation test method, complete the test of the logic to be tested contained in the emulator module by the master script file of the user, it is characterized in that, the method comprises the following steps: a. Interpret and execute the main script file, then establish the stimulus module object and the analysis module object according to the main script file, and configure the stimulus module object and the analysis module object according to the parameters therein; b. The emulator module sends a test service request and sends it to the stimulus module object; c. The stimulus module object constructs a stimulus message according to the test service request, and sends the stimulus message to the emulator module; d. The emulator module completes simulation processing for the input stimulus message according to the hardware behavior described by the HDL code, and sends the processed message to the corresponding analysis stimulus module object; e. The analysis module object analyzes the processed message, and outputs the analysis result. 8. A logic simulation testing method according to claim 7, characterized in that the establishment of stimulus module objects and analysis module objects in said step b refers to the establishment of several corresponding stimulus module objects and analysis module objects. 9. A kind of logic simulation test method as claimed in claim 7, characterized in that, the data exchange between the emulator module and the stimulus module object in the step b, the step c and the emulator module and the analysis module in the step c The data exchange of objects is carried out through the parameter data structure. 10. A kind of logic simulation test method as claimed in claim 7, characterized in that, the construction of the incentive message in the step c is performed by scheduling the incentive data flow generated by each incentive module object, and then calling the corresponding TCL script message structure to generate the incentive message. 11. A logic simulation testing method as claimed in claim 7, characterized in that the analysis of the tested message in said step e more specifically comprises: e1. Perform protocol compliance analysis on the tested message, if it is a sliced message, reassemble the message to obtain a complete message; e2. Analyzing the complete message, extracting the inserted label, and obtaining the payload of the message; e3. Verify the message payload, and obtain the analysis result. 12. A logic simulation testing method according to claim 11, characterized in that, step e1 of said step e further comprises: if the message after the test is a message automatically inserted by the logic to be tested, then User-assisted authentication; otherwise continue.

Images