feature article
Subscribe Now

Clocks, Xs, and Resets

Real Intent Discusses New Solutions

Does it ever feel to you like, no matter how many new tools features appear, it’s never quite enough? In some cases, you solve one problem – but it doesn’t stay solved. Complexity, scaling, performance and power requirements – they may all catch up to the solution, necessitating further tool refinement. In other cases, new problems arise that were never dealt with before.

We’ve got some examples of each, distilled from a conversation with Real Intent at DAC. Let’s start with problems that have already been solved.

Danger! Clock Crossing Ahead!

I remember in my days back at Monolithic Memories and AMD. I was doing a seminar tour, and our technical topic (because no one likes a day-long sales pitch) had to do with metastability. And this was a new topic to many. During this era, there were even hopeful architectural proposals that aimed to eliminate metastability risk entirely. (Spoiler: you can’t; you just push the problem from one parameter – like a setup time – to another – like some pulse width).

As an industry, we gradually came to grips both with the notion of metastability and the need to design circuits that are robust in the face either of events whose timing is truly random or events originating from different clocks that are mutually asynchronous – that is, they aren’t derived from some common ur-clock way back upstream. (Or they have a common source, but funky clock gating makes for funky timing.)

Back in the day, this mostly related to signals coming onto and off of what would seem today to be ridiculously simple circuits. As integration grew, however, it became feasible to host more than one clock domain on a circuit. FPGAs wrestled with this in the early days; now it affects pretty much any large ASIC or SoC.

And so we got tools to test the robustness of the so-called clock-domain crossings (CDC), where a signal moves from synchrony with one clock into a new zone where it needs to be resynchronized with another clock – without causing any metastability or other glitch. Real Intent has had such a tool (Meridian CDC), based on formal analysis techniques, for a long time.

And yet, it’s still not good enough. Now, not only do we have potentially large numbers of clock domains – we also have the notion of modes. At a high level, modes are obvious: I’m a phone and now I’m going to do GPS work; in a minute I’m going to stream a video. But deep inside, this gets implemented by multiplexing different clocks into registers. Now what do we do for analysis?

Real Intent describes a couple of typical approaches:

  • Just worry about the worst-case modes. The risk here is obvious: you may miss a mode that matters.
  • Separate out all the modes and run them one at a time. This is doable, but laborious – both in setup and in having to pore through all the results. It also obscures possible links between modes, with a fix to one mode screwing up another one. Call it Whack-A-Mode.

And it gets even harder than that. Depending on how clocks are muxed, there may be a mode where one clock drives both source and destination registers – in other words, not a domain crossing. But in another mode, those two registers might have different clocks – now it is a domain crossing. And that might change dynamically.

In other cases, tracing out the logic at the clock input to a set of registers might reveal that, despite the fact that you can choose from multiple clocks, that choice becomes exclusive to the entire set of registers. Choosing clock A in one place means clock A everywhere in that register set, and similarly with every other choice. So there’s never a domain crossing here, despite the proliferation of clocks.

And, of course, you can combine them all. You could have one mode that keeps things synchronous by selection; another that makes for asynchronous crossings; and another that guarantees synchronous behavior using logic that guarantees exclusivity. And, again, they could change dynamically.

Simplistically speaking, you could dream up an uber-tool that could simply crush all of this together into a solution. But, without direction, it would start to resemble a cross-product of clocks, generating an uber-ton of work and a further uber-ton of results that you have to examine, much of which will be meaningless or repetitive.

So Real Intent has done this thing they call Static Intent Verification (SIV). It infers the clocking intent at potential domain crossings, eliminating pseudo-modes that couldn’t exist and pruning the list of things to check to only those that involve actual domain crossings. If there’s a mode where a particular register pair operate synchronously, then no analysis will be wasted on that situation.

The result is their newly announced Verix CDC product, which they claim to be the first true complete multimode solution. Not just the worst modes, not modes one-by-one, but all modes all at once. The only reason this is tractable is the SIV thing. They say it collapses the analysis time for a single mode from a week to a day. Going multimode adds about 20% to the analysis time. They also compact the results they report so you’re not spending time on redundant or phantom issues.

While what we’ve been discussing happens at the RTL level, it’s also possible for synthesis to create new crossings – and you have to analyze that at the gate level. Real Intent calls this “physical CDC,” and they plan to have it available by the end of the year.

X Static

Other familiar ground is the case of so-called X-propagation – something that happens in the verification world, but not in the real world. In the real world, every digital signal has a solid state – 1 or 0. But, when simulating, we don’t always know which until some logic path has determined the state. So those unknown states are “X.”

If you really want to be thorough, then you want to be sure that, no matter the actual physical value that this X eventually takes on in real silicon, the circuit will work. And that verification can be a lot of work. And, like so many other verification issues, you may end up working on things that don’t matter. If an X propagates for a few cycles and then peters out because some other path dominated, then does it matter? Very zen…

Real Intent says that many designs are overly pessimistic about their Xs (not to be confused with being overly pessimistic about one’s exes…). This makes for very long simulation times – but the real problem is that, with each run, you have to examine results and prune away meaningless stuff and then rerun the verification. Over and over – it can take months.

In an upcoming tool (in early access now, but due out before long), they claim to do a better job of isolating those X-propagation scenarios that really matter. Unintuitively, this actually adds 10-20% to the run time. But the payoff is that you have far fewer runs to do, reducing full-chip analysis from around two months to one month.

And Now We Have R Crossings

Now that we’ve looked at the refinements needed for two existing verification applications, we come to one that we haven’t worried about so much before: reset. Yeah, reset. That annoying signal that you always forgot to connect to something on that 7400-series chip from the TI databook. Cuz you just want to worry about the signal, not that extra stuff. (With apologies to anyone whom I just lost with the 7400 reference…)

And we’ve been grumblingly dutiful about making sure to connect our resets ever since. But we couldn’t leave it at that, could we? Of course not. Now we’re faced with multiple resets – giving rise to the concept of a reset domain. And a single clock domain may have multiple reset domains.

When checking resets for risk of metastability, it’s harder than with clocks. For CDC, you compare one clock to another. With reset, you have to compare different resets – and then you also have to check each one relative to any clocks. Because, yes, if you mess up the reset and clock timing, you can go metastable.

They have a set of risk mitigation strategies, which provide reset circuits that are aware of safe and unsafe paths. Using these, you should end up with robust circuits that won’t create any in-field surprises.

In case you thought things couldn’t get any squirrelier, they can: superimpose this reset situation on a multimode circuit. And… that’s a bridge too far at the moment. For now, their reset-domain crossing (RDC) solution is single-mode.

This solution was actually announced last November, so it’s on the shelves today.


More info:

Real Intent

One thought on “Clocks, Xs, and Resets”

Leave a Reply

featured blogs
May 6, 2021
For the third time*, I find myself writing the obligatory, "Hello, World!" first blog post. So "Hello" to all you readers of Cadence's Computational Fluid Dynamics blog. (Or... [[ Click on the title to access the full blog on the Cadence Community si...
May 6, 2021
Learn how correct-by-construction coding enables a more productive chip design process, as new code review tools address bugs early in the design process. The post Find Bugs Earlier Via On-the-Fly Code Checking for Productive Chip Design and Verification appeared first on Fr...
May 6, 2021
In April, we continued improvements to our new similar parts functionality as well as our search upgrades, and released several new content product pages on the website. We’ll also piggyback some of the cart upgrades we’ve rolled out in the last few months onto th...
May 4, 2021
What a difference a year can make! Oh, we're not referring to that virus that… The post Realize Live + U2U: Side by Side appeared first on Design with Calibre....

featured video

Introduction to EMI

Sponsored by Texas Instruments

Conducted versus radiated EMI. CISPR-25 and CISPR-32 standards. High-frequency or low-frequency emissions. Designing a system to reduce EMI can be overwhelming, but it doesn’t have to be. Watch this video to get an overview of EMI causes, standards, and mitigation techniques.

Click here for more information

featured paper

Compact. Precise. Connected. Increase productivity with intelligent edge computing.

Sponsored by Texas Instruments

Smart devices in factories and buildings are getting smaller and more capable, with enhanced real-time control, robust connectivity, and configurable web services. Read about new processor technology that is unleashing the true potential of Industry 5.0 and the Internet of Things.

Click here to read more

featured chalk talk

Accelerating Physical Verification Productivity Part Two

Sponsored by Synopsys

Physical verification of IC designs at today’s advanced process nodes requires an immense amount of processing power. But, getting your design and verification tools to take full advantage of the compute resources available can be a challenge. In this episode of Chalk Talk, Amelia Dalton chats with Manoz Palaparthi of Synopsys about dramatically improving the performance of your physical verification process. 

Click here for more information about Physical Verification using IC Validator