Hierarchical DFT with Enhancements for AC Scan, Test Scheduling

and On-chip Compression – A Case Study

Jeffrey Remmers Darin Lee Richard Fisette

Plexus Design Plexus Design Mentor Graphics Corp.
Solutions, Inc. Solutions, Inc. 1601 Trapelo Rd.
325-1 Boston Post Rd. 325-1 Boston Post Rd. Waltham, MA 02514
Sudbury, MA 01776 Sudbury, MA 01776

Abstract
The DFT architecture, pattern generation and
application, and economic issues encountered in large
ASIC designs are increased when at-speed testing is
introduced. This case study shows enhancements over
the current state of the art hierarchical methodology
by improving transition testing, test scheduling, and
using compression on a production design.
1.0 Introduction
System-on-Chip (SoC) design focusing on the
integration of IP Cores is now a mainstream
technology and is becoming quite mature in
application. Because of the core based nature in the
design of SoC devices, the hierarchical methodology
employed for DFT makes use of the natural
partitioning and follows the same core-based flow.
DFT and test architectures can be segmented and
related to the different hierarchical logic groupings.
However, due to the increasing size of modern designs
plus the inclusion of AC scan tests used to detect the
more prevalent speed related defects, the pattern
counts are growing at a higher rate than economics
and tester memory can match.
The key technologies investigated with this case study
design were exactly the management of vector sizing
by both hierarchical partitioning and the use of
embedded on-chip compression; the inclusion of an
enhanced set of AC transition delay vectors; and an
evaluation of the methodology needed to allow post-
design test scheduling.
The design that is the focus of the case study was a
large SoC, with multiple instances of one core. The
end customer had very high quality requirements.
Because it included the detection of speed-related
defects, AC scan type testing using transition delay
(TDF) was added to traditional single stuck-at fault
(SSF) testing. The AC scan methodology that was
applied was enhanced from previously implemented
1
techniques to include TDF coverage at the boundaries
of the cores.
The addition of TDF vectors resulted in a larger vector
volume that would not fit on the target tester. To this
end, vector compression DFT was added to the chip to
reduce the memory requirements for the target tester.
The most efficient method of adding compression
DFT, at design time, was to implement it at the
individual core level and to then integrate it at the top-
level.
Once the DFT was in place, there were concerns about
both test application time and test power consumption.
DFT techniques to allow the testing of multiple cores
at once were included to reduce test time. However, to
provide a level of guarantee against power problems at
test, enhancements were added that allow flexibility in
choosing which cores and how many to test
simultaneously. This design methodology is currently
being employed in multiple designs, across multiple
sites.
This paper is organized as follows: section 2 presents
the motivation for the work; section 3 presents the
details and requirements of the design; section 4
covers the pattern-sizing estimate that drove the DFT
design; section 5 presents the core-level DFT; section
6 details the top-level DFT; section 7 briefly outlines
the role of 1149.1 in the on-chip DFT; section 8
presents the specifics of TDF testing; section 9
discusses the role of the clock-chopping PLL; section
10 reviews some of the challenges encountered in the
case study design; section 11 concludes the paper; and
finally section 12 outlines future work to be
considered.
2.0 Motivation
In this case study design, the size of the device posed a
problem with high pattern count. Even considering
the inherent compression benefits found in the
hierarchical methodology, the introduction of
transition fault patterns caused the total tester memory
requirements to exceed tester limitations. The target

Paper 29.3 INTERNATIONAL TEST CONFERENCE 1

