dft HIRARCHY

22
AppNote 6202 Hierarchical DFT Methodology in a FastScan or TestKompress Flow By Rick Fisette Last Modified: April 5, 2006 ©Copyright Mentor Graphics Corporation 1995-2006. All rights reserved. This document contains information that is proprietary to Mentor Graphics® Corporation. The original recipient of this document may duplicate this document in whole or in part for internal business purposes only, provided that this entire notice appears in all copies.In duplicating any part of this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use and distribution of the proprietary information. Trademarks that appear in Mentor Graphics product publications that are not owned by Mentor Graphics are trademarks of their respective owners. 1 Introduction ...................................................................................................................... 2 2. What is Hierarchical DFT?.......................................................................................... 2 2.1 Modular vs. Hierarchical. .................................................................................... 2 2.2 Motivation for Hierarchical DFT ........................................................................ 3 3. Hierarchical DFT Background Information ................................................................ 3 Why register I/Os?................................................................................................... 4 Testing inside the block........................................................................................... 5 How do top level logic and block interconnects get tested?. .................................. 5 What if all my I/Os are NOT registered? ................................................................ 6 Are there any special considerations for At-Speed test? ......................................... 7 Handling the core chains. ........................................................................................ 9 How many chains should there be?. ...................................................................... 10 Block Level Pattern Generation. ........................................................................... 11 4. SOC Level Implementations ..................................................................................... 11 Top Level Logic Insertion. .................................................................................... 11 Building Phase Level Netlists. .............................................................................. 14 SOC Level Pattern Generation. ............................................................................. 14 Rev 1.1 April 5, 2006 Page 1 of 21

description

DFT hirarchy flow

Transcript of dft HIRARCHY

Page 1: dft HIRARCHY

AppNote 6202

Hierarchical DFT Methodology in a FastScan or TestKompress Flow

By Rick Fisette Last Modified: April 5, 2006

©Copyright Mentor Graphics Corporation 1995-2006. All rights reserved.

This document contains information that is proprietary to Mentor Graphics® Corporation. The original recipient of this document may duplicate this document in whole or in part for internal business purposes only, provided that this entire notice appears in all copies.In duplicating any part of this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use and distribution of the proprietary information.

Trademarks that appear in Mentor Graphics product publications that are not owned by Mentor Graphics are trademarks of their respective owners.

1 Introduction ......................................................................................................................2 2. What is Hierarchical DFT?..........................................................................................2

2.1 Modular vs. Hierarchical.....................................................................................2 2.2 Motivation for Hierarchical DFT ........................................................................3

3. Hierarchical DFT Background Information ................................................................3 Why register I/Os?...................................................................................................4 Testing inside the block...........................................................................................5 How do top level logic and block interconnects get tested?. ..................................5 What if all my I/Os are NOT registered? ................................................................6 Are there any special considerations for At-Speed test?.........................................7 Handling the core chains. ........................................................................................9 How many chains should there be?. ......................................................................10 Block Level Pattern Generation. ...........................................................................11

4. SOC Level Implementations .....................................................................................11 Top Level Logic Insertion.....................................................................................11 Building Phase Level Netlists. ..............................................................................14 SOC Level Pattern Generation. .............................................................................14

Rev 1.1 April 5, 2006 Page 1 of 21

Page 2: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 2 of 21

5. Block Level Scan Chain Insertion.............................................................................14 Partition Chain Insertion .......................................................................................15 Core Chain Insertion .............................................................................................15

6. TestKompress Insertion.............................................................................................16 7. SOC Level Integration...............................................................................................16 8. SOC Level Pattern Generation ..................................................................................17

8.1 Building Phase Level Netlists ...........................................................................17 8.2 Stuck-at Pattern Generation ..............................................................................17 8.3 Transition Pattern Generation ...........................................................................19 8.4 Top Level Fault Grade ......................................................................................20

9. Pattern Verification ...................................................................................................21 10. Conclusions ...........................................................................................................22

1. Introduction – This app note describes one manner in which Hierarchical DFT can be implemented in a block-based design flow. Section 2 What is Hierarchical DFT? will provide a definition of hierarchical DFT, why it is being implemented and some of the costs and benefits. Section 3 Hierarchical DFT Background Information will go into detail on how testing hierarchically is different from more traditional approaches and what DFT features must be implemented at the block level. Section 4 SOC Level Implementations will go into more detail on what features need to be implemented at the SOC level. For those who wish to skip the background information contained in the first fours sections, Section 5 Block Level Scan Chain Insertion will provide sample dofiles and test procedure files for use in DFTAdvisor. These examples will demonstrate how the scan chains should be inserted at the block level. Section 6 TestKompress Insertion will cover specific TestKompress commands needed in a hierarchical flow. Section 7 SOC Level Integration will address the integration of blocks at the SOC level. Pattern generation (both stuck-at and transition) is described with example scripts in Section 8 SOC Level Pattern Generation . Pattern Verification is briefly addressed in Section 9. The Conclusions section will summarize the benefits of a hierarchical approach to DFT and the additional work required over a more traditional approach. 2. What is Hierarchical DFT? – Hierarchical DFT implies many things but fundamentally

