As most ASIC designers are aware, there are two primary test-related issues that cause a high degree of pain and schedule delay in creating ASIC designs -- the difficulty in adhering to DFT (Design For Test) rules and the integration of diverse test methodologies. Now that blocks of independently developed Intellectual Property (IP or "Cores") are more frequently being used, it has become more common to have to deal with the variety of test approaches used by the different IP suppliers.
Most significant, however, are DFT rules. Adherence to DFT rules continues to be a major hurdle within ASIC design, just as they have for years, and especially in designs with multiple clock domains. While the introduction of BIST (Built-In Self Test) has solved some test-related problems, it has created a few new ones, and has not eliminated the issue of DFT Rules.
In addition to ASIC designs, the largest FPGAs available today are capable of implementing close to one million ASIC logic gates. At this level of integration, design reuse becomes a necessity and these flexible devices finally enter the realm of true SoC (System-on-Chip) densities. However, unlike designs implemented in conventional ASIC technologies, designs are normally placed in FPGAs with little or no regard for test issues or rules, since FPGAs are tested at the factory. Most FPGA designers never have to think about test at all!
FPGAs provide many benefits, and system designers tend to use them as a matter of habit - regardless of their suitability for achieving target performance and cost, or completing development projects on schedule. Large FPGAs, in particular, carry with them severe performance limitations that can cripple a development project, and cost levels that can reduce gross margins for system products considerably.
To overcome these cost and speed limitations, FPGA users must sometimes consider replacing large FPGAs with some form of mask configurable ASIC device. Unfortunately, when this decision is made the design is often complete, and ASIC-related test rules were never a consideration. The conversion process therefore is usually painful and time-consuming, and the resulting ASIC fault coverage is often low.
Experts agree that from 20% to 50% of the development effort on an ASIC project is normally spent on test-related issues. In spite of the progress made by EDA vendors offering synthesis tools including test insertion and automatic DFT rule checking, the problems and pain persist. As a result, ASIC designs frequently enter production with less than 90% fault coverage, causing unnecessary device defect rates and board-level fallout as a result.
Conventional ASIC test
The ability of a particular ASIC test process to thoroughly test a device is called fault coverage, and is a measure of what percentage of detectable, stuck-at faults are tested by the patterns (test vectors) utilized in the test process. An example of a "stuck-at" fault is a gate output that should exhibit a logic "1" for a particular set of input values and yet the output is a "0". Likewise, a "stuck-at-1" fault exists where a gate's output is a "1" even thought it should be a "0" according to its inputs and function.
The first step in inserting structures into a design for scan testing is to replace all flip-flops in the design with scan flip-flops. Sometimes this is done as part of the synthesis process, although it is historically performed later in the flow. Inserting scan flip-flops, as shown in Figure 1, allows a higher degree of controllability of nodes within the design, thereby increasing the fault coverage. However, conventional scan technology does not provide for full control or observe all of user nets in a design, leaving many structures untested. Even BIST techniques rely on scan-type structures for increasing controllability and observability.
The most common variety of scan flip-flop contains a multiplexer prior to the D input such that test data can be shifted into the flip-flop during test mode. Or alternately, a normal logic signal can be stored during user mode operation.

Figure 1 - Conventional ASIC scan insertion
The paradigm for conventional ASIC scan testing typically includes the following:
- There is one test clock and the circuit must allow this to be applied to all scan flip-flops.
- During testing, all flip-flops are in test mode.
- During normal user operation, all flip-flops are in normal mode.
Notice that when using mux-based scan flip-flops (as in Figure 1), a multiplexer is normally inserted in the primary path for the user's clock to allow the test clock to be delivered to all flip-flops during test mode. All test flip-flops are placed in Test_Mode at the same time.
DFT rules
Conventional ASIC/SoC technologies, such as a standard cells and embedded arrays as well as modular array ASICs from other vendors, require many DFT rules in order to provide sufficient fault coverage and acceptable device defect rates. When DFT rules are not followed, a number of faults become untestable using conventional scan methodologies, and the overall fault coverage suffers considerably.
To obtain reasonable coverage levels of detectable, stuck-at faults using scan design, it is typically required that the design be fully synchronous. Hence, we have the first DFT rule. Unfortunately many designs, especially in networking and communications, require multiple asynchronous clocks, so this DFT rule cannot be avoided. Also, in the quest for speed, synthesis often produces re-convergent redundant logic structures - another violation.
In general, not following DFT rules reduces fault coverage. As fault coverage is lowered, the defect rate for devices is increased, and more and more bad devices slip through.
A list of commonly recognized DFT rules includes the following:
- Designs should be fully synchronous with a common clock.
- Asynchronous inputs to storage elements must be disabled from an external pin during testing.
- Only sequential library elements specifically designed to support ATPG may be used. Negative edge-triggered flip-flops are sometimes forbidden.
- Gated clocks are not allowed. They must be bypassed during test.
- Internal 3-state busses should not be used; muxes are preferred.
- Combinational logic loops are not allowed.
- Re-convergent, redundant logic is not allowed.
- External busses must be disabled during testing.
- Interfaces between IP blocks containing diverse test methodologies must be fully testable.
Figure 2 shows the relationship between fault coverage and defect rates for 0.25m conventional ASICs, based on formulas published by Hewlett-Packard.

