|
New manufacturing test challenges are raised with SoC technology advances where both test quality and test costs are affected with a direct impact on current Design-For-Test (DFT) methodologies and flows.
Indeed, by analyzing major advances in DFT methodologies, it is worth noting that most of the substantial effort was dedicated on the one hand to enable at-speed testing for a better test quality and on the other hand to develop new DFT techniques such as test compression to cope with the rapid increase of the scan test costs. Such efforts are unfortunately not sufficient with the new SoC testing challenges.
Furthermore, with the increasing complexity of SoCs, DFT insertion and verification have become more and more costly and several bottlenecks are observed when using traditional SoC design flows. The traditional DFT insertion and verification process comes too late in comparison to other design steps where the main design decisions are taken ahead of time, pre-synthesis.
Nowadays, a typical SoC design flow is structured into two subsequent design phases. The first phase consists mainly of functional design steps where the final outcome is a synthesizable RTL. Given an RTL input, the second phase, called implementation design, starts from logic synthesis followed by DFT insertion and ends with layout design. The final output is usually a set of GDS II physical files. Because implementation design neither adds nor deletes SoC functions, there exists a significant organizational and cultural difference between design engineers who are involved in each design phase. This has been accentuated with EDA technology advances which enable estimations of speed and power at RTL so that any feedback from implementation design teams to functional design teams is decreasing in time. As a result, the gap between functional and implementation design phases, which is materialized by the dashed line in Figure 1, is increasing and the communication between designers from both design levels is significantly declining.
 |
As illustrated in Figure 1, DFT is traditionally considered as one implementation design step where both DFT verification and test logic implementation are considered post-synthesis. This is in contradiction with the original DFT nature where test logic for several test modes apart from a mission mode, needs to be added to the original design. In other words, DFT is in reality a combination between both functional and implementation design steps where key DFT verifications have to start early in the design process independently from DFT implementation. For DFT implementation purpose, depending on the DFT methodology, it is widely accepted to insert preliminary and technology independent test logic. Memory BIST (MBIST) and IEEE 1149.1 are typical examples of DFT methodologies for which preliminary test logic can be implemented early in the design flow. However, the final implementation of test logic for DFT methodologies such as internal scan and test point insertion is kept technology and silicon dependent later in the design flow.
To focus more on scan as the backbone of all SoC DFT methodologies, scan test modes can be split into two main categories; static test to detect static faults, and dynamic test for the detection of dynamic faults. The dynamic test has two types of clocking, namely high-speed clocks driven by automatic test equipments (ATE) and at-speed clocks which are generated from internal PLL. For each of these scan test types, it is necessary to consider several test modes where different structures are involved. Typical examples are: test compression logic such as test compression bypass logic for precise diagnosis, clock control logic for clock domain by domain test, power control logic for power island by island test, control logic for peak power reduction during test and finally random pattern generation logic for reliability evaluation.
Today, the test logic for the above test modes is mostly inserted into the gate-level netlist after logic synthesis. Therefore, as the increase of design logic size, the time for test logic design verification, especially during simulation, has drastically increased. Also, any debugging of a DFT problem requires a significant amount of time to be discovered at the gate level. Thus, some DFT problems may even be left unfixed because of the lack of time with direct consequences on the final DFT quality. Also, in case a feedback on DFT problems is possible on time, any communication on netlist problems with RTL designers is difficult and usually unproductive.
|
