Fault coverage is a number generated and reported by EDA tools, namely, fault simulators. The accuracy of fault coverage with today's EDA tools is inadequate, for various reasons:

• No two tools generate the same number of faults for the same design.
• No two tools report the same number of detected faults for the same design.
• No two tools report the same number of tied faults for the same design.
• No two tools report the same number of redundant faults for the same design.
• No two tools report the same fault coverage for the same design.

The most important quality criteria for evaluating semiconductors is the defect part per million (DPPM). The relationship between DPPM or defect level (DL), fault coverage (FC), and yield were studied and characterized by Williams and Brown (IEEE Transactions on Computers) in the early 1980's as follows:

Y represents yield, and T is test coverage (used interchangeably here with fault coverage). In 1996, Toshiba indicated that T1/2 should substitute for T in the above equation to track fairly well with actual data (Design-for-Test Handbook, 1996). From the above equation, it's clear that the higher the fault coverage, the lower the DL. When FC is at 100 percent, DL reaches zero, regardless of yield. For this reason, semiconductor companies have worked hard to achieve higher fault coverage with various design-for-test (DFT) schemes in their designs. Also, many companies have established fault-coverage goals in their design and quality processes.

According to reports from the IEEE International Test Conference (ITC'99), there are more than a dozen commercial tools that report fault coverage. Including the number of fault-coverage reporting tools in use internally by companies, there's an estimated thirty distinct tools reporting fault coverage worldwide. A typical problem with many of these tools is that, for the same design, no two tools report the same fault coverage. In general, it isn't uncommon to see 5-percent fault-coverage variation with different tools for the same design.

Figure 1 - Circuit with a redundant gate

With a 5-percent fault-coverage variation, weeks - and probably months - of extra effort are needed to meet fault-coverage goals. At Adaptec (San Jose, CA) for example, we had a design that didn't meet the customer's fault-coverage requirement (it was 4.2 percent short) and we spent 13 man-months - equivalent to more than a quarter million dollars - to finally meet the requirements.

Table 1: Fault lists from circuit 1 using two tools
Instance Name	Number of faults Tool A    Tool B
U1	6	6
U2	6	6
U3	6	6
U4	8	8
I/O	0	8
Total	26	34

In addition, with a range as large as 5-percent in fault-coverage variation, there is the risk of actually losing a customer contract. For example, assume that the yield is 90 percent, while fault coverage is at 96 percent reported by one tool and at 99.99 percent with a competing tool. According to the equation, the DPPM is 4,205 and 11, respectively - dramatically different metrics from the two tools. Of course, if customers learn that the DPPM of a product is over 4,000, the customer base quickly evaporates. If, however, customers hear that the DPPM of a product is 11, they tend to embrace the product and the supplier.

Table 2: Fault lists from circuit 2 using one tool
Instance Name	Number of faults Basic Tool with Tool options enabled.
U33	0	8
U34	8	8
U35	6	6
ff11	8	8
ff12	8	8
ff21	8	8
ff22	6	6
u_ddt2	0	0
I/O	0	0
Total	44	50

Unfortunately, a 5-percent fault-coverage variation may also result in possible legal issues. For example, an IP vendor may claim fault coverage of 99.5 percent using tool A for characterizing coverage of the product. The potential IP buyer, however, may measure the same product and see the coverage drop to 96.5 percent using tool B. With 5-percent fault-coverage variation, the value of fault coverage is dubious, at least in the minds of potential customers.

Why is there as much as a 5-percent fault-coverage variation between different tools? The cause is rooted in the lack of a consistent definition of fault coverage across the industry. Tool vendors define fault coverage based on their "common sense" - clearly, the definition of fault coverage varies from tool to tool.

Figure 2 - Circuit with a black box

Missing faults from I/O pins

Some tools don't generate faults on I/O pins, generating one source of discrepancies. In Table 1 for example, tool A generates 26 faults for Circuit 1 as shown and tool B generates 34 faults for the same circuit (see Figure 1; see Table 1). How did tool A miss 8 faults? Answer: they are the faults from the four I/O pins.

We can't simply assume that chip I/O faults have been tested (or are even testable for that matter) and thus, they disappear from the fault list. Some faults on I/O pins aren't easily tested, such as pull-up and pull-down. We could change our methodology and/or enhance our DFT scheme - or add more and different vectors to guarantee fault coverage of those untested faults, should we know that these faults weren't tested. Simply eliminating these faults from the fault list yields inaccurate and misleading information about fault coverage and is simply not acceptable.

Table 3: Fault lists from one tool in different modes
Instance Name	Number of faults Combinational  Sequential
U33	0	8
U34	6	6
U36	6	6
ff11	14	14
ff12	14	14
ff21	0	8
ff22	12	12
I/O	0	0
Total	52	68

In Figure 2, the instance u_ddt2 is a black box. A tool generates 44 faults by default. The missing faults are those in fan-in cone logic of u_ddt2, U33, ff22/Q, and inputs of u_ddt2 itself (see Table 2).

In reality, some cells - for instance, complex embedded memory cells, analog cells, and special clock domain synchronization cells - may not have their ATPG models, and they become black boxes in ATPG. When a design contains black boxes from ATPG, special DFT schemes (such as scan register wrapper) help. Simply eliminating these faults from the fault list yields false information about a design's testability and fault coverage, and isn't acceptable.

Combinational mode

In Figure 3, flipflop ff21 is out of the scan chain. (This may be the case for critical timing paths.) In combinational ATPG, some tools don't generate faults on its fan-in logic as shown in Table 3.

Table 4 summarizes the fault numbers from two real-world designs. Clearly, in the combinational mode, the number of faults is smaller than in the sequential mode.

Figure 3 - Circuit that is not full-scan

The fault difference between the combinational mode and sequential mode creates great confusion and headache within the typical ATPG flow - the combinational mode runs first (because it runs faster) and is then followed by running the incremental sequential mode (see Table 4). Subsequent questions from management often follow: You get higher fault coverage in the first place (combinational run) - why does the fault coverage drop off after the second run? What's the value of expensive, sequential ATPG if the results are sub-standard compared with the combinational mode?

Discounted faults

In fault-coverage calculation and reporting, some faults are discounted or are redundant. Circuit 1 contains redundant logic in order to eliminate the glitch (see Figure 1). The two tools examined do generate eight faults from redundant logic. However, in the fault-coverage report, these eight faults are discounted by tool A and thus the fault coverage for Circuit 1 is measured at 100 percent.

Table 4: Numbers of faults in different ATPG mode of the same tool
Design	ATPG Mode Combinational  Sequential
A	720290	723882
B	396356	402282

Tool B behaves differently. In a regular fault-coverage report, these eight faults are counted and classified as untestable, and reports a 69-percent fault coverage(see Table 5). It also reports, however, 100 percent testable fault coverage, which creates additional confusion about fault coverage.

Table 5: Fault coverage from two tools
Item	Tool A     Tool B
Fault Coverage	100%	69%
Testable Fault Coverage	NA	100%

Redundant faults should never be discounted in fault-coverage calculation. A defect in redundant logic may affect the design's expected behavior. The testability issue is hidden when 100 percent fault coverage is reported. If we know that there is an issue in testability because of redundant logic, then an additional DFT scheme should be considered, such as adding observable points.

Tied faults

Tied faults are faults on pins that are tied to power (Logic 1) and ground (Logic 0). All tools exclude tied faults in fault-coverage calculation in one way or the other. Tied logic, just like any other logic, can go wrong in manufacturing. If a tied-1 pin has stuck-at-zero defect, a design may not function as expected. Excluding tied faults in fault-coverage calculation doesn't reflect silicon defect of tied logic and can yield false information about testability within a design.

Table 6: Fault-coverage calculation formulas used in three tools
Tool	Formula	Remarks
A	FC = (Fd+PT * Prop) / Ft TC = (Fd+PT * Prop) / (Ft-UD)	Ft: Total Faults Fd: Detected Faults
B	FC = Fd / (Ft-tied-redundant)	PT: Possible detected faults
C	FC = Fd / Ft	UD: undetected faults Prop: a user-controlled PT probability TC: Test coverage

If a testability issue is perceived, further enhancement of the DFT scheme with on-chip zero/one generator is strongly recommended. Additionally, fault coverage is calculated with a formula. Today, there aren't any two tools that use the same formula. Table 6 shows fault-coverage calculation formulas from three different tools.

Mandating change

The discrepancies - identified here between several commercially available tools - have created tremendous difficulty in fault-coverage integration of ATPG, incremental fault simulation of functional vectors and IDDQ, and communication among tools. More importantly, the inconsistencies bring into question the value of fault coverage. For an experienced user of a tool, it isn't difficult to pump up 1 to 2 percent fault coverage.

Therefore, the subject of fault coverage with commercial EDA tools is a vital one. Both the semiconductor and EDA industries must establish industrial standards for fault coverage. The total number of faults provides the basis for the determination of fault coverage. As stated earlier, great discrepancies exist in generating total number of faults. For the same design, the total number of faults varies from tool to tool, and even from option to option within the same tool.

London Jin is director in charge of verification and test in microprocessor engineering of Toshiba in San Jose. He was previously a senior manager in IC development and DFT technology at Adaptec.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to mikem@isdmag.com.