Published on October 07th, 2008

Max’s Chips and Dips: Timing Closure Verification from Real Intent

“A truth that’s told with bad intent, beats all the lies you can invent.” William Blake (1757 - 1827)

I have been a naughty boy. I have left undone those things I ought to have done. For example, way back in the mists of time (we used to call it "summer" when I was young) I was chatting to the guys and gals at Real Intent about their Timing Closure Verification (TCV) tools, and I for one am very impressed.

I was going to write about this yonks ago (where a "yonk" is 1960s British slang for some indeterminate – but having the impression of being quite long – amount of time), but what with "this and that" the sands of time slipped through my fingers until ... now!

But I think I’m in danger of wandering off into the weeds, so let’s all take a deep breath, relax (I’m now in my "happy place"), and start at the beginning. The entire enchilada – the "crux of the biscuit" as it were – is the Envision Verification Family. This suite comprises four main products, which I tend to visualize as going to parties in pairs.

In the case of block-level design and verification, we have Ascent and Conquest, which already sound as though they are capable of getting the job done (whatever that job is). In fact, Ascent is an automatic formal verification tool, while Conquest performs Assertion Based Verification (ABV).

But that’s not what I came here to tell you about. For the purposes of these wafflings and musings, I want to focus on Real Intent's chip-level design and verification engines: Meridian and PureTime. In this case, Meridian performs very sophisticated Clock Domain Crossing (CDC) analysis, while PureTime verifies the timing exceptions associated with functional false paths and multi-cycle paths.

I can’t help myself; I know that this isn’t particularly germane to the issue; but I just have to say that I love these product names – especially Meridian. As we all know, a meridian (or line of longitude) is an imaginary arc on the Earth’s surface drawn from the North Pole to the South Pole. We can visualize some meridians as corresponding to the boundaries between different time zones. When you cross from one time zone to another you have to reset your clocks ... which leads us back to Clock Domain Crossing. (Personally, I would have called this product PrimeMeridian, but I’m British so maybe I’m biased.)

But we digress. Consider a design formed from "islands of logic" where each island is driven by its own clock. The term Clock Domain Crossing refers to a signal passing from one clock domain to another. Due to the fact that the clocks are asynchronous with respect to each other, it is possible that we might lose valid data or the signal might transition during the setup and hold window of the receiving clock, thereby resulting in meta-stability.

In order to ensure correct CDC functionality, the designers should be following strict CDC design principles, but how can we guarantee that this is indeed the case? As designs become ever-more complex, it becomes well-nigh impossible to verify CDC correctness by hand. This is where Meridian leaps into the fray with gusto and abandon. First it analyzes your design to automatically determine where clock domain crossings occur, and then it plays around by inserting skew into the signals to see if it can break things by generating local errors and propagating them to the outside world.

But wait, there’s more, because now we come to PureTime. Timing exception constraints are used to provide design intent to synthesis and static timing tools. By means of these exception constraints, designers can relax timing optimization of specific paths (which is a good thing), but incorrect exceptions can cause chips to fail in functional operation, causing expensive re-spins and missed market windows (which is a bad thing).

The problem is that both synthesis and static timing analysis tools take these constraints literally without verifying their correctness. And, sad to relate, conventional functional verification tools like simulation, emulation or prototyping are typically not equipped to catch exception errors.

All of which brings us to PureTime. This little scamp accepts the design in the form of pre-synthesis RTL or a post-synthesis gate-level netlist – along with Timing Exceptions specified in de facto industry standard Synopsys Delay Constraint (SDC) format – and it checks that everything is as it should be. Some tools of this ilk are combinational, but PureTime is a mixture of sequential and formal, which allows it to verify both False path and Multicycle path statements, using highly accurate full sequential analysis.

For all exception paths, PureTime employs glitch-aware analysis algorithms. Furthermore, two or more exceptions which are perfectly valid independently may not be valid concurrently. Thus, PureTime analyzes the interactions between exceptions and ensures that each exception is valid with respect to all of the others.

Transformations made to the design by synthesis, scan chain insertion, and other back-end processing may be significant as to whether exceptions remain valid in the hardware implementation. By running at both the RTL and gate levels, PureTime protects against errors in any of these transformations.

The great thing about all of Real Intent’s tools is that you can drop them into your existing flow without disrupting anything (they understand all of the standard modeling and assertion languages like Verilog, SystemVerilog, VHDL, PSL, SVA, and so forth). So there really is no downside, while the upside is that using these tools helps you to locate, identify, and fix potential problems before they make their way into the final silicon.

So there we have it. You can purchase and use Meridian and PureTime individually, but the combination of the two provides what Real Intent calls Timing Closure Verification (TVC). Furthermore, you get better pricing for the TVC bundle, which is always a good thing (call me "old fashioned" if you will). Until next time, have a good one!

Clive (Max) Maxfield is author of “Bebop to the Boolean Boogie (An Unconventional Guide to Electronics)” and “The Design Warrior’s Guide to FPGAs (Devices, Tools, and Flows)”, Max is also the co-author of “How Computers Do Math” (ISBN: 0471732788) featuring the pedagogical and phantasmagorical virtual DIY Calculator. In addition to being a hero, trendsetter, and leader of fashion, Max is widely regarded as being an expert in all aspects of computing and electronics (at least by his mother). Max was once referred to as “an industry notable” and a “semiconductor design expert” by someone famous who wasn’t prompted, coerced, or remunerated in any way.

Tech Videos

©2019 Extension Media. All Rights Reserved. PRIVACY POLICY | TERMS AND CONDITIONS

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.