Method and apparatus to emulate VLSI circuits within a logic simulator

Claims

What is claimed is:

1. A method of emulating a complex circuit in a simulated system on a logic simulator with no upper simulation time limit, comprising the following steps:

a) providing a simulator interface to control and accumulate any functionally complete architecturally visible update from said logic simulator to said complex circuit,

b) providing a model debug and user interface to manipulate any architecturally visible registers and status within said complex circuit,

c) providing a control mechanism to keep said complex circuit in an architecturally unaltered state by providing necessary clocks and data signals to keep said complex circuit operating in a quiescent state,

d) providing a control and routing mechanism to accept and to submit simulator updates and user interface debug updates to said complex circuit after bringing said complex circuit out of said quiescent state,

e) providing a control and routing mechanism for monitoring responses from said complex circuit, putting said complex circuit back into quiescent state, and routing said responses to said logic simulator and to said model debug and user interface,

whereby the complex circuit is continually emulated within the simulated system with the ability to view or to alter or to set breakpoints on architecturally visible internal state of the complex circuit so as to provide a powerful debugging environment prior to building a real prototype of the system under development.

2. The method of claim 1, further including:

a) providing an arrangement for representing a plurality of instances for said complex circuit,

b) providing a plurality of model debug and user interfaces for representing a plurality of instances of said complex circuit, and

c) providing simulation and emulation control and routing mechanism for a plurality of instances of said complex circuit.

3. The method of claim 1, further including:

a) providing an arrangement for representing a plurality of instances for a plurality of different complex circuits,

b) providing a plurality of model debug and user interfaces for representing a plurality of instances of a plurality of complex circuits, and

c) providing simulation and emulation control and routing mechanism for a plurality of instances of a plurality of different complex circuits.

4. The method of claim 1, further providing an arrangement for representing a plurality of instances of a plurality of different complex circuits within a plurality of simulation sessions representing an emulation support using a plurality of model debug and user interfaces and providing emulation and simulation debugging for a plurality of said instances of a plurality of said different complex circuits within a plurality of said different simulation sessions.

5. The method of claim 4 wherein said complex circuits represent a plurality of predetermined and programmable circuits and systems.

6. A simulation model for emulating a complex circuit in a simulated system on a logic simulator with no upper simulation time limit, comprising:

a) a simulation means for representing said complex circuit consisting of a very large scale integrated circuit device or an electronic system within said simulated system represented on said logic simulator,

b) a debugging means for viewing and altering an architecturally visible register or status within said complex circuit on a model debug and user interface,

c) a maintenance and controlling means for creating a simulation session representing said simulated system for allowing said complex circuit to communicate with said logic simulator to start, pause, advance, or stop said simulation session,

d) a simulation interaction means for repeatedly accepting stimuli from said logic simulator and for responding locally with new stimuli to said logic simulator representing modeling activities to and from said complex circuit until a functional tuple is accumulated representing a predetermined functional pattern or a sequence of functional patterns of stimuli along with simulation specific functional data representing one complete architecturally visible access to said complex circuit's architecturally visible internal registers,

e) an emulation means for generating emulation breakpoint commands and to generate architecturally visible emulation tuples representing a predetermined functional pattern or sequence of functional patterns of stimuli along with user specified debug data for accessing said complex circuit's architecturally visible internal registers,

f) an acquiescing means for keeping the internal state of said complex circuit current by submitting to said complex circuit an acquiesce tuple representing a predetermined pattern or sequence of patterns of stimuli,

g) a controlling means for submitting said acquiesce tuples or said functional tuples or said emulation tuples or said emulation breakpoint commands or said maintenance commands to said complex circuit to continually keep said complex circuit in an architecturally correct operational internal state,

h) a simulation routing means for accepting a simulation functional response or an emulation breakpoint response or a simulation session setup and maintenance response from said complex circuit and routing said accepted response back to said logic simulator for starting, pausing, advancing, or stopping of said simulation session,

i) an emulation routing means for accepting said simulation response or said emulation and breakpoint response from said complex circuit and routing said accepted response back to said model debug and user interface for emulation debug or breakpoint update,

whereby the complex circuit is continually emulated within the simulated system with the ability to view or to alter or to set breakpoints on architecturally visible internal state of the complex circuit so as to provide a powerful debugging environment prior to building a real prototype of the system under development.

7. The simulation model of claim 6, further including:

a) simulation means to represent a plurality of instances for said complex circuit within said logic simulator,

b) said model debug and user interface providing emulation means for representing a plurality of instances of said complex circuit, and

