JPH0954709A - Method and structure for debug information display - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and structure for debug information display capable of heightening the efficiency of debugging of a test vector. SOLUTION: Arranging structure for debug information display on a display for debug by the test vector described in high-level language is the one for debug information display provided with a history information display part which displays the generating time of an error, that of a specific operation stored in a memory device at every specific operation such as a sub routine call, etc., and the attribute information of the specific operation including a source file name by making relate to test time in addition to at least one of a time display part 11, a waveform(14-16) display part and a fail map display part.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to the fields of LSI design, development, and manufacturing, and more specifically, a debug information display method and debug method capable of improving the efficiency of debugging a test vector (also called a test pattern). Information display structure.

[0002]

[Technical background] In designing and developing an LSI by CAE or the like, a large number of test vectors that cover all the functions of the target LSI are created for simulation before the prototype of the LSI and these test vectors are used. , LSI functional tests, etc. FIG. 5 systematically shows the test flow before and after the trial manufacture of the LSI. The functional test after the LSI is prototyped will be described later.

Usually, as shown in FIG. 5, first, a logic model simulation and function debugging are performed using a behavioral model 101 based on a design specification 103 to create a circuit model 104. After this, the simulator 108
Will perform simulation including timing and debug timing and function. In order to perform this simulation, a large number of simulation test vectors 107 are used. The test vector 107 is created by using the test vector creation language 105 or the graphical test vector creation tool 106.

However, in recent years, these test vectors have been subject to 100,000 to 10,000, due to the increase in the timing and functions to be confirmed with the increase in the scale of LSI.
It has reached to 000. These test vectors are created by ATPG (Automatic Test Pat).
is being automated by the Turn Generator. However, in many cases, the test vector for the functional test of the LSI cannot be created by ATPG, and it is necessary to create it manually.

When a large number of test vectors are manually created, a series of operations of the target LSI are generally created as a subroutine using a high-level language, and these are combined to write a program. Verilo
An example of the source code of the test vector by g-HDL is shown in 1 of FIG. 6 and 2 of FIG. 6, and the equivalent source code in C language is shown in 1 of FIG. 7 and 2 of FIG. Note that line numbers are added to these source codes for convenience of description.

Lines 1 to 5 of FIG. 6 and lines 14 to 52 of 2 of FIG. 6 (lines 4 to 36 of 1 of FIG. 7) are the basic operations for reading and writing data from and to the memory elements in the LSI as subroutines (subroutine "read"). "Write"). 54 lines 2-60 of FIG. 6 (38-44 lines of 1 of FIG. 7)
The row) is a subroutine (subroutine “readwrite”) that is a test vector for testing whether or not the reading and writing of the memory element in the LSI has been correctly performed. Lines 62 to 69 of 2 in FIG. 6 (1 in FIG. 7 and 2 in FIG. 7)
46 to 53) is a subroutine (subroutine "resetit") for resetting the LSI. Lines 71 to 75 of 2 in FIG. 6 (55 to 55 of 2 in FIG.
(Line 60) combines these subroutines,
Making the whole test vector. In this way, by making the test vector a subroutine, the efficiency of creating the test vector is significantly improved.

In the above simulation, debugging is performed using a simulator or a tool having a waveform display function. In debugging, the cause is often found by using the vector count (which is equivalent to the time) at which an assertion error (mismatch with the expected value) occurs.

However, in the conventional debugging on the simulator, only the information on the signal name and the vector count (or time) at which the error occurred is displayed. For example, "signal name dat [7], vector count 36763200
Information such as "An assertion error has occurred" has only been displayed on tools such as the waveform display function. That is, according to this method, the location of the error, that is, the information "what kind of operation the error occurred when testing" is not directly displayed.

Therefore, the location of the error cannot be obtained without back-calculating from the vector count information (or time information). Also, for example, "vector count 367
It cannot be easily known from the information that "63200 has an error" that "the address of the read / write test caused the error" regarding the memory element. Furthermore, it is not possible to grasp "which subroutine was executing the error".

Under such circumstances, conventionally, the state of the error occurrence time has been grasped by re-executing the simulation while collecting the related data in detail until the time when the error occurs. Alternatively, the time of the test item is calculated to check which test item the error corresponds to. Therefore, it takes a huge amount of time to investigate the cause of the error, and the work efficiency is extremely poor.

On the other hand, when the temporary design is completed by repeating the simulation and the debug using the test vector as described above, the LSI is prototyped and tested by the LSI tester. Referring back to FIG. 5, first, a photomask is created (see reference numeral 109),
The LSI is actually manufactured (trial manufacture) (see reference numeral 100). The manufactured LSI 100 is tested by the LSI tester (see reference numeral 111), and finally the timing and function are debugged. Also in this case, as in the case of the above-described simulation, the LSI tester 111 performs a functional test such as an actual operation speed test using a large number of test vectors 112 on the prototype LSI 100. The test vector can also be generated by using a tool for generating a simulation vector (test vector generation language 105 or graphical test vector generation tool 106) (see reference numeral 113).

Even when performing debugging on the LSI tester,
Use a tool that has a vector address display function to rely on the signal name where the error occurred,
(Also referred to as)) and calculate back from the signal name and vector count to identify what kind of operation the error occurred.

