Billion Gate CDC Sign-off Done Right

Vikas Sachdeva

Real Intent Inc., Sunnyvale, CA

2

I. INTRODUCTION

Over the past decade, the move to System-on-Chip (SoC) design has dramatically

increased chip sizes. Consider a typical SoC design shown in Figure 1, a high-performance

design with SoC core, multiple caches, and interfaces. Typical SoC designs today are, big

enough to stress the capacity of state-of-art verification flows. More importantly, they have

many subcomponents with complex interactions. There are many asynchronous interfaces

between the processor cores, caches, application engines, integrated memories, system

and networking interfaces. Each subcomponent usually has its own clock domain. More

complex chips than design shown in Figure1, are routinely being taped out today. The

additional complexity is not from more complex functional units, but from the integration of a

greater number of them at the system level.

These independently developed components come together to enable a rich feature set for

the SoC. However, accompanying this abundance of features, there is a proliferation of

internal and external protocols and aggressive power requirements that leads to an

explosion in the number of asynchronous clocks in SoCs. Ensuring that this complex SoC

works according to specifications, demands that design and verification teams spend an

increasing amount of time on verifying the correctness of asynchronous boundaries on the

chip.

This paper starts with discussing why a comprehensive hierarchical methodology is needed

to verify Clock Domain Crossing (CDC) aspects of these complex billion-gate SoCs. It then

elaborates on some of the challenges created by such a methodology. Based on these

challenges, the paper summarizes a set of requirements for an efficient and effective

solution. In the final section, the paper introduces the 2017.A version of Meridian CDC, a

CDC verification tool that addresses all these requirements and enables a robust CDC

Sign-off methodology for billion gate SoCs. For more information on CDC analysis in

general, refer to “Clock Domain Crossing Demystified: The Second Generation Solution for

CDC Verification” on the Real Intent website. (www.realintent.com/white-papers/)

Figure 1: Typical SoC

3

II. Hierarchical CDC Methodology

A straightforward way to do CDC Verification on an SoC is by doing a flat run. A flat CDC

verification run is relatively easy to setup and covers all CDC issues. Ensuring correct setup

is a critical part of CDC verification and can be a significant effort. The simplicity of setup is

a major advantage of flat CDC verification. However there are also some disadvantages

with this flow. One is that the full-SoC RTL is only available late in the design cycle, at a

time when iterations are costly. Moreover, for billion gate SoCs the huge volume of CDC

data can make debug overwhelming and inefficient.

Flat CDC verification usually works well for small SoCs, but for big SoCs a robust

hierarchical methodology is much more effective. Many verification and implementation

tools such as synthesis, static timing analysis and functional verification support hierarchical

methodologies that promote IP-reuse principles and the divide-and-conquer paradigm for

breaking down the volume of data. In a hierarchical CDC analysis methodology, there are

two kinds of flows possible: a) Hierarchical bottom-up CDC verification b) Hierarchical top-

down CDC Verification.

In hierarchical bottom-up CDC verification, each IP or block is verified and its CDC

information is saved. As higher-level subsystems or SoCs are assembled, the CDC

information from the lower levels is used at the top level for CDC verification. In a bottom-up

flow, constraints for each block are developed separately by each block-level designer. Also,

SoC constraints may be developed independently from block-level constraints. This can

lead to inconsistencies among these constraints. So, in a bottom-up verification flow

verifying coherency of these constraints is a must.

The difference between hierarchical top-down CDC verification and bottom-up CDC

verification is that in top-down verification the top-level constraints are developed first. After

that constraints for lower level blocks are derived from top-level constraints. Block level

CDC analysis is done based on the derived block-level constraints and hierarchical CDC

information is saved. The top level CDC analysis then uses the block level CDC information

that was saved in the block-level run and does CDC analysis on the interaction of the blocks.

Since this flow relies on top-level constraints, block-level CDC verification cannot start until

top level constraints are available.

In short, the bottom-up flow does constraints development and CDC analysis both bottom