it refers to inserting DFT at the block level in a manner that makes chip level integration of DFT easier.

2.1 Modular vs. Hierarchical – Modular applies only to TestKompress implementations

and is slightly different from hierarchical. The modular capability of TestKompress allows the user to put a complete TestKompress engine inside a block in the IP generation phase. An SOC design would contain multiple blocks with multiple, different TestKompress configurations. In the pattern generation phase, modular TestKompress generates patterns for all the blocks simultaneously. This implies that all the TestKompress channels for each block are wired more or less directly to the SOC pins.

Hierarchical is differentiated from modular in that additional block level work is done to isolate blocks from one another. This allows blocks to share SOC level pins for scan chain access. Blocks can be tested individually (in a serial fashion) or in groups of blocks. When implementing TestKompress in a hierarchical SOC design, modular TestKompress is employed in order to be able to test multiple blocks at a time but it is not necessary to test ALL the blocks simultaneously. Hierarchical DFT techniques can also be used in a non-TestKompress (i.e. traditional) scan/ATPG flow.

Page 3: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 3 of 21

2.2 Motivation for Hierarchical DFT - The motivation for doing this work at the block level is to stay consistent with the rest of the steps in the design flow (RTL, synthesis and layout) which are also done at the block level. Hierarchical DFT also provides a framework which allows cores to be re-used in other designs. Here is a more complete list of the benefits of this DFT flow:

• Flow compatibility with other design steps makes scheduling the completion of DFT tasks more predictable

• Allows for core re-use across multiple SOC design teams • Reduced tool capacity requirements • Faster tool runtime • ECOs (Engineering Change Orders) on individual blocks only require new test

patterns for those blocks. Pattern sets for other blocks are not affected. • Lower power consumption on tester by testing individual blocks or small groups

of blocks • Block isolation results in quicker identification of problems on the tester • Masking problem blocks on the tester (e.g. to address scan chain shift timing

problems) only affect that block. Other isolated blocks are still fully tested. This is particularly valuable when screening initial prototype parts.

• Faster production test time.

Some of the costs associated with this approach include: • More rigidly enforced design practices • Additional up-front planning for DFT • Additional top level routing overhead

3. Hierarchical DFT Background Information – This section covers the details of

what is required for hierarchical DFT at the block level and the SOC level. The specific Hierarchical DFT methodology presented in this App Note assumes that the customer’s hierarchical design flow has the following characteristics:

• Blocks are physically laid out individually as hardmacs • The I/O ports of these hardmac blocks are registered by design • Hardmac blocks are then assembled at the chip level • There may or may not be glue logic at the chip level

Figure 1 illustrates the physical design view of a hierarchically designed SOC.

Page 4: dft HIRARCHY

Block 1

Block 2

Block 3

Block 4

Block 5

Block 6

Block 7

Block 8

Block 9 Block 10Block 11 Block 12

Top Level Logic 2

Top Level Logic 1 Clock Gen.

Test Control

Physical Design View

Figure 1 Hierarchical Physical Design

Why register I/Os? - One increasingly common design technique being used in hierarchical designs is to register all the I/O ports of each block. The benefit of this practice is that all the timing inside the block is based on these registration points at the I/O. This eliminates dependencies on the delays outside of the block allowing the designer to complete work on the block before the rest of the chip is completely designed. The hierarchical DFT approach described in this application note takes advantage of this design practice and assigns these I/O registers to one or more scan chains referred to as Partition Scan chains. Signals like clocks, resets and static test control signals are not registered but are controlled from chip level pins.

Figure 2 illustrates what the scan chains would look like in a block that has followed these hierarchical design guidelines.

Rev 1.1 April 5, 2006 Page 4 of 21

Page 5: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 5 of 21

Core Scan Partitio

ScaChai

FunctionaI/O

Registere

Core

FunctionaI/O

Registere

Functional I/O Ports

Block Level Scan Insertion

Figure 2 - Hierarchical Scan Insertion at Block Level

