Automated test vector generation and verification

Details Automated test vector generation and verification Automated test vector generation and verification

1998-09-24

2001-10-16

Teska, Kevin J. (Department: 2123)

Data processing: structural design, modeling, simulation, and em

Simulating electronic device or electrical system

Circuit simulation

C716S030000

Reexamination Certificate

active

06304837

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to integrated circuits, and more particularly to methods for automated test vector generation and verification.
2. Description of the Related Art
Testing integrated circuits that are ultimately fabricated onto silicon chips has over the years increased in complexity as the demand has grown, and continues to grow for faster and more densely integrated silicon chips. In an effort to automate the design and fabrication of circuit designs, designers commonly implement hardware descriptive languages (HDL), such as Verilog, to functionally define the characteristics of the design. The Verilog code is then capable of being synthesized in order to generate what is known as a “netlist.” A netlist is essentially a list of “nets,” which specify components (know as “cells”) and their interconnections which are designed to meet a circuit design's performance constraints. The “netlist” therefore defines the connectivity between pins of the various cells of an integrated circuit design. To fabricate the silicon version of the design, well known “place and route” software tools that make use of the netlist data to design the physical layout, including transistor locations and interconnect wiring.
When testing of the digital model, various test vectors are designed in order to test the integrated circuit's response under custom stimulation. For example, if the integrated circuit is a SCSI host adapter chip, the test vectors will simulate the response of the SCSI host adapter chip as if it were actually connected to a host computer and some kind of peripheral device were connected to the chip. In a typical test environment, a test bench that includes a multitude of different tests are used to complete a thorough testing of the chip. However, running the test vectors of the test bench will only ensure that the computer simulated model of the chip design will work, and not the actual physical chip in its silicon form.
To test a silicon chip
12
after it has been packaged, it is inserted into a loadboard
14
that is part of a test station
10
, which is shown in FIG.
1
A. Although the model of the chip design was already tested using the test vectors of the test bench, these test vectors are not capable of being implemented in the test station
10
without substantial modifications, to take into account the differences between a “model” and a “physical” design. In the prior art, the conversion of a test model test vector into test vectors that can actually be run on the test station
10
required a very laborious process that was unfortunately prone to computer computational errors as well as human errors. Of course, if any type of error is introduced during the generation of the test vectors that will ultimately be run on the silicon chip
12
, the testing results generated by the test station
10
would indicate that errors exist with the part, when in fact, the part functions properly. This predicament is of course quite costly, because fabrication plants would necessarily have to postpone release of a chip until the test station indicated that the part worked as intended.
As mentioned above, the prior art test vector generation methodology was quite laborious, which in many circumstances was exacerbated by the complexity of the tests and size of the chip being tested. The methodology required having a test engineer manually type up the commands necessary to subsequently generate a “print-on-change” file once executed using Verilog. Defining the commands for generating the print-on-change file includes, for example, typing in the output enable information for each pin, defining pin wires, setting up special over-rides for power-on reset pins, etc. At this point, the print-on-change file would then be generated using a Verilog program, which in turn uses the commands generated by the test engineer.
In addition to manually producing these commands, a separate parameter file having timing information is separately produced in a manual typing-in fashion by the engineer. The generated print-on-change file and the parameter file are then processed by a program that is configured to produce a test file, which is commonly referred to as an AVF file. However, the production of the AVF is very computationally intensive because the generated print-on-change file can be quite large. The size of the print-on-change file grows to very large sizes because every time a pin in the design changes states, a line of the print-on-change file is dumped. Thus, the more pins in the design, more CPU time is required to convert the print-on-change file into a usable AVF file. In some cases where the test is very large or complex, the host computer processing the print-on-change file is known to crash or in some cases lock-up due to the shear voluminous amount of data.
Unfortunately, as mentioned above, the generated AVF file may have defects, such as timing errors, which may translate into errors being reported by the test station
10
. The problem here is that the test station
10
will stimulate the part differently than the stimulation designed for the digital version. This problem therefore presents a very time consuming test and re-test of the part by the test station
10
. When re-testing is performed, many modifications to the parameter file, containing timing information, are performed in an effort to debug errors with the AVF file. Although some parts are in fact defective in some way, the test engineer is still commonly required to re-run the tests to determine whether the errors are due to a defective AVF file or the physical device.
In view of the foregoing, there is a need for a method that reduces test vector generation cycle time, as well as increases the accuracy of test vector generation and simulation processes. Another need exists for a new method for automating the generation of the initial AVF file, which reduces computation time and reduces test engineer manual interaction that is susceptible to the introduction of errors. There is also a need for a method for automatically verifying whether the generated AVF file is free of defects, which will enable a substantial reduction in test cycle time.
SUMMARY OF THE INVENTION
Broadly speaking, the present invention fills these needs by providing a method to reduce test vector generation cycle time, as well as increase the accuracy of test vector generation and simulation processes. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below.
In one embodiment, a method for generating AVF test file data for use in testing a simulation of an integrated circuit design and subsequently testing a physical silicon version of the integrated circuit design is disclosed. The method includes providing a map file that contains a plurality of identifying statements for each multiple port I/O cell in the integrated circuit design. Then, generate a verilog executable file for the integrated circuit design. The verilog executable file is configured to contain data associated with the map file, output enable data derived from a netlist, and AVF data conversion information. The method further comprises executing the verilog executable file along with a test bench that includes the netlist of the integrated circuit design, a set of test files, and models. The execution is configured to produce the AVF test file data and a DUT timing file data.
In another embodiment, an automated test vector verification method is disclosed. The method includes receiving an AVF test file of an integrated circuit design and receiving a DUT test file of the integrated circuit design. The method then executes using the AVF test file and the DUT test file to produce an input vector (.invec), an environment file (.env), and an expected output vector (.outvec). Then, the method provides the input v

Affiliated with

Also associated with

Rating

Automated test vector generation and verification does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Automated test vector generation and verification, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Automated test vector generation and verification will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2574696