Professional Documents
Culture Documents
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
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
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.
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.
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
No
Yes
No
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;
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
Light_Direction(o)
Light_Direction(1)
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
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
Assertions
Assertion Compiler
Simulation
Testbench Testbench
Formal Verification
Static Formal Verification Dynamic Formal Verification Formal Formal Metrics Metrics
OVL Assertions
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
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
Looking Ahead
Open Verification Library
a consistent method of reporting and controlling assertions
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