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

Abstract

<P>PROBLEM TO BE SOLVED: To use a light-weight operating system on a message base as a base for cooperative simulation of hardware/software. <P>SOLUTION: Electronic circuits are mapped in a software process and communicate status changes through message transfer primitive as a hardware process. A signal maintainer 12 manages statuses of all global signals. A clock signal used by a hardware process and an instruction set simulator is generated by a clock generator 13, and a process queue waiting for an event is managed by a queue maintainer 14. A scheduler 16 executes a process at every nanosecond tick, and a central control process 11 controls the execution of the processes. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a method and apparatus for hardware and software co-design and co-validation using a lightweight message-based operating system. In particular, the electrical circuit design is mapped to a software process, and 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 control software elements and mapped electrical circuit elements to be co-simulated and evaluated for their interaction. The present invention relates to a co-validation method that provides a software and hardware co-simulation environment, a computer system that implements the co-simulation method, and a computer that includes software instructions that implement the co-simulation method. It is implemented as a software environment that supports program products and software simulation and instruction set simulation of hardware elements. The present invention is also realized as a method for developing an instruction set simulator for a target central processing unit (CPU).

  The following references all provide useful background information about the indicated subject matter relating to the present invention.

PTOLEMY is a project that studies heterogeneous modeling, simulation and design of concurrent systems. The current implementation is implemented in the JAVA (registered trademark) programming language. The PTOLEMY website at http://ptolemy.eecs.berkeley.edu contains more detailed information about PTOLEMY.

POLIS is a software program for hardware / software co-design of embedded systems. POLIS utilizes a framework developed for PTOLEMY. The POLIS website at http://www-cad.berkeley.edu/~polis/ contains more detailed information about PTOLEMY.

  The following is a description of some subjects that provide a suitable basis for understanding the present invention.

  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 an environment suitable for embedded or dedicated applications, but not for applications that are poorly designed or intended to produce malicious consequences. . In the past, this has limited the use of microkernel systems for soft or hard real-time embedded code.

  Currently, the demand for good hardware-software co-simulation tools is caused by three main factors:

1. Increase in size and complexity of computer systems (both hardware and software);
2. Requirements for cost-effective SOC (system-on-a-chip) implementation;
3. Reuse IP (intellectual properties) to maximize return on investment.

  Currently, it is generally recognized that an effective solution to the above factors requires both hardware and software components. This opened up the design space to “co-design” requirements. If many tasks can be performed either by general purpose central processing units or by dedicated (or programmable) hardware, how is the most effective partitioning done? The design step operates in the following feedback loop.

1. Do 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 operational constraints;
4). Correct errors and perform possible subdivision to meet design criteria;
5. Complete synthesis of hardware components and software optimization;
6). Perform a low-level (accurate timing) simulation of all components.

  7. Iterate towards an acceptable or optimal solution.

  A typical approach to this procedure that has been adopted 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. The PTOLEMY / POLIS environment provides a framework for an integrated simulation tool that allows inspection of a given partition and provides a final code generation phase that produces synthesized results.

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

  From the programmer's point of view, even a “good” ESTEREL generates a “bad” C. In fact, ESTEREL generates code very close to FORTRAN in its programming style (simple if-then test and goto branch). This places a heavy load on the C compiler just by generating a certain amount of machine code and limits the ability to perform more global optimization. This condition also forces software engineers to discard existing IPs and recode useful and tested (and trusted) algorithms. Needless to say that there is no support for object-oriented technology, software partitioning is a lower class in this hierarchy, since there are no high-level features of modern languages.

  Because there is no language that has the expressive power of both modern programming languages (eg, C ++) and high-level hardware design languages, there is considerable resistance to even trying to address a unified co-design environment.

  Other implementations of the PTOLEMY framework are possible and may help solve the above problems. Such systems limit available design space and eliminate optimal results if existing code, including commercial IP, which may not be available in source code form, cannot be used. There is a possibility. If the main problem (for cost or time-to-market reasons) is the reuse of existing “legacy” IP that has already been split into hardware and software, the design space change. Components that exist in multiple ways, such as C code or VHDL, can be easily conceived. In this case, the problem is as follows.

1. Is there an existing set of IPs that meet design constraints when used together;
2. How these processes, if present, must be “glued” so that control signals and data flow correctly;
3. If it does n’t exist, what ’s wrong? What is the necessary approach to solve this problem?

  These issues focus on the interface between existing designs and the overall correct operation of the entire system, and therefore focus on co-simulation and co-verification. is there.

  With the exception of dynamic subdivision, programmers have the freedom to express their ideas in the language (single language or languages) that best suits their needs. Additional “glue” can be provided as hardware entities (eg, address decoding logic) or software modules (eg, drivers for off-CPU hardware chips). What is needed at this stage is a rapid feedback system to evaluate the design.

  Again, commercial co-simulation tools don't offer everything they promise. Sometimes this "tool" is just an integrated framework that can connect a commercially available simulator. This saves a lot of important work, and if this provides a “plug and play” framework, the best tools can be connected to solve each requirement. However, if there is no direct communication between the individual components and thus no direct feedback, this approach may eventually fail as the design space increases. Such an implementation is currently characterized by an iterative “sequential approximation” method that provides traces 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 includes a re-targetable tool that may be useful across a set of problems. Is to be placed.

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

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

2a. Software processes tend to be event driven. That is, the software process waits for some other process or 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 that appears in the input, performs some processing, and waits for the next event.

3a. Events between software processes typically proceed by sending a “signal” to another process through a scheduler where the sender prepares a “packet” (data area) of information and acts as a data synchronization point;
3b. Events between hardware processes are typically signaled (eg, chip select) through glue logic (eg, latches) where the sender provides a value on a set of “data” wires (eg, a bus) and acts as a data synchronization point. Proceed by sending a (chip-select) signal to another chip.

4a. In a single CPU system, there is no true software parallelism, and apparent parallelism is done by the operating system switching between tasks;
4b. In all hardware except for the most obvious hardware, there is true parallelism, which is because independent hardware units receive a distributed clock and each performs its own task during that clock cycle. Achieved.