Figure 2 - Defect rates for conventional ASICs
Historically, ASIC suppliers prefer to see fault coverages greater than 90%. However, for designs with 1 million gates on 0.25m, 90% coverage would produce a defect rate of 0.28% or 2800ppm - unacceptable considering these defects will not be found until devices have been assembled on PCBs. Even when all DFT rules are followed, it is very unusual if the fault coverage for a conventional ASIC design exceeds 98%. Therefore, if all or at least most DFT rules are not followed, the user's company will suffer the consequences in device fallout after board assembly.
As shown in Figure 3, device fallout at the board-level can mean expensive subassembly debug, or worse yet, scrap. As more devices having less than 100% fault coverage are included in a particular board assembly, the rate of subassembly failure increases exponentially.

Figure 3 - Board fallout versus device defect levels
Source: Syntest Technologies
There's no avoiding test issues with conventional ASICs
Experienced ASIC designers are all too familiar with the design flow for conventional ASICs. They know the degree to which DFT rules and test point insertion, as well as scan chain routing and timing, can cause a highly iterative process where the designer often becomes continually involved -- making design changes and re-doing timing convergence. These iterations can, even today, go on for 3 to 6 months or more before an acceptable level of test coverage has been achieved and both the user design and the test logic all run at speed.

Figure 4 - Historical ASIC test flow
The historical test flow for ASIC development, with emphasis on test development, is shown in Figure 4.
More designers these days are inserting scan as part of the synthesis process -- a wise decision. Then, at least the initial pre-route timing is closer to reality. Notice the loop where the customer inserts additional test points after the initial fault grading. Unfortunately, if the deficit in fault coverage is due to a synthesizeable core purchased from a third party, the user may be reluctant to alter that portion of the design for fear that it may no longer work properly.
When the ASIC supplier performs placement, it is typically done with scan chains disconnected -- placing the priority on the timing of the user's design. Once placement is complete, the scan chains are re-ordered to better match up with the placement results. This is often done by the supplier, but sometimes the burden is placed on the customer.
After the routing step, the design is validated for correct timing and function, as well as proper function of the scan chains. Timing problems often surface here in both the user design and the test-related circuitry. Sometimes, results are sent back to the customer indicating thousands of hold-time violations that must be fixed. Some ASIC suppliers will attempt to fix these while others again place the burden on the customer. These iterations within the flow of Figure 4 often go on for months, giving conventional ASIC/SoC design a reputation as a long, painful and expensive process requiring a large mount of engineering resources.
EDA tool suppliers are also more conscious of DFT rule issues and offer tools that can check for DFT rule violations after synthesis. Some of these tools even offer to fix some of the violations automatically, as in the case of inserting "lockup latches" in paths that cross clock domains. However, most DFT violations result from explicit design styles and are not easily fixed without designer intervention.
Even in large system manufacturing companies having state of the art tools, design groups often choose to focus on design issues and not DFT, basically tossing designs "over the wall" to the test engineering group to fix the problems and deal with the ASIC vendors. Unfortunately, for as difficult and valuable a problem that ASIC test is, it adds no inherent value to the functionality of the design itself. Given a choice, designers will always choose to spend their time and effort concentrating on features and functionality that increase the value of their company's end product.
Test challenges in FPGA conversions
Some companies supplying conventional ASICs are positioning certain product lines as "FPGA Conversion Solutions" with claims of a simplified and "seamless" design flow. The problem is that these solutions are essentially scan-based conventional ASICs (usually based on embedded array technology), where the supplier is willing to take on more of the burden of the conversion process in order to get the business.

