JPH11110429A - Event generating device, and hardware simulation device and method therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a hardware simulation device for carrying out logical inspection with high reliability. SOLUTION: At the time of compile, a listing file 304 is generated by using an event generation keyword described in a text program 301 for instructing for generating an event in a format which does not have any influence on an object program 305. A user task generated based on a listing file 304 is registered in an event synchronization generating module 310. Also, the operation of a simulation model module 400 is monitored by a function program for monitoring, and an instruction which is being executed is specified. Then, when an instruction, by which an event described in the text program 301 should be synchronized, is executed, the user task corresponding to the event is read through an interface to the module 400, and the event is scheduled.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an event generation device, a hardware simulation device, and a method thereof.

[0002]

2. Description of the Related Art In the course of designing an LSI (Large Scale Integration) such as a microprocessor or a microcontroller, an operation model described by software may be subjected to logic simulation on a computer to perform logic verification. Such a logic verification work is, for example, as shown in FIG. 9, a design target L created using a hardware description language such as Verilog-HLD.
This is performed using the SI operation model 28. Operation model 2
8, an event module 25 for generating an event such as an interrupt or a bus request is provided by a Veril
written in a hardware description language such as og-HLD,
The signal of the target model 31 is actually driven. The operation model 28 further includes a clock supply circuit module 29, a reset generation circuit module 3
0, modules necessary for operating the target model 31 such as the memory controller module 33 and the memory model module 32 are provided.

[0003] In an LSI such as a microprocessor or a microcontroller, a target model 3 is usually used.
1 requires a software program in addition to the modules described above. Such a software program converts a text program 21 written by a user into an operation model 2 using a compiler 22.
8 is converted into an object file 23 in a format that can be read. This conversion is not limited to once, but may be performed a plurality of times.

In the operation model 28, when simulating the occurrence of an event, as shown in FIG. 10, for example, an instruction "sw r2,
A write instruction for a specific external memory address such as "r5" is explicitly described, and when the write instruction is executed, a trigger for executing the corresponding event is generated. The event module 25 executes the instruction “sw r2,
After scheduling the event based on the time at which the write operation to the I / O mapped external memory is performed according to “r5”, the event is generated according to the schedule.

In this example, the event is scheduled to occur six cycles after the write operation to the I / O mapped external memory is performed. Therefore, the event actually occurs when the instruction “sw r
Instruction "addir6,0x0" after 6 instructions from "2, r5"
"001" is assumed.

[0006]

In this case, however, the operation of the target model 31 is stopped for some reason in a state where it is determined that an event occurs six cycles after execution of the instruction "sw r2, r5". (Stall), the instruction “addr r6, 0x000
No event occurs at the timing when "1" is executed. That is, the instruction “addi r6, 0x0001”
The event is not necessarily generated at the timing when is executed, and so-called out-of-synchronization may occur.

[0007] The above-described logic verification is a task of executing the text program 21 on the operation model 27 to verify the function of the LSI. Therefore, in order to achieve the original purpose, the text program 21 should not include an instruction other than the original purpose, such as the above-mentioned instruction “sw r2, r5”. For this reason, it is important to execute the simulation as much as possible without including a description other than the operation originally performed by the target model 31 in the text program 21 in order to enhance the reliability of the logic verification.

The present invention has been made in view of the above-mentioned problems of the prior art, and has an event scheduled in synchronization with the timing at which an instruction in a text program is executed, and which can perform highly reliable logic verification. It is an object to provide a generator, a hardware simulation device, and a method thereof.

[0009]