0-7803-9039-3/$20.00 © 2005 IEEE
tester was an Agilent 93K configured with 28M of
vector memory (per pin). Since the decisions on the
DFT methodology needed to be made early in the
process, an estimate was made for the total pattern
count based on previous design experiences – this
estimate will be explained further in the paper.
3.0 Case Study Design
The focus of this case study is on the multi-phase scan
1
methodology developed by Plexus Design Solutions,
Inc., which was implemented during the design of the
Cobra chip. The Cobra design (Figure 1) is a 13.5M
gate, 0.13µ TSMC process, having embedded-core
frequencies of 133 MHz and 233 MHz. Our customer
recognized the importance of DFT and has made a
significant effort to achieve the highest possible test
quality. There are a number of DFT features designed
into the Cobra chip, such as Full Scan, Boundary
Scan, Memory BIST (both with and w/o repair), and
some Functional Test.
Figure 1 - Case Study Design
The following is a list of the DFT features and
requirements for Cobra:
• Full scan - Cobra is a nearly “full scan” design using
Mux-D flops. With the exception of a small number
of registers in the clock control logic, all of the 350K
flops were scanned.
• Stuck-at - The target coverage for stuck-at faults was
99.6+%.
Paper 29.3 INTERNATIONAL TEST CONFERENCE
• Transition Faults- Because 0.13µ processes have
exhibited an increased number of at-speed related
defects, it was deemed necessary to target transition
faults. While the core is running at frequencies of
130 to 240 MHz, and is achievable by available
testers, at-speed clocks were generated using the on-
chip PLL. This was done to prove the concept for
future planned designs that will require frequencies
beyond the tester’s capability. It also provides a
capability to target lower cost testers if desired. The
goal for transition coverage is >80%, as reported by
the tools.
• Compression will be used at the core level for both
TDF and SSF patterns.
• Path Delay – Path delay tests are defined for the
device as determined by Static Timing tools. The
number of paths is initially limited to 100 per core.
• Boundary Scan - Cobra has Boundary Scan on all of
the I/Os except for the tri-state enable pin. That pin is
used to isolate the device in board and MCM
assembly.
• Memory BIST - Memory BIST was used on all the
Artisan memories. Soft repair is implemented on
selected, larger memories and will be executed at
power-up of the device.
4.0 Vector Sizing Estimation
The DFT architecture had to be developed prior to the
generation and understanding of vectors, and there was
a very real concern that the vectors would exceed the
capabilities of the target tester. The design, at the
planning stage, consisted of a DSP core that was
replicated eight times, plus some interface logic and
other computation blocks. An estimation of vector
impact was possible, because a previous generation of
the product family included a similar architecture. To
more accurately estimate the pattern count and the
required tester memory, some experiments were run
on the previous generation core (DSP1).
Again, this case study design was targeted to 0.13µ
technology and therefore, required both SSF patterns
and TDF tests. So, the tests for this generation would
be significantly larger than those from previous
designs.
The first step was to run a baseline ATPG for SSF
(Single Stuck-at Fault), which established the final
SSF coverage goal (Table 1).
DSP 1
SSF Baseline
Scan Chain Number of Test Pattern Test Vector
Length Chains Coverage Count Memory*
1000 28 99.35% 1320 ̃1.3M per pin
*Test Vector Memory = Longest Chain x Pattern Count
Table 1
2

