Simulator architecture

Details Simulator architecture Simulator architecture

1998-10-26

2001-07-17

Teska, Kevin J. (Department: 2123)

Data processing: structural design, modeling, simulation, and em

Simulating electronic device or electrical system

Timing

C703S016000, C703S020000, C703S022000, C714S738000

Reexamination Certificate

active

06263303

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to simulation of embedded digital hardware systems and software running on such systems.
BACKGROUND OF THE INVENTION
Simulation is the primary technique used to verify electronic system designs before substantial manufacturing expense is undertaken to produce prototypes. Simulation is a particularly important phase in the design of complex integrated circuitry such as central processing units or digital audio/video processors, because the manufacturing expense and delay in producing a prototype of an integrated circuit is substantial. Furthermore, even after a prototype has been produced, simulation is often useful to identify and debug problems encountered during testing of the prototype to determine whether there are design flaws.
While there are numerous commercially available simulation systems, all can be generally categorized into two groups: cycle-based simulators and event-driven simulators. Both are successful in modeling hardware at low levels, i.e., at a switch, gate or register level. In high level modeling, i.e. at or above the behavior level, module level or architecture level, current simulation techniques as used in industry are of limited use. Generally speaking, the description language used by simulators is normally not as flexible as general programming languages such as C/C++. As In the context of digital video decoding in particular, it will be noted that there are many C/C++ reference models, e.g. for MPEG/MEPG2 decoding, available in the public domain. Unfortunately, these reference models cannot be used in conventional simulators due to the limited description language provided by the simulator. A consequence, it is difficult to model a complete complex system at a high level, for example to perform embedded software verification.
The functional structure of a cycle-based simulator is illustrated in FIG.
1
. Cycle-based simulators are typically used for relatively high-level simulation of the underlying hardware system. Typically, in a cycle-based simulator, a software module
10
is generated for each hardware component of the system, the module modeling the high-level behavior of the corresponding hardware component. Global variables
12
stored and managed by the underlying operating system, are used to represent the transfer of information between each hardware component. Each module is responsive to a triggering signal simulating the passage of time. A processing core
14
generates these trigger signals and delivers the trigger signals sequentially to each module
10
.
When triggered, a module
10
responds by performing processing tasks, based upon the current values of global variables
12
or a current internal state. As part of this processing, a module may modify a global variable
12
, simulating an output of the corresponding hardware stricture.
When modeling a complex system, cycle-based simulation has the drawback that, by its nature, a cycle-based simulator prevents the simulation of a module or function that operates over multiple cycles. Consequently, computation delays and pipelined structures are difficult to model at a high level of abstraction. Furthermore, cycle-based simulation requires that the simulation core trigger each module
10
during each simulated time period. In a complex simulated system, there may be many modules that will take action or produce a changed output only every, e.g., 100 clock cycles. As a consequence, 99% of the time a call to such a module will not produce any meaningful activity, but rather will, at most, simply increment a counter internal to the module. Thus, there is inefficiency in a cycle-based simulation, particularly in a complex system in which may components are idle for large periods of time. Simulation of digital audio/video processors often suffer from both of these drawbacks.
The typical functional structure of an event-driven simulator is shown in FIG.
2
. Event-driven simulators are typically used in simulation of low-level behaviors of the simulated system. Typically, in an event-driven simulator, the behaviors of low level components of a system, which may be individual logic gates captured from a hardware definition language (HDL), or abstractions of logic gates such as used in a register-transfer model, are defined in software modules
16
. These software modules are responsive to “events” received by the module from the simulator core
18
, and in response generate “events” which are delivered to the simulator core
18
for transfer to other software modules
16
. The core
18
references an event-response table
20
to determine where events from a given module are to be transferred, and then transfers the events appropriately. As seen in
FIG. 2
, a first event(
1
), causes a module to generate a second event(
2
), which is transferred to two additional modules.
When an event is delivered to a component modeled by an module
16
, a child process
22
is formed to execute code in the module. A current state
23
for the child process
22
is also formed, representing the event(s) triggering the child process and the current state of any global variables used as inputs to the module. This child process then executes under control of the operating system based on the code in the module, until its execution is completed. Typically, an event-driven simulator operates on a multi-threading operating system, with each child process represented by a separate thread.
While an event-based simulator provides highly accurate modeling of detailed behaviors not typically captured by cycle-based simulators, it is relatively difficult to define simulation of complex circuit structures, since the nature of the simulation language does not readily permit definition of such structures. Often the task of preparing an event-driven simulation model is left to an automated simulation compiler operating directly on HDL, which produces an extremely detailed low-level model of behaviors. Furthermore, if event-based simulation is used to model a complex circuit structure in which the actions performed in response to an event are relatively lengthy, a large number chains of child processes may be produced, substantially greater in number than the original number of modules. For example, if an event(
0
) is followed quickly by an event(
1
), a child process or several such processes may be generated from the receipt of event(
0
) at a module
22
, and while this child process is continuing to execute in response to its stored state, a second child process may be generated from the receipt of event(
1
) at the module. If each child process takes a duration of time to complete, still further child processes may be triggered from the same module, resulting in a substantial multiplication of child processes corresponding to a single module. In a complex system with multiple state machines, pipelined sections with delays, the resulting “blooming” of child processes, and the overhead involved in process swapping between each child process in a multithreading operating system, can overwhelm the system and substantially slow processing.
In simulation of a digital audio/video processor for simultaneously decoding audio and video digital television signals, it has been found that an event-based simulator was faster than a cycle-based simulator. However, due to the complexity of the underlying system, process swapping in the event-based simulator consumed more processor time than any other operation. Partly as a consequence of this inefficiency, simulation of a decoding of a single video frame consumed approximately one day of simulation by a workstation. This is far too slow to appropriately simulate all of the functions that must be simulated to verify a design. In particular, to verify that audio/video synchronization is properly operating, decoding of one hundred or more frames of video must be simulated to determine whether synchronization is being performed properly.
SUMMARY OF THE INVENTION
Accordingly, there is a need for a simulator th

Affiliated with

Also associated with

Rating

Simulator architecture does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Simulator architecture, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Simulator architecture will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2563109