SUMMARY OF THE INVENTION In order to solve the above-mentioned problems of the prior art and to achieve the above-mentioned object, an event generating apparatus of the present invention describes an instruction for logic verification for controlling hardware. Based on an object program generated by compiling a test program, an event is generated in the simulation model when performing a logic verification by operating a hardware simulation model described using a hardware description language. An event generating device, comprising: a compiler that generates an event information file at the time of compilation by using an event generating keyword that is described in the test program and instructs the generation of an event in a format that does not affect the object program. , Based on the event information file, A user task generating means for generating a user task according to an event described using a continuation type high-level programming language, and registering the user task; and an interface between the user task generating means and the simulation model; The operation described in the test program should be synchronized based on the operation monitoring unit that monitors the operation of the simulation model according to the object program and specifies the instruction being executed, and the monitoring result of the operation monitoring unit. And a scheduler for reading a user task corresponding to the event from the user task generation unit to the simulation model via the interface when the instruction is executed, and scheduling the event.

In the event generation device according to the present invention, the simulation model operates based on the object program. At this time, the instruction being executed in the simulation model is monitored by the operation monitoring means. Then, when an instruction to be synchronized with an event corresponding to the user task registered in the user task generating means is executed, the event is scheduled. The scheduled event monitors whether or not a condition held by itself is satisfied, occurs when the condition is satisfied, and performs a predetermined event operation.

Further, the hardware simulation apparatus of the present invention operates the hardware simulation model based on an object program generated by compiling a test program describing a logic verification instruction for controlling the hardware. A hardware simulation device for generating an event information file at compile time by using an event generation keyword described in the test program and indicating generation of an event in a format that does not affect the object program. A compiler, a simulation model which is described using a hardware description language and performs a simulation operation of the target hardware based on the object program, and a procedure based on the event information file. It generates user tasks in accordance with the described event with the type of high-level programming language,
A user task generating means for registering the user task,
An interface between the user task generation unit and the simulation model; an operation monitoring unit that monitors an operation of the simulation model according to the object program, and specifies an instruction being executed; and a monitoring result of the operation monitoring unit. When an instruction to be synchronized with an event described in the test program is executed, a user task corresponding to the event is read out from the user task generating means to the simulation model via the interface, and Scheduling means for scheduling an event.

Further, the hardware simulation method of the present invention operates the hardware simulation model based on an object program generated by compiling a test program describing a logic verification instruction for controlling the hardware. A hardware simulation method for compiling an event information file by using an event generation keyword described in the test program and indicating generation of an event in a format that does not affect the object program. Performing a simulation operation of the target hardware based on the object program using a simulation model described using a hardware description language, and performing a procedural high-level operation based on the event information file. Generate a user task according to an event described using a programming language, monitor the operation of the simulation model according to the object program, specify an instruction being executed, and, based on a result of the monitoring, When an instruction to be synchronized with an event described in the test program is executed, a user task corresponding to the event is read out to the simulation model via an interface to schedule the event.

[0013]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an LSI simulation apparatus according to an embodiment of the present invention will be described. FIG.
Is an LSI simulation device 3 according to the present embodiment.
00 is a system configuration diagram of FIG. As shown in FIG.
The I simulation apparatus 300 includes an event list extraction module 306, a system call / memory load module 307, an event synchronization generation module 310, and a simulation model module 400.

The event list extraction module 306
Based on the function names defined in the event program library 303 and the transfer order of the arguments of the functions, the events described as user events by the event schedule declaration in the listing file 304 are stored in the user tasks 308 _{1 to} 308 _n . expand. The user tasks 308 _{1 to} 308 _n are registered in the event synchronization generation module 310. Here, one user task is generated from one event,
A plurality of user tasks may be generated from one event.

The listing file 304 is created at the same time that the compiler 302 creates the object file 305 by compiling the test program 301 describing user events in addition to the instructions executed by the processor. The listing file 304 describes an address where an instruction to be executed by the processor after compilation is arranged, a compilation result of the instruction, and an instruction immediately after or immediately before the user event is specified.

