( ESNUG 308 Item 4 ) ---------------------------------------------- [1/20/99]
From: "Suttinan Chattong" <suttinan@cyberway.com.sg>
Subject: Inexplicable Initialization Test Compiler Problems (Split Chains)
Hi John,
This is the first time I'm posting to ESNUG, I hope I'm posting this
message to the right place.
The problem I currently face with test compiler is that I have a design with
an embedded macro which requires initialization sequence to bring it into
scan test mode. Also there are many scan chains in the design, that we
decided to have two scan tests - one for one half of the design and the
other for the other half. The choice of which scan test to select is done
via external pins ("01" means enabling scan test for one half, and "10"
means enabling scan test for the other half). These external pins are
called TSTPAD1 and TSTPAD0.
The requirement of initialization sequence means we have to modify the test
protocol. So our ATPG script goes like this:
set_test_hold 1 find(port, TSTPAD0)
set_test_hold 0 find(port, TSTPAD1)
check_test > pass1.dft_check
write_test_protocol -out pass1.tpf
Then we modify the initialization sequence of the test protocol, and then
we do
read_init_protocol pass1_mod.tpf
check_test > pass1_mod.dft_check
John, what we found very puzzling about this check_test report is that the
TSTPAD(1:0) = "01" during the initialization vector, after which (during
scan in & parallel vector), it is "10" ??????!!!! This is very puzzling,
since the "pass1_mod.tpf" test protocol is based on "pass1.tpf" test
protocol that we've written out in the first step, for which TSTPAD(1:0) is
asserted to "01" always. Also, in "pass1_mod.tpf" we are leaving the
ports TSTPAD(1:0) untouched, so the test_hold effect of the original test
protocol should be passed to the "pass1_mod.tpf". Somehow this effect is
not as expected.
Does anyone know what might have gone wrong? I'd be most grateful if you
can shed some light on this issue.
- Suttinan Chattong
Cyberway Singapore
|
|
