You are on page 1of 27

Assertion-Based Verification

Introductory Tutorial CSE 575/577 Theo Theocharides, Spring 05

Ack: Bruce Wile, Richard Stolzman

Assertion-Based Verification
ASIC and SoC verification has kept many engineers awake on many a night. Ever-increasing design complexity Disproportional Design Growth
Designer productivity underwent a breakthrough gate-per-hour increase A comparable breakthrough did not happened in verification productivity.
Theo, Vijay PSU 2005

Assertions What are they?


An assertion is an expression that, if false, indicates an error. Used for debugging by catching can't happen errors. A conditional statement that checks for specific behavior and displays a message if it occurs. Generally used as monitors looking for bad behavior may be used to alert for desired behavior as well For our purposes: A statement about a specific functional characteristic or property that is expected to hold (or not) for a design.

Theo, Vijay PSU 2005

Assertion-Based Verification
Assertion-based verification (ABV) solutions are gaining in popularity Assertions are statements of designer assumptions or design intent Assertions should be inherently reusable These supplement, not replace, traditional simulation tests Design and verification engineer knowledge is leveraged Both design observability and design controllability can be improved Assertions enable formal verification

Theo, Vijay PSU 2005

Assertions - Evolution
Were added during verification to monitor conditions that were otherwise hard to check using simulation. Used to simplify the debugging of complex design problems. Assertion monitors can be thought of as internal software test points Used to improve observability,
ability to observe bugs once they are triggered by a simulation vector.

Bugs caught almost instantly at the point they happen


Theo, Vijay PSU 2005

Assertions - Revolution
Assertions are being used successfully with formal verification. Assertions as targets for formal verification is used to improve controllability Low controllability is the problem that occurs when the number of simulation vectors needed to penetrate and thoroughly stimulate the potential functional mistakes buried within a design becomes prohibitive.

Theo, Vijay PSU 2005

Example 32-bit Comparator

Theo, Vijay PSU 2005

Example 32-bit Comparator


For a worst-case single-bit bug, you need 264 vectors (!!!). The fastest simulator today would take over half a million years to verify. Using an assertion, the same verification is completed in less than a minute. Often impossible to create a minimal set of sequential patterns (input vectors) that
adequately sensitize a design in the correct way, controls all of the sequential elements needed to trigger errors using simulation.
Theo, Vijay PSU 2005

Benefits
Provides internal test points in the design Simplifies the diagnosis and detection of bugs by localizing the occurrence of a suspected bug to an assertion monitor, which is then checked Allows designers to verify the same assertions using both simulation and formal verification Increases observability when simulation is used Increases both controllability and observability when formal verification is used.
Theo, Vijay PSU 2005

Assertion Benefits Example


Simple traffic light controller at the corner of Elm and Main streets Light should stay green for one minute in each direction when the intersection is busy. Sensors are to be installed to detect traffic on both Elm and Main streets.

Theo, Vijay PSU 2005

Nightmare on Elm Street


Wait 60 seconds

Figure 1.2: The Traffic Nightmare

No

Main Street Traffic?


Yes

Yes

No

Elm Street Traffic?

Main Street turns green Elm Street turns green

Theo, Vijay PSU 2005

VHDL Code
library ieee; use ieee.std_logic_1164.all; entity traffic is port ( clk : in std_ulogic; -- Clock reset : in std_ulogic; -- Async Reset timer_pulse : in std_ulogic; -- The timer pulse, '1' indiates timer expiration Main_Street : in std_ulogic; -- Indicates when traffic is present on Main St. Elm_Street : in std_ulogic; -- Indicates when traffic is present on Elm St. Light_Direction : out std_ulogic_vector(1 downto 0) -- "01" Indicates that Main St. should be green -- "10" Indicates that Elm St. should be green ); end traffic; architecture rtl of traffic is type state is (main, elm); signal current_state_din, current_state_dout : statestd_ulogic_vector(1 downto 0); begin -- rtl -- purpose: Determines when the light should change -- type : combinational -- inputs : timer_pulse, Main_Street, Elm_Street, current_state_dout -- outputs: current_state_din

dataflow_proc: process (timer_pulse, Main_Street, Elm_Street, current_state_dout ) begin -- process change_light current_state_din <= current_state_dout; -- When the timer expires, evaluate the traffic situation if timer_pulse = '1' then if Main_Street = '1' then current_state_din <= main01; elsif Elm_Street = '1' then current_state_din <= elm10; end if; end if; end process dataflow_proc; Light_Direction <= "01" when current_state_dout = main else "10"; -- purpose: creates the registers for current state -- type : sequential -- inputs : clk, reset, current_state_din -- outputs: current_state_dout reg_proc: process (clk, reset) begin -- process register if reset = '0' then -- asynchronous reset (active low) current_state_dout <= main01; elsif clk'event and clk = '1' then -- rising clock edge current_state_dout <= current_state_din; end if; end process reg_proc; end rtl;

