You are on page 1of 27

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/233960880

Strategy to Achieve High Test Coverage for SOC

Conference Paper · August 2008

CITATIONS READS
0 1,311

1 author:

Nor azura Zakaria


Malaysian Institute of Microelectronic Systems
8 PUBLICATIONS   6 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MBIST in DFT View project

All content following this page was uploaded by Nor azura Zakaria on 02 June 2014.

The user has requested enhancement of the downloaded file.


Strategy to Achieve High Test Coverage for SOC

Nor Azura Zakaria

MIMOS BERHAD, Malaysia

norazura@mimos.my

ABSTRACT

Yield issues are very important and costly in semiconductor manufacturing process as it depends
on the maturity of the process technology involved. To address yield issues and make sure the
silicon device comes out functionally successful requires very high test coverage. In this paper, it
will present the strategy to ensure that high test coverage more than 98% coverage can be
achieved for SOC chip with multimillions of gates.

The work is cover from RTL level up to test pattern generation. It is also discussed further about
how to debug DFT violation and failure in ATPG simulation. Full scan implementation has been
done for testing core design 0.18 um process technology with 3 M gates SOC design.

In this paper also, it is also presented the flow and methodology that used in IC design Lab for
every stage and why the flow in implemented in this work.
Table of Contents

1.0 Introduction………………………………………………………………………………….6
2.0 DFT Challenge and DFT Goal……………………………………………………………...6
2.1 DFT Project Implementation……………………………………………………………….6
2.2 Full Scan Flow and Methodology…………………………………………………………..7
2.3 RTL Cleanup………………………………………………………………………………...9
2.3.1 Common DFT Violation………………………………………………………………...9
2.3.1.2 Latches…………………………………………………………………………...9
2.3.1.3 Uncontrollable Clock…………………………………………………………….9
2.3.1.4 Asynchronous Reset As a data………………………………………………….9
2.3.1.5 Bus Contention………………………………………………………………….10
2.3.1.6 Sensitivity of Feedback Loop…………………………………………………..10
2.3.2 Violation Coding Example……………………………………………………………..11
2.4 Synthesis and Scan-Stitching………………………………………………………………12
2.4.1 Scan Chain Architecture……………………………………………………………….13
2.4.2 Scan Testing Clock……………………………………………………………………...13
2.4.3 Control Signal during Scan Testing…………………………………………………...13
2.4.4 Hookup Test Port……………………………………………………………………….14
2.4.5 Latch Clock Gating……………………………………………………………………..15
2.5 Handling Hard Macro: ARM7TDMI and Memories…………………………………….16
3.0 ATPG Run and Fault Simulation………………………………………………………….16
3.1 Increasing Test Coverage With Data Analysis……………………………………………16
3.2 Blockage Tracking and Debugging………………………………………………………..18
3.3 Fault Simulation with VCS Simulator…………………………………………………….20
3.4 Failure Simulation and Debugging………………………………………………………..23
4.0 Discussion and Conclusion ………………………………………………………………..25
4.1 Discussion……………………………………………………………………………….25
4.2 Conclusion...………………………………………………………………………………...26
5.0 Acknowledgement...………………………………………………………………………...26
6.0 References…………..……………………………………………………………………….26

SNUG Singapore 2008 2 Strategy to Achieve High Test Coverage for SOC
List of Figures

Figure 1: Wireless IC Design at top level design ……………………………………….………..7


Figure 2: Recommended DFT Flow………………………………………………………………8
Figure 3: Bidirectional Pad. ……………………………………………………………………..10
Figure 4: Example Violation.. …………………………………………………………………...11
Figure 5: Test Mode Selection Module….……………………………………………………….13
Figure 6: Scan Chain Architecture….……………………………………………………………14
Figure 7: Latch Clock Gating for DFT.. ………………………………………………………...15
Figure 8: Memory Bypassed Using scan_mode signal..…………………………………………16
Figure 9: Fault Number vs Test Coverage……………………………………………………….17
Figure 10: Graph Test Coverage vs Module Name……………………………………………...17
Figure 11: Blocking Path between USB and Synchronous Reset Synchronizer Module………..18
Figure 12: Blockage path before fixed………………………………………………………......19
Figure 13: Blockage Path is Removed…………………………………………………………...19
Figure 14: Fault Number vs Test Coverage……………………………………………………...19
Figure 15: Test Coverage vs Module Name……………………………………………………..20
Figure 16: Recommended Scan Simulation Flow……………………………………………….22
Figure 17: Data Shifting Failure. ………………………………………………………………..23
Figure 18: Hold Violation Causing Failure……….…………………………………………..…24

