JP2001290857A - Timing simulator - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve the problem that a user is unable to know the contents of changes in the number of execution machine cycles of each instruction with combinations of instructions when a software simulator which debugs a program (executable program) for microcomputer control simulates the state of the pipeline of the microcomputer. SOLUTION: Design data (timing data by instructions) of the microcomputer are held in the form of a timing table of the simulator and the state of the pipeline is actualized by software by referring the timing table of a corresponding instruction each time the instruction is executed to calculate an accurate execution machine cycle; and a timing data storage part is provided and its contents as execution histories by the instructions can be viewed by the user as a function of the simulator.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a simulator of a pipeline computer for simulating the state of a computer (computer) having a pipeline structure in each execution cycle on a general-purpose computer (personal computer, EWS).
In particular, the present invention relates to a timing simulation method and an apparatus for performing, on a target computer on a general-purpose computer, a pipeline state in execution of each instruction by referring to a timing table for each instruction and performing an operation equivalent to hardware.

[0002]

2. Description of the Related Art FIG. 3 shows an example of a general method for analyzing a conventional microcomputer control program (executable program). Referring to FIG.
To create a microcomputer control program.
Thereafter, in step 302, the program created in step 301 is compiled to create an executable program. In step 303, an in-circuit emulator (ICE) and a debugger (hereinafter collectively referred to as a debugger) are used, and in step 304, an executable program is loaded into the debugger. Then, any function (or
The only way to check the execution time and the number of execution cycles from the designated address to the designated address) was to look at the execution history of each instruction with the trace function of the debugger shown at 308. Since this trace function is a general function that is a cycle-based trace that usually indicates a state after pipeline control, there is no way for a user who debugs a change in an instruction execution cycle (execution time) caused by a combination of instructions to know. . However, some ICEs realize the execution cycle and the execution time with the same trace function. In this case, however, there is a demerit that the cost of the ICE increases because a dedicated memory for tracing is required.

[0003] In software simulators, there are simulators for controlling the pipeline of hardware (microcomputer) to be debugged, but there is a problem that the simulation speed is slow.

[0004]

As described above, in the conventional simulator, it is possible to simulate the state of the pipeline and simulate the execution cycle until the execution cycle increases due to the change in the state of the pipeline. As a result, there is a problem that a user who debugs a program in the state of the pipeline does not know why the number of cycles of the currently executed instruction has changed.

The present invention is intended to solve such a problem, and a simulator which operates exactly the same as the operation of hardware by directly using hardware design data of a target (microcomputer) to be debugged. The purpose is to provide.

[0006] Further, by separating the information of the pipeline into the instruction simulator and the CPU instead of incorporating it into the simulator main body and forming a table, the timing simulator itself is made into a general-purpose structure, and the timing simulator can be developed in a short time only by replacing the table. The purpose is to be able to do it.

[0007]

According to the present invention, there is provided a method for realizing a timing simulator, comprising:
A microcomputer control program having a different architecture from the computer,
Reads all the instruction tables of the microcomputer to be analyzed and the timing table for each instruction, analyzes the instructions stored in the instruction memory when executing the program for each instruction, determines the instruction from the instruction table, The pipeline information of the instruction is referred to the timing table, the output result is obtained from the timing table by a combination of the previous instruction information and the information of the own instruction, and the execution machine cycle considering the pipeline is calculated.

[0008] Further, an instruction analysis unit capable of sharing the internal structure of the timing simulator irrespective of the type of microcomputer to be analyzed, a command processing unit that receives a command from the simulator and performs processing in accordance with the command; All instruction tables for each computer, a timing table for every instruction of the microcomputer, and a product type dependent section storing the pipeline structure of the microcomputer are divided into different sections. A timing simulator that can realize simulations for all microcomputers by replacing the model dependent part.

[0009]

FIG. 1 is a diagram showing an internal configuration of a timing simulator according to an embodiment of the present invention.

The timing simulator shown in FIG. 1 includes a user interface unit 107 for performing input by a keyboard or a mouse and controlling output to a CRT, a file, or a printer, and a user interface unit 10.
7 shows a command processing unit 106 for executing a process according to a command input from 7, an instruction simulator 101 for simulating an instruction of debug target software for storing an analysis target executable program, and a timing table for each instruction of the target device. Instruction timing table 102, a pipeline structure unit 103 showing a pipeline structure of a device to be debugged, and a timing simulator engine unit 104 which blocks the instruction timing table 102 and the pipeline structure unit 103.
And a timing data storage unit 105 for storing the state of the pipeline after execution of each instruction.