Figure 5 - FPGA replacement flow without AutoTest
The flow claimed by one such manufacturer is shown in Figure 5. The box labeled
"Check for Test and Fix" is the clue that the flow is not as seamless as claimed. The red arrow has been added by the author to indicate what often happens in order to provide a more acceptable level of fault coverage.
A different manufacturer offering a "vectorless" conversion solution for FPGA designs included the following items in their literature as requirements:
- Avoid asynchronous designs (single external master clock preferred).
- No combinational feedback loops
- No delay dependencies or pulse generators
- Single external master Set/Reset signal preferred.
This same manufacturer's literature then states that a minimum 75% fault coverage is required -- an interesting number since it would result in a defect rate of well over 1% or 10,000ppm.
In the end, designs originally created for FPGAs will rarely meet all of the DFT rules required to reach acceptable levels of fault coverage when migrated to a conventional ASIC solution. A different approach is required to make ASIC speed, capacity, and cost available to FPGA users without requiring modifications to their existing designs.
Other embedded ASIC test solutions -- CrossCheck
The first embedded ASIC test solution was sold by a company called CrossCheck in the 1980s. This was reasonably successful at the time and offered an increase in controllability and observability over conventional scan. Actually, given the willingness of the user to implement a large number of transistor switches for sensing, 100% observability could be reached!

Figure 6 - CrossCheck embedded test architecture
A simple example of this architecture is shown in Figure 6. Notice that switches S1 and S2 are capable of observing gates G1 and G2 respectively. In a similar way, it is possible to add enough switches to the X-Y matrix to observe all nodes.
However, controllability has a number of problems. First, control is accomplished by "overdriving" nets that are already being driven by active drivers. Given the wireload issues in today's deep-submicron technologies and the varying sizes of drivers that are required in a typical design, overdriving may simply not be practical on many nets. A form of control that does work without drive limitations is demonstrated by switch S3 driving an input on gate G3. While this cannot fully control the output of gate G3, it can disable it in circumstances where this is desirable -- for instance, breaking feedback loops or blocking gated clocks or asynchronous set/resets.
Another limitation in controllability for the CrossCheck architecture arises when one attempts to simultaneously control multiple nodes with switches that are in different rows and columns - undesired switches can be activated. Overall, while an enhancement to conventional scan, the CrossCheck architecture was not a 100% solution and, in view of its complexity (it had to be custom synthesized for each design) and limitations was therefore not generally adopted.
Other embedded ASIC test solutions -- logic BIST
A variation on scan test called BIST (Built-In Self-Test) is being used by some conventional ASIC suppliers, and promises to reduce the time required to test devices during the manufacturing test process, as well as allowing devices to use less expensive testers. Here, additional circuitry is introduced within a device to create pseudo-random patterns that become the test stimulus, with signature generators being inserted to interpret the results.
This reduces the burden on the test system and allows more patterns to be applied in less time at higher speeds, to some extent also increasing fault coverage simply by the sheer quantity of vectors applied. Often, BIST "wrappers" are constructed around RAMs or blocks of logic, which are then tested independently. Many IP cores purchased from third parties are supplied with BIST wrappers. Sometimes, logic BIST is even used for all the logic in an ASIC design.
However, BIST still relies on conventional scan structures being inserted into the logic as shown in Figure 7, and hence, still requires DFT rules to be followed in order to provide tolerable levels of fault coverage. Also, BIST introduces some additional DFT rules at the interface between the BIST wrapper surrounding a particular block of circuitry and other functions in the design. It is not uncommon to find that untestable faults have been inadvertently introduced at this interface.
In the end, the evolution of the conventional ASIC flow, even with the addition of Logic BIST, does not lead to a smooth methodology without the long iterative process and associated pain. It also does not lead to the levels of fault coverage that should exist in order to make device fallout levels on expensive PCB assemblies truly acceptable.

Figure 7 - Logic BIST
What's needed is an alternative approach that adds control and observe capability without the limitations that come with the traditional "scan" approach, whether used alone or as part of logic BIST. A new approach is needed that not only increases fault coverage and eliminates DFT rules, but frees the designer from ever having to think about test.
The needed methodology would enable what ASIC designers have only dreamed about - the "testless design flow".