c) control means providing simulation and emulation support for a plurality of instances of said complex circuit.

8. The simulation model of claim 6, further including:

a) simulation means to represent a plurality of instances for a plurality of different complex circuits within said logic simulator,

b) said model debug and user interface providing emulation means for representing a plurality of instances of a plurality of different complex circuits, and

c) control means providing simulation and emulation support for a plurality of instances of a plurality of said different complex circuits.

9. The simulation model of claim 6, further including simulation means to represent a plurality of instances of a plurality of different complex circuits within a plurality of simulation sessions representing emulation support using a plurality of model debug and user interfaces and providing emulation and simulation debugging for a plurality of said instances of a plurality of said different complex circuits within a plurality of said different simulation sessions.

10. The simulation model of claim 9 wherein said complex circuits represent a plurality of predetermined and programmable circuits and systems.

11. A simulation model for emulating a complex circuit in a simulated system on a logic simulator with no upper simulation time limit, comprising:

a) a simulation means for representing said complex circuit consisting of a very large scale integrated circuit device or an electronic system within said simulated system on said logic simulator,

b) a debugging means for enabling a user to view or to alter an architecturally visible register within said complex circuit,

c) a maintenance interface means for providing maintenance and control for setting up a simulation session involving said complex circuit to communicate with a software shell model and said logic simulator along with a model debug and user interface to start, pause, advance, or stop said simulation session on said logic simulator,

d) said software shell model providing simulation interaction means for repeatedly accepting stimuli from said logic simulator and for responding locally with new stimuli to said logic simulator representing modeling activities to and from said complex circuit until a functional tuple is accumulated representing a predetermined functional pattern or sequence of functional patterns of stimuli along with simulation specific functional data representing one complete architecturally visible access to said complex circuit's architecturally visible internal registers,

e) said model debug and user interface further providing emulation means for generating emulation breakpoint commands and for generating an architecturally visible emulation tuple representing a predetermined functional pattern or sequence of functional patterns of stimuli along with simulation specific debug data for accessing said complex circuit's architecturally visible internal registers,

f) a command and data interpreter and router providing routing means for accepting any of said functional tuples from said shell model and said emulation tuples and said breakpoint commands from said model debug and user interface and maintenance and setup commands from said maintenance interface,

g) said command and data interpreter and router further providing buffering means for passing on of said functional tuples to a simulation specific functional state generator and said emulation tuples and said breakpoint commands to a user request and default functional state generator and said maintenance and setup commands to a device control,

h) said simulation specific functional state generator providing control means for accumulating said functional tuples and submitting corresponding predetermined functional pattern or a sequence of functional patterns of stimuli and simulation dependent data to said device control,

i) said user request and default functional generator providing control means for accumulating said emulation tuples and submitting corresponding predetermined functional pattern or a sequence of functional patterns of stimuli and user supplied emulation data to said device control,

j) said user request and default functional generator further providing control means for accumulating said breakpoint commands and submitting these to said device control,

k) said device control providing buffering means for accepting any of said functional tuples or said emulation tuples or said emulation breakpoint commands or said maintenance commands to submit these to a personality module,

l) said personality module connected to said complex circuit via input and output buffers by a plurality of signal paths,

m) said personality module further providing acquiesce means for keeping the internal state of said circuit current by controlling said input and output buffers to submit to said complex circuit an acquiesce tuple representing a predetermined pattern or a sequence of patterns of stimuli,

n) said personality module further providing control means for accepting command and data from said acquiesce tuples or said functional tuples or said emulation tuples or said emulation breakpoint commands or said maintenance commands and to submit these to said complex circuit to continually keep said complex circuit in a correct architecturally operational state,

o) said personality module further providing buffering and routing means for registering a simulation functional response or an emulation breakpoint response or maintenance setup response from said complex circuit and submitting said response to said device control,

p) said device control further providing buffering means for passing on said simulation and emulation responses to said simulation specific functional state generator and said user request and default functional state generator and said command and data interpreter and router,

q) said simulation specific functional state generator further providing buffering means for routing said simulation functional responses and said emulation breakpoint responses from said device control to said command and data interpreter and router and said software shell model for pausing, or advancing said logic simulator,

r) said user request and default functional state generator further providing buffering means for routing said simulation response and said emulation and breakpoint responses from said device control to said command and data interpreter and router and said model debug and user interface,

s) said command and data interpreter and router providing buffering means for routing said simulation setup and maintenance command response from said device control to said maintenance interface for starting or controlling or stopping said logic simulator,