SNUG Singapore 2008 3 Strategy to Achieve High Test Coverage for SOC
List of Tables

Table 1: Simulation Result Case I………………………………………………………….……25


Table 2: Simulation Result Case II………………………………………………………..……..25

SNUG Singapore 2008 4 Strategy to Achieve High Test Coverage for SOC
1.0 Introduction

Semiconductor manufacturing is like any other production process and has inter-related
chemical, electrical and mechanical engineering operations. The yield is defined on the
expectancy of the silicon output without any manufacturing defects or faults.

Test coverage is calculated based on how many faults that can be covered compared to the total
number of possible faults in the chips. Since the complexity of the SOC increases rapidly, there
is no way to test the millions of gates in a chip without help from well- structured test programs.
Objective of the test program should be to generate test patterns that controls and observes
almost all possible fault sites within silicon from chip periphery.

Test Coverage = DT + (PT x PT_credit) x 100


All_Faults - UD - (AN x AU_credit)

" PT = Possibly Detected Faults


" DT= Detected Faults
“PT_credit= initial 50 percent
“UD = Undetectable
“AU= ATPG untestable-not detected
“AN= ATPG untestable and not detected
From this formula, test coverage result is proportionate to the all detected fault value. So in this
paper, the strategy that we implemented in this project is ensuring that all possibility detected
(PT) and DT (detected) fault must be increased. The design must be testable following DFT rules
so that ability to observe and control is in our hand. Engineer has to know where the clocks and
asynchronous reset is handling in the design.

In section 2.0, it is elaborate the method in each stage from coding level until scan stiching. It is
also give an example coding method and how to debug the DFT violation. It is also describes
DFT architecture in SOC for handling clock distribution, reset distribution and bypassing IPs. All
DFT architecture with the correct constraint and the specification for all valid scan path and
invalid scan cell must be listed in DFT work. Debugging method and analysis method is
discussed in Section 3.0. ATPG setting in TETRAMAX determined the success of DFT
performance in verfying scan specification and all the information is important while debugging
failure in scan simulation In Section 4, some points from this prior work need to be discussed as
for the reference and improvement in future work. The conclusion is also including at the end of
the paper.

2.0 DFT Challenge and DFT Goal


2.1 DFT Project Implementation
Wireless Design that has 3 M gates is integrated with PLL, ARM7TDMI, AMBA peripheral,
USB peripheral and 17 memories and targeting to 0.18 um process technology. All the IPs

SNUG Singapore 2008 5 Strategy to Achieve High Test Coverage for SOC
embedded in this SOC design had been bypassed using test mode pin during testing exclude USB
and AMBA module. For USB and AMBA module, the scan chain will be implemented and
integrate with other module in design. In Figure 1, it shows the design diagram of the this
Wireless IC with its BSR(Boundary Scan Register) cell. This design is consist of 256 pads, BSR
cell to support boundary scan testing, JTAG tap controller, core design and some small is
sub_top_core in handling clock and reset.

Figure 1: Wireless IC Design at top level design


2.2 Full Scan Flow and Methodology
There is few method and methodology you can follow to complete your full scan implementation
[2],[3],[4]. As the full scan implementation is done after synthesis process, the DFT flow is
depending on the flow you chose in synthesis. After dealt with many issues on the timing
problem, there are two approaches that have been done; one approach is optimizing the design by
using bottom up synthesis and another one is top down synthesis. While achieving test coverage
targets at two different flows, there is so many challenges that need to be faced as some of the
architecture especially clock driven and reset driven at top level is need to be changed.

Design Flow DFT Structure Test Coverage Timing Closure


Bottom Up Synthesis 4 mains block group 99% Not achieved
and integrated at top
level
Top Down Flow Scan stiching at core 98.08% Achieved for
level. Output of the core functional and test
level is connected mode
manually and compiled.

SNUG Singapore 2008 6 Strategy to Achieve High Test Coverage for SOC
But after achieved the target there is a recommended flow that DFT engineer could follow. The
recommended flow is shown at Figure 2.

Figure 2: Recommended DFT Flow

SNUG Singapore 2008 7 Strategy to Achieve High Test Coverage for SOC
2.3 RTL Cleanup:
As mentioned at introduction part, the strategy that we emphasized to have a quality result for
DFT performance is ensure all RTL blocks is passing DFT violation. The clean up RTL means
all the violations is need to improve at coding stage. In this stage the code is not only met its
functionality requirement but meet testability requirement.

