Minimizing yield fallout by avoiding over and under at-speed testing - Embedded.com

Minimizing yield fallout by avoiding over and under at-speed testing

The authors discuss the problems associated with SoC at-speed testing such as over-testing and under-testing, which affect yield, and provide suggestions on how to overcome them.

In the nanometer technology used for automotive SoCs, most defects on silicon are due to timing issues. Thus, at-speed coverage requirements in automotive designs are stringent. To meet these requirements, engineers expend a lot of effort to get higher at-speed coverage. The principle challenge is to achieve silicon of the desired quality with high yield at the lowest possible cost. In this article we discuss the problems associated with over-testing and under-testing in at-speed testing, which can result in yield issues. We will provide a few suggestions that can help to overcome these problems.

The primary objective of at-speed testing is to detect any timing failure that may occur on silicon at its operating frequency. The most important part to be tested is the logic that generates controllable clock pulses having the same frequency as required for functional operation. The preferred way to supply controlled clock pulses is from the tester (ATE) through the input pads, as this will reduce complexity and minimize the additional test logic that needs to be built over the design.

However, this scheme will have frequency limitations because pads generally cannot support very high frequency clocks. So on-chip phase-locked loops (PLLs) and oscillators are used to provide clock pulses. Free running clocks from these sources cannot be used directly, however, because first we have to shift vectors through scan chains at slow frequency (shift frequency), capture at functional frequency, and then flush out data at shift frequency. We need controllable pulses while capturing at functional frequency, which can be achieved by using the chopper logic. A typical clock architecture with at-speed clocking is shown in Figure 1 .


Click on image to enlarge.
Figure 1: A typical clock architecture with at-speed clocking

For any SoC, STA (Static Timing Analysis) sign-off is integral to validating the timing performance. Timing sign-off ensures that the silicon will operate at the desired functional frequency. The same logic applies to at-speed testing as well. STA signoff must be done for at-speed mode along with the functional modes because the clock path might be different in at-speed mode, and added test control logic needs to be timed as well. The chopper logic is not required in normal functional mode, so we need to meet the timing requirements of the chopper logic as well.

Ideally speaking, closing timing in at-speed mode should not be a problem if the change in clocking is done in the common path, such as at the start of the clock path, so that the change is common for both launching and capturing flops, and hence does not affect setup and hold timing of the design. The test control logic generally works at slow frequency or is static and hence not very difficult to meet timing.

Typical SoC clocking scheme
However, modern Soc designs are not that simple. High performance and low leakage requirements result in the designs having various clock sources within a single SoC, such as PLLs, oscillators, clock dividers, etc. Depending upon the architecture, there can be a number of IO interfaces operating on an external clock running at a few MHz, such as SPI, JTAG, I2C, etc. As a result, different parts of the SoC can operate at different frequencies.

Here’s where things get complex. The clocking solutions (chopper logic) discussed earlier for at-speed clocking are not sufficient for complex chips operating at different frequencies. In at-speed testing, these complexities raise problems known as Under-testing and Over-testing, which then lead to the need for optimal testing.

Over-testing happens when logic is tested at a higher frequency in at-speed mode compared to the frequency of operation in functional mode. Referring to Figure 2 , over testing happens if a pll_clock is provided to any low frequency modules like watchdog and RTC during at-speed mode. The one key reason for such an approach is simplicity of the test clock path, as this approach will require only minimal change in functional logic. In our example, we just need to bypass all divided clocks/RC osc clocks/external clocks by scan clock which in turn will be controlled by the pll clock.

Figure2: Memories and flash are operating on a divided PLL clock while the platform is working at real pll_clock. The internal RC oscillator is feeding clocks to blocks like the RTC (Real Time Counter) and watchdog timer, which require very slow frequency clocks. Blocks like display masters have both an IPS interface and a camera interface. The IPS interface generally works at system frequency while camera logic works at a slower frequency clock provided from the outside world. IO interfaces like SPI and JTAG work on a few MHz. Thus the overall configuration of an SOC requires multiple blocks working at multiple frequencies.

Under-testing happens when any logic is tested at slower frequency in at-speed mode than the intended frequency of operation. This scenario generally exists when it is not possible to supply a test clock of the exact frequency as in functional mode, but at the same time closing design at high frequency is not possible either due to large data path delays or technology constraints. In this case we are forced to supply a clock of lower frequency.

