JP2002007142A - Method and system for generating simulator - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and device for generating simulators for wide range architectures and for generating an instruction level simulator for easily constituting those simulators so that detail statistics, profiling, and/or timing information can be provided. SOLUTION: In this method and device for generating an instruction level architecture simulator from the machine description of an instruction level architecture to be simulated, a user adds a complementary simulation code to a simulation mechanism for correcting, increasing, or controlling the execution of the simulation mechanism so that a further complicate target can be better simulated. In a machine description format, an instruction dispatch code section 'before' and 'after' copied to the corresponding section of a code for executing a core simulation mechanism is provided so that a method for operating the simulator can be reinforced or corrected.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to an instruction simulator, and more particularly, to a tool for generating an instruction level simulator.

[0002]

BACKGROUND OF THE INVENTION Software development for embedded systems relies heavily on the use of simulators. Unlike general purpose computers, embedded hardware, by its nature, provides little support for the software development cycle. Often, software development must start well before the actual software becomes available. Therefore, simulators need to provide a convenient platform for inspection, debugging, profiling and optimization of embedded applications. When properly configured, the simulator can provide more detailed statistics and profile information than any hardware platform.

A disadvantage is that simulators are much slower than the hardware they simulate.
The more detailed the simulation, the longer the simulator runs. Logical and functional level simulators only have simulation speeds on the order of tens or hundreds of cycles per second. Instruction level simulators are faster. The speed ranges from thousands to millions of simulation cycles per second.

[0004] Instruction level simulators for a given embedded architecture are commonly available from vendors and / or one or more third party suppliers. They are often part of a complete tool chain, but their usefulness is often limited to several methods. First, commercial simulators often offer only limited simulation capabilities. Simulators typically report only the entire elapsed cycle, although a debugger interface is often available.

No other statistical or profiling information is provided. Second, these simulators are distributed in binary form. Therefore, it is not possible to extend or customize these simulators to collect new statistics or profile new events.
Third, simulators are typically only available for a small number of host platforms that do or do not match well with the customer's computing environment. Fourth,
The simulation speed is often not fast enough to favor large applications, large data sets or frequent inspections.

For example, European Telecommunications St
andards Institute, Digital Cellular Telecommunicat
ions System (Phase 2+); Adaptive Multi-Rate Speech
G shown in Transcoding (GSM 06.90) (Dec. 1999)
SM-AMR (Global System for Mobile Communicatio
(ns-Adaptive Multi-Rate) Implementation of a global system for speech transcoders, enabling important applications in a cellular telephone to a set of standard test vectors requires several digital signal processors (DSPs). ) Requires 200 million simulated instructions. In order to complete the activation in one CPU week, the simulator must be able to simulate about 450,000 instructions per second. 1 CPU day (one
Approximately 2.5 million instructions per second are required to complete the activation at CPU day).

[0007] One solution is to write a fast instruction level simulator from scratch. However, writing an instruction-level simulator manually is labor intensive, time consuming, and error prone. Also, TM Conte & CE Gimarc, editors, "Fa
st Simulation of Computer Architectures, "Ch. 2, K
Several more improved simulation techniques, such as dynamic cross-compilation, used to generate very fast simulators, as shown in luwer Academic Publishers (1995),
Make simulators that are complex, portable and difficult to modify.

[0008] Modern available tools for generating instruction-level architecture simulators do not provide a convenient mechanism for accurately simulating more complex target instructions. Also, currently available instruction level simulator generator tools do not provide adequate support for generating simulators that simulate parallel instructions. Typically, the instruction level simulator uses a simulated program counter that includes the address in the simulated memory space of the next instruction to be simulated.

[0009] If necessary, the instructions are first decrypted and the side effects of the instructions (side
-effects) are simulated. The program counter typically assumes that the program counter value should be updated with the simulated address of the next sequential instruction or the simulated address computed by the currently executing branch instruction. Be updated. However, this assumption may not be sufficient to correctly simulate various computer architectures at the instruction level in the usual way.

For example, MIPS Technologies, Inc. of Mou
MIPS architecture commercially available from ntain View, CA, and Texas Instruments Incorporated
TI C62x, commercially available from of Dallas, TX,
x architectures are both delayed
Implements a branch, where the side effects of the branch, ie, changes in control flow, are not effective until a number of cycles after execution of the branch. Obviously, so that the branch side effects take effect immediately,
The return of the target address for the next sequential instruction is incorrect.