5a. In a properly designed software system, individual processes operate independently except for predefined inter-process communication paths (which can also be dynamically assigned);
5b. In a well-designed hardware system, each instance of a hardware process can be determined by a well-defined communication path using signals and wires (this can be determined by settings in "glue logic") Except for).

  Tools for simulation of VHDL code already exist (eg Model Technologies VSIM). Such tools operate by emulating the behavior of individual entities within the entire system, and based on item 5b above, instead of hardware parallelism, software-type parallelism (ie sequential execution) )I do. This must be done by checking each individual process state (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 operates as a single process on the workstation, and an internal scheduler tracks the state of its internal VHDL process.

  FIG. 1 illustrates a conventional VHDL simulation. Typically, the simulation environment is executed within a multiprocessing operating system (eg, UNIX® 1). The simulation components are an instruction set simulator 4, a VHDL simulation 5, and an interface 6 for passing signals. The VSIM environment 2 uses the internal scheduler 3 to control simulation components. As shown in FIG. 1, the interrupt 7 must be passed from the VHDL simulation 5 through the interface to the instruction set simulator. Interaction with the external component 8 must be passed to the VSIM environment 2 through the internal scheduler 3, and the VSIM simulator 2 must pass data through the UNIX system 1. The internal scheduler 3 is an essential component of a conventional simulation system because the entire VSIM environment 2 appears to the operating system as a single process running on the UNIX operating system shell 1. At the same time, multiprocessing support for the UNIX operating system 1 is required to allow this process to interact with other external components 8 of the system.

  Real systems are often much more complex than what a simple “sum of parts” approach shows, and system integration issues can reveal design defects that are overlooked during individual design phases . This is particularly apparent when designing non-deterministic systems (eg, processing of data received over best effort network links). The design space must also take into account the various errors that can occur (packet loss, data corruption, real-time deadline exceeded, etc.) and strategies for handling the errors when they actually occur.

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

  Therefore, in such a system design, a simulation shorter than the data of one entire GOP is likely to overlook an illegal error processing situation. In fact, it is difficult to consider a test strategy that does not require data on the order of seconds and a simulated run down to 1 minute. In such a system, there will be at least two “preliminary” steps for any design. The first step is confirmation that the design handles real-time constraints of full speed MPEG data. The second step is to find out how well it handles error conditions over a much longer period.

  There is a general tradeoff between a more powerful (eg, cost and energy) CPU and additional custom hardware (eg, FPGA or ASIC). Using the above MPEG example, if there is no hardware support in the MIPS processor, display exceeding 10 frames / second is impossible. However, in the case of an Intel MMX level processor, it is possible to display more than 30 frames without additional hardware. Such an observation is a powerful objection to using a single design language for both hardware and software. This is because this performance can only be achieved by coding the main routines directly in Intel assembly language. It is almost meaningless to “make a CPU” a potential candidate by ignoring a function that can correctly solve the problem at hand.

  The present invention overcomes the above problems and limitations of the prior art in view of the above circumstances.

  Additional 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 a first aspect of the present invention, there is provided a computer system that performs validation of an electronic circuit and a control program that targets the electronic circuit, wherein the electronic circuit and the control program provide interprocess communication using messages. Simulated using a predetermined computer language executed in a lightweight operating system environment constructed on the basis of a microkernel, the computer system includes signal management means for managing the state of all global signals, and the electronic circuit. A clock generation means for generating a clock signal used by the software model of the system and an instruction set simulator for executing a part of the control program, and a process queue for waiting for an event from the software model and the instruction set simulator Queue management means for managing, and scheduler means for executing a component including the software model and the instruction set simulator for each predetermined timing interval, the signal management means, the clock generation means, and the queue management Means and a scheduler means are subsystems controlled by a central control process executed by the computer system, wherein the electronic circuit is mapped to a process executed by the lightweight operating system, and elements of the mapped electronic circuit The state change between them is modeled by message passing of the lightweight operating system.

  According to the second aspect of the present invention, 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 realized. The method includes modeling the interaction between the memory and the cache as a sequence of signals on the data bus. Here, the target processor is stalled until the cache is loaded by waiting for the completion of the memory operation. In addition, this method uses a sequence of signals derived from the internal data flow model of the target processor and uses the internal bus width and timing to fill the instruction pipeline and delay by an appropriate number of clock cycles. Including that. In addition, the method includes executing an instruction decode cycle of the target processor to interpret instructions available for execution. In addition, the method determines whether the scheduled instruction implements pipeline disconnection and if the scheduled instruction implements pipeline disconnection, stalls the scheduler for future instructions. including. Further, the method includes transferring the scheduled instruction to an appropriate instruction pipeline or hardware component and calculating the cycle execution time for each instruction. Furthermore, this method determines whether there is non-deterministic timing. Further, the method includes outputting a result that is available at the end of the calculated execution cycle. The method further includes using the signal interface along with the emulated control register of the target processor to determine whether the interrupt handler should be scheduled for the next cycle.

  According to the second aspect of the present invention, an executable program for a computer system that performs the validation of 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 operating system environment constructed based on a microkernel that provides interprocess communication by messages. The executable program has a first executable code portion that manages the state of a plurality of global signals. The executable program further includes a second executable code portion that generates a plurality of clock signals. Further, the executable program has a third executable code portion that manages a process queue that waits for an event. Furthermore, the executable program has a fourth executable code portion that generates a predetermined timing interval. The executable program further includes a fifth executable code portion that controls execution of at least the first, second, third, and fourth executable code portions when executed on a computer; An electronic circuit is mapped to a process executed in the lightweight operating system, and a state change between elements of the mapped electronic circuit is modeled by message passing of the lightweight operating system.

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

  Before describing the features of the present invention, some details are discussed with respect to the prior art to assist in understanding the present invention and to provide the meaning of various terms.

  As used herein, the term “computer system” has the broadest possible meaning and includes stand-alone processors, networked processors, mainframe processors, and processors in a client / server relationship. However, it is not limited to these. The term “computer system” should be understood to include at least a memory and a processor. Generally, the memory stores at least a portion of the executable program code at various times, and the processor executes the instructions that make up the executable program code.

  In this specification, the term “embedded computer system” includes, 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, an instrument that uses a central processor to control its functions can be said to have an embedded computer system. The embedded central processor executes object code instructions stored in memory. An embedded computer system can have a cache memory, input / output devices, and other peripheral devices.

  As will be appreciated, the terms “predetermined operation” and “computer system software” mean substantially the same for the purposes of this specification. For the implementation of the present invention, the memory and processor need not be physically located at the same location. That is, it is anticipated that the processor and memory will be in physically different devices or in different geographical locations.

  As used herein, "media" or "computer-readable media" refers to diskettes, tapes, compact disks, integrated circuits, cartridges, remote transmission over communication lines, or other similar Computer-usable media can be included. For example, to distribute computer system software, suppliers (suppliers, etc.) can also provide diskettes and provide instructions to perform certain operations in some form over satellite transmission, direct telephone links, or the Internet. It is also possible to transmit.

  As will be appreciated, the computer system software can be “written” on diskette, “stored” on an integrated circuit, or “transmitted” over a communication line. For purposes, a computer usable medium is said to “have” instructions to perform a predetermined operation. That is, the term “comprising” is intended to include the above and all equivalent ways in which instructions for performing a given operation involve a computer-usable medium.

  Thus, for simplicity, the term “program product” is used hereinafter to refer to a computer usable medium having instructions (as defined above) for performing a predetermined operation in any form.

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

  Because of the remarkable similarity between VHDL processes and processes running on lightweight operating systems, it becomes possible to write VHDL processes as separate software processes using the lightweight operating system and schedule events. . Preferably, the lightweight operating system is built on a small microkernel that provides message-to-process communication. The message is an operation code having an associated parameter, and expresses the event-driven model of item 3a above. Preferably, the message is a global data definition that is mapped to a system structure that is passed between processes. Event semantics are application defined. In this case, the inter-process message can also be used to notify the process about changes in the VHDL signal value. Preferably, the lightweight operating system provides a group 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 supplied by the microkernel core, the process can also define its own message code and parameters to implement application specific interfaces. In that case, this interface is grouped into a set of routine calls implemented in a shared library.

  Next, with reference to FIG. 2, the feature of the present invention for performing the validation of the electronic circuit and the software targeting the circuit will be briefly described. The electronic circuit and control program are simulated using a predetermined computer language that runs in a lightweight computer system operating environment. In S0900, the elements of the computer hardware behavior, modeled by one or more circuit description languages, are translated into the selected lightweight operating system syntax and methods. In S1000, the behavioral description of the electronic circuit design is translated into a software model having the above syntax targeting a lightweight computer system operating environment. In S1100, the instruction set simulator is configured in a predetermined computer language so that the instruction set simulation executes the part of the control program targeted for electronic circuit design. At S1200, the electronic circuit design software model is combined with the instruction set simulation to create a system under test to be executed in a lightweight computer operating system environment. Finally, in S1300, a stimulus is input to the test target system to cause the test target system to output a result.

  Next, the feature of the present invention for performing the validation of the electronic circuit and the control program will be described in more detail.

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

  VHDL variables are similar to C variables. That value is retained when control leaves the process. However, the scope of that name is local to the process in which it was instantiated. Thus, the present invention replaces VHDL variables with C static variables. The bit vector type can be included in the C unsigned integer type up to 32 bits wide (in the case of a processing system operating on a 32-bit processor). Both individual bit access and slice operations can be performed with shift and mask operations.

  Signals are used to send values between processes. The scope of the signal value is global throughout the system, but its name is local to a particular process. In the present invention, multiple copies of a process can be instantiated with the same local signal name (eg, Chip_Select) that accesses different signals (eg, UART_A_Chip_Select, UART_B_Chip_Select). Simple signal values such as “0” and “1” and slice values are easily expressed as bit patterns in the machine. VHDL supports logic values outside this range, such as “Z” and “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 for that signal is met. Determining conditions for a VHDL process to be “operational” is one of the functions that must be implemented in language syntax mapping.

  The VHDL language also provides a syntax that controls 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, the central process in the simulation system handles the tracking of the value of each signal and the distribution of signal changes among the processes monitoring that value. When this process is referred to in the following description, it will be referred to as the “fabric” process. The present invention uses lightweight operating system message passing operations to pass signal value changes and other syntax passing between processes. For example, the VHDL syntax “wait for N ns” is expressed by a message having the following two user-defined parameters.

Msg WAITFOR {int CLOCKT; int TICKS;}
The TICKS parameter provides 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 microkernel core functions.

  Signals are named using strings, but are referenced using opaque pointers. The following interface routines implement the mapping between signal names and references. In addition, the interface includes shared library routines that notify the central control processor about signal value changes and wait for signal value changes.

  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 * SIGNAL): This routine returns an opaque pointer that can be used to reference the (globally named) SIGNAL parameter. This routine performs a string comparison against all registered names and returns a signal reference if it exists. If the signal is not already in the list, it is created with an initial value of zero. In this way, 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 SYM parameter, if it has a defined (ie non-floating tristate) value .

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

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

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

  The fabric process must know whether the signal is operating in a simple binary domain or using multi-valued logic. This domain is determined by the interface routines used to send signal changes across the system, and the processor allows multi-valued logic domains to be represented. Individual C header files (eg, ieee.h) that contain a representation of the extension values required for each multi-valued logical domain can encapsulate individual logical domains (eg, std_logic package).

  All Wait routines of the following form take one of the following three values for the CLOCKT parameter: 0 means asynchronous operation (schedule the process as soon as the specified condition is met). -1 schedules the process if the condition is met on the falling edge of the process clock signal, +1 schedules the process if the condition is met on the rising edge of the process clock signal.

  Void WaitClk (int CLOCKT): This routine suspends the current process until the next rising or falling edge of the 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, int CLOCKT)