up, whereas in the top-down flow constraints development and propagation is done top

down while CDC analysis is done bottom up.

Both of these hierarchical flows resolve the disadvantages of flat CDC verification, but they

come with their own set of challenges. The next section discusses these challenges in detail,

along with requirements helpful in alleviating the issues.

III. Requirements of the Hierarchical CDC Methodology

Any CDC methodology needs to ensure that all possible CDC violations are found, i.e. that it

is complete. The hierarchical methodology not only needs to ensure that all block

4

interactions are free of CDC violations, but also that all clock domain crossings are checked

in the context of the entire SoC. The winning methodology will be the one that is most

efficient in terms of the overall time it takes to detect, debug, and fix all the issues.

Automation and ease of debug are very important, as well as is the ability to partition the

work (e.g. divide and conquer). Let’s start by looking at various aspects of this in detail.

Block specific reporting of CDC violations

One of the goals of a hierarchical methodology is to significantly reduce the volume of data to be

handled by the user who is reviewing CDC violations at the SoC level. This can be enabled by

distributing the work across users and addressing block-level issues independently of SOC level

issues, and without duplication. Consider the design in Figure 2.

Here CDC violations from FF3 to FF4 are within the scope of Block2 - these are the violations

that should be reviewed at the Block2 level and should not be reported at the SoC level. Other

violations, i.e. FF1 to FF2 and FF5 to FF6, should be reviewed at the SoC level.

Inter-block reporting of CDC violations

Figure 2: Block Specific CDC Violations

5

At the SoC level there can be CDC violations which involve two or more lower-level blocks. These

problems can only be identified while running CDC analysis at the SoC level. Consider the design

shown in Figure 3, there are two synchronizers in this design (shown in gray color).

The first stage of each synchronizer, i.e. F5 and F7, is being driven by combinational logic. Since

we know that combinational logic driving the first stage of a synchronizer has the possibility of a

logic hazard being captured asynchronously by the receiving domain, both of the above are CDC

violations. Designers doing CDC sign-off at the block level may or may not be aware of how their

block is integrated at the SoC level. As a result these violations only become visible when SoC is

integrated.

The implication is that when CDC verification is done at the block level, the hierarchical model

needs to save information about the ports in order to report CDC violations at the SoC level. A

primitive way to do this is via a TCL or text model where basic CDC information related to ports is

saved. The kind of information usually saved pertains to the clock domain on a port, whether it

drives a synchronizer, or whether it is driven from combinational logic. These models are created

either using methodology scripts or EDA tools. These TCL or text models can work for simple

CDC violations, but when violations become complex and involve multiple blocks, these models

start to miss important CDC issues. For example, consider the design in Figure 4. In this design,

multiple synchronized signals (syncout1, syncout2, syncout3) are converging creating the

Figure 3: Inter-block CDC Violations

6

possibility of loss of correlation effects from these signals. If a primitive TCL or text model that just

saves information about the ports is used, the CDC violation will not be reported at the SoC level.

In general these simplistic models miss important CDC issues when reporting a violation not just

needs boundary information but more detailed CDC-specific data from the block level. Ensuring

that all possible CDC violations are reported is one of the uncompromisable requirements for a

hierarchical methodology. Simple TCL/text models can miss issues that need to be resolved for

CDC sign-off.

Constraints consistency between block and top, only where it matters

A hierarchical flow relies on block-level models of CDC analysis. It is, therefore, critical that the

top-level and block-level constraints be consistent. The ability to check the consistency of these

constraints is an essential part of any hierarchical methodology. As a simple example, if two

asynchronous clocks from an SoC feed into a block where the block designer assumed them to

be synchronous, CDC bugs will be missed in the block. Verifying consistency of the constraints

protects against such gaps.

At the same time, even though constraints consistency is critical to ensure that the model saved

at the block level is correct, the process can be noisy and cumbersome if the consistency checks

are simplistic. Typically, an IP is reused across various SoCs and the constraints that propagate