The event synchronization generation module 310 includes user tasks 308 _{1 to} 308 _n and a system call module 309, and is described using, for example, the C language. The event synchronization generation module 310 has a function of expanding a list of events to the user tasks 308 _{1 to} 308 _n . Also, the user task 30
As 8 ₁ ~308 _n one function program monitors the progress of the simulation of the simulation model module 400, the monitoring function program having always pointing function currently executing instruction in the test program 301 is provided. The monitoring function program calls the user tasks 308 _{1 to} 308 _n to the simulation model module 400 in accordance with the progress of the simulation to schedule an event corresponding to the user task. For a scheduled event, whether or not the event is to be generated is determined by itself based on the description content in the event, for example, according to a monitored value. The test program 301
The user event therein is preferably described using C language. This is because, by using the C language, clock count, signal monitoring, signal value setting, and the like can be described in various formats.

The system call module 309 calls the registered user tasks 308 _{1 to} 308 _n to the simulation model module 400. Here, the interface between the system call module 309 and the event trigger module 403 is, for example, Veril
This is realized using a function provided by the og-PLI 507. That is, the simulation model module 40
When an event is called from 0, the user tasks 308 _{1 to} 308 _n corresponding to the event are called via the event trigger module 403 and the system call module 309 using the function of the PLI 507.

The system call / memory load module 307 loads the object file 305 generated by compiling the test program 301 using the compiler 302 into the memory model 405 of the simulation model module 400, for example.

Simulation model module 400
Are a clock supply circuit module 401, a reset generation circuit module 402, an event trigger module 40
3, a memory controller module 404, a memory model module 405, and a target model module 406, which are described using, for example, Verilog-HDL. Clock supply circuit module 401
Generates clock data to be supplied to the target model module 406. The reset generation circuit module 402 drives a simulation of a reset operation of the target model 406 as necessary. The event trigger module 403 includes the user tasks 308 _{1 to} 308 registered in the event synchronization generation module 310.
has a function to call _n when the simulation is started.

The memory controller module 404 includes:
Data transfer is controlled between the memory model module 405 and the target model module 406. The memory model module 405 stores instructions executed in the target model module 406. The target model module 406 is a program for simulating the core of the LSI to be simulated. Target model module 406
Is, for example, as shown in FIG.
Stage 451, DEC (instruction decode) stage 45
2. A five-stage pipeline RISC (Red) comprising an ALU (instruction execution) stage 453, a MEM (memory access) stage 454, and a WB (write) stage 455.
uced Instruciton Set Computer) is a program that simulates a processor.

In the LSI simulation apparatus 300,
The listing file 304 includes information indicating the correspondence between the event occurrence timing and the processor instruction execution timing, and the user tasks 308 _{1 to} 308 _n generated based on this information are scheduled and activated according to the progress of the simulation. By doing so, simulation is performed by synchronizing instruction execution and event occurrence in the processor.

Event schedule declaration The event schedule declaration corresponds to the test program 301.
Described inside. In the present embodiment, unlike the conventional test program shown in FIG. 9, the event schedule declaration is not explicitly specified by an instruction. Specifically, as shown in FIG. 2, “＠” is described following “;”, and the user task function name of the event is described subsequently. After "@", the event program library 303 defines in advance a format such as the order in which function arguments are passed.

