Clock-domain crossing (CDC) verification is a critical step in the design verification cycle. However, CDC verification is not only necessary on RTL; at 28nm nodes and below it is also essential on gate-level designs due to the possibility of the introduction of CDC errors during the synthesis phase that can lead to silicon failure. In this article we review the root cause of these challenges and introduce an automated approach to overcome these difficulties.
INTRODUCTION
CDC verification ensures that signals pass across asynchronous clock-domains without being missed or causing metastability. Traditionally, CDC verification is done on a register-transfer level (RTL) representation of the design. However, during the synthesis stage, when the design is transformed from RTL to gate-level, various new issues can be introduced that may eventually lead to chip failures. So, even after CDC verification closure at the RTL, it is important to perform CDC verification on a gate-level design to detect and address new issues.
Changes introduced in the netlist during synthesis, such as timing optimization of synchronization logic and insertion of design-for-test (DFT) and low-power circuitry may cause incorrect behavior in CDC synchronizers, introduce new CDC paths or break valid CDC paths. For example, new clock-domain crossings can be introduced due to insertion of low-power logic as shown in Figure 1. Similarly, due to scan logic insertion, a clock tree can be impacted if the correct mode design constraints are not specified, as shown in Figure 2.
 |
Figure 1. CDC path impacted by power logic
 |
Figure 2. Clock and data path impacted by DFT logic
Additionally, faulty implementation of combinational logic by synthesis tools may result in glitches on con-trol and data paths. As shown in Figure 3, a valid mux-based synchronizer (3A) is converted to a combinational logic which is logically correct, but can propagate a glitch from asynchronous transmit domain causing chip failure (3B).
 |
Figure 3A. RTL MUX logic, pre-synthesis
 |
Figure 3B. MUX logic converted to combinational logic with glitch
The bottom-line is that even after you have achieved "CDC closure" at the RTL level, CDC-related chip-killing glitches can appear downstream unexpectedly. In short, you thought you were safe, but you are still at risk!
So what can be done about this?
First, tweaking the settings in your synthesis tool can sometimes help prevent this issue in the first place. But based on our experience with numerous customer designs – especially devices at the 28nm node and below – it's clear that the reduced "bandwidth" of these advanced nodes, coupled with the high circuit complexity, makes it virtually impossible for a synthesizer to exhaustively account for all the causal factors and constraints. Consequently, CDC verification at the gate-level is absolutely required in order to ensure all chip-killing glitch-y circuitry is identified and designed out. Unfortunately, the solution is not as easy as simply re-running RTL-centric CDC tools on gate-level netlists.
WHY RTL CDC TOOLS ARE UNSUITABLE FOR GATE-LEVEL ANALYSIS
The most common reasons that make gate-level CDC verification closure a daunting task with RTL-focused CDC tools include:
Significant setup effort: All designs have refined CDC design constraints setup at the RTL with which the design is verified to be CDC clean. These RTL constraints cannot be reused during CDC verification at the gate level because of changes in the module and signal names post synthesis and technology mapping. All design constraints that refer to RTL signals and modules no longer work. Manual conversion of constraints is not feasible as it involves high effort and needs knowledge of name transformations done by the synthesis tool. Writing new setup constraints is not desirable as it requires several iterations to fine-tune the constraints and thus leads to significant delay in the verification schedule.
Glitches can be introduced on CDC paths that were safe at the RTL: As per the earlier example, the most common glitch introduction scenario is when a mux in the data path is transformed as combinational logic that can possibly glitch. This situation requires special approach to identify and fix glitch scenarios.
The design bus signals are split into multiple single-bit signals at the gate-level, causing several issues:
- Differentiation between data and control signal is lost and traditional CDC verification tools treat every path as a single-bit control path.
- In general, the design size "increases" as compared to the RTL description, stretching the capacity limits of CDC verification tools.
- The CDC crossing count increases many times, resulting in high noise, leading to the next point…
Exponentially higher debug effort due to increase in violations and noise:
- Recall that designers commonly add waivers during CDC analysis at the RTL for acceptable scenarios. However, these waivers -- written on RTL results -- do not work at the gate-level due to signal name and topology changes. This makes gate-level CDC closure much more difficult as now the verification engineer needs to reanalyze and waive CDC paths that were already qualified at the RTL.
- False violations can increase due to the interference of scan logic. User intervention is needed to correctly specify the functional mode.
At this point, after reading all these depressing limitations of RTL-level CDC analysis you might be wondering why bother to do RTL CDC verification at all. Ironically, the key to effective gate-level CDC verification is successful RTL verification.
PROPOSED GATE-LEVEL CDC VERIFICATION FLOW
As you might expect, the basis of our gate-level solution leverages virtually every element of a successful RTL-level CDC analysis. Specifically, Figure 4 below illustrates a high-level CDC verification flow on RTL to netlist and how to enhance the flow to reuse knowledge about setup and waivers at the RTL for downstream gate-level CDC verification.
 |