In this case, at present, only the information on the signal name and time at which the error has occurred is displayed. Therefore, as in the case of the above-described simulation, the error location is identified and the error is detected when the operation is performed. It is not easy to know what happened.

In particular, when debugging a prototype LSI, it is necessary to return to the simulation work each time an error occurs.
The work efficiency is extremely poor and unrealistic. For this reason, a specialized test engineer operates the LSI tester to perform a series of tests, and collectively notifies the design engineer of error information at the end of the test. However, in this case, if the error information is described by the vector count value, the design engineer cannot immediately understand the test item in which the error has occurred, and there is a problem in information transmission.

[0015]

SUMMARY OF THE INVENTION It is an object of the present invention to provide a debug information display method and a display structure capable of promptly displaying information on a location causing an error that occurs in a simulation at a design stage using a test vector. Is to provide. Another object of the present invention is to provide the above-mentioned display method and display structure capable of promptly displaying information on a location causing an error that has occurred on an LSI tester of a prototype LSI.

[0016]

SUMMARY OF THE INVENTION The present invention is a method and display structure for displaying debug information for debugging by a test vector on a display in direct correspondence with a description in a high-level language (that is, a line or block of source code).

That is, the debug information display method of the present invention is
(1) Each time a specific type of operation occurs during test execution,
A step of recording attribute information of the specific type operation including the generation time of the specific type operation and a source file name in a storage device as history information in association with a test time; Based on the time of occurrence of the error and the history information, and limiting the location in the source file in which the code that caused the error is described, and displaying the information about the limited location on the display. Characterize.

The debug information display structure of the present invention is
In addition to at least one of a time (or vector count) display section, a waveform display section, and a fail map display section, an error occurrence time and a value stored in a storage device each time a specific type operation such as the subroutine call is performed. A history information display unit is provided for displaying the occurrence time of the specific type operation and the attribute information of the specific type operation including the source file name in association with the test time. The waveform display unit may include at least one of an address display unit and a data display unit.

The present invention is applied to a debug information display method and display structure in a simulation at the LSI design stage, or to a debug information display method and display structure in a test of a prototype LSI by an LSI tester.

In the present invention, in order to easily understand the cause of the error, it is usually preferable to display the waveform information and the fail map together with the information about the limited portion of the source code.

According to the present invention, history information is added to a plurality (usually a large number) of test vectors expanded on the time axis, and the test vector description language processing system processes the history information in processing the description language. Record with signal waveform information. Then, when an error occurs, the history information is displayed on the display automatically or by a user operation. By doing this, it becomes easy to identify the error location. The display of the corresponding part of the source code (or the list of debug information) is performed by software for waveform display, vector editor of LSI tester, software such as fail map, or the like.
In this case, the source code or the like can be displayed by tracing the subroutine in which the error has occurred.

