Application of Test-View Modeling to Hierarchical ATPG

Rahul Shukla, Phong Loi, Kathy Yang

Nagesh Tamarapalli
Arie Margulis, Ken Pham


Advanced Micro Devices Inc, Mentor Graphics AMD India Private Limited
1 Commerce Valley Dr 411 Legget Drive, Suite 502 EPIP Zone Whitefield,
E Markham, Canada Ottawa, Ontario Brookfield, Bangalore, India
rahul.shukla, phong.loi@amd.com kathy.yang@mentor.com nagesh.tamarapalli@amd.com
arie.margulis,ken.pham@amd.com

Abstract-Hierarchical ATPG has become a standard
methodology to achieve full coverage for large SoCs. But
with increasing size of SoCs even hierarchical ATPG is
hitting limitations, pushing ATPG Tool capabilities and
design-center compute resources to their limits. This paper
illustrates the application of test view models to
hierarchical atpg with a focus on advantages of using Test
View models as part of scan verification and Test pattern
generation in large SoCs. The paper also outlines the
requirements for generating a robust Test View model and
the different methodologies considered for generating the
test view model.
Keywords- hierarchical atpg, test view modeling, ATPG
verification
I. INTRODUCTION
Hierarchical ATPG has become a standard methodology
to achieve full coverage for large SoCs. But with increasing
size of SoCs even hierarchical ATPG is hitting limitations,
pushing ATPG Tool capabilities and design-center compute
resources to their limits.
In this paper we will discuss the application of Test-View
models to facilitate Hierarchical ATPG, with a focus on
the guidelines for a test-view model,
the methodologies considered to generate Test-
View models
benchmarking of the test-view generation
methodologies and
Finally the runtime and compute resource benefits
of a Test-View Model based approach for
Hierarchical ATPG.
In order to facilitate verification, implementation, physical
design and Scan-ATPG flows, today the SoCs is partitioned
into smaller IPs.
From Scan-ATPG perspective, Scan Isolation wrappers
are inserted at the boundary of each IP to isolate it, as
shown in Figure 1. As part of Hierarchical ATPG each such
IP is tested in inward facing mode (Intest) and outward
facing mode (Extest or Interconnect). Along with ATPG at
ATE, functional debug using scan dump is also supported as
part of DFx. Scan-dump uses scan chains to capture the data
and shift out in single chain mode
For hierarchical ATPG pattern generation, existing
literatures [1], [2], [3], [4] propose IP-SoC based test pattern
generation to address the limitations with large design size.
As the size of SoCs are increasing, the probability of
defects in interconnect mode is also observed to increase.
So even though Intest Mode provides the significant portion
of fault coverage a robust Extest mode is also becoming
imperative. Both Extest and Single Chain mode require the
entire design to be loaded into the Test and Verification
Tool, which consistently exceeds compute and Tools
capabilities.
The hierarchical ATPG section describes the IP-SoC
methodology. The Test-View Model Usage and
Expectations section discuss the Test-View metrics. The
Comparison of Test-view Model Methodologies section
compares the different methodologies considered for the
generation of a Test-View model with the advantages and
disadvantages of each. The Verification of the Test-View
Model section illustrates the verification methodology
followed to ensure correctness of the test-view models. The
Results Run time savings and comparison section
illustrates benchmarking of different methodologies
considered for the Test-View model generation and the
ultimate runtime/machine resource savings by using the
Test-View models.
II. HIERARCHICAL ATPG METHODOLOGY
As part of hierarchical ATPG, each IP is tested in two scan
modes, the Inward facing mode Intest Mode and the
Interconnect test mode Extest Mode. Intest mode sets
up the SOC where each IP block is isolated and all internal
logic is tested simultaneously. Extest mode sets up the SOC
where only the interconnections of the IP blocks are tested.
2014 27th International Conference on VLSI Design and 2014 13th International Conference on Embedded Systems
1063-9667/14 $31.00 2014 IEEE
DOI 10.1109/VLSID.2014.26
110
2014 27th International Conference on VLSI Design and 2014 13th International Conference on Embedded Systems
1063-9667/14 $31.00 2014 IEEE
DOI 10.1109/VLSID.2014.26
110

Figure 1: Support for Hierarchical ATPG
To facilitate the IP-SoC ATPG methodology, each IP block
has local clock chopper circuits to control the shift and
capture clocks during scan. The ports for the block have
isolation wrappers to drive and capture data internally in
Intest mode and drive and capture data externally in Extest
mode. The SoC has distributed IEEE1500 client and power
controller so each IP block can be setup locally.
Efforts were allocated to ensure complete JTAG control
of PLL when in test mode as elaborated in [1]
In hierarchical ATPG, patterns for each block are
generated at the IP level. The patterns are merged together
and translated to SoC level. This method has merits in terms
of ease of pattern generation, diagnosis and reusability for
duplicate IP cores (especially for Graphics core and CPU
cores).
The verification of Intest, Extest and Single Chain is done
using a divide and conquer approach. Each IP is
verified at IP level followed by verification at SoC level.
III. TEST-VIEW MODEL USAGE AND EXPECTATIONS
Here we elaborate on the intended usage and guidelines for
Test-View.
A. Extest Mode
In Extest Mode, as shown in Figure 2, preservation of
Interface logic, Isolation Wrappers, Clock Chopper
circuit, Power Control logic, Feed-through paths and
IEEE 1500 controller is required.
In Extest Mode pattern generation requires all IPs to
simultaneously be configured in Outward facing mode as
shown in Figure 1. Given the limitations due to the size of
the design, In Extest the Test-View model is used for both
pattern generation and verification.

Figure 2: Test-View of SoC
B. Intest Mode
The SoC is generally partitioned into multiple Intest
Modes, with only a sub-set of IPs being tested concurrently,
both due to IO limitations and power droop considerations.
In Intest Mode, the pattern generation is carried out at IP
level, followed by merging and translation of the patterns to
SoC level. To verify the patterns at SOC, The Test-View
models of IPs-not-under-test are used.
For Intest, only feed-through paths through non-targeted
IPs are required to be preserved as shown in Figure 3.

Figure 3: Test-View of SoC in Intest Mode
C. Single Chain
In order to facilitate scan based debug (scan-dump), each
IP features to stich all sequential elements stitched into a
111 111
single chain. Each IP can be configured into a single chain
using the IEEE controller embedded in that IP. To help
demarcate each IP an 8-Bit marker register is stitched into
the chain. Each IP can also be bypassed with only the 8-Bit
marker register being traced.
The Single Chain verification was done by utilizing a
single chain view of the models, containing only the
marker flops. The verification was carried out by targeting
one IP at a time for single chain trace, while using Test-
View for all other IPs.
D. Considerations
Based on the earlier mentioned consideration a Test-View
of the design can be depicted as shown in Figure 4:

Figure 4: Test-View of an IP
While developing the Test View methodology, these
considerations were required for each test mode, as
elaborated below.
1) Clock Chopper Circuit: Preservation of Clock
chopper Circuits and its controls is required for Intest and
Extest Mode to ensure proper pattern generation and
verification
2) IEEE 1500 Controller: JTAG logic in the design is
required by all 3 test modes, Single Chain, Intest and Extest,
to ensure proper DRC, pattern generation and verification.
3) Power Control: Preservation of power control, which
is imperative for power intent verification, is required for
all 3 test modes.
4) Scan Isolation Wrappers: Preservation of scan
wrappers, dedicated and shared, and their clock and data
connectivity are required to ensure usage in Extest Mode.
5) Feed-through sequential and combinational:
Preservation of Feed-through, both sequential and
combinational is required to verify connectivity of controls
and data to and from different IPs and to SoC.
6) PLL Control: Special consideration done to add
JTAG override for all PLL controls to ensure usage of
Model views of all non-targeted IPs. The PLL controls exist
as a separate IP, which is used as a full-model during
pattern generation and verification.
IV. COMPARISON OF TEST-VIEW MODEL
METHODOLOGIES
Three approaches were considered to generate the Test-
view of IP.
A. Timing Tool Based
Interface Logic Model (ILM) is used to preserve
interface timing arcs in timing Tools. This approach can be
extended to create Test-Views. In this approach a Preserve
attribute is set to the modules of design, intended to be
preserved as elaborated in previous section, to create a Test-
View.
In order to utilize this approach, DFx components like
IEEE1500 Controller, Clock Chopper, EDT and
interconnects between them, have to be preserved through
scripts. This approach yields a significantly smaller ILM
model, but is highly design dependent.
Given the limitations of the above approach and its high
dependence on design, further work, in regards to
benchmarking was not carried out for this approach.
B. Synthesis Tool Based
Design editing capability of the synthesis Tool is
desirable when generating Test-View. In this approach, an
incremental compile is done after removing the CORE flops
in the design. This approach is the most conservative of the
three methods as only the unnecessary logic (core flops) is
removed.
Although this approach yields a robust model, the
disadvantage is the resulting size of the Test-View. In
theory, a smaller model is expected as a compile should
remove any redundant logic. In practice, the synthesis still
maintained the IPs hierarchy of the smaller unused logic
blocks and added internal tie-off cells. Several experiments
were conducted to improve the savings but it is suspected
that the design complexity prevents any further
optimization.
C. Test Tool Based
An ATPG vendor, Mentor Graphics introduced a new
feature to generate Graybox Model for ATPG. A graybox
is a simplified representation of a design tile that contains
only the minimum amount of circuitry required to process
the grayboxed design tile at the next higher level hierarchy.
In this generation process, the Tool traces the extest mode
scan chains based on test setup first, and then performs
graybox logic identification by tracing backward from all
primary output pins and wrapper chains, the Tool marks the
112 112
instances it traverses through the backward tracing and sets
their in_graybox attribute to true.
Ideally, the blocks responsible for test setup (IEEE
1500) are part of this inclusion. The Tool also provides the
user the option to manually preserve hierarchical instances
when needed. Additionally, the Tessent Shell infrastructure
(super set of Tcl) can be used to overwrite in_graybox
attribute. Since we can customize this before or after the
automatic identification, this approach is flexible enough for
more complex designs.
This approach is the most aggressive of the three
methods as all other non-required design structures are
removed. Since all the approaches have capability to add
custom code to handle design complexity, the basis of
comparison relies on the memory footprint and runtime
savings.
The benefit of this approach is that the Tool tends to
produce a significantly reduced graybox model, and a
flexible approach.
The disadvantage of this approach is that logic had to be
additionally preserved. Also as optimization of the design is
carried out to keep the least required logic; extensive
verification is required to ensure the correctness of the
graybox.
V. VERIFICATION OF THE TEST-VIEW MODEL
At the IP level, there were 3 main steps to ensure the
correctness of the graybox model at the point of generation,
as shown in Figure 5.
1) Verify Clock chopper circuits, patterns generated
using Test-Views were simulated against full netlist.
2) Chain trace for Extest and Single Chain mode and
3) To ensure against over-optimization of logic, patterns
generated using full netlist were fault simulated against
Test-View.


Figure 5: Verification flow of Test-View Model
VI. RESULTS RUN TIME SAVINGS AND COMPARISON
A. Design size and memory footprint savings
A comparison of the different approaches in terms of design
size reduction is as discussed below. As expected, the
metrics are dependent on the number of wrapper flops in the
IP. Comparison in terms of Number of Scan Wrappers
(Figure 6), sim gates (Figure 7), and file size in MB of
Test-View Model (Figure 8) and flatten time (Figure 9)
was carried out to benchmark the Synthesis Tool based and
Test Tool based methodology.
Figure 6 shows a comparison of wrapper cells existing as
part of each IP considered for benchmarking, the selection
of IPs was done to have a variable set for comparison.


Figure 6: Number of Wrappers in each IP Considered for
benchmarking.
Sim_gates, shown below is a metric that measures the
design size in number of gates. Here Test-Tool approach
provides improvements ranging from 10% (IP F) of the
original design, to 26 % (IP B) of the original design in
worst case. The synthesis Tool based approach failed to
give significant reduction in most cases, with only one IP
giving reduction of 21%, while in the worst case the
reduction was 92% of the original size.

Figure 7: Benchmarking of sim_gates
113 113
Filesize, shown below is a metric which translates into
memory footprint requirement for compute resources.
Similar to the results observed in sim_gates, the Filesize
reduction was more significant in case of Test Tool
approach, with reduction ranging from 1% (IP E) to
21% (IP B) of the original size. In case of synthesis Tool
the reduction ranged from 31% to 94% of the original
size.

Figure 8: Benchmarking of Filesize in MB
The flatten time, shown below is the time taken by the Tool
to run design rule checks and simulate the initialization
sequence. The data trend observed in terms of Filesize and
sim_gates was observed in flattening runtime. Flattening
time reduction was more significant in case of Test Tool
approach, with reduction ranging from 15% (IP D) to 31%
(IP E) of the original flattening time. In case of synthesis
Tool the reduction ranged from 24% to 78% of the original
flattening time.


