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
Jan 22, 2021
Amidst an ongoing worldwide pandemic, Samtec continues to connect with our communities. As a digital technology company, we understand the challenges and how uncertain times have been for everyone. In early 2020, Samtec Cares suspended its normal grant cycle and concentrated ...
Jan 22, 2021
I was recently introduced to the concept of a tray that quickly and easily attaches to your car'€™s steering wheel (not while you are driving, of course). What a good idea!...
Jan 22, 2021
This is my second post about this year's CES. The first was Consumer Electronics Show 2021: GM, Intel . AMD The second day of CES opened with Lisa Su, AMD's CEO, presenting. AMD announced new... [[ Click on the title to access the full blog on the Cadence Community...
Jan 20, 2021
Explore how EDA tools & proven IP accelerate the automotive design process and ensure compliance with Automotive Safety Integrity Levels & ISO requirements. The post How EDA Tools and IP Support Automotive Functional Safety Compliance appeared first on From Silicon...

featured paper

Speeding Up Large-Scale EM Simulation of ICs Without Compromising Accuracy

Sponsored by Cadence Design Systems

With growing on-chip RF content, electromagnetic (EM) simulation of passives is critical — from selecting the right RF design candidates to detecting parasitic coupling. Being on-chip, accurate EM analysis requires a tie in to the process technology with process design kits (PDKs) and foundry-certified EM simulation technology. Anything short of that could compromise the RFIC’s functionality. Learn how to get the highest-in-class accuracy and 10X faster analysis.

Click here to download the whitepaper

featured chalk talk

Nordic Cellular IoT

Sponsored by Mouser Electronics and Nordic Semiconductor

Adding cellular connectivity to your IoT design is a complex undertaking, requiring a broad set of engineering skills and expertise. For most teams, this can pose a serious schedule challenge in getting products out the door. In this episode of Chalk Talk, Amelia Dalton chats with Kristian Sæther of Nordic Semiconductor about the easiest path to IoT cellular connectivity with the Nordic nRF9160 low-power system-in-package solution.

Click here for more information about Nordic Semiconductor nRF91 Cellular IoT Modules