The second step was to create transition-delay patterns
against DSP1. In addition, those patterns were then
fault graded for SSF coverage, and an ATPG (SSF)
top-off was run to achieve the final coverage, as
determined in the baseline run (Table 1).
In other words, by understanding the SSF content of
the transition delay vectors, it was possible to replace
the majority of the stuck-at vectors with the transition-
delay vectors. The total pattern set is a combination of
TDF patterns plus SSF top off vectors (Table 2).
DSP1
AC Scan plus SSF top off
Transition Transition SSF Top Off SSF
Patterns Coverage Patterns Coverage
3780 98.35% 24 99.35%
*Test Vector Memory = Longest Chain x Pattern Count
Table 2
Taking the data from the work done on the previous
generation core, we determined a scaling factor for the
full chip pattern count, based on the DSP1 tests. In
that previous design, the scaling factor was 2.73x. In
other words, when the DSP1 was integrated into the
top level design, it required 2.73 times the number of
patterns that were used to test it without integration
into the total chip. This was due to the fact that all
primary pins of the DSP1 core were not visible at the
chip level. To deliver patterns to the core, it required
traversing through some top level logic.
Using this scaling factor on the transition-delay plus
top-up SSF patterns (3804 patterns x 2.73 = 10,385),
resulted in the estimated chip level patterns. In that
previous generation chip, the eight core level chains
were concatenated (8 scan architectures at 1000 bits of
depth), so the total memory in the tester for that
architecture would have been 10,385 x 8000 = 83M of
vectors per pin.
Adopting the Hierarchical DFT Methodology , and
using a single phase per core, the vector memory
would be reduced to (number of cores) x (pattern
count) x (length of longest chain). The plan was to
have 10 cores in the device, with a chain length of
1000 registers. With 3804 patterns per core, this was
approximately 38M per pin. It is a significant savings
over the historical methodology, but still exceeded the
per pin memory of the tester.
The next option was to use compression technology on
the cores for pattern count reduction. Using the
Hierarchical DFT Methodology with compression in
the cores was the option under consideration.
The hierarchical DFT methodology used in previous
designs provided benefits of faster runtime, no tool or
machine capacity problems, early detection of
testability issues, simplified verification, isolation of
potential problem blocks, a universally applicable
methodology for managing scan chains at the chip
level, and simplified debug of scan chain failures on
Paper 29.3 INTERNATIONAL TEST CONFERENCE
1
the tester . In addition, this methodology allowed us
to efficiently use tester memory, which was planned
early in the process. Because the design is partitioned
along functional boundaries, scan planning is done to
balance the test patterns from each block. The number
of chains (channels for the compression flow), the
depth of the chains and rough pattern counts are
determined early in the flow.
When compression was introduced in the DSP1 core,
it was configured to have 280 internal chains of length
100. Twelve external channels were brought out from
the core. Running patterns with the same flow
Test Vector
Memory* (transition, Fault sim, top off), the total test vector
3.8M per pin memory was reduced to 600K per pin. Multiple
schemes for bringing out the core level channels to the
chip level could be used.
1
In the existing Hierarchical DFT Methodology , multi-
phase scan chain muxing was used. With that flow,
the chains from the cores are fed into muxes in the top
level. Based on scheduling plans and pin availability,
those past flows used a single core per phase.
Using that same single phase per core approach, the
total memory was approximately (10 cores) *
(600K/core) = 6M per pin. This was well within the
limitations.
In the first core implementation, a number other than
12 channels was chosen due to constraints in one of
the first chip designs. In that first tape-out, which
used the DSP core, only sixteen pins were allocated
for scan in/scan out channels. However, the analysis
performed for the selection of the ‘Hierarchical DFT
with compression’ flow was still valid.
The production design studied here was comprised of
eight DSP cores (Hard Macro), some computational
1
blocks, interface sub-blocks and other glue logic. The
DSP core was hardened and reused in multiple designs
across multiple design sites, so the methodology
required the block to have DFT that was easily ported
and integrated.
Due to the high level of ac testing and the subsequent
increase in overall pattern count, the methodology
chosen was enhanced to include compression
technology from a commercial EDA supplier. In this
case study, Mentor Graphics’ TestKompress was used.
5.0 Core
The hierarchical methodology follows a similar flow
1
used in previous designs . In this design, compression
was added at the core level to reduce the size of the
patterns stored on the tester. Using the terminology of
the EDA tool, the channels were defined as the input
connections to the decompressor and the output
connections from the compactor (Figure 2).
3
The number of chip level pins available for scan
determined the channels defined in each block. Since
the DSP (Hard Macro) core will be used in designs
across many design groups, the first two “customers”
to use the core determined the number of channels. In
this case study design, eight scan in and eight scan out
pins were defined. The channel to chain ratio was
determined by the target compression combined with a
target chain length. From an overall planning point of
view, the chain lengths in each core were defined to be
approximately equal, with a range of 150 to 200
registers deep. The compression logic was added at
the block level and then the reduced number of
channels was fed to the top and multiplexed out to the
pins of the device through the multi-phase scan muxes
(Figure 1).
Figure 2 – Channels in and out of the core
One key element in the use of a hierarchical
methodology is the registration of Inputs and Outputs
(I/Os) in the top level blocks of the chip. In many
designs, the ports are registered to have accurately
characterized blocks (for reuse). Registration is also
used to minimize the constraints on global routing.
Since the core performance is characterized at the
block level, it is not dependant on asynchronous
timing from other blocks. This reduces the timing
constraints on those inter-block routes. In this
hierarchical methodology, the DFT flow takes
advantage of those registers to isolate the blocks. This
isolation provides the ability to generate patterns for
the block that are independent of the logic in other
blocks within the design. In the design used with this
case study, one major core, the DSP, did not register
all I/Os. This posed a challenge for the methodology
requiring special handling for those unregistered ports.
Paper 29.3 INTERNATIONAL TEST CONFERENCE
While the design team initially committed to register
the ports in the cores, when the DSP was first checked
(early synthesized netlist), there were many ports
without registration. One solution was to add registers
to all ports, combined with muxes to achieve the
isolation required. However, this was not deemed
possible due to the latency introduced in the system.
An alternate solution for registering the ports to the
core was to use DFT tools to identify registers within
the design. Using this technique, the tools traced
through the inputs to the block through the
combinational logic until the first level of registration
was identified (Figure 3). However, in many cases,
this resulted in an identification of multiple registers
per input port, which caused two issues to arise. First,
the number of registers identified for the partition
chain increased significantly. In the case study design,
it caused the length of the partition chain to be 6318
(number of identified partition registers) instead of
848 (number of ports into the block).
Figure 3 – Ports fan out to multiple Input Partition Registers
Secondly, in some cases, the combinational logic had
feedbacks to input partition registers from logic
internal to the core (within the partition registers,
Figure 4). This caused a problem in testing the final
phase, or the top level logic. In the testing of the top
level logic, all partition scan chains were placed in
scan mode. Patterns were fed into those registers
while the cores (inside the partition chains) were in
“don’t care” states. However, when there was
feedback from an internal node back to the input of a
partition scan chain, it caused an unknown to be
present on the partition register. This caused a loss of
test coverage at that register and the cones of logic fed
by that register.
4
 not employed in testing the top level logic (final phase
in the multi-phase muxing).
The other major enhancement made in this chip level
testing was the ability to test multiple cores
simultaneously (selectable through JTAG). This
resulted in the minimization of the overall test time, by
exercising multiple cores at once. With a selectable
option, it can be tuned to ensure that the maximum
power dissipation of the package-die combination is
not exceeded (testing all cores at once could exceed
Figure 4 – Feedback to Partition Register from Internal Cells the power capabilities). Table 3 describes how the
The solution to this problem required the insertion of a muxes are controlled in each phase.
small number of test points (Figure 5) to control those Pttn Phase
Mux1 Mux2 Mux3 Mux4
HM0 HM4 RX HM1 HM5 TX HM2 HM6 CT Top HM3 HM7 SA Top
feedback loops for use in the final phase of testing (top Top Top

level logic testing). P0