Void WaitUntil2c (void * SYM1, int OP1, uint VALUE1, void * SYM2, int OP2, uint VALUE2, int CLOCKT)
Void WaitUntil3c (void * SYM1, int OP1, uint VALUE1, void * SYM2, int OP2, uint VALUE2, void * SYM3, int OP3, uint VALUE3, int CLOCKT): These routines can be 1, 2 or 3 Wait for one or more of the conditions to be true (at the same time). 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 interprocess 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 preprocesses each signal name. In S1010, for each signal, the present invention generates an internal variable by appending the prefix phrase “signal_” to the name. Therefore, the opaque pointer to the signal CHIP_SELECT is “static void * signal_CHIP_SELECT”. This new signal name is then bound to the signal reference when the process is instantiated. The instantiated signal name need not be the same as the signal name. For example, signal_CHIP_SELECT can be instantiated as follows:

signal_CHIP_SELECT = fabric_find_signal ("UART_A_CHIP_SELECT");
In the VHDL body, the preprocessor modifies the reference to the signal CHIP_SELECT to refer to the variable signal_CHIP_SELECT. When instantiated, the variable signal_CHIP_SELECT is coupled to the UART_A_CHIP_SELECT signal.

  In S1015, it is determined whether there are more signal names to be preprocessed. If there is, the next signal name to be preprocessed is acquired in S1018, 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, when the process control flow reaches S1020 to S1060, what type of operating language syntax is used, and how that operating language is targeted to a syntax targeting a lightweight computer operating system. Determine whether to translate. Preferably, the working language used is VHDL and the syntax used for translation is C-based.

  In step S1020, it is determined whether the operation language syntax to be translated is assignment to an internal variable. In the case of assignment to an internal variable, the process control flow proceeds to S1025. If it is not an assignment to an internal variable, 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 completion of 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 assignment to an external variable. In the case of assignment to an external variable, the process control flow proceeds to S1035. If it is not assignment to an external variable, the process control flow proceeds to S1040.

  Most interface routines are accessed through preprocessor macros designed to make VHDL-C translations easier to read and understand. These macros handle the conversion between signal names and variable names. In the following macro, “signal” means the name of the VHDL signal. These names are preprocessed to the opaque type reference above.

