Error detection/correction and fault detection/recovery – Pulse or data error handling – Digital logic testing
Reexamination Certificate
2001-04-03
2003-02-11
Tu, Christine T. (Department: 2133)
Error detection/correction and fault detection/recovery
Pulse or data error handling
Digital logic testing
C703S013000
Reexamination Certificate
active
06519727
ABSTRACT:
FIELD AND BACKGROUND OF THE INVENTION
The present invention relates to a system and method for applying flexible generation constraints, and in particular, to a system and method for applying such complex constraints to a functional verification programming environment during test generation.
Design verification is the process of determining whether an integrated circuit, board, or system-level architecture, exactly implements the requirements defined by the specification of the architecture for that device. Design verification for a device under testing (DUT) may be performed on the actual device, or on a simulation model of the device. For the purposes of explanation only and without intending to be limiting in any way, the following discussion centers upon testing which is performed on simulation models of the device.
As designs for different types of devices and device architectures become more complex, the likelihood of design errors increases. However, design verification also becomes more difficult and time consuming, as the simulation models of the design of the device also become more complex to prepare and to test.
The problem of design verification is compounded by the lack of widely generalizable tools which are useful for the verification and testing of a wide variety of devices and device architectures. Typical background art verification methods have often been restricted to a particular device having a specific design, such that the steps of preparing and implementing such verification methods for the simulation model must be performed for each new device.
The process of verifying a design through a simulation model of the device is aided by the availability of hardware description languages such as Verilog and VHDL. These languages are designed to describe hardware at higher levels of abstraction than gates or transistors. The resultant simulated model of the device can receive input stimuli in the form of test vectors, which are a string of binary digits applied to the input of a circuit. The simulated model then produces results, which are checked against the expected results for the particular design of the device. However, these languages are typically not designed for actual verification. Therefore, the verification engineer must write additional programming code in order to interface with the models described by these hardware description languages in order to perform design verification of the device.
Examples of testing environments include static and dynamic testing environments. A static testing environment drives pre-computed test vectors into the simulation model of the DUT and/or examines the results after operation of the simulation model. In addition, if the static testing environment is used to examine the results output from the simulation model, then errors in the test are not detected until after the test is finished. As a result, the internal state of the device at the point of error may not be determinable, requiring the simulation to be operated again in order to determine such internal states. This procedure consumes simulation cycles, and can require the expenditure of considerable time, especially during long tests.
A more useful and efficient type of testing is a dynamic testing environment. For this type of environment, a set of programming instructions is written to generate the test vectors in concurrence with the simulation of the model of the DUT and while potentially being controlled by the state feedback of the simulated device. This procedure enables directed random generation to be performed and to be sensitive to effects uncovered during the test itself on the state of the simulation model of the device. Thus, dynamic test generation clearly has many advantages for design verification.
Within the area of testing environments, both static and dynamic testing environments can be implemented only with fixed-vector or pre-generation input. However, a more powerful and more sophisticated implementation uses test generation to produce the environment. Such test generation involves the production of a random or pseudo-random testing environment, either through a custom generator program or else through a configurable generator. The custom generator program poses difficulties for reuse, in that it is typically designed for one specific hardware device as the DUT, and as such may be difficult or impossible to use for other devices.
Configurable generators can be further divided into two subcategories: template-based generators and constraint-based generators. Template-based generators for producing testing environments are domain specific, in the sense that they are only useful for certain types of hardware. If the device under test does not fit into the requirements of the template, then the template-based testing environment is not useful. For example, U.S. Pat. No. 5,202,889 discloses a process for generating biased pseudo-random test patterns for testing the design of an integrated circuit such as a microprocessor. However, as disclosed this process is heavily dependent upon the pre-defined templates produced for the particular architecture and function of the hardware, such as interactions with registers, and as such would be difficult to generalize to all types of test generation for different DUT's. Furthermore, the disclosed process does not feature constraints or other relatively complex test generation expressions, further limiting the possible scope of the disclosed method for test generation.
Constraint-based generators, by contrast, are able to accommodate many different types of hardware, rather than hardware in a particular domain. One example of such a constraint-based test generation procedure is disclosed in U.S. patent application Ser. No. 09/020,792, filed on Feb. 6, 1998, incorporated by reference as if fully set forth herein. This test generation procedure interacts with, and sits as a higher level over, such hardware description languages as Verilog and VHDL. The test generation procedure is written in a hardware-oriented verification specific object-oriented programming language. This language is used to write various tests, which are then used to automatically create a device verification test by a test generator module. A wide variety of design environments can be tested and verified with this language. Thus, the disclosed procedure is generalizable, yet is also simple to program and to debug by the engineer.
The disclosed language features a number of elements such as structs for more richly and efficiently describing the design of the device to be simulated by the model. Structs are compound data structures. A struct definition is the basic data abstraction mechanism used to encapsulate data, data-relations and procedural activity in one single entity. A struct can therefore also be described as an object-oriented programming class. Each struct features one or more fields for storing data.
Among the disclosed features of the test generation procedure is the possibility to specify declarative relations between fields of a struct as constraints. Constraints are directives for the test generation. For example, type constraints are declared in the context of a struct, and are used to impose constraints on the values generated for the fields in a struct. A constraint can be used to restrict the possible values generated for fields in a particular run of a test. The restriction can narrow the choice to a single value, or to a range of possible values. Thus, the addition of constraints can direct and restrict the test generation procedure.
Unfortunately, as disclosed in U.S. patent application Ser. No. 09/020,792, these constraints are only operative according to the order of presentation, rather than according to any flexible, “logical” order. Therefore, the disclosed constraints are rigid in nature, in the sense that altering the order of presentation of the constraints may change the outcome of applying these constraints, according to the disclosure of U.S. patent application Ser. No. 09/020,792. Thus, a
G.E. Ehrlich Ltd
Tu Christine T.
Verisity Ltd.
LandOfFree
System and method for applying flexible constraints does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for applying flexible constraints, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for applying flexible constraints will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3182617