In this embodiment, ";" is used as a keyword indicating a comment line defined by the compiler 302. The characters described after this keyword have no meaning except for the event schedule declaration. Therefore, the characters described after ";" can be used for purposes other than the logical simulation. Event schedule declaration ";@event_gen" shown in FIG.
Has the following meaning: That is, [1] This event is executed by the immediately following instruction (in FIG. 2, n
op instruction is executed in the ALU stage of the processor. [2] 5 cycles after the scheduled time
Activate (ON) the NT signal (external input terminal of the processor).

In this embodiment, as shown in FIG. 2, after five instructions from the position where the event schedule declaration “; @event_gen” is described, the instruction “adddir” is issued.
6,0x0001 "is described. Thus, if the processor was not stalled, internally or externally, the ADDI instruction would be executed five cycles after the event was scheduled. However, the declaration of this event does not take into account pipeline disruptions due to such stalls.
It merely declares that an event will occur in the fifth cycle.

Event Scheduling and Occurrence The event corresponding to the schedule declaration in the text program 301 shown in FIG. 2 must be executed in synchronization with the instruction of the processor. In this embodiment, the timing (time) at which the event schedule is synchronized with the instruction is such that the instruction is processed in the ALU stage 453 in the pipeline of the processor 457 being simulated by the target model module 406, as shown in FIG. Determined on a cycle basis. In the present embodiment, any stage in the pipeline of the processor may be used as a reference as long as the event schedule can be synchronized with the instruction. That is, a synchronization mechanism using a unit other than the ALU stage 453 is also considered as an application example.

One schedule declaration is shown in FIG.
Is expanded into one user task (one of the user tasks 308 _{1 to} 308 _n ). The ALU stage 453 of the processor is constantly monitored by the monitoring function program in order to schedule the event corresponding to the schedule declaration in accordance with the instruction to be synchronized.
That is, the monitoring function program recognizes which instruction is being executed in the ALU stage 453 at a certain time. Such a function is necessary when the ALU stage 453 is used as a trigger for synchronization.

When an instruction of a processor to be synchronized with an event is executed in the ALU stage 453, the event is scheduled. User tasks 308 _1-
308 _n is Ve which is an interface between the system call module 309 and the memory model module 405.
The function is called from the event trigger module 403 by the function of rilog-PLI and activated. For monitoring the ALU stage 453, various methods can be adopted depending on the structure of the processor pipeline.

As described above, the pipeline of the RISC processor simulated by the target model module 406 is the five-stage pipeline shown in FIG. In the first IF stage 451 of the five-stage pipeline, an IMP (Instruction Memory Pointer) 4
The instruction is read from the address on the instruction memory module 460 indicated by 56. The data path in the pipeline 462 is controlled by the pipeline control circuit module 461 shown in FIG. Here, a processor internal block 457 is configured by the IMP 456, the pipeline control circuit module 461, and the pipeline 462, and the processor internal block 457 is described in the target model module 406 shown in FIG.

The ALU stage 453 is the IF stage 4
Since this is the third cycle counting from 51, the monitoring function program monitors the address of the instruction to be fetched next from the address indicated by the IMP 456, and checks whether or not a stall factor has occurred. It is determined whether the executed instruction is executed in ALU stage 453. Then, if the monitoring function program determines that the instruction to be synchronized with the event is executed in the ALU stage 453, the instruction to be synchronized is A
The event is scheduled at the timing executed in the LU stage 453. Once the scheduled event has been started as a user task, the task is executed according to a predetermined procedure. For example, the event shown in FIG. 2 counts five cycles after being activated. Then, at the fifth cycle, the external terminal INT of the processor is turned on. This ON operation corresponds to the execution (occurrence) of an event. After execution, the task ends unless otherwise specified.

The time (cycle) from the activation of the user tasks 308 _{1 to} 308 _n to the occurrence of an event,
The target of the event (the terminal to drive the signal) and its value are described in the user task.
Note that when the user tasks 308 _{1 to} 308 _n actually execute processing, if another program is required, the necessary program is called from the event program library 303. This is because, when a plurality of events include the same type of operation, the operation is registered in the event program library 303 to reduce the amount of description of the user event. Therefore, for example, when only the signal name (terminal name) to be driven, its value, and the wait (wait) cycle are different, a program relating to these may be registered in the event program library 303.

[0031] Starting 4 user tasks are views for explaining a method of starting a user task in the course of the simulation. First, as shown in FIG. 4, the simulation is started (Step S).
1), simulation model module 4 shown in FIG.
The event trigger module 403 of 00 is executed (step S2). Thus, the status of the simulation in the target model module 406 is monitored by the monitoring function program 501, which is an event trigger task. That is, when the event trigger module 403 is executed, only the monitoring function program 501 is called, and the user tasks 308 _{1 to} 308 _n of other events are not called.

Here, the event trigger module 403
Is a module described in Verilog-HDL language, while the monitoring function program 501 is described in C language. In the execution of the event trigger module 403, all the events described in the test program 301 are put together in advance before starting the simulation, and preparations are made for calling the user tasks 308 _{1 to} 308 _n .

