Abv.docx

What is assertion-based verification? Assertion-based verification (ABV) is a technique that aims to speed one of the most rapidly expanding parts of the design flow. It can also be used in simulation, emulation and silicon debug. Research has suggested that verification can take up 70% of the time and cost of a full design cycle and that, within that, functional verification can take up more than half of the verification time. A number of studies have concluded the use of ABV reduces functional verification dramatically compared with traditional methods. One of the most widely cited studies is from a 2000 paper presented at the 12th International Conference on Computer Aided Verification by IBM Research in Haifa, Israel, which claimed a 50% reduction in verification effort through the use of the same formally derived assertions during the unit, subsystem and system verification phases. However, a distinction must be drawn between the use of assertions and their integration within a coherent and effectively implemented methodology. To understand this, we first need to consider assertions in isolation and the challenge they present.

What are assertions? One way of considering assertions is to say that they are active comments. Where design and verification engineers have historically inserted passive code into a design to describe the intent of what is being exercised at a particular point in RTL or testbench code, assertions are “executable specifications”. They describe either legal or illegal behavior that can be observed at the point of their insertion by tools, and then flagged as having passed or failed. In itself, this is an easy-to-grasp extension of how comments work (and indeed passive comments are still added to assertions to ease communication as to their purpose between various participants in a design project). They are well suited to control signals because they are inherently specific. In addition to their specification aspect, assertions should also include some coverage properties to help ensure thoroughness of the verification and later aid in the gathering of metrics that help to assess not only their benefit on an individual project but also how well the technique is being generally implemented. Assertions are essentially produced in three forms.   

The design engineer will insert them in the main design file alongside the code to be verified. The verification engineer will insert them in the bind files used as part of the verification process. A third party – a standards group or a tools vendor – will provide a library of off-the-shelf assertions for common use-cases. The most commonly used non-proprietary library is the Open Verification Library (OVL), originally developed by Accellera (now the Accellera Systems Initiative). Assertions are today main written in two languages (although historically a wider range has been used).



SystemVerilog Assertions (SVA) is a subset of the SystemVerilog (IEEE 1800) combined hardware description and verification language, and is now by far the most popular format.  The Property Specification Language (PSL) (IEEE 1850) is predominantly used by engineers working in VHDL environments, but also has variants for SystemC, Verilog and SystemVerilog. There are then two types of assertion.  

Concurrent assertions must always be satisfied by a design. Temporal assertions must by satisfied by the design under certain defined (often clock-based) conditions. These conditions can either contain an individual set or a sequence of sets.

What are the benefits of assertions? The benefits of assertions fall into four broad categories.

1. Reducing verification time In 2002, Richard Stolzman of Verplex (now part of Cadence Design Systems) calculated that it would take almost 600,000 years for a one million-cycle-per second simulator to check every possible single-bug error in a 32bit comparator. Even allowing for increases in computational power since then, the exclusive use of such formal verification strategies remains unrealistic. By focusing parts of the verification process on intent rather than every possible configuration, assertions can inherently reduce the overall cycle time massively, when they are properly used and implemented with sufficient coverage.

2. Catching errors earlier By encouraging designers to include assertions at the block level, they raise the abstraction level of the overall verification process above a point where the designer might consider his or her work on a subsystem to be complete and ready for hand-off to the verification engineer. Not only design time but also cost can be cut by capturing errors before they require a larger-scale respin of RTL.

3. Focusing the design effort Designers who have worked with assertions say that the process has forced them to concentrate more closely on realizing a project’s objectives. Similarly, the early incorporation of assertions within RTL – as opposed to those assertions that verification engineers later develop for testbenches – improves communication between the teams working on different aspects of a design flow. For example, they can prove particularly useful as prompts when verification engineers are drafting plans and testbenches.

4. Pinpointing sources of error Assertions should be coded closely to those elements in the design that they verify. Then, when they do flag an error, it is easier to trace it back to its source.

What are the challenges with assertions? Assertions have obvious potential benefits, but the challenges they present are less immediately apparent. In broad terms, these challenges can be split into four categories.

1. Implementation A major problem during the initial phase of the adoption of assertions was their inconsistent implementation. This was especially the case where designers with a consequently more limited understanding of verification strategies were asked to write them. Assertions would be inserted at some parts of the RTL, but not others. As much as they can focus a designer on delivering intent, those designers could equally fall prey to real-world pressures (e.g. schedules) that meant their coding was considered a lower priority, or was simply forgotten. This could also introduce some confusion for verification engineers, with incomplete sets of assertions directing their attention to limited areas of the overall intent. Moreover, even when assertions were inserted, they sometimes lacked appropriate documentation and, more damaging, coverage information. This problem has declined given that assertions have now been in use for more than two decades, but it has not entirely disappeared.

2. Coding and debug

A certain level of language proficiency is needed for either SVA or PSL to take full advantage of assertions. This is not always available within the design team – at least not on the scale that may be needed for a complex project. The languages have their own quirks and twists. Many design managers feel they must balance the need to master the technologies against the time that it may take productive engineers with projects in hand to gain that mastery. Meanwhile, even trained SVA users often say that they find the language difficult to work with, both for coding and debug. Among designers, one consequence of this is that they will tend to write ‘simpler’ (i.e. one/two-cycle assertions) than may be optimal. Verification engineers also complain that composing temporal SVA assertions is especially challenging.

3. Customization The flexibility of off-the-shelf assertions is arguably an extension of the coding issue, but still merits consideration in its own right. The OVL provides a set of standard assertions for common use-cases, but the increasing complexity of subsystem and system design has led to ever greater complaints that they lack an ability to be customized to meet rapidly changing design intent requirements. The same is said of the assertion libraries provided by vendors which, though more regularly updated, are also engaged in trying to keep up with the design landscape, particularly as consumer devices require ever increasing functionality. Customization – and the subtleties it therefore requires – again stresses the need for design and verification teams to maintain sufficient local expertise in assertion languages.

4. Metrics Any assertion process must have a structured way of reporting and tracing errors, a working coverage database, and techniques that allow for thorough ongoing analysis both within and across projects, as well as a tightening of the integration between simulation, emulation and verification. ABV must not simply do its job but also be seen and acknowledged to have done its job, if the technique is to gain currency within the user company.

Why do I need an assertion-based verification methodology? In a DAC 2008 Accellera workshop, Harry Foster of Mentor Graphics suggested four questions that companies should ask themselves to assess how well they were balancing the benefits of and challenges with assertions, and whether they were fostering the right strategy for their use: 1. What is required to mature a project team’s ABV skills for successful adoption? 2. What needs to be considered in terms of a project’s ABV infrastructure (beyond commercial tools)? 3. What metrics need to be defined and gathered to measure progress? 4. What benefits are real industry projects seeing using OVL/SVA/PSL? The leading tool vendors now provide ABV methodology structures within their simulation, verification and emulation software suites. There have also been a number of useful attempts to produce software that automates the generation of assertions or makes SVA easier to compose by using a graphical environment. Users can leverage all of these technologies to gain great benefits from assertions and ABV. But even as more and more companies claim to use the technique, there remain many who use assertions on

an as you go basis believing they are operating ABV, but still lacking a true methodology. Others have methodologies which could be made more effective.

What else can I do with assertions? Assertions are often thought of as a technique that is used to get a design right before it is committed to silicon. But if you are prepared to carry the extra manufacturing cost, it’s possible to synthesize assertions into logic gates that get built into the final chip. Careful design of the assertions can improve the controllability and observability of your logic design, making it easier to find deeply buried bugs during post-silicon validation. There’s more on this topic here.