For example, JE Veenstra and RJ Fowler,
"MINT: A Front End For Efficient Simulation of Sh
ared-Memory Multiprocessors, "Proc. of the 2d Int '
l Workshop on Modeling, Analysis, and Simulation o
f Computer and Telecommunication Systems (MASCOT
The Mint simulator shown in S), 201-207 (Jan. 1994) solves this problem of simulating a delayed branch by providing two versions for each instruction. The first version is applicable for general execution, and the second version is applicable when instructions are executed in branch delay slots.

[0012]

SUMMARY OF THE INVENTION An instruction level simulator that provides simulators for a wide variety of architectures and facilitates configuring these simulators to provide detailed statistics, profiling, and / or timing information. There is a need for a method and apparatus for producing. There is also a need for an instruction level simulator generation tool that generates a portable simulator for a variety of host plot forms. Yet another need exists for an instruction-level simulator generation tool that makes simulators as fast as possible without compromising portability and ease of writing simulators. There is also another need for an instruction level simulator generation tool that allows simulation of certain instructions, including instructions executed in delay branches, and control of the timing of simulation of parallel instructions.

[0013]

SUMMARY OF THE INVENTION A method and apparatus for generating an instruction level architecture simulator from an instruction level architecture machine description to be simulated is disclosed. The disclosed simulator generation tool facilitates the generation of a basic simulator and provides a program with sufficient flexibility to control and extend the simulator to perform cycle-accurate simulations. The disclosed simulator generation tool preserves the concept of time and concurrenc in the sequencing of simulation steps.
Generate an instruction-level architecture simulator that can maintain y).

In accordance with one aspect of the present invention, a user may be required to better simulate more complex targets.
Supplemental simulation behavior can be added to the simulation mechanism to modify, augment or control the execution of the simulation mechanism.
The machine description format provides "before" and "after" instruction dispatch code sections that are copied into corresponding sections of the advanced that embody the core simulation mechanism to enhance or modify the way the simulator works .

The semantic of each target instruction is embodied by a function such as a C function called a semantic function. Each of the decoded target instructions represents a target instruction and includes a target instruction descriptor (TI) that contains information used by the simulator generation tool.
D) has an associated data structure called D). In decoding, the semantics of the target instruction are tied to the TID by assigning the address of the correct semantic function to the function pointer in the TID.

During the simulation, the simulated program counter first computes the address of the TID pointed to by the target instruction. Thereafter, supplemental simulation code copied from the "before" section of the machine description may be executed in accordance with the present invention. Then, the instruction dispatch itself is executed using an indirect function call to the semantic function specified in the TID. The return value is copied to a simulated program counter (PC). Finally, additional supplemental simulation code copied from the "after" section of the machine description may be executed in accordance with the present invention.

The present invention then allows optional code to be introduced before and / or after the target instruction dispatch. In this way, the simulator generation tool can modify, augment, or control the simulation mechanism to better simulate a more complex target architecture.

The supplemental simulation code included in the simulation mechanism is used to simulate the delay line, for example, to buffer the target address of the branch until the correct point in the simulation for the flow of control has been changed. Can be used. Also, supplemental simulation code included in the simulation mechanism provides a simulated write-back to the resulting regestor file at the end of the simulated cycle for an architecture that allows for parallel processing. ) Can be used to control The "before" and "after" sections can be used to insert code to gather simulation statistics and profiling information for the program being simulated.

[0019]

FIG. 1 is a schematic block diagram showing an example of an instruction level simulator generation tool 100 according to the present invention. The present invention provides a simulator generation tool 100 that reads a description 400, described in detail below in connection with FIG. 4, of an instruction level architecture to be simulated, and generates an instruction level architecture simulator 180. As described below, the present invention facilitates the creation of a basic simulator and provides a programmer with enough flexibility to control and extend the simulator to perform cycle accurate simulations.

The generated instruction level architecture simulator 180 includes a simulation mechanism 185 that controls the simulation of the target architecture, including sequencing the simulated instructions. The present invention allows a user to create an instruction-level architecture simulator 180 that maintains concurrency in the notion of time and sequencing of simulation steps.

