Compact and effective representation of simulation results

• US 20040260527A1
• Filed: 06/19/2003
• Published: 12/23/2004
• Est. Priority Date: 06/19/2003
• Status: Abandoned Application

• Current Assignee: Alexandru G. Stanculescu
• Original Assignee: Alexandru G. Stanculescu
• Inventors: Stanculescu, Alexandru G.
• Application Number:
  US10/465,480
• Publication Number:
  US 20040260527A1
• Time in Patent Office: Days
• US Class Current: 703/14
• CPC Class Codes: G06F 30/33 Design verification, e.g. functional simulation or model checking

Abstract

The present invention provides a method and system for representing the simulation results in a much more compact format than the current state of the art and speeds up significantly both the storing of the results and the processing of the database, especially speeding up the comparison of two databases. This is achieved by (1) providing the database with more information which is typically available in the simulator or could easily be made available directly from the design description, and by (2) using the dependency graph of the signals in the database to implement a much faster comparison of two databases.

Claims

1. A method for providing more information to the digital simulation results database, either from the simulator or directly from the description of the circuit being simulated, resulting in a more compact representation of the database and a more efficient processing of the data stored in it, the method comprising the steps of:

(a) declare to the database which of the signals are basic signals, whose changes in values must be stored as they are reported by the simulator.

(b) declare to the database which signals are auto-generate signals and what is the way to generate all their changes in value without needing information from any other signal.

(c) declare to the database which signals are derived from other signals and the way to generate all their changes in value without needing information from any other signal except of those referenced in the declaration.

(d) report to the database transactions, each transaction consisting of (1) signal identifier, (2) signal value (including strengths information if necessary), (3) time at which the change occurred, and optionally (4) delta count as partial order information, where signal identifier must be identifying a basic signal.

2. The method of claim 1 further including the method of (i) loading in memory all the value changes and the times at which each change occurs for a derived signal that does not depend directly or indirectly upon a delayed copy of itself (it is suggested to declare dependency loop breakers as basic signals), or (ii) loading in memory all the value changes and the times at which each change occurs for an auto-generate signal that is stored in the database, method consisting of the steps included in the recursive function dbLoadSignal, presented in the detailed description of the invention.

3. The method of claim 2 further including the method for getting the information regarding which signals are basic, auto-generate and derived (steps a, b, c of described in claim 1) directly from the design description rather than from the simulation and accepting transactions from the simulators for all signals. By discarding transactions for auto-generate or derived signals the data base can be significantly compacted.

4. The method of claim 2 further including the method for faster comparison of two simulation results databases, by first comparing the headers of the two databases, then the basic signals which have similar headers, and only afterward compare the derived signals that reference directly or indirectly only basic signals that are different in the two databases, thus saving the time necessary to compare signals that have similar header information, and that depend on signals that have identical history of changes of their values.

Each signal in the results database shall point to two linked lists:

one of signals upon which it depends and another one of signals that depend on it.

The method consists of the following steps applied to the simulation results database;

a) Load and compare all signal headers of the two databases.

b) Load and compare all signal value changes for all basic signals that have identical headers in both databases.

c) Make a list of all derived signals that have identical headers in both databases and that depend directly or indirectly (i.e. via other derived signals) on basic signals with different headers in the two databases or whose list of value changes and times were found different in the two databases at step b), or on auto-generate signals that have different headers in the two databases.

d) Rank the signals in the list made at step c) by giving each signal a number (a rank) equal to the maximum of the ranks associated to each of the signals which it references plus one, with the convention that basic and auto-generate signals have associated the rank of zero. Thus a signal that depends only on basic or auto-generate signals has a rank of one.

e) Associate for each signal a cap, representing the number indicating the highest rank of any signal that depends upon it. Link together all signals with the same cap number.

Process all derived signals in increasing order of their rank by (i) loading in memory all their changes in value and the time at which the changes occur in both databases, by calling the function dbLoadSignal for the corresponding signal in each database, and (ii) Call the function CompareSignalFrom2Databases, which compares the value changes and the occurrence time for each change for the same signal in the two databases. Each time the rank changes, free the memory of the signals having the cap equal to the previous rank.

5. The method of claim 3 further including the method for faster comparison of two simulation results databases, by first comparing the headers of the two databases, then the basic signals which have similar headers, and only afterward compare the derived signals that reference directly or indirectly only basic signals that are different in the two databases, thus saving the time necessary to compare signals that have similar header information, and that depend on signals that have identical history of changes of their values.

Each signal in the results database shall point to two linked lists:

one of signals upon which it depends and another one of signals that depend on it.

The method consists of the following steps applied to the simulation results database;

f) Load and compare all signal headers of the two databases.

g) Load and compare all signal value changes for all basic signals that have identical headers in both databases.

h) Make a list of all derived signals that have identical headers in both databases and that depend directly or indirectly (i.e. via other derived signals) on basic signals with different headers in the two databases or whose list of value changes and times were found different in the two databases at step b), or on auto-generate signals that have different headers in the two databases.

i) Rank the signals in the list made at step c) by giving each signal a number (a rank) equal to the maximum of the ranks associated to each of the signals which it references plus one, with the convention that basic and auto-generate signals have associated the rank of zero. Thus a signal that depends only on basic or auto-generate signals has a rank of one.

j) Associate for each signal a cap, representing the number indicating the highest rank of any signal that depends upon it. Link together all signals with the same cap number.

Process all derived signals in increasing order of their rank by (i) loading in memory all their changes in value and the time at which the changes occur in both databases, by calling the function dbLoadSignal for the corresponding signal in each database, and (ii) Call the function CompareSignalFrom2Databases, which compares the value changes and the occurrence time for each change for the same signal in the two databases. Each time the rank changes, free the memory of the signals having the cap equal to the previous rank.

6. The method of claim 2 further including the capability of supporting partially derived or auto-generate signals (i.e. signals that change their property of being auto-generate or derived at a certain time during the simulation). This method must include the step for efficiently (i.e. only when needed) checking whether the given signal maintains its property. This check must be performed whenever a transaction on the signal is reported during a non pre-analyzed situation, such as during interactive simulation or from a PLI for which there was not enough information at compile time to decide that this PLI call may affect the kind of certain signals.

The method of claim 2 must be enhanced for the purpose of loading a signal in memory for fast processing by replacing the function dbLoadSignal with dbLoadSignalXL.

7. The method of claim 3 further including the capability of supporting partially derived or auto-generate signals (i.e. signals that change their property of being auto-generate or derived at a certain time during the simulation). This method must include the step for efficiently (i.e. only when needed) checking whether the given signal maintains its property. This check must be performed whenever a transaction on the signal is reported during a non pre-analyzed situation, such as during interactive simulation or from a PLI for which there was not enough information at compile time to decide that this PLI call may affect the kind of certain signals.

The method of claim 2 must be enhanced for the purpose of loading a signal in memory for fast processing by replacing the function dbLoadSignal with dbLoadSignalXL.

8. The method of claim 4 further including the capability of supporting partially derived or auto-generate signals (i.e. signals that change their property of being auto-generate or derived at a certain time during the simulation). This method must include the step for efficiently (i.e. only when needed) checking whether the given signal maintains its property. This check must be performed whenever a transaction on the signal is reported during a non pre-analyzed situation, such as during interactive simulation or from a PLI for which there was not enough information at compile time to decide that this PLI call may affect the kind of certain signals.

The method of claim 2 must be enhanced for the purpose of loading a signal in memory for fast processing by replacing the function dbLoadSignal with dbLoadSignalXL.

9. The method of claim 5 further including the capability of supporting partially derived or auto-generate signals (i.e. signals that change their property of being auto-generate or derived at a certain time during the simulation). This method must include the step for efficiently (i.e. only when needed) checking whether the given signal maintains its property. This check must be performed whenever a transaction on the signal is reported during a non pre-analyzed situation, such as during interactive simulation or from a PLI for which there was not enough information at compile time to decide that this PLI call may affect the kind of certain signals.

The method of claim 2 must be enhanced for the purpose of loading a signal in memory for fast processing by replacing the function dbLoadSignal with dbLoadSignalXL.