Testing inside the block - The partition scan chains act as an isolation ring around the block. The result of isolating the block is that the controllability and obsevability of faults in the block have no dependencies on logic outside of the block. When testing a block hierarchically (i.e. testing a block in isolation while it’s embedded in a chip) there is no direct access to the block’s I/O ports. There is only access through the scan chains. The partition chains serve to launch values into the block (from the input partition cells) and capture values coming out of the block (with the output partition cells). When running ATPG at the block level (before embedding into the chip) be sure to ignore functional inputs and mask functional outputs and use scan chain access only. This emulates exactly the access one would have to the block once it gets embedded in the chip. Test coverage results achieved in this manner duplicates exactly the coverage one would get from the chip level regardless of how it is integrated. The Partition chains guard against any control/observe issues that could come from outside the block. How do top level logic and block interconnects get tested? – The Partition chains also enable the testing of logic and interconnects outside of the block. In this case the roles of input and output partition cells reverse as shown in Figure 3. Input Partition cells now capture data (from

Page 6: dft HIRARCHY

top level logic and other blocks) and output Partition cells launch data (to be captured by top level logic or the input Partition cells of other blocks).

Output Partition Chain

Input Partition Chain

Top Level Glue Logic

Top Level Glue Logic

Figure 3 - Testing Top Level Logic and Interconnects

What if all my I/Os are NOT registered? – This methodology is most effective when all the I/O ports of the block (with the exception of clocks, resets and test control signals which are best comtrolled directly from the chip level pins) are registered. There is some tolerance though of logic between an I/O port and the first/last point of registration. This “outlier” logic, as shown in Figure 4 would sit outside of the Partition chains and would be caught during chip level testing. The benefits of the methodology are significantly reduced if this occurs on too many I/O because the Partition Chains become unmanageably large and too much outlier logic gets pushed to the top level for testing.

Rev 1.1 April 5, 2006 Page 6 of 21

Page 7: dft HIRARCHY

Output Partition Chain

Input Partition Chain

Top Level Glue Logic

Top Level Glue LogicOutlier

Logic

Outlier Logic

Figure 4 - Non-Registered I/Os and Outlier Logic

Are there any special considerations for At-Speed test? – At-speed testing in a hierarchical manner requires some special handling in how the partition chains get inserted. In order to implement a typical at-speed test pattern (either transition or path delay) it is necessary to provide two at-speed clock pulses to cause a transition from a Launch register and be captured at an endpoint being the Capture register. Scan based at-speed patterns require three registers in order to implement this type of pattern. This would include the Launch and Capture registers already mentioned but it is also necessary that a third “Transition” register be able to provide the transition value to the D input of the Launch register. Figure 5 illustrates how a 0 to 1 transition is detected at the input of U2 by loading a 0 into the launch flop and a 1 into the transition origin flop through the scan chain. Using the broadside technique, the first non-shifting pulse captures the 0 into the capture flop. Next, the second at-speed pulse captures the 1 that started from the transition flop and was propogated through the launch flop.

Launch Flop Capture FlopTransition Origin

U21 0U1

States after loading scan chain and before two at-speed clocks

FF3

QD SI

SE

FF1

QD

SI

SE

FF2 Q D

SI SE

QB QB QB

Figure 5 - Typical Transition Pattern Scenario

The problem with hierarchical at-speed test arises at the boundaries of the block as shown in Figure 6. If an input Partition scan cell is the Launch register then there’s no transition register

Rev 1.1 April 5, 2006 Page 7 of 21

Page 8: dft HIRARCHY

behind it to provide the transition value. The result is that all the logic between the input partition cell and the next point of registration cannot be tested for at-speed defects.

Launch Capture

U2X 0

Cannot detect at-speed defects between input register and next level of registration

Input Port

FF

QDSI

SE

FF

QD

SI

SE

QQ

Figure 6 - Transition testing at Hierarchical Boundary

One way to get around this problem is to re-use the input Partition scan chain itself to provide the Transition register as in Figure 7. This is accomplished by holding scan_enable active, for the input Partition chain only, during the at-speed launch and capture pulses. At the same time the output Partition scan cells are acting as Capture registers therefore their scan_enable signal must go inactive as is normal. Because scan_enable for input Partition cells needs to be at a value opposite to the output cells, it is necessary to have separate scan_enable signals for each as well as a third scan_enable for the core scan chains which always behaves like a normal scan_enable.

Launch Flop Capture Flop

U2X 0

When testing inside a block, previous input partition scan cell serves as the transition origin so long as SE is held active during capture. SE for core and output partition cells must be inactive in order to capture.

Input Port

FF1 Q D

SI SE

Transition Origin

X Input Port

FF1 Q D

SI SE

QB

QB FF2

QD

SI

SE

QB

1

1 Output

Port

1

0

FF2 Q D

SI SE

QB 0

Core Logic

Figure 7 - Using Partition Cells for Transition Testing