The test vector description language may be in the form of an interpreter or a compiler, a hardware description language such as Verilog-HDL or VHSIC-HDL, a script language attached to CAE software (for example, US Mentor Grap
Hics's Apple) or C, Pascal, B
Any general-purpose computer language such as asic may be used.

The test vector description language may be processed (interpreted) by the test vector description language processing system at the same time as the simulation or the test progress in the LSI tester, or by the processing system in advance. It may be processed (compiled).

[0024]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described below in detail. First, a method of recording debug information when the specific type operation is a subroutine call of a test vector program in the LSI simulator will be described.
In this case, each time a subroutine call is generated, the time when the subroutine call is generated and the attribute information of the specific type operation (that is, the source file name, line number, and argument that are making the subroutine call) are related to the simulation time. The history information is recorded in a storage device (memory, hard disk, etc.). These pieces of history information are usually stored in the area where the simulation result information or the input signal information is stored in association with these pieces of information.

Below, 1 Veri of FIG. 6 and 2 Veri of FIG.
A case will be described where log-HDL is executed and debug information is recorded. Note that, as described above, the line numbers given on the left are given for the purpose of explanation and are not directly related to the present invention. In the Verilog-HDL language processing system, first, after compiling and initializing, first, 2 in FIG.
71 to 75 lines of the initial sentence,

... 71 // main test sequence 72 initial begin 73 resetit; 74 readwrite; 75 end ... Note that // on line 71 indicates a comment line, so this line is not executed.

It should be noted that only one initial sentence will be described here. In the case of Verilog-HDL, a plurality of initial statements may be executed in parallel, but in this case, each initial statement may be recorded separately.

The simulation time is 0 at the start of execution of the initial sentence. Therefore, it is recorded as follows that the simulation started from the initial sentence on line 72 in FIG.

1 filename = test.v line = 72 time = 0 call initial (none)

An argument is described in (), but since there is no argument here, the fact (none) is described. Next, in line 73 of the initial sentence, the subroutine "r
"setit" is called. This subroutine call is recorded as follows:

2 filename = test.v line = 73 time = 0 call resetit (none) The end of the subroutine “resetit” is recorded as follows.

3 time = 1000 return from resetit Next, in line 74 of FIG.
"adwrite" is called. This subroutine call is recorded as follows:

4 filename = test.v line = 74 time = 1000 call readwrite (none) The subroutine “readwrite” is described as follows in 2 of FIG.

・ ・ ・ 54 // simple memory test procedure 55 task readwrite; 56 begin 57 integer i; 58 for (i = 0; i <16'h10000; i = i + 1) write (i, i); 59 for (i = 0; i <16'h10000; i = i + 1) read (i, i); 60 end ... The subroutine "write" is called at line 58 of the subroutine "readwrite". This subroutine call is recorded as follows:

5 filename = test.v line = 58 time = 1000 call write (0,0) Here, since write has an argument, the argument 0,0 indicating the first writing is Recorded in parentheses. In addition, 16'h1000 in lines 58 and 59
0 is the hexadecimal value 10000 stored in 16 bits
Is shown. Various methods used in conventional debuggers can be used to express the function arguments, which is obvious to those skilled in the art. When the subroutine "write" is completed, the completion of this subroutine is recorded as follows.

6 time = 1500 return from write Writing is performed 65536 times, and the subroutine “wri” is written.
Each time "te" is called and when it is finished, it is recorded as follows.

・ ・ ・ 131075 filename = test.v line = 58 time = 32768500 call write (65535,65535) 131076 time = 32769000 return from write Furthermore, the subroutine “read” is called at line 59 of the subroutine “readwrite”. Also when
As in the case of "write", the following is recorded.

131077 filename = test.v line = 59 time = 32769000 call read (0,0) When the subroutine "read" is completed, the following is recorded.

131078 time = 32769500 return from read Here again, the read is performed 65536 times, and is recorded as follows each time the subroutine “read” is called and each time the subroutine “read” is ended.

262147 filename = test.v line = 59 time = 65536000 call read (65535,65535) 262148 time = 65536500 return from read Finally, the subroutine "readwrite" and the end of the initial statement are as follows. Will be recorded.

262149 time = 65537000 return from readwrite 262150 time = 65537000 end of initial

If an error occurs when running the test,
It is possible to temporarily stop the execution of the simulation and refer to the information recorded in the storage device, or it is possible to refer to the above information without stopping the execution of the simulation. In any case, based on the error occurrence time and the error attribute information stored in the storage device, the location where the code that caused the error is described, in this case, the number of times of reading of which subroutine Alternatively, it is possible to know whether an error has occurred in writing.

Next, a method for collectively recording, for each wait statement, the source file name with the wait statement, the number of lines, and the subroutine information from the initial statement when the wait statement is executed will be described.

Below, Veril of 1 of FIG. 6 and 2 of FIG.
An example in which og-HDL is executed and debug information is recorded is shown. The language processing system of Verilog-HDL is first shown in FIG.
Execution starts from the initial statement on line 72 of No. 2 In addition,
In this case as well, description will be made focusing on only one initial sentence, but if there is another initial sentence, it is the same as in the above case that independent recording is performed by a similar method.

The subroutine "resetit" is called in the initial statement starting from line 72 of FIG. 6 (line 73). The subroutine "resetit" is described as follows.

・ ・ ・ 62 // reset task 63 task resetit; 64 begin 65 rst = 1'b1; 66 # 500 67 rst = 1'b0; 68 # 500; 69 end ・ ・ ・

Here, first, as shown below, 66
Record that the time when the wait statement for the line was called is zero. In addition, the wait statement is the subroutine "res".
"etit" and the source code containing it is called test. Record that it is line 66 of v. Further, it is recorded that the subroutine "resetit" is called from the 73rd line of the initial sentence.

1 wait 500 time = 0 2 subroutine resetit (none) filename = test.v line = 66 3 initial filename = test.v line = 73 ・ ・ ・

Similarly, for the subsequent wait statements, the time when the wait statement was executed, the information about the subroutine executing the wait statement, and the information about the subroutine call leading to the subroutine are traced to the initial statement. Record until you arrive.

4 wait 500 time = 500 5 subroutine resetit (none) filename = test.v line = 68 6 initial filename = test.v line = 73 7 wait 100 time = 1000 8 subroutine write (0,0) filename = test .v line = 23 9 subroutine readwrite filename = test.v line = 58 10 initial filename = test.v line = 74 11 wait 200 time = 1100 12 subroutine write (0,0) filename = test.v line = 25 13 subroutine readwrite filename = test.v line = 58 14 initial filename = test.v line = 74 15 wait 100 time = 1300 16 subroutine write (0,0) filename = test.v line = 27 17 subroutine readwrite filename = test.v line = 58 18 initial filename = test.v line = 74 ・ ・ ・

In this case, based on the error occurrence time and the attribute information of the error stored in the stack, the location where the code that caused the error is described (in this case, how many times of which subroutine is read or Can see if an error occurred in writing).

Further, each time an assertion (instruction for checking whether or not the simulation result matches the expected value), the source file name and the number of lines with the assert instruction, and the initial statement including the assert instruction are used to make a subroutine. The method of recording the subroutine call up to is described. To use this method, it is necessary to introduce an assert statement into the test vector description language. 8 and 1 of FIG. 8 are rewritten by using the assert statement in lines 45 to 70 of the Verilog-HDL of 1 and 2 of FIG.
Shown in The assert statement starting from line 46 of 1 in FIG. 8 is described as follows.

・ ・ ・ 45 // Assertion on data_out 46 $ assert (data_out, dat); 47 48 # 100 49 ncs = 1'b1; 50 # 200; 51 end 52 endtask ・ ・ ・ The above assert statement is executed Then, the execution result is recorded as follows.

1 time = 32769200 assert data_out = 0 2 subroutine read (0,0) filename = test1.v line = 46 3 subroutine readwrite filename = test1.v line = 59 4 initial filename = test1.v line = 74 5 time = 32769700 assert data_out = 1 6 subroutine read (1,1) filename = test1.v line = 46 7 subroutine readwrite filename = test1.v line = 59 8 initial filename = test1.v line = 74 ・ ・ ・

That is, the time at which the assert statement is executed, the signal name of interest, and the expected value are sequentially recorded, and information about the stack contents at the time of executing the assert statement (from the initial statement to the current time) Information of the subroutine call of).

