CN1577274A - Automation emulation method and system - Google Patents

Abstract

The invention discloses an automatic simulation method. A device with information processing capability completes the simulation by executing a script. The method includes the steps of: starting the execution script to start a verification project; configuration file; execute the script to start the emulator and run the simulation script to simulate the measured object, the measured object receives the excitation signal and reads the configuration file, and saves the response data generated during the simulation process; executes the script to start the data comparison script and the result analysis script, Compare response data with expected values and output analysis results. The invention also discloses a logic automation simulation system at the same time.

Description

Automatic simulation method and system

technical field

The invention relates to simulation technology, in particular to an automatic simulation method and system.

Background technique

The baseband processing of wireless communication equipment mainly adopts physical layer protocol and digital signal processing algorithm realized in digital way. According to different implementation manners, the implementation manners in the prior art can be divided into three implementation manners: software, hardware, or a combination of software and hardware. In the hardware-software hybrid implementation, the hardware implementation mainly adopts an application-specific integrated circuit (ASIC)/field-programmable gate array (FPGA) method. However, since ASIC/FPGA has the characteristics of large design scale, complex structure, and difficult verification, as the scale of logic chips increases and the complexity continues to increase, the workload of logic simulation verification increases exponentially. It is not conducive to implementation and increases the cost.

In the prior art, a commercial emulator is commonly used to complete the logic simulation verification, and the script operating environment is integrated inside the commercial emulator, for example: the Tool Command Language (TCL) script operating environment is embedded in the Modelsim emulator itself, and the developed A set of macro commands specially used for simulation, users can run simulation scripts in this environment, which can achieve a certain degree of automation, as shown in Figure 1.

However, in the above solution, the simulation environment is completely closed and has limited functions, and only simulation scripts can be run. There is no special logic simulation project management function designed for the characteristics of logic verification, and it is impossible to realize the entire simulation project, test case, regression test, etc. The management of the simulation makes the efficiency and automation of the simulation very low. In addition, because the simulation environment is related to the specific emulator, the external interface is not open, it is difficult to integrate with other tools, and its scalability, portability and reusability are poor, which makes it difficult for users to add the functions they need. very difficult.

Contents of the invention

The invention provides an automatic simulation method and system to solve the problem of low efficiency in the prior art due to the inability to realize the automation of logic verification.

In order to solve the above problems, the present invention provides the following technical solutions:

An automated simulation method, comprising the steps of:

A. Start the execution script to start verifying the project;

B. Execute the script to start the excitation script and the configuration script to generate the excitation signal and generate the configuration file respectively;

C, execute the script to start the emulator, receive the excitation signal and read the configuration file by the emulator;

D. The emulator runs the simulation script for simulation, and saves the response data generated during the simulation process;

E. Execute the script to start the data comparison script and the result analysis script, compare the response data with the expected value, and output the analysis result.

An automated simulation system includes a processor for data processing, a memory for storing programs and data, and a simulation platform, which includes:

Verification script module: composed of command sets for starting and executing scripts, used to start and execute scripts to execute test columns;

Emulator module: started by the execution foot, used to run the simulation script for simulation;

Verification project module: including relevant file modules required for the verification process, and adopting a fixed directory structure to organize the relevant file modules;

Verification project management module: used to realize the directory management of the entire verification project module, the execution of test columns and regression test execution, and provide a user interface for project management operations.

Wherein: the simulation platform further includes a user expansion interface module, through which tools are added to the simulation platform.

The invention adopts a verification project management method suitable for logic simulation automation, and provides a convenient extension interface for users, so that users can complete the automatic simulation of the entire logic project based on this platform, greatly improving the standardization and automation of simulation, and the simulation Sharing between projects.

Description of drawings

Fig. 1 is the block diagram of simulation structure of prior art;

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

Fig. 3, Fig. 4 are simulation platform structural diagrams of the present invention;

Fig. 5 is the simulation flowchart of the present invention;

Fig. 6 is a schematic diagram of the simulation process;

Figure 7 is a schematic diagram of the user interface;

Fig. 8 is a schematic diagram of the corresponding relationship between the test column and the test platform;

Figure 9 is a schematic diagram of the directory structure of the verification project;