When doing at-speed testing for logic and interconnects outside of the block, the input and output partition cells reverse roles. Figure 8 shows how input partition cells act as capture registers (scan_enable inactive) and output Partition cells are Launch registers requiring a transition register behind them to provide the transition value.

Rev 1.1 April 5, 2006 Page 8 of 21

Page 9: dft HIRARCHY

Launch FlopCapture Flop

X 0

FF1

QD SI SE

Transition Origin

X FF1

QD SI SE

QB

QB

FF2 Q D

SI

SE

QB

1

1 Output

Port

1

0

Core Logic

Core Logic Top Level Glue Logic

Input Port

Figure 8 - Transition Testing Outside the Block

Re-using the partition scan chains to provide a transition register requires that there always be a scan cell behind each Partition cell. This is always the case except for the very first partition cell in the chain which is driven from the tester. To get around this problem an extra “lock-up” register is inserted at the beginning of partition chain as in Figure 9. It’s similar in behavior to a “lock-up” latch used in scan chains, in this case though it must be a register. Since it is only in the scan path it has no functional impact. It serves no purpose for stuck-at testing but it also does no harm. Its purpose is to serve as the transition register for what would otherwise be considered the first scan cell of a Partition Chain

Launch Flop Capture Flop

U2X 0

Input Port

FF1

QD

SI

SE

Transition Origin

PartitionScan

Chain Input QD

QB

QB

FF2

QD

SI

SE

QB

1

1 0

Core Logic

Figure 9 - Partition Chain Inputs

Handling the core chains – After identifying and inserting the partition scan chains, the remaining registers are assigned to core chains. There needs to be a distinct scan_enable signal

Rev 1.1 April 5, 2006 Page 9 of 21

Page 10: dft HIRARCHY

for the core chains separate from the two scan_enables used for the input and output partition chains. The behavior of this signal though is the same as for normal scan chains for both stuck-at and at-speed patterns. How many chains should there be? – The number of partition and core chains is driven by the same planning process as is used for non-hierarchical implementations. If it is a normal ATPG flow you target whatever number of chip level pins are available for scan. The difference being that in a hierarchical implementation you may have more chip level pins to use because the resources can be shared across all the blocks. In a TestKompress flow, the number of chains is driven by the compression goals and the ratio of channels to chains being targeted. In all cases, partition and core chains should be as balanced in length as possible.

Figure 2 illustrated a very simple partition scan chain implementation. Figure 10 is a more accurate representation of what the block level chains would look like after addressing the at-speed requirements for partition scan chain insertion. For convenience purposes the core chains shown are not balanced with the partition chains but the assumption is that you would balance them.

Rev 1.1 April 5, 2006 Page 10 of 21

Combinational

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

FF

Scan_in1 Scan_out4

FF

FF

FF

FF

FF

FF

FF

Scan_in4

Scan_out3

Scan_in3

Scan_in2

Scan_out1

Scan_out2 Scan_out6Scan_in6

Scan_out7 Scan_in7Scan_out5can_in5SScan_en

Outputreg_scan_en Inputreg_scan_en

D SD SE CK

Q QB

D SD SE CK

Q QB

D SD SE CK

Q QB

D SD SE CK

Q QB

D SD SE CK

Q QB

D SD SE CK

Q QB

D SD SE CK

Q QB

D SD SE CK

Q QB

Page 11: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 11 of 21

Figure 10 - At-Speed Ready Partition Chains

Block Level Pattern Generation – Patterns should be generated at the block level in order to determine if there are any test coverage issues and also to get an idea of how much tester memory will be required to test the block. Be sure to constrain all functional inputs to CX and mask all functional outputs. By using just the scan chain access to the block you mimic the same control and observe conditions as when the block is embedded in the SOC. The test coverage achieved at this point accurately reflects what it will be in the SOC. By determining the amount of tester memory required for each block, a fairly good estimate of the total SOC tester memory requirements can be achieved by adding up all the block level requirements. So long as the amount of top level glue logic is not large, this estimate is useable for planning purposes relatively early in the SOC schedule.

4. SOC Level Implementations – Once all the block level work is done to provide

isolation, there are a number of chip level implementations that can be employed to take advantage of that effort. What is described here is a method by which blocks can be tested either individually or in groups by sharing chip level scan chains through some muxing logic. This approach will be referred to as serial test scheduling.

Top Level Logic Insertion – To implement serial test scheduling, it is necessary for the SOC level designer to create and insert muxing logic to control access from scan chain/channel outputs to chip level outputs and a decoder block to control the mux selection. Chip level inputs need to be wired in parallel to the scan chain/channel inputs of each block as well as the muxing and decode logic. At this time, this is a manual, user-defined process. Since this logic is not complex, some customers just treat this as another top level function and implement it in the top level RTL. Figure 11 represents how the SOC design from Figure 1 would look when the blocks are scanned hierarchically and top level muxing logic is added to share chip level scan chains.