The information recorded as described above is later used to retrieve what kind of operation was to be tested at the simulation time by collating it with the time of the error information. In this method, the information for associating with the source code is not recorded for the portion where the assert statement is not used. When the information at the time of executing the assertion is not needed, the area of the storage device can be saved, which is significant.

Here, the case where the test vector is described in Verilog-HDL has been described as an example, but some caution is required due to the characteristics of the language. Veri
In a hardware description language such as log-HDL, many source code processes are performed in parallel. It is not desirable to record all the execution information that is progressing in parallel because it leaves huge and unnecessary information. Therefore, we need a way to choose which run to record information about.

The initial statement describes the start of a series of processes in which execution is started spontaneously and simultaneously from the start time 0. As described above, the execution information started by this initial statement is Although recorded in the storage device, execution of a specific initial sentence can be prevented from being recorded by some option specification or language description.

The always statement (which corresponds to a process statement in VHSIC-HDI) is started to be executed when a specific type operation occurs. In the present invention, execution information started by the Always sentence is not recorded. However, the execution of a particular always-sentence may be designated to be recorded by some option designation or language description.

When a general-purpose programming language such as C language is used (see 1 in FIG. 7 and 2 in FIG. 7), Veri
There is no mechanism like the initial sentence of log-HDL,
The same thing can be described by providing a reset subroutine as follows.

