Test Coverage Analysis of Partial Scan SoCs using ATPG and Fault

Simulation of Functional vectors using TetraMax: A Case Study

Mugil Vannan H
[mugil.vannan@st.com]

ST Microelectronics India Pvt Ltd. Noida

Abstract
SoC designs with full-scan architectures rely on test vectors generated from an ATPG tool
like Synopsys Tetramax for fault coverage and diagnosis. But the partial and non-scan
devices rely heavily on functional test patterns for the test coverage. The functional test
vectors use internal BIST techniques like signature analysis using LFSR for the detection of
faults in the logic. TetraMax offers a flow for the fault simulation of these functional
vectors and derive the test coverage of a non-scan or partial scan design using externally
generated vectors. It also gives an estimate of the effectiveness of a functional test vector in
catching Stuck-at faults. This paper discusses the flow in implementing the ATPG and
Fault Simulation flow for a partial scan ST7 based device using TetraMax. Fault simulation
flow involves the modeling of RAM and ROM blocks leading to better coverage of the
shadow logic. It also details the problems faced and conclusions obtained from the activity.

Introduction:
The TetraMax ATPG tool comes with an integrated fault simulator for fault grading
externally generated functional test vectors. These functional test vectors are usually
assembly programs simulated on the RTL or Gate level netlist using a logical simulator like
Synopsys VCS or Cadence NCSim. The functional test vectors are programs written with
the design specifications in mind rather than manufacture defects (like stuck-at faults) that
reside in the combinational logic of a design. The functional test vectors use internal BIST
(Built In Self Test) features like Signature Analysis Techniques that use LFSR (Linear
Feedback Shift Register) techniques to produce a test signature that is shifted out at the end
of the test. The Partial and Non-Scan designs predominantly use the functional test vectors
for fault detection. Unlike Full Scan designs, where ATPG patterns generated by the tool
yield very high fault coverage, functional test vectors do not offer a test coverage metric on
their own. But they can be fault graded using a fault simulator (like TetraMax) to find out
the coverage yielded by the pattern. The following discussion elaborates on the background
of the ST7 device, the flow used to generate the functional vectors, the TetraMax
methodology used to fault simulate the vectors, the advantages of the flow, the problems
faced and the conclusions drawn from the activity.
Device Background:
The ST7 device is an 8-bit microcontroller developed for the automotive market. The
device is designed in STs CMOSM6DH (0.5 m) technology. The device has a central ST7
core surrounded by a host of digital peripherals such as Timer, SPI and SCI and analog
blocks such as RAM, ROM, ADC and PLL. The device has partial scan in one of the digital
IP blocks.
Item
Process

Technology
ST CMOSM6DH (0.5 m)

Total Gate Count

22785

No of Sequential elements

1438

No of scan elements

91

Max Operating Frequency

16 MHz

Pattern generation:
The ST7 functional test patterns are assembly programs in hex form that are simulated
inside the RAM similar to the Application programs run by the end user of the chip. We
used NCSim version 4.0_s6 to simulate the assembly patterns. We write out a VCD (Value
Change Dump) file. The VCD file is then converted into a WGL (Waveform Generation
Language) file using an ST internal utility. The WGL format is a defacto industry standard
accepted by many tools and also production testers like IMS and ITS. TetraMax accepts
external patterns in wide range of formats including WGL. We used the WGL format since
we deliver the same WGL to the Engineering team who test it on the Silicon. So the
functional vectors used for fault simulation and the ones tested on the silicon are the same.
ATPG Fault Simulation Methodology:
Fault simulation of functional vectors can be performed stand-alone in case of non-scan
designs or in combination with ATPG for partial scan design as in our case. The typical
flow for ATPG followed by fault simulation is as follows.
1. Use TetraMax to generate ATPG patterns for the Scan part of the design.
2. Save the uncollapsed fault list from ATPG
3. Revert back to the DRC mode and perform DRC without SPF file
4. Reload the saved fault list.
5. Run a good machine simulation of the external functional vectors.
6. Fault Grade the functional pattern that has been generated.
The above flow is also well suited for Full-Scan designs, as we can analyze the coverage
from the ATPG and then decide on the sub-blocks that need additional coverage effort in
the form of functional vectors. The flow and the sample script are available in TetraMax
User Guide and the Solvenet home. If step 5 fails, there is no use in fault simulating the
external patterns as the coverage results obtained would be erroneous. This is given more
attention in a later section.

