feature article
Subscribe Now

Are We Done Yet?

OneSpin Takes on Formal Verification Metrics

“Is this it?”

“Yeah, I think so. Drop it off here.”

“Whaddaya mean, ‘I think so’? If they don’t get the money, we’re dead.”

“I know, I know. But you can’t see any addresses here. It’s all so beat up I don’t really know which house is which.”

“And you had to go without a map. Real smart.”

“There is no map, you moron! Not even Google will drive through this neighborhood. This is, like, No Man’s Land. I just want to get in, make the drop, and get out. Look, there, those guys are watching us. Givin’ me the creeps.”

“OK, well, drive around one more time to make sure. I don’t want to leave this in the wrong place. I like my life too much. I don’t actually know why… I just do.”

“All right, all right. But we’ve only got five minutes. They said drop it off by noon or don’t bother dropping it off.”

“OK, keep your head on. Jeez! We’ll drive around one more time and then make our best call. And then pray. It’s all we can do.”

It’s all well and good to verify a design, but how do you know when you’re done? Simulation has coverage metrics, so, whether or not you agree with their value, by that definition, you can know when you’re done (or as close as you’re going to get).

It’s not so easy with formal analysis. According to OneSpin’s Peter Feist, there are many aspects of formal for which no metrics exist. So you really don’t know if you’ve completed the job and everything is fine. You do what seems to make sense, and then the deadline hits and, absent a compelling reason to push out delivery, you declare yourself done. (And maybe pray.) It’s the best you can do.

This problem feeds into a bigger issue being addressed by Accellera with their Unified Coverage Interoperability Standard (UCIS) efforts. While the title may focus on data that can be moved between tools, it also highlights verification areas for which there are no metrics to move around.

OneSpin is addressing this with their new Quantify MDV product (MDV standing for “Metrics-Driven Verification”). With this tool, they divide the totality of a design into six categories, and, conceptually, they color these categories either as some shade of green or some shade of red. Yeah, as you might guess, green is good and red is bad. The overall metric is the ratio of red to green. But that over-simplifies things.

There are two very simple categories. There’s a green one for code that has been verified by assertions. And there’s a red one for code that hasn’t been verified by any assertions. The solution to the latter is obvious: add more assertions.

Then there are four other categories that are flagged for designer review. They may be OK or they may not be. By default, three of them are red and one is green.

The first of these is a red one: it indicates parts of the design that are excluded from verification because of constraints. The good news about formal analysis is that it can cover the entire design space. The bad news is that the space is huge, and there is a “relevant” subset of that space that merits your attention. If you can focus analysis on that sub-space, then your verification will complete much more quickly.

You identify this sub-space by applying constraints. The problem is, it’s not like you can draw the whole space and then draw the sub-space and be done with it. The constraints you use are an attempt to rein in the verification heuristically, but they don’t explicitly map out the sub-space you’re trying to achieve.

It’s like trying to isolate a small circle inside a big one using only rectangles to mask off the unwanted areas. It’s hard to position them so they don’t cover any of the desired circle, while still leaving as much of the undesired area covered as possible. That means that you can under-constrain (whose only drawback is that verification will take longer than needed) or you can over-constrain – whose drawback is that you eliminate legitimate parts of the design from verification.

To check this, Quantify MDV will identify pieces of the design that will not be verified due to constraints. You can then decide whether or not this is acceptable.

The next category consists of statements in the code that are completely unreachable. An example of this might be actions to be taken in a state that will never be reached (barring some sort of upset that puts the entire circuit in an unknown condition). This raises the question, of course, as to why the logic is there in the first place. Either it’s a mistake or it should be removed.

The next category consists of logic in the design that serves no discernable purpose. If some value or state is set and then never used, there’s no real reason to verify whether or not it works. Such logic would appear to be redundant. Again, this would generally be a red flag: either something’s wrong or the logic should be removed.

Finally, there may be logic explicitly introduced to enable verification. As such, it plays no part in the normal functioning of the design, and so its verification would not be included in the plan. Even though it’s considered benign, and is hence green, it’s also submitted for designer review.

It bears noting that identifying these portions of the code is different from actually verifying them. OneSpin has a “quick” mode that lets you simply establish your coverage. This will go much faster than doing the full verification, and it may allow you to address problem areas before running the whole thing. Along with this mode, there’s another classification, “open,” indicating that an assertion covers some piece of the design, but it hasn’t been verified yet.

Mr. Feist believes that they are the first to be establishing something more solid for assessing formal verification progress. As such, it’s proprietary – the kind of thing that the UCIS project is trying to rationalize. But, assuming he’s right, someone has to be first, and you have to start somewhere, so he feels that this can help to provide some direction for this portion of the UCIS problem.

But, for the time being, this is intended to take their earlier gap identification work and move towards a more formal set of formal coverage metrics. So that you can know where you are, and praying plays less of a role.


More info:


Leave a Reply

featured blogs
May 21, 2022
May is Asian American and Pacific Islander (AAPI) Heritage Month. We would like to spotlight some of our incredible AAPI-identifying employees to celebrate. We recognize the important influence that... ...
May 20, 2022
I'm very happy with my new OMTech 40W CO2 laser engraver/cutter, but only because the folks from Makers Local 256 helped me get it up and running....
May 19, 2022
Learn about the AI chip design breakthroughs and case studies discussed at SNUG Silicon Valley 2022, including autonomous PPA optimization using DSO.ai. The post Key Highlights from SNUG 2022: AI Is Fast Forwarding Chip Design appeared first on From Silicon To Software....
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...

featured video

Synopsys PPA(V) Voltage Optimization

Sponsored by Synopsys

Performance-per-watt has emerged as one of the highest priorities in design quality, leading to a shift in technology focus and design power optimization methodologies. Variable operating voltage possess high potential in optimizing performance-per-watt results but requires a signoff accurate and efficient methodology to explore. Synopsys Fusion Design Platform™, uniquely built on a singular RTL-to-GDSII data model, delivers a full-flow voltage optimization and closure methodology to achieve the best performance-per-watt results for the most demanding semiconductor segments.

Learn More

featured paper

Reduce EV cost and improve drive range by integrating powertrain systems

Sponsored by Texas Instruments

When you can create automotive applications that do more with fewer parts, you’ll reduce both weight and cost and improve reliability. That’s the idea behind integrating electric vehicle (EV) and hybrid electric vehicle (HEV) designs.

Click to read more

featured chalk talk

High Voltage Charging Solution for Energy Storage & Backup Systems

Sponsored by Mouser Electronics and Analog Devices

Today there is growing demand for energy storage with more power, longer range, and longer run time. But the question remains: how can we increase our energy storage given the energy storage mediums on the market today? In this episode of Chalk Talk, Amelia Dalton chats with Anthony Huyhn from Analog Devices about the benefits of high voltage energy storage, why stacked battery cells are crucial to these kinds of systems, how high voltage energy storage systems can reduce conduction loss exponentially and what kind of high voltage charging solutions from Analog Devices are on the market today.

Click here for more information about the Maxim Integrated MAX17703 Li-Ion Battery Charger Controller