51. Could there be any issue due to floating nets or undriven nets?? in scan insertion.
After doing the equivalence checkin only I came to know how exactly the connections were in the post scan netlist(by looking at the schematics). I do not have any combinational paths in the clock tree in my pre scan netlist. This sounded very strange to me even. But I could not find any way out.
When I tried to run drc check in the dft mode there were no violations. But when I moved on to fastscan I actually encountered T3 and T5 violations in drc. And then I tried to debug using the schematics of conformal tool(LEC) since I do not have DFT Visualizer license. Thats when I came to know what happened actually.
52. In transition fault detection process there should be two vectors - for intialization and for transition. I want to understand when exactly they applied? Doesn't transition propagation vector corrupt initialization vector? Can you please explain in steps?
Here are the steps followed during transition fault testing( BRoadside)
1. load scan chains
2.Force PI
3.pulse clock
4. Force PI
5.measure PO
6.pulse clock
7. unload/load scan chains
Clearly you see, not possible for the corrupting intialization vector.
Why latches (other than lock-up and clock gating) in design are bad for ATPG? We always loose coverage by putting them on transparent mode by constraining enable signal. How can we increase this coverage?
I think you answered your own question regarding why we lose coverage,
"putting them on transparent mode by constraining enable signal".
Any logic driving the enable signal will lose some coverage due to this constraint.
If the enable signal is driven by a large cone of logic, you can increase the coverage by adding a "force transparent on" gate close to the enable of the latch, and add an observe flip-flop just before the added gate, so that most of the faults in the logic cone can be recovered.
Without modifying the circuitry, recovering fault coverage in ATPG really depends on how these latches are used in the functional path.
54. How PLL generates two at-speed clocks during launch and capture cycles of LOC at-speed testing? Is there any circuitry which generates two pulses after scan loading?
Yeah, you have to design that circuitry, but it's design dependent.Many EDA companies now provide solutions for this. Commercial on-chip solutions for LOS (launch-on-shift) based testing are also available.
I understood that there should be seperate clock control circuitry to select two at-speed clock pulses from free-running PLLs for transition fault testing. What about stuck-at testing, in this case we need only one pulse from PLLs to capture response. Will there be any signal to control this behavior of clock control circuitry?
Well, it's not strictly necessary to have on-chip control. You can source the clock from an I/O, just as long as your ATE can handle the speed you need, and the device can distribute the clock well enough. The advantage of having on-chip control is that you can use a slow tester.
As far as the stuck-at clock goes, remember, you're using the slow external clock to shift data through the scan chains. For stuck-at, you can bypass the at-speed clock control and use only the slow external clock. Yes, you'd need a control signal. You can also, if you want to increase your flexibility, and get better fault coverage, design your clock control to be able to output 2, 3, or even 4 pulses, to catch faults that only get caught with sequential patterns. I've not done it myself, but I've read about such designs.
Transition delay and path delay fault models both seek to describe defects which cause slow transitions on gate inputs or outputs. The difference is that a path delay is more specific - the whole path, from point a to point b is specified. It's a more stringent case than a transition fault. To detect a transition fault, it is only required that the ATPG generates a pattern to propagate that fault to a scanned flop. The path selected may not be the worst case path.
Most people in the industry begin with transition faults, because the ATPG can generate patterns with decent coverage more easily. Then if desired, those patterns are augmented with a much smaller set of path delays that are determined to be critical (maybe those with the least margin as determined by the timing tool).
55. I am very new to the field of DFT and ATPG. I have generated test patterns using Synopsys TetraMax. And i don't how to validate these patterns. What should i do ? Does anyone has any tutorials to verify these patterns again the netlist using simulators like modelsim or vcs ?
I normally output Verilog Testbenches of the chain tests and parallel-load (broadside) ATPG patterns, and simulate them against the netlist w/ SDF.
There shouldn't be a lot to this, since the testbenches are automatically generated. You may have to manually add the sdf annotation command (although some tools have ways of allowing you to automatically add that).
After doing the equivalence checkin only I came to know how exactly the connections were in the post scan netlist(by looking at the schematics). I do not have any combinational paths in the clock tree in my pre scan netlist. This sounded very strange to me even. But I could not find any way out.
When I tried to run drc check in the dft mode there were no violations. But when I moved on to fastscan I actually encountered T3 and T5 violations in drc. And then I tried to debug using the schematics of conformal tool(LEC) since I do not have DFT Visualizer license. Thats when I came to know what happened actually.
52. In transition fault detection process there should be two vectors - for intialization and for transition. I want to understand when exactly they applied? Doesn't transition propagation vector corrupt initialization vector? Can you please explain in steps?
Here are the steps followed during transition fault testing( BRoadside)
1. load scan chains
2.Force PI
3.pulse clock
4. Force PI
5.measure PO
6.pulse clock
7. unload/load scan chains
Clearly you see, not possible for the corrupting intialization vector.
Why latches (other than lock-up and clock gating) in design are bad for ATPG? We always loose coverage by putting them on transparent mode by constraining enable signal. How can we increase this coverage?
I think you answered your own question regarding why we lose coverage,
"putting them on transparent mode by constraining enable signal".
Any logic driving the enable signal will lose some coverage due to this constraint.
If the enable signal is driven by a large cone of logic, you can increase the coverage by adding a "force transparent on" gate close to the enable of the latch, and add an observe flip-flop just before the added gate, so that most of the faults in the logic cone can be recovered.
Without modifying the circuitry, recovering fault coverage in ATPG really depends on how these latches are used in the functional path.
54. How PLL generates two at-speed clocks during launch and capture cycles of LOC at-speed testing? Is there any circuitry which generates two pulses after scan loading?
Yeah, you have to design that circuitry, but it's design dependent.Many EDA companies now provide solutions for this. Commercial on-chip solutions for LOS (launch-on-shift) based testing are also available.
I understood that there should be seperate clock control circuitry to select two at-speed clock pulses from free-running PLLs for transition fault testing. What about stuck-at testing, in this case we need only one pulse from PLLs to capture response. Will there be any signal to control this behavior of clock control circuitry?
Well, it's not strictly necessary to have on-chip control. You can source the clock from an I/O, just as long as your ATE can handle the speed you need, and the device can distribute the clock well enough. The advantage of having on-chip control is that you can use a slow tester.
As far as the stuck-at clock goes, remember, you're using the slow external clock to shift data through the scan chains. For stuck-at, you can bypass the at-speed clock control and use only the slow external clock. Yes, you'd need a control signal. You can also, if you want to increase your flexibility, and get better fault coverage, design your clock control to be able to output 2, 3, or even 4 pulses, to catch faults that only get caught with sequential patterns. I've not done it myself, but I've read about such designs.
Transition delay and path delay fault models both seek to describe defects which cause slow transitions on gate inputs or outputs. The difference is that a path delay is more specific - the whole path, from point a to point b is specified. It's a more stringent case than a transition fault. To detect a transition fault, it is only required that the ATPG generates a pattern to propagate that fault to a scanned flop. The path selected may not be the worst case path.
Most people in the industry begin with transition faults, because the ATPG can generate patterns with decent coverage more easily. Then if desired, those patterns are augmented with a much smaller set of path delays that are determined to be critical (maybe those with the least margin as determined by the timing tool).
55. I am very new to the field of DFT and ATPG. I have generated test patterns using Synopsys TetraMax. And i don't how to validate these patterns. What should i do ? Does anyone has any tutorials to verify these patterns again the netlist using simulators like modelsim or vcs ?
I normally output Verilog Testbenches of the chain tests and parallel-load (broadside) ATPG patterns, and simulate them against the netlist w/ SDF.
There shouldn't be a lot to this, since the testbenches are automatically generated. You may have to manually add the sdf annotation command (although some tools have ways of allowing you to automatically add that).
