Teaching Functional Formal Verification

Dr. Yaron WolfsthalManager, Formal MethodsIBM Haifa Research Laboratories

DAC 2002

Overview

Functional Formal Verification - Motivation and Taxonomy

Property Verification– Model Checking– The RuleBase tool, the Sugar language– The pragmatic view

Experience using RuleBase– IBM Server Group– IBM's industrial partners

Example: The Buffer Summary, final remarks, and answers to some questions which

students often ask

what you specified is what you envisioned– functional verification - specification level

what you designed (RTL) is what you specified– functional verification - implementation level

what you taped-out is what you designed in RTL– equivalence checking

what was manufactured is what you taped-out– production testing

specification

VHDL

transistors

silicon

"concept"

Taxonomy of Verification

Engineers build mathematical models of systems so they can predict their properties through the power of calculation

It's the power of mechanized calculations (eg. fluid dynamics, finite-element analysis) that makes the construction of complex physical systems possible

Formal Methods apply these ideas to the complex logical design of computer systems

Build a formal mathematical model of some aspect of the system

Calculate whether or not it has some desired property

Motivation for Functional Formal VerificationPhilosophy Behind Formal Methods

In the beginning there was Simulation– event-based– cycle-based– clever test generation

But... simulation alone has inherent limitations

Motivation for Functional Formal VerificationHistorical Perspective of Verification Solutions

Simulasaurus

Example: A 256-Entry Arbiter

256 bits

Req0

Req1

Req255

ID

Exhaustively simulating all input combinations...

... will require ~10^60 years on a simulator executing 1012 c/s.

COMPLEXITY

CHANGECHANGE

H/W CRISIS

Motivation for Functional Formal VerificationNeed for Methodology Shift Observed in Industry

FORMAL METHODS

Enter Formal Methods:Methodology for Managing Complexity

Covering the Design Space -with Formal Verification (2)

Covering the Design Space with Formal Verification (1)

Covering the Design Spacewith Simulation

Motivation for Functional Formal VerificationFormal Verification vs. Simulation (Unit View)

Property Specification:– Using a language for formally specify functional requirements

and behaviors of a chip interface protocols performance constraints

Analysis:– Using a procedure for establishing that the requirements

(properties) hold Note:

– Property Verification in general is not limited to Formal Verification!

In the context of this talk, however, we focus on FV, and in particular on an FV technique called "Model Checking"

The Property Verification Paradigma.k.a. ABV, Assertion-Based Verification

Conceptually, consists of two major elements

0

1

2 5

6

34

process

request

request

Model Checking - Formal Property Verification Doing it the Automatic Way

Type text

Type text

Type text

Type text

Type text

Represent design as a finite state machine Automatically calculate truth or falsity of specification by traversing the state

space

"if a request is received, it will be processed within 3 clocks"

Temporal relationships between signal values

External and internal protocols

Cache coherency/consistency policies

Mutual exclusion, absence of contentions

Correctness of arithmetic computations

Sample Properties

