Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > T&M

Cut yield fallout by preventing over and under at-speed testing

Posted: 14 Oct 2011     Print Version  Bookmark and Share

Keywords:SoCs  phase-locked loops  Static Timing Analysis 

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.

Figure 2: 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.

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.

Let us take an example of a DSPI module. The IP works on 2 clocks, an external clock of 15MHz 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.

Frequency dividers in design
In case of clock dividers, the original source clock is used in all the test modes and is muxed with divided clock as shown in figure 3.

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

This is a common scenario in design where we have lot of dividers but we can't use them in at-speed testing because these dividers are not controllable during testing (phase determination). So the easiest approach to simplify things in at-speed testing is to provide an undivided clock in test mode, which results in over testing.

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

 First Page Previous Page 1 • 2 • 3 • 4 Next Page Last Page

Comment on "Cut yield fallout by preventing over..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top