31. How to meet coverage goals?
You need to review the untestable faults to determine why they are not getting covered.
The first thing to do is make sure that all the faults that should not be targeted by this test are dropped and not considered for test coverage.
Then find the logic on your chip with the most untested faults. Pick one of the faults in this area and determine why you can’t generate a test for it. You can use the interactive debugger to do this. You can manually create a test for this fault and as you do this figure out what stops you and the ATPG. The interactive debugger might be able to help you with this using it's analysis features.
32. Once a die is tested, can the pins used for scan testing need not be brought out when the die is packaged as IC? Does this have any big advantage?
No - you don't have to bring them out, but then you can't re-test w/ scan at the package level. Normally, folks don't have dedicated scan in/out pins anyway, they share them with mission-mode pins, so they end up getting bonded out anyway.
33. Why should we force the bidis to Z? Can we not use these ports as scan_in and scan_out of our various scan chains? If we use them, then how should we constrain them in the load_unload procedure? Will forcing these ports to Z affect coverage? Will it mean that we cannot put any value on these lines thereby constraining the tool to choose the other ports only for applying input stimulus?
This is normally done for just the bidis that are scan outputs. By constraining them to 'Z', it tells the tool that the pin is working in output mode, and therefore it can then trace the scan chain properly (the chains are traced from output to input).
While shifting you want to prevent conflicts on the non-scan port bidirect pins and to force the correct direction on any pins that are used as scan ports.
You can force Zs on bidirec pins to prevent conflicts.
You have to add hardware and control signals to force the scan ports in the correct direction while shifting.
You can improve test coverage by adopting the TEI methodoly that LSI logic uses. They have a pin that forces all bidirects to be off with the pin. The test are applied with strobe, wait and clock cycles (for stuck at tests).
The strobe cycle has all of the bidirects in the same direction as specified by the ATPG and the TEI pin is disabled.
The wait cycle applies Z to all the bidirect inputs and turns TEI on so all the bidirects will be in input mode.
In the clock cycle all bidirects are in input mode and you drive the values that were on the bidir busses from the input pins and you apply the capture clock.
This prevents bidirect conflicts from affecting test coverage, so your coverage is higher and require fewer vectors.
34. Can a C2 violation occur for a set/reset signal? I am getting this violation for a signal that is identified as a set/reset signal by the tool when "analyze control signlas -auto" command was used.
yes, C2 can happen for set/reset signals. For both Mentor and Synopsys tools, at least, set/reset signals are considered clocks. This DRC violation says that there is a defined clock that does not actually do any work in the circuit (maybe it is replaced in scan mode). To fix it may be as simple as taking that clock out of your ATPG scripts.
35. The time at which the scan chain is put in functional mode can vary depending on the test we are carrying. Given this, how can there be a common test mode pin for all the scan chains?
Test mode pins are typically not the same as scan-enable pins. One or more scan-enable pins (signals) are used to toggle between functional mode and scan mode. These are what you seem to be referring to. Typically different scan-enable signals are needed for at-speed testing to handle things like multi-cycle paths and inter-clock domain paths.
Test mode pins are typically used to put the circuit in test mode and are therefore generally global (static) signals. For example, a test mode pin could be used to share pins between their functional use and as scan I/O.
I am assuming that the test mode pin (irrespective of the number of scan chains) is used to control unwieldy circuits during testing.
You need to review the untestable faults to determine why they are not getting covered.
The first thing to do is make sure that all the faults that should not be targeted by this test are dropped and not considered for test coverage.
Then find the logic on your chip with the most untested faults. Pick one of the faults in this area and determine why you can’t generate a test for it. You can use the interactive debugger to do this. You can manually create a test for this fault and as you do this figure out what stops you and the ATPG. The interactive debugger might be able to help you with this using it's analysis features.
32. Once a die is tested, can the pins used for scan testing need not be brought out when the die is packaged as IC? Does this have any big advantage?
No - you don't have to bring them out, but then you can't re-test w/ scan at the package level. Normally, folks don't have dedicated scan in/out pins anyway, they share them with mission-mode pins, so they end up getting bonded out anyway.
33. Why should we force the bidis to Z? Can we not use these ports as scan_in and scan_out of our various scan chains? If we use them, then how should we constrain them in the load_unload procedure? Will forcing these ports to Z affect coverage? Will it mean that we cannot put any value on these lines thereby constraining the tool to choose the other ports only for applying input stimulus?
This is normally done for just the bidis that are scan outputs. By constraining them to 'Z', it tells the tool that the pin is working in output mode, and therefore it can then trace the scan chain properly (the chains are traced from output to input).
While shifting you want to prevent conflicts on the non-scan port bidirect pins and to force the correct direction on any pins that are used as scan ports.
You can force Zs on bidirec pins to prevent conflicts.
You have to add hardware and control signals to force the scan ports in the correct direction while shifting.
You can improve test coverage by adopting the TEI methodoly that LSI logic uses. They have a pin that forces all bidirects to be off with the pin. The test are applied with strobe, wait and clock cycles (for stuck at tests).
The strobe cycle has all of the bidirects in the same direction as specified by the ATPG and the TEI pin is disabled.
The wait cycle applies Z to all the bidirect inputs and turns TEI on so all the bidirects will be in input mode.
In the clock cycle all bidirects are in input mode and you drive the values that were on the bidir busses from the input pins and you apply the capture clock.
This prevents bidirect conflicts from affecting test coverage, so your coverage is higher and require fewer vectors.
34. Can a C2 violation occur for a set/reset signal? I am getting this violation for a signal that is identified as a set/reset signal by the tool when "analyze control signlas -auto" command was used.
yes, C2 can happen for set/reset signals. For both Mentor and Synopsys tools, at least, set/reset signals are considered clocks. This DRC violation says that there is a defined clock that does not actually do any work in the circuit (maybe it is replaced in scan mode). To fix it may be as simple as taking that clock out of your ATPG scripts.
35. The time at which the scan chain is put in functional mode can vary depending on the test we are carrying. Given this, how can there be a common test mode pin for all the scan chains?
Test mode pins are typically not the same as scan-enable pins. One or more scan-enable pins (signals) are used to toggle between functional mode and scan mode. These are what you seem to be referring to. Typically different scan-enable signals are needed for at-speed testing to handle things like multi-cycle paths and inter-clock domain paths.
Test mode pins are typically used to put the circuit in test mode and are therefore generally global (static) signals. For example, a test mode pin could be used to share pins between their functional use and as scan I/O.
I am assuming that the test mode pin (irrespective of the number of scan chains) is used to control unwieldy circuits during testing.
