Error detection/correction and fault detection/recovery – Pulse or data error handling – Digital logic testing
Reexamination Certificate
2000-09-21
2002-02-12
Decady, Albert (Department: 2133)
Error detection/correction and fault detection/recovery
Pulse or data error handling
Digital logic testing
Reexamination Certificate
active
06347388
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The invention relates to testing electronic circuitry. More particularly, the invention relates to a method and apparatus for verification of such electronic circuitry in integrated circuits, boards, and systems.
2. Description of the Prior Art
Design verification is the process of determining whether a particular hardware and software combination, such as an integrated circuit (IC), exactly implements the requirements defined by the IC's specification. As IC designs become more complex, the likelihood of design errors increases. However, design verification also becomes increasingly difficult and time consuming.
A typical prior art design verification scheme is devised in accordance with the device's specifications. A comprehensive test plan for the design is then devised and implemented. The verification scheme and test plan are usually both device-specific, and must therefore be revised or generated anew for each device to be tested.
Verification of a device under testing (DUT) frequently requires the DUT to be tested through integration cycles, as well as through specification changes. Additionally, the tester must determine the coverage of a test, for example, between subsystem and full-system verification, to determine if the testing is to be continued or has already been completed.
Verification testing may be performed on the actual device, or on a simulation model of the device. For purposes of explanation only, the following discussion will be limited to simulation models.
As systems become larger and more complicated, functional verification consumes a larger percentage of engineering resources. Furthermore, the prior art verification tools do not achieve the same level of abstraction as the design specification used for verification. Thus, the test generation tools may not allow the use of the abstract data types required to model a design.
Hardware Description Languages (HDLs) such as Verilog and VHDL are used to verify a design through the comparison of at least two design representations. Low-level netlists also perform a similar type of verification procedure. In this procedure, HDL and Netlist views of a design are simulated. Input stimuli to the simulator can come from a variety of sources. Checking is done by comparing results or behavior with the expected results that are either concluded by the designer or computed by a predictor simulator.
HDLs are designed to describe hardware at higher levels of abstraction than gates or transistors. However, such HDLs are typically not designed for verification. Thus, a verification engineer must often design a verification testbench that includes interfaced HDL programming, C or C++ programming, and various scripts.
In a system-level simulation approach, a designer builds a hierarchical, modular model of the entire device system. Test vectors are then developed to verify the functionality of the system. A test vector is a string of binary digits that is applied to an input of a circuit. The test vector is used to compare the circuit's output to the expected results.
In the prior art, the solution to increasing verification productivity has been to introduce increasingly faster simulators. Modeling and simulation can be accelerated through use of, for example, hardware modelers, commercial bus-functional models, simulator accelerators, and Field Programmable Gate Array (FPGA)-based Application Specific Integrated Circuit (ASIC) emulators.
However, the prior art mechanisms have not adequately addressed the reduction of verification development time. Verification engineers are still needed to write functional tests, develop diagnostic suites, determine test coverage, and analyze the results.
Verification engineers typically use combinations of deterministic, static, and dynamic tests to construct testing tools. In deterministic testing, each test is developed, checked, and executed manually. While some level of automation can be introduced into the testing process, deterministic testing still generally requires significant efforts of skilled personnel.
Deterministic tests are usually design-specific. Therefore, re-use of such a verification procedure is difficult, if not impossible. With the time, cost, and personnel constraints imposed by current marketing conditions, functional coverage by means of deterministic testing alone is usually low.
A static testbench is a program that drives pre-computed test vectors into the DUT simulator, and/or checks outputs after the simulation is completed. Such static testbench is frequently used to increase functional coverage during design development. A static testbench can include elements such as HDL Behavioral Functional Models (BFMs), monitors, and memories, as well as random test generators and post-run-checkers.
Generally, a static testbench is used to check the results of a test after the test has been completed. Thus, an error in the test is not detected until after the test is finished. As a result, the internal state of the device at the point of the error is not determined. To analyze signals and register states, the test must be re-run to the point at which the error occurred. This procedure consumes simulation cycles, and can require the expenditure of considerable time, especially during long tests.
A static testbench usually requires as least as much, and frequently twice the amount of code as the HDL model to which it is applied. The static testbench code is difficult to manage and control. Additionally, a static testbench is almost completely design-specific, and contains fixed code, written for one design. Thus, a static testbench is rarely re-usable for a next-generation design.
Parameter-driven test generation can be used to overcome the limitations of a static testbench. In this procedure, a program is written, for example in the C language, to generate test vectors. These test vectors are stored to a memory storage device, such as a hard drive, prior to the commencement of the test. C code is versatile and allows the creation of functions that can be reused for different device designs.
Parameter-driven test generation allows directed random generation. For example, a directed random generator can be used to test a communications device by creating large numbers of test packets meeting known parameters.
Parameter-driven test generation can support a low level of interaction with the HDL model. This is because the test program can be directed to send new stimuli to the simulator only after the occurrence of particular events. However, parameter-driven test generation is static. Thus, parameter-driven test generation cannot shape such stimuli in response to a model's state. It is therefore often difficult to generate exactly the correct stimulus to bring about the required state of the device for design errors detection.
For example, in certain memory controllers, a write to the master Direct Memory Access (DMA) count register should abort the current transaction. However, using a static procedure, it is extremely difficult to generate a test to verify that this will happen even if the write occurs in the last clock cycle of the current transaction.
A program that generates test vectors in concurrence with the DUT simulation and while being controlled by the state feedback of the simulated device is known as a dynamic testbench. A dynamic testbench can therefore be used to shape test vectors in response to device states. In such dynamic testbench, the test programs interact with the HDL model through an Application Program Interface (API) supported by the underlying simulator.
However, the implementation of such API is not a simple task. API implementation can differ among simulators. For example, each VHDL simulator has a different API. While Verilog uses a standard Procedural Language Interface (PLI), the interface is not always the same, especially between event-driven and cycle-based simulators. Additionally, if more than one simulator is used, such as a cycle-based simulator at the
Chase Shelly A
De'cady Albert
Glenn Michael A.
Verisity Ltd.
LandOfFree
Method and apparatus for test generation during circuit design 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 test generation during circuit design, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for test generation during circuit design will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2985500