Uint GetSignal (signal NAME): This macro returns the current value of the signal named NAME;
Void Signal (signal NAME, uint VALUE): This macro sets the VALUE of the signal NAME to its (32-bit) value;
Void SignalZ (signal NAME): This macro sets the value of the signal NAME to the IEEE Z value.

At S1035, translation from VHDL substitution to 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 completion of this translation, the process control flow returns to S1020.

  In S1040, it is determined whether the operating language syntax to be translated is a wait point. If it is a wait point, the process control flow proceeds to S1045. If it is not an assignment to an external variable, the process control flow proceeds to S1050. Similar to the assignment to the external signal, the wait 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 have a condition 1, 2 or Allows the process to wait until it appears in the three signals, and allows the process to be scheduled according to the required clock synchronization.

In S1045, the translation of the VHDL syntax is performed as follows:
VHDL: wait until (startn = '0');
Macro: WaitUntil (startn, EQ, 0);
C: WaitUntilc (signal_startn, EQ, 0, 0);
After completion of the weight point translation, the process control flow returns to S1020.

At S1050, the VHDL control syntax is translated into an equivalent C language operation. This translation may include additional interface calls. As an example, the translation of the 'if' control syntax is done as follows:
VHDL: if (resetn = '0') then
Macro: if (GetSignal (resetn) == 0) {
C: if (fabric_read_signal (signal_resetn) == 0) {
After the completion of the translation of the control syntax, the process control flow returns to S1020.

  Referring to FIG. 4, it is determined in step S1060 whether there are more operating language constructs that need to be translated. If there is more, the process control flow proceeds to S1020. If there are no more, the conversion process is complete.

  With these few basic transformations, it is possible to translate working VHDL code into C, compile that code, and 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 simulation depending on whether the original design is formulated in VHDL or 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 indirection and advanced data structures, but otherwise serves as a starting point for retargetable 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 invention, the software component of the design can be simulated using an instruction-set simulator (ISS) of the target processor. In general, such a simulator has the following three elements.

1. Target processor operation and register emulation;
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. An interface to external hardware emulation that represents the devices present in the system under test.

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

  Element 1 requires software to emulate the registers of a processor with a 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. Furthermore, operations on registers must also be correctly emulated, including the generation of status and error information caused by such operations.

  Element 2 requires an interface to the foreign 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. ISS emulates local RAM using one of two methods. When 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. Thereby, it is possible to emulate a machine having more physical memory than an actual machine. This also provides a re-checkable memory checkpoint in case of 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 hardware model. According to a first aspect of the invention, a set of modules representing the operation of external hardware is linked to an ISS executable file. External devices are assumed to be mapped to 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 LENGTH): 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 was presented on its input address line.

  Void uart_store (int ADDRESS, int LENGTH, uint VALUE): This routine emulates a write request from the processor to the device. This routine must act as if the ADDRESS parameter was 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 a hardware component to generate an interrupt signal to the processor.

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

  Processors can operate with hundreds of megahertz clocks, but such speeds are 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 restriction on software design. This is because the data cache must be bypassed to access such data (although that 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 complete in a single cycle.

  The basic interface is provided through three routines called from individual instruction emulations as needed:

  Void fetch (iblock * IN, uint ADDRESS1, int NBYTE, uint * ADDRESS2): This routine loads NBYTE bytes from (emulation) address ADDRESS1 and stores (stores) them in (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 (emulation) address ADDRESS1 into the (4 words) instruction pipe starting at index IX. The routine first searches the instruction cache and then proceeds to memory to fill the 8-word cache line if no data is found.

  Void store (block * IN, uint ADDRESS, int NBYTE, uint * VAL): This routine writes NBYTE bytes from (machine) address VAL to (emulation) address ADDRESS. 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 the number of cache hits, the number of cache misses, and the number of accesses to non-cache memory.

  When timing measurements are not required, the simplest (and fastest) simulation of the CPU is to fetch and decode instructions one by one and complete the execution of each instruction before proceeding to the next instruction. Using the Intel I960 processor chip as an example, ISS provides sufficient emulation of cache operations. It supports both instruction cache and data cache and uses memory controller registers (mcon0-mcon15) to determine whether to cache 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 directly accesses RAM emulation.

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

  The target system is started from the starting entry point. The target system clears the blank storage area to zero, performs a controlled processor reset, and sets the internal control register. The initialization routine creates four processes and calls the hardware initialization routine for 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 open regular I / O files (stdin, stdout, and stderr) to the console multiplexer process and then calls the printf routine to format the string and send the message to the console. send. This causes a context switch to the console, prepending the process name to the string and forwarding it to the UART process.

  In response to the Tx-Available interrupt generated by the hardware, the UART transmits a character string to the hardware one character at a time. After all characters have been sent, a message is returned to the application through the console process, after which the application is terminated.

  Operating the ISS at this level can show a certain degree of reliability that the software is operating correctly. For example, software that controls the operation of a UART with an application correctly interprets status flags supplied by the chip to indicate when the CPU can write characters. Furthermore, the routines are called in the correct order with the correct parameters and linkage. It is also reasonable to assume that there is no detectable memory corruption and no access to the outside of the defined memory area.

  However, even if the simulator is operated in this mode, actual information regarding the execution time cannot be obtained. This is because every instruction assumes only one clock tick. Run the instruction timing mode and print out the pipeline trace to show where the instruction cycle is going.

  Using ISS also allows access to information that is not normally available using an in-circuit emulator. For example, it is possible to determine the maximum depth of the register cache actually used, or to count the number of frame spills along with cache hit statistics.

  It is also possible to count the number of times each instruction has been executed. Such data is very useful in determining processor tradeoffs, especially when manufacturing highly integrated SOCs. This is because, for example, the number of gates is reduced by a smaller number of branch instructions. Although the I960 architecture provides “predictive branch” instructions, the compiler does not use them. These instructions can be removed, or another compiler that can use these functions can be considered.

  Even this level of detail is far from cycle accuracy. This is because it assumes a one-cycle memory model where all bus transactions (including multiword operations) are completed within the same cycle. In order to accurately model timing at this level, a precise model of the system data bus and its devices is required, which requires creating a complete co-simulation environment.

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

  However, this feature ignores the following three main elements when selecting a particular CPU:

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

  2. The CPU may implement internal parallel processing across multiple dedicated units so that bus operations can be performed concurrently with register-to-register operations, assuming no resource usage conflicts.

  3. Access to internal cache memory, external RAM memory and devices may have very different response times. The normal effect of this is simply delayed execution, but in certain critical cases (for example, determining the processing order of tasks with relative timing of incoming interrupts), the overall performance is significant. May play a role.

  Next, a method for deriving a cycle-accurate instruction set simulation of a target processor for verification of 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 5 I960 instruction paths;
• Register scoreboarding to ensure that results are not used before they are available;
Implementation of pipeline disconnection instructions such as branches and calls (calls);
• Pipeline installation for instructions that take longer than a single clock time to complete.

  Referring to FIG. 6, the instruction pipeline is examined at the beginning of each processor clock tick. If the pipe is not completely filled, the ifetch routine is called to fill it. If the instruction needed to fill the pipe is not found in the instruction cache, the ifetch pseudo-instruction is scheduled. This instruction is executed in the CPU bus control unit (BCU) and memory path (and therefore may be delayed if these units are busy). As a result, when this instruction is executed, 8 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. Some I960 instructions occupy more than one word, so an incomplete instruction may be present in the pipe, in which case it cannot be decoded (as in the second callx instruction in FIG. 6). . The instruction is coded only once and the decoded form is stored in the data structure. Decoding also involves identifying internal processing units, pipelines and register resources needed to schedule instructions.

  The resources being used by the CPU are represented by a scoreboard structure for each tick. Instructions are fetched sequentially from the pipeline and scheduled one by one. Scheduling is either when an instruction requests a resource that has already been committed during this tick, or when an instruction causes a pipeline disconnect, or when there are no more decoded instructions in the pipeline. Stop.

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

  When scheduling is complete, the instructions that enter the unit are executed in the current tick. An instruction that takes longer than a single tick to complete propagates its resources to subsequent ticks when the pipeline stalls.

  Referring to FIG. 6, the lda instruction can be scheduled in the current tick, locking the AGU, the MEM path, the frame pointer as the source register, and the stack pointer as the destination register. This prevents the next callx instruction from being scheduled, so the next callx instruction remains in the pipe. Since the lda instruction takes multiple cycles to execute, the AGU stalls at the next tick, and resources from this instruction are copied to the scoreboard as long as the instruction occupies the AGU. When lda completes, it releases its resources and the callx instruction can start. The next callx (which can now be fully decoded) is not scheduled for two reasons. First, because of a resource crash on this callx, but secondly, the callx instruction causes a pipeline disconnect (and a transfer to a new instruction pointer).

  Referring to FIG. 6, the emulation of the lda instruction is not particularly complicated. Since the instruction decoding routine has already evaluated the destination register and memory operands, the routine simply updates the location (in ISS memory) holding the register. The result 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 co-simulated.

  The process of modeling the target processor with cycle accuracy will be described with reference to FIGS. In step S1105, it is determined whether the target processor has an onboard cache memory. If the target processor has on-board cache memory, the process flow proceeds to S1115, and an algorithm for controlling on-board cache access is modeled. If the target processor does not have on-board cache memory, the process flow proceeds to S1120.

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

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

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

  In S1145, it is determined whether the target processor has a multipath architecture. If the target processor does not have a multipath architecture, the process flow proceeds to S1165. On the other hand, if the target processor has a multipath architecture, an algorithm is generated in 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 returns to S1140 and the parallel instructions are executed. Otherwise, the process flow proceeds to S1165.

  Referring to FIGS. 8 and 9, in S1165, it is determined whether the simulated instruction is a multi-cycle instruction. If the simulated instruction is a multi-cycle instruction, a scoreboard is prepared at S1170 as described above. Next, in S1175, resources are propagated as described above, and the process flow proceeds to S1180.

  In S1180, it is determined whether non-deterministic timing exists. If non-deterministic timing exists, end is evaluated. In S1190, an algorithm is generated that determines termination conditions for non-deterministic timing operations in the current machine state. Depending on the architecture of the target processor, this may include computations based on values in the emulated machine registers, and may also include generating code that examines the state of external signals. In S1192, the end condition is checked, and if the instruction has not ended, the process flow proceeds to S1175. If the instruction is finished, the previously propagated resource is cleared and the instruction simulation is complete.

  With reference to FIG. 10 to FIG. 13, execution of system covalidation including an electronic circuit and a control program for controlling the electronic circuit will be described. In S1310, a stimulus is input to the system under test. In step S1315, it is determined whether the CPU is “operable”. If so, the process flow proceeds to S1340. If not, the target processor is stalled at S1320 and the instruction is loaded into the emulated cache memory at S1325. In S1330, it is determined whether the cache memory is loaded. If the memory is 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 target processor's internal data flow model. Referring to FIG. 11, at S1345, a delay based on a predetermined number of clock cycles is performed to emulate the internal data bus action 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 the instructions available for execution. This instruction decode cycle is executed as described above.

  After the internal decode cycle of the target processor is 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 requested, the process control flow proceeds to S1370.

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

  Referring to FIG. 12, it is determined in S1380 whether non-deterministic timing exists. If non-deterministic timing exists, in S1390, an algorithm for determining the termination condition generated in S1190 is executed at the end of each clock cycle.

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

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

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

  Next, a detailed description will be given of causing a test target system to output a result 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, the global loop controller 23 is used as an example to continually repeat the designed test cycle to fully work with the co-simulated hardware and software. The test stimulus process 24 provides stimulus from the “outside” to the system under test. Another function of the test stimulus process 24 is to input erroneous inputs to the system under test in order 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. The 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, can be several processes depending on the complexity of the circuit design.

  In addition, the signal display process allows stepping and watching the effect of individual statements on the global state.

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

  As a first step, a hardware operation description 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 fabric process and stimulus generation program required for the simulator are the same. As a second step, the programming language source file is compiled into object code for a processor running a lightweight operating system. As a third step, these files are linked with the object code for the lightweight operating system to form a complete execution environment. As a fourth stage, the executable file is loaded into the system where the simulator is executed. As a fifth step, the simulator is run under the control of a lightweight operating system and the output is observed.

  Next, with reference to FIG. 14, a computer system for co-validation of an electronic circuit and a control program targeting the electronic circuit will be briefly described. The electronic circuit and control program are simulated using a predetermined computer language that runs in a lightweight computer system operating environment. The computer system also uses the above routine. After completion 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 instruction set simulator, and a software model and instruction set simulator. A queue maintainer subsystem 14 that manages a process queue that waits for an event, a scheduler subsystem 16 that executes at least one process at a predetermined timing interval, at least a signal maintainer subsystem 12, a clock signal generator subsystem 13, a queue And a central control process 11 that controls the execution of the maintainer subsystem 14 and the scheduler subsystem.

  In addition to the microkernel support process, the computer system has a fabric process 10, an instruction set simulation process, and processes that represent hardware components and a stimulus system, all of which operate in conjunction with each other. The central control process 11 of the 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) a clock generator 13 for generating a clock signal;
(C) a queue maintainer 14 that manages a queue of processes that wait for an event;
(D) a scheduler 16 that executes each active process for each nanosecond tick;
(E) A display generator 15 that drives a display showing signal changes to the user.

An example of a test stimulus is a signal that indicates the availability of data on the external interface. The stimulus can also simulate error conditions, such as parity check errors generated by ECC memory.

  Referring to FIG. 15, the entire simulation environment operates as a plurality of processes within the lightweight operating system 30. Individual processes include a fabric process 31, an instruction set simulation process 32, and VHDL processes 33,34. The VHDL processes 33, 34 have a one-to-one correspondence with the instantiated hardware process of the modeled hardware. All signal interactions 35 pass through the fabric process 31 as messages scheduled by the operating system 30.

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

Problem 1: If two processes are operational and change the value of a signal during their execution, the result may depend on the order in which the processes are executed. For example, if the signal "test" has the value '1' at the beginning of the run,
Process 1: if (test = '1') then test <= '0'; end if;
Process 2: test <= '1';
If process 1 is executed before process 2, the (simple) result is that "test" is set to '1' at the end of execution. If process 2 is executed before process 1, the result is that "test" is set to '0' at the end of execution.

  Problem 2: If the process changes and a 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 real systems, 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 a more complex duty cycle, is required for the following syntax:

Clock process: clk <=! Clk after 5 ns;
Conventional VHDL simulators typically deal with the first two problems by the concept of “delta”, ie, a subtick sync point. Using subtick synchronization points, all signal values are fixed at the beginning of the delta. These values are issued in response to a request 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 requires the VHDL programmer to insert extra wait statements into the code to force alignment to the next delta. For problem 2 above, a statement that enforces a delta boundary is inserted to solve this non-deterministic problem.

Process 1: test <= '1';
wait for 0 ns;
if (test = '1') then output <= '1'; end if;
Process 1 will consistently set output to '1'. However, there is no guarantee that the synthesized result will work as expected.

  In the current implementation of the fabric process, an instantaneous value is issued (so this example behaves as if a weight is 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 may detect multiple changes within a single “delta” for a single signal and report this to the simulation output or mimic other actions. Modifications can be made to change the implementation.

  The simulator generates an absolute time value. The fabric process clock subsystem currently uses a 1 nanosecond basic time slice, which is sufficient to track the required accuracy of the current clock signal. This may need to be changed as the multi-GHz system becomes more widespread. Clock signal support has been incorporated into the central process to simplify the interface for common operations.

  Most operational VHDL is written with a trigger that operates in one of two modes. In asynchronous mode, the signal change enabled the process to react to that signal in the next nanosecond. In synchronous (clock) mode, the signal was examined only at the edge of the clock signal (rising or falling). These modes are determined during motion translation in S1000 of FIG. The process operability was determined at the beginning of each nanosecond tick based on the signal changes that occurred in the previous tick and the clock transitions occurring at that time. The process that became operational during the nanosecond tick did not begin until the next tick, providing an environment similar to the “delta” mechanism.

  The salient feature of this interface method is that the process waiting for the event is in a true wait state within the microkernel core. That is, they are not checked at each clock tick and do not incur overhead in the rest of the system. The fabric process handles all checks for conditions. By removing the overhead of the traditional operating system and performing simulations directly under the lightweight operating system, the present invention not only operates faster, but the representation of the emulated state is the scheduling of the operating system itself. Implemented directly through the core.

  Trace output can be displayed on the console as each process executes the translated code. If the system-wide ECHOVHDL variable is not zero, the simulation environment makes the signal value change visible to the observer by printing a string prefixed with a nanosecond tick timestamp. In combination with the signal display subsystem in the co-simulation environment, stepping can be performed to watch the effect of individual VHDL statements on the global state.

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

  The computer system can also include a server 45 connected to the processor 40 by a data link 44. The data link 44 is a conventional data link (for example, Ethernet, twisted pair, FTP, HTTP, etc.). The server 45 provides access to the program library 46 connected to this server. Program library 46 may also provide software instructions adapted to allow a computer system to perform the steps of the present invention. As described above, the program library 46 is implemented on any of various media known to those skilled in the art (eg, floppy disk, hard disk, optical disk, cartridge, tape, CD-ROM, writable CD, etc.). Is possible. In the computer system shown in FIG. 16, the software instruction on the memory 42 allows the processor 40 to access the program library 46 by accessing the server 45 through the data link 44. The computer system shown in FIG. 16 is not intended to be limiting in any way, and many different computer systems that implement the present invention can 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 invention, but to serve the following description. This sample system has an I960 instruction set simulator with an external data bus connected to both the memory subsystem 38 and the address decoding glue logic 36. Arrows indicate unidirectional or bidirectional signal. The glue logic 36 drives a chip-select signal for the memory and the UART chip 37 and provides various signal presentation requests to the UART 37. 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 was linked to a data bus based on the MIPS architecture, using information from the NEC VR4300 processor User Guide. Since there was no external bus mastering device on the bus, the system used a subset of the full MIPS bus. The selected set of signals was sufficient to implement the device with different burst times and different response times.

  The bus operates in synchronous mode and activity is scheduled on the rising edge of the busclk signal. 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] A command bus that identifies data and transaction types. This adds a burst of 8 words to the read mode but does not use error indication commands and external non-response mode;
EOK set low when an external device can accept commands;
EValid set low when an external device places valid data on the bus;
Set to high when the PMaster processor releases bus ownership (so that an external device can issue a read response).

In this simple model without an external bus mastering device, no other protocol signals from the full MIPS bus were used.

  From the processor perspective, referring to FIG. 18, the buses are driven in the following order.

1. The processor waits for EOK to go low (which indicates that no external device is using the bus);
2. The processor drives an address on SysAD and an appropriate Write command on SysCmd. 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 (this indicates that the external device has accepted the command);
4). The processor sequentially drives one data word on the SysAD bus every busclk cycle and marks the last (or only) word with a 'no-more'flag;
5. At the end of the last data cycle, the processor sets PValid high (this indicates that the processor is no longer driving the bus) and tri-states SysAD and SysCmd.

  Referring to FIG. 19, the processor lead is as follows.

1. The processor waits for EOK to go low (which indicates that no external device is using the bus);
2. The processor drives an address on SysAD and an appropriate Read command on SysCmd. 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 (this indicates that the external device has accepted the command);
4). The processor sets PValid high (this indicates that the processor is no longer driving the bus) and sets PMaster high to release control of the bus;
5. The processor waits for EValid to be set low (this indicates that the external device has placed valid data on the bus). The processor then sequentially reads one data word from the SysAD bus, one per busclk cycle;
6). The processor waits for EValid to be set high, then sets PMaster low and regains control of the bus.

  UART used a very simple signal model as follows.