to the IP boundary will be dependent upon the SoC context in which the IP is integrated.

Figure 4: CDC Violations involving multiple blocks

7

Consider the design in Figure 5. Say CDC analysis at Block B was done with in1 not specified

as a constant. When Block B is instantiated at the SoC level, a constant drives in1 because of

SoC constraints. In this case, since Block B CDC analysis has been done with a scenario (i.e.

in1 not constant) that is pessimistic compared to the scenario in which it is instantiated at the

SoC level (i.e. in1 constant), the hierarchical methodology should not report this violation at the

SoC level.

Consider another scenario of hierarchical constraints inconsistency as shown in Figure 6. Clocks

clk1 and clk2 are asynchronous to each other on this design. Say during CDC analysis at

Block B, ports in1 and in2 were specified to be in clock domain clk2. At the SoC level both

in1 and in2 are actually being driven by flops in clock domain clk1. This leads to two CDC

paths at the SoC level: first through in2, which ends in a synchronizer, and second through in1,

which is gated by a synchronizer. Although the clock domains specified on both in1 and in2

ports are incorrect at Block B level, the CDC crossings through these ports are safe at the SoC

level. So in this case also the hierarchical methodology should not report constraints

inconsistency violations at the SoC level.

When a hierarchical inconsistency is reported in a CDC run, the SoC constraints or block-level

constraints need to be fixed, and the analysis should be run again. Modifications in either block-

Figure 5: Inconsistent constraints between block and top

Figure 6: Inconsistent constraints between block and top

8

level or SoC-level constraints can reveal new hierarchical inconsistencies and the same process

then needs to be repeated. (See Figure 7.) This is a major burden on the user if there are many

of these inconsistencies. To avoid this, the reporting of hierarchical consistency checks should be

sophisticated enough to analyze the detailed CDC impact of each kind of inconsistency and be

able to determine whether to report or not report the constraints inconsistency. This can only be

ensured when enough CDC-specific information is saved in the block level CDC runs. TCL or text

based models are too simplistic to be able capture such details resulting in unpredictable iterative

loops, leading to tape-out delays.

CDC configuration consistency between block and top

In addition to constraints consistency, a hierarchical flow also needs to check for CDC

configuration consistency between the block and top levels. For example, block-level CDC

analysis might have been done assuming that two-stage synchronizers are sufficient, but SoC

guidelines might require three stages of synchronization. These kinds of mismatches are also

critical to provide sign-off quality hierarchical analysis.

Figure 7: Simplistic consistency checks leading to unpredictable iterative loops in the hierarchical flow

9

Usability and debug

Since a hierarchical CDC run is based on model information saved at lower block levels, a major

challenge is usability and debug in this flow compared to a flat run. If the information saved at the

block level is limited, it correspondingly does not allow complete debug at the SoC level, and the

productivity advantages of the hierarchical flow are lost. Designer time is one of the most

important resources, and seamless debug in the hierarchical flow is, correspondingly, critical.

Again, the simplistic TCL and text models fail to serve this requirement.

Support for configurable IPs

Many IP blocks used in current SoCs are configurable and can be parameterized differently

according to SoC needs. Also, differently parameterized instances can exist within the same SoC.

For example, consider the design in Figure 8. Depending on whether Block A is instantiated

with Mode = 1 or Mode = 0, FF1 to other flops may or may not be a CDC violation.

A hierarchical flow should, therefore, allow different models for different configurations, and

should even report violations when appropriate models are not used for different configurations.

IV. Summary of Requirements for a Hierarchical Methodology

The previous section explained challenges in CDC verification in the context of a

hierarchical flow. With that as the basis, the following items can be considered to be

Figure 8: Different configuration of the same IP

10

requirements of a hierarchical CDC verification tool and methodology for scalability and

sign-off level confidence:

• Manage the volume of violations via divide and conquer

• Provide performance and productivity gain over a flat CDC run

• Ensure that all possible CDC violations are covered at the block and top levels

• Provide intelligent hierarchical constraints-consistency checking

• Provide a means for hierarchical CDC-configuration-consistency checking

• Provide support of configurable and parameterized IPs

• Debug efficacy equivalent to a flat CDC analysis

As discussed in the previous section, TCL or text based hierarchical models generated

either by current EDA tools or home-grown scripts can support some of above requirements

but not all. Also these models don’t provide usability and debug that is seamless with a flat

CDC run.

V. Hierarchical CDC Verification Done Right with Meridian CDC

Meridian CDC 2017.A, Real Intent’s CDC sign-off solution, enables an efficient sign-off-

quality hierarchical CDC verification. In the Meridian CDC hierarchical flow, every block is

verified as part of CDC sign-off. At the end of block-level CDC verification, a “transparent”

hierarchical model is saved. The model has comprehensive information for complete and

accurate analysis at the top level. Transparent modelling of the blocks in Meridian CDC

facilitates debug in a hierarchical run that is equivalent to the flat run. The transparent model

also allows for hierarchical constraints and CDC configuration consistency checks. It

enables an intelligent hierarchical analysis to determine whether the inconsistencies impact

CDC sign-off or not. This saves unpredictable iterative loops that exist with simplistic

hierarchical models.

Meridian CDC supports the ability to specify different hierarchical models for configurable

IPs. It can also identify when a proper parameterized model is not being used in CDC

verification at the SoC level.

In addition to all the above, Meridian CDC supports an integrated visualization tool. The

iDebug GUI keeps users focused on important issues through an efficient organization of

the findings, and provides links to schematic and source information. For example, iDebug

interprets the debug information provided by Meridian CDC and provides pruned annotated

schematic views that focus on the faulty logic (See Figure 9). With a few mouse clicks,

users are directed to the associated faulty RTL source code. This debug approach allows

for easy investigation deep in the design to quickly isolate the root cause for any warnings

and errors. iDebug provides helpful guidance and suggests actions to enable users to

pinpoint the source of the problems quickly.

11

All the CDC analysis data is stored in a database that can be accessed through the GUI or

command-line interface (CLI). Users can customize the debug methodology to match their

design flows using spreadsheet reports, graphical reports, scripting, and so on.

VI. SUMMARY

With the complexity of modern SoCs, there is a proliferation of internal and external

protocols and aggressive power requirements that lead to an explosion in the number of

asynchronous clocks. Ensuring that this complex SoC works according to specifications,

demands that design and verification teams spend an increasing amount of time on verifying

the correctness of asynchronous boundaries on the chip. CDC sign-off using flat verification

for these complex SoCs is inefficient because of the voluminous amount of violation data it

generates. A comprehensive hierarchical flow that can provide sign-off quality results as

well as divide the volume of CDC data between the SoC and blocks can solve the sign-off

challenge being faced by designers working on these billion gate SoCs.

Meridian CDC 2017.A’s hierarchical flow distinguishes itself by creating transparent models

for hierarchical CDC analysis. This leads to high accuracy, low-noise results, and seamless

SoC debug. Hierarchical flow in Meridian CDC enables intelligent block and SoC level

consistency checks which save unpredictable iterative loops that exist with other tools. The

Meridian CDC hierarchical flow was developed with several partners who have helped

refine the presentation of violations, and to ensure that the tools provides appropriate debug

information for the user to understand the cause and effect of a violation. Meridian CDC

2017.A enables accurate and reliable hierarchical flow with unprecedented performance

and productivity gains for billion gate SoC CDC sign-off.

Figure 9: Intuitive debug in iDebug

12

REFERENCES

[1] http://www.realintent.com/real-intent-products/meridian-cdc/

2017-02-16, v1 Copyright © 2017 Real Intent Inc.

Real Intent, Inc.

990 Almanor Avenue, Suite 220

Sunnyvale, CA 94085

support@realintent.com

Phone: 408-830-0700

Fax: 408-737-1962 realintent.com