Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Circuit simulation
Reexamination Certificate
1998-08-19
2001-07-17
Teska, Kevin J. (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Circuit simulation
C703S016000, C703S019000, C702S067000, C716S030000
Reexamination Certificate
active
06263301
ABSTRACT:
TECHNICAL FIELD
The invention relates generally to managing the data generated from a computer simulation of an integrated circuit (IC) and more particularly to a technique for storing and viewing data that is generated from a computer simulation of IC operation.
BACKGROUND ART
A single IC may include millions of individual devices, such as transistors, capacitors, and resistors, formed on one chip to perform desired functions. Production of such complex ICs is an intricate process that involves many steps. One of the first steps in producing an IC involves designing a virtual version of the IC using computer-aided design tools. The design of a virtual version of an IC can be broken down into three general areas: design definition, design verification, and design layout. IC design definition can be described at various levels of sophistication or detail. The levels of design sophistication include the functional level, also referred to as the register transfer level (RTL) or the architectural level; the logical level, also referred to as the gate level; and the transistor level, also referred to as the layout level.
Known design environments commonly utilized at the functional design level involve one of two major hardware design languages, Verilog or VHDL. To minimize the cost of design errors, the functional design of an IC is put through a verification process to identify and correct functional design problems before the IC is laid out and fabricated. An old technique for design verification involves performing a computer simulation of a virtual design of the IC and applying a known series of input data, also known as verification vectors, to the inputs of the IC. The simulation then simulates the expected outputs that the IC would physically generate. The design is verified by a design engineer studying the simulated outputs of the IC to determine if the IC is functioning correctly.
The described prior art technique of design simulation at the functional level requires a large volume of verification vectors. As the complexity of an IC grows, the volume of verification vectors grows exponentially in relation to the number of gates in the IC. This large volume of verification vectors is difficult to manage in terms of an engineer being able to generate the vectors and analyze the vectors. As IC designs and IC verification have grown more complex, the task of generating and analyzing verification vectors is being replaced by more automated processes.
A known technique for generating, managing, and analyzing the growing volume of verification vectors involves including verification software in the simulation software. The verification software generates the verification vectors that are input into the virtual IC that is being simulated. In addition, the verification software examines the output of the virtual IC being simulated for correct behavior. The added verification software is often in the form of bus functional models. That is, the verification software simulated along with the IC mimics and verifies the correct functioning of buses that comprise inputs and outputs to the IC. A bus is a collection of signals that together carry data in and out of lCs. An interface to an IC is a collection of buses, data signals, and control signals that connect to the IC and together perform some data transfer operations in or out of the IC. A bus functional model is a software representation of an interface to an IC. A bus functional model typically interacts with an IC during a simulation by sending data to and receiving data from the IC during the simulation. Bus functional models can be written which send a large body of defined data to an IC, and they can also be written to verify that interfaces are receiving some expected data in a fashion that conforms to the specification of how the interface is supposed to operate. In this way, bus functional models can both generate and verify simulation vectors that are sent to and received from the simulated IC.
FIG. 1
is a high level representation of a simulation unit
10
that utilizes a bus function model
12
to interact with a virtual IC
14
during simulation. The bus functional model along with the IC being simulated together generate simulation results over the course of the simulation. The simulation results are then stored in a simulation results database
18
for future use. The simulation results typically flow from the simulation unit in a stream of data and then are stored in the database.
FIG. 2
is an example of a waveform display of simulation results that includes a clock signal
30
, three variables X, Y, and Z, and their associated variable values
32
,
34
,
36
as a function of time. As can be seen from the waveform display of
FIG. 2
, the waveforms do not easily identify the specific operations that are being performed at any point in time.
Although simulation results in some prior art simulations are broken down into bus functional models, there are many suboperations that occur during the operation of a bus functional model that cannot be readily located in a database or viewed for analysis. As a result, large volumes of simulation results are stored and viewed as one continuous group of verification vectors as shown in
FIG. 2
, thereby making the simulation results difficult to analyze and use for debugging.
In view of the large volume of simulation results that must be analyzed to detect and correct design flaws in the virtual design of an IC, what is needed is a method and apparatus that allow simulation results to be more easily analyzed.
SUMMARY OF THE INVENTION
A method and apparatus for managing simulation results involve identifying distinct transactions within a group of simulation results so that the simulation results can be stored and viewed on a transaction basis, instead of as a single continuous block of simulation results. In a preferred embodiment of the invention, transaction-specific data, related to the identified distinct transactions within the simulation results, is stored into a database. The stored transaction-specific data is then utilized to graphically display the simulation results such that individual transactions identified within the simulation results are graphically distinct. Raising the level of abstraction of simulation results from cycles and signals to transactions enables easier simulation analysis and debugging.
In the preferred embodiment, a transaction is defined as a specific sequence of values on a grouping of signals over a period of time in which the signal activity has some higher level operational meaning. For example, a transaction may be comprised of a single operation such as a read operation or a write operation. In accordance with the preferred embodiment of the invention, standard simulation results are augmented to provide transaction-specific information by storing transaction specific data elements. The standard data elements generated from a computer simulation include any variable names involved in the transaction, the variable values related to the variable names, and the time values that are related to the variable values. The variable name is an identifier that identifies the particular signal that is being generated and monitored. The variable value is the value of a named variable at a given point in time, and the time values are the times when the variables change values during a simulation, The transaction-specific data elements that are recorded in association with a simulation event include the name of the transaction, the start time of the transaction, the end time of the transaction (alternatively, the duration of the transaction), and the interface on which the transaction takes place. The name of the transaction identifies the transaction and preferably indicates the type of transaction as, for example, a read transaction or a write transaction. The start time and the end time identify when a particular named transaction begins and ends and the interface refers to what interface the transaction takes place on, for example, a collection o
Cox Steven G.
Gallo James M.
Glasser Mark
Cadence Design Systems Inc.
Law Offices of Terry McHugh
Sergent Douglas W.
Teska Kevin J.
LandOfFree
Method and apparatus for storing and viewing data generated... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for storing and viewing data generated..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for storing and viewing data generated... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2530366