UartD {7..0} is a byte-wide bi-directional 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 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. Address and data bus values must be valid as long as the chip is selected;
UartI is set high to notify the interrupt from the UART to the processor.

  busclk is a synchronous clock signal to the chip, and all transitions are sampled at the rising edge of the clock.

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

制御レジスタは、まずインデックス番号を書き込んだ後に８ビットのデータを書き込むという２段階アクセスによって、内部ＵＡＲＴレジスタにアクセスするために用いられる。制御レジスタ０は、制御アドレスに制御オペレーションを書き込むことによって直接にアクセスされることが可能である（制御オペレーションは、間接レジスタ番号の範囲外のバイナリ値を有する）。この最小モデルでは、上記テーブル２にリストした制御オペレーションのみがインプリメントされた。これらは、割込み駆動およびポーリングモードの出力（入力はない）を提供するのに十分であった。

The control register is used to access the internal UART register by a two-stage access that first writes an index number and then writes 8-bit data. 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 interrupt driven and polling mode outputs (no inputs).

  System memory was assumed to support back-to-back burst mode transfer over the SysAD line at the speed of busclk. The memory controller was granted access to the SysAD, SysCmd, PMaster and EValid signals on the processor bus and was clocked by busclk. The memory controller used two additional signals to glue logic.

