 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to integrated circuits, and more
particularly to methods for performing computer model at-speed testing of
integrated circuit designs.
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. 1A.
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.
Furthermore, most conventional testing techniques require that the physical
part actually be placed into the physical test station. At that time, the
physical test station only allow test engineers to test parts at speeds
that are a fraction of the true operating speeds of the integrated circuit
design part. As a result, many times integrated circuit designs that are
believed to work properly under test conditions will fail once they are
exposed to their true functional operating speeds. This of course
increases the cost of developing, testing, re-testing, and redesign of
integrated circuit devices.
In view of the foregoing, there is a need for methods and computer readable
media for testing integrated circuit designs via a computer model that
enables testing at speeds that resemble actual functional operating speeds
in order to reduce testing uncertainties, customer returns, and thereby
increase customer satisfaction.
SUMMARY OF THE INVENTION
Broadly speaking, the present invention fills these needs by providing
techniques for testing integrated circuit design computer models at speeds
that resemble those of normal operating physical integrated circuit
designs. The present invention further discloses test vector conversion
techniques that take into account temperature and silicon variations which
lead to variations in operating speeds. The converted test vectors are
thus capable of being run on both integrated circuit design models having
slow speed characteristics and those having fast speed characteristics
without producing erroneous test data. 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 computer implemented method for performing testing of
a computer model of an integrated circuit design is disclosed. The method
includes generating a first AVF test file for a first integrated circuit
design having slow characteristics and generating a second AVF test file
for a second integrated circuit design having fast characteristics. The
method then proceeds to comparing test file parameters from the first AVF
test file and the second AVF test file. After the comparing, the method
moves to generating a modified AVF test file that takes into account the
comparing of the test file parameters from the first test file and the
second test file. The modified AVF test file is therefore suitable for
running on both the first integrated circuit design and the second
integrated circuit design.
In another embodiment, a computer implemented method for performing pin
margin testing of a computer model of an integrated circuit design that is
tested on a computer model of a physical tester is disclosed. The method
includes: (a) performing pin margin testing on a first integrated circuit
design having slow characteristics and a second integrated circuit design
having fast characteristics; (b) recording miscompares detected during the
pin margin testing of the first integrated circuit design and the second
integrated circuit design; (c) applying strobe timing variations to the
computer model of the physical tester; (d) recording miscompares detected
during the applying of the strobe timing variations; (e) generating a plan
file that contains instructions on how to fix miscompares detected during
the pin margin testing and the strobe timing variations; and (f) running a
post processor in a plan mode that is configured to generate a pin
margining correct AVF test file. Once the post processor is run in plan
mode, a verification run of the pin margining corrected AVF test file is
run in order to find any additional miscompares.
In yet another embodiment, a computer readable media containing program
instructions for performing testing of a computer model of an integrated
circuit design is disclosed. The computer readable media includes: (a)
program instructions for generating a first AVF test file for a first
integrated circuit design having slow characteristics; (b) program
instructions for generating a second AVF test file for a second integrated
circuit design having fast characteristics; (c) program instructions for
comparing test file parameters from the first AVF test file and the second
AVF test file; and (d) program instructions for generating a modified AVF
test file that takes into account the comparing of the test file
parameters from the first test file and the second test file.
Other aspects and advantages of the invention will become apparent from the
following detailed description, taken in conjunction with the accompanying
drawings, illustrating by way of example the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be readily understood by the following detailed
description in conjunction with the accompanying drawings, wherein like
reference numerals designate like structural elements.
FIG. 1 illustrates a test station that is typically used in testing
physical silicon integrated circuit devices.
FIG. 2 illustrates a flowchart that details the operations performed in
generating an AVF file, a DUT file, and a log file in accordance with one
embodiment of the present invention.
FIG. 3 illustrates a flowchart which illustrates the execution of the AVF
generator (avfgen) that is configured to produce an avf.v file in
accordance with one embodiment of the present invention.
FIG. 4A illustrate example AVF generator commands in accordance with one
embodiment of the present invention.
FIGS. 4B and 4C illustrate a more simplified example of a chip design and
an associated command line entry in accordance with one embodiment of the
present invention.
FIG. 5A illustrates a flowchart defining the method operations performed in
generating a map file for a particular chip design in accordance with one
embodiment of the present invention.
FIGS. 5B and 5C illustrate an example of a multiple I/O port cell and a map
file entry in accordance with one embodiment of the present invention.
FIG. 5D illustrates the method of generating a map file for all I/O cells,
including single and multi port cells, in accordance with one embodiment
of the present invention.
FIG. 6A illustrates an example of the method operations performed in
generating a list of pins for the chip design in accordance with one
embodiment of the present invention.
FIGS. 6B through 6D illustrate tables that are implemented during the
generation of the AVF file and DUT file data in accordance with one
embodiment of the present invention.
FIG. 7A illustrates a more detailed description of the sub-method
operations of an operation of FIG. 3 where output enables are defined for
each pin or pad in the chip design, in accordance with one embodiment of
the present invention.
FIG. 7B illustrates an example of an AVF data conversion truth table, in
accordance with one embodiment of the present invention.
FIG. 8A illustrates the method operations performed when timing data is
generated for the production of the DUT file in accordance with one
embodiment of the present invention.
FIG. 8B is a table illustrating an exemplary statement timing calculation
in accordance with one embodiment of the present invention.
FIG. 9 illustrates a more detailed flowchart diagram of the method
operations performed in FIG. 3 when generating a display statement in
accordance with one embodiment of the present invention.
FIG. 10 illustrates a flowchart diagram of an AVF test vector verification
loop in accordance with one embodiment of the present invention.
FIG. 11A illustrates a flowchart identifying the operations performed
during AVF data verification in accordance with one embodiment of the
present invention.
FIG. 11B illustrates pictorial examples of a multitude of tests that may be
run as part of the test files in order to stimulate the chip design under
test, in accordance with one embodiment of the present invention.
FIG. 12 illustrates a flowchart that describes the generation of a Verilog
environment file that is subsequently executed in an operation of FIG.
11A, in accordance with one embodiment of the present invention.
FIG. 13 illustrates an at-speed test vector conversion procedure used in
testing integrated circuit designs that are computer models of a physical
integrated circuit design, in accordance with one embodiment of the
present invention.
FIG. 14A illustrates a flowchart diagram that defines the method operations
performed during an at-speed test procedure in accordance with one
embodiment of the present invention.
FIG. 14B provides a pictorial illustration of an AVF test file for a slow
part and a fast part, in accordance with one embodiment of the present
invention.
FIG. 14C illustrates an speed-corrected modified AVF test file after the
comparison operations were performed to generate the changes to the output
signals, in accordance with one embodiment of the present invention.
FIG. 15 illustrates a flowchart of the at-speed test vector conversion
process, in accordance with another embodiment of the present invention.
FIG. 16 shows an at-speed conversion block diagram in accordance with one
embodiment of the present invention.
FIG. 17 illustrates a flowchart diagram of the method operations performed
during pin margin testing in accordance with one embodiment of the present
invention.
FIG. 18 illustrates a more detailed flowchart diagram of operation 766 of
FIG. 17 in which strobe variations are performed and any miscompares are
recorded, in accordance with one embodiment of the present invention.
FIG. 19 is a flowchart illustrating method operations for performing pin
margin testing in accordance with another embodiment of the present
invention.
FIG. 20 illustrates a flowchart diagram identifying the method operation
that may be performed during signal swallow investigations, in accordance
with one embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
An invention for testing integrated circuit design computer models at
speeds that resemble those of normal operation of the physical integrated
circuit design, before testing is performed on the actual physical
integrated circuit design. The present invention also discloses test
vector conversion techniques that take into account temperature and
silicon variations which lead to variations in operating speeds. The
converted test vectors are thus capable of being run on both integrated
circuit design models having slow speed characteristics and those having
fast speed characteristics without producing erroneous test data. In the
following description, numerous specific details are set forth in order to
provide a thorough understanding of the present invention. It will be
understood, however, to one skilled in the art, that the present invention
may be practiced without some or all of these specific details. In other
instances, well known process operations have not been described in detail
in order not to unnecessarily obscure the present invention.
As discussed above, FIG. 1 illustrates a test station 10 that is typically
used in testing integrated circuit devices. The test station 10 typically
includes a computer station which is coupled to a unit that has a
loadboard 14. The loadboard 14, as is well known in the art, is used to
receive integrated circuit devices 12. By the time testing is performed on
the test station 10, the integrated circuit device 12 will be in a
packaged form and has the proper package pins that will communicate with
appropriate electrical receptacles on the load board 14. The following
description will therefore detail the computer process implemented in
automating the generation of test vectors and the automated verification
of the test vectors before they are transferred to the test station 10 for
use in testing the packaged circuit device 12. Section A will therefore
describe the automated generation of the AVF file data and DUT timing file
data (e.g., that includes the execution of avfgen and avf.v), and section
B will describe the automated verification loop (e.g., that includes the
execution of avf2vlg) that is executed to verify the generated AVF file
data.
A. Automated AVF and DUT Data Generation
FIG. 2 illustrates a flowchart 100 that details the operations performed in
generating an AVF file, a DUT file, and a log file in accordance with one
embodiment of the present invention. The method begins at an operation 102
where a chip design is provided for testing along with a netlist for the
chip design. Also provided are testing parameters for the chip design,
such as the file names for the chip design, the file name for the netlist,
whether or not debugging information will be generated along with the
file, instantiations for the chip and the I/O pads, the pin number for the
power-on reset pin, etc.
Once these testing parameters have been provided in operation 102, the
method will proceed to an operation 104 where a map file is provided for
the chip design. As will be described below with reference to FIGS. 5A
through 5C, the map file will identify a port/pin map list for each of the
multiple port cells. Accordingly, for each multi-port cell, the instance
for the cell, the ports for the cell, the enable information for the cell,
and the pin numbers for the cell will be generated as an entry in the map
file. Once a map file having a plurality of entries for each of the
multi-port cells is provided, the method will proceed to an operation 106.
In operation 106, an AVF generator (avfgen) is provided, which is
configured to be executed by using the information provided in operations
102 and 104. The method now proceeds to operation 108 where the AVF
generator is executed to produce an "avf.v" file, which is a Verilog
executable file. The avf.v file is then provided as part of a test bench
for testing the target chip design. As shown, the test bench will
generally include test files 110a, the avf.v file 110b, a netlist 110c for
the chip design, and a set of models 110d. The test files 110a include
information that details the wiring information for interconnecting the
chip design to the set of models 110d. In addition, the test files 110a
also include information that will detail the commands that are designed
to stimulate the chip design under test and in accordance with the
appropriate timing.
It should be noted that the avf.v file 110b is a generic file that will
work with all of the tests provided in the test files 110a. Once the test
bench has been established, the method will proceed to make the test bench
information accessible to operation 112, where the test bench is executed
to generate an AVF file 114, a DUT file 116, and a log file 118.
FIG. 3 illustrates a flowchart 200 which illustrates the execution of the
AVF generator that is configured to produce the avf.v file as described
with reference to 108 of FIG. 2. Initially, the method begins at an
operation 202 where the command line is set up to generate an avf.v file
using a netlist of the chip design. As mentioned above, the avf.v file can
then be subsequently executed along with a test bench in order to generate
the desired AVF file and the DUT file.
Setting up the command line generally entails typing in the correct data to
enable running the AVF generator and a desired chip design, and its
associated instantiations, map file, and netlist. FIG. 4A illustrates the
typically commands that may be provided in a command line when it is
desired to generate the avf.v file. As shown, a command line 202a is
provided with a reference to avfgen and associated commands for running
the AVF generator. The typical commands include, -V, -P, -0 FILENAME, -M
FILENAME, -N FILENAME, -T TOP INSTANCE, -I IOPAD INSTANCE, and -R RESET
PIN NUMBER. These identifying commands will therefore assist the AVF
generator in producing the proper avf.v file for the desired chip design
and associated netlist. FIGS. 4B and 4C illustrate a more simplified
example of a chip design 226 and an associated command line entry. For
example, the chip design 226 includes associated instantiations for u_top
232, u_iopad 234, and u_top.x 236. These example instantiations identify
some characteristics for this simplified chip design 226. Accordingly, the
command line entry referenced in 202a of FIG. 3 for the simplified chip
design 226 would read as shown in FIG. 4C.
Referring once again to FIG. 3, once the setup of the command line is
complete, the method will proceed to execute the AVF generator to produce
the avf.v file in operation 108. The generation of the avf.v file begins
at an operation 204 where a map file is read into memory for the desired
chip design. Next, the method will proceed to an operation 206 where the
netlist for the chip design is read in order to generate a list of pins
based in part from data in the map file that is stored in memory. Once the
list of pins have been generated in operation 206, the method will proceed
to an operation 208 where output enables for each pin in the chip design
are identified.
The method now proceeds to an operation 210 where an AVF data conversion
function is defined that considers output enabled data, current pin
values, and power-on reset states. Once the AVF data conversion function
has been defined in operation 210, the method will proceed to an operation
212 where the list of pins stored in memory are retrieved to generate code
that produces timing for a DUT file for each pin in the list of pins. The
method now proceeds to an operation 214 where a large display statement
(i.e., a Verilog statement) is produced to enable the generation of a line
of the AVF file for a particular cycle. In general, generating a display
statement includes, performing a function call (for each pin) to the AVF
data conversion table (i.e., FIG. 7B), and then taking the result from the
function call and placing it into the proper entry location in the AVF
file.
After the large display statement has been produced in operation 214, the
method proceeds to an operation 216 where a DUT creation code is
generated. As will be described below, the DUT creation code is configured
to produce the DUT file once the avf.v file produced in 108 is executed
along with the test bench. Once the DUT creation code has been generated
in operation 216, the method of flowchart 200 will be done. As described
above with reference to FIG. 2, the avf.v file 110b and other test bench
files may then be executed to generate the AVF file 114, the DUT file 116,
and 10 the log file 118.
Accordingly, the avf.v file that is produced when the AVF generator is
executed, may be used with any number of test files 110a and associated
models 110b, in order to test the true functionality of the chip design
under test. Reference may be made to Table B, which is an exemplary AVF
file that may be generated once the test bench for a particular design is
executed. Appendices B-1 through B-3 illustrates an exemplary DUT file 116
that may also be generated when the Verilog test bench executable files
are executed.
FIG. 5A illustrates a flowchart 250 that identifies the method operations
performed in generating a map file for a particular chip design in
accordance with one embodiment of the present invention. The method begins
at an operation 252 where cell types and their associated logical
functionality are identified from the netlist of the chip design. Once the
cell types and their associated logical functions have been identified,
the method will proceed to an operation 254 where the method will proceed
to a next multiple I/O cell in the netlist for the chip design.
Initially, the method will go to the first multiple I/O cell. Once at the
first multiple I/O cell, the method will proceed to an operation 256 where
the multiple I/O cell is formatted in an identifying statement. FIG. 5B
illustrates one example of a multiple I/O cell that may be part of the
chip design. In the example of FIG. 5B, an instance of an oscillator
(u_OSC) is provided having a dataport 1 and a dataport 2. The multiple I/O
oscillator is shown having a first pin and a second pin. The first pin is
assigned pin number 34, and the second pin is assigned pin number 35.
Dataport 1 of the first cell is shown having output enabled data .ned 1,
and .neu 1. Dataport 2 is shown having output enabled data .ned 2 and .neu
1.
Therefore, for this exemplary multiple I/O cell of FIG. 5B, the identifying
statement formatted in operation 256 is shown in FIG. 5C as 256'. This
exemplary map file entry will therefore identify the oscillator as being a
multiple I/O cell, which is part of the netlist. The method will now
proceed to an operation 258 where it is determined if there is a next
cell. If there is a next cell, the method will proceed to an operation 252
where the cell types and their associated logical functionality are
identified. Now, the method will again proceed to operation 254 where the
method will move to the next multiple I/O cell in the netlist for the chip
design. Once the next multiple I/O cell in the netlist for the chip design
is identified, it will be formatted in a proper identifying statement in
operation 256. This method will therefore continue until there are no more
multiple I/O cells in the netlist. At that point, the method of generating
a map file 250 will be complete.
FIG. 5D is a flowchart 270 illustrating the method operation performed in
generating a map file for all I/O cells including single port cells and
multi port cells, in accordance with one embodiment of the present
invention. The method begins at an operation 272 where all cell types and
their associated logical functionality are identified. Once all cell types
have been identified, the method will proceed to an operation 274 where
the method will proceed to a next cell type in the list of I/O cells.
Initially, the method will begin with the first cell in the list of I/O
cells. Then, the method will proceed to a decision operation 276 where it
is determined whether the current cell is either a single port or a
multi-port cell.
If the current cell is a single-port cell, the method will proceed to an
operation 278 where an output-enable equation for the current single-port
cell type is generated. Once the output-enable equation has been
generated, the method will proceed to an operation 280 where the port name
associated with the signal name is input into the map file. Specifically,
this operation informs the program where to look for the signal name. This
is needed because for each cell type, the signal name will be at a
different port. Once operation 280 has been performed, the method will
proceed to a decision operation 282 where it is determined whether there
are anymore cells in the list of I/O cells. If there are no more cells,
the method will be done. Alternatively, if there are more cells, the
method will proceed back to operation 274.
Assuming now that the current cell in decision operation 276 is a
multi-port cell, then the method will proceed to an operation 284. In
operation 284, an output-enable equation will be generated for the current
pin/pad of the multi-port cell type. Next, the method will proceed to an
operation 286 where the port name associated with the signal name for a
current port is input into the map file. Once the input has been performed
for the current port, the method will proceed to a decision operation 288
where it is determined whether there are anymore ports in the current
multi-port cell. If there are, operations 284 and 286 will be repeated for
each port in the multi-port cell Once all ports have been completed for
the multi-port cell, the method will proceed to decision operation 282
where it is determined if there are anymore cells in the list of I/O
cells. If there are, the method will again proceed back up to operation
274 where the next cell type will be identified. Alternatively, if it is
determined in operation 282 that there are no more cells in the I/O cell
list, the method will be done.
An example of the map file entries for single port and multi-port cells is
shown in Table A below. Specifically, an example for a single port cell
and a multi-port cell have been provided, including the output-enable
equations and the pin names.
TABLE A
Exemplary Map File Entries For Single/Multi Port Cells
Cell Type Single/Multi Output-Enable Equation Pin Name
Single port cell
ioej08 S "{NED} && {MEU}" {PAD};
. . . .
. . . .
. . . .
Multi port cell
ioaj06 | | |
