( ESNUG 261 Item 3 ) -------------------------------------------- [5/22/97]
From: "David C. Black" <dblack@ink.apple.com>
Subject: A Non-JTAG 1149.1 Test Compiler Technique For DC Parametrics
John,
I would like to share a Test Compiler technique I have used recently to
simplify creation of the "DC parametrics output test". For those unfamiliar
with the test, it is simply a test that places the outputs of your design
into both high and low states in as few vectors as possible. During
fabrication, this test is used to verify output drivers and bonds.
Typically, this test is hand crafted. If your design utilizes JTAG 1149.1,
the following may be uninteresting, since it is quite easy to scan values
into the output pads on a JTAG device. The following technique assumes that
you are using some form of scan, preferably full-scan, and of course the
Synopsys Test Compiler; although, some other scan tools may be able to
provide a similar feature to use this technique.
Simply, I use the Synopsys command "set_test_require" to establish that the
enables on all output drivers are active, and establish a value for the
output ports' values as well. I then initiate ATPG for the device, but only
write out a single scan vector. The "set_test_require" command directs the
Test Compiler to create a test vector pattern that establishes the
required value on the specified node. There are a few minor catches to
this approach.
First, there is a bug in TC v3.5a that must be worked around. Namely, you
cannot set_test_require the output port of a tri-state device. The simple
work-around is to set_test_require the input port. For example, if your
output pad is instantiated thusly (Verilog):
OPO53 PIN_112o ( .A(ready_out), .ENZ(ready_enable_), .Y(ready_pad) );
// INPUT ENABLE 3ST-PAD
where Y is to the tri-state output pad, use:
set_test_require "zero" find("pin","*/PIN_*o/ENZ")
set_test_require "one" find("pin","*/PIN_*o/A")
Notice that I use a consistent naming notation for the instances of my I/O
pads to simplify finding them. You could also probably use some form of
filter() to find cells that are I/O pads.
Second, you may find that Test Compiler is unable to establish the
requested set_test_require'ments because there is a logical contradiction
in your logic. For example, if one output is the complement of another,
then you will need to special case those output ports. Also, open-drain
outputs may be impossible to set high (as opposed to tri-state). When TC
finds a contradiction during create_test_patterns, you will receive a
message such as:
dc_shell> create_test_patterns -output "outhi" -backtrack_effort "high"
...SOME OUTPUT DELETED...
Loading design 'F642397'
Checking test design rules
...
Fault coverage 0.00 0.00
No. of test patterns 0
Test Generation Time (CPU) 7.00 sec
Information: No tests generated - conflicting signal
requirements in design.
Use the 'report_test -atpg_conflicts' command for more
information. (TEST-208)
Simply, follow the directions:
dc_shell> report_test -atpg_conflicts
****************************************
Report : test
-atpg_conflicts
Design : F642397
Version: v3.5a
Date : Tue Mar 11 17:22:47 1997
****************************************
Design Object Conflict Reason
------------- ---------------
uDie/uIo/S_53/Y (Pin) set_test_require "1"
1
dc_shell>
It is too bad that you only get these error messages one at a time;
however, it doesn't take much time to isolate these cases.
Eventually, I settled on a script with roughly the following:
read final.db
$OPEN_DRAIN = find("pin",{ "uDie/uIo/PIN_021o/u*/A", \
"uDie/uIo/PIN_033o/u*/A" });
$OPPOSING = find("pin",{ "uDie/uIo/PIN_210o/u*/A" });
$NEVER = find("pin",{ "uDie/uIo/PIN_056o/u*/A" });
$OUTPUTS = find("pin","uDie/uIo/PIN_*o/u*/A") - $TDO - $OPEN_DRAIN \
- $OPPOSING - $NEVER;
$ENABLES = find("pin","uDie/uIo/PIN_*o/u*/GZ") - $TDO_EN;
set_test_require zero $ENABLES >/dev/null;
set_test_require one $OUTPUTS >/dev/null;
set_test_require zero $OPPOSING >/dev/null;
set_test_require zero $OPEN_DRAIN >/dev/null;
remove_attribute $NEVER, "test_require"
create_test_patterns -output "outhi" -backtrack_effort "high"
write_test -input "outhi" -output "outhi" -format "verilog" -first 1
/* repeat for output's low */
Of course, your lists and the output format will differ.
Please use this information to get your designs through test faster, and
consider sending in your own tips to ESNUG. The more everyone shares, the
more the entire design community moves forward. Also, we all spend less
time doing reinventing the same wheels.
- David C Black
Apple Computer, Austin, TX
|
|