MemS is a memory chip-select, which is set low when the memory is the target of command and address data on the bus;
MemEOK is set low by the memory controller when the memory controller can accept the command.

  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.

  Both UART and memory implementations were written directly in behavioral C using the VHDL signal library to control their operation according to the above architecture specification. In addition, the UART implementation stored a string that was 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 was written as a single entity in VHDL that implements a state machine for coding and signal translation by address. VHDL was translated into C according to the method of S1000.

  Next, the integration of the above instruction set simulator into the co-simulation environment will be described. Several changes to the ISS were required to integrate the ISS into the fabric environment. Once the I / O operation was not of a predictable duration, most of the changes were related to timing changes.

  The following code was added to the process initialization sequence to initialize the fabric interface, process synchronization clock and signal set.

FabInit ();
/ * Specify pclock period * /
fabric_set_clock ("pclk", 0, 5);
/ * Initial state of the processor signal * /
Signal (PMaster, 0);
Signal (PValid, 1);
/ * Data and command bus floats until driven * /
SignalZ (SysAD);
SignalZ (SysCmd);
A routine that simulates a single processor clock tick must run before executing each tick.
WaitClkR ();
Modified to wait for a rising edge change on pclk from the central fabric process by adding a call 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 design that is co-simulated.

  The basic strategy for I / O (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 followed the above description. For example, a new operation started as follows (assuming that the variable this points to an I / O request data structure):

if (GetSignal (EOK) == 0)
{
Signal (Pvalid, 0);
Signal (SysAD, this->addr);
Signal (SysCmd, this->op);
this-> memstate = 1;
}
sbmarksb (this-> inst, 2);
That is, after waiting for EOK to be set low, it drives a signal on the bus. Note that, regardless of whether the command is initiated, the unit is stalled for the next tick and the resource must be marked as unavailable. This routine also polls all the signals. This is because the wait 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 less than 10 states. The machine also handled instruction fetch cycles.

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 register during the interrupt processing of the simulated processor. In a co-simulation system, this is in UART code
Signal (uartI, 1);
Calls and corresponding tests in the ISS process
if (GetSignal (uartI) == 1)
{
IGEN (7);
}
Must be replaced by. This approach uses the bus control unit (Bus
The problem occurred when the Control Unit) was busy and the processor could not handle the interrupt immediately, or when requesting an instruction fetch before the interrupt was ready to run. Without special action, interrupts will be processed at each clock tick until the processor priority register is updated to the interrupt priority.

  This was handled by a flag that was set when interrupt processing was started. This flag bypassed all pipeline scheduling as long as there was activity in the bus control unit (including activity 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 checking the register being interrupted 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 operating at full speed. Thus, the instruction pipe is filled with 0 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 busclk, one (processor) wait state was required per access.

  The UART was assumed to be connected to a 9600 baud external serial line. Therefore, characters were sent every 1 millisecond. Since 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 execution of the previous code example, the "Hello World" program. The output shown in FIG. 20 demonstrates a working system running on a development board containing a MIPS-III architecture CPU. This architecture, unlike the architecture of the simulated CPU (Intel I960), demonstrates how a more capable 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. Device drivers for lightweight operating systems can be easily written, providing a rapid prototyping and simulation environment. There is no reason to restrict the simulator to a single CPU.

  With the exception of the lightweight operating system core itself, the simulation system is independent of any particular machine architecture. Its very low overhead and memory requirements allow lightweight operating systems to make maximum use of available RAM for simulation without paging or swapping. Also, such systems generally require a minimal set of external peripherals, so it may be possible to use a high performance CPU as a simulation engine or accelerator for a conventional workstation.

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

  The foregoing description of various features of the present 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. It is obtained by performing. The principles of the present invention and its practical application have been described so that one skilled in the art can utilize the present invention in various modifications in various embodiments for the particular application contemplated.

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

It is a figure which shows the conventional simulation system which has a multilayer simulation environment. FIG. 3 is a diagram showing a basic process flow of a method for co-validation between an electronic circuit and software targeting the circuit according to the characteristics of the present invention. FIG. 5 shows a detailed process flow of a method for translating a hardware behavior description into a software model according to a feature of the present invention. FIG. 5 shows a detailed process flow of a method for translating a hardware behavior description into a software model according to a feature of the present invention. FIG. 6 illustrates an example set of commands for a command line interface to an instruction set simulator. It is a figure which shows the typical command flow by the Intel 1960 processor. FIG. 4 illustrates a process flow for determining instruction cycling as an instruction passes through a target microprocessor, in accordance with aspects of the present invention. FIG. 4 illustrates a process flow for determining instruction cycling as an instruction passes through a target microprocessor, in accordance with aspects of the present invention. FIG. 4 illustrates a process flow for determining instruction cycling as an instruction passes through a target microprocessor, in accordance with aspects of the present invention. FIG. 4 illustrates a process flow of an emulated target processor when a co-validation simulation is performed in a lightweight computer operating system environment in accordance with features of the present invention. FIG. 4 illustrates a process flow of an emulated target processor when a co-validation simulation is performed in a lightweight computer operating system environment in accordance with features of the present invention. FIG. 4 illustrates a process flow of an emulated target processor when a co-validation simulation is performed in a lightweight computer operating system environment in accordance with features of the present invention. FIG. 4 illustrates a process flow of an emulated target processor when a co-validation simulation is performed in a lightweight computer operating system environment in accordance with features of the present invention. FIG. 4 illustrates an exemplary software process for co-validation in a lightweight computer system environment in accordance with features of the present invention. FIG. 5 illustrates a signal flow path in a lightweight computer operating system environment in accordance with features of the present invention. FIG. 3 illustrates an exemplary computer system for hardware and software validation of a target microprocessor and electrical circuit in accordance with features of the present invention. FIG. 4 illustrates an exemplary system consisting of a target microprocessor, glue logic, I / O hardware and memory that are co-verified using the present invention. FIG. 18 is a diagram illustrating bus read timing of the exemplary system shown in FIG. 17. FIG. 18 illustrates bus write timing for the exemplary system shown in FIG. 17. FIG. 18 shows signal timing generated by the present invention for the exemplary system shown in FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 UNIX (R) 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 Circuit under test 22 Bus arbitration process 23 Global loop controller 24 Test stimulus 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 (5)

In a computer system that performs validation of an electronic circuit and a control program that targets the electronic circuit,
The electronic circuit and control program are simulated using a predetermined computer language that is executed in a lightweight operating system environment built on a microkernel that provides interprocess communication via messages,
The computer system includes:
A signal management means for managing the state of all global signals;
Clock generation means for generating a clock signal used by a software model of the electronic circuit and an instruction set simulator for executing a part of the control program;
Queue management means for managing a process queue that waits for an event from the software model and the instruction set simulator;
Scheduler means for executing components including said software model and said instruction set simulator at predetermined timing intervals;
The signal management means, the clock generation means, the queue management means and the scheduler means are subsystems controlled by a central control process executed by the computer system, and the electronic circuit is the lightweight operating system. The computer system is characterized in that a state change between elements of the mapped electronic circuit is modeled by message passing of the lightweight operating system.   3. The computer system according to claim 2, further comprising display control means for displaying a state change with respect to the global signal on a display.   The computer system according to claim 1, wherein the predetermined timing interval simulates a time interval of 1 nanosecond or more.   The computer system according to claim 1, wherein the predetermined timing interval simulates a time interval of less than 1 nanosecond. In an executable program for a computer system that performs validation of an electronic circuit and a control program that targets the electronic circuit,
The electronic circuit and control program are simulated using a predetermined computer language that is executed in a lightweight operating system environment built on a microkernel that provides interprocess communication via messages,
The executable program is:
A first executable code portion for managing a plurality of global signal states when executed on a computer;
A second executable code portion for generating a plurality of clock signals when executed on a computer;
A third executable portion of code that manages a process queue that waits for an event when executed on a computer;
A fourth executable code portion that, when executed on a computer, generates a predetermined timing interval;
A fifth executable code portion for controlling execution of at least the first, second, third and fourth executable code portions when executed on a computer;
And the electronic circuit is mapped to a process executed by the lightweight operating system, and a state change between elements of the mapped electronic circuit is modeled by message passing of the lightweight operating system. An executable program for a computer system that performs electronic circuit and control program co-validation.

Images