Thus it is necessary to test the silicon for defects at exactly the same frequency as the functional frequency. Any deviation will lead to issues of either over-testing or under-testing:

  • Closing the designs on higher frequencies for at-speed testing, when functional logic is intended to work at slower frequencies, will affect area and power of the overall design. In case of timing critical designs, the at-speed testing tool will use high drive strength cells and even may require low Vt cells to meet these frequency targets.
  • Even if the timing of the design is closed at higher frequency, at the cost of power and area, we could be unnecessarily pessimistic in our yield calculation. There can be unrealistic yield fallout during at-speed testing. For example, in a design with two clock domains, domain1 @ 120MHz and domain2 @ 80MHz, we close timing at 120MHz flat for the whole design to simplify clocking architecture in at-speed mode. All the ATPG pattern generation for both these domains will happen @ 120MHz. Due to process variability, on silicon, domain1 is working fine at 120MHz but domain2 is working at 110MHz only, thus all the dies will be treated as defective parts. Though the chip is good enough for functional requirements, based on at-speed pattern failure we will declare the die as a faulty one and this will reduce our yield.
  • In the case of under-testing, at-speed patterns will not guarantee that the chip will actually work at the intended frequency. Since bad dies can pass at-speed tests, the original purpose of at-speed testing to filter out bad dies can be defeated. In this case we will be over-optimistic in our yield calculation.

Having understood the drawbacks, we will focus on the reasons for the presence of over-testing and under-testing in any SoC:

Simplicity of clock architecture
Given so many clock sources in the functional mode, the easiest way is to provide few controllable test clocks in at-speed mode.

Figure 3: The easiest and simplest test clock solution is to mux the PLL clock with the external clock even for at-speed mode, a case of over-testing.

Let us take an example of a DSPI module. The IP works on 2 clocks, an external clock of 15 MHz and a functional PLL clock of 120MHz for internal logic. As shown in Figure 3, the easiest and simplest test clock solution is to mux the PLL clock with the external clock even for at-speed mode, a case of over-testing.

nm.
Frequency dividers in design
In case of clock dividers, theoriginal source clock is used in all the test modes and is muxed withdivided clock as shown in below Figure 4 .

Figure 4: The original source clock is used in all the test modes and is muxed with divided clock.

Thisis a common scenario in design where we have lot of dividers but wecan’t use them in at-speed testing because these dividers are notcontrollable during testing (phase determination). So the easiestapproach to simplify things in at-speed testing is to provide anundivided clock in test mode, which results in over testing.

Timing exceptions such as multicycle paths
Indesigns, various timing exceptions in the form of multicycle paths,false paths, case analysis, etc. are used when the signal propagationrequires more than a single-cycle clock during functional operation.These exceptions are valid in at-speed mode as well and hence should beappropriately ported in at-speed mode, also in the form of SDC (standarddesign constraint file). However current ATPG tools have limitations inunderstanding some of these constraints, especially multicyclepaths. When parsing through the SDC file, it ignores multicycle pathsand does not create any pattern for that. For example, if we have amulticycle of 2 from one register to another register, it will simplymask any pattern that checks capture between these two registers.

Sothis means all the multicycles paths are not tested in at-speedtesting, resulting in under-testing. On the other hand, if theseexceptions are not made part of the SDC file, the timing check willhappen in a single clock cycle, whereas functionally this path will workin two clock cycles, which is a typical case of over-testing. Overallit is a big concern as generally we have lots of multicycle exceptionsin any complex design, which can lead to either over-testing orunder-testing if we follow conventional methods.

Optimal At-speed testing
Sofar we have seen that both over-testing and under-testing are notdesirable, so we need a methodology to ensure that actual benefits ofat-speed testing are realized without compromising design QOR. The ideais that there should not be any significant area/power overhead ondesign due to at-speed testing but at same time we should ensure that inat-speed testing design is checked at intended functional frequency andnot more or less than that.

Listed here are a few guidelines/techniques to ensure that at-speed testing is done in the correct way:

  • Identify the different frequency domains in your design in func mode. This is an important step because the earlier you identify the frequency domains, the better you will know at-speed testing requirements. Thorough analysis of the clock architecture can help define optimal at-speed clocking. For example, when starting a project, generally not much emphasis is given to external IO interface frequency targets, which can later impact defining at-speed clocking strategy for these interfaces.
  • Define at-speed mode timing constraints along with functional mode constraints generation. Any timing critical paths in at-speed mode can be addressed at the start of the design cycle itself. Making changes at early stages is always easier.
  • One of the key solutions is to identify cases of under-testing and over-testing because many times these issues will crop up during final STA runs or even when they are unnoticed in case timing is met. Using some sort of scripting, comparison of max frequency of all the registers in functional mode and at-speed mode can be done. Divide the registers into three categories: flops having same frequency in both modes – good to go; flops having frequency less in at-speed mode than in func mode – case of under testing; flops having frequency more in at-speed mode than in func mode – case of over testing.

Oncethese cases are identified, thorough analysis should be done and allthe architecture possibilities should be explored to provide clock ofexactly same frequency as in functional mode.

