JP2002175344A - Co-validation method between electronic circuit and control program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To use a light-weight operating system on a message base as a base for co-design (cooperative design) and co-simulation (cooperative simulation) of hardware/software. SOLUTION: Circuit design is accepted operation description and is mapped to software processes. A VHDL process is translated by using a rule set designed for a specified light weight OS to be used. Hardware processes, mapped to the software mutually communicate state changes through message transfer primitive of the light weight OS, using an interface library. Integrated co- simulation environment of the software (to be written, for example, in C or assembler language) and the hardware (to be written, for example, in VHDL and a subset of C) is obtained by the addition of an instruction set simulator which operates under the same OS is added.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to a method for performing co-design and co-validation of hardware and software using a lightweight message-based operating system. And equipment. In particular, the electrical circuit design is mapped to a software process, and the state changes between the mapped electrical circuit elements are passed using lightweight operating system message passing primitives. An instruction set simulator operating under a lightweight operating system allows the control software elements and the mapped electrical circuit elements to be co-simulated and their interaction evaluated. The present invention provides software and hardware co-simul
, a computer system that implements the co-simulation method, a computer program product that includes software instructions that implement the co-simulation method, and a software simulation and instruction set of hardware elements Implemented as a software environment that supports simulation. The present invention is also realized as a method for developing an instruction set simulator for a target central processing unit (CPU).

[0002]

BACKGROUND OF THE INVENTION The following references all provide useful background information on the indicated subject matter in connection with the present invention.

[0003] PTOLEMY is concurrent.
A project to study heterogeneous modeling, simulation and design of systems. The current implementation is implemented in the Java programming language. http://ptolemy.eecs.berkeley.edu
The PTOLEMY website at
Includes more detailed information about

[0004] POLIS is a software program for hardware / software codesign of embedded systems. POLIS utilizes a framework developed for PTOLEMY. http: // www-c
The POLIS website at ad.berkeley.edu/~polis/ contains more detailed information about PTOLEMY.

[0005] Some subjects that provide a suitable basis for understanding the present invention will now be described.

[0006] In general, lightweight operating systems allow applications to run faster by removing many barriers between hardware and application-level code. One direct result is that few, if any, protection mechanisms remain in the system. This makes such environments suitable for embedded or dedicated applications, but not for applications that are poorly designed or intended to produce malicious results. . Traditionally, this has limited the use of microkernel systems for soft or hard real-time embedded code.

At present, the demand for good hardware-software co-simulation tools is driven by three main factors: 1. Increasing the size and complexity of computer systems (both hardware and software). 2. The need for cost-effective SOC (system-on-a-chip) implementation. 3. I that maximize return on previous investments
Reuse of P (intellectual property).

[0008] It is now generally recognized that an effective solution to the above factors requires both hardware and software components. This opened the design space to the "co-design" requirements. Many tasks, even with general-purpose central processing units,
How can the most efficient partitioning be done if it can also be performed by dedicated (or programmable) hardware? The design step works in a feedback loop as follows. 1. Perform initial partitioning into tasks and code task algorithms. 2. Assign tasks to hardware or software components and generate appropriate executable code according to these assignments. 3. Perform high-level simulation to confirm basic functions and operation constraints. 4. Correct errors and perform possible subdivisions to meet design criteria. 5. Performs complete synthesis of hardware components and software optimization. 6. Perform low-level (accurate timing) simulation of all components. 7. Iterate towards an acceptable or optimal solution.

A representative approach to this procedure, taken up to this point, is illustrated in the PTOLEMY / POLIS environment. PTOLEMY / POLIS claims to be a true co-design environment by allowing tasks to be synthesized in either software or hardware implementations. PTOLEM
The Y / POLIS environment provides a framework for an integrated simulation tool that allows inspection of a given partition, as well as a final code generation phase that produces a synthesized result.

However, the architecture of the PTOLEMY / POLIS environment reflects the prejudice of its author and its primary user (ie, a hardware engineer). The PTOLEMY / POLIS environment has minimal support for software components for the system design to be co-simulated. This includes ES, including for software implementation
It is clear from the need to write all task specifications in TEREL. ESTEREL is a suitable programming language as a front end to state machine type VHDL, but C
It is a difficult language to be synthesized into.

From a programmer's perspective, "good" E
Even if it is STEREL, "bad" C is generated. In fact, ESTEREL, in its programming style (simple if-then tests and goto branches),
Generate code very close to AN. This puts a heavy load on the C compiler even if only a certain amount of machine code is generated, and limits the ability to perform more global optimizations. Also, this condition forces software engineers to abandon existing IP and re-code useful and tested (and trusted) algorithms. Not to mention the lack of support for object-oriented technology, and the lack of high-level features of modern languages, software partitioning is a lower class in this hierarchy.

A modern programming language (for example, C +
Since there is no language that expresses both +) and a high-level hardware design language, there is considerable resistance even to trying to work on a unified co-design environment.

[0013] Other implementations of the PTOLEMY framework are possible and may help solve the above problems. Such a system would limit the possible design space and eliminate optimal results if existing code, including commercially available IP, which might not be available in source code form, could not be utilized. Could be. If the main problem (for cost and time-to-market reasons) is the reuse of existing “legacy” IP already split into hardware and software, the design space is change. For example, components that exist in a plurality of methods such as C code and VHDL can be easily conceived.
In this case, the problem is as follows. 1. Existing I that satisfies design constraints when used together
Does a set of P exist? 2. How to "glue" these processes, if present, so that control signals and data flow correctly
Do you have to? 3. If not, what are the bad points? What is the approach needed to solve that?

These issues emphasize the interface between existing designs and the overall correct operation of the overall system, and thus the emphasis on co-simulation and co-verification. It was done.

Considering that dynamic subdivision is excluded,
Programmers have the freedom to express their ideas in the language (single or multiple languages) that best suits their needs. Additional "glue" can be provided as a hardware entity (e.g., address decoding logic) or a software module (e.g., a driver for an off-CPU hardware chip). What is needed at this stage is a quick feedback system to evaluate the design.

Again, commercial simulation tools do not offer all of the promises. At times, this "tool" is just an integrated framework to which commercial simulators can be connected.
This saves a lot of important work, and if it provides a "plug and play" framework, the best tools can be connected to solve each requirement. However, in the absence of direct communication between individual components, and thus no direct feedback, this approach may ultimately fail as the design space increases. Such implementations are currently characterized by an iterative "iterative approximation" method that provides a trace from one tool to another and waits for convergence.

One alternative approach is to develop an architectural framework and co-simulation environment that already has the required feedback path, which can be re-targetable that may be useful across a set of problems. ) To place tools.

Considering the co-simulation problem from a software perspective rather than a hardware engineering perspective, and especially considering similar applications of SOC integration, several similarities emerge:

1a. Lightweight software systems tend to be written as a set of interacting processes through a small (sometimes real-time) scheduler. 1b. VHDL code tends to be written as a set of intercommunicating entities through a set of wires.

2a. Software processes tend to be event-driven. That is, the software process waits (waits) for some other process or an external signal, performs some processing, and waits for the next event. 2b. Hardware entities tend to be event driven. That is, the hardware entity waits for some condition appearing in the input, performs some processing, and waits for the next event.

3a. Events between software processes typically proceed by the sender preparing a "packet" (data area) of information and sending a "signal" to another process through a scheduler that acts as a data synchronization point. 3b. Events between hardware processes typically involve signals (e.g., chip select) through glue logic (e.g., latches) where the sender prepares a value on a set of "data" wires (e.g., a bus) and acts as a data synchronization point. (chip-select) signal) to another chip.

4a. In a single CPU system, there is no true software parallelism, but apparent parallelism is performed by the operating system switching between tasks. 4b. In all hardware, except for very trivial hardware, there is true parallelism, in which independent hardware units receive distributed clocks, each performing its own task during that clock cycle. Achieved.

5a. In a well-designed software system, individual processes operate independently, except for a predefined inter-process communication path, which can also be dynamically allocated. 5b. In a well-designed hardware system, each instance of the hardware process has a well-defined communication path using signals and wires,
It operates independently, except that it can be determined by settings in "glue logic."

Tools for simulation of VHDL code (eg, Model Technologies VSIM)
Already exists. Such tools operate by emulating the behavior of individual entities inside the entire system, and based on item 5b above, use software-based parallelization (ie, sequential execution) instead of hardware parallelization. )I do. This must be done by checking the state of each individual process (eg, delta or clock transition) at the synchronization point and making a state change at the end of each simulation cycle. Typically, the entire simulation environment runs as a single process on a workstation, and an internal scheduler tracks the state of its internal VHDL processes.

FIG. 1 illustrates a conventional VHDL simulation. Typically, the simulation environment is a multi-processing operating system (eg, UNIX)
(Registered trademark) 1). The components of the simulation are instruction set simulator 4, VHD
An L simulation 5 and an interface 6 for transferring signals. The VSIM environment 2 uses the internal scheduler 3 to control the simulation components. As shown in FIG.
Must be passed from the VHDL simulation 5 through the interface to the instruction set simulator. Interactions with external components 8 must be passed to the VSIM environment 2 through the internal scheduler 3, and furthermore, the VSIM simulator 2
Data must be passed through the system 1. The internal scheduler 3 is an essential component of a conventional simulation system because the operating system sees the entire VSIM environment 2 as a single process running in the UNIX operating system shell 1. At the same time, multiprocessing support of the UNIX operating system 1 is required to enable this process to interact with other external components 8 of the system.