The constituent unit 104 (including 102 and 103) makes a file for each of various microcomputers,
Even if the number of microcomputers to be newly simulated increases, the timing simulator engine unit 10
4 is added to improve versatility.

[0012] Except for the components 106 (including 104 and 105), even if the program to be debugged is changed,
Simulator functions can be realized without changing the internal structure (function, format).

FIG. 2 is a flowchart at the time of instruction execution of the pipeline simulator according to the embodiment of the present invention.

In FIG. 1, first, at step 201, the code table of the own instruction is searched, and at step 202, the status of the address register from the previous instruction is checked. In step 203, operand access of the instruction is checked to determine whether it is a branch instruction or, in the case of a branch instruction, the fetch address of the next instruction. Next, in step 204, an actual output result is obtained while querying the information up to step 203 when searching the timing table. Further, at step 205, a memory weight by space is calculated. Next, check if there is an interrupt request in step 2
If it is determined in step 06 and there is a request, an interrupt acceptance process 207
Move to If there is no interrupt request, step 207 is skipped. Next, in step 209, the number of execution cycles of the own instruction in consideration of the number of memory waits calculated in step 205 is added to the number of cycles derived from the timing table in step 204 to obtain the number of execution cycles. Then, the prefetch address of the execution address of the instruction following the own instruction is calculated, and the processing ends. By repeating the processing from step 201 to step 209, a pipeline simulation equivalent to hardware is realized.

FIG. 4 is an example of a code table for each instruction of the microcomputer to be debugged. The meanings of the items in FIG. 4 are “UARN” and “UARN”, respectively, for the address register in which the input parameter instruction (own instruction) may cause register interference (whether the same register used in the previous instruction is used). Indicates a number, and "-1" indicates that the address register is not used. This information is used to check for register interference in step 202. "MARN" indicates the number of the address register changed by the instruction of the input parameter. "-1" indicates that the address register is not changed. “OWT” indicates a store instruction. Used to determine writing to the I / O area. “2” indicates a read modify write, “1” indicates a write, “0” indicates a read, and “−1” indicates that there is no access to the memory. “OASZ” indicates the size of data accessed by a data transfer instruction involving load / store. “0” indicates a transfer instruction, “1” indicates a byte transfer, and “2” indicates a word transfer instruction.

FIG. 5 is an example of a timing table for each instruction of the microcomputer to be debugged. The meaning of each item in FIG. 5 is the in side (input parameter)
When the target instruction is in the first decryption stage, "FDA" indicates that the immediately preceding instruction is being loaded or stored in the execution stage. "FARM" indicates that the target instruction is the first execution stage and the immediately preceding instruction has rewritten the address register. "IFI" indicates that when the target instruction is in the decoding stage, the instruction is fetched from the internal ROM. “FDAI” is FDA =
When 1 (when the target instruction is in the first decoding stage, the loading or storing of the immediately preceding instruction is executed in the execution stage), it indicates that the immediately preceding instruction is loaded from the built-in ROM. “OFSI” indicates that the target instruction is a load or store instruction and is loaded from the built-in ROM. "IBCP" indicates the amount of instructions prefetched into the instruction buffer when the instruction in question is in the first decoding stage (the number of instructions in the instruction buffer). "TKN"
Indicates that the target instruction is a conditional branch instruction and the condition is satisfied. “BTO” indicates that the target instruction branches and the branch destination address is an odd number. The out side (output parameter) "FDA" indicates that the load or store is executed in the final execution stage (first decoding stage of the next instruction) of the target instruction. "FARM"
Indicates that the address register is rewritten in the final execution stage of the target instruction (the first decoding stage of the next instruction). “INTR” indicates the latest point in time at which execution can be aborted by an interrupt. For example, when INTR = 1,
The abort interrupt sequence can be started at the decoding stage of the target instruction or at the next stage. “INTC” indicates the earliest point of completion interrupt that can be accepted after the execution of the target instruction is completed. For example, when INTC = 2, it indicates that the completion interrupt sequence can be started two cycles after the first decoding stage of the target instruction. "OFS
F "is the operand fetch of the target instruction or
Indicates the access location of the store. When OFSP = 1, the operand is accessed in the cycle next to the first decoding stage of the target instruction (execution stage of the target instruction).
“OFS” indicates the number of operand fetches or stores of a target instruction. “IBCP” indicates the amount of the instruction prefetched into the instruction buffer at the time when the execution of the target instruction is completed. This numerical value becomes the input parameter (IBCP) of the next command. “IF” indicates the number of instruction fetches during execution of a target instruction. “+1” indicates a branch destination fetch. “CYCLE” indicates the number of execution cycles of the target instruction.