Figure 10 is a schematic diagram of the directory structure of verification related files;

Figure 11 is a schematic diagram of script correspondence;

Fig. 12, Fig. 13, Fig. 14, Fig. 15 and Fig. 16 are the tool guide development template interface diagrams;

Fig. 17A, Fig. 17B and Fig. 17C are schematic flow charts in the process of developing tools;

Fig. 18 is a working flowchart of the WCDMA uplink dedicated channel excitation data generation tool.

Detailed ways

The process of logic verification is the process of applying incentives to the object under test and verifying whether the logic is correct by detecting its response, as shown in Figure 2A. For simple logic, the provision of stimulus and comparison of responses can be realized only in a test bench written in a hardware description language (HDL), so the requirements for automation are not high. With the development of technology, the logic design becomes more and more complex, and the difficulty of logic verification is also greatly increased. The provision of incentives and the detection of responses need to be realized in various ways, such as the generation of incentive data by writing C language programs. For algorithmic logic, the generation of incentives and the detection of responses often involve complex algorithms, so it is necessary to use algorithm simulation tools such as Matlab and Cossap or write application programs to implement complex algorithms.

The most common way to achieve automation is to provide a unified work platform and realize the scripting of the process. As shown in Figure 2B, many resources may be required to complete a test task, and the execution of the simulation process includes many steps. In the past, these resources and steps were relatively independent and scattered, and the efficiency of management and execution was very low.

Referring to Fig. 3 and Fig. 4, the system of the present invention organically integrates resources together, and connects various steps of the simulation process in series through scripts, thereby realizing the automatic execution of the simulation process.

Figure 3 shows a computer with which it can implement the method of the present invention. The computer has a processor, which is connected to the memory through the bus, and is also connected to the input and output interfaces through the bus.

The memory stores the simulation platform program and related data. The input and output interface is connected with the keyboard, the printing device and the display, and the verification result and the user interface are displayed through the display, and the verification result is also output in text form by the printing device in a prescribed format.

Figure 4 shows the structure of the algorithm logic simulation platform, including a verification project management module, which realizes the directory management of the entire simulation project, the execution of test cases and the execution of regression tests. Execution of test cases is achieved by invoking TCL verification scripts. In the platform, TCL scripts play the role of "paste" and are used to integrate various applications and tools to automate the entire verification process. In addition, the platform provides a user extension interface, and users can easily expand the functions they need into tools and call them in verification scripts. For example, if the user needs to increase the function of generating some kind of incentive data, this function can be implemented in C or other languages and expanded into TCL commands, so that it can be called in the verification script.

The algorithmic logic automation simulation platform uses the TCL scripting language. The platform does not directly control the HDL simulator, nor does it directly exchange data with the simulator, but indirectly calls the simulator through scripts to achieve the purpose of simulation, so it is compatible with all HDL simulators and serves as a general logic simulation platform.

Referring to FIG. 7 , the verification project management module of the algorithmic logic test platform provides a user interface. The user interface has three main areas: the mode control area, the code display and editing area, and the status area, in addition to the menu bar and toolbar.

There are three modes to choose from in the mode control area, which are test task, toolbox and code browsing. The test task is mainly used for the creation and management of test tasks, test case management and other functions, and adopts a directory structure that conforms to the algorithmic logic integration simulation specification. Code browsing can display the basic structure of TCL scripts, such as the name space and the subroutine name defined in it. Double-click the subroutine name to display the code of the subroutine in the code display and editing area on the right. The toolbox contains various tools developed for specific test items, such as WCDMA uplink access channel excitation signal generation. Various tools in the toolbox provide a graphical user interface, which is a floating window, and the user can set related parameters in the window. All three modes use a navigation tree structure.

Referring to Figure 5 and Figure 6, the automated simulation process is as follows:

Step 10: Start the execution script to start verifying the project;

Step 20: Execute the script to start the excitation script and the configuration script to generate the excitation signal and generate the configuration file respectively;

Step 30: Execute the script to start the emulator, and the emulator runs the simulation script to simulate the object under test;

Step 40: the object under test receives the excitation signal and reads the configuration file, and saves the response data generated by the object under test during the simulation process;

