Lint for Implementation

When I was at Atrenta, we took advantage of opportunities to expand our static tool (aka linting) first to clock domain crossing (CDC) analysis and DFT compatibility and later to static analysis of timing constraints, all of which have importance in implementation. CDC is commonly thought of as an RTL-centric analysis, however, late-stage clocking refinements due to low-power implementation also require runs at the gate-level. These kinds of analyses are in effect a lint for implementation, a pre-check to ensure that the design and timing constraints are consistent and clean according to a variety of requirements. I’m encouraged to see that this mindset is becoming even more common, as evidenced in Cadence’s recent release of their Conformal Litmus tool.

The need for CDC checking should (I hope) be beyond debate. Virtually every SoC design hosts multiple clock domains, for different standard I/O interfaces (PCIe, USB, etc) and for different on-chip functions (CPU cluster, GPU, DMA, AI accelerators, etc). Data or control passing between these domains can drop bits/words or run into lockups which may only be fixable through a system reset. Neither static timing analysis (STA) nor simulation can reliably find all possible problems and design review is not up to comprehensive checks on these massive devices. This is serious; missing CDC problems have led (and continue to lead) to more than a few embarrassing field failures.

The need for constraint checking may not be so obvious to many of you. After all, you’re going to do all of this properly during STA in implementation, right? True, but implementation cycles are not very quick. There’s no way around this when you’re dealing with key implementation choices, say adding pipelining or fiddling with your CTS. But there’s a very obvious way to minimize iterations caused basic inconsistencies in constraints – flush them out early, the same way you flush out basic errors in RTL, by linting the constraints.

You might be surprised to hear that constraints need this kind of checking. You shouldn’t be. They’re IP data, no more immune from errors than any other IP data. The IP used in an SoC comes from a bunch of different sources, so constraints are developed by different people with differing expectations and perhaps differing quality control. At Atrenta we had a number of IP-provider customers who had their customers advise they needed to do more checking. Even if the individual IP constraints are correct by some measure, when you put them together in an SoC with constraints for the top-level, it’s not uncommon to find cross-hierarchy inconsistencies.

Since mistakes and misunderstandings happen, you have to plan for checking across the full design, and this is much faster to do at RTL. Fast is good, but you also have to be able to trust the checking will fully correlate with your later STA runs. This is where it got a little hairy for us at Atrenta. We didn’t build production synthesis tools or signoff timers so we had to rely on customer feedback on what we might be missing. We did pretty well but not to the point you could consider our checks signoff-grade for pre-implementation. To do that you have to own the timer certainly and ideally the synthesis tool as well.

Conformal Litmus is integrated with Tempus (the Cadence STA solution) using the same interpretation of the design, timing and constraints you’ll find in that timer; therefore, consistency throughout the flow is verified with the same signoff timer you’ll be using implementation.

Since the design will certainly evolve through the flow, and generally constraints do also, consistency checks are necessary to validate such changes. Does my RTL plus RTL-constraints match my netlist plus netlist-constraints (at a consistency level), for example? We had some of this capability at Atrenta, but we didn’t have a netlist equivalency checker, where Cadence obviously has Conformal. Litmus supports all required combinations of consistency checks between different steps.

I asked Kam Kittrell (senior product management group director at Cadence) about false-path and multicycle path checking (I knew you would have this question too). Litmus doesn’t do this, although it does do consistency checking for path exceptions across the flow—which makes sense. I don’t know anyone who really proves FPs and MCPs well, despite many claims. And these kinds of checks would definitely not work at the full-chip level.

CDC checking is integrated in all of this. Litmus checks for metastability, glitch potential and reconvergence possibilities (reconverging separately synchronized signals). The CDC checks are structural, missing some of the formal possibilities, but since this is intended for full-chip checking, that’s not surprising. Again, ability to run these checks at each stage is important since domain crossings can be introduced or changed during low-power implementation.

You can learn more about what Cadence provides in Conformal Litmus, including how they manage for low noise reporting, HERE.