When the target model module 406 is executed (step S3), the monitoring function program 50
1 based on the result of the simulation monitoring by the target model module 406
At the U stage 453, at the timing when an instruction to be synchronized with the event described in the test program 301 is executed, the user tasks 308 _{1 to} 308 _n corresponding to the event are transmitted to the system call module using the function of the PLI 507. Call the target model module 406 via 309 and the event trigger module 403 to schedule the event. Thereafter, when this event occurs, the user tasks 308 _{1 to} 308 _n corresponding to the event may end (disappear). Thereby, the load on the system is reduced. Then, for example, when all of the instructions described in the object file 305 shown in FIG. 1 have been executed by the target model module 406, the simulation ends (step S4).

[0034]Task type Hereinafter, the user task of the event synchronization generation module 310 will be described.
308₁To 308_nWhat features do you need to have
Will be described. FIG. 5 shows the event synchronization generation module 3
Ten user tasks 308₁To 308 _nMust have
It is a figure for explaining a function which needs. concrete
Has a signal monitoring function 552 and an event schedule
Case determination function 553, event schedule function 554
And a signal drive function 555. this
These functions utilize the functions of the PLI 507 shown in FIG.
From the event synchronization generation module 310
Called by the application model module 400. Also,
These functions are all performed by the event synchronization generation module 3
At 10, it is described using the C language.

The signal monitoring function 552 is a function for constantly monitoring the external terminals and internal signals of the simulation model module 400 shown in FIG. As a result, ALU stage 4 of the pipeline of the processor shown in FIG.
The address of the instruction executed at 53 on the instruction memory module 460 is specified. The event schedule condition judging function 553 is a function for judging a condition of whether or not to schedule an event. For example, in the pipeline processing of the target model module 406, it is determined whether a stall (stop) has occurred. The event schedule function 554 actually executes the event schedule and uses the system call module 309 shown in FIG.
8 ₁ is a function to start the ~308 _n. The event drive function 555 is provided in the simulation model module 400
External terminals and internal signals are forcibly driven (drive)
Function.

The above-mentioned monitoring function program is realized by using a signal monitoring function 552, an event schedule condition judging function 553, and a function of activating a user task among the event schedule functions 554. Here, of the event schedule function 554,
The occurrence of the event is described in the user tasks 308 _{1 to} 308 _n . It is preferable that the event drive function 555 prepares a user task for realizing the function in the event program library 303. Of course, the signals can also be driven directly from the user tasks 308 _{1 to} 308 _n using the PLI 507.

Hereinafter, the LSI simulation apparatus 300
Will be described. First, the test program 30
The operation in the event that an event schedule declaration as shown in (1) below is made in 1 will be described.

[0038]

＠ external_int (int, 5, on) (1)

The event schedule declaration shown in the above (1) has the following two meanings.・ Test program 3
01, it is scheduled when the instruction immediately after the event schedule declaration is described is executed in the ALU stage 453 of the processor.・ After 5 cycles from the scheduled time, the interrupt signal IN
T is activated (ON).

The test program 301 is compiled by the compiler 302 to generate a listing file 304 and an object file 305. At this time, the symbol ";記号" described in the test program 301 is searched by the compiler 302,
Subsequently, information such as an event schedule declaration and a command immediately after the user event generated by the declaration is described in the listing file 304.
The object file 305 is stored in the memory model module 40 of the simulation model module 400 by the system call / memory load module 307.
5 is read. Next, the event program library 30 is executed by the event list extraction module 306.
According defined format 3, the event that is described as user event by the event schedule declarations shown above (1) in the listing file 304, for example, are deployed in the user task _3081, it is registered in the event synchronization generator module 310 .

