Netlist CDC. Why You Need it and How You do it.

The most obvious question here is “why do I need netlist CDC?” A lot of what you’re looking for in CDC analysis is really complex behaviors, like handshakes between different clock domains, correct gray coding in synchronizing FIFOs, eliminating quasi-static signals and the like. Deeply functional, system-level intent stuff. How on earth could you deal with that at the netlist level? Not to mention that you’re already battling massive levels of false negatives. Wouldn’t these be a thousand times worse in a netlist design? Well yes, but – synthesis, ECOs, CTS and the like can mess up a lot of details relevant to CDC, during implementation. Which is why you also have to run CDC on netlists. The question then is – how?

Yes, you still have to do RTL-based CDC

First, I don’t believe anyone is claiming you can ignore CDC analysis at RTL and start from scratch on a netlist. RTL CDC is still essential to do all that functional/intent-based analysis, and to build up lists of exceptions and waivers. Because you’re going to need those controls and constraints for your netlist-based CDC. You’re also going to have to be careful with what netlist names you use in those controls. For example, not using names that may disappear in synthesis. The constraints and controls you develop in this RTL-level analysis will then be the starting point for netlist-based CDC.

Design changes in implementation

Second, what does implementation change that requires re-running CDC? Quite a lot. From a big-picture behavior point of view it’s low-level stuff, though still very important to CDC correctness. Some of these spring from optimizations in synthesis, for example design restructuring to optimize timing. Flip-flops move around in paths, causing CDC-correct pre-synthesis logic to become invalid. Some power related capabilities must be inserted in implementation. Some DFT choices are floorplan sensitive (such as MBIST controller sharing), requiring they be updated in implementation. Clock-tree balancing is a very delicate task, continuing to evolve in implementation, not only to optimize skews but also as clock gating plans evolve.

New CDC problems can also arise through ECOs. A functional, timing or power problem discovered late in implementation may force a logic change in the netlist, one reason we need netlist equivalence checking. Unfortunately EQ doesn’t help with CDC. Going all the way back to the RTL to fix a functional problem is too big a hit to the schedule at this late stage. More changes, more need to recheck CDC.

Glitching

Logic gates can glitch when two or more inputs change at the same time. The output briefly flips then flips back again. Not a big deal when the gate is safely cocooned between two levels of registers. But it can be a very big deal if the gate is controlling a clock or an asynchronous reset around a clock (or reset) domain crossing. These hazards can’t always be fixed at RTL. Synthesis can choose how to implement functions like muxes, for example, if you don’t carefully constrain the choice. The default synthesis selections may be glitch prone. You can’t figure this out until after synthesis.

VC SpyGlass for netlist CDC

Synopsys has adapted SpyGlass CDC to be well aligned with these netlists CDC needs. Designers benefit with VC SpyGlass’ ability to support huge designs (1.5 billion+) and a robust Tcl environment to reduce design setup between implementation and verification flows, including the ability to develop their own design query scripts and generation of custom reports. The tool also supports features I’ve mentioned in earlier blogs, such as machine learning root cause analysis (ML RCA) help to generate constraints to reduce noise and hierarchical flow support to improve

You can learn more from this white paper.

Also Read:

The Big Three Weigh in on Emulation Best Practices

Synopsys Presents SAT-Sweeping Enhancements for Logic Synthesis

DAC Panel – Artificial Intelligence Comes to CAD: Where’s the Data?