There is an option in the tool to do automation fix for the DFT violation reported but due to some
violation the tools cannot improve it. It is also not advisable to use this approach as to forbidden
the tools creates its additional logic that could disturb timing requirement. It is also beneficial to
STA team, whereby the clock driven, generated clocks, uncontrollable asynchronous reset and
synchronous reset and feedback path loop can be traced earlier. From this information the timing
constraint and the timing optimization can be debugged earlier while designer doing the RTL
coding.

2.3.1 Common DFT Violation


The quality of the code is just not up to functionality goal but the quality of the code is must be
synthesizable and testable. If they follows DFT rule, violation can be easily avoided. Sometimes
because of human error, there will be a common dft violation that will come up. DFT Rules that
indicates the violation to the scan chain sequential element are:

2.3.1.2 Latches
Latch is normally design to avoid glitches or having some delay for certain condition of
achieving a good functionality. But for DFT purpose, latch would not be included in scan chain
and tools would define it as non scan flip flop. As for this purpose if the designer could avoid the
latch, it will better to get the high coverage of the design. But if there is no ways to avoid latches
to meet the functionality performance, before scan stitching all the latches must be define to be
excluded from scan chain.

2.3.1.3 Uncontrollable Clock


Uncontrollable clock violation could be caused by clock generated, clock drives the data and race
condition between scan flop and non scan flops while capturing mode. All the method to solve it
is normally is putting multiplexer and the control signal to select input signal is test mode [2].

2.3.1.4 Asynchronous Reset As a data


The most common violation that the designer always do is not put the register in initial condition
for the asynchronous reset. If this happen, the data come from the logic is connected to this signal
and as its function asychnronous to the clock the new data might be wrongly shifted. The failure
data could be caused if the value that goes to reset signal is 0 propagate while capturing mode
and after the clock rise for shifting mode, the reset value would reset all the value at its flops.

SNUG Singapore 2008 8 Strategy to Achieve High Test Coverage for SOC
2.3.1.5 Bus Contention
Bus contention could happen if the same bus is having a conflict data float in same bus between
two different flops. This is always happened if the code of the register is using multi dimensional
array method.
1) Multi-dimensional array
RTL example:

reg [10:0] apiu_pwr_meas_set1 [10:0]; // multi-dimentional array


apiu_pwr_meas_set1[0] <= 8'h00;
apiu_pwr_meas_set1[1] <= 10'h00;
apiu_pwr_meas_set1[2] <= 10'h00;
apiu_pwr_meas_set1[3] <= 10'h00;
There are two solutions to fix this violation. One is to avoid the array size more than 10 (but may
not be functionality feasible) and second one is to set naming rules while writing the netlist into
verilog format to avoid multi dimension array name issues:

define_name_rules --check_bus_indexing -flatten_multi_dimension_busses.

This option in DC, will ensure that the bus structures of multi-dimensional array will follow the
correct matrix as is has been coded.

2) Handling bidirectional pad

Figure 3: Bidirectional Pad

When scan input port is a bidirectional pad, to avoid the conflict of tester and design driving at
same time, the tristate buffer at this pad is always driven as an input pad during test mode. In test
mode, input enable (IE) is always to be set 1’b1 and output enable (OE) is always to be set to
0’b0.

3) Tristate driver
It is well known that the bus contention could be avoided also by not putting tristate driver in
your design module.

2.3.1.6 Sensitivity of Feedback Loop


Combinational feedback loop can be sensitive for the test pattern propagating especially while in
capturing mode. It could generate the failure in real testing. But some of the feedback path loop
is involved with the registers might caused the failure in simulation. Normally we would check
the sensitivity of feedback path loop how it is impact the controllable and observable of the fault

SNUG Singapore 2008 9 Strategy to Achieve High Test Coverage for SOC
in shifting and capturing mode. If there is any blocked path or the ATPG tools cannot search for
the new set of loading value to break the loop, the code must be changed as well.

2.3.2 Violation Coding Example

Some coding could be generated many violations based on the poor style coding. Example shown
in box below is the RTL that coded to generate the counter to count error bit. In the point of DFT
view, the first line of the RTL box code will generate the violation as the asynchronous reset
signal is having a computation with other data. Figure 4 is presenting all DFT violation that had
been reported by ATPG tool .All the other register that inputted by the violated asynchronous
signal (reset as data) or violated clock (clock as data) is violated.

rst a) Uncontrollable Asynchronous Reset

D Q

clk

All registers is violated rdat_tx , buff_tx_rdy , cn, k, bep , state ,


b_err_count, err_burst, rdy

b) Combination Feedback Pathloop Violation

X1 violation

A0

A1

Y
ber [1]

B0

B1 all path connect to ber [7:0]


is having a same loop path

c) Clock as a Data and Connected to Primary Output

Figure 4: Example Violation


Solution on Example 1:
Improving DFT violation could sometimes give the improvement for the functionality
verification. There is no doubt that sometimes the functional verification could not identify the
root of the failure for the asynchronous reset where it depends on the quality of the functional
testbench is been programmed. After identified the violation, the solution code is clean without
any violation after run DFT check on it.

SNUG Singapore 2008 10 Strategy to Achieve High Test Coverage for SOC
always @(posedge clk or negedge rst)
begin
if(!rst)
begin
rdat_tx <= 0;
buff_tx_rdy <= 0;
cnt <= 0;
ber <= 0;
ctrl_bep <= 0;
state <=0;
err_burst <= 0;
rdy <= 0; // 001-b1,010-b2,011-b3,100-b4, 111-
block
ber_done <= 0;
end
else
begin
if(rdy_tx) // grab tx data
begin
cnt <= cnt + 1;
rdat_tx[cnt] <= dat_tx;

if(cnt == 455)
buff_tx_rdy <= 1'b1; // all data are ready in buffer
end
else if(rdy==3'd7)
begin
buff_tx_rdy <= 0;
rdy <= 0;
ber <= 0;
err_burst <= 0;
ctrl_bep <= 0;
ber_done <= 0;
end
else if(cnt>9'd455)
cnt <= 0;

else if(buff_tx_rdy)
begin
if(rdy != 0)
begin
ber <= ctrl_bep + ber;

2.4 Synthesis and Scan-Stitching:


After scan synthesis had been done from the synthesis guy, DFT Engineer has to ensure that all
DFT constraints have been correctly defined and scan chain specification must be previewed to
ensure that DFT scan chain architecture is balanced for the design itself before doing the
implementation of scan chain stitching of all scan flops. After all DFT violation had been
observed and repaired, the scan chain architecture had to be previewed first before the scan chain
is been stitched for the whole design. If the fault coverage target is not achieved yet, all DFT
violation must be analyzed using ATPG tool to improve the RTL code. Timing optimization

SNUG Singapore 2008 11 Strategy to Achieve High Test Coverage for SOC
during scan-stitching is disabled as timing optimization will be primarily handled by synthesis
team.

2.4.1 Scan Chain Architecture


From the design architecture we have to determine the DFT architecture. Scan chain Architecture
of the WIRELESS IC DESIGN design is as below:
a) Sequential Element Count: 84333
b) Scan Chain Count: 64
c) Longest Path of scan chain: 1316
d) Memory Scan Depth (tester reference) = 3.6 M clock cycle
e) Scan In Port Number: 64
f) Scan Out Port Number 64

2.4.2 Scan Testing Clock


WIRELESS IC DESIGN design has few clocks; CLKIN as a system clock, BB_CLKR as RF
baseband Receiver clock, BB_MCKO as RF baseband Transmitter clock, TEST_CLK0 as clock
in debug mode, and TEST_CLK1 is a clock in bypass mode. All the internal clock and the
distributed PLL clock had been bypassed using one single clock domain as shown in Figure 6.
The test clock for manufacturing test is using clock domain, CLKIN. Test clock configuration is
as below:
Clock period: 100ns
Clock Edge Rise: 45 ns
Clock Edge Fall: 55 ns

2.4.3 Control Signal during Scan Testing


Control Signal that has to be controlled during manufacturing test is stated as below.
1) SE – Set 0 (Capturing Mode) and Set 1 ( Shifting Mode )
2) MODE[2] – Must be always set to 0
3) MODE[1] – Must be always set to 1
4) MODE[0] – Must be always set to 0
5) POR – Assertion and de-assertion is depend on the cycle of scan capturing and scan shifting

Figure 5: Test Mode Selection Module

SNUG Singapore 2008 12 Strategy to Achieve High Test Coverage for SOC
IO Pads
BSR cells BSR cells IO Pads
Pad 1 sub_top_gprs (core design)
0
EM_D[0] 1 Pad 129
EM_A[0]
test_si1
test_mode

test_so1

Pad 130
0
Scan input port sharing Scan Chain 1 io_em_a_pad_0 1
EM_A[1]

with functional input port


test_so2

io_em_a_pad_1
Example of clock
sub_clkin
bypassing

Clock distributions
CLKIN
Module from PLL
PLL

0
1

io_bb_txst
test mode
test_si64 0
test_so64
1

io_i2c_sda
sub_clkin Scan Chain n

BSR cells Scan output port sharing


with functional output
Pad 128 port Pad 256
I2c_SDA
BB_TXST

Figure 6: Scan Chain Architecture


2.4.4 Hookup Test Port:
As the chip is has limited additional I/O port, all the scan chain port is shared with the functional
port. Scan In port is shared with the bidirectional pad, where during scan testing this pad is
always functioning as the input pad. Scan Out Port is sharing with the output port controlled by
test mode signal. It is briefly stated how the control signal drive the function of shifting test
pattern, capturing the test pattern from the combinational logic to the register and observed the
value at primary output in scan testing.

In this project, hookup test port at the top level will be done manually on RTL as the limited
option in DFT tool which only allow Scan Enable(SE) signal to control the IO pads instead of
using test mode pin. While BSR cell is been inserted at top level RTL, all this port must be set as
a linkage port:

SNUG Singapore 2008 13 Strategy to Achieve High Test Coverage for SOC
set_bsd_linkage_port -port_list {MODE[2] MODE[1] MODE[0] CLKIN SE RFMD_CLKR
EM_DCLK_IN TESTCLK0 TESTCLK1}

SE pin is having maximum fanout from the top level to the all connection of the scan flops, the
timing constraint for SE pin is a most critical part to STA team to ensure the timing performance
is meet between the tester and the chip. Therefore to avoid possibility of the timing issue between
the ATE and SE signal of the chip, it was decided to choose the test mode pin to control IO pads
for scan testing. After the hookup test port is done, the scan stitching netlist of core design will
be compiled together in DC, to have a complete full scan netlist and SPF generated file.

2.4.5 Latch Clock Gating

In synthesis works, the synthesis guy is also optimizing the power performance of the chip itself.
In improving the power performance in term of saving power for the remaining inactive
switching work of the circuit, the clock gating cell should be inserted while running synthesis.
Latch is a non scan flop and it will disturbed the controllable and observable of the test pattern
propagating between the scan flops, there is a way to handle the violation to improve the test
coverage. The few options are already served mainly for DFT purpose by Power Compiler tool.
The option we used is to put the control signal before Scan Enable pin to get higher test
coverage. The details explanation can be referred to the reference [11]. It was stated that the fault
coverage using Scan Enable signal before the latch is given higher fault coverage.

Power Optimizing Scripts:

set_clock_gating_style -sequential_cell latch -control_point before \

-control_signal scan_enable -max_fanout 16 -minimum_bitwidth 8 \ # Coloured Red is for

-negative_edge_logic {integrated} -positive_edge_logic {integrated} \ # DFT Purpose

insert_clock_gating

propagate_constraints -gate_clock

hookup_testports -verbose

Figure 7: Latch Clock Gating for DFT

SNUG Singapore 2008 14 Strategy to Achieve High Test Coverage for SOC
2.5 Handling Hard Macro: ARM7TDMI and Memories
For the memories, the testing for manufacturing defect is used built in self test (BIST) method
where the test mechanism and test algorithm is separate mode with testing mode. As the
memories is a hard macro all the memories will isolated from the testing. This bypassing work is
done manually coded at RTL coding stage.

Figure 8: Memory Bypassed Using scan_mode signal

As ARM7TDMI is a hard macro and do not have a scan chain stitched in its core, in scan testing
mode this ARM macro had been bypassed. Some of the combinational logic surround the ARM
will not be tested but it is not effected the fault coverage for the whole design as the nodes point
is too little compared to overall total fault.

3.0 ATPG Run and Fault Simulation:


Final stage is to generate the test pattern with Tetramax and VCS and doing all scan simulation
using VCS. DFT performance and its functionality in internal scan will be put into TETRAMAX
tool to recheck the validity of DFT constraints, to analyze DFT violation, performing all
algorithms of ATPG mode in generating test pattern, and review all report related. In case if the
test coverage is low, the DFT Engineer should review all the fault coverage performance for each
block for both Stuck At-0 and Stuck-At-1. The simulation works will be discussed detail in 3.2
section.

3.1 Increasing Test Coverage With Data Analysis

Analysis of violations is effectively done using the advanced features of ATPG tools. Using GUI
schematic and also extensive reports, we can get the information of all criteria of fault
propagating in the design. All ATPG untestable paths for STA1 or STA0 can be used as a
reference to investigate the root cause of low test coverage for overall design.

The graph is obtained by choosing the module that presented the fault number bigger than 20k
faults in design. From this result, the module that has a significant low fault coverage and bigger
fault number is USB module. In the graph, turquoise colored bar shows that fault coverage for

SNUG Singapore 2008 15 Strategy to Achieve High Test Coverage for SOC
USB block is only achieved 49.3% fault coverage. But compared to the result from USB module
itself it has test coverage of 98.99%, after the scan path integrated to the top level test coverage
drops by more than 50%. Due to increase the fault coverage for overall design, the analysis on
the uncontrollable and unobservable point must be done.

Figure 9: Fault Number vs Test Coverage

Figure 10: Graph Test Coverage vs Module Name

SNUG Singapore 2008 16 Strategy to Achieve High Test Coverage for SOC
3.2 Blockage Tracking and Debugging

Figure 11: Blocking Path between USB and Synchronous Reset Synchronizer Module

As the violation is not occurs from the module itself, the integration path for each clocks,
asynchronous reset and synchronous reset reviewed from path to path. From the Figure 11, it s
traced that blockage is happen between reset synchronize block to reset synchronous signal from
external patterns. Blockage means the pattern that enable to detect Stuck-AT-1 and Stuck-AT-0
for the USB logics cannot be controlled where the combinational APTG cannot propagate from
the primary input to check the defect point.

To fix the issue, the synchronous reset itself need to be connected from any nearer input pin
while scan testing. Therefore all the test patterns that to detect fault can be controlled easily and
the fault can be observed savely. As the RTL is been freeze this time, the new connection is done
into the verilog netlist shown in the box bellow.

New connection to improve test coverage:

mux_3 mux5 ( .a(usb_vp), .b(pll_reset_out_tmp), .sel(scanmode), .c( pll_reset_out) );


mux_2 mux6 ( .a(usb_vp), .b(rst_dev_out_tmp), .sel(scanmode), .c(rst_dev_out) );
mux_1 mux7 ( .a(usb_vp), .b(hreset_out_tmp), .sel(scanmode), .c(hreset_out) );
mux_0 mux8 ( .a(usb_vp), .b(hreset_n_out_tmp), .sel(scanmode), .c( hreset_n_out) );

SNUG Singapore 2008 17 Strategy to Achieve High Test Coverage for SOC
Figure 12: Blockage path before fixed

Figure 13: Blockage Path is Removed

Figure 14: Fault Number vs Test Coverage

SNUG Singapore 2008 18 Strategy to Achieve High Test Coverage for SOC
Figure 15: Test Coverage vs Module Name

The test coverage for the whole core design is finally achieved up to 97.19%. This result is
achieved for the basic ATPG run as shown in the Figure 14 and Figure 15.

3.3 Fault Simulation with VCS Simulator

After fixed all violation at basic scan atpg, scan simulation need to be done for chain simulation.
After it passed, the simulation will be run at parallel simulation and random pattern on serial
simulation.The flow of the fault simulation and ATPG test generation is shown from the Figure
16. After doing test case simulations and debugging the final settings for the ATPG to is as
below:

set drc -noshadows -allow_unstable_set_resets


run_drc /project/Wireless_IC_Design/asic/ATPG/work/spf/top_core.spf
DRC -force

add capture mask <list of violation register: C2, C8, C26>


run drc

add nofaults top_Wireless_IC_Design_BSR_top_inst -Stuck 01


add nofaults top_Wireless_IC_Design_DW_tap_inst -Stuck 01
add_faults -all

set_atpg -capture_cycles 0 -abort_limit 100


set_atpg -resim_basic_scan_pattern mask
run_atpg -auto

set_atpg -capture_cycles 4
set_atpg -abort_limit 100
set_atpg -resim_basic_scan_pattern mask

SNUG Singapore 2008 19 Strategy to Achieve High Test Coverage for SOC
run_atpg fast_sequential_only -auto

analyze_faults -class au
analyze_faults -class ud
report summaries sequential_depths

set_atpg -capture_cycles 6
set_atpg -abort_limit 100
set_atpg -resim_basic_scan_pattern mask
run_atpg fast_sequential_only -auto
report summaries sequential_depths

analyze_faults -class au
analyze_faults -class ud

set_atpg -capture_cycles 8
set_atpg -abort_limit 100
set_atpg -resim_basic_scan_pattern mask
run_atpg fast_sequential_only -auto
report summaries sequential_depths

Final Result:
No DFT Performance DFT Synopsys Tool
CPU Time (s) 21932.89
Test Coverage 98.22%
Fault Number 2865620

SNUG Singapore 2008 20 Strategy to Achieve High Test Coverage for SOC
Basic ATPG Run for
Chain Test Pattern

Chain SImulation

Fail
Result

Pass

Basic ATPG Run for


Serial and Parallel Test

Parallel SImulation

Fail
Result

Pass

Serial Simulation for


Random test pattern

Fail
Result

Pass

Run Fast Sequential ATPG and Full


Sequential ATPG

Fail

Result

Pass

End

Figure 16: Recommended Scan Simulation Flow

SNUG Singapore 2008 21 Strategy to Achieve High Test Coverage for SOC
3.4 Failure Simulation and Debugging