1 main () {2 timereset (); 3 / * test sequnece 1 * / 4 5 timereset (); 6 / * test sequnece 2 * / 7 8} Time reset subroutine "timereset"
Resets the time variable to zero. In this case, "tim
Each time "erset" is called, recording of new independent debug information is started.

A specific method and display structure for displaying the above debug information will be described below. Since the display contents are almost the same whether the simulation result is displayed or the test result by the LSI tester is displayed, the case of displaying the simulation result will be described here.

FIG. 1 is a flow chart showing a basic display method in the case where detailed debug information is displayed by a user's operation, together with debug information about waveforms and source code. In the figure, the waveform is displayed in the waveform display window (see S901), and the source code information corresponding to the waveform is displayed (see S902). Here, when the user wants to display the detailed information on the display and performs a predetermined operation (see S903), a window for displaying the error portion of the source code opens (S904).
reference). When the user wants to display the source code according to the history, the display of the source code is switched by a predetermined operation (S905). Hereinafter, specific examples according to the above display method and further improvement of the method will be described.

FIG. 2 shows a window 1 for displaying the simulation result and a window 2 for displaying the source code. The window 1 is provided with a simulation time display section 11 (in the case of an LSI test result, a vector count) and display sections 12 to 16 for each signal. FIG. 2 shows a case where a read error occurs in the data h0001 (hexadecimal 0001) for the address h0001 (hexadecimal 0001) (note that in FIG. 2, the values of the address and the data are coincident with each other. Warnings (arrows and correct data) are displayed at the relevant portions of the data display section 13 (indicated by the error information display section 17).

In the present invention, in addition to these, the display section 18 is caused to display information regarding the source code of the test vector description language. History information (debug information) is displayed on the display unit 18. The storage device contains information associating the time of a specific type operation (subroutine call, wait, assert) with the hierarchical structure of the specific type operation in the test vector description language.
Display with 16.

In this embodiment, the window 2 is set so that the user can open it as needed. For example, the window 2 is opened by clicking the error information display unit 17 or the source code display unit 18 with the mouse, and the window 2 is closed by clicking the close point 19.
When the user clicks the display section 17 or 18, the window 2 displays the location where the error occurred or the subroutine corresponding to the source code information. As shown in line 46 of window 2, debug location ($
assert (data_out, data);) is highlighted. In FIG. 2, this emphasized portion is indicated by reference numeral 20. 2, the file name (test.v) and other information regarding the error (read (0001, 0001) are displayed in the title bar of window 2. Note that the first 0001 in () is read. The hexadecimal address related to the error is shown, and the next 0001 in () is the hexadecimal data related to the read error.Only the file name is displayed in the title bar of FIG. Data (0001)
Is at another place (for example, 35 lines, 3 in window 2 in FIG. 2).
It can also be displayed at the right end of line 6. Note that these addresses and data are already displayed in window 1. Therefore, it is possible not to display this in the window 2.

In the window 1, the source file name, the lowest layer subroutine name, and the value of the argument given to the subroutine are displayed. This display can be switched to the number of lines of the source code, the subroutine name of the upper hierarchy, the value of the argument, and the file name by the user's operation, as shown in window 1 of FIG. For example, "r
When the subroutine "ead" is called a plurality of times with the same argument, the test location cannot be limited only by the information of the read subroutine which is the lowest layer. In such a case, it becomes easy for the user to limit the test locations by freely following the upper subroutine information. To switch the display of window 1, assign a command to a specific key,
Various methods such as displaying a menu bar are adopted. In FIG. 3, by double-clicking the display portion 18 of the window 1, the display of the window 2 is switched to the display of information such as a test program related to a higher order subroutine.

The display unit 18 shown in FIGS. 2 and 3 has a plurality of windows (for example, in the case of FIG.
Can be provided in rows). This is, for example, Ve
This is effective when a plurality of test vector description sequences are executed in parallel, such as a case where a plurality of initial statements exist in the description of rilog-HDL. In this case, the window 2 shown in FIG. 2 and FIG.
It is preferable to allow a plurality of openings depending on the number of eight. Further, in this case, it is preferable that the user is provided with a selection function capable of selecting and displaying all or a part of the test vector description sequence (that is, the initial sentence).

As shown in FIG. 4, the signal waveform is not displayed,
The display method or display structure of the present invention can also be applied to fail map software that displays error information only as a whole.

The fail map software is standardly installed in the LSI tester. In the fail map window 1'of FIG. 4, signal names and errors generated in each signal are collectively displayed. The number displayed at the left end is the vector count (that is, the test time divided by the test cycle length). This vector count corresponds to the simulation time in the simulator. The X mark displayed in the vector count 65539 of the data signal indicates that a mismatch (fail, that is, an error) has occurred as a result of comparing the expected value and the response of the DUT with the vector count of the signal. ing.

In the present invention, when an arbitrary error is selected on such fail map software, the source code of the test vector description language corresponding to the error is
The window 2 shown in FIG. 4 is opened so that it can be displayed. Although not shown in FIG.
As shown in, the source code may be displayed after passing through the waveform table screen once, or the source may be displayed by tracing back the hierarchy of the subroutine call.

When only the debug information is given, that is, when the debug information is recorded only at the place where the assertion is made, the association with the source code is the place where the error occurs or the assertion is made. Can only be done in place. The example of displaying the information obtained from the test vector description language processing system has been described above. However, other information may be added to the information and displayed.
Also, some information may be omitted and displayed.

[0073]

As described above in detail, the present invention can exert the following effects. (1) By recording the test execution information and the specific-type operation attribute information as history information, it is possible to improve the efficiency of debugging work during a test by a simulation or an LSI tester. Conventionally, simulation or L
Fails and errors found on SI tester
It usually took a few hours to a day to understand what kind of movement the
According to the present invention, since the debug information can be displayed appropriately, it is possible to perform the above grasp within a few minutes. (2) Further, when the information is transmitted from the test engineer to the design engineer and the simulator engineer, the history information according to the high-level language is added in addition to the waveform information, so that the information transmission can be made efficient. it can.

[Brief description of drawings]

FIG. 1 is a flow chart showing a basic display method in the case of displaying more detailed debug information by a user operation together with debug information about waveforms and source code.

FIG. 2 is a diagram showing a window 1 displaying a simulation result and a window 2 displaying a source code.

FIG. 3 is a diagram showing a state in which windows 1 and 2 shown in FIG. 2 are switched by a user operation.

FIG. 4 is an explanatory diagram in a case where the display method or display structure of the present invention is applied to fail map software which displays only error information as a whole.

FIG. 5 is a diagram systematically showing the flow of tests before and after trial manufacture of an LSI.

FIG. 6 is a diagram showing an example (first half portion) of a source code of a test program by Verilog-HDL.

FIG. 6 is a diagram showing an example (second half) of the source code of the test program in Verilog-HDL.

1. FIG. 7 is a diagram showing a source code (first half) in C language equivalent to the source code of FIG.

7 is a diagram showing a source code (second half) in C language equivalent to the source code of FIG. 6.

[FIG. 8-1] Verilog-HD using an assert statement
It is a figure which shows the source code (first half part) of L.

[FIG. 8B] Verilog-HD using an assert statement
It is a figure which shows the source code (latter half part) of L.

[Explanation of symbols]

 1, 1 ', 2 Window 11 Simulation time display section 12 Address display section 13 Data display section 14-16 Signal waveform 17 Error information 18 Data display section 19 Close point 20 Highlighted section

Claims (5)

[Claims] 1. A method of performing debugging with a test vector written in a high-level language and displaying the debug information on a display, (1) When a specific type operation occurs during execution of a test, the specific type operation is performed. And a step of recording the attribute information of the specific type operation including the source file name in the storage device as history information in association with the test time, and (2) the time when the error occurred during the execution of the test. Debugging the code that caused the error on the basis of the history information, and displaying information about the specified location on a display. Information display method. 2. The debug information display method according to claim 1, wherein the specific type operation is at least one of a subroutine call, a wait, and an assertion. 3. In a debug information display structure on a display for debugging with a test vector written in a high-level language, in addition to at least one of a time display section, a waveform display section and a fail map display section, an error occurrence time and , The attribute information of the specific type operation including the generation time of the specific type operation and the source file name, which is stored in the storage device each time the specific type operation such as the subroutine call is performed, in association with the test time. And a debug information display structure having a history information display section. 4. The debug information display structure according to claim 3, wherein the specific type operation is at least one of a subroutine call, a wait, and an assertion. 5. The debug information display structure according to claim 3, wherein the waveform display unit includes at least one of an address display unit and a data display unit.