P1
0
1
1
1
1
1
1
1
1
1
P2 2 1 1 1 1

P3 3 1 1 1 1
P4 4 1
P5 5 1
P6 6 1
P7 7 1
P8 8 1
P9 9 1
P10 10 1
P11 11 1
P12 12 1
P13 13 1
P14 14 1
P15 15 1

Note: HM – HardMacro, SA – Sand, CT - CompoundTop, Top

– Top Level
Table 3: Phase Test

• Phase 0 - four HardMacro cores are tested in parallel.

Figure 5 – Test Points Added for Observation • Phase 1 - four other HardMacro cores are tested in
parallel.

6.0 Chip Level
In the chip level testing, the strategy of using multi-
1
phase muxes was used . In multi-phase muxing, the
scan in and scan out from multiple cores were
multiplexed into and out of the chip. Using this
technique, multiple cores can use the same few I/O
pins available for use in test. In previous designs, the
selection of cores under test was controlled through
primary inputs to the chip.
This methodology was enhanced by using JTAG
instructions to control the selection of the blocks under
test. Using JTAG for control reduced the number of
dedicated package pins required for test. It does add a
level of complexity in the application of test patterns
to the device, but this is essentially a test procedure
that is setup and automated in the EDA tools.
During the chip level test, each of the cores was tested
independently in each phase. The final phase focused
on testing the top level logic, which is outside of the
defined cores. In this case study design, compression
technology was used in all the major blocks but was
• Phase 2 - the RX/TX cores, the Sand and
CompoundTop cores are tested in parallel.
• Phase 3 - the top level logic with all partition scan
chains from each core are tested at the same time.
• Phases 4 to 15 - each core can be tested individually.
A decision was made to have the default operation test
four cores at once. As the table describes, in Phase 0, four
of the DSP Hard Macros were tested in parallel. Patterns
for Hard Macro 0 are delivered through Mux1. Patterns
for Hard Macro 2 are delivered through Mux2, Mux3
provides patterns to Hard Macro4 and Mux4 supplies
patterns to Hard Macro6.
The one exception to this strategy is the top level testing.
In the final phase, the scan chains from all of the top level
logic is brought out to package pins along with all
partition chains from the cores. This is the technique
which picks up the combinational logic that resides
outside the partition cells in the cores. It also covers the
cones of logic that reside between the registers in the top
level and the ports in the cores. In this final phase, all 32

