Test results checking via predictive-reactive emulation

• US 6,332,201 B1
• Filed: 03/23/1999
• Issued: 12/18/2001
• Est. Priority Date: 03/23/1999
• Status: Expired due to Term

• Current Assignee: Samsung Electronics Co. Ltd.
• Original Assignee: Hewlett-Packard Company (HP Inc.)
• Inventors: Subramanian, Raghu, Chin, Richard
• Primary Examiner(s): Iqbal, Nadeem
• Application Number:
  US09/273,582
• Time in Patent Office: 1,001 Days
• Field of Search: 714/28, 714/29, 714/25, 714/26, 714/33, 714/34, 714/37, 714/47, 703/14, 703/15, 703/20
• US Class Current: 714/28
• CPC Class Codes: G01R 31/318342 by preliminary fault modelling, e.g. analysis, simulation
• CPC Class Codes: G01R 31/318357 Simulation computer simulation of digital circuits G06F30/3308
• CPC Class Codes: G06F 30/33 Design verification, e.g. functional simulation or model checking

Abstract

A function for verifying the behavior of a digital system, where the digital system can exhibit several differing but valid behaviors from the same input. Identical input vectors are applied to both a hardware model and hardware emulator of the digital system via a simulator. Simulating the hardware emulator generates one or more predicted output vectors, while simulating the hardware model produces a single output vector. The output vector of the hardware model is then compared with the one or more predicted output vectors of the hardware emulator. If there is not an output match, an exception is raised. If the output vector of the hardware model matches one of the predicted output vectors of the hardware emulator, a rules checker applies a set of context specific rules defining a valid behavior to the current matching output vector, the internal model state information from the hardware emulator, and a history file of previous output vectors. If the current matching output vector passes the rules checker, the hardware emulator reacts by updating its internal state information and the verification continues with a new input vector, otherwise an exception is raised indicating a rules violation.

Claims

1. A functional testing system for verifying the behavior of a digital system, the system comprising:

a plurality of input vectors;

a hardware model representing a relatively low-level software characterization of the digital system;

a hardware emulator representing a relatively high-level software characterization of the digital system, wherein the hardware emulator is capable of storing internal model state information;

a system simulator for applying the plurality of input vectors to the hardware model and the hardware emulator, wherein each input vector applied to the hardware model produces a corresponding model output vector and wherein each input vector applied to the hardware emulator produces one or more corresponding emulator output vectors;

a comparator comparing each of the one or more emulator output vectors to the model output vector, activating a match signal if the model output vector matches one of the one or more emulator output vectors, and providing a current matching output vector;

a history file storing matching output vectors from the comparator;

a set of context specific rules defining a valid behavior for the list of matching output vectors stored in the history file; and

a rules checker determining whether the current matching output vector is valid based on the history file, the internal model state information from the hardware emulator, the set of context specific rules, and the current matching output vector.

2. The functional testing system of claim 1, wherein the context specific rules include rules on output ordering.

3. The functional testing system of claim 1, wherein the context specific rules include rules on output persistence.

4. The functional testing system of claim 1, wherein the context specific rules include rules on port grouping/bus behavior.

5. The functional testing system of claim 1, wherein the system simulator includes:

a model simulator for simulating the hardware model; and

a predictive simulator for simulating the hardware emulator.

6. The functional testing system of claim 1, wherein the hardware model is synthesized and processed to form the digital system.

7. The functional testing system of claim 1, wherein if the comparator determines that there are no current matching output vectors between the hardware emulator and the hardware model for a given input vector, an exception handler raises an exception.

8. The functional testing system of claim 1, wherein if the rules checker determines that the current matching output vector is invalid, an exception handler raises an exception.

9. The functional testing system of claim 1, wherein if the rules checker detects a problem with the internal model state information, an exception handler raises an exception.

10. A method for verifying the behavior of a digital system, the method comprising:

defining a hardware model representing a relatively low-level software characterization of the digital system;

defining a hardware emulator representing a relatively high-level software characterization of the digital system, wherein the hardware emulator is capable of storing internal model state information;

defining a plurality of input vectors;

simulating the hardware model and the hardware emulator by applying the plurality of ordered input vectors to the hardware model and the hardware emulator, wherein each input vectors applied to the hardware model produces a corresponding model output vector, and each input vector applied to the hardware emulator produces one or more corresponding emulator output vectors;

comparing each of the one or more emulator output vectors produced by the hardware emulator to the model output vector;

activating a match signal if the model output vector matches one of the one or more emulator output vectors;

providing a current matching output vector if the model output vector matches one of the one or more emulator output vectors;

storing matching output vectors in a history file;

defining a set of context specific rules which define a valid behavior for the ordered list of matching output vectors stored in the history file; and

determining whether the current matching output vector is a valid based on the history file, the internal model state information from the hardware emulator, the set of context specific rules, and the current matching output vector.

11. The method of claim 10, wherein the step of defining the set of context specific rules includes the step of defining rules on output ordering.

12. The method of claim 10, wherein the step of defining the set of context specific rules includes the step of defining rules on output persistence.

13. The method of claim 10, wherein the step of defining the set of context specific rules includes the step of defining rules on port grouping/bus behavior.

14. The method of claim 10, wherein the hardware model is synthesized and processed to form the digital system.

15. The method of claim 10, further comprising the steps of raising an exception if the comparing step determines that there are no current matching output vectors between the hardware emulator and the hardware model for a given input vector.

16. The method of claim 10, further comprising the step of raising an exception if the determining step determines that the current matching output vector is invalid.

17. A computer readable medium containing instructions for controlling a computer system to perform a method for verifying the behavior of a digital system, comprising the steps of:

defining a hardware model representing a relatively low-level software characterization of the digital system;

defining a hardware emulator representing a relatively high-level software characterization of the digital system, wherein the hardware emulator is capable of storing internal model state information;

defining a plurality of input vectors;

simulating the hardware model and the hardware emulator with a system simulator by applying the plurality of ordered input vectors to the hardware model and the hardware emulator, wherein each input vectors applied to the hardware model produces a corresponding model output vector, and each input vector applied to the hardware emulator produces one or more corresponding emulator output vectors;

comparing each of the one or more emulator output vectors produced by the hardware emulator to the model output vector;

activating a match signal if the model output vector matches one of the one or more emulator output vectors;

providing a current matching output vector if the model output vector matches one of the one or more emulator output vectors;

storing matching output vectors in a history file;

defining a set of context specific rules which define a valid behavior for the ordered list of matching output vectors stored in the history file; and

determining whether the current matching output vector is a valid based on the history file, the internal model state information from the hardware emulator, the set of context specific rules, and the current matching output vector.

18. The computer readable medium of claim 17, wherein the context specific rules include rules on output ordering.

19. The computer readable medium of claim 17, wherein the context specific rules include rules on output data persistence.

20. The computer readable medium of claim 17, wherein the context specific rules include rules on port grouping/bus behavior.

21. The computer readable medium of claim 17, wherein the hardware model is synthesized and processed to form the digital system.

22. The computer readable medium of claim 17, wherein if the comparator determines that there are no current matching output vectors between the hardware emulator and the hardware model for a given input vector, an exception is raised by an exception handler.

23. The computer readable medium of claim 17, wherein if the rules checker determines that the current matching output vector is invalid, an exception is raised by an exception handler.