TetraMax Fault Simulation Environment:

In Fault simulation, TetraMax runs the patterns in the same way as it is run in the logical
simulation environment. If we have any verilog behavioral models used in generating the
pattern, they have to be replicated in TetraMax environment also. Otherwise the good
machine simulation of the pattern could fail. There are a few differences between the
simulator in TetraMax and the one used in logic simulations. TetraMax is a cycle-based
simulator as compared to the event-based simulator used to generate the patterns.
Cycle-based simulators calculate the steady state response of the circuit at each clock cycle
at the boundary of the combinational block between two registers. They do not propagate
the values through each and every gate, as in event-driven simulations. As a result, the
cycle-based simulator doesnt take into account the delay at the gates and is a zero delay
simulator. TetraMax is a cycle based simulator. It calculates the values of the simulation at
the boundary nodes (Figure 1) at the clock edges Also the TetraMax has a Full Sequential
engine to fault simulate the functional patterns. The main advantage of the cycle based
simulators is that they speed up the simulations by a factor of 10 to 100 as compared to the
Event driven simulators. But the disadvantage is that glitches cannot be detected. Also
TetraMax cannot include back annotation timing information (in the form of SDF files) in
its simulation.

Figure 1. Cycle based Simualtion

Memory Models:
As mentioned earlier, our functional patterns are first loaded inside the RAM by the CORE
logic and then the program executes from the RAM. Also the ROM stores the addresses of
the interrupt and the RESET vectors. So, both RAM and ROM memory models are
essential to run our test vectors. TetraMax supports a very limited subset of verilog syntax.
Writing TetraMax compatible verilog models is very difficult because of this limitation. For
example, in our case the ROM is segmented into two parts and the the incoming address
has to be decoded before reading from the respective segments. But TetraMax supports
only conventional memory structures and subsequently we were unable to code the
decoding logic in verilog and had to design the same using structural elements. So, even
the TetraMax behavioral models are mostly structural.
Shadow logic Fault detection:
TetraMax cannot detect faults around the shadow logic if they are defined as black boxes.
But in the case of functional pattern fault simulation we had to model these black boxes
and automatically were able to detect the faults in the shadow of analog blocks such as
RAM, ROM and the ADC. After modeling the analog blocks we only need to run the
relevant functional pattern for the shadow logic to detect the faults in the region.
For example, we had initially defined the ADC as a black box for the fault simulation. As a
result the faults in the ADC interface (digital block) were in the shadow and were not
detected. We wrote a rudimentary ADC model in verilog (compatible to TetraMax) and
then ran a couple of ADC Interface functional test vectors. The coverage of the ADC
interface block immediately went up.
This strategy can also be used in the case of Full-Scan designs, to improve the final
coverage after the ATPG run.
Shadow Logic
ADC Interface

Total Faults
760

Initial Test Cov

4.53%

After Fault simultion

61%

Test Coverage Vs Code Coverage as a metric for writing functional Patterns:

IP designers usually use the RTL Code coverage obtained from tools like (VNavigator) as
the basis for writing functional patterns to test the RTL State machine completely. From a
Specifications perspective, it allows the designer to know whether the RTL code is bug free
and adheres to the intended functionality. These functional vectors are eventually used in
production testing where they are run on the final silicon.
The Code coverage results for a set of functional vectors usually include a list of statistics
like 1.Statement coverage, 2.Branch coverage, 3.Toggle coverage. We did an exhaustive
comparison of these figures for a set of functional vectors for each IP against the test
coverage, obtained from the fault simulation of those vectors in TetraMax. The results are
presented in the graph below.

The main aim of this discussion is to emphasize the need to fault simulate the functional
vectors before including them in the production test set. From the graph we can see that a
good statement or toggle coverage does not necessarily mean good test coverage. For a
fault to be detected, it has to be both controlled and propagated to one of the primary ports
of the DUT where it can be observed. But a figure like Toggle coverage is concerned only
with controllability of a node.
These functional patterns occupy a large size and impact heavily on the tester time for a
very poor return on the fault coverage, which renders most of them redundant for
capturing manufacture defects.