Figure 8 - No scan required here
AutoTest -- a new architecture for ASIC test
Lightspeed Semiconductor believes solving the test problem requires an entirely new approach. With that in mind Lightspeed created the first modular array architecture. Unlike conventional ASICs, the function modules within a modular array contain both "control" and "observe" capability. This enables manufacturing test to be performed by isolating individual modules and nets - fully validating the silicon integrity with 100% fault coverage, regardless of the user design implementation - and regardless of DFT rules.
A general view of the embedded AutoTest architecture is shown below. For simplicity, the focus here is on the Q_Cell array with its unique "control and observe" capability. In reality, there will be clouds of combinational logic interspersed between Q_Cells, but since these clouds will have no unbroken feedback loops or re-convergent paths, they are fully testable.
The array of modules is bordered by test control logic that drives an X-Y matrix of control signals through the array. As indicated within the modules in the figure below, each Q_Cell can be individually controlled to be in test mode or normal mode. Test mode is where information is frozen in the test latches and can be either shifted in (control) or shifted out (observe). Alternately, individual cells may be placed in normal (user function) mode where each cell performs the function it is configured to perform during normal user circuit operation. The transition of a particular cell from normal to freeze mode also captures the output logic value produced by the cell, which can then be shifted out for observation.

Figure 9 - Control for AutoTest within modular array
The AutoTest circuitry is operated in a manner quite different from conventional scan testing. As mentioned earlier, the scan test methodology used for conventional ASICs requires all scan flip-flops within a design to be in "test_mode" at the same time. In contrast to this, the sequence of operation for AutoTest will cause some modules to be in test mode while others are in normal mode during any specific test cycle within the sequence.
Whether or not a particular module is in "test" or "normal" mode is controlled by the X-Y matrix of signals called CC (cut column) and CR (cut row) as shown below.

Figure 10 - Freeze control operation of AutoTest latches in Q-Cell
The coincidence of logic "0" signals on both CC and CR at a particular Q_Cell will place that cell in normal mode. Conversely, a logic "1" on either CC or CR at a particular Q_Cell will place that cell in freeze mode.
A test sequence typically consists of the following sequence of events:
- Set all CC and CR lines to "1". All cells enter freeze mode.
- Load test latches with stimulus values.
- Toggle CC and CR lines for selected Q_Cells. Selected cells enter normal mode - then re-enter freeze mode - thereby capturing resulting output value.
- Shift data out of test latches to observe results.
How AutoTest fixes violations
Some DFT violations are inherently not a problem for Lightspeed Modular Arrays, simply due to the basic paradigm of AutoTest. AutoTest treats all nets the same way - whether they are clocks or not, and regardless of polarity. This inherently covers the DFT rule concerning clock polarities as shown in Figure below.

Figure 11 - Clock polarity DFT rule
During the physical layout process, Q_Cells are occasionally substituted for P_Cells of equivalent functionality where a net needs to be controlled and a Q_Cell is not already in place. Another DFT rule where Q_Cells fix the violation relates to asynchronous sets and resets and is shown in Figure below.

Figure 12 - Asynchronous set/reset DFT rule
In Figure 11, the AND-OR gate is implemented with a Q_Cell and can therefore be controlled in test mode so as to not interfere with the synchronous clocking of the flip-flop. Figure 12 demonstrates how re-convergent redundant paths are automatically broken by a Q_Cell in one of the signal paths.
Summary
Often, ASIC designers wish they had the freedoms FPGA designers enjoy. Not having to worry about test issues is one of those freedoms.
Conventional ASICs use test methodologies that require a multitude of DFT rules to be followed in order to obtain tolerable levels of fault coverage for manufacturing test. Meanwhile, the complications of handling test issues greatly slow the ASIC development process. The persistence of these test-related problems has created a need for an alternative approach to conventional SOC/ASIC development. The architecture-based solution provided by the AutoTest structures contained in Modular Array ASICs fulfills this need.
Bob Osann founded Lightspeed Semiconductor in April of 1995. He was president and CEO of Lightspeed from April 1995 to January 1998 and chairman from January 1998 to August 2000. Osann has more than 25 years of experience in a variety of semiconductor, systems and EDA companies. Prior to Lightspeed, he was co-founder and vice president of marketing at Aptix Corporation. He was vice president of advanced products at Personal CAD Systems and president and CEO of Assisted Technology.