Minimizing Test Time by Exploiting

Parallelism in Macro Test

Hans Bouwmeester Steven Oostdijk Frank Bouwman

Rudi Stans Loek Thijssen* Frans Beenker
Philips Research Laboratories
Electronic Design & Tools
P.O. Box 80.000, 5600 JA Eindhoven, The Netherlands
*Delft University of Technology
Faculty of Electrical Engineering
Mekelweg 4,2628 CD Delft, The Netherlands

Abstract with a very specific internal structure (e.g., RAMS,

Increasing complexiry of modern designs and high costs
of test equipment are putting more and more emphasis
on test application times. This paper presents a classi-
fication of methods for reducing the test time of a de-
vice by exploiting parallelism in Macro Test. Techniques
and considerations will be given for different methods
of parallel testing. I t will be shown that without design
modifications signijicant reductions in test time can be
reached. To obtain afirther test time reduction, anal-
ysis of resource sharing conflicts is done in order to be
able to decide which design modifications can best be
made. As a result, a trade-off between test time and ad-
ditional testability hardware can be made. Results of one
of the methods of parallel testing are given for two in-
dustrial devices. Test time reductions of up to 40-50%
compared to sequential approaches have been reached
without making any design modifrcations.
1 Introduction
Due to increasing IC complexities and decreasing IC de-
sign times, meeting testability constraints becomes more
and more a challenge. Testability has been defined as
[Be 841:
“An electronic device is testable, if test patterns can be
generated, applied and evaluated such that predefined
objectives vault detection,fault location, maximum num-
ber of test patterns, maximum run time, etc.) are met
within given time and costs constraints.*’
Complex designs often consist of several building blocks
ROMs, PLAs, ALUs). It is found, that these build-
ing blocks are better tested through the use of dedicated
fault and defect models, dedicated test pattern generation
tools and specilic test strategies. Macro Test provides
a strategy to be able to generate test specifications for
such complex designs [Be 86,Be 90,Bo 921. The device
is partitioned into testable blocks (macros),whereby ac-
cess to every macro is created from the device pins.
Activities to produce a testable design are called testa-
biliry synthesis. In Macro Test, testability is considered
to be an integral part of the design process. By closely
matching the partitioning in the design (design blocks)
with the partitioning for test, testability synthesis can
start in the early design cycles. Also, partitioning allows
the use of macro-specific test strategies and fault models
[De 881. If each macro is testable as a stand-alone unit,
stepwise adding Design For Testability (DFT) hardware
can guarantee the whole design to be testable.
Macro Test relies on the ability to execute a test for a
macro from the device pinning. We have decoupled the
access protocol for a macro from the test data required
to test this specific macro. An access protocol or test
plan specifies how to transport a set of test patterns to
a macro, how to apply the patterns, and how to observe
the responses. Every macro has its own test plan. Af-
ter a test plan is specified at the macro boundaries, it
must be transformed into a test plan specified at the de-
vice boundary. This transformation is executed by a test
plan generation process. The process is based on a path
tracing algorithm using functional properties of blocks
in the design [Ma 931.

INTERNATIONAL TEST CONFERENCE 1993 Paper 20.3

0-7803-1429-8/93$3.00 1993 IEEE 451

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
 After a test plan (at the device boundary) and a test pat-
tem set have been generated for a macro in the design,
the test pattern insertion process takes care of writing
out the test plan for every test pattern in the set. The re-
sult of this process is called the mucro test specification.
Finally, a complete device tesf specification is produced
by merging all macro test specifications. This process is
called test assembly [Be 903. Test pattern insertion and
test assembly have been visualized in Figure 1.
test test test
patterns plan
-
"'
test pattern
insertion
macro test macro test
specification
test assembly - a specification on which IC pins and at what relative
device test
specification
Figure 1: Test pattern insertion and test assembly.
Until recently, test assembly was mainly a concatena-
tion procedure: a device test was performed by sequen-
tial execution of test plans for every pattem in the test
pattern sets. However, this approach of performing the
assembly procedure leads to a long device test time. Es-
pecially if reloads of the tester memory are required, the
costs for testing may easily exceed an acceptable level
p a 901. This is certainly the case for large consumer
type of devices, in which the price of the product is
strongly determined by the market.
Several techniques to reduce test times by scheduling
tests for designs which are tested using Built-In Self Test
(BIST), are given in [Ki 82,Ab 86,Cr 88,Fe 90Jo 901.
In [Oo 91,Gu 91,Na 921 the test time is reduced by or-
ganizing the scan registers in one or more scan chains
to reduce the total number of shift operations required.
Within Philips, BIST is only used in special cases, e.g.,
for RAMS which require a high amount of test patterns
to reach an acceptable fault coverage. A demand exists
for parallel test techniques which apply closely to the
Macro Test strategy.
This paper presents techniques to optimize the device
test specification by considering parallelism in Macro
Test. This parallelism is exploited in a test assembly al-
gorithm. It is shown that without design modifications,
significant reductions in test time are possible. Also will
be shown which design modifications can best be made
to the testability hardware in a design in order to ob-
tain afurfher reduction of the test time. Results will be
presented for two industrial devices of which one has re-
Paper 20.3
452
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
cently been taken into production. With the pamllel test
assembly algorithm, reductions of up to 40-50% have
been reached compared to traditional techniques where
macros were tested sequentially.
2 Test assembly
Test plan generation
As mentioned in the introduction, the lest plan gener-
test ation process determines the access protocol (test plan)
required to access a macro from the device pinning. This
process is based on a path tracing algorithm using func-
tional properties of blocks in the design. A test plan is
data independent. It contains references to test data and
times data needs to be applied or observed and control
needs to be set.
A test plan consists of a sequence of feesf plan steps. In
every test plan step, control values are specified which
must be applied to test control ports on a relative clock
cycle. Also, the step specifies input ports and output
ports, with a reference to the values that must be applied
to or observed from that port.
Example
Consider the example design block in Figure 2. In this
design, macros M1 and M2 are tested using scan tech-
niques. nl and n2 represent the number of test patterns
required to test M1 and M2. The modes of the four scan
registers in this example are controlled by control sig-
nals cl, c2, c3 and c4. It is assumed that the scan mode
is specified by S and the normal mode by N. Don't care
values are specified by -. To be able to reduce test time
by ordering registers in a scan path, [Oo911 introduced
the weight of scan registers. The weigh[ W,., of a scan
register ri of length l i is defined by:
[Oo 911 showed that a good heuristic for minimizing
the total number of required shift cycles is to sort the
registers in a scan path in order of decreasing weight
from the scan data input port (sdi) to the scan data output
port (sdo). If we take n2 > nl, this results in the register
ordering given in the figure.
Test plans for M 1 and M2 are specified in Tables 1 and 2.
In these test plans, p a l and paw2 represent the sets
of test patterns that need to be applied to M1 and M2
respectively. A test pattern consists of two parts. A first
part specifies the bits that must be applied to a macro,
the second part specifies the bits that must be observed.
For example, for M1 four bits must be applied, and two
bits must be observed. patM1[1..4] gives a reference
 to the bits that must be applied, patM1[5..6] gives a x14 steps + 3 patterns x 8 steps = 52 cycles or tesr
reference to the bits that must be observed. Note that it specification steps (Figure 3).
is possible to observe the result at the scan-out port at
steps 12 and 13 instead of steps 13 and 14 in the test Test Plan M1 Test Plan M2
plan of Figure 1 (by shifting the observe window). Since
only in specific examples this would give a reduction in
test time, and for simplicity reasons, this optimization
will not be taken into account.

c l c2 c3 c4

0 Cycles 52

Figure 3: Sequential test assembly.

However, this (sequential) test time can be reduced by

Figure 2: Example design (n2 > nl).
a more efficient merge of test plans and test data into
another test specification. For example from Figure 2
can be concluded that the shift-in of a test pattern can
safely be done in parallel with the shift-out of a previous
test pattern. Also, patterns can be shifted in to M1 and
M 2 in parallel.

controls data-ins data-outs

The following protocol can now be used to test M1 and
cycles cI..c4 Sdi Sdo
M2. First, a pattern for M1 and M 2 is shifted in and
1-4 S--- PtM 1[ 1-41 - applied. This takes a total of 8 + 1 = 9 cycles. While
5-1 SS-- - - the next pattern for M1 and M2 is shifted in, the results
8 -s-- - -
of both macros are shifted out. Again, this requires 9
9 -NN- - -
10 --ss - - cycles. Since two patterns were required to test M1 and
11-12 --- S - - three patterns to test M2, we are left with one pattern.
13 ---S - P ~ 1151
M Shifting-in this final pattern requires 4 cycles. However,
14 ____ - P ~ 1M161 we still need to shift-out the results of the former pattern
which requires 5 cycles. After applying the final pattern
we need 3 cycles to shift-out the response of M2. The
parallel assembly of test plans and test data now results
in a test specification of 8 + 1 + 8 + 1 + 5 + 1 + 3 = 27
test specijication steps (Figure 4). Thus, a reduction in
test time from 52 steps to 27 steps can be obtained by
considering parallelism in testing.

Table 2: Test plan for M2. 3 Parallelism in testing

Test assembly
After test plans and test pattern sets have been generated
for every macro in the design, a device tesr specijicarion
needs to be produced. This process is called rest assem-
bly [Be 901. A simple but effective approach to perform
the assembly is by sequentially writing out all macro test
plans for every pattern in the pattern set of the macro.
For example, if in Figure 2 n l = 2 patterns and n2 = 3
pattems, this approach leads to a test time of 2 patterns
We will call the execution of a test plan for a single pat-
tem a tesr plan execution. Test plan executions which
can be merged are said to be compatible. To be able
to determine compatibility, we introduce the notion of
a resource. A resource can have attributes as design
entity (hardware), rime, signal value and signal direc-
tion. A resource is considered the entity which we use
to differentiate between test plan executions that can be
performed in parallel and test plan executions that can-
not. It will be shown that the choice what to consider

Paper 20.3
453

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
 --
Test Plan M 1 Test Plan M2
-
T 14 steps
F
a steps
7 considered to be the resources for this test plan. In the
i P H d
tJ4hl-I
iTest Specification
Y
0 Cycles 27
Figure 4: Parallel test assembly.
as resources may significantly determine the amount of
parallelism that can be exploited, and therefore the test
time reduction that can be reached.
To minimize test time, the test assembly process needs to
allocate the macro test specification steps to time slots
in a way that the total number of required time slots
(number of device test specification steps or: clock cy-
cles required) is minimized. This allocation needs to be
done in a way that the functionality of the test plans
is maintained, and without the occurrence of conflicting
resource conditions.
A classificationof different levels of parallelism in VLSI
testing can now be made by considering different choices
that can be made to specify resources.
Test plan parallelism
At a first level, only hardware structures are consid-
ered as resources. If no hardware structures are shared
between two test plans, they can be executed in paral-
lel. The level at which parallelism is considered will be
called the rest plan level, since resources are specified
for complete test plans. The relative time steps (or test
plan steps) at which specific hardware structures are used
are not (or: need not be) taken into consideration. For
example, in [Ki 82,Cr 881 register segments that act as a
TPG (test pattern generator) or SA (signature analyzer)
in BIST are considered to be resources. This means that
tests which require the same register segment in their
execution cannot be applied in parallel.
Example
Consider the example design in Figure 2. The test plans
for macros M1 and M2 have been given in Tables 1
and 2. From Figure 2, it can easily be seen that pattems
can be applied to M1 and M2 in parallel by shifting
patterns in and out concurrently for both macros. This
merged test plan is given in Table 3. This merge of test
paper 20.3
454
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
plans can be done since M1 and M2 do not share regis-
ters for applying or observing test patterns. Therefore,
registers which are used to apply or observe test pattems
in a test plan are sufficient to be considered as resources.
In the test plan of Table 1 patterns are applied via reg-
ister R2 and observed via register R3. R2 and R3 are
same way, R1 and R4 are the resources for the test plan
of Table 2. Since no resources are shared, the test plans
can be merged. Macros M1 and M2 can now be tested
by executing the merged test plan n l times, and the test
plan of M2 n2-nl times.
controls data-im data-outs
cycles cl..c4 sdi Sdo
1-4 S--- wM1I141 -
5-8 ss-- patM2II-41 -
9 NNNN - -
10 --ss - Patm51
11-12 ---S - patMZ(6-71
13 ---S - p a t 1151
~
14 ____ - o a t 1161
~
Table 3: Merged test plan for M1 and M2.
Note the don’t care values given for control ports cl..c4.
Control ports cl ..c4 can be merged into a single port with
modes scan (S) and normal (N) by choosing N for the
don’t cares on cycle 9, and S for the don’t cares of the
remaining cycles. For readability reasons, don’t cares of
further test specification examples have been filled in.
Test plan step parallelism
A lower level at which parallelism can be considered is
the rest plan step level. At this level, a resource consists
of a hardware srrucrwe in combination with the rime step
at which the hardware structure is required. Thus, hard-
ware structures are specified for test plan steps instead
of for complete test plans. Now that (relative) times
are known at which hardware structures are used, test
plans can be scheduled to use shared hardware structures
at different times during their execution [Sa 881. This
level also creates the possibility to exploit pipelining be-
tween two consecutive test plan executions [Ab 861, i.e.,
the execution of a test plan can safely be started before
a previous execution of the same test plan for another
pattem has been finished.
Examples
Consider the example design in Figure 2. The test plan
for macro M1 has been given in Table 1. We consider
parallelism at the test plan step level. A resource is
considered to be a scan register in combination with the
time interval in which the scan register is used (contains
test data). Since the scan-in steps (1-8) are compatible
with the scan-out steps (10-14), pipelining can be ex-
 ploited between consecutive test plan executions. A test that it can only be exploited if the registers contain a
specification for M 1 according to this semi-pipelining hold mode. However, in this case test time can also be
protocol is given in Table 4. reduced by performing the shift-in, apply and shift-out
cycles for M1 and M2 simultaneously (see Table 3). Af-
controls data-ins 11 data-outs
ter executing this parallel scheme nl times, all test pat-
repeat cycles ~ 1 . ~ 4 Sdi II sdo
1 4 ssss tems for M1 have been applied and the n2-nl remain-
4 ssss ing patterns for M2 can be applied according to one of
nl-1 1 NNNN the schemes described above. With this approach, hold
3 ssss modes are not required for the scan registers. Table 6
1 ssss gives an assembled test specification for M, in which
1 ssss
3 ssss parallelism at the test plan step level has been exploited.
1 1 NNNN
3 ssss
2 ssss
Table 4: Test specification for M1 (semi-pipelining).

Note that the shift-in of a test pattern is started as soon

as the previous pattern has been applied to M1. The
issuing rate of test pattems to the sdi port can be higher
if registers (R1 and R4) are equipped with a hold mode.
By putting R1 and R4 in hold mode (H) when R2 and
R3 are in normal mode (N), test data in R1 and R4
can be saved. Of course, to be able to exploit this full-
pipelining possibility, the test assembly process needs
knowledge about possible modes of the scan registers.
Also, this new shifting protocol poses requirements on
the test control structure, since a simple merge of con-
trol ports cl..c4 in one new control port is not longer Table 6: Test specification for M.
possible. Therefore, best results can be obtained from
a test assembly algorithm, if the assembly is done be- Test Specification step parallelism
fore building the test control structure. The assembled
test plan for M1 according to this full-pipelining shift A third level at which parallelism for testing can be
protocol is given in Table 5 . exploited is the tesi specifrcafion step level. Note the
difference between a test plan step and a test specifica-
controls tion step. A test plan step contains references to a test
repeat cycles ~ 1 . ~ 4
1 4 ssss patMl1 1-41
pattern set. However, since every test plan step will be
4 ssss patM 1 1 1-41 executed once for each pattern that must be applied or
1 HNNH observed, the conienfs of the test data are not known in a
3 ssss test plan step. In a test specification step, these contents
1 ssss are known. Therefore, (parts of) a test pattem may be
nl-3 1 HNNH
1 ssss used more than one time in a test plan execution. Thus,
2 ssss at the test specification step level, a resource is con-
1 ssss sidered a combination of a hardware structure (space
1 1 HNNH
1 ssss domain), a time step at which the hardware structure is
2 ssss required (time domain) and the state (value) of the hard-
1 ssss ware structure at this time step in terms of the test data
1 HNNH contents (contents domain). Two forms of test specifi-
1 ssss cation step parallelism can be given. First, a part of a
2 ssss
ssss test pattem may be saved after it has been applied to a
macro, so it can be used again as a part of a successor
Table 5: Test specification for M1 (full-pipelining). pattern that must be applied to the macro. Second, (parts
of) test data which is required for more than one macro
Disadvantage of the full-pipelined shifting protocol is may be applied to these macros simultaneously.

Paper 20.3
455

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
 Example fault simulation which faults in M2 are covered by this
First, an example in which a part of a test pattem is test pattem set. For M2, test pattem generation is now
saved after it has been applied to a macro and is used only required for the remaining (not yet covered) faults.
again as a part of a successor pattern that must be applied If M1 and M2 are identical, considering parallelism at
to the macro. Again, consider Figure 2. Let nl = 3 and the test specification step level provides an effective ap-
the test pattern set for M1 be patM1[14] = {IlOlLH, proach for parallel testing [Me 901.
OlOlHH, OllOLL}. Note from Figure 2 that for M1 the
applying register R2 is 4 scan cells wide whereas the
observing register R3 is only 2 scan cells wide. Thus,
R3 can observe a new response pattern from M1 every
2 cycles. Without knowledge of the test data contents
it takes 4 cycles to fill R2 with a new pattern for M1.
However, if the contents of the test data are taken into
consideration, a possible overlap between the test pat-
tems can be exploited. Assume R2 is filled with test data
for M1. Also assume that R2 contains a mode in which sdi
data can be applied to Ml in a manner that the contents
of R2 are not lost. This mode will be called the ap-
ply/hold mode (A). Now, overlap between test patterns
I : ; I 4I sdo
can be exploited by shifting two instead of four times I i:
after each pattern apply cycle. The test specification for
M1 due to this parallelism at the test specification level Figure 5 : Example design (n2 > nl).
is given in Table 7.

controls A resource compatibility relation

repeat cycles cl ..c4
I 4 ssss
2 ssss
2 ssss
1 HANH
2 ssss
1 HANH
1 ssss
1 ssss
1 HANH
5 ssss
Table 7: Test specification for M1 (contents-pipelining).
Example
Second, an example in which test data is simultaneously
applied to two macros. Consider the example design in
Figure 5. In this design, M1 and M2 are connected to
a bus. The bus has been made controllable and observ-
able via a scannable bus control block (BCB) [Bo 921.
Now, a test pattem that has been scanned in to the BCB
can be applied to both M1 and M2 simultaneously. An
interesting approach to minimize the test time of this
design could be to try to find the minimum set of test
patterns that detects faults in both M1 and M2 instead
of generating sets of pattems for M1 and M2 separately.
If patterns for M1 and M2 are generated using differ-
ent test pattern generation tools (e.g., if M1 is a RAM,
and M2 combinatorial logic), a possible method could
be to generate test pattems for M1 and to check via
Resources are the abstraction that enables us to differen-
tiate between test plan executions that can be performed
in parallel (according to a certain parallel scheme) and
test plans that cannot. We showed that, for testing, a
resource can be considered a combination of a hardware
structure, a time step at which the hardware structure is
required and the state (value) of the hardware structure
at the time step. If resources for two test plan exe-
cutions are compatible, the test plan executions can be
performed in parallel.
Examine Figure 5. Note that parallelism is possible de-
spite the fact that the bus is shared between test plan
executions for M1 and M2 on the same time step. How-
ever, this kind of parallelism cannot be exploited if hard-
ware structures are shared in the pattem response trans-
portation hardware. For example, if M1 and M2 both
write on the same bus, test plan executions cannot be
merged since only the value that should be observed is
known. The actual value that will be observed deter-
mines whether or not a fault occurred in M1 or M2.
Therefore, we will distinguish between input hardware
structures and output hardware structures. For compati-
bility, input hardware structures may be shared on a time
step, as long as the state of the input hardware structure
is the same between test plan executions.
Let hw be a hardware structure, for example, a test con-
trol port. The type of the hardware structure (in this

Paper 20.3
456

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
 case: input) is given by the variable type. The time step
at which hw is required is given by time. State gives the
state of hw (in this case: the value of the control port
at time step time). A resource can now be considered a
r2 are said to be compatible (notation: rl
only if
-
four-tuple {hw, type, time, state}. TWO resources rl and
r2) if and
(hw1 +hW2)
+
v (time, time2)
V ((statel -
state2) A (type1 = type2 = input)).
For a test plan execution, a set of resources needs to
be specified. Two test plan executions tp1 and tpz are
compatible (i.e., can be performed in parallel) if every
resource ri E R(tp1) is compatible with every resource
rj E R(rp2) (with function R returning the resources in
a test plan).
--
Note that the compatibility relation is not transitive, i.e.,
if x y and y z then no knowledge exists whether x
N
2.
We can use the compatibility relation to determine com-
patibility for every pair of test plan executions. The
results of this analysis can be presented in a test com-
patibility graph (TCG) [Ki 821. Every node of the TCG
represents a test plan execution. An edge occurs be-
tween two nodes if the test plan executions are compat-
ible. Concerns about the way in which test plan execu-
tions are merged and the reductions in test time if spe-
cific merge algorithms are used lead to different TCG
representations, TCG labelings, and test scheduling al-
gorithms. Test scheduling algorithms aim at finding a
schedule for test plan executions which gives a mini-
mum test time, given a certain protocol for merging test
plan executions.
4 Implementation considerations
For an initial implementation of a parallel assembly al-
gorithm in the Macro Test tools available within Philips,
we have chosen to first exploit parallelism at the test plan
level and the test plan step level. As a first approach,
we have developed an assembly algorithm that generates
a test specification for a number of macros, given gen-
erated test plans and test pattern sets for every macro.
Advantage of this approach is that a significant reduc-
tion in test time is reached without making any design
modifications.
Algorithm
We chose to implement an algorithm which is able to
merge test plan executions according to the principles
given in Tables 3 and 4. Thus, if possible, pattems will
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
be applied to several macros in parallel and the shift-
in of new patterns will be done concurrently with the
shift-out of previously applied patterns. For every test
plan, resources are specified by the test plan generation
process. Four hardware structures are specified: (1) test
control ports, (2) scan output registers: scan registers
used for application of patterns, (3) scan input registers:
scan registers used for observation of patterns, and (4)
primary ports: primary ports used for application or ob-
servation of patterns. Since a scan register may apply
a pattern to one macro, and simultaneously observe a
response from another, a difference has been made be-
tween scan input registers and scan output registers.
To be able to determine whether the shift-in of new
patterns can safely be done in parallel with the shift-
out of previously applied patterns, we specify for each
hardware structure whether it is required during scan-in,
apply or scan-out.
For control ports, the value of a port on a time step
needs to be specified (the state). If two test plans require
incompatible values on a control port during scan-in,
apply or scan-out, the test plans are incompatible.
Using the resource specifications, compatibility can be
determined between every pair of test plans, and visu-
alised in a test compatibility graph (TCG). Using the
TCG, a schedule of test plans with minimal or close to
minimal test time can be determined. To perform this
scheduling, an (approximate) measure for the reduction
in test time is required for our method of merging test
plans.
Test time costs
Let nt, be the number of test patterns that need to be
applied through a test plan t,. The number of shift op-
erations between two consecutive applications of test
patterns is given by the sh$t length ht,. Let :6 specify
the number of shift operations required in t , to shift-in
a pattern and 6:; specify the number of shift operations
required in t , to shift-out a response. An approximate
equation for the test costs C ( t z )i.e.,
, the number of cy-
cles required to execute a test plan can now be given
[Oo 911:
C(ti)x nt, ' 6t,.
If semi-pipelining is not being exploited, the shift length
can be given by:
6 t , = 6; +b y .
If shifting is done according to the semi-pipelined pro-
tocol of Table 4, the shift length becomes:
bt, = max(6?, ~5~;.)
Paper 20.3
457
 The test time reduction if two scan test plans t l and t 2
are executed in parallel according to the protocol given
in Table 3 is approximately equal to:
These cost criteria can be used as a basis for different
kinds of (heuristic) scheduling algorithms as have been
given in [Ki 82,Cr 88Jo 90,Oo 911.
To be able to exploit the advantages of partitioned test-
ing as described in [Cr881, our scheduling algorithm
takes for every test plan a parameter which specifies
whether an interruption between consecutive test plan
executions is allowed or not. For example for RAMS,
interruption is only allowed if the contents of the RAM
are not lost, or if a mechanism for restoring the RAM
to its state of before the interruption exists.
Further reducing test time
After the resource compatibility graph has been created,
an analysis can be done which further test time reduc-
tions can be reached by removing incompatibilities be-
tween test plans. This can be done in two steps.
First, a new test plan generation process for a macro can
be directed to try to find different resources (e.g., dif-
ferent scan registers in which a response pattern can be
observed) to be used in a macro test plan. In this way,
"expensive" incompatibilities between test plans can be
removed. However, the attempt to remove an incom-
patibility may introduce new incompatibilities between
other test plans. A different approach may be to gener-
ate all possible test plans for a macro. The test assembly
algorithm can then choose the optimal test plan for the
assembly process to obtain a minimal test time. Note
that this further reduction in test time is reached without
making any design modifications.
Second, modifications can be made to testability hard-
ware structures that are used. Analysis of occurring re-
source sharing conflicts may lead to the conclusion that
design modifications can further reduce test time. A
trade-off between additional testability hardware and a
reduced test time can now be made.
Macro test optimizations
As mentioned, inputs for the algorithm described here
are a set of generated test plans with corresponding test
pattern sets. The result of the algorithm is a schedule of
test plans. Execution of the test plans according to this
schedule leads to minimal or close to minimal test time.
The schedule consists of a number of parts. In each
part, a new set of (assembled) test patterns is applied
to a number of macros in parallel according to a new
(assembled) test plan. We can now extent the concept
Paper 20.3
458
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
of a macro to a virtual macro. A virtual macro can
be tested by executing its assembled test plan for every
pattern in its assembled test pattem set. Note that with
the introduction of virtual macros, the direct relationship
which existed between macros and a block of hardware
is lost. Executing a test plan for a virtual macro will
test part of the hardware in one or more macros. Virtual
macros are merely the result of an optimization process
(in this case: for test time). Since both the input and
the output of the assembly process are (virtual) macros,
several optimization processes can now be performed
independently.
5 Results
To demonstrate the validity of the approach presented in
this paper, we take a digital signal processor (DSP1) IC
produced by Philips Semiconductors. This DSPl con-
tains about 150,000 transistors. The IC is partitioned
into 18 macros. For every macro, the control class of
the test plan, the number of test patterns T i t , and shift
length bt, have been given in Table 8. Also, the macro
test plans have been divided into control classes. All
test plans of a class are tested using compatible control,
i.e., the values that need to be applied to the control
ports are compatible between the test plans. Thus, test
plans of different control classes cannot be executed in
parallel. Since for all test plans, control values turned
out to be compatible between scan-in and scan-out, the
shift lengths are specified for the semi-pipelining shift
protocol. All reductions presented here are compared to
the semi-pipelining protocol.
Table 8: Macro data for the DSPl.
For every control class, the test incompatibility graph
FIG) has been given in Figure 6.
 gives the test time reduction if only incompatibilitiesdue
to sharing of data ports and scan registers are removed.

class 1 Iclass 2
test reduction number of removed
time registers incompatibility
I shared
276224 I 50% I all
325151 41% all reg. sharing
332937 40% 18 16 - 17
456839 17% 9 14 - 17
459443 17% 19 15 - 16
459517 17% 18 15 - 17
465049 16% 1 3-4
class 3 466091 16% 1 1-2
466869 16% 9 8 - 10
466889 16% 1 5-6
466889 16% 10 9 - 10
466899 16% 13 12 - 13

Table 10: Test time reductions if incompatibilities are

Figure 6: TIGs for every control class. removed.

The results of the scheduling process are given in Ta- As can be seen from Table 10, a reduction of 40% can
ble 9. The schedule consists of 17 assembled test plans be reached if the incompatibility between test plans 16
s j . The number of test patterns 72,, and shift length 6,, and 17 (the test plans for the two RAMs) is removed.
have been given for every assembled test plan. The test Choosing different test plans for the RAMs leads to the
time dropped to 466889 cycles, i.e., a reduction of 16%. new test schedule given in Table 1 1 . Note that the re-
duction of 40% in test time has been reached without
mucro components nsi 6,, making any design modifications.
6 7 13 17 18 20 202
6 13 17 18 30 163
6 13 17 30 163 - -
5 13 17 20 163 -
j macro components &
13 17 92 163 I 6 7 13 14 16 17 18 20 202
12 17 10 192 2 6 13 14 16 17 18 30 172
17 1254 163 3 6 13 14 16 17 30 172
14 16 150 158 4 5 13 14 16 17 20 172
16 1564 91 5 13 14 16 17 50 172
2 10 11 80 110 6 13 16 17 42 172
11 1 10 11 21 110 7 12 16 17 10 192
12 10 11 262 72 8 16 17 1254 172
13 8 9 11 20 73 9 16 258 91
14 I1 220 55 10 2 10 11 80 110
15 15 76 96 11 1 10 11 21 110
16 3 64 91 12 10 11 262 72
4 20 94 13 8 9 11 20 73
14 I1 220 55
-
para llel time 466889
15 15 76 96
16 3 64 91
Table 9: Test schedule for the DSPl.
-17
Da I
4
el rime
- 20 94
7 ;721
-
Analysis results of removing resource sharing conflicts
to further reduce test time are given in Table 10. The 6rst Table 11: Test schedule after the incompatibility be-
line of this table shows that a reduction of 50% would tween macros 16 and 17 has been removed.
be reached if no incompatibilities would exist, i.e., all
test plans can be put in one control class and no primary
data ports, scan input registers and scan output registers Application of the parallel assembly algorithm to a sec-
are shared between test plans. Thus, for this IC, 50% ond industrial device (here called DSP2) has lead to
is the minimum reduction that can be reached with this similar promising results. A general overview of results
method of parallel testing. The second line of Table 10 for both ICs is given in Table 12.

Paper 20.3
459

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.
 DSPl 1 1 I 1
sequen:;\,
semi-ppe med
parallel (initially)
parallel after
removing a resource
10996
~~3~16

466889

335721
~~
sharing conflict
wtentia
r -
6 4
DSP2 sequential 1170360
semi-pipelined 587076 0%
parallel 298894 49%
potential 136932 77%
Table 12: Test time reduction results.
6 Conclusion
In this paper, a classification of different possibilities for
reducing test time of devices by exploiting parallelism
in Macro Test has been presented. It has been shown,
that the choice what to consider resources for testing
greatly determines the complexity of the test scheduling
algorithm that needs to be used and the amount of par-
allelism (and therefore the reduction in test time) that
can be exploited. Also, impacts of test plan generation
and test control structures on parallelism are described.
Application of one of the techniques of parallel testing
to industrial devices has lead to test time reductions of
40-50% without making any design modifications.
Acknowledgements
This work was carried out in JESSI project AC6.
The authors like to thank the members of group Van
Utteren at Philips Research Labs for the many valuable
discussions.
References
[Ab 861 Magdy S . Abadir, Melvin A. Breuer, "Test Schedules
for VLSI Circuits Having Built-In Test Hardware", IEEE
Transactions on Computers, April 1986, pp. 361-367.
[Ba 901 Robert W. Bassett et. al., "Low-cost testing of high-
density logic components", IEEE Design and Test of Com-
puters, April 1990, pp. 15-28.
[Be 861 Frans Beenker et. al., "Macro Testing: Unlfying IC
and Board Test", IEEE Design & Test of Computers. De-
cember 1986, pp. 26-32.
[Be 901 Frans Beenker, Rob Dekker, Rudi Stans, Max van
der Star, "Implementing Macro Test in Silicon Compiler
design", IEEE Design & Test of Computers, April 1990,
pp. 41-51.
[Be 841 R.G. Bennetts, Design of Testable logic circuits,
Addison-Wesley, 1984.
[Bo 921 Frank Bouwman et. al., "Macro Testability; The
Results of Production Device Applications", Proceedings
IEEE International Tesl Cor$erence, 1992, pp. 232-241.
[Cr 881 Cary L. Craig, Charles R. h e , Kewal K. Saluja,
"Test Scheduling and Control for VLSI Built-In Self-Test",
IEEE Transactions on Computers, September 1988, pp.
1099-1 109.
[De 881 Rob Dekker, Frans Beenker, Loek Thijssen, "Fault
Modeling and Test Algorithm Development for Static Ran-
dom Access Memories", Proceedings IEEE International
Test Conference, 1988, pp. 343-352.
[Fe 901 Sheng Feng, Yashwant K. Malaiya, "Optimization of
Test Parallelism with Limited Hardware Overhead", Micro-
electronics Reliability. Vol. 31 1991, pp. 271-276.
[Gu 911 Rajesh Gupta, "Advanced Serial Scan Design for
Testability", CEng Technical Report 91-IO, University of
Southern California, 1991.
[Jo 901 Wen-Ben Jone, C.A. Papachristou, M. Pereira, "A
Scheme for Overlaying Concurrent Testing of VLSI Cir-
cuits", 26th ACMIiEEE Design Automafion Conference,
1989, pp. 531-536.
[Ki 821 Charles R. Kime. Kewal K. Saluja, "Test Scheduling
in Testable VLSI Circuits", Proceedings International Sym-
posium on Fault-Tolerant Computing, 1982, pp. 406-412.
[Le 901 Sunggu Lee, Kang G. Shin, "Design for Test Using
Partial Parallel Scan". IEEE Transactions on Computer-
Aided Design, February 1990, pp. 203-21 1.
[Ma 931 Erik Jan Marinissen, Krijn Kuiper, Clemens Wouters,
"Testability and Test Protocol Expansion in Hierarchical
Macro Testing", Proceedings IEEE 3rd European Test Con-
ference, 1993.
[Me 901 R. Mehtani et. al., "Macro-Testability and the V S P ,
Proceedings IEEE Inferrdonal Test Conference, 1990, pp.
739-748.
[MO 911 Sean P. Morley, Ralph A. Marlett, "Selectable
Length Partial Scan: A Method to Reduce Vector Length",
Proceedings IEEE Infernational Test Conference, 1991, pp.
385-392.
[Na 92) Sridnar Narayanan, Charles Njinda, Melvin Breuer,
"Optimal Sequencing of Scan Registers", Proceedings
IEEE infernutional Test Conference, 1992, pp. 293-302.
[Oo911 Steven Oostdijk, Frans Beenker, Loek Thijssen, "A
Model for Test-Time Reduction of Scan-Testable Circuits",
Proceedings IEEE 2nd Europem Test Conference, 1991, pp.
243-252.
[Sa 881 John Sayah, Charles R. Kime, 'Test Scheduling for
High Performance VLSI System Implementations", Pro-
ceedings IEEE Inlernational Test Conference, 1988, pp.
421-430.

Paper 20.3
460

Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on October 13,2021 at 14:37:55 UTC from IEEE Xplore. Restrictions apply.