FIG. 6 is a hardware image diagram of the instruction execution flow shown in FIG.

An instruction code is acquired from an instruction simulator 600, and UARN, MARN, OASZ, and OWT information of a corresponding instruction is obtained from an instruction table map at 601. Next, there are a system for passing the UARN, MARN, OASZ, and OWT information 606 to the I / O data handling 608, and a system for using the operand address 611 to determine the address space. Next, the timing table of 602 is searched, and the FDA, FARM, and IBCP of its own instruction are output to 603. Next, 603 FDA, FARM,
The IBCP is passed to 604 as it is, and is used as a parameter of the immediately preceding instruction. Next, 604 FDA, FARM, IBC
P and FDAI are set as input parameters of the target instruction at 605. Further, the result of the conditional branch from 606 is passed to TKN of 605, and the result of space determination of 611 is passed to OFSI and IFI, and the necessary input parameter value of the target instruction is inputted at 605. Further, the input parameters of the timing table 602 are used as the search results of the timing table 603, and the CYCL information is passed to the cycle number calculator 609 to calculate the correct cycle number. Further, the INTR and INTC information of 603 is passed to the interrupt presence / absence determination of 610 and the next instruction execution start time calculation unit.
A status update request is issued to the 00 instruction simulator. Also,
At 603, the OFSP is output to the I / O data handling unit 608, and the result of calculation at 608 is sent to the instruction simulator 600 as I / O data, and a request for updating the I / O is issued. By repeating the above steps, a timing simulation that faithfully reproduces the operation of the pipeline for each instruction is realized.

[0019]

According to the embodiment of the present invention, in a timing simulator for simulating the state of each execution cycle of a computer (computer) having a pipeline structure on a general-purpose computer (personal computer, EWS), a micro-simulator to be simulated is used. Separate the computer-dependent part from the simulator body and create a file, so that the simulator system can be generalized and the parts that need to be newly developed can be reduced, and the hardware information of the microcomputer to be debugged can be reduced. The development period of the timing simulator is shortened by adding only the above.

Further, in the timing simulator, the pipeline state (timing information) is displayed as a pipeline state transition every time an instruction is executed or as a pipeline state transition after a program is stopped. The user can observe the state of the line.

[Brief description of the drawings]

FIG. 1 is a diagram showing an internal configuration of a timing simulator according to an embodiment of the present invention.

FIG. 2 is a timing search flowchart at the time of executing one instruction of the timing simulator according to the embodiment of the present invention;

FIG. 3 is a diagram showing a flow of a conventional technique of a debugging method of a microcomputer control program according to the embodiment of the present invention;

FIG. 4 is a diagram showing an example of a code table for each instruction of a microcomputer to be simulated according to the embodiment of the present invention;

FIG. 5 is a diagram showing a timing table for each instruction of a microcomputer to be simulated according to the embodiment of the present invention;

FIG. 6 is a configuration diagram of a timing simulator according to the embodiment of the present invention.

[Explanation of symbols]

 101 Instruction Simulator 102 Instruction Timing Table 103 Pipeline Structure 104 Timing Simulator Engine 105 Timing Data Storage 106 Command Processing 107 User Interface 201 Instruction Code Table Search 202 Address Register Interference Check 203 Space Judgment 204 Timing Table Search 205 Memory Weight Calculation 206 Whether there is an interrupt 207 Interrupt acceptance processing 208 Cycle number addition 209 Instruction prefetch address calculation

Claims (5)

[Claims] 1. A simulator that executes the same operation as the operation of hardware of a computer having a pipeline structure, wherein the same operation as the state of the hardware pipeline is realized by software every time a given instruction is executed. A timing simulator, characterized in that: 2. The timing simulator according to claim 1, further comprising a pipeline structure definition unit of a target computer to be simulated, wherein said pipeline structure definition unit is added according to the computer to be simulated. A timing simulator having a general-purpose simulator structure. 3. The timing simulator according to claim 1, further comprising: an execution state storage unit for storing a state of a pipeline for each execution of one instruction, wherein a state from the start to the end of execution of the program is stored in the execution state storage unit. A timing simulator that prevents a program execution time from being shortened and that can reproduce an operation of a pipeline state from the execution state storage unit after the execution is completed. 4. The timing simulator according to claim 1, wherein a priority is given to one of simulation accuracy (timing accuracy) and simulation time by an activation option of the simulator. 5. The high-level language structure according to claim 2, wherein the pipeline information defined by the pipeline structure definition unit is processed into target computer hardware design data (Verilog data). A simulation method of converting data into binary data for further improving the simulation speed and internally processing the binary data as a timing table.