whereby the complex circuit is continually emulated within the simulated system with the ability to view or to alter or to set breakpoints on architecturally visible internal state of the complex circuit so as to provide a powerful debugging environment prior to building a real prototype of the system under development.

12. The simulation model of claim 11, further including:

a) said maintenance interface further providing control means for representing a plurality of instances of said complex circuit within said simulation session with the use of a plurality of said software shell models,

b) said model debug and user interface further providing emulation means for representing a plurality of instances of said complex circuit as setup by said maintenance interface within said simulation session, and

c) said device control further providing control means for supporting a plurality of personality modules representing a plurality of instances of said complex circuit as setup by said maintenance interface within said simulation session and providing emulation and simulation support for a plurality of said personality modules.

13. The simulation model of claim 11, further including:

a) said maintenance interface further providing control means for representing a plurality of instances of a plurality of different complex circuits within said simulation session with the use of a plurality of said software shell models,

b) said model debug and user interface further providing emulation means for representing a plurality of instances of a plurality of said different complex circuits as setup by said maintenance interface within said simulation session, and

c) said device control further providing control means for supporting a plurality of personality modules representing a plurality of instances of a plurality of said complex different circuits as setup by said maintenance interface within said simulation session and providing emulation and simulation support for a plurality of said personality modules.

14. The simulation model of claim 11, further including a plurality of device control providing control means for supporting a plurality of personality modules for controlling a plurality of instances of a plurality of different complex circuits as setup by a plurality of maintenance interfaces within a plurality of simulation sessions representing emulation support using a plurality of model debug and user interfaces and providing emulation and simulation debugging for a plurality of said instances of a plurality of said different complex circuits within a plurality of said different simulation sessions.

15. The simulation model of claim 14 wherein said complex circuits represent a plurality of predetermined and programmable circuits and systems.

BACKGROUND--FIELD OF INVENTION

This invention relates to simulation, modeling, and control of operations of complex large scale integration (LSI) devices, very large scale integration (VLSI) digital devices, or digital systems. More specifically, the invention relates to controllability and observability of complex digital circuitry and systems within logic simulation sessions, including those capable of executing instructions under program control.

BACKGROUND--DESCRIPTION OF PRIOR ART

Traditionally, any design team which used digital logic simulators (computer software systems to verify, digital hardware designs) had access to only software-based logic simulation models to exercise and to verify the simulated design. These logic simulation models are software programs which emulate the functionality of devices used in the simulated design on the logic simulators. For simple digital devices, even today, software simulation models are very much in use, while software simulation models of complex VLSI integrated circuits are being developed less often due to a few disadvantages. For one, they are very time consuming to develop and test. Second, for a third party (a party other than the manufacturers or customer) to develop the software model for a complex device with accuracy, the specifications of the internal operation of the device must be gathered and thoroughly understood. This has been a serious limitation because manufacturers of such complex devices are generally reluctant to disclose such details to third parties.

U.S. Pat. No. 4,590,581 to L. Curtis Widdoes, Jr., May 20, 1986, "Method and Apparatus for Modeling Systems of Complex Circuits", discloses a hardware modeler for simulating a VLSI device with an actual physical specimen of such device. While Widdoes' apparatus provides functional accuracy of the device during simulation, the modeling method results in a very poor simulation performance and it does not provide observability of the internal operation of the device being simulated. These are major deficiencies of Widdoes' system. Therefore the design and debugging of digital systems still leaves much to be desired. Specifically, performance is of particular concern for a device which needs a constant application of clock and other functional signals to keep it operating properly, as do most microprocessors and memory devices. For such devices, the hardware modeler must repeat all previously simulated input signals before a new set of stimuli is applied. The implication of this fact is that the time to execute a set of test stimuli to simulate a digital design using a hardware model is proportional to the square of the number of test stimuli in the set. Typically, finite pattern memories of the hardware modeler (storage of previously replayed simulation signals) seriously limit the number of test stimuli sets that can be applied within a typical simulation session.

Although Widdoes cites software model performance as one of the drawbacks of a complex software model, it is generally agreed now that the software models for microprocessors fare equally well in simulation performance against a hardware model for the same microprocessor. When multiple representations (instances) of a device are used in a simulation session, or several users need to access the same hardware model as outlined in Widdoes' patent, the performance of the overall logic simulation is drastically reduced when using the hardware modeler. This is due to the fact that a complete history of the simulation pattern for each instance (different representation of a VLSI device used within a design) has to be repeatedly replayed to the actual device. These performance degradations and test pattern quantity limitations are not there when using software models for same devices. Finally, the apparatus and means described by Widdoes to build a hardware modeler needs complicated hardware and fast access memories and is thus very expensive.