Step 50: Execute the script to start the data comparison script and the result analysis script, compare the response data with the expected value, and output the analysis result.

Wherein, there may be multiple execution scripts, and the multiple execution scripts are sequentially started by the verification script to complete the verification project requiring multiple test tasks.

In order to realize the unified management of the verification items and standardize the verification process, this embodiment fixes the directory of the verification items. Each verification project uses the same directory structure. The biggest advantage of using a common directory structure is that you can use relative paths, write portable scripts, and find files easily.

The directory structure is determined according to the characteristics of algorithm logic verification. In logic verification, test cases are grouped, and test cases in the same group use the same test platform (Testbench). A group of test cases and their corresponding Testbench is called a verification program group. There may be multiple validator groups for a validation project. Refer to Figure 8, the correspondence between test cases and Testbench.

Refer to Figure 9, which shows the top-level directory structure of the verification project:

Among them, the subdirectory SoC_N in the figure is the verification project, and each verification project contains the first to sixth subdirectories, and the functions are as follows:

The first subdirectory doc: store related specifications, design and verification documents;

The second subdirectory beh: stores reusable behavior models, public subroutines and functions, etc.;

The third subdirectory rtl: store the design source code that can be synthesized;

The fourth subdirectory syn: stores the comprehensive script, netlist and various report files generated by synthesis;

The fifth subdirectory phy: store constraint files, layout and routing scripts, burn-in files and various report files generated during the layout and routing process;

The sixth subdirectory verif: stores verification-related files, which is composed of a verification program group (verisuite). A program group includes a group of interrelated test files, mainly testbench and a group of test cases (testcase) corresponding to this testbench. Each testcase includes test scripts, configuration data files, stimulus data files, simulation result data files, and reference comparison data files.

The directory structure of the sixth subdirectory verif is shown in FIG. 10 . The directory structure fully considers the structure of testbench and the characteristics of algorithm logic.

Verisuite subdirectory of the verification program group: called the verification program group, which stores the test files required to verify a certain type of characteristics. All testcases in this group use the same testbench, and each testcase has different configurations, stimuli, responses, and reference comparison data;

Simulation work subdirectory work: It is the simulation work directory, which stores the simulation compilation results, and serves as a temporary directory for file copy operations during simulation;

Script subdirectory scripts: store the scripts that need to be called in the simulation;

Configuration file subdirectory config: store configuration files;

Stimuli file subdirectory stimuli: store stimulus data files;

Simulation result subdirectory result: store simulation output results, simulation process log files, code coverage reports and defect tracking tables;

Comparison data subdirectory reference: store simulation reference comparison data;

Execution script subdirectory run.tcl: the execution script of the test case, which is also executed during the regression test;

Description file subdirectory readme.txt: detailed description file of the test case.

The project management capabilities of the simulation platform include:

・Creation, deletion, import, and export of authentication items

Users can create, delete, import, and export verification items under the test root directory.

Creation, deletion, import, and export of verification program groups

Users can create, delete, import, and export verifier groups under the verif directory.

· Create, delete, import and export test cases

Users can create, delete, import, and export test cases in the verisuite directory.

Using the above functions, verifiers can easily realize the sharing, reuse, porting and archiving of test codes.

The calling relationship of test case scripts is shown in Figure 11 (take testcase as the current directory). Each test case has only one execution script (run.tcl), and the execution of the test case is realized by running the script. Executing scripts will call other scripts according to the specific test items. These scripts include simulation scripts, stimulus generation scripts, response comparison scripts, and result analysis scripts, among others. It is necessary to briefly explain the calling method of the simulation script, and use the following command to implement the Modelsim simulator.

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

Regression testing is an essential part of the logic verification process. Using the test scheduler Scheduler of the algorithmic logic simulation platform, we can easily add the test cases that need regression to the regression test group, save and run automatically. The test scheduler allows users to create regression test groups in a specified order, start the test at a specified time, and execute the test scripts in it sequentially.

