CDC Analysis using JasperGold

In this post, we will look at the analysis of Clock Domain Crossings in a design using the Cadence JasperGold Tool.

Clock Domain Crossing or CDC is one of the most challenging and interesting topics of discussion in VLSI Design. CDC basically means crossing from one clock domain to another. A clock domain means a clock having a particular configuration (frequency, phase, skew, jitter) etc.Unfortunately, we cannot expect just one fixed frequency clock to be sufficient to meet all our requirements for large designs. We may need clocks of varying frequencies working simultaneously. During this time, one of the major challenges that one can face is sending the data from one clock to another and being able to obtain the exact data at the destination without loss.

Possible issues when crossing clock domains:

1. Metastability
2. Data Loss

1. Metastability
To understand this, one must be clear about the Setup and Hold times for a flip-flop.

Setup Time is defined as the time before a clock pulse for which the input data must be held stable so that the data can be sampled correctly.
Hold Time is defined as the time after a clock pulse for which the input data must be held stable so that the data can be sampled correctly.

In the above waveform, assume that input is generated by clk1. Now a D flip-flop working on above clk2 is trying to sample the input.

• However clk2 is too close to the posedge of clk1 such that at position marked 1, clk2 will not be able to capture the input properly.
• Setup/hold time will be violated as input is changing at that edge of clk2.
• When violated, the data will go into a state called metastable state. It is neither 0 or 1, it is a temporary oscillating state between 0 and 1 and must be avoided at all costs. This will occur at the region marked output unstable period.
• Only at position marked 2, the input data is stable and can be safely sampled.

2. Data Loss
Data Loss can occur when the destination clock is slower than the source clock. This means, if there is an input pulse for one source clock cycle, the destination clock posedge might miss out on sampling this data.

See the above waveform where clk2 (destination) is faster than clk1 (source). Posedge marked 1 of clk2 will not be able to capture the input as the input just starts to change. By the time we reach posedge 2, the pulse is over. So the data is lost.

How to solve this problem?
The answer is Synchronizers.

What do synchronizers do?

1. Ensures that data is sampled by destination domain only when source data is stable.
2. Informs the source to place new data only after receiving acknowledgement from destination for the previous data (with feedback).

Types of Synchronizers:

1. Double Flop Synchronizer
2. Feedback Synchronizer
3. Mux-Based Synchronizer
4. Asynchronous FIFOs

We shall not discuss deep regarding each synchronizer in this post. Now that we have understood the basic CDC issues, we can now look at how we can analyze and correct these issues using Cadence JasperGold Tool.

Tcl Script for JasperGold

Let us see how we can develop a Tcl script that can be sourced by the JasperGold Tool for CDC Analysis.

1. Reading the RTL files.

The design files can be read using analyze command using the sv switch.

Consider a design with the following files: topmodule.v, file1.v and file2.v

Then the command will be used as:

analyze -sv topmodule.v

analyze -sv file1.v

analyze sv file2.v

(Note: Provide full path of the files if they do not exist in the current directory)

2. Elaborate the design by specifying top module.

This is done using the elaborate command and -top switch.

elaborate -top topmodule.v

3. Declare the global clocks used in the design using clock command.

For example:

clock clk1

clock clk2

4. Declare global resets used in the design using reset command.

reset reset1, reset2

From hereon, we use the check_cdc command with various options to perform certain configurations as per our requirement.

5. Associate the primary ports of the design (those of the top module) with its clock domain.

For example: 

If the primary ports addr1 and data1 works in clock domain clk1, 

addr2 and data2 works in clock domain clk2,

Then we can declare this information like this to the tool:

check_cdc -clock_domain -port {addr1} -clock_signal clk1

check_cdc -clock_domain -port {data1} -clock_signal clk1

check_cdc -clock_domain -port {addr2} -clock_signal clk2

check_cdc -clock_domain -port {data2} -clock_signal clk2

6. Now we can inform the tool about some other properties of signals used in the design using the -signal_config switch of check_cdc.

For example:

a) If a particular signal holds a constant value. 

Example: If a signal ready holds the constant value 1, we can declare it using:

check_cdc -signal_config -add_constant {ready 1}

b) If a particular signal is static during clock domain crossing.

Example: Let us assume the signal addr1 is static when it crosses from clock domain clk1 to clk2. Then we can declare this info so that the tool does not report a CDC violation for addr1.

check_cdc -signal_config -add_static {addr1}

7. Declare synchronous clocks used in the design so that signals crossing between such clocks are not reported as CDC violations.

For example: If two clocks clk1 and clk2 are synchronous, we declare them like this:

check_cdc -clock_group -sync {clk1 clk2} -name synchronous clocks

8. Enable this check as well so that the tool can detect FIFOs. By default, it is off.

check_cdc -check -rule -set {{fifo_detection true}} 

Now that all declarations have been given by the user, we can now tell the tool to perform its analysis.

The tool will do the following:

8. Find clock domains

check_cdc -clock_domain -find

9. Find CDC pairs

check_cdc -pair -find

10. To perform structural analysis and detect synchronizers:

check_cdc -scheme -find

Finally, the tool can generate various reports using the -report option in .csv format.

-file option to specify the file name and path

-force option to overwrite an already existing file.

Different reports are generated for different categories like:

check_cdc -report pairs -file pairs.csv -force

check_cdc -report violations -file violations.csv -force

check_cdc -report domains -file domains.csv -force

check_cdc -report rules -file rules.csv -force

check_cdc -report signal_config -file signal_config.csv -force

After this, open the Cadence JasperGold tool GUI.

Here, use the Source Tcl script option to execute the Tcl script.

After completion, the tool will generate errors and warnings (if present) regarding CDC violations.

Under pair:

no_scheme: This means no synchronization scheme has been implemented between two clock domains.

cdc_pair_logic: This occurs when there is some logic on the CDC path.

cdc_pair_fanout: This occurs when the CDC path fans out to multiple destinations.

Under scheme:

sync_chain_logic: This occurs when there is some logic on the synchronization path.

sync_chain_fanout: This occurs when the synchronization path fans out to multiple destinations.

(From the DFF figure above, the path labelled din_flop is the 'CDC path' and the path labelled dmeta is the 'synchronization path' from the previous explanation)

From the GUI Window, we can waive certain violations if we know such a violation will not occur (For example: If the signal is static during that period).

After selecting the Waive option, add a message and the waiver will appear in Tcl format in the session window.

Copy this waiver message from the session window and add it to your Tcl file.

The waiver message will be of the format:

check_cdc -waiver -add -filter [...] -comment {....}

In other cases, you can choose Debug Violation to open the schematic and find out how to tackle the CDC issue.

As shown in this image, the signal crosses from one clock domain (in one module) to another clock domain (in another module) without any synchronization.

With this, we conclude with CDC analysis using JasperGold tool.

Refer the Jaspergold tool documents for more information.

References:

Jaspergold CDC User Guide