In accordance with a feature of the present invention, simulator generation tool 100 allows a user to modify, augment or control the execution of simulation mechanism 180 to better simulate more complex targets. , Allowing additional supplemental simulation code to be added. As described further below in connection with FIGS. 3 and 4, the machine description format 400 shown in FIG. 4 used by the simulator generation tool 100 includes "before" and "after" instruction dispatch code sections 470. , 480
I will provide a. The C code written in the “before” and “after” instruction dispatch code sections 470, 480 is a C code 300 (FIG. 3) that embodies a core simulation mechanism to enhance or modify the way simulator 180 works. Are verbatimly copied to the corresponding sections 320, 340 of.

In one implementation, the supplemental simulation code included in the simulation mechanism 185 simulates a delay line to buffer the target address of the branch until the correct point in the simulation for the flow of control has changed. Can be used to Another application of section 480 “after” machine description 400 is to write simulated results to a register file at the end of a simulated cycle for an architecture that allows for parallel processing, such as the TI C62xx architecture. Is to control the back.

In this architecture, a variable number of 1 to 8 instructions can be executed in parallel.
The default behavior of the simulator generation tool 100 indicates that these instructions are simulated sequentially. Since the semantics of the architecture identify parallel issues, the result of these instructions and the side effects have the current end-of-cycle or recycle latency (for those instructions with unit cycle latency) ( It must be buffered until the end of some subsequent cycle (for instructions with a latency of more than one cycle, such as multiply instructions).

This causes all instructions to write their results to the buffer, and to detect the end of the simulated cycle and write back the correct value from the buffer to the simulated register file. It may be embodied by including the code in the "after" section 480. Yet another application of the "before" and "after" sections 470, 480 is to insert code to gather simulation statistics and profiling information about the program being simulated.

FIG. 1 is a conceptual block diagram of an exemplary simulator generation tool 100. Simulator generation tool 100 may be embodied as any commercially available general purpose computing device modified herein to provide the features and functionality of the present invention. For example, the simulator generation tool 100 is based on "Generating Effic
ient Simulators from a Specification Language, "Sw
edish Inst. of Computer Science (SICS) Technical R
eport, T97: 01, ISSN 1100-3154, (1997), S. Onder &
"Automatic Generation of Microarch by R. Gupta
itecture Simulators, "1998 IEEE Int'l Conf. on Com
puter Languages, 80-89 (May 1998), "LISA-Machine Description Language for Cycle-Ac" by S. Pees et al.
curate Models of Programmable DSP Architectures, "
36 ^th Design Automation Conf., 933-38 (June 1999),
And LISA User's Guide, Institute for Integrated
Signal Processing Systems, ISS-RWTH Aachen, Vers.
The simulation generation tool disclosed in 1.60 (February 17,2000) can be embodied modified to provide the features and functions of the present invention.

Specifically, as shown in FIG.
Simulator generation tool 100 must include a simulator generation process 150 that includes the features and functions of the present invention described herein. The simulator generation tool 100 includes certain standard hardware components, such as a processor 120, a data storage device 130, and optionally a communication port 140.

The processor 120 can be linked to each of the other listed elements by means of either a shared data bus or a dedicated connection, as shown in FIG. The communication port 140 is the simulator generation tool 1
00 is connected to, for example, a LAN (not shown). The data storage device 130 searches according to the present invention,
The processor 120 is operable to store one or more instructions operable to convert and execute (optionally in parallel).

Simulation Mechanism The simulator 180 generated according to the present invention uses the TM C
"Fast Simulation of Co by onte & CE Gimarc, etc.
mputer Architectures, "Ch. 2, Kluwer Academic Publ
Use the pre-decode simulation mechanism as shown in ishers (1995). Instead of decoding the target instruction each time it is executed, the simulation mechanism decodes the target instruction once and the decoded information is stored in an easy-to-use intermediate representation.

When instructions are executed iteratively, the information stored in this intermediate representation is reused, amortizing the overhead of decoding the instructions, and increasing the overall simulation speed. The intermediate representation is embodied as a C structure type and is called the target instruction descriptor (TID) 220 shown in FIG. Separate TID
But the cached mode (cached
mode) is maintained in code memory for each decoded instruction, except when using mode).