The hardware modeler had subsequently been improved with Widdoes' improvement U.S. Pat. No. 4,635,218, granted Jan. 6, 1987 which shows an apparatus which alleviates certain limitations of pattern memory and model performance. This only partially improved the drawbacks outlined above. While the altered method provided a slight increase on the memory pattern capacity and reduced slightly the network traffic overhead of communication between the simulator and the hardware modeler, it did little to reduce the costly hardware to control these activities. This Widdoes U.S. Pat. No. 4,635,218 patent ended up providing a hardware model capable of providing only logic and timing accuracy of the actual physical device being simulated, but it compromised one fundamental characteristic which a complex simulation model needs mainly to support, i.e., visibility of internal architectural state and control over the operation of the complex device being simulated.

A primary reason why a digital logic simulation is used by a digital design engineer is the accessibility and control over the design under scrutiny. Widdoes' VLSI hardware model fails to provide any clear visibility and control of the architecturally visible internal status and registers of the VLSI model. This is especially desired when software instructions need to be executed on simulated design. This capability is available only within software models for a VLSI device (or for a system) today. These software models can provide an in-circuit emulator (ICE) like environment for debugging the design.

As software models for complex VLSI devices are time consuming to develop and need a large engineering resource, they have only been successfully developed by large companies, such as International Business Machines (IBM) and Digital Equipment Corp. (DEC) for their flagship microprocessors, such as the IBM Power PC microprocessor and the DEC Alpha microprocessor. These software models provide complete visibility and control over simulation of the design while executing instructions. Hardware models cannot provide any debugging benefit as is available with these software models.

While the performance of a hardware model will be comparable to that of a software model for a single instance of the device, it is generally agreed that for multiple users or when multiple instances of a device are used within a simulation session, software models outperform hardware models. And overall both types of simulation models are still significantly too slow for a full-blown large system simulation using multiprocessing and parallel processing architectures as are designed today. But at present, while simulating with many of the commercial complex VLSI device models, the designer has to either forego extensive design analysis or make do with the limitation of the hardware models. Finally, only a large design team can justify the large capital investment for the hardware modeler.

For most of the other complex VLSI devices in the marketplace, the current simulation alternative is to use a software model (only available for some limited complex devices) or to use a hardware model. As both options are not only very expensive, but are also only partial solutions to a complete digital design and debug of complex systems, the design teams end up building a prototype of a partially simulated design. The prototypes are taken to an engineering lab and the final stage of design verification is completed using an ICE such as those sold by Intel Corp., Santa Clara, Calif. along with logic analysis tools such as those sold by Hewlett Packard Corp., Palo Alto, Calif. This method of design verification linearizes the design analysis phase followed by design verification phase, thus lengthening product introduction cycles and ultimately the product cost. Also the selection of complex VLSI devices gets frozen very early in the design analysis phase, thereby limiting the provision of an optimum set of design alternatives.

Most common types of microprocessors have ICE support from multiple vendors, but for complex Application Specific Standard Products (ASSP) and fabricated Application Specific Integrated Circuits (ASIC) there are very few ICE products to support development. U.S. Pat. No. 4,633,417 to Wilburn et al., Dec. 30, 1986, outlines an "Emulator for Non-fixed Instruction Set VLSI Devices". Also U.S. Pat. No. 4,782,461 to Mick et al., Nov. 1, 1988, shows an apparatus which improves upon Wilburn's emulator to allow emulation of multiple VLSI devices with breakpoint facilities. Like other ICE products, these systems address the debug accessibility of VLSI devices within digital systems once these have been designed and fabricated. Thus for early analysis using simulation tools, the apparatus proposed by these patents cannot benefit design teams.

U.S. Pat. No. 4,644,487 to Edward Smith, Feb. 17, 1987, outlines a "Method and Apparatus for Verifying the Design of Digital Electronic Components". This apparatus builds upon the same theme as Widdoes and lacks the visibility and controllability of simulated devices. Also the apparatus intends to work with a real target system, as opposed to a simulated system and the means described to complete the operation is very time consuming. The problem that the Smith patent proposes to resolve is quite successfully tackled by other technical means, i.e., by a few commercial products in the marketplace today, e.g., as made by Quickturn Design Systems, Mountain View, Calif. These commercial products take a designer's representation of the VLSI device in a netlist form (representation of the design consisting of interconnected basic logic elements) and utilize special software algorithms to program FPGAs (Field Programmable Gate Arrays) to emulate a real-time system with a reconfigurable netlist. These products provide higher performance in design simulation only when a design analysis is complete. Also they also lack the observability and controllability and to some extent, the interactions, provided by logic simulation tools. Finally, the Smith apparatus is useful only after the design analysis is thoroughly completed on logic simulators.