Then, the instructions in the memory model module 405 are executed by the target model module 406. In addition, using the function of the PLI 507, the simulation operation of the simulation model module 400 is performed based on the instruction executed in the ALU stage 453 by the monitoring function program read via the system call module 309 and the event trigger module 403. Is monitored. The instruction to be event generated by the user task 308 ₁ synchronization is equal to or timing to be executed by the ALU stage 453, the user task ₃₀₈₁ is started is read to the target model module 406 by the function of PLI507 . Specifically, “@evnet” shown in FIG.
_Gen (int, 5, on) ”at (1)
When the event schedule declaration described in (1) is described, the monitor signal of the ALU stage is turned on as shown in FIG. 308 ₁ is read in the target model module 406 (scheduled as).

[0042] When the user task ₃₀₈₁ is started, the cycle before generating the described events in the user task 308 _1, based on such target and a value causing an event, an event occurs. In particular,
As shown in the above (1), as shown in FIG. 6 (C), the counting is started after the monitor signal of the ALU stage is turned on, and when the count value becomes "5", that is, the schedule After 5 cycles,
As shown in (D), the interrupt signal INT is activated (ON). As a result, an interrupt occurs in the target model module 406.

As another example, a case where the event schedule declaration is described as in the following (2) will be described.

＠ external2_int (int, 5, on, 2) (2)

In this case, when the instruction immediately after the position where the event schedule declaration is described in the test program 301 is executed in the ALU stage 453 of the processor, as shown in FIG. monitoring signal is turned on, the corresponding user task 308 ₂ schedule. Then, the count is started, as shown in FIG. 7 (C), shown when the count value becomes 5, i.e., after 5 cycles from the timing that the user task 308 ₂ is scheduled, in FIG. 7 (D) Thus, the interrupt signal INT becomes active (ON), and becomes deactive (OFF) after two cycles.

[0045] Here, the operation of the interrupt signal INT to the active, to the operation and to de-activate may be performed by a single user task 308 _2, and the user task of the interrupt signal INT is activated, deactivated May be used.

As another example, a case where the event schedule declaration is described as in the following (3) will be described.

＠ bus_wait (wait, 0, on, 3, write, 0x1234, 0x1253, 10) (3)

In this case, when the instruction immediately after the position where the event schedule declaration is described in the test program 301 is executed in the ALU stage 453 of the processor, as shown in FIG. monitoring signal is turned on, the corresponding user task 308 ₃ is scheduled. Then, during 10 cycles of after the user task 308 ₃ was scheduled, will the external terminals write the state of the active (ON), and the address being accessed at that time, "0x123
When the value is in the range of “4” to “0x1253”, the external terminal “wait” is activated (ON) for three cycles and then deactivated.

For example, as shown in FIG.
After the monitoring signal of the stage becomes active, at timing t ₁ , as shown in FIG.
te becomes active, and the address at that time is shown in FIG.
As shown in (E), “0x1234” to “0x125”
3 ”, the external terminal“ wai ”in FIG.
t becomes active for only three cycles. Here, FIG.
10 cycles are counted from the event occurrence by the count value A shown in (C), and the external terminal wait becomes active by the count B shown in FIG.
The cycle is counted.

As described above, according to the LSI simulation apparatus 300, it is possible to prevent the code corresponding to the instruction for executing the simulation accompanied by the occurrence of the event from appearing in the object file, and the logic verification can be performed accurately. Can be done. That is, in the test program 301, the occurrence of an event is described in a format that does not actually affect the object code, such as a comment statement, and the event is scheduled using the description of the event only during simulation.

The LSI simulation device 300
According to the above, the event can be generated in a sure synchronization with the instruction to be synchronized with the event.

It is preferable that the test program 301 is not changed as much as possible together with the simulation model module 400. This is to provide a simulation environment that is consistently common in the LSI development process at the time of logic verification work and at the time of actual chip measurement using a tester or the like. That is, the change in the simulation environment becomes enormous as the LSI development scale increases. Therefore, it is possible to reduce the possibility that a mistake due to the change is involved, thereby shortening the development period.

The LSI simulation apparatus 300
According to this, in the event synchronization generation module 310, the event schedule and the generation program are described in a high-level language such as C language, so that a complicated specification intended by the user can be described very easily.