The TID is stored in the instruction store 21
Stored in an array called 0. The instruction store 210 may be used in either an exhaustive or a cached mode. The mode is selected by the command line option when the simulator generation tool 100 is required, and is fixed for any given generated simulator.

In the exhaustive mode, there are TIDs for all possible target instruction locations in the simulated memory. For a 32-bit, word-aligned, instruction set architecture such as MIPS,
One TID is allocated every 4 bytes of the simulated instruction memory. 2, 4 and 6
For architectures such as the SC140 architecture with byte length instructions, there is one TID for every two bytes (instruction alignment unit). A standard executable file has sufficient information about the size and location of the program text section to prevent having to assign a TID to all but some of the instruction memory occupied by the program text. provide.

The advantage of the exhaustive mode is that the TID
Is persistent throughout the simulation. This makes the TID a convenient place to store instruction level statistics 222 and profiling information 224 that are reported or processed at the end of the simulation.

The cached mode can be used either when a smaller memory footprint is desired or when the entire instruction store of the device needs to be simulated. In the cached mode, the instruction store operates as a direct mapped TID cache. As a result, TIDs for multiple target instructions may be mapped to a single location in the cache. This means that the TID must be validated before using the information stored in a particular TID.

This is done by storing the address of the target instruction in its corresponding TID at the time it is decoded, and by comparing it with the program counter (PC) before use. If there is no match, the instructions must be decoded again and overwrite any previous information stored in the particular cache entry. T
Since IDs can be overwritten, they are no longer useful for storing any statistics or profile information.

While there is concern that simulation speed may be reduced in cache mode due to instruction replacement and re-decoding, experience has shown that the performance impact is negligible. The TID cache has a similar size (number of entries, not the size of memory) and performance approximately equivalent to the organization's processor instruction cache. Similarly, the additional overhead of validating the TID before use is not significant.

The semantics of each target instruction is embodied by its own C function. This function is called the semantic function 230 for the specific target instruction. In decoding, the semantics of the target instruction are determined by assigning the address of the correct semantic function 230 to the function pointer 226 in its TID.
Tied to that TID 220.

Thus, instruction dispatch is performed by JE Veenstra and RJ Fowler.
"MINT: A Front End For Efficient Simulation of Sh
ared-Memory Multiprocessors, "Proc. of the 2d Int '
l Workshop on Modeling, Analysis, and Simulation o
f Computer and Telecommunication Systems (MASCOT
S), 201-207 (Jan. 1994), which can be embodied as an indirect function call similar to the dispatch mechanism used in Mint.

In the case of a delayed branch, the semantic function 230 for the branch instruction will place the branch target address in a "branch target" buffer. The code is Machine Description 4
Written in section 480 after 00 to track the progress of the simulation and detect when the simulated program counter should be updated with the next value from the instruction semantics. In this way, the realization of the semantics of the instruction is
It is greatly simplified.

Instruction Decoding The decoding of the target instruction can be performed in two ways, eagerly or lazily. For example, mint uses an avid approach. The statement decodes the instructions of the program as it is loaded into the simulated memory. Eager decoding works best when the instructions are clearly separated from the data, and each instruction starts at a priori
i) needs to be determined.

This is a RISC (reduced instruction)
set) may be reasonable for style architectures, but is generally not possible for architectures with variable length instructions. For this reason, the exemplary embodiment of the simulator generation tool 100 generates code for performing instruction decoding lazily. This is done by initializing the semantic function pointer 226 of every TID entry to point to the special semantic function 230-s for undecoded instructions.

When this special semantic function 230-s is called, it first calls the decoding function. This decodes the target instruction and initializes the appropriate fields in TID 220. The special semantic function 230-s then calls the correct semantic function 230 using the new value of the semantic function pointer 226. Any returned values are sent back to the call site.

The lazy decoding approach is useful for simulating programs that include self-modifying or code generated at run time, or code that is dynamically loaded during execution. When any part of the program memory is written, as long as the semantic pointer of the affected TID is reinitialized for the undecoded function, the instructions will be decoded again and the program will It will be simulated correctly.

The decoder function is embodied as a series of if-statements that compare the bit patterns of the target instructions, in the order in which they appear, with the bit patterns of all the instructions in the machine description. Early return if one match is found
y return). Multiple matches can occur. Each match is
Causes the initialization of the fields in the TID. The set of TID fields that are initialized need not be the same for different instructions. However, some fields, such as the pointer 226 to the semantic function, are always initialized. Then, the semantic action for one instruction is identified by the last instruction that matched during decoding.

