76. I have been told that any logic in
the reset path creates testability problems. I would like to know exactly the
problem that would create.
I did a bit of analysis myself. If the
internal reset is OR'ed with POR and then issued as one single reset to rest of
the logic, still the internal reset comes from some flop or through a cloud
that can again be controlled through the scan chain. So we are in complete
control of how and when the internal reset is generated and can be disabled
during testing. Is the issue because, the combination that is required to
disable the internal reset might clash with combination required for testing
itself.
Any thoughts?
The
bottom line is that the resets to all the flops in scan chains need to be
controlled during the scan shift operation. If not, these resets that come from
other flops will be randomly resetting others flops duringg this time, which
makes
it impossible to scan data in and out...
Depending
on the implementation, some people use scan_enable to control the internal
resets, and some use scan_mode.
I
have couple of comments
1)
Internally generated reset is like any other logic during test mode.
If
we can control them using our scan pattern, so can we do for the internal
reset. I guess the issue here that pattern that is used to mute the internal
reset might collide with pattern that is required to test.
2)
Even though we can disable such control signal using scan signals, it is
probably preferable to keep such signals at bare minimum. This one is a pure
guess
You're
right - an internally generated reset should be valid during test mode.
However, if it emanates, in any way, from a scanned flip-flop, then it must be
gated during scan shift. If not, the integrity of the scan chain is broken.
So
the bare minimum, as you say, is probably scan_enable.
1)
I believe fault simulation is carried out to check the effectiveness of the
vector. I believe the vector generated by the ATPG tool is by a deterministic
process and should be able to bring out the fault. Why is then fault simulation
required. Also, can the ATPG tool itself cannot determine if vector is not an
effective one
2)
Are there special tools for fault simulation? i.e. fault simulator.
Or
the regular simulators provide this option.
Fault
simulation is not required to validate ATPG output. However, as deepaky
correctly points out, an ATPG tool will internally call a fault simulation
tool. This is because once a pattern is generated to cover a specific fault, it
is fault simulated to see if it covers any other faults that were not explicitely
targeted. If other faults are covered they can be dropped from further
consideration (unless a specific N-detect level is a requirement, but that's a
different discussion....)
Stand-alone
fault simulators do also exist. They are typically used to fault grade
functional vectors. Fault simulators are also included in LBIST solutions to
fault grade the pseudo random patterns generated by the LBIST.
77. If Fault Simulation is not
required to validate ATPG then why do we have an option to perform fault
simulation in tools like fastscan.
Fastscan
is a versatile test pattern generation and fault simulation tool. It can be
used to fault grade any set of scan patterns against many types of user
definable fault types. Again, for the fault types than Fastscan is capable of
targeting, it is not necessary to perform a separate fault simulation run on
the patterns Fastscan generates. However you can for example fault simulate
those generated patterns on other fault types.
Many
people will use their functional verification test for manufacturing test. They
need to fault simulate these vectors to determine what faults are covered and
left uncovered to be targeted by an ATPG. It also allows them to determine the
quality of these tests.
78. How to avoid C4 violation in
Synopsys DFT compiler?
First
thing you cannot get C4 in the pre_dft drc, it will be some D violation.
Second,
you have not used the command
set_dft_configuration
-fix_reset enable ( may be you miss to write that here)
Further,
I dont think that autofix will solve this problem. It is a capture issue and
not scan shift issue. What I think is happening here is that , your reset pin
before reaching the flop is gated with testmode and then reaches the flop. The
flops are not failing the drc and coming on the scan chain because the reset on
the pin of the flops is in inactive state.
You
can trace the top level reset pin in your design to see if it is getting gated
some where.
In
DC you can use the command
all_fanout
-from reset
79. debugging compressed patterns
failing in tester
well,
for debugging its always easier with basic scan patterns corresponding to these
compressed patterns. However if you wish to debug with these compressed
patterns then you need to find the cycle failing and then find all the
corresponding flops in all the chains compressed. This way you will have huge
number of flops which could be failing e.g. if you have compression ratio of
100 then for each failure you will have 100 flops which could be contender to
this failure.
80. C6 violation during ATPG
set
clock_off simulation on
set
split capture_cycle on
And
if the two commands by kunal does not resolve these issue, then you need to
mask these flops.
Normally
such violation occurs when Clock is seen as Data by ATPG tool.
For
Fastscan the commands would be :
add
cell constraint -drc C6
This
will add constraint DX on the output of such registers.