The LSI simulation apparatus 300
Once created, the existing program can be shared by modifying a part of the program in a plurality of development processes, and the man-hours of development resources can be reduced.

Further, the LSI simulation device 30
According to 0, it is possible to test the created event in another environment in advance. That is, a program using the C language can be executed only by a general-purpose workstation or personal computer. Therefore, a simulation environment using expensive Verilog-XL can be used efficiently.

The present invention is not limited to the above embodiment. For example, in the above-described embodiment, the C language is used as a high-level language for describing an event.
Other high-level languages such as al may be used. Although Verilog-HDL is used as a hardware description language for describing a simulation program, a hardware description language such as vHDL may be used. If you use another language,
The function of the interface between the event synchronization generation module 310 and the simulation model module 400 is also changed.

In the above-described embodiment, the case where the event is generated in synchronization with the instruction being executed by the target model module 406 is exemplified. However, the LSI simulation apparatus 300 generates the event asynchronously with the instruction being executed. It may further include a function for causing the user to perform the operation.

Further, in the present invention, all the functions of the monitoring function program may be provided to the user task, and the user task may be automatically scheduled when the simulation is started. Further, in the present invention, instead of generating a user task for each event, a plurality of user tasks for executing one event may be generated for each function. In this case, an event list is created in a table, and the schedule of the event and its execution and termination are controlled while referring to the table.

[0058]

As described above, according to the present invention,
The code of an instruction for executing a simulation that involves an event can be prevented from appearing in the object program, and the logic verification can be accurately performed. Further, according to the present invention, it is possible to generate an event by reliably synchronizing with an instruction to be synchronized with the event.

[0059]

[Brief description of the drawings]

FIG. 1 is a system configuration diagram of an LSI simulation apparatus according to an embodiment of the present invention.

FIG. 2 is a diagram for explaining an example of a test program shown in FIG. 1;

FIG. 3 is a diagram for explaining a function of a target model module shown in FIG. 1;

FIG. 4 is a diagram for explaining a method of activating a user task in a simulation process.

FIG. 5 is a diagram for explaining a function that the user task of the event synchronization generation module needs to have;

FIG. 6 is a diagram for explaining an example of an event schedule declaration and an operation of the LSI simulation apparatus shown in FIG. 1 when the declaration is used;

FIG. 7 is a diagram for explaining another example of the event schedule declaration and the operation of the LSI simulation apparatus shown in FIG. 1 when the declaration is used.

FIG. 8 is a diagram for explaining another example of the event schedule declaration and the operation of the LSI simulation apparatus shown in FIG. 1 when the declaration is used.

FIG. 9 is a system configuration diagram of a conventional LSI simulation apparatus.

FIG. 2 is a diagram for explaining an example of a test program shown in FIG. 9;

[Explanation of symbols]

300: LSI simulation apparatus, 301: Test program, 302: Compiler, 303: Event program library, 304: Listing file,
305: Object file, 306: Event list extraction module, 307: System call / memory load module, 308 _{1 to} 308 _n : User task,
309: System call module, 310: Event synchronization generation module, 400: Simulation model module, 401: Clock supply circuit module, 4
02: Reset generation circuit module, 403: Event trigger module, 404: Memory controller module, 405: Memory model module, 406: Target model module

Claims (18)