The multiple match feature (multip
le match feature) can be used to perform default initialization for classes of instructions that have encoding with the same subfield.
For example, both the TI C62xx and the Arm architecture have a full cond specified by a predicate encoded in the first four bits of the instruction encoding.
itional) having execution. Also, since the parsing of these four bits is the same for all instructions, it is convenient to express the analysis only once.

An efficient way to accomplish this is to first write the function for each predicate and declare an additional function pointer in the TID to point to one of these predicate functions. It is. using this method,
Predicates can be evaluated at runtime by indirect function calls.

A default instruction description (matching any instruction) is inserted into the machine description before any other instruction description to correctly initialize this predicate function pointer. In this way, the predicated function pointer is initialized once for all instructions. The remaining fields of the TID, including the semantic function pointer 226, are correctly initialized by a subsequent successful decoding.

One important feature of ordering instruction significants is that this allows for proper decoding of variable length instructions where shorter instructions may be prefixes of longer instructions. . One example of such an architecture is Microele
ctronics Group, Lucent Technologies and Motorola,
Inc., SC140 DSP CoreReference Manual (Dec. 1999)
Is a StarCore SC140 DSP. SC1
40 has a 16-bit instruction that matches the first 16 bits of some 32-bit instructions. By placing the instruction description for the 16-bit instruction before the 32-bit instruction, correct decoding is performed.

Main Simulation Loop FIG. 3 shows a main simulation loop 300 including features of the present invention. Loop 300 consists of four parts 31
0, 320, 330, 340. First, the address of the TID for the target instruction pointed to by the simulated program counter is computed in part 310. Second, C code verbatim copied from one section of the machine description is executed in part 320. Third, the instruction dispatch itself is performed, in part 330, using an indirect function call to the semantic function 230 identified in the TID. The return value is the simulated program counter (P
C). Finally, additional C code verbatim copied from one section of the machine description is executed in part 340.

And according to one feature of the present invention, the simulator generation tool 100
Target instruction dispatch (Part 3
30) before (part 320) and after (part 340). In this way, the simulator generation tool 100 can modify, augment or control the simulation mechanism to better simulate a more complex target architecture.

For example, the TI C62xx is an architecture such as a VLIW (very large instruction word) of statically scheduled, variable width issues. The TI C62xx instruction latency is apparent to the programmer, for example, one load has four delay slots during which the previous value of the destination register is accessible. As mentioned above, in order to correctly simulate this architecture, the parallel problems of instructions as well as their latencies must be correctly modeled.

The basic simulation mechanism of the simulator generation tool 100 executes an instruction simulation in a strict sequence. Since the semantics of the architecture identify parallel problems, the result and side effects of these instructions may be up to the end of the current cycle for instructions with unit cycle latency, or instructions with latency greater than one cycle, for example, Multiply instructions with recycle latency must be buffered until the end of some subsequent cycle.

One way to do this is to use the semantic function 23 for all instructions.
0 causes the side effects of the instruction to be written to a series of buffers, and then writes the code inserted after the instruction dispatch to detect the end of one cycle, and writes the pending values from the buffer back to the register file. ba
ck).

Machine Description FIG. 4 shows an exemplary structure for a machine description 400. Generally, the machine description 40
0 specifies architecture dependent information for one simulator. As described further below, the machine description 400 determines the encoding and semantics of each instruction in the instruction set, as well as the simulator generation tool 10.
0 includes additional field declarations for the various data structures used. Also in accordance with the present invention, machine description 400 includes supplemental code 185 to modify or add to basic core simulation mechanism 180, such as support for instruction VLIW issues or collection of statistics or profiling information. obtain.

If there is a need for flexibility and a need for a simple implementation, the machine description 4
00 is SC Johnson, "YACC-Yet Another Compiler
Compiler, "Computing Science Technical Report 32,
Follows a hirosofi similar to that of YACC shown in AT & T Bell Laboratories, Murray Hill, NJ (1975). C
Is used to the maximum extent possible.