Theo, Vijay PSU 2005

Possible Problem?
Encoding of internal state machine uses 2 bits to encode two legal states State encoding however is identical to light direction, unlikely to be documented between Design and Verification Engineer Need assertion to ensure that Flip Flops will never enter illegal states, as it might affect downhill logic!
Theo, Vijay PSU 2005

Timing, Area, Power met, but


Figure 1.4 Circuit view of functionally bad traffic signal
clk reset

reg_ proc latch Main_Street timer_pulse Elm_Street

Light_Direction(o)

Light_Direction(1)

Theo, Vijay PSU 2005

How to uncover such bugs?


At a small scale design, it is easy to see the bug evolving. As designs grow, it is a true struggle. Assertions help catch these types of bugs They operate independent of attempted test cases

Theo, Vijay PSU 2005

Assertion Checkers
Checkers check the assertion conditions
Checker fire on indications of bugs (e.g., FIFO write when full) Improve observability but still rely on tests for stimulus

Certain types of checkers can be inferred directly from the RTL code
Example: Arithmetic overflow on a computation Example: Proper synchronization across an asynchronous clock domain boundary

The most valuable assertion checkers come from information in the designers head
It must be easy to capture assertions

Theo, Vijay PSU 2005

Assertion Capture
Checkers can be written in many ways In a testbench language (C, C++, e, Vera, etc.) Directly in RTL (Verilog or VHDL) With RTL assertion constructs (VHDL, SystemVerilog) In a formal property language (Sugar, ForSpec, etc.) Embedded in RTL with pseudo-comments Assertion capture should be as easy as possible Designers dont want to learn a new language Assertion checker libraries provide a lot of leverage

Theo, Vijay PSU 2005

Complete ABV Flow


RTL Design RTL Design Automatic RTL Checks

Assertions

Assertion Assertion Library Library

Assertion Compiler

Simulation

Testbench Testbench

Standard Verilog Standard Verilog Simulator Simulator

Coverage Coverage Reports Reports

Formal Model Compiler

Formal Verification
Static Formal Verification Dynamic Formal Verification Formal Formal Metrics Metrics

Theo, Vijay PSU 2005

Open Verification Library


Standard method of defining more complex assertions Specification mechanism was needed for both simulation and formal tools without the need for proprietary languages. Assertion library for open source standardization. OVL is the only existing assertion-specification standard that currently works with any IEEE1364 (Verilog) and IEEE-1076 (VHDL) compliant simulator
Theo, Vijay PSU 2005

OVL Assertions

Theo, Vijay PSU 2005

Assertions
In its simplest form, an assertion consists of the function to be monitored. Assertions can be easily implemented in Verilog or VHDL by the designer Why any special assertion language or method is needed at all?
Reusability and simplicity

Ideal of assertion-based verification goes beyond function capability to include usability and methodology
Theo, Vijay PSU 2005

Example
Consider a simple assertion to verify that a certain logical condition cannot happen. Performed by assert_never. While a designer could create an assertion to check for this condition in a few lines of Verilog or VHDL code, the OVL library module for assert_never is over a page in length
Theo, Vijay PSU 2005

Why the complexity and the library?


OVL assertions will not affect design behavior or synthesis results. Assertions can be disabled, a level of severity for the error can be easily specified or the number of failures counted. It quickly becomes apparent that a wellconceived and well-defined library of assertions has notable benefit. By selecting an assertion from a library, a standardized set of functionality and user options is provided.
Theo, Vijay PSU 2005

Example
Consider the verification of a request acknowledgement. For a design to function correctly, after a request condition (req) is asserted, an acknowledge must occur after 3 and before 7 clock cycles have occurred. The Verilog example is given using the OVL assert_frame module, using the defaults for reporting
Theo, Vijay PSU 2005

Example

Theo, Vijay PSU 2005

Looking Ahead
Open Verification Library
a consistent method of reporting and controlling assertions

Sugar (Formal Property language)


express abstract, higher-level specifications of design functionality.

SystemVerilog Assertions
add a native assertion construct and capability
Theo, Vijay PSU 2005

Summary
RTL assertions are used to capture design intent in a verifiable form Portable monitors that check for correct behavior During simulation, assertions improve observability coverage, making the source of an error evident. Simulation debug time is greatly reduced. Improve controllability coverage. Help explore the equivalent of billions and billions of input patterns without requiring test vector creation. Same assertions are used for both simulation and formal verification

Theo, Vijay PSU 2005