A method for mathematically proving functional properties ('"specifications") on the design. No tests required

Proving a property is showing that it holds for all possible input combinations, across all execution paths

Improved verification quality, reduced cost– less tapeouts– less bugs in the field– ideally, investment in sim+FV should remain flat

Key Formal Verification Method: "Model Checking"

H

L

Answer questions like – does my design satisfy these

rules... e.g. Request will be always Processed within 3 cycles

Inputs:– The design– The environment (irritator for its

inputs)– The rules (specification or properties to

verify)

Output:– A documented pass/fail answer

(with error trace)

Design(VHDL)

Environment (EDL)

Rules(Sugar)

Model Checker (RuleBase)

Pass/Fail

Model Checking Flow

Type text

Type text

Type text

Type textType text

Request will be always processed within 3 cycles

dataholdtrdy

frameirdy

Wrt Rd WrtRetry

RuleBase: The IBM Model Checker

Collection of powerful verification algorithms (BDD-based, SAT) under same front-end

Will verify a design, typically control logic, against a set of properties, producing documented fail/pass answer

Deals with industrial-size designs (a real issue)

GA July 1996 Version 1.4 released June 2002

Used throughout IBM, by external licensees, and in academia Friendly University Program

"We applied FFV to some extent on approximately 40 design components throughout the processor and found more than 200 design flaws at various stages and of varying complexity. At least one bug was found by almost every application of FFV. In most cases, FFV began significantly later than verification. It is estimated that 15% of these bugs were of extreme complexity and would have been difficult for traditional verification. In some cases, a late bug found in verification or in the laboratory was recreated and its correction verified efficiently with FFV. "

User Experience:Model Checking the IBM eServer p690

Formal Verification in Practice

Tool Perspective (capacity)– deal with state-space explosion

User Perspective– how to define "functional properties" (the

specification)

– how to define "assumptions on input"

– usability

Type text

Type text

Type text

Type textType text

Li

Hipi+1

Li+1

Hi+1

Formal Verification in Practice

Tool Perspective (capacity)– deal with state-space explosion

User Perspective– how to define "functional properties” (the specification)

– how to define "assumptions on input"

– usability

Type text

Type text

Type text

Type textType text

RuleBase - Under the Hood

Automated Reductions/abstractions– cone-of-influence– flip-flop equivalence

Advanced Model-Checking Algorithms– classic CMU algorithm– on-the-fly checking of safety formulas– bounded model checking– guided search

Formal Verification Challenges - Putting it to WorkThe Specification Perspective

Tool Perspective (capacity)– deal with state-space explosion

User Perspective– how to define "functional properties" (the specification)

– how to define "assumptions on input"

– usability

April 22, 2002– Sugar selected by Accellera as basis for IEEE standard specification language

Sugar Goes Public

dataholdtrdy

frameirdy

Wrt Rd WrtRetry

Verification Directives

Env. Modeling

Temporals

Expressions

Sugar-based tools already announced by:Cadence, Verplex, TransEDA, IBM

Natural, concise way for formulating properties English:

Whenever we see an assertion of signal req, followed by an assertion of signal ack, which is not followed by an assertion of signal cancel, we should see - starting at the next cycle - an assertion of signal start_trans, followed by between 1 and 8, not necessarily consecutive assertions of signal data_valid, followed by an assertion of signal write_end

Sugar:

always { req; ack; !cancel } |=> { start_trans; data_valid [=1..8]; write_end }

Specifying Properties - the Sugar 2.0 Language

Formal Verification Challenges - Putting it to WorkThe "Environment Assumptions" Perspective

Li

Hipi+1

Li+1

Hi+1

Tool Perspective (capacity)– deal with state-space explosion

User Perspective– how to define "functional properties"

(the specification)

– how to define "assumptions on input"

– usability

Why "Environmental Assumptions"

Avoiding "False Fails" ("False Negatives")– Only consider legal inputs to the system under test– Under illegal inputs, artificial, nonrealistic failures can be reported

Limiting search space reduce set of applicable input behaviors = reduce state-space size

env:read only

Designenv:write only

Design

How to Write "Environmental Assumptions"

Same syntax as "properties"– restrictions on input behavior

State-Machine syntax (w/non-determinism) Verilog VHDL EDL

Universities: Your installation of RuleBase currently supports only Sugar 1.0, which has only EDL flavor

Example: The Buffer

BUF is a design block that buffers a word of data (32 bits) sent by a sender to a receiver. It has two control inputs, two control outputs, and a data bus on each side:

Sender Rcvr BUF

StoB_REQ

BtoR_REQ

RtoB_ACK

BtoS_ACK

DI(0..31) DO(0..31)

Example: The Buffer

Sender Rcvr BUF

StoB_REQ

BtoR_REQ

RtoB_ACK

BtoS_ACK

DI(0..31) DO(0..31)

Communications (on both sides) takes place by means of a 4-phase handshaking as follows:

When the sender has data to send to the receiver, it initiates a transfer by putting the data on the data bus and asserting StoB_REQ (Server to Buffer REQuest). If BUF is free, it reads the data and asserts BtoS_ACK (Buffer to Server ACKnowledge). Otherwise the sender waits. After seeing BtoS_ACK, the sender may release the data bus and deassert StoB_REQ. To conclude the transaction, BUF deasserts BtoS_ACK.

When BUF has data, it initiates a transfer to the receiver by putting the data on the data bus and asserting BtoR_REQ (Buffer to Receiver REQuest). If the receiver is ready, it reads the data and asserts RtoB_ACK (Receiver to Buffer ACKnowledge). Otherwise, BUF waits. After seeing RtoB_ACK, BUF may release the data bus and deassert BtoR_REQ. To conclude the transaction, the receiver deasserts RtoB_ACK.

Property SpecificationNote: This is not About Sugar Syntax!

Basic functional properties Protocol properties Data-path properties

Yet I will make an attempt to expose you to Sugar 2.0

First Property:– Overflow (two reads without a write in between) cannot occur!

Second Property:– Underflow (two writes without a read in between) cannot occur!

Property-Based Verification of the Buffer:Basic Functional Properties

rule ack_interleaving {

formula "No overflow: RtoB_ACK is asserted between any two BtoS_ACK assertions " { always { [*] ; !RST & rose(BtoS_ACK) ; true }( rose(RtoB_ACK) before rose(BtoS_ACK) ) }

formula "No underflow: BtoS_ACK is asserted between any two RtoB_ACK assertions" { always { [*] ; !RST & rose(RtoB_ACK) ; true }( rose(BtoS_ACK) before rose(RtoB_ACK) ) }}

2.0

Property-Based Verification of the Buffer: Sugar Formulation of the Overflow/Underflow Properties

The protocol sequence must always be honored Focus on Request signals first

– Request signals will not be prematurely asserted– Once asserted, Request signals will stay high until acknowledged

Next, focus on Acknowledge signals– Acknowledge signals cannot spontaneously be asserted– Once asserted, an Acknowledge signal will stay high until the triggering

Request signal is turned off

Property-Based Verification of the Buffer:Handshaking Properties

rule four_phase_handshake_left

{ formula "A request can not be raised when ack is high " { always { [*] ; !StoB_REQ & BtoS_ACK ; StoB_REQ } (false) } formula "A request can not be lowered when ack is low" { always { [*] ; StoB_REQ & !BtoS_ACK ; !StoB_REQ } (false) } formula "An acknowledge can not be raised when req is low" { always { [*] ; !BtoS_ACK & !StoB_REQ ; BtoS_ACK } (false) }

formula "An acknowledge can not be lowered when req is high" { always { [*] ; BtoS_ACK & StoB_REQ ; !BtoS_ACK } (false) }

}

Property-Based Verification of the Buffer Sugar Formulation of the Handshaking Properties - LHS

2.0

Property-Based Verification of the Buffer Sugar Formulation of the Handshaking properties - RHS

rule four_phase_handshake_right

{

formula "A request can not be raised when ack is high" { always { [*] ; !BtoR_REQ & RtoB_ACK ; BtoR_REQ } (false) }

formula "A request can not be lowered when ack is low" { always { [*] ; BtoR_REQ & !RtoB_ACK ; !BtoR_REQ } (false) }

formula "An acknowledge can not be raised when req is low" { always { [*] ; !RtoB_ACK & !BtoR_REQ ; RtoB_ACK } (false) }

formula "An acknowledge can not be lowered when req is high" { always { [*] ; RtoB_ACK & BtoR_REQ ; !RtoB_ACK } (false) }

}

2.0

Basic transfer property Data sent to receiver (RHS) is the same as received from sender

(LHS) To specify in Sugar, we can use next_event (b)(f)

The next time that b holds, f must hold A conceptual extension of the next operator

Property-Based Verification of the Buffer:Data-Path Property

Property-Based Verification of the Buffer:Data-Path Sugar Property

rule checking_data{ "Data sent to receiver is the same data received from the sender in the last write" formula

{ always ((!RST & rose(BtoS_ACK) & DI(0)) next_event(rose(RtoB_ACK))( DO(0)) ) } formula

{ always ((!RST & rose(BtoS_ACK) & !DI(0)) next_event(rose(RtoB_ACK))( !DO(0)) ) }}

2.0

– Basic transfer property– Data sent to receiver (RHS) is the same as received from

sender (LHS) Question: How do you remember what was sent? Answer: You use an auxiliary state-machine for bookkeeping

Property-Based Verification of the Buffer:Data-Path Property - Another Way

.

sticky_bit: if rises, it stays active forever.

var tmp(0..31): Boolean;assign init(tmp(0..31)) := {0};assign next(tmp(0..31)) :=

IF rose(BTOS_ACK) THEN DI(0..31)

ELSE tmp(0..31) ENDIF;

Declare it

Initialize it

Give it a behavior

The Bookkeeping FSM ("Satellite"):Stores last input driven by sender

var tmp(0..31):boolean;assign init(tmp(0..31)) := 0;assign next(tmp(0..31)) := IF rose(BTOS_ACK) THEN DI(0..31) ELSE tmp(0..31) ENDIF;

rule checking_data{ "Data sent to receiver is the same data received from the sender in the last write" formula { Always { [*] ; !RST & rose(RTOB_ACK) }( DO(0..31) = tmp(0..31) ) }}

Property-Based Verification of the Buffer Sugar Formulation of the Data Transfer Property

2.0

.

sticky_bit: if rises, it stays active forever.

var sticky_bit: Boolean;assign init(sticky_bit) := {0,1};assign next(sticky_bit) :=

casesticky_bit : 1;else : {0,1};

esac;

Declare it

Initialize it(non-det. behavior)

Give it a behavior

This Syntax is Really the "Modeling Layer of Sugar"

//sticky_bit: //once asserted, stays active forever.

non-det. behavior

until asserted

a.k.a. EDL - Environment Description Language

F.A.Q.

What tutorials are available? What else can be done to address large state spaces? What is the typical size of design units that can be addressed? What kind of bugs are we after?

Tutorials

Sugar Tutorial – http://www.haifa.il.ibm.com/projects/verification/sugar/sugar_tutorial.pdf

Generalized Buffer– http://www.haifa.il.ibm.com/projects/verification/RB_Homepage/tutorials.html

New! Fresh Arbiter from the Server Group – contact Emmanuel Zarpas, zarpas@il.ibm.com

Design for Formal Verification: Proper Methodology is Useful for Overcoming Size Limitations

Verify control logic alone– leave datapath for simulation

Abstract out internal parts Degenerate design parts by limiting environment behavior Partitioning Modes

Partitioning for Model Checking (1)

Partitioning for Model Checking (2)

Practical for block-level verification ("designer-level verification") Practical also - with proper training - for

– unit-level verification of complicated control logic (up to 1000's of FFs)– system-level verification of abstract architectural models

Capacity (in terms of State Variables)

Unit

BB

BB

Unit (1000s)

B (10s)

B

BB

RTL

Cannot provide absolute guarantee of success– Done w.r.t. user-provided specification– On abstract model which may not fully capture reality

Focus on adding value to existing processes– Finding bugs ASAP!– Debugging, explore requirements

Falsification, Bug Hunting: A Pragmatic Approach

Avail

Predict

Sample Bug Found with RuleBase

The Rule:If Cmd is pending in the L2 Queue, eventually it will be routed to the L2

Bus Interface

L1 L2Cmd Prediction

Cmd Cmd

Avail

PowerPC Bus

L1/L2 Control

CPU

Summary: Teaching (Functional (Formal Verification))

Model Checking is accessible to engineering students– some will say: essential – prerequisites: Digital Systems / Logic Design

Property Verification via model checking is a powerful tool Start from the beginning

– design for formal verification– pragmatically approach your verification problem– thorough verification plan

Friendly RuleBase University Program!