( ESNUG 310 Item 9 ) ----------------------------------------------- [2/7/99]
Subject: (ESNUG 308 #4) Initialization Test Compiler Problems (Split Chains)
> The problem I currently face with test compiler is that I have a design w/
> 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
From: [ A Synopsys Test Guy ]
Hi John,
I work at Synopsys in the Test Products Application team. I would like to
answer Suttinan Chattong's email regarding the use of read_init_protocol.
The command read_init_protocol allows the user to read the initialization
portion of a test_protocol. What we call the "initialization part" is the
section of this file contained between the
"foreach_program(){" and "...} foreach_patterns(){"
statements. This corresponds to vectors applied to the ASIC before the scan
testing proper starts with the shifting in of the fist scan vector. Only
changes in this part of the protocol will be taken into consideration by
check_test after a read_init_protocol command. That's why after reading
the modified protocol Suttiman does not observe the right value during shift.
To force a value on a port during all the test session you need to use the
command set_test_hold. The flow I would then advise is:
set_test_hold 1 find(port, TSTPAD0)
set_test_hold 0 find(port, TSTPAD1)
check_test > pass1.dft_check
set_test_hold 0 find(port, TSTPAD0)
set_test_hold 1 find(port, TSTPAD1)
check_test > pass1_mod.dft_check
Best regards,
- [ A Synopsys Test Guy ]
|
|