Fault grading functional vectors is an effective method to weed out patterns that do not
capture many production faults. Thus we can reduce the size of the production pattern set
and also save on testing time per device. It is needless to say that test coverage is an
important statistic to bridge the gap between testing functionality and capturing stuck-at
faults.
External Vectors failing Good Machine simulation:
We have to perform a good machine simulation using the functional patterns before
running a fault simulation, to compare the TetraMax simulation responses to the expected
responses found in the pattern. If the good machine simulation fails, there is no point in
proceeding with the fault simulation as the figures obtained would be meaningless.
In our case we faced the problem of some WGL vectors failing the good machine
simulation. A possible reason could be that the behavioral models used in TetraMax and
Logical simulations could be different. But in our case, we use the same memory models
and netlist to generate the test vectors. It could also be due to the difference in the
simulation engines used by TetraMax and NCSim. NCSim is an event based simulator and
TetraMax is a cycle based simulator. But other patterns succeed in the same environment.
Also the kinds of patterns that failed had very little in common between them. For most
part the failures were random.
We tried an alternate approach of generating EVCD (Extended Value Change Dump)
patterns from NCSim that can be directly read by the TetraMax. This partly solved our
problem as some of the failing WGL patterns passed in the EVCD format. But some
patterns were still failing. A TetraMax bug was confirmed and a STAR was raised (No.
9000064596).
Room for Improvement:
Tetramax fault simulator is a good tool for grading functional vectors. But we faced a few
limitations while using Tetramax. The main limitation is TetraMaxs inability to
understand many verilog constructs. It prevents us from effectively modeling sophisticated
analog blocks such as ADC, Flash memories and segmented ROM. Also there is a need for
a waveform viewer. It is very tedious to debug full sequential patterns on the GSV
(Graphical Schematic viewer).

Conclusion:
This paper has attempted to address the need for fault grading functional patterns. Fault
simulation provides a means to analyze the test coverage of Partial and Non-scan devices.
It can also be used to improve the coverage of full scan architectures by running a few
functional vectors after the ATPG run. It is a good means to detect redundant functional
vectors that have low fault detection capability. During the course of our activity, we wrote
a number of functional patterns aimed at the Non-detected fault classes such as AP, ND
and AU. We were able to improve the test coverage of the device from 8% (through partial
scan ATPG) to 85 % with the help of functional patterns aimed at the non-detected faults.
We also found that Test coverage is a better metric than Code coverage as far as developing
production test patterns are concerned. The Tetramax reports associated with the Test
coverage analysis are provided in the Appendix.
References:
[1] TetraMax ATPG User Guide. Version 2004.06. May 27 2004
[2] Cadence NC_VHDL Simulator Help. Version 4.0 July 2002.
[3] ST Internal VNavigator Guidelines. Release 0.2. October 9 2002

Appendix: Test Coverage Reports

After Partial Scan ATPG
Uncollapsed Stuck Fault Summary Report
----------------------------------------------fault class
code #faults
------------------------------ ---- --------Detected
DT
7139
detected_by_simulation
DS (5970)
detected_by_implication
DI (1169)
Possibly detected
PT
291
atpg_untestable-pos_detected AP
(16)
not_analyzed-pos_detected NP
(275)
Undetectable
UD
6033
undetectable-unused
UU (5358)
undetectable-tied
UT
(364)
undetectable-blocked
UB
(45)
undetectable-redundant
UR
(266)
ATPG untestable
AU 82061
atpg_untestable-not_detected AN (82061)
Not detected
ND
1396
not-observed
NO (1396)
----------------------------------------------total faults
96920
test coverage
7.85%
fault coverage
7.37%
----------------------------------------------Pattern Summary Report
----------------------------------------------#internal patterns
168
#basic_scan patterns
168
-----------------------------------------------

Partial Scan ATPG + Fault Simulation of functional vectors:

Uncollapsed Stuck Fault Summary Report
----------------------------------------------fault class
code #faults
------------------------------ ---- --------Detected
DT 76308
Possibly detected
PT
5852
Undetectable
UD
4709
ATPG untestable
AU
0
Not detected
ND
7921
----------------------------------------------total faults
94790
test coverage
84.71%
fault coverage
80.50%
----------------------------------------------Pattern Summary Report
----------------------------------------------#internal patterns
0
#external patterns (/data/521cvgr/Patterns_mug/wgl_atpg/cons_iddq_ram5.vcd.first.wgl) 261698
#full_sequential patterns
261698
-----------------------------------------------