To tackle timingexceptions, the solution lies in converting a multicycle path to asingle-cycle path by testing at lower frequency. The concept is simple.Suppose a design works at 200MHz and has a few paths of a multicycle of2. Timing these paths at 200MHz with a multicycle of 2 is equivalent totesting these paths at 100MHz in a single cycle. In at-speed testing,test the logic in two passes. In the first pass a capture clock of200MHz will be provided to test all single-cycle paths and allmulticycle paths will be masked. In the second pass, capture clock of100MHz will be provided to test all multicycle paths only. The sameconcept can be applied with higher multicycles.

Doing at-speedtesting in multiple passes will also solve the problem ofover-testing/under-testing to a large extent. As we discussed above,sometimes it is not possible to provide exact frequency clock to alldomains simultaneously, but we can do so by configuring capture clock atmultiple frequencies in each pass. Generally, in designs where we usepll for the system clock, we have the flexibility to configure pll atsome discrete frequencies.

The same approach of testing inmultiple passes can be used to address the problem of over-testingassociated with frequency dividers. The difference is that in the caseof multicycle paths, the flops can be masked, but in the case ofdividers, we need controllability of divided clocks so that the clockcan be gated in scan mode.

Figure 5: Duringat-speed testing in pass 1 when system clock is at 200Mhz, clock gatinglogic will gate the clock to the domain that is functionally operatingat 100Mhz (through divide by 2 logic).

As shown in Figure 5 ,during at-speed testing in pass 1 when system clock is at 200Mhz, clockgating logic will gate the clock to the domain that is functionallyoperating at 100Mhz (through divide by 2 logic). But in pass 2 whensystem clock is set at 100Mhz, enable of clock gating cell will bedriven to logic 1. This will ensure that logic is now tested at theintended frequency of 100Mhz.

Using the above guidelines, mostof the issues related to over-testing and under-testing should beresolved. But in case one is forced to choose between under-testing andover-testing, the decision depends on the application of the SoC.Automotive designs, where human safety is the prime concern, the safeapproach of over-testing should be chosen, whereas in a power-hungrydesign, such as in networking and wireless domains, go forunder-testing. Even for these cases, every effort should be made toensure that the deviation from the desired frequency should be as littleas possible.

Let us take one example of a design with multiple frequency clocks, which will help to understand the concept:

Supposea design is working on 240MHz and we have a multicycle of 2, 3, 4 etc.for various paths. Also there are some interfaces working on externalclocks of 10MHz and 60MHz. To avoid any kind of over-testing orunder-testing, test it in a number of passes in at-speed mode. ConfigurePLL at 240, 120, 80, 60MHz and test all logic at actual functionalspeed.

  • 1st Pass: @240MHz- all single cycle paths (mask 100MHz and 60MHz interface, rest SDC is standard one)
  • 2nd Pass: @120MHz – Paths with multi-cycle of 2 (remove multi-cycle 2 exceptions from SDC) + 100MHz interface logic (over-testing minimized)
  • 3rd Pass: @80MHz – Paths with multi-cycle of 3 (remove all multi-cycle exceptions of 2 and 3)
  • 4th Pass: @60MHz – Paths with multi-cycle of 4 paths + 60mhz interface logic (remove all multi-cycle exceptions)


Conclusion

With SoCs becoming functionally more complex andtechnology moving to lower nodes, good yield is proving to be animportant concern for any design company. Yield directly impacts theprofit-loss equation and serious efforts are required to fix the reasonsfor low yield. At-speed testing is an important yardstick to measurethe quality of silicon and thus we should target high coverage numbers.But at the same time, we should run our at-speed patterns at appropriateclock frequency only, because testing at wrong clock frequency willlead to problems of overtesting or undertesting. Both these conditions(of under-testing and over-testing) are neither good for design QOR norfor yield estimation.

Test clocking should be given equalimportance to functional clocking and an effort should be made toprovide the same frequency clock to different domains as they areclocked in functional domain. At the same time considerable attentionshould be given to multicycle paths because typically they constitute asignificant component of timing paths in any design. At-speed testing inmultiple passes is the solution to multicycle paths at-speed testing.Multiple passes testing methodology can also be used to solve othercases of over-testing and under-testing as well. So in conclusion, usingthe above recommendations and methodologies we can achieve moreaccurate at-speed coverage, which in turn will ensure that we haveminimum yield fallout issues without compromising design QOR.

Rajiv Mittal  works at Advanced Micro Devices (AMD) as Senior Member of TechnicalStaff in ASIC/Layout Design Team in India. Earlier he worked atFreescale Semiconductor as Staff Design Engineer. With more than 11years of experience he has worked in a wide range of SoC and ASIC designdomains, mainly in physical design activities across a number ofprocess technology domains, ranging from 130nm to 40nm.

Amol Agarwal  has worked at Freescale Semiconductor as Senior Design Engineer forfive years, on the physical design team where he has been involved inseveral block-level and chip-level designs in technology ranging from250nm to 55

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.