Overcoming complex CDC violations with a concurrent block and SoC-level verification flow

By Namit Gupta, Kaushik De and David Hsu |  No Comments  |  Posted: December 8, 2014
Topics/Categories: EDA - Verification  |  Tags: , , , ,  | Organizations:

CDC violations are now so complex that it takes a combined block and full SoC level verification strategy to catch and fix all the bugs

With the complexity of modern SoCs, verifying that all the clocks on a chip are routed correctly through multiple clock and power domains is incredibly challenging. It is not enough to show that each block is free of any clock-domain crossing (CDC) issues; each block must also be checked for the way in which it handles clocks within the context of the SoC. Verifying the integrity with which clock signals pass between domains in complex SoCs requires a concurrent block and SoC-level strategy.

A typical CDC verification flow at the block level

A typical CDC verification flow at the block level starts by reading in the block RTL and the constraints and checking that the basic set-up is okay. If it isn’t, the block’s owner can revise the RTL and add further constraints until it meets set-up requirements. Once this is achieved, the CDC analysis tool will detect any clock synchronizer circuits that have been implemented and check which clock paths have been properly synced, and which have not.

On the basis of this analysis, the RTL can be reworked until the synchronization checks pass, at which point the tool can move on to more complex checks for reconvergence and reset issues.

The output of this iterative process should be the hand-off of an RTL block with a clean CDC report that includes a detailed set of constraints about how the block can be used, plus a list of exceptions (paths that need not be analyzed), waivers (violations that can be ignored) and information about any signals that are constant.

Finding complex CDC bugs using a combined block and SoC-level verification strategy

Ensuring that all possible CDC violations are found requires not only that each block is free of CDC violations, but also that all clock domain crossings are checked in the context of the entire SoC. This requires a combined and ideally concurrent block- and SoC-level CDC verification flow. Two technology advancements are required in order to support this type of flow—significant reduction in violation noise, and next-generation performance and capacity to handle SoCs full-chip flat at RTL.

In the past, tool capacity and run-time issues meant that it was usually not possible to flatten a whole SoC design for CDC verification. Alternative strategies had to be created to ensure that blocks were free of CDC bugs when considered as standalone blocks, and as part of a SoC. It was also vital to check that the SoC itself was also free of CDC errors. All this had to be done under ever-increasing time-to-market pressure.

One way to achieve this was to move to a hierarchical CDC verification strategy, checking and revising individual blocks until they were free of CDC errors, and then abstracting them into a black-box model that could be integrated at the SoC level. In this type of approach, it is important to capture the CDC intent at the block level, such as IO clock relationships,synchronizers at interface, etc.

CDC issues in SoC-level verification runs (Source: Synopsys)

Fig 1 CDC issues in SoC-level verification runs (Source: Synopsys)

However, undertaking such a CDC verification run at the SoC level, using blocks defined as above, can reveal very complex issues. In Figure 1:

  • if a path is driven from g. CLK A to CLK A, it is not a CDC issue
  • if a path goes from CLK C to CLK B, you can ignore it if it has been synchronised by nFFs
  • if a path goes from CLK E to CLK F
    • it may be unsynchronised, and therefore a CDC violation
    • Or, it may be driving CLK F in block 3, and so may not be a violation
  • the feedthrough path from block 1 to block 3 via block 2, through which CLK D drives CLK G, is identified at SoC level as unsynchronised
  • when a path from block 2 to block 3 is quasi-static, it can be ignored by CDC

 Some challenging CDC scenarios

The complexity of CDC issues means that it is easy for bugs to be hidden within blocks, or between blocks at the SoC level. Here are some examples of challenging scenarios that illustrate these cases, and some thoughts about how they can be addressed – or in the case of purely hierarchical flows, how they are not.

Scenario 1

When synchronized signals from multiple blocks reconverge, any skew between them may create a CDC issue.

SoC-level block to block clock recovergence (Source: Synopsys)

Fig 2 SoC-level block to block clock recovergence (Source: Synopsys)

This scenario reveals one way that CDC bugs can get missed. Block C has been modeled correctly at the block level, but in an SoC context, the block cannot know that its inputs are being driven by two synchronized signals.

The way to fix this issue is to ask the owners of block C to define the input ports as receiving synchronized signals, and then redo the block modeling so that this is apparent at the SoC level.

Scenario 2

In this scenario, clock signals from two blocks, A and B, reconverge through an arbitrary block C to a fourth block D.

SoC-level indirect block-to-block clock recovergence (Source: Synopsys)

Fig 3 SoC-level indirect block-to-block clock recovergence (Source: Synopsys)

If block C isn’t using synchronizers itself, how would its owner know to declare the flow of synchronization signals through its logic for the benefit of block D?

Scenario 3

This scenario includes a parameterized block A, of which there are two instances, i1 and i2.

Parameterized blocks can hide CDC issues at the block level (Source: Synopsys)

Fig 4 Parameterized blocks can hide CDC issues at the block level (Source: Synopsys)

When the MODE signal is 1, instance 1 of Block A acts synchronously, but instance 2, which receives the inverted MODE signal, acts asynchronously, creating a CDC issue.

The best way to tackle this problem is to set constraints to forbid the use of hierarchical, parameterized blocks in SoCs that are going to be verified using a hierarchical CDC flow.