The parallel simulation result had shown below indicated that the chain-9, chain-25 and chain-35
is having a failure while capturing the data at the scan output port.

Few segment of the failure report:


// *** ERROR during scan pattern 257 (detected during load of pattern 258), T= 129200.00 ns
257 chain9 784 (exp=0, got=1) // pin EM_A[8], scan cell 784
257 chain9 785 (exp=0, got=1) // pin EM_A[8], scan cell 785
257 chain9 791 (exp=0, got=1) // pin EM_A[8], scan cell 791

// *** ERROR during scan pattern 3364 (detected during final pattern unload), T= 1693300.00 ns
3364 chain9 1017 (exp=0, got=x) // pin EM_A[8], scan cell 1017
3364 chain9 1035 (exp=0, got=x) // pin EM_A[8], scan cell 1035
3364 chain9 1053 (exp=0, got=x) // pin EM_A[8], scan cell 1053

// *** ERROR during scan pattern 3364 (detected during final pattern unload), T= 1693300.00 ns
3364 chain25 82 (exp=0, got=x) // pin EM_WP[0], scan cell 82

// *** ERROR during scan pattern 3364 (detected during final pattern unload), T= 1693300.00 ns
3364 chain35 953 (exp=1, got=x) // pin EM_WE[1], scan cell 953
3364 chain35 954 (exp=1, got=x) // pin EM_WE[1], scan cell 954
// 1693400.00 ns : Simulation of 3365 patterns completed with 6 errors

Failure is detected –expected value


is one but got 0 at EM_A[7]
Figure 17: Data Shifting Failure

Waveform shows the failure detected at EM_A[7], scan output port as it was expected to get 1,
but got 0. The assumption can be make is the failure could be timing problem. As per assumption
there was few test cases had been done, chain simulation, parallel simulation and serial
simulations. But after run serial simulation on respected chain, the simulation is passed.

SNUG Singapore 2008 22 Strategy to Achieve High Test Coverage for SOC
But one of the test case that detected on the simulation is fail with timing is running simulation
for both test pattern 257 and test pattern 258. The failure is because the hold timing between the
few register while shifting mode happen. It can be look at waveform below.

It was determined that there is hold violation


between this two registers

Figure 18: Hold Violation Causing the Failure

STA reports are rechecked and it was detected that the path is unconstraint and it had been traced
that the constraint for one of distribution clock had not been defined.

from u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/cdis_trig1/iq_ts_reg_2_ (SDFFRX2)


to u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/cdis_trig1/prev_tx_st_reg (SDFFRXL)

pt_shell> report_timing -delay min -to u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/main1/adjust_tb_reg_0_/SI

Startpoint: u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/cdis_trig1/wr_iq_reg
(rising edge-triggered flip-flop)
Endpoint: u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/main1/adjust_tb_reg_0_
(rising edge-triggered flip-flop clocked by clkin)
Path Group: (none)
Path Type: min

Point Incr Path


------------------------------------------------------------------------------
/u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/cdis_trig1/wr_iq_reg/CK (SDFFRX1)
0.000 0.000 r
/u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/cdis_trig1/wr_iq_reg/Q (SDFFRX1)
0.483 & 0.483 f
/u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/cdis_trig1/wr_iq (sr_trigger)
0.000 & 0.483 f
/u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/main1/test_si (sr_main)
0.000 & 0.483 f
u_Apiu_baseband/u_apiu_l1c/l1c_top/sltrate/main1/adjust_tb_reg_0_/SI (SDFFRXL)
0.004 & 0.487 f
data arrival time 0.487
------------------------------------------------------------------------------
(Path is unconstrained)

Incorrect setting
set_case_analysis 1 u_sub_top_Wireless_IC_Design/u_comb_logic/clkmux2/S0
set_case_analysis 0 u_sub_top_Wireless_IC_Design/u_comb_logic/clkmux1/S0

Correct Setting:
set_case_analysis 0 u_sub_top_Wireless_IC_Design/u_comb_logic/clkmux2/S0
set_case_analysis 1 u_sub_top_Wireless_IC_Design/u_comb_logic/clkmux1/S0

SNUG Singapore 2008 23 Strategy to Achieve High Test Coverage for SOC
After the STA team put the correct DFT constraints and closed timing, the simulation with
timing fixed netlist is passing simulations. After fixing timing for the test mode, the simulation is
passing. Scan simulation for all test vectors have been done using two different format of test
program, verilog format and STIL format. The results are tabled as below:

Scenario 1: Timing in test mode is clean but timing in functional mode not clean

Verilog Simulation Result STIL Simulation Result


