( ESNUG 256 Item 4 ) -------------------------------------------- [11/22/96]
Subject: ( ESNUG 251 #8 ) Test Compiler "Moody" With Test_Mode & Reset_n
> I have a question about disabling asynchronous resets during test mode.
> Test Compiler requires all asynchronous resets to be disabled during
> test mode. Should this include our primary input "reset_n" ? I have
> included this gating and I am still having problems with Test Compiler.
> The problems result on only a small amount of the flip-flops and seems
> to depend on how Test Compiler generates the logic for this gating. I
> have always thought that strobing reset should reset all of the flip
> flops in the design even if test_mode (another primary input) is a '1'.
>
> Assume active low asynchronous reset for the flip flop and when signal1
> = '1' then we want to reset the flop. There is no problem when:
>
> (reset_n and (test_mode or not signal1))
>
> There is a problem when:
>
> ((test_mode nand reset_n) nand (reset_n nand signal1))
>
> Even though Test Compiler is infering an asynchonous reset port on
> reset_n. It is not able to realize that reset_n will be a '1' when
> shifting in and out data. I have been told by a Synopsys FAE that
> test_mode= '1' should not allow reset_n to reset the flip flop although
> this has not been sitting well with me. Any advice on ESNUG would be
> greatly appreciated.
From: Bill Armstrong <army@hlds.com>
John,
This is probably rooted in the fact that it is fairly easy to generate
a set of test patterns to test an asynchronous reset and what Test
Compiler, TC, is trying to do.
TC is not only adding scan chains to the circuit, but also generating
sets of serial and parallel test vectors to cover as many stuck-at
faults in the design. The problem, I believe, is Test Compiler does
not automatically know the difference between a regular input signal
and an asynchronous reset signal. Although you'd think, by requiring
an additional property (similar to clk pins) on the flip-flops, TC
could be made to understand these types of asynchronous signals,
after all a clock signal is just a special type of asynchronous
signal.
Getting back to the point, I feel it necessary to give a little
synopsis (no pun intended, notice the spelling) on what TC actually
does when generating test patterns. TC, if memory serves and in very
basic terms, puts the circuit in normal operation, sets all of the
input signals to some state, generates a clock, and puts the circuit
into scan mode where, during several clocks, the scan registers are
serially shifted out of the circuit. These will become the known
"good" results for comparison during silicon testing. While serially
shifting data out TC is also serially shifting new data into the scan
chain to propagate to normal outputs in the next normal clock
operation. TC then puts the circuit back into normal mode, stores the
normal outputs to be used as known "good" values for testing silicon,
sets the inputs signals to another state, generates another clock,
puts the circuit into test mode, and starts serially shifting the scan
registers again. TC repeats this process until a percentage of faults
have been covered (storing results if it improves the coverage),
i.e. the faults can be controlled, setting of inputs and clocking, and
observed, either at the serial output points of the scan chain or the
parallel (normal) outputs of the circuit. Whoa, that's a mouthful. I
hope I haven't bored everyone.
Now, since TC does not know the difference between a regular,
synchronous, signal an asynchronous reset it could, and would, set the
reset such that all of the flip-flops were cleared after being setup,
during the previous serial shift operation, to propagate known values
to the normal outputs. This would reek havoc on the fault analysis TC
is trying to do and the fault coverage would be less than what could
be achievable. To explain a little further, during TC's analysis it's
looking for changes on outputs based on different patterns it feeds
into the scan chain. If the flip-flops were randomly reset the normal
outputs would be in the same state as a previous reset, independent of
what was fed into the scan chain, and TC would think this combination
of scan chain values was not valid (had no affect on the outputs),
when in fact, it may be the only combinations of values to affect a
particular node (or fault) which would propagate to an output, if the
reset signal was not active.
I think, maybe, I wrote too much. I must mention one more thing,
however, I believe Synopsys has a way of disabling asynchronous
signals in TC. The thing is you have to tell TC which signals to
disable, but this seems easier than messing with the HDL code to add
unnecessary gates, don't you think?
- Bill Armstrong
High Level Design Systems
|
|
