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. Introduction .............................................................................................................................. 4
2. OCC structure and principle .................................................................................................... 4
2.1 Basic structure and principle of OCC ........................................................................... 4
2.2 Details of at-speed clock pulse generation ................................................................... 6
3. 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
4. Conclusion ............................................................................................................................. 14
5. 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 One-hot counter Clk_gate
CGU
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 shift shift
scan_clk reg reg reg
clk_enable
scan_enable clk_out
One-hot counter fast
Sync0 Sync1 Sync2 & pipe clk Clk_gating
fast_clk Compare logic en
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 250MHz
Divider
1/2
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
Block B
500MHz Divider OCC_B
B
1/2 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 at-
speed clocks (CLK_A and CLK_B), so there will be two scenarios for OCC to start running.
OCC_A start
scan_en OCC_B start
CLK_A
CLK_B
Figure 7 Both OCCs start to run at different time
OCC_A start
scan_en OCC_B start
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 cant 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 OCCs .
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 shift shift
scan_clk reg reg reg
OCC_B clk_enable
scan_enable clk_out
One-hot counter fast
Sync0 Sync1 Sync2 & pipe clk Clk_gating
fast_clk Compare logic en
occ chain
occ_si occ_so
shift shift shift
scan_clk reg reg reg
OCC_A clk_enable
scan_enable clk_out
One-hot counter fast
Sync0 Sync1 Sync2 & pipe clk Clk_gating
fast_clk Compare logic en
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-1-
Clock 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: 1-
Clock 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: 0-
Clock 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-1-
Clock 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