Parallel Simulation 6 Failure Parallel Simulation 1 Failure
Chain Simulation Passed Chain Simulation Passed
Random Serial Random Serial
Simulation Passed Simulation Passed
Table 1: Simulation Result Case I

Scenario 2: Both timing performance of the functional mode and test mode is clean

Verilog Simulation Result STIL Simulation Result


Parallel Simulation 1 Failure Parallel Simulation Passed
Chain Simulation Passed Chain Simulation Passed
Random Serial Random Serial
Simulation Passed Simulation Passed
Table 2: Simulation Result Case II

After the STA team closed the timing clean for both of functional mode and testing mode, the
scan simulation passed for all type of scan simulation using STIL test program but using verilog
simulation there is still 1 failure. From the scenarios, STIL simulation is performed better
compared to verilog simulation.

4.0 Discussion and Conclusion


4.1 Discussion
Based on the test cases discussed and the flow that have been recommended in this paper, it is
emphasized that;
o It is possible to get high test coverage for the design if the DFT rules and guidelines are
followed and adhered right from the start of the design flow.
o EDA tool does a good job only if the design is DFT compliant. Else unnecessary
iterations occur in the design cycle.
o During RTL freeze, list of registers to be avoided from scan chain should also be
identified and included in the DFT constraints.
o Some capture violations which results in mild drop of fault coverage can be masked
successfully during test pattern generation. The decision to fix the violation or to mask
the fault sites needs to be reviewed.
o For some work like hook-up testing port from pad level to the core level is better done at
RTL level as there are limitations in tool usage for these features.

SNUG Singapore 2008 24 Strategy to Achieve High Test Coverage for SOC
o From the Table 1 and Table 2, it is also recommended to do the scan simulation based on
the STIL protocol is using STIL test pattern. it is also directly supported by the fab ATE
where the same STIL database could be simulated and run in the ATE. This saves disk
space, and validates the actual pattern set and not a "branch" in the flow of data to a
Verilog pattern database that only had value for simulation [5].
o It is undeniable that the scan testing is only use low-speed test (10 MHz) rather than high-
speed functional clock (WIRELESS_IC_DESIGN 52 MHz). Transition faults may not be
covered but it is more applicable for deep submicron technology. For the target 0.18u
technology, stuck-at fault model coverage suffices the required fault coverage
requirements.

Further Discussion:

The quality of the overall performance of the test coverage based on the cost of the
manufacturing defect and other issues faced during post-silicon test pattern debugging are not
covered in this paper. It will be discussed further in the future paper.

4.2 Conclusion
This paper had discussed the flow and the methodology work to get high test coverage and how it
is implemented in Wireless IC Labs project. The high test coverage is finally obtained for this
design is 98% test coverage. Some issues had also had been shown and the solution to solve the
problem had also been discussed.

5.0 Acknowledgement
The appreciation goes to those involved in this project and gave full cooperation in achieving
good result. Acknowledgements to Suhaimi Bahisham, Muhammad Khairol, Roslee, Mohamed
Farid, Noraini, Zubir, Sridar, Sivaprasad Embanath, Norliza Jalani and Nazaliza Othman.

6.0 References
1. Tracy Larrabee, Member, IEEE, Test Pattern Generation Using Boolean
Satisfiability, IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. 11,
NO. 1, JANUARY 1992
2. DFT Compiler DFT Architecture User Guide (DB Mode) ,Version X-2005.09, September
2005
3. DFT Compiler User Guide Vol. 1: Scan (XG Mode) Version Y-2006.06, June 2006
4. TetraMAX® ATPG User Guide Version Y-2006.06, June 2006
5. Test Pattern Validation User Guide Version Y-2006.06, June 2006
6. Kyeongsoon Cho, Randal E. Bryant, Carnegie Mellon University
Test Pattern Generation For Sequential MOS Circuit by Symbolic Simulation
7. Sukalyan Mukherjee, Design for Testability to Achieve High Test Coverage- A
Case Study, Wipro Ltd.

SNUG Singapore 2008 25 Strategy to Achieve High Test Coverage for SOC
8. Yinghua Min and Zhongcheng Li, Evaluation of Test Generation Algorithms
Center for Fault-Tolerant Computing, CAD Lab. Institute of Computing
Technology, Academia Sinica Beij ing, China
9. Wang Wu Wen,2006 VLSI Test Principle and Architecture, Elsevier Inc
10. J. Bhasker , Verilog HDL Synthesis
11. Power Compiler" User Guide Version Y-2006.06, June 2006, Chapter 12

SNUG Singapore 2008 26 Strategy to Achieve High Test Coverage for SOC

View publication stats

You might also like