U.S. Pat. No. 4,901,259 to Watkins, Feb. 13, 1990, outlines an "ASIC Emulator" to emulate a custom VLSI device netlist a in real-time system setup using software to emulate the logic functions of the VLSI device. The drawback of this apparatus is that, unlike what the inventor states, the software model running under a software simulator will not have sufficient execution speed to emulate a VLSI device in a real system. With the pace of advancement of semiconductor technology, this has proven to be technically difficult to achieve. Real hardware systems today typically work at clock speeds of 50 Mhz and up. An ASIC that will be emulated on the hardware shown by Watkins needs to get back response from the software simulator at the 50 MHz rate. However, the software models on today's fastest commercial simulators working on a 50 Mhz workstations, provide only a few hundred simulated clock cycles per second at best. So the ASIC Emulator described by Watkins will not be able to synchronize generic hardware ASIC in the real world.

A typical example would be to consider emulation of a Dynamic Memory Refresh Controller Device using the method outlined. When the target system consists of a bank of Dynamic Random Access Memories (DRAM), the internal state of the DRAMs would be lost using this ASIC Emulator as the Dynamic Memory Refresh Controller would not be capable of running sufficiently fast to refresh the real target system. And as outlined above, there are commercial products (Quickturn Design Systems, Mountain View, Calif.) already in the market which have a better solutions for the problems outlined and proposed by Watkins. Finally, these ASIC emulation apparatus may be useful only after a design prototype system using the ASIC is produced and available in engineering lab. Thus, the tool proposed by Watkins may be useful only after the design analysis is thoroughly completed on logic simulators.

OBJECTS AND ADVANTAGES

Accordingly, several objects and advantages of the present invention referred to as (Emulation Modeling Apparatus) are:

to provide an improved way to model a complex VLSI device;

to provide an improved way to model an off-the-shelf component, or an ASIC under development, where the internal operation (architecturally visible status) are accessible to the simulation user for observability and control during design verification on a logic simulator;

to provide special design methods which effectively mix two prior device control methodologies, namely hardware modeling and in-circuit emulation;

to provide an apparatus to a designer which provides the ability to observe and to control commercial microprocessors and other VLSI devices used in a design while simulating these complex devices and the design on a logic simulator, thereby providing an efficient if-then-else scenario studies during the design analysis and verification cycles heretofore not available;

to provide a tremendous savings in debugging effort and design analysis time to a design team, resulting in a broader and more complex design analysis;

to provide cost savings in product development by reducing the design verification and system integration time due to the controllability and observability of VLSI devices being modeled;

to provide an efficient and uniform response to accesses in simulating real VLSI devices under varying load conditions such as several users accessing a simulation device, or multiple representations of devices being used within a simulation session, or very long simulation sessions;

to provide model information access means which avoids upper limits to simulation duration;

to provide a simpler method of developing a complex VLSI model as opposed to a full function complex software model by working with information that is readily available in published data books by the manufacturer of the complex VLSI devices and by utilizing the actual functional accuracy of the model through special control of the VLSI device itself;

to provide a way to integrate system software very early in a design verification cycle while using logic (digital/analog mixed mode) simulators on system designs that use microprocessor, such that the designer can set breakpoints on the internal operations of the microprocessor;

to provide a new way to integrate the use of emulation systems (as sold by Quickturn Design Systems, Mountain View, Calif.) into logic simulation and analysis, such that a design team can take a netlist for a VLSI device, load it onto an emulation systems and use the proposed emulation modeling apparatus to provide visibility and control within the ASIC being designed.

Further objects and advantages of my emulation modeling apparatus will become apparent from a consideration of the drawings and ensuing description.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a simulation system with the emulation modeling apparatus in accordance with the invention.

FIG. 2A is an example of graphical model debug and user interface that would be provided for modeling a dynamic random access memory device which would be supported by the emulation modeling apparatus of FIG. 1.

FIG. 2B is an example of graphical model debug and user interface that would be provided for modeling a microprocessor which would be supported by the emulation modeling apparatus of FIG. 1.

FIG. 3 shows a preferred embodiment of a model debug and user in