Paper 29.3 INTERNATIONAL TEST CONFERENCE 5

chains are from either partition chains or scan chains
within the top level logic. This phase is the only one that
does not include compression technology.
To test one core at a time, the target core will have its
channels described to the EDA tool (chain identification,
etc) and patterns will be generated for that core only. As
an added capability, when the device is in “single core
test” mode, the cores not under test will have clocks
disabled and no patterns delivered to them.
The structure that is in place will also allow for testing of
2, 3 or up to 4 cores simultaneously. The only change will
be how those cores are defined to the EDA tool.
To test in the non-default mode, the EDA tools must
create patterns for each different option. This will require
different pattern sets to be generated and delivered to the
operations department if the device needs to be tested in
any mode other than the default.
Following receipt of the device from fabrication, the
initial tests will be run with the default mode. If power
dissipation issues are encountered (IR drop, etc), different
options for the test sequencing will be used.
7.0 JTAG and its Role
The IEEE 1149.1 standard was followed in the case
study design. As well as the standard functionality,
addition capabilities were included employing user
defined instructions.
JTAG’s functionality was used to setup the chip in
different test modes. Below is the list of tasks the
JTAG controller performs.
• JTAG selects the phase scan muxes at the top level to
technique, power will not be consumed in cores not
targeted in the Phase-mux select approach described
in Table 3.
• Sets up pin parametric testing.
• Tests connectivity of the package to the board
(standard implementation).
8.0 Hierarchical Transition Fault Testing
In the case study design, transition fault patterns were
created using launch off capture (as opposed to launch
off last shift). This was selected to reduce the
constraint on the Scan Enable signals. When using
launch off last shift, SE becomes a high speed pin,
requiring it to be routed like a clock, or to use retiming
logic (pipeline registers) for the SE signal. Launch off
capture requires a larger number of patterns, but with
the design using embedded compression technology,
this is not a concern.
Multiple scan_enable's are necessary to implement
more complete transition fault testing in a hierarchical
manner. Also, to support hierarchical transition fault
testing, a lock-up flop positioned at the beginning of
the input partition scan chain and at the beginning of
the output partition chain is included.
To correctly describe the reason, it is first necessary to
review the requirements for detecting a transition
fault. The following figure illustrates how a scan
pattern is used to initialize a transition fault site and
deliver a transition vector.
Transition Origin Launch Flop Capture Flop
V1 R(V1) 1) Last shift loads initialization
D Q V2 D Q D Q vector (V1) into the Launch
FF3 FF1 FF2 Flop. Transition vector (V2)
originates from the flop driving
SI SI SI
the D input of the Launch Flop.

select the core under test according to Table 3. R(V2)

V2 2) With scan shifting turned off
D Q D Q D Q
• It sets up the PLL in the different clock frequencies FF3
SI
FF1
SI
FF2
SI
(SE =0), launch V2 from D input
of FF1.

and controls the clock chopper to test the target core