A real system is a simple "sum of parts"
Often much more complex than the approaches show, problems in system integration can reveal design flaws that are overlooked during individual design phases.
This is particularly evident in the design of non-deterministic systems (eg, processing of data received over best-effort network links). Also, the design space must take into account the various errors that can occur (packet loss, data corruption, exceeded real-time deadlines, etc.) and strategies to handle the errors when they actually occur.

Another in real world applications
One problem is that the periodicity of the data is often not more than microseconds or nanoseconds, but a fraction of a second or more. As an example, consider a display system for MPEG data. There is a basic frame period of 33 ms (for a display of 30 frames per second), but this is not the true period of the data. MPEG provides a G with a (single) full frame of data and a series of interpolated frames to modify it.
Cluster the frames into OP (group of pictures) segments. Normally, a GOP is 15 frames, that is, data on the order of 0.5 seconds. This layer limits the propagation of errors as the loss of full frame data effectively renders subsequent frames in the GOP meaningless.

Therefore, in the design of such a system, a simulation shorter than the data of one entire GOP is likely to overlook an incorrect error processing situation. In fact, it is difficult to consider test strategies that do not require data on the order of seconds and simulated execution up to one minute. In such a system, there will be at least two "preliminary" steps for any given design. The first step is to confirm that the design handles the real-time constraints of full speed MPEG data. The second step is to look at how well it handles error conditions over much longer periods of time.

[0029]

