The very process of testing digital circuits routinely increases their dynamic power consumption to levels far exceeding their power specification. If the power consumption is great enough, it can result in failures at wafer probe or pre-burn-in package test that require a significant amount of time and effort to debug. This issue, especially prevalent when testing very large systems-on-a-chip (SoCs) under corner conditions, causes unnecessary yield loss on the production line and ultimately reduces manufacturers' gross margins. The best way to avoid test power problems is to incorporate power-aware testing techniques in the design-for-test (DFT) process. In this article, we'll first examine the relationship between dynamic power consumption and test to determine why managing power is more critical today than ever before. Then we'll explore two distinct DFT methodologies that take advantage of recent advances in automatic test pattern generation (ATPG) technology to automate generation of low-power manufacturing tests.
Test Power Issues
Scan ATPG algorithms are optimized to reduce the number of patterns, which means that each pattern improves fault coverage as much as possible. Bits in the scan pattern that set up and propagate the targeted faults are called "care bits." The remaining bits are randomly filled to detect additional "bonus" faults not explicitly targeted by the care bits. Both care bits and random-fill bits in each scan pattern cause logic state transitions that charge and discharge parasitic capacitors in a device. This leads to an increase in dynamic power relative to the level consumed when the circuit operates under normal conditions.
There are two types of dynamic power consumption that affect device testing: peak power and average power. Peak power, sometimes referred to as "instantaneous power," is the amount of power consumed during a small instant of time such as the portion of a clock cycle immediately following the rising (or falling) edge of the system clock. Peak power reflects the node switching activity level in a device: the more nodes that simultaneously switch from one logic state to another, the higher the peak power.
Scan testing can increase peak power in a device by up to 20 times the level consumed with mission-mode patterns. Switching currents can be so pronounced that power rail collapse occurs: bits shifted into a circuit along a scan chain are dropped, resulting in pattern mismatches on the tester. Switching currents are typically less severe than this, but they can still cause power rail droop, whereby the increased IR-drop along power rails introduces undesirable circuit delays. In some cases, scan data fails to propagate to the next stage in the scan chain, resulting in test program failure. Power rail droop in shift mode is usually addressed by reducing the scan shift frequency sufficiently to allow enough time for scan signals to meet the shift cycle timing under corner conditions. Reducing the scan shift frequency, however, increases tester time and therefore test cost in a volume production scenario.
Even if a pattern is successfully scanned in, peak power during the launch/capture sequence (referred to as "capture mode" from now on) can contribute enough IR-drop delay that logic values fail to transition within the capture window and the device fails the pattern. Although this issue is associated with both stuck-at and transition delay tests, it's more common in delay-dependent at-speed test patterns. The IR-drop problem in capture mode, as well as the power rail collapse problem in shift mode, can be addressed by over-design of the power rail system to accommodate the increased switching activity of scan testing. Yet increasing the width of power and ground rails adds area to the circuit that would be unnecessary if there were better ways to control peak test power.
Average power is power consumption averaged over a large number of clock cycles, such as the hundreds or thousands of cycles needed to scan a single stimulus pattern into a design while scanning out the response to the previous pattern. Scan testing can increase average power in a device by 2-5 times the level consumed with mission-mode patterns. Excessive average test power can lead to thermal problems such as "hot spots" on the die that can damage the device. Because average power is directly proportional to frequency, it can be controlled during scan shifting by selecting a shift frequency low enough to avoid the problem. As noted above, reducing the scan shift frequency can contribute to higher test cost.
Because average test power is relatively straightforward to manage on the tester, most power-related test issues today stem from excessive peak power. Unobtrusive ways to reduce both peak power and average power during test is currently the focus of intensive efforts in the semiconductor and design automation industries.
Why Managing Power is Critical Today
Managing power consumption during test is critically important these days because the latest fabrication processes make possible the manufacture of designs containing hundreds of thousands -- even millions -- of scan flops. A large portion of these flops can simultaneously switch during scan testing and this peak switching activity increases peak power and exacerbates IR-drop delays as discussed in the previous section.
Moreover, because defect densities for processes at 65nm and below have increased, product yields have decreased. To compensate for these lower yields and maintain acceptable quality levels, manufacturers are turning to ultra-high-resolution at-speed testing to detect very small delay defects inside devices. The enhanced timing resolution capable using small delay defect ATPG has proven to be effective in detecting nanometer defects previously undetectable using standard transition delay testing. Yet the technique requires even tighter control of incidental delays caused by peak currents generated during test than standard at-speed test methods.
In summary, very large SoCs now rely on advanced at-speed ATPG technologies to maintain high test quality in the presence of more nanometer defects, and this trend is driving use of power-aware testing techniques in the DFT flow.
Expressing Power Budget in Terms of Flop Switching Activity
Flop switching activity is highly correlated with node switching activity, and dynamic power consumption reflects node switching activity. It's therefore reasonable to conclude that reducing flop switching activity sufficiently during scan test is an effective way to avoid power-related failures caused by test, and detailed case studies of IR-drop behavior in fabricated devices support this observation [1]. The goal of power reduction techniques, then, is to reduce flop switching activity sufficiently so that "good" devices pass all scan ATPG tests under corner conditions. Notice we don't need to minimize switching activity, but instead just reduce it to levels comparable with switching rates observed when mission-mode patterns are applied.
To illustrate, assume we apply a large number of mission-mode patterns to a design and find that the peak flop switching activity is 26% of the total number of flops. If we generate scan ATPG patterns and track the number of patterns corresponding to a given switching rate, we might observe a distribution similar to the grey distribution of Figure 1. Since both the peak and mean switching rates exceed 26%, there is substantial risk that scan testing will increase IR-drop delays relative to normal device operation.
1. Conceptual example of baseline and low-power distributions for a scan ATPG pattern set.
If, however, we employ techniques to reduce power consumption during test, we effectively shift the distribution to the left. In the overlapping blue low-power distribution of Figure 1, the peak switching activity of the scan ATPG patterns doesn't exceed the power budget, so the risk of power issues occurring during manufacturing test is diminished.
In the following sections, we'll look at two approaches to achieving low-power pattern distributions. They differ fundamentally in the manner in which the power budget is specified.
Design Partitioning Reflects Power Budget
Assume in this scenario that one of the clocks in our design drives a sufficiently large number of flops so that the peak switching activity of these flops exceeds the total power budget of the design. We don't want the test logic to alter any of the clocks, so instead we partition the design into N blocks each with its own scan enable pin and each containing its own scan compression logic and scan chains, as shown in Figure 2. The number and composition of blocks is chosen so that the flop switching rate in any single block, including the one containing the most flops, doesn't exceed the total power budget. In this respect, you might say the partitioning "hardwires" the power budget into the design.
2. Partitioning a design to decrease power during test.
Pattern generation is constrained so that all but one of the scan enables are active (SE=1) and ATPG proceeds one block at a time. The ATPG tool targets faults in the capture-enabled (SE=0) block and faults between the blocks, designating faults in all other blocks "ATPG-untestable." This process is repeated serially for all N blocks, using simple commands to change the status of faults in a block from "ATPG-untestable" to "not detected" just prior to generating patterns for it.
By confining all switching activity to the block targeted for test, we effectively reduce peak power consumption during capture mode. But note that during capture mode the only way to eliminate switching activity in the other blocks is to ensure there is no change in their logic states between the last cycle of scan-shift mode and the next cycle (corresponding to the launch phase of capture mode in the block being tested). This could be accomplished by scanning in either all 1's or all 0's into the blocks not being tested. Unfortunately, this approach results in a loss in fault coverage and requires rather complex manipulations of the fault list and generation of top-off patterns to compensate. Even though we are testing one block at a time, we want to load patterns into all the blocks simultaneously to target inter-block faults.