The user extension interface (called tool guide or toolbox in the platform, hereinafter referred to as tool guide) is a part of the algorithm logic simulation platform, and it is also a part of the platform where users can perform secondary development. It has good scalability and reusability properties, the interface is shown in Figure 12A. Because in logic testing activities, each logic has its own different characteristics, in order to complete the verification, users need to develop some tools by themselves, such as incentive generation tools, result analysis tools, process control tools, script generation tools, etc. Using the user extension interface can enable users to complete adding functions to the platform in the least time.

The tool guide divides all parameters that need to be configured by a tool into multiple steps to configure, and completes the configuration of all parameters through step-by-step parameter configuration. Emulator provides a tool guide development template. The tool guides developed according to this template have the same interface style and usage methods. In this way, the tool guides developed by anyone are standard and can be used directly by others. No training is required on how to use it. The tool guide is completely developed in TCL/TK language, and can run on different operating systems, with good portability.

· Directory structure of the tool guide

In the root directory of the platform, there is a folder ToolWizards specially used to store tool wizards. The directory structure is shown in Figure 12B:

There is a directory ToolWizards under the root directory of the platform, all tool wizards are stored in this directory, and each tool wizard directory includes two directories (images directory for storing flowcharts and directory pakcage for storing files implementing tools ) and two files (the TCL file realized by the tool guide interface and the help file in wordpro format), among which the TCL file realized by the tool guide interface has been made into a template file, and the user only needs to make simple modifications to complete the development of the tool.

·Interface description of the tool guide

The tool wizard only includes three different interfaces, which are tool information (start step), parameter configuration (intermediate step) and completion (end step) pages, and the parameter configuration can include multiple pages.

The tool information interface is the page displayed after the tool is started, which mainly displays some basic information of the tool, so that the user can have a basic understanding of the tool. Click the button [Help] on the lower left to open the help document of this tool. The tool information interface is shown in Figure 13.

Parameter configuration is the main part of the tool wizard. This part completes the parameter configuration of all steps of the tool, and each step corresponds to a page. Each page is composed of a prompt part and a parameter configuration part. The prompt part mainly indicates the position of this step in the entire tool workflow. The user provides the required picture and embeds it into this page to let the user understand the corresponding parameters of the current configuration. Which part of the workflow; the parameter configuration part allows users to configure parameters conveniently in a visual way. Click the button [Help] on the lower left to open the help document of this tool; click the button [Next>>] on the lower right to enter the next parameter configuration of the parameter configuration step; click the button [<<Back] on the lower right to return to the previous one page; the drop-down combo box on the upper right is a list of all parameter steps, which provides a quick channel to enter other parameter configuration pages, and you can directly enter the corresponding step page by selecting a different configuration step. The parameter configuration interface is shown in Figure 14.

As shown in Figure 15, completing the page is the last step of the tool wizard. The left side of the page is the parameter list, which is a summary of all parameter configurations. It lists all the configured parameter values. The parameter values cannot be modified here. Yes, if the user needs to modify, they can go back to the corresponding step for modification. Here, a number is added before each parameter name to indicate which step the parameter belongs to; the tool script command editing area is on the right, when the user clicks the button below [Make] Then substitute the parameters in the list on the left into the command implemented by the tool to form a TCL script command, which will be displayed in the tool script editing area. The user can modify the tool script in the editing area, or directly copy and paste it into the verification script. ; Below is a row of command operation buttons, which are [Help]: open the help document of this tool, [Clear]: clear the content of the tool script editing area, [Make]: generate the tool script and display it in the editing area, [Insert] : Insert the content of the editing area into the script editor of the platform.

·Introduction to six basic controls

In each parameter configuration page, six basic controls are provided, which can satisfy all situations of input parameters, and are introduced below:

A. A drop-down combo box (ComboBox), used to select one of multiple choices. When there are less than 10 options, the format of the control property is {"first value" "second value" "third value" ""fourth value""fifth value"}

B. The switch control (checkbutton) is used in the case of choosing one of the two. The control attribute format is {"displayed content", "value when ticked" and "value when the check is removed"}, such as {"double antenna open"" 1" "0"}

C. Numerical adjustment control (SpinBox), used for data selection with regular numerical changes. Generally, there are more than 10 options, and the control attribute format is {minimum value, maximum value change step size}, such as {0 100 5}

D. Text input box (entry), used to input text, including numbers, used for irregular text or number input, the control attribute format is empty, ie {}

E. Radio button (radiobutton), which is used to select one of a few options, and there are no more than 4 options. The format of the control attribute is {"the first case" "the value of the first case" "the second case"" The value of the second case" "the third case" "the value of the third case" "the fourth case" "the value of the fourth case"}

F. The file selection box (entry), used to select the file name, such as selecting an input or output file, the control attribute format is {"I or O"}, I indicates that the selected file is an input file, O indicates that the selected file is an output document.

· Control position

In each parameter configuration page, there are 8 positions for placing controls, and their distribution and position numbers are shown in Figure 16: each position in the figure can place a short control (one of controls A, B, C, and D) ), two positions on the same line (ie 1 and 2, 3 and 4, 5 and 6) can place a long control (one of the controls E, F), so that up to 8 short controls can be placed on each page Control or 4 long controls, if there are both long controls and short controls, the number of controls is between 4 and 8. Therefore, you can only configure up to 8 parameters in each step. If there are more parameters, you can split them into multiple steps for configuration.

·Tool wizard development steps

The general steps for developing tools on the algorithmic logic test platform are described below.

First of all, to realize the tool, the tool wizard of this platform supports the following three implementation forms of tools:

1) A DLL binary package implemented in C/C++ and expanded into a TCL command;

2) Packages implemented in pure TCL;

3) An executable file (suffixed as exe) with parameters.

Then, the configuration parameters of the tools need to be divided into modules to form multiple configuration steps. It is best to divide them according to the workflow of the tools, so that all parameters that need to be configured are divided into multiple steps for configuration. The principle of module division is to be able to reflect the workflow of the tool, and there must be a relatively close relationship between the divided steps. Then draw these steps into a flow chart for the picture prompt in this step, for example, a flow chart divided into two steps is shown in FIG. 17A .

For example, the work flow diagram of the WCDMA uplink dedicated channel excitation data generation tool is shown in Figure 18:

The next step is to create the corresponding pictures displayed in each step. The prompt pictures in each step can be different. The basic requirement is to be able to serve as a reminder, so that users can know this step after viewing the pictures. What is the role of the parameters to be configured in . When configuring the parameters of the corresponding steps, it is recommended to reflect the steps in the flow chart drawn above in the form of enhanced colors, which is simple to make but has a strong prompting effect. The prompt pictures in the two steps that have been made are as follows:

The flowchart (image1.gif) in the first step is shown in Figure 17B; the flowchart in the second step (image2.gif) is shown in Figure 17C.

After planning the steps of the tool and the parameters to be configured in each step, you can start to modify the TCL template file implemented by the tool wizard interface, and modify it according to the template (DemoWizard.tcl, which can be changed to your own name) provided in the attachment below. You only need to modify the variable value of the user setting part, and other modules do not need to make any modifications.

The invention can organically combine various resources into the verification process through scripts, has good scalability, repeatability and reusability, and improves the efficiency and automation of verification.

Claims (14)

1, a kind of automation simulation method is characterized in that the method comprising the steps of:

Start the execution script and begin the checking project;

Carrying out script startup excitation script and configuration script produces pumping signal respectively and generates configuration file;

Carry out script startup emulator operation emulation script measurand is carried out emulation, measurand receives pumping signal and reads configuration file, and preserves the response data that simulation process produces;

Carry out script startup data contrast script and interpretation of result script, response data and desired value are compared, the output analysis result.

2, the method for claim 1 is characterized in that, described execution script is a plurality of, starts this a plurality of execution scripts successively by the checking script, to finish the checking project that need carry out a plurality of test assignments.

3, method as claimed in claim 1 or 2 is characterized in that, the checking project all adopts fixed schedule structure organization associated documents.

4, method as claimed in claim 3 is characterized in that, the bibliographic structure of checking project comprises:

First sub-directory is used to preserve relevant specification, design and identifying file;

Second sub-directory is used to preserve reusable behavior model, public subroutine and function;

The 3rd sub-directory, be used to preserve can be comprehensive design source code;

The 4th sub-directory is used to preserve comprehensive script, net table and the comprehensive various report file that produces;

The 5th sub-directory is used for preserving the various report file that unbound document, placement-and-routing's script, firm file and placement-and-routing's process produce;

The 6th sub-directory is used for preserving the checking associated documents.

5, method as claimed in claim 4 is characterized in that: the 6th sub-directory further comprises:

The simulation work sub-directory is preserved emulation compiling result, and carries out the document copying operation during for emulation as temp directory;

Proving program group sub-directory is used to deposit in order to verify the required test file of a certain class feature of measurand.

6, method as claimed in claim 5 is characterized in that: proving program group sub-directory comprises the identical test of a plurality of bibliographic structures row sub-directory, and each test case sub-directory further comprises:

The script catalogue is used for preserving emulation and needs invoked script;

The configuration file catalogue is used to preserve configuration file;

The excitation file directory is used to preserve the excited data file;

The simulation result catalogue is used to preserve emulation output result, simulation process journal file, code coverage report and defective Track Table;

The correlation data catalogue is used to preserve emulation with reference to the comparison data;

Carry out the script catalogue, be used to preserve the execution script of this test case;

The supporting paper catalogue is used to preserve the detailed description file of this test case.

7, method as claimed in claim 1 or 2 is characterized in that: described checking project and proof procedure carry out unified management by the checking project management module, and this checking project management module provides a user interface to verify the project management operation for the user.

8, method as claimed in claim 7 is characterized in that, the checking project management module provides user's expansion interface by user interface, and the user verifies the project management module function by this user's expansion interface developing instrument to increase.

9, method as claimed in claim 8 is characterized in that, described expansion interface provides instrument guide development template, to develop the instrument guide of standard.

10, a kind of automation simulation system comprises the processor that is used for data processing, is used for stored programme and memory of data, it is characterized in that this system also has emulation platform, and this simulation table comprises:

Checking script module: constitute by the command set that starts the execution script, be used for starting the execution script and carry out test with being listed as;

Emulator module: start by carrying out pin, be used to move the emulation script and carry out emulation;

Checking projects module: comprise the associated documents module that proof procedure is required, and adopt the described associated documents module of fixed schedule structure organization;

Checking project management module: be used to realize the directory management of whole checking projects module, execution and the regression test execution that row are used in test, and provide a user interface for the project management operation.

11, analogue system as claimed in claim 10 is characterized in that also comprising user's expansion connection module, increases instrument by this expansion connection module to emulation platform.

12, analogue system as claimed in claim 11 is characterized in that described user's expansion connection module comprises instrument guide development module, goes out the instrument of standard by this Development of Module.

13, as the described analogue system of one of claim 10 to 12, it is characterized in that: the bibliographic structure of checking projects module comprises:

First sub-directory is used to preserve relevant specification, design and identifying file;

Second sub-directory is used to preserve reusable behavior model, public subroutine and function;

The 3rd sub-directory, be used to preserve can be comprehensive design source code;

The 4th sub-directory is used to preserve comprehensive script, net table and the comprehensive various report file that produces;

The 5th sub-directory is used for preserving the various report file that unbound document, placement-and-routing's script, firm file and placement-and-routing's process produce;

The 6th sub-directory is used for preserving the checking associated documents.

14, analogue system as claimed in claim 13 is characterized in that: the 6th sub-directory further comprises:

The simulation work sub-directory is preserved emulation compiling result, and carries out the document copying operation during for emulation as temp directory;

Proving program group sub-directory is used to deposit in order to verify the required test file of a certain class feature of measurand.

Wherein: proving program group sub-directory comprises the identical test of a plurality of bibliographic structures row sub-directory, and each test case sub-directory further comprises:

The script sub-directory is used for preserving emulation and needs invoked script;

The configuration file sub-directory is used to preserve configuration file;

Excitation file sub-directory is used to preserve the excited data file;

The simulation result sub-directory is used to preserve emulation output result, simulation process journal file, code coverage report and defective Track Table;

The correlation data sub-directory is used to preserve emulation with reference to the comparison data;

Carry out the script sub-directory, be used to preserve the execution script of this test case;

The supporting paper sub-directory is used to preserve the detailed description file of this test case.

Images