Accurate and Reliable CDC Verification Closure

Ramananda Bhimireddy, Suman Chalana

Qualcomm India Private Limited

Bangalore, India

https://www.qualcomm.com

ABSTRACT
Static CDC verification check is not sufficient to prove the Design is 100% safe to CDC crossings.
With ever increasing CHIP competition in market, providing a CDC safe product is one of the major
goals. While performing CDC checks, we assume few signals behavior as stable (Static or OFF) even
when there is a crossing. A single wrong assumption can cause downstream chip failure or critical
function failure, which might lead to re-spin of chip. Spyglass tool has native assertion generation
capability based on the crossing type for few scenarios. With a predefined methodology, we can
generate custom assertions (SVA) using Spyglass tool. These assertions can then be used in DV to
validate the assumptions made during CDC analysis.
This paper outlines the methodology to ensure fail-safe CDC check by leveraging assertion based DV
capabilities.
SNUG 2019

Table of Contents
1. Introduction ........................................................................................................................................................................... 3
2. Solution .................................................................................................................................................................................... 3
2.1 Types of waiver-tags and Assertion logic ................................................................................................... 5
2.2 Challenges ................................................................................................................................................................ 5
2.3 Limitations ............................................................................................................................................................... 5
3. Results ...................................................................................................................................................................................... 6
4. Conclusions ............................................................................................................................................................................ 6
5. Acknowledgements ............................................................................................................................................................. 6
6. References .............................................................................................................................................................................. 6

Table of Figures
Figure 1 Assertion validation flow ................................................................................................................................... 4

Page 2 Accurate and Reliable CDC Verification Closure

SNUG 2019

1. Introduction
Clock domain crossing (CDC) is one of the major design check performed
to achieve the silicon success. With ever-increasing multi-clock designs, CDC check complexity also
keeps increasing and designers need to make sure all the reported CDC crossings are resolved. Proper
synchronization scheme need to be used in design to resolve a crossing issue. Not all crossing may
not need a synchronization scheme based on the behavior of source/destination domain signal.
A complex IP with multi-clock design generally have thousands of clock domain
crossings. Some of the CDC’s can be ignored(waived) due to the known/assumed signal behavior.
Static analysis does not take design behavior into consideration. As an example; we sometimes
assume configuration register signals only change at the configuration time and never change while
functionality started. In this scenario, we proceed with a waiver by assuming signal are unchanged
(stable). Similarly there would be many such assumption scenarios. What is the guarantee, that our
assumptions are absolutely correct in all design use cases?
In this paper, we address the flow to test our assumptions are valid or not
in Design Verification (DV) simulations using Assertions (SVA).

2. Solution
In a regular flow, we write a constraint to waive a clock domain crossing.
The comment section of the constraint is generally used to track the reason for the waiving the
particular crossing, but we never validate the waiver reasoning. Sometimes we may re-use the
waivers along with Design for the derivative Chips, but these new derivative Chips use-cases may
vary and it’s difficult to manually review the thousands of waivers.
Only way to validate the waivers with actual use cases is by proving in DV
simulations. As per the newly proposed flow, we write the comment section in a pre-defined fashion
or can be called as machine-readable format.

Example:
-comment {<predefined waiver tag name>;<user comment section>;}

These predefined waiver-tag’s and corresponding SVA logic already

embedded in the Spyglass tool based on the customer requests. With help of this inbuilt waiver-tag
mechanism, Spyglass tool can understand the waiver reasoning and generates the corresponding
SVA. Generated SVA will be validated in Targeted DV tool. Figure-1 shows the complete flow diagram.
Assertion logic needs to be implemented based on the waiver-tag type.

Waiver constrains are written in <module>. sg_cdc_constraint.sgdc file and then perform the CDC
checks. Assertion files will be generated part of the output results folder. Spyglass tool supports VCS,
and third-party simulator targets. Generated assertion files need to be bind to the DV run and validate
part of regressions. Designer need to review the failed assertions and take the appropriate action to
fix the waiver/waver-tags.

Page 3 Accurate and Reliable CDC Verification Closure

SNUG 2019

*.sgdc constrain to
CDC clk/data
waive the crossings
RTL constrains

Spyglass CDC tool

CDC reports Assertions

DV setup DV Simulation Tool

if any SVA
errors
No SVA errors
DV signoff Assertions results

Figure 1 Assertion validation flow

Page 4 Accurate and Reliable CDC Verification Closure

SNUG 2019

2.1 Types of waiver-tags and Assertion logic

This section covers few general waiver-tags, we can always implement the
new waiver-tags and related assertion logic based on designs.
Below explained waiver-tag types are only for reference.

Tag-1: Destination domain logic is not active when source signals are toggling. Which means there
can be an “enable” signal which blocks the source signal values not to propagate to destination logic.
Simple assertion code can be implemented to inject random values to the destination Flop and check
if Flop output is toggling or not when “enable” signal is active.
Example waiver-tag: -comment {disable_dest;<user comment;>}

Tag-2: Destination clock is OFF when source signal is changing. Which means when the clock is OFF
source signal cannot propagate through the Flop. A simple assertion can be implemented to check
whenever source signal is toggling clock is active or not.
Simple SVA function is: dest_clk_en |-> $stable(signal)
Example waiver-tag: -comment {dest_clk_off;<user comment;>}

Tag-3: Gray code signal. This waiver-tag generally used for Convergence crossing. A Simple assertion
logic can be implemented to check all the source signals are gray code pattern or not.
Simple SVA function is: $onehot0(cur_bus_value ^ prev_bus_value)
Example waiver-tag: -comment {gray_input;<user comment;>}

Tag-4: Stable signal. This waiver tag can be used in cases where source signal doesn’t change
frequently. We can also implement a check for duration, if a signal is stable for the defined number
of clock cycle or not. A simple assertion logic calculates the source signal change time and compares
with the user provided stable period.
Example waiver-tag: -comment {stable;5;<user comment;>}

2.2 Challenges
Major challenges to enforce this methodology is:
1. Making sure of proper waiver-tag is used for each waiver and reporting if any wrong/no
waver-tag is used.
2. Developing assertion logic for each waver-tag type.

2.3 Limitations
1. All waivers may not be possible to have a waver-tag which can be proved in DV. (Example:
Debug signals)
2. A poor DV test plan may impact the CDC SVA validation.

Page 5 Accurate and Reliable CDC Verification Closure

SNUG 2019

3. Once Assertion is developed, turn-around time to get the new Tool version.

3. Results
The benefit of using SVA will be better CDC quality and it can be measured
during Post silicon phase - There shouldn’t be any CDC related issues in Silicon due to wrong
waivers.
Ex: We are able to find a real constraint issue in one of the recent project in Qualcomm.

4. Conclusions
The proposed method validates the CDC waiver reasoning in real use-cases
in DV. Which helps the designer to fix if any wrong waiver is present and saves silicon re-spin.
Earlier in normal flow, there is no way to prove the waiver reasoning and validated by manual checks
which is error prone and depends on Designer’s knowledge on the Design.

5. Acknowledgements
Our sincere thanks to Sanjay Muchini from Qualcomm India Private Limited, CAD team.
We would like to acknowledge Kosala Samarasekera, Sudeep Mondal and Harsha vardhan
Dasagrandhi from Synopsys, for their continuous support during this work.

6. References
[1] IEEE P1800™/D6 Draft Standard for SystemVerilog—Unified Hardware Design, Specification, and
Verification Language
[2] Synopsys SpyGlass CDC User Guide.

Page 6 Accurate and Reliable CDC Verification Closure