Figure 4. CDC verification flow from RTL to netlist
First, RTL CDC closure is one of the necessary RTL sign-off criterion; so assume that every design at the RTL stage will have gone through CDC verification. After the RTL is frozen, the design goes through synthesis and a netlist is generated. As per the warning in the previous section, a fresh CDC run on the gate-level netlist would require huge and painful setup effort that would only yield very noisy results. To address this, the trick is to reuse the constraints and waivers that were created for CDC verification at the RTL level. Specifically, this new flow works on a gate-level netlist along with RTL constraints or gate-level constraints (and/or any SDC files) for the gate-level design. It then employs specially designed gate-level analysis algorithms inside the Questa® CDC Gate-Level app ("CDC-GL"), which infers all the design-mode constraints and detects the scan and test signals. Then, after the user qualifies the setup, the actual CDC analysis on netlist is executed with the Questa® CDC Gate-Level app. Below are the details, in the context of the aforementioned challenges of the conventional approach.
A. Setup Automation: The good news is that all of the constraints created for RTL CDC verification can be provided as-is – Questa® CDC-GL automatically maps RTL constraints to the corresponding gate-level signal and module names that were generated by the synthesis tool. Again, this automation saves tons of effort that would have been needed to create and refine the setup through multiple iterations; plus it also ensures reduced false noise as the constraints are already validated in RTL CDC analysis. An example of this automation is illustrated in Figure 5. The custom synchronizer and quasi-static signal specifications in the RTL are automatically converted to match the gate-level design signal and module names.
 |
Figure 5. Examples of automatic conversion of RTL constraints to gate-level constraints
Note: RTL-to-gate name mapping processing can be expedited by referencing name-mapping files from logic equivalence checking (LEC) run on the synthesized design (Mentor's FormalProTM is one example of such a tool). Additionally, if you have an SDC file, Questa® CDC-GL can also automatically extract important information from the SDC and use it for the gate-level CDC analysis.
The next level of automation Questa® CDC-GL provides is the inference of constraints for the logic that was not present in the RTL but got inserted during synthesis and later stages. For example, DFT logic is inserted later in the flow. However, it is important to verify the CDC design in the right mode, that is, the functional mode. If the tool does not differentiate between test and functional modes, it leads to more gated clocks, and hence extra noise and false crossings. In the proposed methodology, such mode and constant settings are inferred by analyzing the design topology using software algorithms on the design graph. This ensures that the user doesn't have to manually analyze false crossings and constrain the design in the appropriate mode. With the suggested flow, the user just runs the gate-level CDC analysis and reviews the constraint guidance provided by the tool.
An example of the scan logic impacting CDC crossings is shown in Figure 6A. If mode constraints are not specified, then with traditional CDC verification approach, the CDC path will be reported as unsynchronized crossing. However, in the proposed methodology such logic is analyzed to detect scan enable and test mode signals and correct constants are set on them automatically to ensure the design operates in functional mode and synchronizers are detected as shown in Figure 6B. This approach eliminates false noise due to insertion of extra logic, also saves a ton of user effort in specifying the constraints manually.
 > |
Figure 6A. DFT inserted CDC path
 > |
Figure 6B. CDC path with synchronizer in functional mode
B. Elimination of Noise in CDC Analysis: Honoring RTL constraints and inferring functional mode constants not only ensures that the setup is correct, but it goes a long way to minimize "noise" in the CDC analysis of the gate-level netlist. However, considerable noise can still come from the splitting of vector signals during synthesis as this leads to a huge increase in the number of reported crossings. The good news is that Questa® CDC-GL understands the splitting of vectors by synthesis and considers this during CDC gate-level analysis to correctly identify the control and data crossings. This identification of data crossings drastically reduces the noise and also brings gate-level results closer to the RTL-level analysis output. In addition, the RTL signal name is reported so that users can correlate gate-level results with RTL results. An example is shown in Figure 7 below. A 16-bit data crossing in the RTL gets converted to 16 individual single-bit crossings in the netlist. In the proposed approach, a single data crossing and its correlation to the RTL crossing is reported.
 |
Figure 7. Data crossing identification
This automation reduces the violation count and guides the user to differentiate between control and data path crossings, and to correlate the results with RTL results.
C. Reuse of RTL Waivers: RTL CDC analysis of even small IPs can require the creation of many waivers, representing a lot of work, often from multiple people. It's imperative that this time is not wasted, and that's why this suggested methodology enables reuse of the RTL CDC run waivers. In short, the crossings qualified by users as stable or false during RTL analysis need not be reanalyzed at the gate-level because the RTL waivers are automatically transformed and applied to gate-level results. This reuse also includes any status information or user comments attached to the RTL waivers are carried forward corresponding gate-level crossings. This ensures that when the user gets the gate-level results for the first time, there is minimal noise and only new issues identified at the gate-level are highlighted.
CASE STUDY
To prove out the new flow, the new gate-level specific methodology and a traditional CDC verification flow were executed on a representative set of customer designs from 1 to 100 million gates. For each design, constraints at RTL were available along with the netlist, and the CDC results, run time and memory consumption were captured for each run. Figure 8 compiles the comparison of this data.
The data is clear: significant improvements were observed in run time, memory, and noise with the new Questa® CDC-GL flow. As you can see, when the traditional approach was tried on these designs it resulted in a very large number of CDC paths. As explained earlier, this was primarily due to inability to reuse the RTL constraints and waivers, missing constraints for the scan logic and splitting of vector signals.
In contrast, because the new flow automatically applied the RTL constraints, inferred scan logic constraints, honored RTL waivers, and smartly considered the impact of splitting of vector signals, the noise level dropped significantly and also led to an average of 50 percent improvement in run time and 15 percent improvement in memory consumption. Consequently, the turnaround time and effort involved in CDC verification closure on these gate-level netlists was significantly reduced, while the quality of results dramatically increased.
We extended the experiments by running CDC analysis on both RTL and gate-level version of the same testcase with the same set of RTL constraints. The gate-level run was executed using name-map file from the LEC tool and the RTL constraints.
 |
Figure 8. Comparison between RTL-Only CDC analysis and New, Optimized Gate-level CDC verification on gate-level netlists from 1 to 100 million gates
CONCLUSION
CDC analysis at gate-level is required – without it, CDC bugs introduced during synthesis can escape leading to chip failure. The suggested methodology using the Questa® CDC Gate-Level app is easy to adopt as it utilizes all the knowledge from the design and RTL CDC verification processes that occur before. The results of the verification come in much faster, and are much higher quality. All of this shrinks the setup, debug, and repair turn-around time of chip killing glitches during one of the most high pressure stages of a project.
REFERENCES
- Clifford E. Cummings, "Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog", SNUG-2008
- Vishnu C Vimjam and Al Joseph, "Challenges in Verification of Clock Domain Crossings", DAC knowledge center Article
- Ping Yeung, "Five Steps to Quality CDC Verification", Mentor Graphics, Advanced Verification White Paper
- M. Litterick, "Full Flow Clock Domain Crossing – From Source to Si", DVCON 2016
- Anwesha Choudhury, Ashish Hari, "Accelerating CDC Verification Closure on Gate-Level Designs", DVCON 2017
Back to Top