Figure 9: Benchmarking of Flatten time (Setup-> ATPG) in sec.
From the above results at IP level, Test Tool based approach
indicates to be the superior approach compared to the
Synthesis Tool approach. The Test-View Models were
generated using the Test Tool to benchmark runtimes and
compute resource requirements at SoC level.
B. Benchmarking for Test Tool Methodology at SoC
The following figures illustrate the results of resource
savings while generating patterns for Extest modes. The
benchmarking is done against the time taken to flatten the
design (setup-atpg) and the time taken to generate the
sample ATPG patterns. The benefit of runtime will be more
obvious when exhaustive patterns are generated.
As Extest Mode requires the complete design to be loaded
into the Tool, benchmarking of Extest Mode was carried out
first. In terms of machine size for full netlist, a compute
resource with 180GB of memory was required, while
with the Greybox model only a 50GB machine memory
allocation was required.
Comparisons below are shown for two extest modes
existing for the APU under consideration. Figure 10 shows
the benchmarking for Extest0 and Figure 11 shows the
benchmarking carried out for Extest1. The benchmarking
was done in terms of flattening runtimes and Sample
patterns generation runtimes.
Up to 3X reduction in flattening runtime was observed
for both the Extest modes, while a reduction of 4.8X was
observed in terms of pattern generation runtime was
observed for Extest0 and a reduction of 6X was observed
in term of pattern generation runtime for Extest1.

Figure 10: Benchmarking of Extest0

Figure 11: Benchmarking of Extest1
For Intest approach significant reductions both in terms of
test time and compute resource requirements were observed
114 114
as discussed in [1] and also shown in Figure 12 for the sake
of completeness of the paper.

Figure 12: Intest Mode Test Time/Compute resource comparison
Here SOC-IP based approach uses the Test-View Models.
C. Project deployment and considerations
As part of deployment to a project, Test-View models also
support the following:
Post tape out activities: Reading an SDC for patterns
generation for application at silicon is currently
supported by the Test Tool with some limitations.
Presently, the Tool is expected to read back the
relevant sections of the SDC, while ignoring
irrelevant constraints for the test mode. Investigations
are undergoing to generate an SDC that contains
exceptions pertinent only to the greybox model.
Diagnosis: With the shrinking size of transistor,
Layout aware diagnosis can speed up finding the root
cause of Silicon failures. However, in previous
projects, the size of the design caused resource
constraints while running Layout Aware Diagnosis.
With the Test-View model based approach, it is
possible to run layout aware diagnosis at IP- level
(after reverse-translation of the failures).
Coverage analysis: Test-View Models were utilized
to report comprehensive coverage of the design as
shown in Figure 13. Here the faults from individual
IP runs can be merged at SoC level by reading them
into a Test-View based flat model. Using the Test-
View based flat model to merge the faults from
different runs significantly reduces compute resource
requirements for fault merging. The top level Extest
pattern can be generated post this merge to get the
final coverage.

Figure 13: Hierarchical Coverage reporting using greybox models.
VII. CONCLUSION
As the Test-View Models are still in a nascent stage,
additional verification will ensure the correctness of the
Test-View Models. The resources for this verification need
to be accounted for in the initial project planning. As the
design approaches tape-out with a rush for time-to-market
during silicon stage, utilization of Test-View can help
address issues with run-time, machine requirements and
debug turn-around time.
The amount of effort to develop the flow and debug
graybox at IP-level is justified in enhancing the quality of
SoC debug.
In conclusion, the limitations associated with growing
design size require new approaches to complete design
verification and post-silicon patterns generation in a
compressed time-to-market cycle and the use of Test-View
provides a viable alternative to the steadily growing
problem.
VIII. REFERENCES
[1] Rahul Shukla, Arie Margulis, Anatoly Normatov Flow Optimization
for ATPG/Diagnosis of AMD High Performance APU, ITC 2013
[2] P. Varma; S. Bhatia;, "A structured test re-use methodology for core-
based system chips," IEEE International Test Conference, Oct. 1998,
pp.294-302.
[3] Tupuri R.S.; Abraham J.A.; Saab D.G.;, "Hierarchical test generation
for systems on a chip", 13th International Conference on VLSI Design,
2000, pp.198-203.
[4]Sravan Kumar Bhaskarani; Rohit Kumar Patel; Supritha Swamy;
Nitinraj Gupta; Manish Arora; Translation of IP TestKompress Patterns to
Chip Level: Issues Faced and Solutions. U2U, 2010


115 115