An additional syntactic element is:
Give the machine description 400 the overall structure, send information directly to the simulator generator 100,
It will be added to represent these features of the architecture that are cumbersome and redundant to do in C. This approach is based on Simulator Generator 1
00 enables a simple implementation. Instead of having to parse and analyze the hardware technology language, C code is generated such that most code consists of code pasted directly from the machine description.

As a result, the semantics of the instruction, the state simulated by the architecture,
As well as TID and other structure user defined fields are specified in C. Further syntax (synta
x) is the encoding of the instructions, the use and handling of the bit fields of the instruction encoding, and the C
Added to conveniently represent providing a means for grouping parts of code.

FIG. 4 shows a machine description 400.
Shows the overall structure of. Machine description 400
Is divided into a number of sections. Section 4
The initial simulator directive in 05 allows for more stringent alignment requirements than the bytes aligned to be specified. Specifying the correct alignment reduces the overall space requirements of the instruction store when used in exhaustive mode.

The C code written in the %% hdefs section 420 is copied verbatim into a header file containing prototypes for all semantic functions. This file is included in all of the generated C source files. It is a convenient place to define types, variables and macros that should be visible for simulator source code.

%% cdefs section 420 and%
The% aux section 495 contains code that is inserted before and after the definition of the C function that implements the instruction semantics, respectively.

%% global, %% action and %% runinst sections 430,440,45
All of the 0s are used to add user defined fields to the three C data structures: Global State, Action Descriptor and TID. The text written in these sections is appended to the C structure definition for these data types. The global state structure stores global state information. The global state structure is intended to hold both machine states and any statistical counters.

Some internal simulation data structures are also stored in this structure. Action (or subinstruction) descriptors work similarly to TIDs for subinstructions and provide a way to semantically decompose instructions. Simulator generation tool 100 generates macro GLOBAL which is used to refer to field {x} in the current instantiation of each of the global state, action descriptor and TID data types, respectively.
(X), AP (x) and IP (x).

The %% ops section is where instruction semantics are described. The syntax for instruction semantics is detailed in a section called "Instruction Descriptions". This section has three locations: init $ 460, before $ 4
Also used to identify C code that is added to the core simulation mechanism at 70 and after $ 480.

These code sections are executed according to the present invention, respectively, at the time of simulator initialization, before all instruction dispatches, and after all instruction dispatches. For example, M
In the ips simulator, the C code that clears the register to zero every cycle is written to before $, and the instruction semantics indicates that subsequent instructions that may have been written to it also
Register zero can now be written, ensuring that it is always zero.

The instruction semantics for the additional instruction set are optional %%
Instset section 490 can be described. One %% instset separator is required for each additional instruction set.

Instruction Description Unlike modern RISC-type general purpose architectures, embedded architectures often have an instruction set architecture (ISA) with an encoding scheme and instruction semantics that are difficult to capture with a simple description. An example is that the shorter instruction is split into a plurality of discrete bit fields, a number of instruction formats and a register state dependent processor state to select a register bank, an intermediate, signed and Includes variable length instructions that may be valid prefixes for longer instructions than unsigned. And the encoding and semantic description of the ISA must be flexible enough to allow for the representation of highly irregular architectures while making it easy to use and intuitive.

The exemplary instruction description 500 shown in FIG. 5 used by the simulator generation tool 100 includes three parts: encoding, C source for (optional) decode actions, and C source for instruction semantics. Become. The instruction encoding is specified by a string of the form 0bX. X
Is the binary number (0,1), unnamed don't cares (?)
And / or a string of named don't cares (a-zA-Z). A number or symbol is repeated n times, followed by {n}.

Underscores can be used to visually separate the fields of the instruction, but this has no other significance. Named don't
Care is a bit field that can be referenced in the C code of instruction decode or semantic action by prepending $ to its name. The same in the encoding string
Multiple occurrences of named don't care are allowed as long as each is consecutive, and are automatically concatenated when a field is referenced. Discontinuous bit fields may be concatenated by referencing their name concatenation. Binary constant values can also be concatenated in named fields.

For example, $ a0b indicates an unsigned value of the concatenation of bit field a, constant 0 and bit field b. The signed value is referenced by ＄ and immediately following a∧, ie, ＄ ∧a0b.

When the bit pattern of the instruction description matches the instruction word being decoded, a decoder action is used to specify the C code to be executed during decoding. This can be used to calculate values, initialize fields in the TID, or perform any other desired side effects. This is particularly useful in connection with the multiple match decode feature of simulator generation tool 100.

C code specified as instruction semantics is executed exactly as specified, except that the bit field difference is replaced by a variable difference. Further, C
Code is added to the semantic function by default to return the program counter (PC) of the next sequential instruction. For many architectures, a branch may instead be performed by explicitly returning the value of the new PC. M with its delayed branch
For other architectures, such as the ips architecture, the code may require aft to properly modify the PC.
er $ section.

FIG. 5 shows an instruction description 500 for an exemplary Mips addi instruction. Instruction encoding is divided into four fields. The first field 510 is a constant that specifies an opcode. The next two fields 520, 530 are 5-bit values that encode the source and destination register operands (named s and t, respectively).
The last field 540 is a signed immediate value. The reference to i in the instruction semantics uses ∧ to refer to the sign-extended value.

Sub-Instructions To easily write simulations for some architectures, the simulator generation tool 100 provides a means for breaking down the semantics of an instruction into multiple sub-instructions. This is particularly useful where sub-instructions can be reused for multiple instructions.

For example, in the Arm architecture,
Many vanilla data processing instructions (such as ADD and SUD) use the "addressing mode
In what is referred to as a 1 ", the shifter pre-processes one of the operands, immediates, or registers. The input to the shifter and the specification of one of its 11 operations is determined during the affected arm instruction. Bit 25 and 12 re-occurrence bits (11.0) .This intersection of these instructions is referred to as a sub-instruction, or "action".
s) ".

The simulator generation tool 100 provides a simple mechanism for performing this decomposition by extending the use of the instruction description format to include a named scope.
A set of actions can be grouped together in one scope by putting the name of the scope, enclosed by "square brackets", immediately following the instruction identifier. All actions (sub-instructions) in one scope must have the same word width (variable-length action encoding in one scope is not allowed). Except for the scope identifier, all instruction descriptions for one action have the same features of the regular instruction description.

One scope can be referenced in the semantic section of the instruction description using a syntax similar to C function calls. Scope identifiers with the “$” prefix serve as “function names”. “Parameter” is the bit field reference described above. A particular action is bound to a scope reference by decoding the reference instruction when the parameter of the action reference matches the encoding of the action.

A separate decode function is generated for each named scope. If the instruction description refers to one scope and the action is not well tied to that reference, decoding will fail, just as if the bit pattern of the description did not match the current instruction word. The actual dispatch of the action is performed by an indirect function call.

One action can be a reference to another named scope, but recursive references are not allowed, directly or indirectly.

FIG. 6 illustrates the decomposition of instruction semantics using scoped sub-instructions (actions) for the exemplary arm shifter operation described above. As shown in FIG. 6, the code includes a set of sub-instructions (actions) in a first section 610, and a section 610.
Second section 65 seeking an action defined in
Contains a set of instructions in 0.

[0079]

As described above, according to the present invention,
Methods and apparatus for generating instruction-level simulators that provide simulators for a wide range of architectures and that facilitate configuring these simulators to provide detailed statistics, profiling, and / or timing information can do.

The number in parentheses after the requirement of the invention in the claims indicates the relationship of the embodiments of the present invention, and should not be construed as limiting the scope of the present invention. No.

[Brief description of the drawings]

FIG. 1 is a conceptual block diagram illustrating an exemplary instruction level simulator generation tool according to the present invention.

FIG. 2 illustrates various data structures used to represent instructions according to the present invention.

FIG. 3 is a diagram showing a main simulation loop including a feature of the present invention.

FIG. 4 illustrates an exemplary structure for a machine description.

FIG. 5 illustrates an exemplary instruction description used by the simulator generation tool of FIG.

FIG. 6 illustrates the decomposition of instruction semantics according to the present invention using scoped sub-instructions (actions) for exemplary operations.

[Explanation of symbols]

REFERENCE SIGNS LIST 100 simulator generation tool 120 processor 130 data storage device 140 communication port 150 simulator generation process 180 instruction level architecture simulator 185 simulation mechanism 210 instruction store 220 TID 230 semantic function 300 main simulation loop 400 machine description 500 instruction description 610 first section 650 second section

 ──────────────────────────────────────────────────続 き Continuation of the front page (71) Applicant 596077259 600 Mountain Avenue, Murray Hill, New Jersey 07974-0636 U.S.A. S. A. (72) Inventor Tall E Jeremiassen 81F, Oswestley Way, Somerset, 08873 New Jersey United States of America 81F Term (reference) 5B042 HH07 HH38 5B048 DD14