accordingly, both for transition fault patterns and R(V2)
D Q D Q D Q 3) Capture result of V2 at D input of
single stuck-at patterns. FF3 FF1 FF2 FF2 with a second clock pulse.
SI SI SI

• Instructions schedule the Memory BIST test events

including test and repair (soft) capabilities for some
memories. In the soft repair for the large memories,
JTAG instructions are used. The requirement is to
sequentially run their MBIST and soft repair at power
up. Instructions are used to schedule and execute
these events.
• ‘Simple’ MBIST is initiated through JTAG
instructions. These tests are run in manufacturing test
only.
• It disables the clocks delivered to each core that is not
being tested for power saving purpose. Using this
Figure 6 – At Speed Scan Vectors
As illustrated above, it is necessary to have three
registers to execute an “at-speed” scan vector. When
testing a block in a hierarchical manner, the normal
Transition Origin (another flop in the design) is no
longer present. The following figure illustrates how to
use the existing scan chain to supply the Transition
Origin.

Paper 29.3 INTERNATIONAL TEST CONFERENCE 6

 Launch Flop Capture Flop
1) Last shift loads initialization
9.0 PLL Clock Chopping
V1 R(V1) vector (V1) into the Launch
X D Q D Q Flop. Since The D input of FF1
The clocking used for detection of the speed related
FF1 FF2 is driven by “X” (outside of
Transition Origin SI SI block), the transition vector
defects in the interconnect was based on work
(V2) must originate from the
V2 flop driving the scan input. described by Teresa McLaurin, et al in the ITC2000
D Q
X
FF3 proceedings. Internal clock choppers were used for
SI
each of two clock domains. The basic design included
R(V2)
edge detect logic, for starting the clock sequences;
V2
X D
FF1
Q D
FF2
Q 2) In order to launch V2, scan mask registers, to set the clock positions; a shift stage,
shifting must remain enabled
SI SI (SE=1). to drive the gating logic; and the gating logic, to
X D Q
deliver the clock pulses. The source for the clock
FF3
choppers came from the PLL’s used in each functional
SI
domain. The only change required was an accurate
R(V2)
clock source on the load board of the tester. This
X D
FF1
Q D
FF2
Q
3) Capture result of V2 at D input of reference clock was used by the internal PLL’s for
FF2.
SI SI
locking the frequency.
X D Q REF_CLK
FF3 CLK_1/2
PLL CLOCK CLK_1/4
SI X8 DIVIDERS CLK_1/8

CLK
Figure 7 – Transition Pattern Origin
MASK0[7:0] CLK_EN0 GATED_CLK
The reason for the scan_enable signals and a lock-up MASK
MASK1[7:0]
SHIFT
CLK_EN1 GATED_CLK_1/2
SCAN_CHAIN VALUES STAGE CLOCK
flop is to insure that there is a valid state during the MASK2[7:0]
MASK3[7:0]
CLK_EN2
CLK_EN3
GATING
GATED_CLK_1/4
GATED_CLK_1/8
two clock pulses required for at-speed scan testing. In
LAUNCH_CAPTURE
a hierarchical implementation, it is necessarily
assumed that Xs propagate from outside the block. EDGE
SHIFT_IN_BIT
DETECT LD_SHFT
After loading the scan chain for a transition fault BEGIN_AC &
CTRL
pattern, the scan_enable signal for the partition chains TEST_EN

is held active (shift only) during the launch/capture SCAN_SHIFT_CLK_SEL

pulses to insure that there is a register driving a known SCAN_SHIFT_CLK

state into the partition cell during the second pulse.

