KR19990079355A - Test bench generator and simulation method using the same - Google Patents

Abstract

The present invention relates to a hardware description language (HDL) for electronic circuit design, and more particularly, to automatically generate a testbench for simulation of a submodule when designing an electronic circuit using HDL. The testbench generator and a method for simulating a submodule using the testbench generator, the testbench generator 10 takes the beryllog file 100 of the corresponding submodule and automatically generates four testbench files. To create. Any two of these files are used in the top module simulation 20 to generate two files to be used in the submodule simulation 30, and these and the other two of the testbench files are submodule simulations. It is used at 30 to produce the final result file.

Description

Testbench Generator and Simulation Method Using the Same (TESTBENCH GENERATOR AND SIMULATION METHOD)

The present invention relates to a hardware description language (HDL) for electronic circuit design, and more particularly, to automatically generate a testbench for simulation of a submodule when designing an electronic circuit using HDL. A testbench generator that can be used and how to simulate a submodule using the same.

Hardware Description Language (HDL) is a language used in electronic circuit design such as application specific integrated circuit (ASIC) and very large scale integration (VLSI) circuit. The design of the circuit using HDL describes the interconnection relationship of each component by using a certain grammar, and the described result can be simulated by the simulator. Through this, it is possible to verify the characteristics of the designed circuit, and finally to complete the pattern of the corresponding circuit. One example of such HDL is Verilog HDL. Logic designed using Beryllog HDL is simulated with a Beryllog simulator.

In general, in the development of hardware, circuit designers design circuits while changing various hardware specifications. When designing hardware using Beryllog HDL, the structure consists of several modules with a multi-level hierarchical structure. However, if the simulation is performed again for the entire circuit after a small circuit modification, the turn-around time (TAT) of the simulation is too long, which greatly reduces the efficiency of the simulation.

Therefore, when the hardware to be simulated consists of several submodules, it is necessary to exclude the submodules that are operating normally and perform simulation only on the submodules to be modified. To this end, conventionally, a testbench for a submodule had to be manually created. The problem with this method is that it is difficult to describe accurately because the stimulus applied in the testbench created separately is made in the relationship with other modules.

Accordingly, an object of the present invention has been proposed to solve the above-mentioned problems, and to provide a test bench generator that can automatically generate a test bench for simulation of a sub-module when designing an electronic circuit using HDL.

Another object of the present invention is to provide a method for simulating a submodule using a testbench generator capable of automatically generating a testbench for simulation of a submodule when designing an electronic circuit using HDL.

1 is a view showing a simulation method using a test bench generator according to an embodiment of the present invention; And

2 is a flowchart illustrating a flow of operation of a test bench generator according to an exemplary embodiment of the present invention.

According to a feature of the present invention for achieving the object of the present invention as described above, the simulation method of an electronic circuit designed in HDL, consisting of a multi-stage module: Insert files and testbench files for the simulation of a specific submodule Generating a plurality of files using a test bench generator to generate; Performing a top module simulation using respective files for input and output of the submodule among a plurality of generated insertion files; And performing a corresponding submodule simulation by using files for the submodule simulation generated after the top module simulation and a specific testbench file among the testbench files.

In this embodiment, the test bench generator is configured to: analyze information of the submodule including the name of the corresponding submodule and additional information from the HDL file of the submodule; Open respective files and record corresponding header information for storage of a plurality of said test bench files; A plurality of nodes are sequentially analyzed to determine one of input, output, and input / output nodes, and accordingly, information corresponding to a corresponding file among the test bench files is input.

According to the present invention as described above, the test bench generator takes the beryllog file of the corresponding submodule to generate four files for the simulation of the submodule, the corresponding files of these files are respectively the top module simulation, Used for submodule simulation. Therefore, the simulation of a specific submodule can be executed automatically.

(Example)

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a view showing a simulation method using a test bench generator according to an embodiment of the present invention, and Figure 2 is a flow chart showing the flow of operation of the test bench generator according to an embodiment of the present invention. Blocks marked with '*' in FIG. 1 indicate auto-generated files, and the lines indicated by dotted lines show the process of being automatically generated and automatically included.

Referring to Figure 1, the test bench generator 10 according to an embodiment of the present invention is a program that can be written in C language (C language). The test bench generator 10 takes one argument when executed, which is the beryllog file 100 of a specific submodule to be simulated. The beryllog file 100 includes only one submodule. The beryllog file 100 of this submodule includes information on input, output, and input / output ports, and the test bench generator 10 includes information on input, output, and input / output ports from the beryllog file 100. Create three include files and one testbench file. These four files are the [module_name] .in.inc (210), [module_name] .out.inc (220), [module_name] _sub.out.inc (230) insert files and [module_name] _sub_tb.v ( 240) This is a test bench file. Here, [module_name] is the name of the submodule of the beryllog file 100 which is given as an argument (hereinafter, [module_name] is represented by '˜').

The ~ .in.inc (210) is a file containing code for detecting a change in the input port of the submodule, the ~ .out.inc (220) is a change that occurs in the output port of the submodule This file contains the code for recording. The ~ _sub.out.inc 230 is a file used later in the submodule simulation 30, and the ~ _sub_tb.v 240 is a test bench for only the submodule.

