transition delay faults and stuck-at faults

Hi,
Please help me to understand , if there a need to run stuck-at fault model, after running transition fault model? are the stuck-at faults also covered by transition fault model ?

Hi,

1. Stuck at fault model : The node is modeled to be stuck at some value 0 or 1 depending on what we are targeting.
2. Transition fault model : This is considered to stuck at fault model within a time window. The value of the node changes but not within the time ,at which it should change .For detecting such faults we have two vector for each pattern one for launching the fault and the other to capture the fault.

The answer for your queies are below:
1. For both models, fault sites are the same. Both models have diferent aspects to detect different manufacturing fault( For more details of manufacturing faults and fault models, please refer mentor's Dastscan/testkompress atpg user guide) .
To detect those faults,they have different capture clock frequncies.
2. Test coverage criteria. We need test coverage >99% to cover the most of fault sites, which is possible in stuck at than transition.

In DFT, we test for the manufacturing faults. To detect these manufacturing faults there are different fault models that based on algorithms determine the various faults that can arise when the chip is gets fabricated in the fabrication labs. stuck-at fault models and transition fault model are two such models.

Stuck-at fault model (is an infinite delay model, not based on the clock speed of the device). It tells us that a particular node is either stuck-at 0 (connected to ground/VSS) or stuck-at 1 (connected to power/VDD). Based on this the ATPG tool will perform fault analysis and determine if this is a tested or ATPG untestable fault (tied, unused, blocked, redundant).

Transition fault model falls under the delay fault model which tells us that a particular node is able to make a transition from 0->1 value but not from 1->0 and vice-verse. While running ATPG for transition faults, it is necessary to know the running frequency of the Device under test (DUT). A transition fault on a line makes the signal change on that line slow. The two possible faults are slow-to-rise and slow-to-rise.

Transition will come under At-speed testing and stuck-at will come under functional testing. these need to be tested differently as for transition testing LOC or LOS concept will come into picture which employs launch and capture vector. In this care is taken such that all combinational logic elements attain steady state within some clock period. if not then fault is present.

- - - Updated - - -

Macein, You have given a good explanation for the difference between stuck at and transition faults. But when you can confirm that a node can have transition from high-to-low and low-to-high at the functional frequency (testing transition faults) doesn't it confirm that node is definitely not stuck-at any value (which otherwise should have been tested through stuck-at patterns) ?

From the above explaination I can conclude that if we need good coverage >99% stuck-at can fulfil it at slower frequency.
When we want to test with in a certain time frame(at-speed) for the node transition , we can go for atspeed testing, eventhough we might not be able to reach coverage of >99%.
Usually atspeed pattern generation takes more time compared to stuk-at.
Thank you all.

ranger01 said:

Macein, You have given a good explanation for the difference between stuck at and transition faults. But when you can confirm that a node can have transition from high-to-low and low-to-high at the functional frequency (testing transition faults) doesn't it confirm that node is definitely not stuck-at any value (which otherwise should have been tested through stuck-at patterns) ?

Click to expand...

Hi Ranger01,
Good question, you made me think...!!
It is important to run separate tests for stuck-at and transition (atspeed) testing. The two runs will give different test-coverage values, where transition coverage will be 3-4% lower than stuck-at test-coverage. The total list of faults tested under stuck-at are much greater in no. than in transition.

In stuck-at testing we shift-in the values, initialize the primary inputs of the combinatorial logic, observe the outputs,ONLY ONE CAPTURE pulse is given and shift-out the values. The circuit is already in steady state.

While when we are performing transition testing, we shift-in the values, then pulse two clock pulses at the functional clock frequency (Primary input changes are also made with the application of the first clock pulse). The first pulse will launch the transition and the second pulse will capture the response from the combinatorial portion of the circuit. Thus there is a time duration in which the circuit needs to respond correctly otherwise there is a defect.

Also a lot of nodes are left out during transition testing, which can only be covered by stuck-at testing. Suppose a device has a 2.2 Mhz functional freq, but shows slow-to-rise defect for some nodes, this defect goes away when we change the clock freq to 2.0 Mhz or when we are running stuck-at testing. If no stuck-at testing had been performed than it would seem that the device is not working correctly and the chip/device would come under fail category. But actually this is a transition defect not stuck-at and the device can still work correctly. Thus, in scenarios like this both stuck-at and transition tests become necessary and the device will operate under lowered freq.

Regards
Macein

macein, I understand the difference between Transition and stuck-at fault detections. Also as you rightly said the transition patterns will not cover all the testable fault sites. But my idea is, Generate the transition patterns to reach the target coverage for Transition faults, grep out the nodes which are not covered by these patterns, generate the stuck-at patterns on only these nodes. By doing this we use stuck-at patterns as top-up patterns and transition patterns by their virtue would cover most of the nodes.