Asynchronous Occ

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

Gao Qiang Himanshu Kukreja Jovin Basil Roy J

Lantiq Asia Pacific Pte Ltd Singapore www.lantiq.com

ABSTRACT High transition delay coverage is utmost priority in current complex designs to improve the test quality. Conventionally the faults between two OCC domains are not considered for the transition delay test. The default OCC structure and ATPG flow support faults which belong to only one clock domain. When there is a timing requirement between different clock domains, those faults must be tested. This requires some modification for OCC structure or insertion of synchronous OCC IP. The paper describes this novel DFT concept used to test the inter clock domain faults using the asynchronous OCC IP and modification of ATPG. This approach also enabled us to target the critical paths across clock domains using path delay fault model

SNUG 2014

1

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

Table of Contents 1. 2.

3.

4. 5.

Introduction .............................................................................................................................. 4 OCC structure and principle .................................................................................................... 4 2.1 Basic structure and principle of OCC ........................................................................... 4 2.2 Details of at-speed clock pulse generation ................................................................... 6 Cross clock domains faults testing using Asynchronous-OCC ............................................... 7 3.1 Enhancement for Asynchronous-OCC ......................................................................... 9 3.2 SPF Modification ........................................................................................................ 10 3.3 ATPG and Simulation result....................................................................................... 10 3.3.1 Pattern AB result ............................................................................................. 11 3.3.2 Pattern BA result ............................................................................................. 12 3.3.3 Pattern A result ................................................................................................ 12 3.3.4 Pattern B result ................................................................................................ 13 3.4 Coverage improvement............................................................................................... 14 Conclusion ............................................................................................................................. 14 References .............................................................................................................................. 14

Table of Figures Figure 1 Design before OCC insertion ................................................................................... 5 Figure 2 Design after OCC insertion ...................................................................................... 5 Figure 3 at-speed clock pulse generation ................................................................................ 6 Figure 4 waveform of clock pulse generation......................................................................... 6 Figure 5 Example of 2 clock domains with divider ................................................................ 7 Figure 6 Two synchronous clocks with two OCC .................................................................. 8 Figure 7 2 OCCs start to run at different time ........................................................................ 8 Figure 8 2 OCCs start to run at the same time ........................................................................ 8 Figure 9 Proposed Enhancement in OCC connection............................................................. 9 Figure 10 Launch by CLK_A(clk_500), captured by CLK_B(clk_250) .............................. 11 Figure 11 Launched by CLK_B(clk_250), captured by CLK_A(clk_500) .......................... 12 Figure 12 Launch and captured by CLK_A(clk_500) .......................................................... 13 Figure 13 Launch and captured by CLK_B(clk_250) .......................................................... 13 Figure 14 coverage comparison between 2 types of OCC .................................................... 14

SNUG 2014

2

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

SNUG 2014

3

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

1. Introduction The transition-delay fault (TDF) model is used to detect slow-to-rise and slow-to-fall fault on the nodes. TDF fault means that a transition from 0 to 1 or from 1 to 0 on the node does not produce the correct results at the maximum operating speed of the device. So it requires the accurate application of two high-speed clock pulses to apply the tests for these fault models. One common methodology for at-speed testing is to leverage existing on-chip clock (OCC) generation circuitry. This approach uses the active controller (OCC) to generate the high-speed launch and capture clock pulses. High transition delay coverage is utmost priority in current complex designs to improve the test quality. Conventionally the faults between two OCC domains are not considered for the transition delay test. The OCC structure and ATPG flow support faults which belong to the clock domain. When there is a timing requirement between different clock domains, those faults must be tested. This requires some modification for OCC structure or insertion of synchronous OCC IP. The paper describes this novel DFT concept used to test the inter clock domain faults using the asynchronous OCC IP and modification of ATPG procedure (spf) file. This paper will describe the principle of OCC, analyze its limitation for cross clock domain test and propose a solution to test cross clock domain faults.

2. OCC structure and principle 2.1 Basic structure and principle of OCC DFT Compiler can insert OCC controller and TetraMAX can generate at-speed test patterns by applying clocks through proper control sequences to the OCC circuitry and test-mode controls. The following figures show an example design with and without OCC.

SNUG 2014

4

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

1.1 Design without OCC CGU refers to the clock generation unit (PLL) Function logic

FUNC_CLK CGU

Figure 1 Design before OCC insertion

1.2 Design with OCC OCC OCC clock_chain OCC_SI

OCC_SO

ATE_CLK

Fucntion logic

FUNC_CLK CGU

One-hot counter

Clk_gate Clk_Selection ATE_CLK

Test_SE PLL_bypass Scan_mode

Figure 2 Design after OCC insertion NOTE: Figure 2 is just a simplified logical view to understand OCC easily, not a real implementation. Functionality of OCC: 1. scan shift mode, shift configuration value (how many fast clock pulses will be generated) to “OCC clock_chain”. 2. scan capture mode, the one-hot counter will run based on func_clk frequency. It enables at_speed clock pulse based on the value of OCC clock_chain.

SNUG 2014

5

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

2.2 Details of at-speed clock pulse generation OCC occ chain occ_si

occ_so shift reg

scan_clk

shift reg

shift reg

clk_enable

scan_enable Sync0

fast_clk

Sync1

Sync2

One-hot counter & Compare logic

pipe

fast clk en

clk_out Clk_gating

Figure 3 at-speed clock pulse generation The following figure shows how the fast clock pulse is generated when clk_enable[0] is set to 1. enable pulse if clk_enable[0]=1 pipe reg 3 synchronization cycles

fastclk_enable reg

fast_clk scan_enable clk_out 7th clock pulse after scan_enable falling

Figure 4 waveform of clock pulse generation Description: 1. The whole flow is triggered by detecting falling edge of scan_enable. 2. After scan_en is captured by rising edge of fast_clk, it needs the following steps to generate final clock pulse. 1) Three synchronous cycles 2) Synchronized falling edge of internal scan_enable will trigger counter to run: SNUG 2014

6

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

(1 to n) (n will be depend on the value of OCC clock_chain) 3) An additional pipeline cycle: 1 4) fast_clk enable cycle:1 5) occ output clock pulse generated So after scan_enable falling edge , the “3+n+1+1+1” fast_clk pulse will be sent out on clk_out of OCC.

3. Cross clock domains faults testing using Asynchronous-OCC The following is an example design (implemented project) with two clock domains. Frequencies of these two clocks are 500MHz and 250MHz, and the cross clock domain faults need to be tested since they are synchronous and it has synchronous functional paths.

500MHz

Divider 1/2

250MHz

Figure 5 Example of 2 clock domains with divider After inserting OCC, the clock structure would look like the one shown below.

SNUG 2014

7

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

500MHz

Divider 1/2

OCC_B

Block B

B 250MHz

A OCC_A

Block A

Figure 6 Two synchronous clocks with two OCC Based on the description of 2.2, we know that falling edge of scan_en will trigger the OCC to start the operation. For the example shown above, scan_en is asynchronous with internal atspeed clocks (CLK_A and CLK_B), so there will be two scenarios for OCC to start running.

scan_en

OCC_A start OCC_B start

CLK_A CLK_B Figure 7 Both OCCs start to run at different time

OCC_A start OCC_B start

scan_en CLK_A CLK_B

Figure 8 Both OCCs start to run at the same time SNUG 2014

8

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

As shown in the above figures, different time relationship between scan_en and internal clocks make different relationship between OCC_A and OCC_B, so the asynchronous OCC can’t be used to generate patterns for cross clock domain faults directly. Since the relationship of the clocks are not in sync for the capture pulse generation. By doing a hardware change in the circuit we could bring in the synchronicity in the OCC’s .

3.1 Enhancement for Asynchronous-OCC To generate patterns for cross clock domains, we need to make 2 OCCs run in same way regardless the relationship between internal clock and scan_en. Now the following modification needs to be done for OCC_A and OCC_B. For OCC_B, we created a new output from the internal scan_en synchronized by CLK_B. For OCC_A, we use the new output of OCC_B to enable one-hot counter of OCC_A. For the details, please look at the figure shown below. occ chain occ_si

occ_so shift reg

scan_clk

OCC_B

shift reg

shift reg

clk_enable

scan_enable fast_clk

Sync0

Sync1

One-hot counter & Compare logic

Sync2

pipe

fast clk en

clk_out Clk_gating

occ chain occ_si

occ_so shift reg

scan_clk

OCC_A

shift reg

shift reg

clk_enable

scan_enable fast_clk

Sync0

Sync1

Sync2

One-hot counter & Compare logic

pipe

fast clk en

clk_out Clk_gating

Figure 9 Proposed Enhancement in OCC connection

SNUG 2014

9

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

Based on the modification, the starting of OCC_A will be controlled by OCC_B. In other words, only the case shown in Figure 8 will exist in new structure. This gives a predicted synchronous pulse generation between the clock domains. In addition to this hardware change the procedure file also to be modified for the atpg to understand the relationship.

3.2 SPF Modification Latency is a parameter of SPF which refers to the number of pulses of the PLLClock that must pulse before the first internal clock pulse is issued by the OCC controller. Based on the modified structure, the time to issue the first clock pulse from OCC_A and OCC_B will be calculated in the following way. ( ) ( ) For OCC_A: ( ) ( ) For OCC_B: As we have mentioned in the earlier explanation the clocks are 500 and 250 MHz, so the Period_A = 2ns and Period_B = 4ns If n=1 (clk_chain[0]=1) for both clock, then the time of first clock pulse for two internal clocks are shown below. OCC_A: 4 * 2 = 8 ns OCC_B: 4 * 4 = 16 ns So based on same clock configuration settings (clock_chain[0]=1), clock pulse of OCC_B will be 8ns (2 clock_B cycles) later than that of OCC_A. So the latency setting for OCC_B is 2, and for OCC_A is 0. The following are the settings in SPF. PLLStructures "inst_XXX/i_ccu/CLK_B" { PLLCycles 10; Latency 2; // added for synchronous clock … PLLStructures "inst_XXX/i_ccu/CLK_A" { PLLCycles 10; Latency 0; // added for synchronous clock …

3.3 ATPG and Simulation result Based on the modifications of OCC and SPF, four kinds of patterns will be generated by ATPG. Pattern AB : launched by CLK_A and captured by CLK_B (target cross clock domain faults) Pattern BA : launched by CLK_B and captured by CLK_A (target cross clock domain faults) Pattern A : launched by CLK_A and captured by CLK_A SNUG 2014

10

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

Pattern B : launched by CLK_B and captured by CLK_B

3.3.1 Pattern AB result Pattern information from TMAX: Pattern 76 (fast_sequential-parallel_clocking) Cycle-based clocking sequence: -------------------0: \inst_XXX/i_ccu/u_OCC_clkx20/u1/X: 0100 1: \inst_XXX/i_ccu/u_OCC_clkx10/u1/X: 0-1Clock Instruction Registers: 0: 0000010000 1: 0100000000 // PLL internal clock pulse: capture_cycle=0, node=\inst_XXX/i_ccu/u_OCC_clkx20/u1 (3859) // PLL internal clock pulse: capture_cycle=1, node=\inst_XXX/i_ccu/u_OCC_clkx10/u1 (3243) Result of simulation:

Figure 10 Launch by CLK_A(clk_500), captured by CLK_B(clk_250) SNUG 2014

11

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

3.3.2 Pattern BA result Pattern information from TMAX: Pattern 72 (fast_sequential) Cycle-based clocking sequence: -------------------0: \inst_XXX/i_ccu/u_OCC_clkx20/u1/X: 01 1: \inst_XXX/i_ccu/u_OCC_clkx10/u1/X: 1Clock Instruction Registers: 0: 0000010000 1: 1000000000 // PLL internal clock pulse: capture_cycle=0, node=\inst_XXX/i_ccu/u_OCC_clkx10/u1 (3243) // PLL internal clock pulse: capture_cycle=1, node=\inst_XXX/i_ccu/u_OCC_clkx20/u1 (3859)

Figure 11 Launched by CLK_B(clk_250), captured by CLK_A(clk_500)

3.3.3 Pattern A result Pattern information from TMAX: Pattern 75 (fast_sequential-parallel_clocking) Cycle-based clocking sequence: -------------------0: \inst_XXX/i_ccu/u_OCC_clkx20/u1/X: 11 1: \inst_XXX/i_ccu/u_OCC_clkx10/u1/X: 0Clock Instruction Registers: 0: 1100000000 1: 0000000000 SNUG 2014

12

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

// PLL internal clock pulse: capture_cycle=0, node=\inst_XXX/i_ccu/u_OCC_clkx20/u1 (3859) // PLL internal clock pulse: capture_cycle=1, node=\inst_XXX/i_ccu/u_OCC_clkx20/u1 (3859) Result of simulation:

Figure 12 Launch and captured by CLK_A(clk_500)

3.3.4 Pattern B result Pattern information from TMAX: Pattern 16 (fast_sequential) Cycle-based clocking sequence: -------------------0: \inst_XXX/i_ccu/u_OCC_clkx20/u1/X: 0000 1: \inst_XXX/i_ccu/u_OCC_clkx10/u1/X: 1-1Clock Instruction Registers: 0: 0000000000 1: 1100000000 // PLL internal clock pulse: capture_cycle=0, node=\inst_XXX/i_ccu/u_OCC_clkx10/u1 (3243) // PLL internal clock pulse: capture_cycle=1, node=\inst_XXX/i_ccu/u_OCC_clkx10/u1 (3243) Result of simulation:

Figure 13 Launch and captured by CLK_B(clk_250) SNUG 2014

13

Using Synopsys Asynchronous OCC IP to target cross clock domain faults

3.4 Coverage improvement The following figure is coverage comparison between enhancement OCC and default OCC.

Figure 14 coverage comparisons between two types of OCC With the modified asynchronous OCC, the test coverage is increased by almost 4%. Most importantly this 4% coverage enhancement targets some of the timing critical inter clock domain faults, which would have remained, untested with the conventional approach.

4. Conclusion By default, cross clock domain faults are not targeted during at-speed test.. The falling edge of scan_enable triggers OCC to start. As scan_enable is asynchronous with internal at-speed clock, the different relationship between scan_enable and internal clock will make 2 OCC clock outputs asynchronous to each other. This is the reason why the default OCC does not support cross clock domain fault detection. The paper described an innovative methodology to update certain connectivity in asynchronous OCCs to achieve deterministic behavior between two OCCs which can help in targeting the critical inter clock domain faults. The change in OCC connectivity along with corresponding change in SPF helps us achieve the test coverage for the inter clock domain paths which enhances the test quality and thus the reliability of the chip. The methodology has been implemented in one of our devices and is silicon proven.

5. References [ 1 ] Lantiq DFT Standard, “Mandatory Design for Testability (DFT) Features for Infineon Technologies’ SOC Products [ 2 ] DFT Compiler User Guide [ 3 ] TetraMax ATPG User Guide

SNUG 2014

14

Using Synopsys Asynchronous OCC IP to target cross clock domain faults