Claims (17)

[Claims] 1. A method for generating a simulator that simulates execution of a target instruction for an instruction level architecture, comprising: receiving a description of the instruction level architecture; and executing before or after the simulation of the target instruction. Receiving the supplemental simulation code; and generating the simulator from the description, the simulator executing the supplemental simulation code before or after the simulation of the target instruction. A method comprising: 2. The supplemental simulation code comprises:
The method of claim 1, wherein modifying execution of the simulator. 3. The supplemental simulation code comprises:
The method of claim 1, supplementing execution of the simulator. 4. The supplemental simulation code comprises:
The method of claim 1, wherein controlling execution of the simulator. 5. The supplemental simulation code comprises:
The correct (cor
2. The method of claim 1 wherein the delay line is simulated to buffer the branch target address until the point is changed. 6. The supplemental simulation code comprises:
The method of claim 1, wherein at the end of a simulated cycle for an architecture that allows for parallel processing, controlling a simulated result write-back of the result to a register file. 7. The supplemental simulation code comprises:
The method of claim 1, wherein code is inserted to collect simulation statistics. 8. The supplemental simulation code comprises:
The method of claim 1, wherein code is inserted to collect profiling information. 9. A method for generating a simulator that simulates execution of a target instruction for an instruction level architecture, comprising: providing a description template for a user provided description of the instruction level architecture; Providing a function for describing the semantics of: and generating the simulator from the description, wherein the description template is to be executed before or after the simulation of the target instruction. Including a supplemental simulation code section for including the code, To a method and executes the supplementary simulation code before or after the simulation of the target instruction. 10. The supplemental simulation code simulates a delay line to buffer a branch target address until a correct point in the simulation for the flow of control is changed. 9. The method according to 9. 11. The supplemental simulation code controls write back of simulated results to a register file at the end of a simulated cycle for an architecture that allows for parallel processing. Item 10. The method according to Item 9. 12. The method of claim 9, wherein the supplemental simulation code inserts code to collect simulation statistics. 13. The method of claim 9, wherein the supplemental simulation code inserts code to gather profiling information. 14. A system for generating a simulator that simulates execution of a target instruction for an instruction level architecture, comprising: a memory storing computer readable code; and operably coupled to the memory, the computer comprising: A processor configured to execute code readable by the computer, wherein the computer readable code receives a description of the instruction level architecture and executes before or after the simulation of the target instruction. Receiving the supplemental simulation code and generating the simulator from the description, the simulator comprising: System characterized in that before or after the simulation of said target instruction, executes the supplementary simulation code. 15. A system for generating a simulator that simulates execution of a target instruction for an instruction level architecture, comprising: a memory storing computer readable code; and operably coupled to the memory, the computer comprising: A processor configured to execute the readable code, wherein the computer readable code provides a description template for a user-provided description of the instruction level architecture; Providing a function for describing semantics, configured to generate the simulator from the description, The description template includes a supplemental simulation code section for including code to execute before or after the simulation of the target instruction, wherein the simulator includes the supplemental code before or after the simulation of the target instruction. A system for executing simulation code. 16. A product for generating a simulator that simulates execution of a target instruction for an instruction level architecture, comprising a computer readable medium having computer readable code means embodied thereon.
The computer readable program code means; receiving a description of the instruction level architecture; receiving supplemental simulation code to execute before or after the simulation of the target instruction; and Generating the simulator from a description, the simulator executing the supplemental simulation code before or after the simulation of the target instruction. 17. A product for generating a simulator that simulates execution of a target instruction for an instruction level architecture, comprising: a computer readable medium having computer readable code means embodied thereon. The computer readable program code means comprising: providing a description template for a user-provided description of the instruction level architecture; and providing a function for describing semantics of the target instruction. Generating the simulator from the description. The rate includes a supplemental simulation code section for including code to execute before or after the simulation of the target instruction, wherein the simulator performs the supplemental simulation before or after the simulation of the target instruction. A product characterized by executing code.