Of these four files, the two files ˜.in.inc 210 and ˜.out.inc 220 are used in the top-module simulation 20. In other words, the two files, ~ .in.inc (210) and ~ .out.inc (220), are separated from each other by using an insert command at the end of the test bench to simulate the entire hardware designed in Beryllog HDL Top-module simulation 20 is performed by inserting a ~ _sub_tb.v (300) file which is a test bench for the top-module. This results in three files: [module_name] .sti (410), [module_name] .clk (420) and [module_name] .prb (510).

The ~ .sti (410) file stores inputs applied to the input and output ports of the submodule. The clk 420 includes a definition of a clock. By processing a signal having a regularity such as a clock separately from a general input, the size of the ~ .sti (410) file can be greatly reduced. The ~ .prb 510 file is a sampled sample of the output port of the submodule at a predetermined interval, and can be compared with the ~ _sub.prb 520 generated after the submodule simulation.

Insert files generated from the test bench generator 10 ˜_sub.out.inc 230, ˜_sub.tb.v 240, and two files generated from the top module simulation 20 ˜. sti 410 and ˜.clk 420 are used in the submodule simulation 30. When the submodule simulation 30 is completed using the files as described above, the file _sub.prb 520 is finally generated. This is the simulation result of the corresponding submodule.

Meanwhile, in order to completely automate the creation of the test bench for the submodule, various additional information must be delivered in addition to the basic information included in the beryllog file 100 of the submodule. To this end, it is very inconvenient to request additional information from the user every time the test bench generator 10 is executed. Therefore, the additional information is inserted into the beryllog file 100 of the submodule using a compiler directive. An example of additional information to be inserted is as follows.

// $ OBSERVE sigA

// $ CLOCK sigB

// $ HIERARCHY U1.U2.U4

// $ PERIOD 1000

// $ STROBE 880

// $ SIMULATION_TIME 324000

// $ BIDIR_CONTROL_OE sigA oeA

// $ BIDIR_CONTROL_OEB sigB oebB

Since the compiler directive as described above starts with '//' in the Beryllogue HDL, the information can be transmitted only to the test bench generator 10 without affecting the simulation. .

The $ OBSERVE is for observing an internal node (NODE) in addition to the basic output signal and storing it in the output file. The $ CLOCK means that sigA is a clock signal having periodicity, not a general signal. The $ HIERARCHY refers to a hierarchical position occupied by the current submodule in the top level test bench. The $ PERIOD represents a period for observing an output signal when generating an output file. The $ STROBE means a time point observed within one period. The $ SIMULATION_TIME means the total simulation time. In the case of the bidirectional signal, the direction control signal is used to determine whether it is an input or an output. When the output enable signal is active-high, the $ BIDIR_CONTROL_OE is used and the active-low signal is active-high. low), the $ BIDIR_CONTROL_OEB is used.

Meanwhile, the test bench generator 10 generates the four insertion files 210, 220, 230, and 240 by an operation as shown in FIG. 2.

Referring to FIG. 2, the test bench generator 10 includes the submodule including the name of the corresponding submodule from the beryllog file 100 of the submodule and additional information included in the sub-module in step S110. Parsing information from At this stage, necessary data may be input through manual input if necessary. In step S120, the respective files are opened for storing the plurality of test bench files and the corresponding header information is recorded. In operation S130, the plurality of nodes may be sequentially analyzed to determine whether the input, output, or input / output node is one of the input, output, and input information corresponding to the corresponding file among the test bench files opened accordingly.

In more detail, in step S131, characteristics of each node are input. In step S132, it is determined whether an input node is an input node. In the case of an input node, an observing code of the corresponding input node is generated. In step S134, an output node is output node. If it is an output node, it generates a strobing code of the corresponding output node. In step S136, it is determined whether the input / output node is a bidirectional node, and in the case of the input / output node, an Observing Code and a Stroving Code of the corresponding input / output node are generated. In step S138, it is determined whether all the nodes have been processed. If there are still unprocessed nodes, the process proceeds to step S131 and repeats the processing.

According to the present invention as described above, if there is a need to create a test bench for a specific sub-module in a state in which the simulation environment of the entire hardware is constructed, the process can be automated to minimize the simulation TAT to increase efficiency in logic design. . If you write your testbench in an automated fashion, you do not need to do much manual work. In addition, since the stimulus supplied from the test bench for the submodule is exactly the same as when the submodule to be simulated works with other parts of the hardware, the same effect as that of simulating the entire hardware can be obtained. . In addition, the result file of the output of the submodule is automatically generated so that it can be directly compared with the previous result after the circuit modification.

Claims (2)

In a method of simulating electronic circuits designed in HDL and composed of multi-stage modules: Generating a plurality of files corresponding to each other using a test bench generator for generating an insert file and test bench files for a simulation of a specific submodule; Performing a top module simulation using respective files for input and output of the submodule among a plurality of generated insertion files; And performing a corresponding submodule simulation by using files for a submodule simulation generated after the top module simulation and a specific testbench file among the testbench files. Simulation method. The method of claim 1, The test bench generator is: Analyze information of the submodule including the name of the corresponding submodule and additional information from the HDL file of the submodule; Open respective files and record corresponding header information for storage of a plurality of said test bench files; Electronically designed HDL characterized by sequentially analyzing a plurality of nodes provided to determine any one of the input, output, input and output nodes, and accordingly input information corresponding to the corresponding file among the test bench files Simulation method of the circuit.