When testing the logic inside the targeted block, this Figure 8 – PLL Clock Chopper
strategy is required to handle the input partition cells. 10.0 Challenges Encountered in the Case Study
The output partition cells, however, need to capture Design
data on the D pin, when testing inside the block, which In the course of working on the design, there were a
means their scan_enable signal must be inactive number of issues that were encountered. Some
(shift/capture controlled by the tools). When testing required design modifications; others caused an
outside the block (targeting top level logic and block enhancement to the methodology, and yet others were
interconnects), the roles of the partition cells reverse. addressed with modifications to the EDA tools.
The output partition cells must maintain a valid state
for the second clock pulse (meaning One challenge occurred with the use of the PLL clock
outputreg_scan_en must be held in shift mode), but chopper. In this design, the PLL reference clock was
input partition cells must capture data on the D pin also used as the scan shift clock. This allowed for a
(therefore inputreg_scan_en inactive). Without this single pin as the source of the clock input during test.
technique, transition coverage would be lost at the In SAF and TDF testing, the shift clock was the same
partition chains, both input and output. This could as the reference clock. When the mode was changed
represent a significant loss in total coverage. from shift to capture, the output of the PLL clock
chopper was the source for the capture clocks.
In the case study design, the TDF testing was However, the operation of the EDA tool caused faulty
performed inside the de-compressor/compactor logic. behavior. A report was provided to the customer
The tests were created using a simple switch within support group at the vendor and within days, a patch
the ATPG tools. However, the clocking for the was made available. This capability is now supported
transition delay fault testing was generated on chip in a production release of the EDA tool.
using a PLL Clock Chopping circuit. While the clocks
used in this design are low enough speeds to allow the Another challenge happened with transition delay fault
tester to supply them, the clock chopper provides testing. When transition patterns were created for the
flexibility in the future to test the devices on lower core only, the coverage was on the order of 84%,
cost equipment. which was within our target goal. However, when the
total chip was included, and the test was directed at

Paper 29.3 INTERNATIONAL TEST CONFERENCE 7

