Assertion-Based Verification and Assertion Synthesis

I recently read a couple of items on Assertion Synthesis. It got me thinking about how Assertion-based verification is utilized in the design/verification community and what is the best approach to an effective first silicon success methodology which utilizes ABV.Some time ago, I queried a colleague in the verification services business why we have so many silicon re-spins. The answer was simple: “Because we plan for them”. Silicon success rates haven’t been very good (I have no current data) and the industry spends a lot of time and dollars on solving this issue. Is it the design complexity or are the development methodologies just not getting the job done?

About the articles: The first was an article by Paul McLellan on SemiWiki; the second was an anon posting on the DeepChip site.

The main subject of the SemiWiki article was to answer the question:  What is Assertion Synthesis?”. Two statements in the article intrigued me:

“Assertion-based verification helps teams using simulation, formal verification and emulation methodologies, to accelerate verification sign-off. The RTL and test specifications are enhanced to include assertions and functional coverage properties. These are statements that define the intended behavior of signals in the design. Assertion synthesis automates the manual process of creating adequate assertions and functional coverage properties and so makes assertion-based verification more practical.”

“But the challenge of assertion-based verification is creating enough assertions when they must be created manually. Generally one assertion is needed for every 10 to 100 lines of RTL code but it can take hours to create, debug and maintain each assertion. Assertion synthesis is technology that automatically creates high quality assertions to capture design constraints and specifications, and creates functional coverage properties that expose holes in the testbench.”

In the DeepChip post, ESNUG 509 Item 7, the user states:

“So how useful is assertion synthesis really? It seems to be just another add-on task involving pricey add-on tools when you can only generate your assertions very late after most of your verification is done.”

It’s obvious that if you intend to employ Assertion-based verification as a methodology, you need to generate high quality assertions. But when, how many and by what method?

It got me thinking about where the real barriers exist in deploying a robust ABV methodology.

  • Assertion Development

In reading various ABV articles, whitepapers, etc it is generally assumed that writing assertions is complex and time consuming; you have to learn a new language, write useful assertions and spend time debugging them.

A useful assertion model must contain enough assertion properties and cover properties to ensure the design is functioning correctly and to ensure all aspects of the design have been tested.

To ease the pain of deploying ABV,  we need to solve the issue of the time/effort/knowledge required to develop a robust assertion model.

  • Capturing Design Intent

In Paul’s article he states:

“The RTL and test specifications are enhanced to include assertions and functional coverage properties. These are statements that define the intended behavior of signals in the design.”

What I inferred from this statement is that the design intent must be captured and done so according to the specification. In ABV, capturing design intent is the creation of the assertion, assume and cover properties to model the designer’s intent as he interprets the specification. Note I say the designer’s intent since, after all, who knows a design better than the one(s) who developed it. To be complete, this includes individual design modules, their interfaces and the system level sequences of the design.

Designers must create a robust ABV model which captures their design intent according to the specification.

  • Functional Coverage Metrics

Designers make mistakes (I can say this, because I’ve been there, done that!). They don’t always interpret a specification correctly (done that too!). They don’t always implement it correctly (no comment!). Verification engineers are tasked with finding and eliminating those mistakes thoroughly and quickly. But when is a verification engineer’s job done? How does one know when enough stimulus has been generated? The verification industry has all types of tools and methodologies to generate stimulus and explore the state space around a design and to do it as efficiently as the current state of the technology allows. But without coverage metrics, verification engineers are flying blind. When the test plan is exhausted, all the assertions triggered and coverage properties covered in a robust ABV model there’s nothing left to do. Did you completely cover the state space. Of course not, but at least the design matches the specification as interpreted by both the designers and verifiers.

Verification engineers must have the infrastructure in place to efficiently and completely target ABV  properties to know when the job is done.

  • When should you create assertions?

How and when you generate the ABV model of the design is going to make a huge difference in your ability to increase first pass silicon success rates.  The published benefits of ABV are:

  • Monitor a design to ensure correct functional behavior
  • Detect design errors at their source and quickly
  • Can be used across simulation, formal verification, and emulation
  • Captures design intent and travels with the design

At Solid Oak, we develop ABV tools with the main focus of capturing the designer’s intent and presenting a robust ABV model with functional coverage metrics to the verification task. These assertions are available for all the phases of verification: simulation, formal verification and emulation;  and are generated along with the RTL model.

Without knowing the intent,  the verification task is nearly impossible, debug is slower and functional errors go undetected. With the intent captured, the verification task is  manageable and more importantly, measurable.

However you decide to deploy the ABV methodology in your development process, by manual creation or by automatic tool generation, be sure to match your expectations with the methodologies benefits and its ability to improve your first silicon success rate.

Jim O’Connor – President, CEO and Founder Solid Oak Technologies

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>