The more powerful (for example,
There is a general tradeoff between the CPU and additional custom hardware (e.g., FPGA or ASIC) (in terms of cost, energy). Using the above MPEG example, without hardware support in the MIPS processor, it is not possible to display more than 10 frames per second. However, an Intel MMX level processor can display well over 30 frames without additional hardware. Such observations are a strong objection to using a single design language for both hardware and software. This performance can only be achieved by coding key routines directly in Intel's assembly language. It is almost meaningless to "crimp" a potential CPU by ignoring features that can correctly solve the problem at hand.

[0030]

SUMMARY OF THE INVENTION In view of the above circumstances, the present invention overcomes the above-mentioned problems and limitations of the prior art.

[0031] Still other advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. . The advantages of the invention will be realized and attained by means of the instruments and combinations particularly pointed out in the appended claims.

According to the first aspect of the present invention, a method of performing a validation (cooperative verification) between an electronic circuit and a control program targeting the electronic circuit is realized. Here, the electronic circuit and the control program are simulated using a predetermined computer language executed in a lightweight computer system operating environment.
The method includes translating an operation simulation of an electronic circuit into a hardware model consisting of a construct targeted at a lightweight computer system operating environment. Further, the method includes configuring a cycle accurate instruction set simulation. Accordingly, the instruction set simulation executes a part of the control program targeting the electronic circuit. Further, the method includes combining the hardware model of the electronic circuit with the instruction set simulation to create a system under test that executes in a lightweight computer operating system environment. In addition, the method involves inputting a stimulus to the system under test,
Including outputting the result to the system under test.

According to the second feature of the present invention, a computer system for validating an electronic circuit and a control program targeting the electronic circuit is realized. Here, the electronic circuit and the control program are simulated using a predetermined computer language executed in a lightweight computer system operating environment. The computer system has software means for managing the state of all global signals. Further, the computer system has software means for generating a clock signal. Further, the computer system has software means for managing a process queue that waits for an event. Further, the computer system has software means for executing at least one process at predetermined timing intervals. Further, the computer system has software means for central process control.

According to the third feature of the present invention, a computer system for validating an electronic circuit and a control program targeting the electronic circuit is realized. Here, the electronic circuit and the control program are simulated using a predetermined computer language executed in a lightweight computer system operating environment. The computer system has a processor and a memory containing software instructions adapted to enable the computer system to execute a central control process. The central control process has a signal maintainer subprocess that manages the state of the plurality of global signals, and a clock signal generator subprocess that generates clock signals used by the software model and instruction set simulator. Further, the central control subprocess has a queue maintainer subprocess that manages a process queue that waits for events from the software model and the instruction set simulator, and a timer subprocess that generates a predetermined timing interval. Further, the central control subprocess has at least a controller subprocess that controls execution of the signal maintainer subprocess, the clock signal generator subprocess, the queue maintainer subprocess, and the timer subprocess.

According to a fourth aspect of the present invention, a computer system for validating an electronic circuit controlled by a microprocessor and a control program targeting the microprocessor is realized. Here, the electronic circuit, the target microprocessor and the control program are simulated using a predetermined computer language and a predetermined interface library. This computer system has a software model of an electronic circuit. The functions of the electronic circuit have been translated into a predetermined computer language syntax that includes a portion of a predetermined interface library. Further, the computer system has an instruction set simulation of the target microprocessor, whereby the instruction set simulation simulates instructions executed by the target microprocessor when executing a part of the control program. In addition, the computer system has a central control process that couples the software model of the electronic circuit and the instruction set simulation of the target microprocessor to each other. The central control process has a signal maintainer subprocess that manages the state of the plurality of global signals, and a clock signal generator subprocess that generates clock signals used by the software model and instruction set simulator. Further, the central control subprocess has a queue maintainer subprocess that manages a process queue that waits for events from the software model and the instruction set simulator, and a timer subprocess that generates a predetermined timing interval. Further, the central control sub-process includes at least a signal maintainer sub-process,
It has a control sub-process for controlling the execution of the clock signal generator sub-process, the queue maintainer sub-process and the timer sub-process.

According to a fifth aspect of the present invention, an executable program for a computer system for validating an electronic circuit and a control program targeting the electronic circuit is realized. Here, the electronic circuit and the control program are simulated using a predetermined computer language. This executable program
A first executable code portion that manages a state of the plurality of global signals. Further, the executable program has a second executable code portion that generates a plurality of clock signals. In addition, the executable program has a third executable code portion that manages a process queue that waits for events. Further, the executable program has a fourth executable code portion that generates a predetermined timing interval. Further, the executable program has a fifth executable code portion that controls execution of at least the first, second, third, and fourth executable code portions.

According to a sixth aspect of the present invention, there is provided a method for deriving a cycle-accurate instruction set simulation of a target processor for verification of a system including an electronic circuit and a control program for controlling the electronic circuit. Is done. The method involves modeling the interaction between the memory and the cache as a sequence of signals on a data bus. Here, the target processor is stalled until the cache is loaded by waiting for the completion of the memory operation. Further, the method uses a sequence of signals derived from an internal data flow model of the target processor,
Using the internal bus width and timing to fill the instruction pipeline and delay by the appropriate number of clock cycles. Further, the method includes performing an instruction decode cycle of the target processor to interpret instructions available for execution. Further, the method determines whether the scheduled instruction implements pipeline disconnection, and if the scheduled instruction implements pipeline disconnection, causes the scheduler to stall for future instructions. including. Further, the method includes transferring the scheduled instructions to an appropriate instruction pipeline or hardware component and calculating a cycle execution time for each instruction. Further, the method determines whether there is non-deterministic timing. Further, the method includes outputting the results available at the end of the calculated execution cycle. Further, the method uses a signal interface, along with an emulated control register of the target processor,
Including determining whether the interrupt handler should be scheduled for the next cycle.

The above features and other advantages of the present invention will be apparent from the following detailed description and with reference to the accompanying drawings.

[0039]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Before describing the features of the present invention, some detailed matters will be described with respect to the prior art to assist in understanding the present invention and to present the meaning of various terms. .

As used herein, the term "computer system" has the broadest possible meaning and refers to a stand-alone processor, a networked processor, a mainframe processor, and a client / server relationship. Including the processor,
It is not limited to these. The term "computer system" should be understood to include at least a memory and a processor. Generally, a memory will, at various times, store at least a portion of the executable program code, and a processor will execute the instructions that make up the executable program code.

As used herein, the term "embedded computer system" comprises, but is not limited to, an embedded central processor and a memory having object code instructions. Examples of embedded computer systems include, but are not limited to, personal digital assistants (PDAs), cellular telephones, and digital cameras. In general, no matter how primitive, equipment that uses a central processor to control its functions can be said to have an embedded computer system. The embedded central processor executes the object code instructions stored in the memory. Embedded computer systems can have cache memory, input / output devices, and other peripheral devices.

As will be appreciated, the terms "predetermined operation" and "computer system software" mean, for the purposes of this specification, substantially the same. The practice of the present invention does not require that the memory and the processor be physically co-located. That is, it is anticipated that the processor and the memory will be in physically different devices and will be in different geographic locations.

As used herein, as will be understood by those skilled in the art, "medium" or "computer-readable medium"
May include diskettes, tapes, compact disks, integrated circuits, cartridges, remote transmissions over communication lines, or other similar computer-usable media. For example, to distribute computer system software, a supplier (or supply) can provide a diskette and provide instructions to perform some operation in any way through a satellite transmission, a direct telephone link, or the Internet. It is also possible to transmit.

As will be appreciated, the computer system software can be "written" on a diskette, "stored" on an integrated circuit, or "transmitted" over a communications line. For the purposes of the specification, computer-usable media will “have” instructions that perform certain operations. That is, the term “comprising” is intended to include the above and all equivalent methods of performing instructions for performing a given operation involving a computer-usable medium.

Thus, for simplicity, the term "program product" is used hereinafter to refer to a computer-usable medium (as defined above) that has instructions for performing a given operation in any form.

Next, the features of the present invention will be described in detail with reference to the accompanying drawings.

Because of the significant similarity between VHDL processes and processes running on lightweight operating systems, writing VHDL processes as separate software processes using the lightweight operating system and scheduling events is a good idea. It becomes possible. Preferably, the lightweight operating system is built on a small microkernel that provides message-to-process communication. The message is an operation code having related parameters, and expresses the event-driven model of item 3a described above. Preferably, the message is a global data definition that maps to a system structure passed between processes. Event semantics are defined by the application. In this case, the interprocess message is
It can also be used to notify processes about changes in VHDL signal values. Preferably, the lightweight operating system provides a set of message primitives that allow signal lines, address buses, data buses and clock distribution schemes to be built from a small number of basic messages. Preferably, in addition to the messages provided by the microkernel core, a process can also define its own message codes and parameters to implement an application-specific interface. In that case, this interface is organized into a set of routine calls implemented in the shared library.

Next, with reference to FIG. 2, a brief description will be given of a feature of the present invention for performing validation of an electronic circuit and software targeting the circuit. Electronic circuits and control programs are simulated using a predetermined computer language running in a lightweight computer system operating environment. In S0900, 1
Modeled by one or more circuit description languages,
Translate the elements of operation of the computer hardware into the syntax and methods of the selected lightweight operating system. In S1000, the operation description of the electronic circuit design is
Translate into a software model consisting of the above syntax targeting a lightweight computer system operating environment. In S1100, an instruction set simulator is configured in a predetermined computer language so that an instruction set simulation executes a part of a control program targeted for electronic circuit design. At S1200, a software model of an electronic circuit design is combined with an instruction set simulation to create a system under test that executes in a lightweight computer operating system environment. Finally, in S1300, the stimulus is input to the test target system, thereby causing the test target system to output the result.

Next, the features of the present invention for validating an electronic circuit and a control program will be described in more detail.

In step S0900, a hardware description language is checked. Although the VHDL language is preferably modeled, the methods and applications of the present invention are not limited to a particular language or a particular lightweight operating system. The control flow and style of the behavior level VHDL can be easily mapped to C in the following specific points.

The variables in VHDL are similar to the variables in C. That value is retained when control returns from the process. However, the scope of that name is local to the process in which it was instantiated. Therefore, the present invention replaces VHDL variables with C static variables. The bit vector type can be included in the unsigned integer type of C up to a 32-bit width (in the case of a processing system operated by a 32-bit processor). Both the individual bit access and the slice operation can be executed by shift and mask operations.

Signals are used to transmit values between processes. The scope of signal values is global throughout the system, but its name is local to a particular process. In the present invention, multiple copies of a process are represented by different signals (eg, UART_A_C
hip_Select, UART_B_Chip_Select) can be instantiated with the same local signal name (eg, Chip_Select). Simple signal values such as "0" or "1" and slice values are easily represented as bit patterns in the machine. VHDL supports logic values outside this range, such as "Z" or "W", depending on the electrical model used.

An individual VHDL process can suspend its execution for a fixed number of nanoseconds, or until a set of conditions on the signal is satisfied. Determining the conditions for a VHDL process to be "operable" is one of the functions that must be implemented in language syntax mapping.

The VHDL language provides a syntax for controlling the flow of hardware execution. This must be mapped to the equivalent syntax of the programming language (in this case, C) used by the lightweight operating system.

Preferably, a central process in the simulation system is responsible for tracking the value of each signal and distributing signal changes among the processes that monitor that value. When referring to this process in the following description, it will be referred to as the "fabric" process. The present invention uses a lightweight operating system message passing operation to process
Change signal values and pass other syntax. For example, the VH "wait for N ns" (N nanosecond wait)
The DL syntax is expressed by a message having the following two user-defined parameters. Msg WAITFOR {int CLOCKT; int TICKS;} The TICKS parameter provides the number of nanoseconds from the N parameter in VHDL, and the CLOCKT parameter provides the clock relative synchronization point.

The message interface does not appear directly in the application code. All interactions are through shared library routines that call the microkernel core functions.

Although signals are named using character strings, opaq
Referenced using ue type pointer. The following interface routines implement the mapping between signal names and references. In addition, the interface includes a shared library routine that notifies the central control processor about changes in signal values and waits for changes in signal values.

Void * fabinit (void): This routine initializes the central control process interface library. This routine must be called once by each process that will use the signal maintainer.

Void * fabric_find_signal (char * SIGNA
L): This routine uses the (globally named) SI
Returns an opaque pointer that can be used to refer to GNAL parameters. This routine performs a string comparison on all registered names and returns the signal reference, if one exists. Initial value 0 if the signal is not already in the list
Created with In this way, the processes need not be instantiated or initialized in a particular order.

Uint fabric_read_signal (void * SYM):
This routine returns the current value of the signal referenced by the opaque type SYM parameter, if it has a defined (ie, non-floating tri-state) value.

・ Void fabric_set_clock (char * NAME, in
t INITIAL, int PERIOD): This routine defines the clock signal used in synchronization operations for this process. This routine is a shared library call into the fabric process, which handles all transitions internally. The INITIAL parameter specifies the starting value of the signal (usually 0),
The parameters characterize the interval between transitions (ie, half a clock period). Since this defines a signal, the clock is global and multiple processes can also share a lock.

・ Void fabric_tristate (void * SYM, int
VALUE): This routine supports multi-valued logic signals that allow setting and comparison of extended values of the IEEE logic system.

Void fabric_write_signal (void * SYM,
uint VALUE): This routine uses the opaque pointer SYM
Set the value of the signal referenced by to VALUE.

The fabric process must know whether the signal is working in a simple binary domain or uses multi-valued logic. This domain is determined by the interface routines used to send signal changes across the system, and the implementation allows the multi-valued logic domain to be represented. An individual C header file (eg, ieee.h) that contains the required extended value representation for each multi-valued logical domain
Can encapsulate individual logical domains (eg, the std_logic package).

All Wait routines of the form
The parameter takes one of the following three values: 0 is
Refers to an asynchronous operation (scheduling a process as soon as specified conditions are met).
-1 schedules the process if the condition is met at the falling edge of the process clock signal, +1
Schedules a process if the condition is met at the rising edge of the clock signal of the process.

Void WaitClk (int CLOCKT): This routine suspends the current process until the next rising or falling edge of that clock (according to the CLOCKT parameter). Void WaitForc (uint TICKS, int CLOCKT): This routine suspends the current process for TICKS clock ticks.・ Void WaitUntilc (void * SYM, int OP, uint VALUE, i
nt CLOCKT) void voidUntil2c (void * SYM1, int OP1, uint VALUE
1, void * SYM2, int OP2, uint VALUE2, int CLOCKT) ・ void WaitUntil3c (void * SYM1, int OP1, uint VALUE
1, void * SYM2, int OP2, uint VALUE2, void * SYM3, i
nt OP3, uint VALUE3, int CLOCKT): These routines wait for one or more of one, two or three conditions to be true (simultaneously). Each condition is signal SYM, operation OP and VALUE. For example, the "EQ" operation is used to test for equality between SIGNAL and VALUE.

The above routine forms an inter-process message and sends it to the fabric process. This controller process keeps track of all changes to the signal and determines when to wake up the process waiting for the event.

These routines were implemented in a shared library and exported through a C header file. The header file also exports a global nanosecond tick counter managed by the fabric process so that trace output from individual processes can be tagged with the current timestamp.

Referring to FIG. 3, the present invention pre-processes each signal name. In S1010, for each signal, the present invention generates an internal variable by prefixing the name with the prefix phrase "signal_". Therefore, the opaque pointer to the signal CHIP_SELECT is "static v
oid * signal_CHIP_SELECT ". This new signal name is then combined with the signal reference when the process is instantiated. The instantiated signal name does not need to be the same as the signal name, for example , Signal_CHI
P_SELECT can also be instantiated as follows: signal_CHIP_SELECT = fabric_find_signal ("UART_A_CHIP
_SELECT "); In the main body of VHDL, the preprocessor uses the signal CHIP_SELEC
Modify the reference to T to refer to the variable signal_CHIP_SELECT. When instantiated, the variable signal_C
HIP_SELECT is coupled to the UART_A_CHIP_SELECT signal.

In S1015, it is determined whether or not there are more signal names to be preprocessed. If there is, in S1018,
The next signal name to be preprocessed is obtained, and the process control flow returns to S1010 to continue the preprocessing of the signal name. If not, the process control flow proceeds to S1020.

Referring to FIG. 3, the process control flow is S
Upon reaching 1200-S1060, a determination is made as to what type of operating language syntax is being used and how to translate that operating language into a syntax targeted at a lightweight computer operating system. Preferably, the operating language used is VHDL and the syntax used for translation is C-based.

In S1020, it is determined whether the operation language syntax to be translated is an assignment to an internal variable. If the assignment is to an internal variable, the process control flow is S10
Proceed to 25. If not, the process control flow proceeds to S1030.

In S1025, translation from VHDL substitution to C substitution is performed as follows. VHDL: i_word: = 1; C: static uint i_word; i_word = 1; After this translation, the process control flow returns to S1020.

In S1030, it is determined whether or not the operation language syntax to be translated is an assignment to an external variable. If the assignment is to an external variable, the process control flow is S10
Proceed to 35. If not, the process control flow proceeds to S1040.

Most interface routines use V
HDL-C translations are accessed through preprocessor macros designed to be easy to read and understand. These macros handle the conversion between signal names and variable names. In the following macro, "signal" is VHDL
Means the name of the signal. These names are opaque above
Preprocessed to type references.・ Uint GetSignal (signal NAME): This macro is NAM
Returns the current value of the signal E.・ Void Signal (signal NAME, uint VALUE): This macro converts the value of the signal NAME to its (32-bit)
Set to a value.・ Void SignalZ (signal NAME): This macro is called NAME
Is set to the IEEE Z value.

At S1035, translation from VHDL substitution to an external signal is performed as follows. VHDL: a_busp <= '0'; Macro: Signal (a_busp, 0); C: fabric_write_signal (signal_a_busp, 0); The generated assignment will generate a call to the fabric process through the runtime interface. After this translation is completed, the process control flow goes to S102.
Return to 0.

In S1040, it is determined whether or not the operation language syntax to be translated is a weight point. If it is a wait point, the process control flow is S10
Proceed to 45. If not, the process control flow proceeds to S1050. Similar to the assignment to the external signal, the weight point is mapped to an interface call using the following preprocessor macro. Void WaitClk ｛F | R｝ (void): Each of these macros waits for the next rising or falling edge of the process clock signal. • void WaitFor ｛F | R｝ (uint TICKS): These macros wait for TICKS nanoseconds. The process is scheduled for execution at that tick or at the next appropriate clock transition.・ Void WaitUntil ｛F | R｝ (signal NAME, int OP, uint
VALUE) ・ void WaitUntil2 ｛F | R｝ (signal NAME, int OP, uint
VALUE, signal NAME2, int OP2, uint VALUE2) ・ void WaitUntil3 ｛F | R｝ (signal NAME, int OP, uint
VALUE, signal NAME2, int OP2, uint VALUE2, signal
NAME3, int OP3, uint VALUE3): These macros indicate that a process waits until a condition appears on one, two, or three signals, and that the process is scheduled according to the required clock synchronization. enable.

At S1045, the translation of the VHDL syntax is performed as follows. VHDL: wait until (startn = '0'); Macro: WaitUntil (startn, EQ, 0, 0); C: WaitUntilc (signal_startn, EQ, 0, 0); Return.

At S1050, the VHDL control syntax is translated into equivalent C language operations. This translation may include additional interface calls. As an example, the translation of the 'if' control syntax is performed as follows. VHDL: if (resetn = '0') then Macro: if (GetSignal (resetn) == 0) ｛C: if (fabric_read_signal (signal_resetn) == 0)
後 After the translation of the control syntax, the process control flow goes to S10
Return to 20.

Referring to FIG. 4, at S1060, it is determined whether there is any more operating language syntax that needs to be translated. If there is more, the process control flow is S102
Go to 0. If not, the conversion process is complete.

With these few basic conversions, the operation VH
Translate the DL code into C, compile the code,
It is possible to link it for a lightweight operating system. Since the mapping between C and VHDL is one-to-one and reversible, there is no difference in the simulation whether the original design is formulated in VHDL or in translatable C. As long as the translation is performed correctly, the result will be the same. The subset of C that results from this translation is still a powerful programming language. It lacks some features specifically aimed at CPU-based algorithms, such as pointer dereferencing and advanced data structures, but otherwise serves as a starting point for re-targetable designs Is possible. Once the partitioning is known, the functions of the individual solutions (hardware or software) should be fully utilized.

According to a feature of the present invention, the software component of the design is an instruction-set simulator (ISS) of the target processor.
It is possible to simulate using r). Generally, such a simulator has the following three elements. 1. Emulation of target processor operations and registers. 2. An interface to an external program or human interface that displays the state of the emulated processor and controls the operation of the emulator. 3. Interface to emulation of external hardware that represents the devices present on the system under test.

Depending on the sophistication of the simulator and the interaction with external devices, the results may confirm only the basic functions of the system under test or give a simulation of the cycle accuracy of all processes. Sometimes. The configuration of the non-cycle accurate ISS will be described below as a first feature of the present invention, and modifications according to further features of the present invention will be described later.

Element 1 requires that the software emulate registers of the processor according to the specified architecture. Such registers include, but are not limited to, general purpose registers, floating point registers, control registers, and “hidden” registers that are not directly accessible from user software. In addition, operations on registers must also be emulated correctly, including the generation of status and error information caused by such operations.

Element 2 requires an interface to the external agent. Preferably, the ISS has a very simple command line interface and the commands used are listed in Table 1 shown in FIG.

Element 3 requires emulation of memory and other external devices connected to the processor. The ISS emulates local RAM using one of two methods. If the amount of RAM is small, the local memory of the host machine is used. Otherwise, disk space is used to hold the emulated RAM. This allows emulation of a machine that has more physical memory than an actual machine. This also provides a reviewable checkpoint of the memory in the event of a failure. As expected, using an external disk slows down the simulation considerably.

In order for the ISS to respond to external hardware, it must be able to access the model of that hardware. According to a first aspect of the invention,
A set of modules that represent the operation of external hardware
Linked to the ISS executable. External devices are assumed to be mapped into the CPU address space through external glue logic, and a range of (non-cached) memory addresses will cause access to the device. This access range is defined by a hardware command.

For example, a general UART interface can have the following five functions.

Void uart_reset (void): This routine is called during ISS initialization to simulate sending a hardware reset signal.

Uint uart_fetch (int ADDRESS, int LEN
GTH): This routine simulates a read request from the processor to the device. The device must return the appropriate number of bits specified by the LENGTH parameter, as if the ADDRESS parameter had been presented on its input address line.

Void uart_store (int ADDRESS, int LEN
GTH, uint VALUE): This routine emulates a write request from the processor to the device. This routine must act as if the ADDRESS parameter were presented on the input address line and the VALUE parameter was presented on the input data line. The LENGTH parameter specifies the number of valid value bytes.

Void uart_tick (void): This routine is called every processor clock tick and can be used to simulate data streaming and timer operations.

An interrupt generation routine that allows the hardware component to generate an interrupt signal to the processor.

This emulation does not include timing information. The UART is responding in the same clock tick where the event is presented. For test software where precise timing is not an issue, this simple model was sufficient.

Although a processor can operate with a clock of hundreds of megahertz, such speed is only realized when both instructions and data come from a fast on-chip cache. Accessing a slow cache or external memory will reduce the apparent performance of the CPU. Furthermore, for many co-design problems, external hardware can only write to off-chip RAM. This is also a constraint on software design. Accessing such data requires bypassing the data cache (although the data may be loaded into the cache as a result). Of course, accesses to memory mapped I / O locations must also be made through non-cached accesses.

However, this interface does not emulate different access times for components. All memory transactions are assumed to be completed in a single cycle.

The basic interface is provided through the following three routines that are called from individual instruction emulations as needed.

Void fetch (iblock * IN, uint ADDRESS
1, int NBYTE, uint * ADDRESS2): This routine
(Emulation) Load NBYTE bytes from address ADDRESS1 and store them at (machine) address ADDRESS2. The instruction block IN is used for resource score boarding. This routine performs a data cache search in the cacheable area, and otherwise accesses the emulated RAM or device.

Void ifetch (uint ADDRESS1, int MAX,
int IX): This routine implements the instruction fetch algorithm. This loads up to MAX words starting at the (emulation) address ADDRESS1 into the instruction pipe starting at index IX (4 words). The routine first searches the instruction cache and then goes to memory to fill the 8-word cache line if no data is found.

[0100] void store (block * IN, uint ADDRESS,
int NBYTE, uint * VAL): This routine starts at the (machine) address VAL and ends at the (emulation) address ADD
Write NBYTE byte to RESS. This routine also updates the data cache for cacheable memory. The instruction block pointer IN is used for score boarding. These routines also
Collect statistics on cache hits, cache misses, and access to non-cache memory.

If timing measurement is not required, the simplest (and fastest) simulation of the CPU is to fetch and decode instructions one at a time and complete execution of each instruction before proceeding to the next instruction. . Intel I96
Using the 0 processor chip as an example, the ISS provides sufficient emulation of cache operations. It supports both instruction and data caches and uses memory controller registers (mcon0-mco
Use n15) to determine whether to cache the data. This interface also provides address space decoding for accessing memory-mapped hardware devices. The routine calls one of the hardware routines (eg, uart_fetch) or accesses RAM emulation directly.

The ISS was used to execute an exemplary "hello world" program that runs as an embedded application under a lightweight operating system. This simple program has four processes: a UART driver, a console process, 'hello'
Including applications and idle processes. The program also includes an operating system core and a C runtime library.

The target system is started from a starting entry point. The target system clears the blank storage area to zero, performs a controlled processor reset, and sets an internal control register. The initialization routine creates four processes and calls the hardware initialization routine for the UART. This hardware initialization routine installs an interrupt handler.

The console process opens a message channel to the UART process and sets up a queue of messages so that it can receive input from the UART keyboard interface.

The application uses the C runtime library to execute normal I / O files (stdin, stdout
And stderr) to the console multiplexer process, then call the printf routine to format the string and send a message to the console. This causes a context switch to the console, prepending the process name to the string and appending it to the UART
Transfer to process.

The UART responds to the Tx-Available interrupt generated by the hardware and stores the character string at one time.
Send to the hardware character by character. After all characters have been sent, a message is returned to the application through the console process, after which the application exits.

Operating the ISS at this level can provide some degree of confidence that the software is operating correctly. For example, U with application
The software controlling the operation of the ART correctly interprets the status flags provided by the chip to indicate when the CPU can write characters. Further, the routines are called in the correct order with the correct parameters and linkages. It is also reasonable to assume that there is no detectable memory corruption and no access outside the defined memory area.

However, even if the simulator is operated in this mode, actual information regarding the execution time cannot be obtained.
It is assumed that every instruction takes only one clock tick. Activating the instruction timing mode and printing out the pipeline trace shows where the instruction cycle is going.

The use of the ISS allows access to information that cannot be normally obtained by using an in-circuit emulator. For example, it is possible to determine the maximum depth of the register cache actually used, and to count the number of frame spills together with the cache hit statistics.

It is also possible to count the number of times each instruction has been executed. Such data,
It is very useful in determining processor trade-offs, especially when manufacturing highly integrated SOCs. This is because, for example, the number of gates is reduced by a smaller number of branch instructions. I960 architecture is "prediction branch"
Have instructions, but the compiler does not use them. It is possible to remove these instructions, or consider another compiler that can take advantage of these features.

Even this level of detail is far from cycle accurate. In this case, a one-cycle memory model is assumed in which all bus transactions are completed in the same cycle (including multiword operations). To accurately model timing at this level requires a precise model of the system data bus and its devices, which requires creating a complete co-simulation environment.

Next, the configuration of a complete cycle-accurate instruction set simulation will be described. To enable true hardware / software co-simulation, an instruction set simulator for the selected CPU is required, including at least the ISS functionality required for the first aspect of the invention.

However, this function ignores the following three main elements when selecting a specific CPU.

1. Many instructions, such as multiplication and division, do not complete execution in a single cycle.

[0115] 2. The CPU may have implemented internal parallelism across multiple dedicated units so that bus operations can be performed concurrently with inter-register operations, assuming no resource usage conflicts.

3. Accesses to internal cache memory, external RAM memory, and devices may have very different response times from each other. The usual effect of this is simply to delay execution, but in some critical cases (for example, when the relative timing of incoming interrupts determines the order of processing of certain tasks), a significant effect on overall performance. May play an important role.

Next, a method for deriving a cycle-accurate instruction set simulation of a target processor for verifying a system having an electronic circuit and a control program for controlling the electronic circuit will be described in detail.

Using the Intel I960 processor as an example, the ISS models the I960 instruction scheduler by implementing the following functions in addition to the instruction cache. A 4-word instruction pipe with parallel decoding. Emulation of five I960 instruction paths. • Register scoreboarding to ensure that the result is not used before it is available. -Implementation of pipeline disconnection instructions such as branch and call. Pipelining for instructions that take longer than a single clock time to complete.

Referring to FIG. 6, the instruction pipeline is:
Checked at the beginning of each processor clock tick. If pipe is not completely filled, if to fill
The etch routine is called. If the instruction needed to fill the pipe is not found in the instruction cache, an ifetch pseudo-instruction is scheduled. This instruction is executed by the CPU
In the bus control unit (BCU) and the memory path (and may be delayed if these units are busy). Consequently, when this instruction is executed, eight words are loaded into the instruction cache line. Up to four of these words are used by the fill_Ipipe routine to fill the instruction pipeline. The number of words used depends on the state of the pipe and the current instruction pointer alignment with respect to the instruction cache boundary.

If there is data in the instruction pipeline, its value is decoded into an instruction. Because some I960 instructions occupy multiple words, incomplete instructions may be present in the pipe, in which case (as in the case of the second callx instruction in FIG. 6) it cannot be decoded . The instructions are coded once and the decoded form is stored in a data structure. Decoding also involves identifying the internal processing units, pipelines and register resources needed to schedule the instruction.

The resources being used by the CPU are represented by a scoreboard structure for each tick. The instruction is
It is taken out of the pipeline in order and scheduled one by one. Scheduling occurs when an instruction requests a resource that has already been committed during this tick, or when an instruction causes a pipeline disconnection.
Alternatively, it stops either when there are no more decoded instructions in the pipeline.

When the scheduler consumes a slot in the pipeline, the remaining data is carried up and the instruction pointer is updated.

When the scheduling is completed, the instruction to enter the unit at the current tick is executed. Instructions that take longer than a single tick to complete will propagate their resources to subsequent ticks when the pipeline stalls.

Referring to FIG. 6, AGU, MEM path,
Locking the frame pointer as the source register and the stack pointer as the destination register, the lda instruction can be scheduled at the current tick. This is the next call
The next callx instruction stays in the pipe to prevent the x instruction from being scheduled. Because the lda instruction takes multiple cycles to execute, the AGU stalls on the next tick and the resources from this instruction are
As long as it occupies the GU, it is copied to the scoreboard. ld
When a completes, it releases its resources and the callx instruction can begin. The next callx, which can now be completely decoded, is not scheduled for two reasons. First, this callx
Second, but not only because of a resource crash in, because the callx instruction causes a pipeline disconnection (and transfer to a new instruction pointer).

Referring to FIG. 6, emulation of the lda instruction is not particularly complicated. Because the instruction decoding routine has already evaluated the destination register and the memory operand, the routine simply updates the location (in ISS memory) holding the register. The results can be displayed to an external observer for examination, and the scoreboard is marked for a total of 4 ticks for this instruction.

In emulation, as long as the destination register is marked inaccessible during the instruction, there is no need to delay the assignment of the result until the "final" tick as in a real CPU.
This expedient no longer holds when the hardware is being simulated.

The process of modeling a cycle-accurate target processor will be described with reference to FIGS. In S1105, it is determined whether the target processor has an on-board cache memory. If the target processor has an on-board cache memory, the process flow proceeds to S1115, where the algorithm controlling on-board cache access is modeled. If the target processor has no on-board cache memory, the process flow goes to S1120
Proceed to.

In S1120, it is determined whether or not the target processor has an instruction pipeline architecture. If the target processor has an instruction pipeline architecture, at S1130, the instruction pipeline filling process is modeled. Otherwise, the process flow proceeds to S1135.

In step S1135, an instruction and a resource are created. Depending on the architecture of the target processor, a data structure is defined and initialized that represents the effect of each instruction, the resources in the target processor that the instruction requires and locks on, and the duration or termination condition of the instruction. .

Referring to FIG. 8, at S1140, an instruction is simulated by creating an interpreter for the resource definition defined above and the action of the instruction in the current machine state.

At S1145, it is determined whether or not the target processor has a multi-path architecture.
If the target processor does not have a multi-pass architecture, the process flow proceeds to S1165. In contrast, if the target processor has a multi-pass architecture, an algorithm is generated at S1155 that determines whether other instructions should be executed in parallel in the current machine state. If other instructions are to be executed in parallel, the process flow proceeds to S114
Returning to 0, the parallel instruction is executed. Otherwise, the process flow proceeds to S1165.

Referring to FIG. 8 and FIG. 9, S1165
Determines whether the simulated instruction is a multi-cycle instruction. If the instruction to be simulated is a multi-cycle instruction, a scoreboard is prepared at S1170 as described above. Next, in S1175, the resource is propagated as described above, and the process flow is S1
Go to 180.

In S1180, it is determined whether non-deterministic timing exists. If non-deterministic timing is present, termination is evaluated. At S1190, an algorithm is generated that determines the termination condition for a non-deterministic timing operation in the current machine state. According to the architecture of the target processor, this is
It may involve calculating based on values in emulated machine registers, and may also include generating code that checks the state of external signals. In S1192, the termination condition is checked, and if the instruction is not terminated, the process flow proceeds to S1175. If the instruction has completed, the previously propagated resources are cleared and the simulation of the instruction is complete.

Referring to FIGS. 10 to 13, an electronic circuit,
The execution of system validation including a control program for controlling the electronic circuit will be described. S13
At 10, a stimulus is input to the system under test. S13
At 15, it is determined whether the CPU is "operable". If so, the process flow goes to S1340
Proceed to. If not, at S1320, the target processor is stalled, and at S1325, the instruction is loaded into the emulated cache memory. In S1330, it is determined whether the cache memory has been loaded. If the memory has been sufficiently loaded, the target processor is uninstalled (stall release) in S1335.

At S1340, the instruction pipeline is filled with a sequence of signals derived from the internal data flow model of the target processor. Referring to FIG. 11, at S1345, a delay based on a predetermined number of clock cycles is performed to emulate the action of the internal data bus of the target processor. This predetermined number can range from one to several clock cycles based on the width of the internal data bus.

Next, at S1350, an internal decode cycle of the target processor is executed to interpret instructions available for execution. This instruction decode cycle is executed as described above.

After the internal decode cycle of the target processor has been executed, it is determined in S1355 whether the scheduled instruction implements pipeline disconnection as described above. If pipeline disconnection is requested, the instruction scheduler is stalled in S1365. If pipeline disconnection is not required, the process control flow proceeds to S1370.

Next, at S1320, the scheduled instruction is transferred to an appropriate instruction pipeline or hardware component. After transferring the instructions to the appropriate instruction pipeline, the cycle execution time of each instruction is calculated in S1375.

Referring to FIG. 12, in S1380, it is determined whether or not nondeterministic timing exists. If nondeterministic timing exists, in S1390, S119
The algorithm for determining the end condition generated at 0 is executed at the end of each clock cycle.

At S1400, the emulation propagates the resource allocation for the calculated instruction time.
In S1405, a result available at the end of the calculated execution cycle is output. This result may include updating the value of the emulated register or flag, or changing the value of an external signal.

Next, in S1410, it is determined whether an interrupt handler should be scheduled in the next instruction cycle. If it should be scheduled,
At S1420, an interrupt handler is scheduled for execution in the next instruction cycle.

Referring to FIG. 13, at S1425, the result from the stimulus is output from the system under test. This output can be a visual indication of the progress of the simulation shown to an external observer, or
It can also be the generation of a log of such changes for later review and post-processing (eg, a trace output as illustrated by FIG. 20). At S1430, it is determined whether there are any more stimuli to be input to the system under test, and if there are no more, the process ends. If there is, the process control proceeds to S1310.

Next, a detailed description will be given of how to output a result to the test target system by inputting a stimulus to the test target system.

In general, several different processes simulate different parts of the system under test. These processes are specific to the system under test and must be modified on a case-by-case basis. Referring to FIG. 14, a global loop controller 23 is used as an example to continuously repeat the designed test cycle to make the co-simulated hardware and software fully operate. The test stimulus process 24 provides stimulus to the system under test from the “outside world”. Another function of the test stimulus process 24 is to input erroneous inputs to the system under test to see how erroneous inputs are handled. For example, the test stimulus process 24 can act as a responder to a data transfer transaction and respond with a protocol error to test the retry mechanism of the system under test. Bus arbitration process 22
Provides bus arbitration between the system under test and the test stimulus process. The circuit under test 21 can be a single process or, in the alternative, several processes, depending on the complexity of the circuit design.

In addition, the signal display process allows step execution and monitoring of the effects of individual statements on the global state.

Next, combining the hardware model of the electronic circuit with the instruction set simulation to create a system under test that executes in a lightweight computer operating system environment will be described in further detail.

In the first stage, the operation description of the hardware is examined, and a process structure in which each hardware process is represented by an individual software process is configured. Within each process, the behavioral description is translated into a lightweight operating system programming language. An instruction set simulator is similarly coded in this language. The same applies to the fabric process and the stimulus generation program required for the simulator. As the second stage,
The programming language source files are compiled into object code for a processor running a lightweight operating system. Third, these files are linked with the object code for the lightweight operating system to form a complete execution environment. As a fourth step, the executable file is loaded into the system where the simulator runs. Fifth
As a step, the simulator is run under the control of a lightweight operating system and the output is observed.

Next, referring to FIG. 14, a computer system for validating an electronic circuit and a control program targeting the electronic circuit will be described.
A brief description will be given. Electronic circuits and control programs are simulated using a predetermined computer language running in a lightweight computer system operating environment. The computer system uses the above routine. After the end of the design step of S0900, the computer system has a fabric process 10. The fabric process 10 includes a signal maintainer subsystem 12 that manages the state of a plurality of global signals.
A clock generator subsystem 13 that generates a clock signal used by the software model and the instruction set simulator; a queue maintainer subsystem 14 that manages a process queue that waits for events from the software model and the instruction set simulator; A scheduler subsystem 16 for executing at least one process at a timing interval;
It has at least a signal maintainer subsystem 12, a clock signal generator subsystem 13, a queue maintainer subsystem 14, and a central control process 11 that controls the execution of the scheduler subsystem.

In addition to the microkernel support process, the computer system operates in the fabric process 1
0, instruction set simulation process, and
It has processes that represent hardware components and stimulation systems, all of which operate in conjunction with each other. Central control process 11 for co-simulation environment
Manages the overall function and interaction of the following five major subsystems. (A) A signal maintainer 12 that manages the state of all global signals. (B) Clock generator 1 for generating clock signal
3. (C) A queue maintainer 14 that manages a queue of a process that waits for an event. (D) A scheduler 16 that executes a respective active process for each nanosecond tick. (E) a display generator 15 that drives a display that indicates a signal change to the user. An example of a test stimulus is a signal indicating data availability on an external interface. The stimulus can also simulate an error condition, for example, a parity check error generated by an ECC memory.

Referring to FIG. 15, the entire simulation environment operates as a plurality of processes in the lightweight operating system 30. The individual processes include a fabric process 31, an instruction set simulation process 32, and VHDL processes 33 and 34. The VHDL processes 33, 34 correspond one-to-one with the instantiated hardware processes of the hardware being modeled. All signal interactions 3
5 passes through the fabric process 31 as a message scheduled by the operating system 30.

In such a software-based simulation system, since there is no true concurrency in a single processor system, only apparent parallel processing can be achieved. This is the "simultaneous"
Causes the problem of the concept of change and time. There are three issues to consider:

Problem 1: If two processes are operational and change the value of certain signals during their execution, the result may depend on the order in which the processes are performed. For example, if the signal "test" has the value '1' at the beginning of the run, process 1: if (test = '1') then test <= '0'; en
d if; process 2: test <= '1';

If the process 1 is executed before the process 2, the (simple) result is that "test" is "1" at the end of the execution.
It is set to. If process 2 runs before process 1, the result will be "t" at the end of the run.
est "is set to '0'.

Problem 2: If the process changes and a certain signal is read during the same execution period, the result is non-deterministic. For example, consider the following code fragment: Process 1: test <= '1'; if (test = '1') then output <= '1'; end if; In a real system, this may or may not set output to '1' .

Problem 3: The process requires an absolute time value for a clock signal operating at a known frequency. In addition, absolute time, along with more complex duty cycles, is required for syntax such as: Clock process: clk <=! Clk after 5 ns;

Conventional VHDL simulators typically address the first two issues by the concept of a "delta", or subtick synchronization point. Using the subtick sync point, all signal values are fixed at the beginning of the delta. These values are issued in response to requests for signal values, and the values are updated only at the end of the delta. This has the advantage of making the simulation deterministic and independent of the process simulation order.
This causes the VHDL programmer to extra wait to force alignment to the next delta.
Require that statements be inserted into the code. In case 2 above, a statement to force a delta boundary is inserted to solve this nondeterministic problem. Process 1: test <= '1'; wait for 0 ns; if (test = '1') then output <= '1'; end if; Process 1 consistently sets output to '1' Become. However, there is no guarantee that the combined result will work as expected.

In the current implementation of the fabric process,
An instantaneous value is issued (so this example acts as if the weights were implicitly inserted), but the result depends on the order of execution of the process. As will be apparent to those skilled in the art, the system detects multiple changes in a single "delta" for one signal and reports this to the simulation output or otherwise mimics other operations. Modifications can be made to change the implementation.

The simulator generates an absolute time value. The clock subsystem of the fabric process is
Currently, a basic time slice of 1 nanosecond is used, which is sufficient to track the required accuracy of the current clock signal. This may need to be changed as several GHz systems become more widespread. Clock signal support has been built into the central process to simplify the interface for common operations.

Most operating VHDLs are written with a trigger that operates in one of two modes. In asynchronous mode, a signal change describes a process that responds to the signal,
Enabled in the next nanosecond. In synchronous (clock) mode, the signal was only examined at the edge (rising or falling) of the clock signal. These modes correspond to S1 in FIG.
000 is determined during translation. The operability of the process was determined at the beginning of each nanosecond tick, based on the signal change that occurred in the previous tick and the clock transition that was taking place at that time. The process enabled during that nanosecond tick did not start until the next tick, providing an environment similar to the "delta" mechanism.

The salient features of this interface method are:
The process that is waiting for an event is in a true wait state in the microkernel core. That is, those processes are not checked at each clock tick and do not create overhead in the rest of the system. The fabric process handles all checks of the condition. By eliminating the overhead of traditional operating systems and running simulations directly under a lightweight operating system, the present invention not only runs faster, but also expresses the state to be emulated by scheduling the operating system itself. Implemented directly through the core.

Trace output can be displayed on the console as individual processes execute the translated code. If the ECHOVHDL variable of the whole system is not 0,
The simulation environment prints a character string prefixed with a nanosecond tick timestamp so that the change in signal value is visible to the observer. Perform step execution in combination with the signal display subsystem in the co-simulation environment and individual VHD
It is possible to watch the effect of the L statement.

FIG. 16 shows an embodiment of a computer system having the processor 40, the I / O device 43, and the video display terminal 41. I / O device 43
Include, but are not limited to, a keyboard and a mouse. Other devices such as touchpads can be used. In addition, the computer system has a memory 42 (not shown, but incorporated in processor 40) containing software instructions adapted to enable the computer system to perform the steps of the present invention.

The computer system is connected to the server 4 connected to the processor 40 by the data link 44.
5 can also be included. The data link 44 is a conventional data link (for example, Ethernet, twisted pair, FTP, HTTP, etc.). The server 45 provides access to a program library 46 connected to the server. The program library 46
Can also provide software instructions adapted to allow a computer system to perform the steps of the present invention. As noted above, the program library 46 may be implemented on any of a variety of media known to those skilled in the art (eg, floppy disks, hard disks, optical disks, cartridges, tapes, CD-
ROM, writable CD, etc.).
In the computer system shown in FIG.
The above software instructions allow processor 40 to access program library 46 by accessing server 45 via data link 44. The computer system shown in FIG. 16 is not intended to be limiting in any way, and many different computer systems embodying the present invention may be combined.

FIG. 17 shows a block-level design of an exemplary system modeled by the present invention. The system has an I960 processor 35, glue logic 36 and UART 37. This exemplary system is not intended to limit the scope of the present invention, but to assist in the following description. This sample system
An external data bus has an I960 instruction set simulator connected to both the memory subsystem 38 and the address decoding glue logic 36. The arrow is
Indicates one-way or two-way signal. The glue logic 36 is a chip for the memory and UART chip 37.
-Drives the select signal and provides UART 37 with various signal presentation requests. This design was intentionally divided into multiple timing domains by two clocks, a processor clock and a bus clock.

To demonstrate the co-simulation environment,
The I960 instruction set simulator is NEC VR43
Using information from the 00 processor User Guide, it was linked to a data bus based on the MIPS architecture. Because there were no external bus mastering devices on the bus, the system used a subset of the full MIPS bus. The selected set of signals, with varying burst times, and varying response times, were sufficient to implement the device.

The bus operates in a synchronous mode, with activity scheduled on the rising edge of the busclk signal.
The signals and protocols are as described below.
The following bus signals are used: • SysAD [31..0] Multiplexed system address and data bus. • SysCmd [4..0] Command bus that identifies data and transaction type. This is 8 in read mode
Adds bursts of words but does not use error indication commands and external non-response mode. EOK Set low when the external device can accept the command. EValid Set low when an external device places valid data on the bus. Set high when the PMaster processor releases bus ownership (so that external devices can issue read responses). In this simple model without an external bus mastering device, no other protocol signals from the full MIPS bus were used.

Referring to FIG. 18 from the processor's point of view, the bus is driven in the following order. 1. The processor waits for EOK to go low, indicating that no external device is using the bus. 2. The processor writes the address on SysAD and SysCm
Drive the appropriate Write command on d. The processor also sets PValid low (this indicates that there is valid data on the bus). 3. The processor waits for EOK to go high, indicating that the external device has accepted the command. 4. The processor sequentially drives the SysAD bus with one data word every busclk cycle and marks the last (or only) word with the 'no-more' flag. 5. At the end of the last data cycle, the processor
Set PValid high (indicating that the processor is no longer driving the bus), SysAD and S
ysCmd is tri-stated.

Referring to FIG. 19, the processor read is as follows. 1. The processor waits for EOK to go low, indicating that no external device is using the bus. 2. The processor writes the address on SysAD and SysCm
Drive the appropriate Read command on d. The processor also sets PValid low (this indicates that there is valid data on the bus). 3. The processor waits for EOK to go high, indicating that the external device has accepted the command. 4. The processor sets PValid high (this is
(Indicating that the processor is no longer driving the bus), set PMaster high to release control of the bus. 5. The processor waits for EValid to be set low, indicating that the external device has placed valid data on the bus. Next, the processor
Data words are sequentially read from the D bus one by one every busclk cycle. 6. The processor waits for EValid to be set high, then sets PMaster low and regains control of the bus.

The UART used a very simple signal model as follows: UartD {7..0} is a byte-wide bidirectional data bus that supports single data (non-burst) access to and from the chip. UartA is a 1-bit "address" bus used to select one of the two internal registers.
Address '0' is a control register and address '1' is a data register. UartR is set low when the processor issues a read request. UartW is set low when the processor issues a write request. UartS is set low to select UART. The address and data bus values must be valid as long as the chip is selected. UartI is set high to signal an interrupt from the UART to the processor.

Busclk is the synchronous clock signal to the chip, and all transitions are sampled on the rising edge of the clock.

Since the UART requires that the address and data values be presented simultaneously, glue logic must handle the translation from the multiplexed SysAD bus.

[0172]

[Table 1]

The control register is used to access the internal UART register by two-step access in which an index number is first written and then 8-bit data is written. Control register 0 can be accessed directly by writing a control operation to the control address (the control operation has a binary value outside the range of the indirect register number). In this minimal model, only the control operations listed in Table 2 above were implemented. These were sufficient to provide an interrupt driven and polled mode output (no input).

The system memory stores the SysAD at the speed of busclk.
It was assumed to support back-to-back burst mode transfer over the line. Memory controllers include SysAD, SysCmd, PMaster and
Access to the EValid signal was granted and clocked by busclk. The memory controller used two additional signals to glue logic. MemS is the memory chip-select, which is set low when the memory was the target for command and address data on the bus. MemEOK is set low by the memory controller when it can accept commands.

The internal details of the "real" controller (eg, RAS and CAS generation) were not modeled, and all memory accesses were responded in a single (bus) clock cycle.

The UART and memory implementations are both
Written directly in behavioral C using the VHDL signal library to control their operation according to the above architectural specifications. In addition, the UART implementation stored a string instructed to be output to the ISS log file. This means that the simulator has generated a visual record of the output of the simulated system. Glue logic implements a state machine for coding and signal translation at addresses.
Written in HDL as a single entity. VHD
L was translated into C according to the method of S1000.

Next, integration of the above instruction set simulator into a co-simulation environment will be described. To integrate the ISS into the fabric environment, I
Some changes were needed for SS. Once I / O
When the operation was no longer of predictable duration, most of the changes were related to timing changes.

To initialize the fabric interface, a set of process synchronization clocks and signals,
The following code has been added to the process initialization sequence:

FabInit (); / * Specify pclock cycle * / fabric_set_clock ("pclk", 0, 5); / * Initial state of processor signal * / Signal (PMaster, 0); Signal (PValid, 1); / * Data and command bus are floating until driven * / SignalZ (SysAD); SignalZ (SysCmd);

The routine that simulates a single processor clock tick waits for rising edge changes on the pclk from the central fabric process by adding a call to WaitClkR (); before executing each tick. Was changed to This also has the effect of synchronizing the processor with other hardware components. It should be noted that this sequence of operations is specific to the system being modeled, as it is determined by the architecture of the selected data bus model. Such an integration step will be performed for each cosimulated design.

The basic strategy for input / output (fetch and store) operations remained the same. Depending on the memory area descriptor, after first referring to the data cache (or instruction cache), if the data is not in the cache, one of the external devices is accessed. The main change is that all address decoding was done in glue logic and the "hardware" description and device_store routine were not used.

The interface itself complies with the above description. For example, a new operation was started as follows (assuming the variable this points to an I / O request data structure):

[0183] That is, after waiting for EOK to be set low, the signal is driven onto the bus. Note that the unit must be stalled for the next tick, regardless of whether the command has been initiated and resources must be marked as unavailable. This routine also polls all its signals. This is because the weight point is in the 'step' routine.

In the absence of an external bus mastering device or error handling, the external interface was captured by a small state machine with fewer than 10 states. This machine also handled the instruction fetch cycle.

Special care must be taken when integrating interrupt signals into such systems. In a single process implementation, it is possible to directly modify the control registers during the interrupt processing of the simulated processor. In the co-simulation system, this is the UAR
Call to Signal (uartI, 1); in T code and corresponding test in ISS process Must be replaced by This approach caused problems when the Bus Control Unit was busy and the processor could not service the interrupt immediately, or when requesting an instruction fetch before the interrupt could be executed. Unless otherwise specified, interrupts will be serviced at each clock tick until the processor's priority register is updated to the interrupt priority.

This was handled by the flag set when the interrupt processing was started. This flag bypassed all pipeline scheduling as long as there was activity in the bus control unit, including activities scheduled by the interrupt dispatcher. Setting this flag
Ensured that all I / O operations were completed and the processor priority was updated before the operation to check the register during the interrupt was rescheduled.

The processor clock was set to operate at 100 MHz. Within the processor, the internal bus between the instruction cache and the instruction pipe was assumed to be full 128 bits wide running at full speed. Therefore, the instruction pipe is filled with zero latency from the cache. The data cache was assumed to be at level 1, ie, full processor speed. Since the memory access was operated by the busclk, one (processor) wait state was required for each access.

The UART was assumed to be connected to an 9600 baud external serial line. Thus, characters were sent every millisecond. Because there is no buffering inside the UART, the 'Tx Available' signal was delayed by 1 millisecond for each write operation.

This system was used to repeat the above code example, the execution of the "Hello World" program. The output shown in FIG. 20 demonstrates a running system running on a development board that includes a MIPS-III architecture CPU. This architecture is based on the simulated CPU (Intel I96
Unlike the architecture of 0), it demonstrates how a more powerful processor is used for simulation.

When the processing capability of the target CPU itself is low, the target CPU does not support the simulation environment and may not produce a result in an appropriate time. Because a device driver for a lightweight operating system can be easily written, a rapid prototyping and simulation environment can be provided.
There is no reason to limit the simulator to a single CPU.

Except for the lightweight operating system core itself, the simulation system is independent of the specific machine architecture. Its very low overhead and memory requirements allow lightweight operating systems to maximize available RAM for simulation without paging or swapping. Also, since such systems generally require a minimal set of external peripherals, high performance CPs can be used as simulation engines or accelerators for traditional workstations.
U may be used.

Referring to FIG. 16, according to another feature of the present invention, a target CPU of interest is located on a development board 50 connected to the simulation system 40 through a communication medium 51. The communication medium 51 can be a data bus that coexists in the system 40. The target application is the development board 50
Directly on the CPU, thereby avoiding the need for an instruction set simulator. This approach requires support from the CPU instruction set to maintain cycle-level accuracy, and its implementation for any given CPU can be derived from the principles already described.

The foregoing description of various features of the invention has been presented for purposes of illustration and description.
It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and various modifications and changes are possible in light of the above description. By carrying out the following. The principles of the present invention and its practical applications have been described so that those skilled in the art can make use of the present invention with various modifications in various embodiments to suit the particular application contemplated.

Therefore, although only some features of the present invention have been specifically described, it is apparent that various modifications can be made without departing from the spirit and scope of the present invention. It is possible. In addition, acronyms are used merely to increase the readability of this specification. It should be noted that such acronyms are not intended to reduce the generality of the terminology used and should not be construed as limiting the scope of the claims.

[Brief description of the drawings]

FIG. 1 is a diagram showing a conventional simulation system having a multi-layer simulation environment.

FIG. 2 illustrates a basic process flow of a method for validating an electronic circuit and software targeting the circuit, according to a feature of the present invention.

FIG. 3 illustrates a detailed process flow of a method for translating a hardware behavioral description into a software model, in accordance with an aspect of the present invention.

FIG. 4 illustrates a detailed process flow of a method for translating a hardware behavioral description into a software model, in accordance with an aspect of the present invention.

FIG. 5 illustrates an exemplary set of commands for a command line interface to an instruction set simulator.

FIG. 6 is a diagram showing a typical instruction flow by the Intel 1960 processor.

FIG. 7 illustrates a process flow for determining cycling of an instruction as it passes through a target microprocessor, in accordance with an aspect of the invention.

FIG. 8 illustrates a process flow for determining cycling of an instruction as it passes through a target microprocessor, in accordance with an aspect of the present invention.

FIG. 9 illustrates a process flow for determining cycling of an instruction as it passes through a target microprocessor, in accordance with an aspect of the present invention.

FIG. 10 illustrates a process flow of an emulated target processor when a validation simulation is performed in a lightweight computer operating system environment, in accordance with an aspect of the invention.

FIG. 11 illustrates a process flow of an emulated target processor when a validation simulation is performed in a lightweight computer operating system environment, in accordance with an aspect of the invention.

FIG. 12 illustrates a process flow of an emulated target processor when a validation simulation is performed in a lightweight computer operating system environment, in accordance with an aspect of the invention.

FIG. 13 illustrates a process flow of an emulated target processor when a validation simulation is performed in a lightweight computer operating system environment, in accordance with an aspect of the invention.

FIG. 14 illustrates an exemplary software process for validation in a lightweight computer system environment, in accordance with an aspect of the invention.

FIG. 15 illustrates a signal flow path in a lightweight computer operating system environment, in accordance with an aspect of the present invention.

FIG. 16 illustrates an exemplary computer system for hardware and software validation of target microprocessors and electrical circuits, in accordance with aspects of the present invention.

FIG. 17 illustrates an exemplary system consisting of a target microprocessor, glue logic, I / O hardware and memory co-verified using the present invention.

18 illustrates bus read timing for the exemplary system shown in FIG.

FIG. 19 illustrates bus write timing for the exemplary system shown in FIG.

FIG. 20 illustrates the signal timing generated by the present invention for the exemplary system shown in FIG. 17;

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 UNIX system 2 VSIM environment 3 Internal scheduler 4 Instruction set simulator 5 VHDL simulation 6 Interface 7 Interrupt 8 External component 10 Fabric process 11 Central control process 12 Signal maintainer subsystem 13 Clock generator subsystem 14 Queue maintainer subsystem 15 Display generator 16 Scheduler Subsystem 21 Test Circuit 22 Bus Arbitration Process 23 Global Loop Controller 24 Test Stimulation Process 30 Lightweight Operating System 31 Fabric Process 32 Instruction Set Simulation Process 33 VHDL Process 34 VHDL Process 35 I960 Processor 36 Glue Logic 37 UART 38 Memory subsystem 40 processor 41 video display terminal 42 memory 43 I / O device 44 data link 45 server 46 program library 50 development board 51 communication medium

Claims (25)

[Claims] 1. A method for validating an electronic circuit and a control program targeting the electronic circuit, wherein the electronic circuit and the control program are executed using a predetermined computer language executed in a lightweight computer system operating environment. Simulated, the method comprising: a software model comprising a syntax targeting the lightweight computer system operating environment;
Translating an operation simulation of the electronic circuit; configuring a cycle-accurate instruction set simulation such that the instruction set simulation executes a part of a control program targeting the electronic circuit; Combining a software model with the instruction set simulation to create a system under test that executes in the lightweight computer operating system environment; and inputting a stimulus to the system under test to provide a result to the system under test. A method for validating an electronic circuit and a control program, comprising the steps of: 2. The method of claim 2, wherein translating the behavioral simulation comprises using a plurality of rules to translate the behavioral simulation into a syntax targeted at the lightweight computer system operating environment. The method of claim 1. 3. The method of claim 2, wherein one of the plurality of rules translates a behavioral simulation substitution into an internal variable syntax targeted at the lightweight computer system operating environment. 4. The method of claim 2, wherein one of the plurality of rules translates a behavioral simulation signal substitution into an external variable syntax targeted at the lightweight computer system operating environment. 5. The method of claim 2, wherein one of the plurality of rules translates a behavioral simulation weight point into a weight syntax targeted at the lightweight computer system operating environment. 6. The method of claim 2, wherein one of the plurality of rules translates a behavioral simulation control syntax into a control syntax targeted at the lightweight computer system operating environment. 7. The method of claim 1, wherein configuring a cycle-accurate instruction set simulation comprises configuring a simulation targeting a central processing unit. 8. The method of claim 7, wherein configuring the instruction set simulation comprises mapping an address range to represent a hardware device connected to the target central processing unit through glue logic. the method of. 9. The method of claim 7, wherein configuring the instruction set simulation comprises emulating a cache operation of a target central processing unit. 10. The method of claim 7, wherein configuring the instruction set simulation comprises emulating instruction scheduling of a target central processing unit. 11. The method of claim 1, wherein the syntax targeting the lightweight computer system operating environment includes a portion of an interface library targeting the lightweight computer system operating environment. 12. A computer system for validating an electronic circuit and a control program targeting the electronic circuit, wherein the electronic circuit and the control program execute a predetermined computer language executed in a lightweight computer system operating environment. Simulated using: a computer means for managing the state of all global signals; a software means for generating a clock signal; a software means for managing a process queue to wait for an event; and a predetermined timing interval. A computer system, comprising: software means for executing at least one process in; and software means for controlling central processes. 13. The computer system according to claim 12, further comprising software means for driving a display for displaying a state change with respect to the global signal. 14. A computer system for validating an electronic circuit and a control program targeting the electronic circuit, wherein the electronic circuit and the control program execute a predetermined computer language executed in a lightweight computer system operating environment. Simulated using the computer system, comprising: a processor; and a memory containing software instructions adapted to enable the computer system to execute a central control process, wherein the central control process comprises: A signal maintainer subprocess for managing the state of a plurality of global signals; a clock signal generator subprocess for generating clock signals used by a software model and an instruction set simulator; and a software model. Maintainer sub-process for managing a process queue that waits for events from the CPU and the instruction set simulator; a timer sub-process for generating a predetermined timing interval; And a controller sub-process for controlling execution of the timer sub-process. 15. The computer system according to claim 14, wherein said predetermined timing interval simulates a time interval of 1 nanosecond or more. 16. The computer system of claim 14, wherein said predetermined timing interval simulates a time interval of less than one nanosecond. 17. The computer system according to claim 14, further comprising a global display sub-process for displaying a state change with respect to the global signal. 18. A computer system for validating an electronic circuit controlled by a microprocessor and a control program targeting the microprocessor, wherein the electronic circuit, the target microprocessor and the control program are provided in a predetermined computer language. And simulated using a predetermined interface library, the computer system comprising: a software model of the electronic circuit in which a function of the electronic circuit is translated into a predetermined computer language syntax including a part of the predetermined interface library; The target microprocessor, wherein an instruction set simulation simulates instructions executed by the target microprocessor when executing a portion of the control program. And a central control process that couples the software model of the electronic circuit and the instruction set simulation of the target microprocessor to one another, the central control process comprising: A signal maintainer subprocess for managing; a clock signal generator subprocess for generating a clock signal used by the software model and the instruction set simulator; and a queue for managing a process queue that waits for events from the software model and the instruction set simulator. A maintainer subprocess, a timer subprocess for generating a predetermined timing interval, at least the signal maintainer subprocess, a clock signal generator subprocess, and a queue subprocess. Computer system, comprising a control sub-process that controls the execution of the maintainer subprocesses and timer subprocesses, the. 19. The computer system according to claim 18, wherein the predetermined timing interval simulates a time interval of 1 nanosecond or more. 20. The computer system of claim 18, wherein said predetermined timing interval simulates a time interval of less than one nanosecond. 21. The computer system according to claim 18, further comprising a signal display sub-process for displaying a state change for the plurality of global signals. 22. An executable program for a computer system for validating an electronic circuit and a control program targeting the electronic circuit, wherein the electronic circuit and the control program are simulated using a predetermined computer language. The executable program, when executed on a computer, generates a first executable code portion that manages a state of a plurality of global signals; and, when executed on a computer, generates a plurality of clock signals. Generating a second executable code portion, a third executable code portion that manages a process queue that waits for an event when executed on the computer, and a predetermined timing interval when executed on the computer. Fourth executable code portion to be executed on a computer And at least a fifth executable code portion for controlling execution of the first, second, third and fourth executable code portions when the electronic circuit and the control program are validated. Executable program for a computer system that does 23. A method for deriving a cycle-accurate instruction set simulation of a target processor for verification of a system including an electronic circuit and a control program for controlling the electronic circuit, wherein waiting for completion of a memory operation. Modeling the interaction between memory and cache as a sequence of signals on a data bus such that the target processor is stalled until the cache is loaded by the processor; and deriving from an internal data flow model of the target processor Using an internal bus width and timing to fill the instruction pipeline and delay by an appropriate number of clock cycles, and executing an instruction decode cycle of the target processor, Interpreting the instructions available for execution and determining if the scheduled instruction implements pipeline disconnection, and if the scheduled instruction implements pipeline disconnection, a future instruction Stalling the scheduler for each; transferring the scheduled instructions to the appropriate instruction pipeline or hardware component; calculating the cycle execution time for each instruction; and determining if there is non-deterministic timing. Determining; outputting the result available at the end of the calculated execution cycle; and using the signal interface with the emulated control register of the target processor to schedule the interrupt handler for the next cycle. Method of deriving a set of instructions simulations characterized by having the steps of: determining whether to be a ring. 24. The step of determining whether there is nondeterministic timing includes: evaluating the end condition in each clock cycle if there is nondeterministic timing; and determining whether there is no nondeterministic timing. The method of claim 23, comprising: propagating a resource assignment. 25. The step of determining whether the scheduled instruction implements pipeline disconnection comprises, if the scheduled instruction implements pipeline disconnection, stalling the scheduler for future instructions. The method of claim 23, comprising the step of: