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

111111

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 IP’s 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

112112

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

113113

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

114114

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

115115