Over the past few weeks there have been a number of articles about assertions. Two really stand out for me. The first was from Howard Martin at Zocolo tech. Zocolo is a small Austin-based startup focused on increased productivity for engineers adopting and utilizing Assertion Based Design and Assertion Based Verification. In that article he says: Despite good promises, wide-scale use of ABV has not materialized because it is a difficult technology to implement and is perceived as marginally cost-effective. If it had been easy, everyone would have jumped on it by now.

Then a second article, well a blog actually from Mentor, related events associated with a person who had recently transferred from a design company to Mentor. In talking about a project that he had just finished he: overhea[r]d one of the design engineers say that he would never do another design project without assertions.  In fact, his opinion was universally shared among all the project designers.

So what’s with the difference of viewpoint? It seems to me as if it is at least tied to perceptions and expectations. What does a design team expect to put in, in terms of effort, and what do they hope to gain from it. In terms of that second team, here is what was reported: The team claimed that the extra time it took them to add assertions during the RTL coding stage was more than made up for by the reduction in debugging time during verification. Not only that, they claimed that often the act of adding an assertion forced them to think about the design in a different way and even exposed a design error prior to any form of verification.

This means that the design team was not looking to find additional errors, or to directly improve productivity, but indirectly in enabling them to do their job better. Martin also reflected on this and said: Key to understanding the problem is the difference in the terms "Using Assertions" and "Assertion Based Verification." He also quotes Harry Foster as saying: It is a myth that ABV is a mainstream technology.

What I see as common in both articles is summed up well by mentor: what I hear from various teams trying to adopt ABV often takes a more methodological bent, particularly related to the required steps for successfully integrating ABV into existing flows.

In other words, perhaps we should stop talking about the advantages of a particular assertion language or the concentration on tools, and start talking about how to use them effectively on things other than a FIFO. In this way all of the EDA vendors can unite in helping people understand the technology and how to go about insertion in a way that reduced people’s uncertainty about it.

Grow the market first, then try and sell you product.

-------------------------------------------------
Brian Bailey - keeping you covered