WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 571
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 571
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)
            
14173 SemiWiki Banner 800x1001
WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 571
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 571
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)

Structural CDC Analysis Signoff? Think Again.

Structural CDC Analysis Signoff? Think Again.
by Bernard Murphy on 08-05-2020 at 6:00 am

Talking not so long ago to a friend from my Atrenta days, I learned that the great majority of design teams still run purely structural CDC analysis. You should sure asynchronous clock domains are suitably represented in the SDC, find all places where data crosses between those domains that require a synchronizer, gray-coded FIFO or similar approved macro at those boundaries. But purely structural CDC analysis (and for that matter RDC analysis also) isn’t good enough.

Why not? Some people still don’t see why they shouldn’t handle the whole business in STA, throwing in an extra bit of Tcl programming. The reason that doesn’t work is that purely structural analyses generate gigabytes of potential problems, almost all of them spurious. Whether you use a commercial tool or you can custom craft your own tool in STA, no human reviewer can sensibly process that output, so they either discard it (“yeah I ran CDC, but I didn’t have time to review the results”) or they subjectively filter a big chunk at a time, not knowing what they might miss in that process.

Structural CDC analysis

The answer is to filter more intelligently, and that’s where this gets tricky. Some automation is part of the answer, carefully clustering results (which can get pretty sophisticated using ML methods). But it doesn’t reduce those gigabytes enough and it may miss important considerations in power domain crossings and AMS crossings. Getting this right requires adding more intelligence beyond a simple structural analysis, adding more functional and implementation awareness.

Why structural checks aren’t enough

Take the example in the picture above: A REQ/ACK handshake between two asynchronous clock domains in different power domains. Synchronizer cells don’t help. You can check the REQ and ACK signals go through sync cells, but it is wrong to synchronize bits of a data bus individually. It is important to check the data bus crossing functionally. And since these two side of the handshake sit in two distinct power domains, there are additional crossing checks to be considered on power-down and wake-up. Certainly, you must sequence clocks and resets correctly across these domains under different shut-down/power-up or voltage scaling conditions. But you also need to remember that under voltage scaling timing behaviors will change.

Some filtering must be based on a system-level understanding of intent. Quasi-static signals assignments are one such example. Quasi statics are nominal domain crossings for signals which only rarely change; configuration signals are a very common example. Quasi-static signals are the biggest contributor to false positive violations in domain crossing analysis. Correctly constraining these signals alone can massively reduce noise in analysis. But then you have to check to ensure those signals truly are quasi-static. That demands assertion check on those signals in all your formal or dynamic verification environments.

Cadence/TI CDC/RDC tutorial

Cadence participated in a tutorial at (virtual) DAC 2020, “Prevent Domain Crossings from Breaking Your Chip”, which discussed the importance of CDC/RDC analysis beyond structural analyses. Bijitendra Mittra from Cadence India, Venkataraman Ramakrishnan from TI and Sudhakar Surendran from TI India each presented their perspectives. Venkat gave a good general overview of the increasing challenges and the requirements for comprehensive CDC/RDC signoff. Bijitendra drilled down into the analysis details, emphasizing the importance of connecting the structural with functional and implementation. He made the point that these need to be closely coupled, so that, for example, assumptions/constraints set in CDC/RDC analysis become an intrinsic part of the verification plan for formal/dynamic verification.

Folding coverage metrics for CDC/RDC into a comprehensive metrics-driven plan is equally important. Sudhakar gave a design perspective,  real life issues he has run into in both RTL and implementation stages. These included re-convergence, initialization sequences, cascaded asynchronous events, glitch verification, performance analysis and handling hard IP integration, where CDC/RDC issues are not typically understood in .lib or STA models. The tutorial presented a very comprehensive front-to-back view of true CDC/RDC sign-off achieved using Cadence verification solutions.

To learn more about the Cadence JasperGold Clock Domain Crossing App, an app that lets users to perform comprehensive CDC signoff, please visit the Cadence product page.

Also Read

Cadence on Automotive Safety: Without Security, There is no Safety

DAC Panel: Cadence Weighs in on AI for EDA, What Applications, Where’s the Data?

#57DAC – Panel Discussion of High Level Synthesis

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.