Any such block that remains in the design will have to be opened up and run as part of a full-flat analysis to catch the kind of CDC bugs generated by parameterization. This will work up to the point that the number of parameterized blocks to be verified as a flat netlist outstrips the capacity of the tools.

Scenario 4

In the fourth scenario, a source flipflop in Block A drives combinational logic in Block A, Block B and the first stage of Block C, which then has a CDC synchronizer.

Some blocks may not be verifiable in an SoC level CDC check (Source: Synopsys)

Fig 5 Some blocks may not be verifiable in an SoC level CDC check (Source: Synopsys)

The question is how to handle this situation in a hierarchical CDC verification flow. The answer is that any bugs in Block B may not be observable, which may require rethinking of the overall CDC verification strategy.

A concurrent block and SoC-level CDC verification methodology

Concurrent block- and SoC-level CDC verification is required to support these scenarios and others like these. The first step is to recognize that, for time-to-market reasons, some blocks will still have CDC errors when the SoC is first integrated. Using a concurrent block and SoC-level CDC verification methodology, individual blocks and the overall SoC improve hand in hand.

How can we achieve this? At the block level, designers and verification engineers use the methodology outlined above to overcome any errors that CDC verification tools can reveal, and also to try to avoid creating situations in which CDC errors are undetectable at the block level, or in the SoC context.

Iterating block and SoC-level checks concurrently, even though some blocks may not have passed all their CDC checks, can accelerate CDC verification (Source: Synopsys)

Fig 6 Iterating block and SoC-level checks concurrently, even though some blocks may not have passed all their CDC checks, can accelerate CDC verification (Source: Synopsys)

To check the CDC integrity of the full flat SoC, which integrates the black-box representations of each block where possible, Synopsys has created a feature in its CDC tool that defines the ’scope of a violation’.

In the methodology, then, block and SoC-level CDC verification happens concurrently. The SoC owner uses the scope-of-violation reports for each of the integrated blocks to work out which CDC errors are a function of known block-level issues, which that block’s owners should be cleaning up, and which are genuinely a function of the way the blocks are coming together at the SoC level.

Eventually, each block in the SoC should reach a point at which its owners can hand off clean CDC reports, including all the block’s constraints, exceptions and waivers, to the SoC owner.

At this point, the SoC owner uses the Synopsys tool to migrate all the block-level information up to the SoC level, in order to run the full flat SoC verification. This achieves two things:

  • verifying that all the blocks are CDC clean in the context of the SoC, and with all the SoC parameters
  • checking that there are no CDC bugs at the SoC level

It’s this approach that should lead to the final CDC verification run for the SoC, and a design that is free of CDC errors.

This approach should also catch CDC bugs created by parameterized blocks, since both (or all) the modes in which the block can operate should be exercised somewhere in the SoC-level design.


The hierarchical approach to CDC verification, using abstractions of the blocks at the SoC level, helps overcome any possible issues with the capacity or runtime of the CDC tools. However, there are important scenarios in which CDC bugs can be missed at the SoC level using purely hierarchical flows. Our recommendation, therefore, is to use a robust, concurrent full-flat and block-level CDC verification methodology. This is made easier by tools that can provide information about the scope of any known block-level CDC violations so that SoC-level CDC verification can focus on CDC violations caused by block integration.

Further information

CDC landing page

VC CDC Next-Generation Clock Domain Crossing Checking

Verifying Clock Domain Crossings in Complex SoCs – Are You Sure You Caught All the Bugs? – webinar


Namit Gupta, corporate application engineer, Verification, Synopsys

Namit Gupta is a corporate application engineer at Synopsys with responsibility for static and formal verification technologies. His key interest areas are in RTL design, functional verification, and clock domain crossing and low power checking. Namit holds a bachelor’s degree in electronics from the Indian Institute of Technology, Delhi.

Kaushik De, Synopsys scientist, Design Verification, Synopsys

Kaushik De received a B. Tech degree from IIT Kharagpur, and MS and PhD qualifications from University of Illinois at Urbana-Champaign. He worked in various technical and management roles in LSI Logic, Ambit, Cadence, Synopsys, and various startup companies in US and India. He has worked in the area of synthesis, DFT and design verification. Currently he is a Synopsys Scientist at Synopsys, working in design verification, driving the static checker technology. He has co-architected VC Static Platform, VC LP, VC CDC and VC Lint tool. Kaushik has published more than 25 technical papers at conferences and journals, and holds 7 US patents, 4 pending.

David Hsu, director of marketing, static and formal verification, Synopsys

David Hsu is a director of product marketing in the Verification Group at Synopsys, and is responsible for the marketing of Synopsys’ low power, static and formal verification solutions. He has over 25 years of experience in design and test automation R&D, business development and product marketing. Prior to Synopsys, Hsu worked at FormFactor, Compass Design Automation, and VLSI Technology. Hsu holds an MSCS degree from Stanford, a BSCS degree from MIT, and an MBA from Santa Clara University.

Company info

Synopsys Corporate Headquarters
700 East Middlefield Road
Mountain View, CA 94043
(650) 584-5000
(800) 541-7737

Sign up for more

If this was useful to you, why not make sure you’re getting our regular digests of  Tech Design Forum’s technical content? Register and receive our newsletter free.

Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors