feature article
Subscribe Now

Bold Assertions

Different Approaches to Feeding SVA Engines

Point: Assertions are a useful way of verifying the full spectrum of behavior of a piece of circuitry.

Point: The use of assertions has not taken off as quickly as one might expect, given how useful they can be.

Point: A main limiting factor for the use of assertions is their complexity for anything but simple cases; they can be hard to read and harder to write.

This is about as far as we can go with reasonable consensus. Here we come face to face with various ways of solving that last point, and that’s where we go off in a couple different directions. There are a number of formal tools out there just aching for more assertions to prove, so anything that can help to create assertions will make them happy.

Before we jump in, let’s review what assertions are about. Traditional old-fashioned verification involves presenting the design-under-test with a bunch of stimulus vectors and confirming that the output is correct. The problem is, there are lots of different ways to stimulate the design, and it’s hard to cover them all without going completely crazy on the number of vectors.

So an assertion for some piece of functionality can be used instead to say, “This should always happen” or “That should never happen”; a proof engine can then go off and confirm that this is indeed the case. Or not.

Sounds simple in theory, but it’s still no panacea. Take, for example, assertions one could make about the protocol involved in driving a car.  You can specify things you should do and things you shouldn’t do. For example, you could have an assertion:

Driver should never be holding a phone to the ear with one hand while car is in motion.

That’s fine, but what about other distractions? Is eating a Big Mac OK? No? OK, then we’ll add:

Driver should never be eating a Big Mac with one hand (or both hands) while car is in motion.

Of course, a Whopper would create the same problem, so we should abstract to:

Driver should never be eating a burger with one hand while the car is in motion.

But is a sandwich ok?

Driver should never be eating a sandwich chewing while the car is in motion.

But is gum ok? It’s a hands-on-the-wheel thing.

Driver should always have both hands on the wheel while the car is in motion.

But what about changing the radio station?

Driver should always have both hands on the wheel while the car is motion, except to change the radio station.

And you can add to the exceptions things like: turn on the air conditioning, open the window, select a finger to display to the guy that just cut you off, reach around for the brat that’s acting up in the back seat, etc.

The point is, it’s really really hard to come up with all the examples of good behavior and counter-examples of bad behavior. Add to that exceedingly intricate design functionality plus a complex language for expressing assertions, and you’ve got a challenge on your hands.

So what do you do about that?

We took a look at Zocalo some time back. Their approach is to get designers and verification engineers to start creating assertions as early in the design process as possible, before the RTL has been written. This gradually allows designers to verify things as they go and primes the pump for the overall verification problem to come.

Because each assertion is created while the designer is thinking about what the function is supposed to do, it’s a natural way for the designer to express the intent of the design. As the design evolves, it’s being checked all along the way, and so there’s less likelihood of discovering a huge problem late in the game.

Of course, assertions are hard to build, so Zocalo’s focus is on making it easier through better visualization and wizardry that allows the designer to focus more on what the assertion is doing and less on how the syntax implements it; their Zazz Visual SVA tool handles this. The process of capturing all the desired (and undesired) behaviors is still up to the user, however, so the car-driving conundrum still applies.

Another newcomer, NextOp, has a completely different approach. They synthesize assertions directly from the RTL and the testbench. Of course, this means that the RTL must already be in place, so this happens at a distinctly different phase of the design than we’ve seen with Zocalo.

Here the BugScope assertion synthesis engine works alongside the simulator to generate a list of properties based on what happens during simulation. These properties are presented to the designer in a way that distills out the syntactical salt so that you can more easily evaluate the essence of the property. The engineer reviews the list of properties created, and he or she will decide one of two things for each property:

          the property is correct, in which case it is then bound to an assertion in the design;

          the property is incorrect, in which case there’s a test coverage issue in the testbench that the verification engineer should patch (after which you can repeat the process).

Of course, a natural question is how the tool can infer the properties from the simulation. And that, of course, gets into the secret sauce. It appears that the tool generalizes behavior that it sees, but this isn’t an exact science.

They give an example of a design behavior that accesses 500 different memory locations.

          A loose algorithm would infer where the memory access bounds are for that operation based on the top and bottom addresses actually accessed, even if the accesses didn’t completely fill that whole space. That generates two “boundaries.”

          A strict approach would create a property for each individual access; that creates many boundaries.

They actually build some “discretion” into the tool: if too many boundaries are created, it will back off and look for a more general property that captures the behavior in a more abstract manner. This sensitivity isn’t something the user can tweak, but rather is built into the tool.

What’s really happening here is that the tool is inferring the design intent – a bold gambit. Of course, the review process by the engineer means that ultimately it’s a human that confirms whether the intent was correctly inferred.

Both the Zocalo and the NextOp tools are focused on the creation, not the proving, of assertions. So they’re not actually providing the formal tools that exercise the assertions during verification. The formal tools companies must relish the prospect of getting some help to drum up assertion-proving business. No matter whether Zocalo or NextOp wins – and especially if both win – the formal guys will be happy.

13 thoughts on “Bold Assertions”

  1. Pingback: GVK Bioscience
  2. Pingback: this page
  3. Pingback: orospu
  4. Pingback: adme
  5. Pingback: friv
  6. Pingback: poker online
  7. Pingback: iraqi coehuman
  8. Pingback: DMPK Studies

Leave a Reply

featured blogs
Apr 9, 2021
You probably already know what ISO 26262 is. If you don't, then you can find out in several previous posts: "The Safest Train Is One that Never Leaves the Station" History of ISO 26262... [[ Click on the title to access the full blog on the Cadence Community s...
Apr 8, 2021
We all know the widespread havoc that Covid-19 wreaked in 2020. While the electronics industry in general, and connectors in particular, took an initial hit, the industry rebounded in the second half of 2020 and is rolling into 2021. Travel came to an almost stand-still in 20...
Apr 7, 2021
We explore how EDA tools enable hyper-convergent IC designs, supporting the PPA and yield targets required by advanced 3DICs and SoCs used in AI and HPC. The post Why Hyper-Convergent Chip Designs Call for a New Approach to Circuit Simulation appeared first on From Silicon T...
Apr 5, 2021
Back in November 2019, just a few short months before we all began an enforced… The post Collaboration and innovation thrive on diversity appeared first on Design with Calibre....

featured video

Learn the basics of Hall Effect sensors

Sponsored by Texas Instruments

This video introduces Hall Effect, permanent magnets and various magnetic properties. It'll walk through the benefits of Hall Effect sensors, how Hall ICs compare to discrete Hall elements and the different types of Hall Effect sensors.

Click here for more information

featured paper

Understanding the Foundations of Quiescent Current in Linear Power Systems

Sponsored by Texas Instruments

Minimizing power consumption is an important design consideration, especially in battery-powered systems that utilize linear regulators or low-dropout regulators (LDOs). Read this new whitepaper to learn the fundamentals of IQ in linear-power systems, how to predict behavior in dropout conditions, and maintain minimal disturbance during the load transient response.

Click here to download the whitepaper

featured chalk talk

UWB: Because Location Matters

Sponsored by Mouser Electronics and Qorvo

While technologies like GPS, WiFi, and Bluetooth all offer various types of location services, none of them are well-suited to providing accurate, indoor/outdoor, low-power, real-time, 3D location data for edge and endpoint devices. In this episode of Chalk Talk, Amelia Dalton chats with Mickael Viot from Qorvo about ultra-wideband (UWB) technology, and how it can revolutionize a wide range of applications.

Click here for more information about Qorvo Ultra-Wideband (UWB) Technology