that same core, the coverage dropped to 74%. When it
was investigated, the source of the problem was due to
transition patterns that were launched from the input
partition register, traversed through combinational
path and captured into another input partition register.
But, when the core level block was tested, the Scan
Enable for the input partition register was held in
“shift” mode. This prevented the capture of the faults
in the second input partition register.
An enhancement to the methodology was made to
cover the logic that appears between two input
partition registers that are part of a launch-capture
pair. The functional logic resides within the
hierarchical block of logic, but appears between
partition registers, because the target core did not
register inputs to the block. In the process of
identifying and inserting partition registers into
partition chains, there were cases where some logic
was present between two input partition registers.
That logic is not covered in the normal operation of
transition fault pattern generation with this
hierarchical methodology. The solution is to perform
two passes of pattern generation for the target core. In
the first pass, the input scan enable is held to a “1”
(shift). Patterns are generated. In the second pass, the
pin is left unconstrained and allows the tool to control
the shift/capture for the input chain. In that case, those
transition faults that are in the cloud of logic between
input partition registers are covered.
Note that this enhancement is not required when all
inputs to the block are registered.
Another issue is encountered with the enhancement of
testing multiple cores at once. In the motivation for
using the hierarchical methodology, one of the reasons
is to reduce the size of the problem solved by the
ATPG tools. The tools run significantly faster
operating on one core at a time. When four cores are
tested simultaneously, the pattern generation time
grows, the requirements on compute resources
increases, the validation cycle grows (simulation
times), and the debug process for patterns on the tester
is more difficult. However, this enhanced
methodology provides the ability to test the cores
individually. The requirement is to generate new
pattern sets targeted at each core independently. This
is accomplished by loading the fault list for only the
target core and running the ATPG tool against that list.
The downside to this process is the development of
multiple pattern sets for the device.
In the initial bring-up of first silicon, it may be easier
to debug problems by targeting a single core per test
phase. As soon as the devices are successfully tested
(and the load board is verified), a ‘final’ production
pattern set can be generated to minimize the overall
test time by targeting multiple cores per test phase.
Paper 29.3 INTERNATIONAL TEST CONFERENCE
11.0 Conclusion
In this case study design, there were two major goals
that drove the team to use a hierarchical DFT
methodology with ac scan enhancements and on-chip
compression. One was the creation of a core that
would be used across multiple divisions. Another was
to allow for other cores to be delivered by outside
design groups that would be readily integrated into the
total chip.
In addition, other design elements required us to
modify the previous methodology to meet the DFT
needs. With nanometer design (the target technology
was 0.13µ), at-speed testing was required to achieve
the highest quality of test. By adding transition fault
patterns at the target frequencies of the device, the
volume of test data grew too large for the target tester.
As a result, compression was added to the design in
the hierarchical flow.
We also enhanced the methodology to pick up
transition coverage at the boundaries of the blocks,
and to provide some flexibility in the selection of
which cores to test simultaneously. While testing all
cores simultaneously would exceed the power
dissipation capabilities of the device (and potentially
cause IR drop issues), a selectable technique for
testing one or multiple cores at once was used.
The results showed that this enhanced methodology
met the quality goals of our customer while allowing
the tests to run on existing test equipment in a
reasonable amount of time.
12.0 Future work
In follow on designs, more automation of the flow is
planned. Between working with the EDA vendor and
creation of more scripting capabilities, much of the
hand crafting that was required in this case study
design will be improved.
Other future enhancements will involve the capability
to deliver not just the core with scripts, but the core
with a set of test patterns that can be reused in other
devices.
Also we will be adding the capability to have more
selection of cores in testing. In this case study design,
a trade-off was made to hard wire specific
configurations of cores for simultaneous testing.
Future efforts will be made to have more options
available.
Finally we will offer more automation in the handling
of cores that do not have registered I/Os by identifying
the feedback from internal logic into partition scan
registers.
8
Acknowledgements 12. Eric Larsson, Zebo Peng “A Reconfigurable Power-
Conscious Core Wrapper and its Application to SOC Test
Special thanks are in order for Parag Sheth, Tony
Scheduling”, International Test Conference 2003
Kulesa, Ronen Habot, and Minjing Wang from
Conexant Corporation. Martin Buehring from Mentor 13. Sandeep Kumar Goel, Erik Jan Marinissen
Graphics was also a significant contributor to our “Effective and Efficient Test Architecture Design for
success on the project. Al Crouch also helped in the SOCs”, International Test Conference 2002
review and submission of this case study. His
experience and insight were keys in the development 14. Rainer Dorsch, Ramón Huerta Rivera, Hans-Joachim
and delivery of this information. Wunderlich, Martin Fischer “Adapting an SoC to ATE
Concurrent Test Capabilitie”s, International Test
Conference 2002
References
1. Jeffrey Remmers, Rick Fisette, Mauricio Villalba,
“Hierarchical DFT Methodology – A Case Study”,
International Test Conference 2004
2. Alfred L. Crouch, “Design for Test for Digital IC’s
and Embedded Core Systems”.
3. Sengupta, Kundu, Chakravarty, Parvathala,
Galivanche, Kosonocky, Rodgers, Mak, “Defect-Based
Test: A Key Enabler for Successful Migration to
Structural Test”, Intel Technology Journal Q1’99.
4. Ron Press, Janusz Rajski, “Heading off test problems
posed by SoC”, EE Times, October 16, 2000.
5. Hari Balachandran, Kenneth M Butler, Neil
Simpson, “Facilitating Rapid First Silicon Debug”,
International Test Conference 2002.
6. Bailey, Metayer, Svrcek, Tendolkar, Wolf, Fiene,
Alexander, Woltenberg, Raina, “Test Methodology for
Motorola’s High Performance e500 Core Based on
PowerPC Instruction Set Architecture”, International Test
Conference 2002.
7. Wilson, Ron, “DFT Takes on Test Cost in Final
Combat”, Integrated System Design, October 2001
8. Sematech “Overview of Quality and Reliability
Issues in the National Technology Roadmap for
Semiconductors” 98013448A-TR
9. Sabada, Sudhakar “Keynote: Nanometer Design
Challenges” Magma Nanometer Design Seminar October
2002
10. Rick Fisette, Gary Gebenlian, Jeff Remmers
“Efficient DFT Verification Methodology Using Skeleton
Netlist and ATPG tool, a Case Study” International Test
Synthesis Workshop 2003
11. Vikram Iyengar y , Krishnendu Chakrabarty and
Erik Jan Marinissen “Test Wrapper and Test Access
Mechanism Co-Optimization for System-On-Chip”,
International Test Conference 2001

Paper 29.3 INTERNATIONAL TEST CONFERENCE 9