Page 12: dft HIRARCHY

Block 1

Block 2

Block 3

Block 4

Block 5

Block 6

Block 7

Block 8

Block 9 Block 10Block 11 Block 12

Top Level Logic 2

Chain1 Chain2 Chain3 Chain4

Chain8Chain7Chain6Chain5

Scan_phase_sel(2:0)

Top Level Logic 1 Clock Gen.

Test Control

Figure 11 - Sharing Chip Level Scan Chains

With this implementation, it is possible to maximize the number of chip level chains that connect to each of the blocks. Blocks are tested individually or in groups by reconfiguring the mux select lines of the top level mux logic. The mux select settings define the “phase” being tested. For instance Phase 0 is defined as testing Block 1 and Block 2 as shown in Figure 12. The “white space” in this figure represents the blocks whose netlists were not read in. The tool automatically black-boxes these blocks.

Rev 1.1 April 5, 2006 Page 12 of 21

Page 13: dft HIRARCHY

Block 1

Block 2

Top Level Logic 2

Chain1 Chain2 Chain3 Chain4

Chain8Chain7Chain6Chain5

Scan_phase_sel(2:0) = 000

Top Level Logic 1 Clock Gen.

Test Control

Figure 12 - Phase0 Tests Blocks 1 & 2

The top level logic must be present because it contains test control logic and clock generation logic but it is not tested in this phase. Each phase progresses in the same manner, targeting different blocks each time. Figure 13 shows how top level logic and block level interconnects are be targeted in the final phase in which only the top level scan chains and the partition chains of each block are accessed.

Rev 1.1 April 5, 2006 Page 13 of 21

Page 14: dft HIRARCHY

Scan_phase_sel(2:0) = 110

Block 1

Block 2

Block 3

Block 4

Block 5

Block 6

Block 7

Block 8

Block 9 Block 10Block 11 Block 12

Top Level Logic 2

Chain1 Chain2 Chain3 Chain4

Chain8Chain7Chain6Chain5

Top Level Logic 1 Clock Gen.

Test Control

Figure 13 - Testing Top Level Logic & Interconnects

The result of this pattern generation process is a number of scan pattern sets matching the number of phases.

Building Phase Level Netlists – One characteristic of hierarchical design flows is that the SOC level netlist typically consists of just instantiations of the lower level blocks along with the top level logic. The actual definitions of the blocks exist as separate netlists. When generating patterns for a given phase it’s only necessary to read the top level netlist and the netlists of the blocks targeted for that phase. By not reading in the non-targeted blocks for that phase and allowing the tool to auto black box them, tool runtime is significantly improved and capacity is also not a problem. The presence of a potentially large number of black boxes (X sources) does not affect the testing of the blocks because the partition chains act as isolation collars.

SOC Level Pattern Generation – Re-using block level generated patterns at the chip level (also known as pattern re-use) is not tool supported at this time. It is necessary to regenerate patterns from the chip level pins. In this hierarchical design scenario, separate pattern sets are generated for each phase. Block level dofiles and test procedure files most likely cannot be used at the chip level. The user needs to manually create these files ensuring that the chip level test modes are initialized properly and clocks and control signals are mapped to chip level pins. Once these files are generated for a single phase, the other phases only require slight modifications to reconfigure the mux selection logic.

5. Block Level Scan Chain Insertion– This section provides details on how to insert

partition chains and core chains for hierarchical DFT as described in the previous section. The important DFTAdvisor commands are highlighted and a sample dofile is given.

Rev 1.1 April 5, 2006 Page 14 of 21

Page 15: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 15 of 21

DFTAdvisor has the ability to identify and insert partition chains. Recent enhancements have been made to support the specific structure required for hierarchical testing. The specific command used to do this is as follows: SETup PArtition SCan [-EXClude <pin_name ….>] [-INPUT_NUMber <integer> | -INPUT_MAX_length <integer>] [-OUTPUT_NUMber <integer> | -OUTPUT_MAX_length <integer>] [-INPUT_SEN <name>] [-OUTPUT_SEN <name>] Defined clocks and constrained pins are automatically excluded from the Partition chains. This command can exclude any other I/Os using the –EXClude switch. In order to achieve properly balanced scan chains it may be necessary to have multiple input and output Partition chains. This is achieved by using the –INPUT_NUMber or –INPUT_MAX_length for the input Partition chains and –OUTPUT_NUMber or –OUTPUT_MAX_length for the output Partition chains. Partition Chain Insertion - It is necessary to perform scan insertion in two passes. The first pass will insert the Partition Scan Chains and then a subsequent pass will target the rest of the scan cells in the “core” of the block. When running this second pass of scan insertion it is necessary to specify the Partition Chains inserted in the first pass so that the scan cells on these chains are ignored during the second pass of scan insertion and that a final “ATPG Setup” can be properly generated. What follows is an example dofile to insert the partition scan chains:

add clock 0 clk1 add clock 0 clk2 add pin constraint test_enable c1 add cell model LATX –type dlat G D add cell model INVX –type inv set lockup latch on setup partition scan –exclude in1 in2 -input_num 4 \

-output_num 4 \ -input_sen input_partition_scan_en \ -output_sen output_partition_scan_en

set system mode dft run insert test logic –balance_subchain –clock merge \

–edge merge –output new report scan chains report test logic write atpg setup partition_chains –replace write netlist block_partition_chains.v –verilog –replace exit

Core Chain Insertion -Next step is to re-invoke DFTAdvisor on the block_partition_chains.v netlist to insert the core chains. Use the setup dofile generated during the partition chain insertion run in order to identify the existing partition chains. Here is what the core scan chain insertion dofile would look like:

dofile partition_chains.dofile

Page 16: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 16 of 21

set system mode dft setup scan identification full_scan //full_scan is default run insert test logic –clock merge –edge merge \

–max 100 –output new report scan chains report test logic write netlist block_full_scan.v –verilog -replace write atpg setup block_full_scan –replace exit

With the scan inserted for the partition chains and core chains of the block in this manner, the block is ready for either TestKompress insertion or, in a non-TestKompress flow, integration at the SOC level.

6. TestKompress Insertion – The insertion of TestKompress would be done in the same

manner as in a non-hierarchical flow. Use the same guidelines to determine the number of chains and channels to target the desired compression. The partition chains and core chains should add up to the desired number of internal chains and they should be as closely balanced as possible. The only additional hierarchical requirement is to be able to access the partition chains for top level testing. This is accomplished by specifically assigning the partition chains to a channel when in bypass mode. The “set bypass chains” command specifies this during the IP creation phase of TestKompress. The following example is for a design with 12 internal chains and 3 external channels. Chains1 through 4 are the partition chains:

//channel 1 will access all the partition chains //when in bypass mode set bypass chains -bypass_chain 1 -edt_chains \ chain1 \ chain2 \ chain3 \ chain4 //TestKompress requires that all chains be specified //for bypass mode set bypass chains -bypass_chain 2 -edt_chains \ chain5 \ chain6 \ chain7 \ chain8 set bypass chains -bypass_chain 3 -edt_chains \ chain9 \ chain10 \ chain11 \ chain12

Even though the partition chains are only on chains1-4, it is still necessary to specify how all the chains are configured when in bypass mode. When performing top level testing, edt_bypass is asserted on all the blocks so that the partition chains can be accessed.

7. SOC Level Integration – The insertion and integration of the SOC level logic to select

the block level scan chains in phases is a manual process. All block level input scan chains

Page 17: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 17 of 21

(channels in TestKompress flow) are driven in parallel from the SOC input pins. The block level output chains/channels go through muxing logic before connecting to the SOC output pins. Control of the mux selection can be done via direct SOC input pins or by loading internal registers. Other features to consider would be tying the scan inputs of non-targeted blocks to a constant value in order to reduce power consumption during shifting.

8. SOC Level Pattern Generation – This section describes how to “build” phase level

netlists when invoking FastScan or TestKompress. Example dofiles and test procedure files are shown for stuck-at pattern generation and transition pattern generation. Since pattern re-use is not automated by the tools at this time, it is necessary to regenerate all patterns from the SOC level. One advantage to the hierarchical division of the design is that the pattern generation for multiple phases can be run simultaneously. Even though the patterns may be delivered on the tester in a serial fashion, the pattern generation for each phase can be run in parallel.

8.1 Building Phase Level Netlists – A significant reduction in machine capacity and ATPG

tool runtime can be realized by “building” a different netlist for each phase that contains only the descriptions for blocks being targeted in that phase. It is not necessary to actually create separate netlists, this can be achieved by selectively loading block level netlists when invoking the tool. The assumption here is that the SOC level netlist contains the complete definition of all top level logic but only instantiations of the blocks. Block level descriptions exist as separate, stand-alone netlists. The following example shows how FastScan should be invoked to test the first phase of pattern generation which target blocks 1 and 2 as illustrated in Figure 12:

$MGC_HOME/bin/fastscan \ ./netlists/soc_level.v \ ./netlists/block1.v \ ./netlists/block2.v \ -verilog \ -top soc_chip \ -lib ./libs/tsmc13.mdt \ -dofile ./dofiles/phase0_stuck_at.dofile \ -log ./logs/phase0_stuck_at.log \ -replace \ -nogui The key points are that the top level description must be included (soc_level.v) as well as the targeted blocks (block1.v and block2.v). What is not shown is that the verilog descriptions for blocks 3-12 are excluded and therefore must be black-boxed once in the tool. Be sure to specify the correct top module as well. Subsequent phases would be invoked in the same manner. The soc_level.v must always be included but different block level netlists will be substituted. For the top level testing phase, all netlists must be included.

8.2 Stuck-at Pattern Generation – The dofile required for pattern generation (either FastScan or TestKompress) has a couple extra requirements associated with the hierarchical implementation. The following dofile carries forward the same example shown for building the phase level netlists. This phase0_stuck_at.dofile generates stuck-at patterns for phase0 which targets blocks1 and 2. The hierarchical specific commands are highlighted in green:

Page 18: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 18 of 21

//black box any blocks not included in tool invocation //set black box outputs to “Z” to avoid contention add black box -auto z add scan groups grp1 ./scripts/phase0.testproc add scan chains chain0 grp1 scan_in[0] scan_out[0] add scan chains chain1 grp1 scan_in[1] scan_out[1] add scan chains chain2 grp1 scan_in[2] scan_out[2] add scan chains chain3 grp1 scan_in[3] scan_out[3] add scan chains chain4 grp1 scan_in[4] scan_out[4] add scan chains chain5 grp1 scan_in[5] scan_out[5] add scan chains chain6 grp1 scan_in[6] scan_out[6] add scan chains chain7 grp1 scan_in[7] scan_out[7] add scan chains chain8 grp1 scan_in[8] scan_out[8] //set phase selection to phase0 to access blocks1 & 2 only Add pin constraint scan_phase_sel[0] C0 Add pin constraint scan_phase_sel[1] C0 Add pin constraint scan_phase_sel[2] C0 Add clock 0 clka Add clock 0 clkb Set system mode atpg Create patterns –auto Report statistics Save patterns ./patterns/phase0_stuck_at.WGL –wgl \

–parallel –replace //save a list of detected faults for //top level fault grading write faults ./fault_lists/phase0_stuck_at_dt.gz \ -class dt -replace Exit

The corresponding test procedure file would look like this:

set time scale 1.000000 ns ; timeplate gen_tp2 = force_pi 0 ; measure_po 10 ; pulse clka 20 10; pulse clkb 20 10; period 40 ; end; procedure test_setup = timeplate gen_tp2 ; cycle = force scan_phase_sel[0] 0 ; force scan_phase_sel[1] 0 ; force scan_phase_sel[2] 0 ;

Page 19: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 19 of 21

end; end; procedure shift = scan_group grp1 ; timeplate gen_tp2 ; cycle = force_sci ; force edt_update 0; measure_sco ; pulse clka ; pulse clkb ; end; end; procedure load_unload = scan_group grp1 ; timeplate gen_tp2 ; cycle = force clka 0 ; force clkb 0 ; //all scan_enable signals must be active //in order to shift force scan_en 1 ; force input_partition_scan_en 1 ; force output_partition_scan_en 1 ; end ; apply shift 200; end;

Each phase requires a separate dofile and test procedure file. The only thing that changes for each phase are the pin constraints for the phase_select signals. A corresponding change must be made in the test_setup portion of the test procedure file. Note that if Engineering Change Orders (ECOs) are performed on a particular block, it is only necessary to regenerate patterns for the phases that contain that block. You do not have to regenerate all the patterns.

8.3 Transition Pattern Generation – For transition patterns there are additional

requirements to constrain the input_partition_scan_en active when testing at the block level and constrain output_partition_scan_en active when testing the top level logic and interconnects. The “CT” constraint should be used for these signals because SE is not expected to run at functional frequencies therefore it should be removed from the fault list. When automatically black-boxing blocks, use the “-auto Z” option. Since the tool cannot always distinguish inputs from outputs, using the “Z” option avoids a situation in which a black box may try to drive what it thinks is a bus with an “X” value and possibly resulting in tracing rule violations. The following dofile example is for Phase0 transition patterns:

//black box any blocks not included in tool invocation //set black box outputs to “Z” to avoid contention add black box -auto z add scan groups grp1 ./scripts/phase0.testproc

Page 20: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 20 of 21