[Claims] 1. A hardware simulation model described by using a hardware description language based on an object program generated by compiling a test program describing a logic verification instruction for controlling hardware. An event generating device for generating an event in the simulation model when performing logic verification by operating the device, the event generating device being described in the test program and instructing the generation of the event in a format that does not affect the object program. A compiler that generates an event information file at the time of compilation using an event generation keyword; and, based on the event information file, generates a user task corresponding to an event described using a high-level procedural programming language. User tasks User task generating means for recording, an interface between the user task generating means and the simulation model, operation monitoring means for monitoring the operation of the simulation model according to the object program, and specifying an instruction being executed. When an instruction to synchronize an event described in the test program is executed based on a monitoring result of the operation monitoring unit, a user task corresponding to the event is transmitted to the user task generation unit via the interface. And a scheduler that reads the simulation model into the simulation model and schedules the event. 2. The method according to claim 1, wherein the compiler describes, in the event information file, an instruction immediately before or immediately after the event is specified, and the scheduling means executes the instruction immediately before or immediately after the event is specified. 2. The event generator according to claim 1, wherein the event is scheduled. 3. The event generating apparatus according to claim 1, wherein the event holds a condition for generating the event, and occurs when the condition is satisfied after being scheduled. 4. The event generation apparatus according to claim 1, wherein the event holds a time from when the event is scheduled to when the event is generated, an object that causes the event, and a value thereof. 5. The event generating apparatus according to claim 1, wherein the event generating keyword is described as a comment sentence in the test program. 6. The event generator according to claim 1, wherein when the occurrence of the event ends, the user task corresponding to the event disappears. 7. A hardware simulation device for operating a simulation model of the hardware based on an object program generated by compiling a test program describing a logic verification instruction for controlling the hardware, A compiler that generates an event information file at the time of compilation using an event generation keyword that is described in the test program and that indicates generation of an event in a format that does not affect the object program; and a hardware description language. A simulation model that simulates the target hardware based on the object program, and an simulation model that is described using a procedural high-level programming language based on the event information file. A user task generating means for generating a user task corresponding to the user task, and registering the user task; an interface between the user task generating means and the simulation model; and an operation of the simulation model according to the object program. An operation monitoring unit that monitors and specifies an instruction being executed; and, when an instruction to be synchronized with an event described in the test program is executed based on the monitoring result of the operation monitoring unit, the operation monitoring unit responds to the event. And a scheduler for reading a user task to be performed from the user task generator to the simulation model via the interface and scheduling the event. 8. The compiler describes instructions immediately before or immediately after an event is specified in the event information file, and the scheduling means executes an instruction immediately before or immediately after the event is specified. 8. The hardware simulation device according to claim 7, wherein said event is scheduled. 9. The hardware simulation apparatus according to claim 7, wherein the event holds a condition for generating the event, and occurs when the condition is satisfied after being scheduled. 10. The hardware simulation apparatus according to claim 8, wherein the event holds a time from when the event is scheduled to when the event is generated, a target that causes the event, and a value thereof. 11. The hardware simulation device according to claim 7, wherein the event occurrence keyword is described as a comment sentence in the test program. 12. The hardware simulation device according to claim 7, wherein when the occurrence of the event ends, the user task corresponding to the event disappears. 13. A hardware simulation method for operating a simulation model of the hardware based on an object program generated by compiling a test program describing a logic verification instruction for controlling the hardware, comprising: Generate an event information file by compiling using an event generation keyword that is described in the test program and instructs the generation of an event in a format that does not affect the object program, and is described using a hardware description language Using a simulation model, based on the object program, perform a simulation operation of the target hardware, and, based on the event information file, generate an event described using a high-level procedural programming language. Generating a user task, monitoring the operation of the simulation model in accordance with the object program, specifying an instruction being executed, and synchronizing an event described in the test program based on a result of the monitoring. A hardware simulation method for reading a user task corresponding to the event into the simulation model via an interface when the instruction to be executed is executed, and scheduling the event. 14. An instruction immediately before or immediately after an event is specified in the event information file by the compilation, and when the instruction immediately before or immediately after the event is executed is executed, the event is written. 14. The hardware simulation method according to claim 13, wherein scheduling is performed. 15. The hardware simulation method according to claim 13, wherein the event holds a condition for generating the event, and occurs when the condition is satisfied after being scheduled. 16. The hardware simulation method according to claim 13, wherein the event holds a time from when the event is scheduled to when the event is generated, an object that causes the event, and a value thereof. 17. The hardware simulation method according to claim 13, wherein the event occurrence keyword is described as a comment sentence in the test program. 18. The hardware simulation method according to claim 17, wherein when the occurrence of the event ends, the user task corresponding to the event disappears.