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
Nov 24, 2021
The need for automatic mesh generation has never been clearer. The CFD Vision 2030 Study called most applied CFD 'onerous' and cited meshing's inability to generate complex meshes on the first... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Nov 24, 2021
I just saw an amazing video showing Mick Jagger and the Rolling Stones from 2021 mixed with Spot robot dogs from Boston Dynamics....
Nov 23, 2021
We explain clock domain crossing & common challenges faced during the ASIC design flow as chip designers scale up CDC verification for multi-billion-gate ASICs. The post Integration Challenges for Multi-Billion-Gate ASICs: Part 1 – Clock Domain Crossing appeared f...
Nov 8, 2021
Intel® FPGA Technology Day (IFTD) is a free four-day event that will be hosted virtually across the globe in North America, China, Japan, EMEA, and Asia Pacific from December 6-9, 2021. The theme of IFTD 2021 is 'Accelerating a Smart and Connected World.' This virtual event ...

featured paper

Watch PCIe Gen5 Interface Demo Running on a Speedster®7t FPGA from Achronix

Sponsored by Achronix

PCIe Gen5 is the most advanced PCIe specification available today, providing data link capable of a 32 GT/s for next-generation systems. You can start to design your PCIe Gen5 system today using the Achronix Speedster7t FPGA. This demonstration shows a successful PCIe Gen5 link between a Lecroy PCIe exerciser and a Speedster7t FPGA. The Speedster7t family is one of the first FPGAs available now that natively supports the PCIe Gen5 specification.

Contact Achronix for a Demonstration of Speedster7t FPGA

featured paper

Add display or projection anywhere with the smallest DMD available

Sponsored by Texas Instruments

The new 0.16-inch DLP160CP DMD is a good fit for any application that requires an extremely compact projection system to create bright and crisp video or informational images on virtually any surface. Now you can seamlessly design that on-demand projection display into your next-generation Internet of Things appliance, autonomous robot or AR glasses.

Click to read more

featured chalk talk

How Trinamic's Stepper Motor Technologies Improve Your Application

Sponsored by Mouser Electronics and Maxim Integrated (now part of Analog Devices)

Stepper motor control has come a long way in the past few years. New techniques can give greater control, smoother operation, greater torque, and better efficiency. In this episode of Chalk Talk, Amelia Dalton chats with Lars Jaskulski about Trinamic stepper solutions and how to take advantage of micro stepping, load measurement, and more.

Click here for more information about Trinamic TMCM-6110 6-Axis Stepper Motor Driver Board