add scan chains chain0 grp1 scan_in[0] scan_out[0] add scan chains chain1 grp1 scan_in[1] scan_out[1] add scan chains chain2 grp1 scan_in[2] scan_out[2] add scan chains chain3 grp1 scan_in[3] scan_out[3] add scan chains chain4 grp1 scan_in[4] scan_out[4] add scan chains chain5 grp1 scan_in[5] scan_out[5] add scan chains chain6 grp1 scan_in[6] scan_out[6] add scan chains chain7 grp1 scan_in[7] scan_out[7] add scan chains chain8 grp1 scan_in[8] scan_out[8] //set phase selection to phase0 to access blocks1 & 2 only Add pin constraint scan_phase_sel[0] C0 Add pin constraint scan_phase_sel[1] C0 Add pin constraint scan_phase_sel[2] C0 //For block level transition testing, hold //the input_partition_scan_en signal active Add pin constraint input_partition_scan_en CT1 //If this were the top level phase of testing, //remove the constraint on input_partition_scan_en //and replace with the following: // Add pin constraint output_partition_scan_en CT1 Add clock 0 clka Add clock 0 clkb Set system mode atpg Set fault type transition Set pattern type sequential –depth 2 Set transition holdpi on Set output mask on Create patterns Report statistics Save patterns ./patterns/phase0_transition.WGL –wgl \

–parallel –replace //save a list of detected faults for //top level fault grading write faults ./fault_lists/phase0_transition_dt.gz \ -class dt -replace Exit

The corresponding test procedure file would only have to add a force statement for the input/output_partition_scan_en signal in the test_setup portion in order to match the constraint.

8.4 Top Level Fault Grade – Since each phase of pattern generation is performed on a

portion of the total chip netlist, you don’t know what the fault grade is for the entire chip. To do this you need to run a separate FastScan/TestKompress session. You would invoke the tool the same way you would when generating patterns for top level testing (i.e. loading in the entire netlist). This session doesn’t actually generate any patterns, it

Page 21: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 21 of 21

just loads in the various fault lists generated for each phase. The key is to use the “-protect” switch so that detected faults don’t get overwritten as AU faults in a subsequent phase. The tool takes care of summing up the test coverage for the entire design. Here is an example dofile for running the top level fault grade for stuck-at faults:

add scan groups grp1 ./scripts/phase0.testproc add scan chains chain0 grp1 scan_in[0] scan_out[0] add scan chains chain1 grp1 scan_in[1] scan_out[1] add scan chains chain2 grp1 scan_in[2] scan_out[2] add scan chains chain3 grp1 scan_in[3] scan_out[3] add scan chains chain4 grp1 scan_in[4] scan_out[4] add scan chains chain5 grp1 scan_in[5] scan_out[5] add scan chains chain6 grp1 scan_in[6] scan_out[6] add scan chains chain7 grp1 scan_in[7] scan_out[7] add scan chains chain8 grp1 scan_in[8] scan_out[8] //For the fault grade run, it doesn’t matter which //phase is selected, give it any constraints just //so you can get through DRCs Add pin constraint scan_phase_sel[0] C0 Add pin constraint scan_phase_sel[1] C0 Add pin constraint scan_phase_sel[2] C0 Add clock 0 clka Add clock 0 clkb Set system mode atpg Set fault type stuck Add faults -all //load the detected fault list in from each phase load faults ./fault_lists/phase0_stuck_at_dt.gz \ -protect load faults ./fault_lists/phase1_stuck_at_dt.gz \ -protect . . . load faults ./fault_lists/phase12_stuck_at_dt.gz \ -protect //report statistics to show final fault grade Report statistics Exit

The same process is used for transition faults as well, just change the fault type to transition.

9. Pattern Verification – Gate level simulation with timing back-annotated can benefit from

the same flow used for pattern generation. By black boxing non-targeted blocks in the simulator, the simulation times are significantly reduced.

Page 22: dft HIRARCHY

Rev 1.1 April 5, 2006 Page 22 of 21

10. Conclusions – There are many variations on how a hierarchical DFT methodology can be implemented. This application note is intended to show one of those variations and how the DFT tools support this particular flow. For block level tasks, there is a high level of tool automation in DFTAdvisor to properly insert the scan chains and in TestKompress as well if that is part of the flow. The top level logic required for muxing the scan chain/channel access is simple in concept but there is currently no tool automation to generate or integrate that logic. Pattern generation is broken up into several phases and has some additional pin constraints to be considered particularly with regard to at-speed testing.

The primary benefit of this methodology is the ability to finalize DFT tasks earlier in the schedule of a hierarchically designed SOC. Core re-use is also simplified because it is no longer necessary to balance scan chains between blocks if they are tested individually. Test quality goals, and even functional requirements, are often sacrificed in order to meet schedule. Completing DFT before it gets in the critical schedule path means test quality goals need not be compromised. Additional benefits of this hierarchical approach include reduced tool capacity requirements, faster tool runtime, less impact from late ECOs, quicker verification process and easier debug on the tester.