To - PowerPoint PPT Presentation

1 / 72
About This Presentation
Title:

To

Description:

Introduction To Formal Verification Subir K. Roy SDTC/SOC-COE Texas Instruments India Pvt. Ltd., Bangalore Organization of Presentation Motivation System on Chips and ... – PowerPoint PPT presentation

Number of Views:107
Avg rating:3.0/5.0
Slides: 73
Provided by: TexasInst
Category:

less

Transcript and Presenter's Notes

Title: To


1
Introduction To Formal Verification
Subir K. Roy SDTC/SOC-COE Texas Instruments
India Pvt. Ltd., Bangalore
2
Organization of Presentation
  • Motivation
  • System on Chips and IPs
  • Drawbacks of current verification methodology
    using simulation
  • Why formal verification?
  • Semantics/Models/Specification/Fairness
    Constraints
  • Temporal Logics/Computational Tree Logic
  • Binary Decision Diagrams

3
Organization of Presentation
  • Model Checking
  • Verification Flow
  • FV Related Issues Intrinsic Limitations of FV
    Tool
  • Important Verification Tasks
  • Model Generation / Design Abstraction
  • Compositional Verification using Assume-Guarantee

4
Organization of Presentation
  • IP Verification Issues
  • Other Care Abouts
  • Other Interesting Approaches
  • Verification Hierarchy
  • Conclusions

5
Motivation
  • Pentium SRT Division Bug 0.5 billion loss to
    Intel
  • Mercury Space Probe Veered off course due to a
    failure to implement distance measurement in
    correct units.
  • Ariane-5 Flight 501 failure Internal sw
    exception during data conversion from 64 bit
    floating point to 16 bit signed integer value led
    to mission failure.
  • Exception handling mechanism contributed to the
    processor being shutdown (This was part of the
    system specification).

6
SoCs IPs
  • Typical SoCs consist of different components.
  • CPU cores.
  • Memory cores.
  • DSP cores.
  • Different peripherals Interface buses.
  • BIST and DFT Logic insertion.
  • SoC realization turn around time (TAT) is rapidly
    increasing.
  • TAT reduction through design re-use.
  • Design Re-use Employ IP blocks from IP vendors

7
SoC Implementation Approaches
  • Vendor Based Approach ASIC Vendor/Design
    service group carries out implementation
  • Partial Integration System Designer implements
    proprietary application specific logic. ASIC
    Vendor integrates above with their cores
  • In house ASIC Vendor designs specialized
    cores. System Designer implements proprietary
    appli-cation specific logic, integrates cores
    verifies integrated design

8
Multiple Sources for IP
Reuse
  • Semiconductor houses
  • I/O Pad, Processor Core, Custom Logic, Memory,
    Peripheral Interface, DFT/BIST Cores
  • IP/Core Suppliers
  • Processor Core, Peripheral Interface, Analog
    /Mixed Signal blocks (DAC, ADC, PLL)
  • System Designer
  • Controller, Custom Logic, AMS blocks

9
Advantages of Core/IP based approach
  • Short Time To Market (pre-designed)
  • Less Expensive (reuse)
  • Faster Performance (optimized algorithms and
    implementation)
  • Lesser Area (optimized algorithms and
    implementation)

10
Where do bugs come from ?
  • Incorrect specifications.
  • Misinterpretation of specifications.
  • Misunderstanding between designers.
  • Missed cases.
  • Protocol non-conformance.
  • Resource conflicts
  • Cycle-level timing errors.

11
Implications on Verification
  • Abstraction of verification goals (Eg., Signals
    to Transactions, End to End Transactions)
  • Rigorous verification of each individual SoC
    component seperately
  • Extensive verification of full system
  • Automation of all verification activities
  • Reusability of verification components of unit
    Cores/IPs/VCs

12
Drawbacks of Simulation
  • Test bench creation manual, error prone and
    time consuming.
  • Simulation environment not re-usable.
  • Large simulation regression run times Hookup
    logic verification is done through long test
    sequences generated by controller.
  • Simulation based verification can be incomplete.
  • Design Errors Related to asynchronous and
    concurrent interactions between components.
  • Disadvantages Exponential number of test
    vectors to exercise all possible transitions
    between components.

13
Why Formal Verification?
  • Formal Approaches Model Checking
  • Formal Model (Finite State Machine).
  • Efficient Representation (Binary Decision
    Diagrams).
  • Exhaustive Search (whenever possible).
  • No test bench generation Reduction in DV cycle
    time.
  • Faster verification Completion at fraction of
    time compared to simulation when no memory
    blow-up.
  • Properties/Assertions when generic can be re-used
    and automatically generated.
  • Comprehensive verification and coverage High
    quality and confidence. Better ability to detect
    errors.

14
Paradigm Framework
Logic Based Formal Methods
15
Three-step process
  • Formal specification
  • Precise statement of properties
  • System requirements and environmental constraints
  • Logic - PL, FOL, temporal logic
  • Automata, labeled transition systems
  • Models
  • Flexible to model general to specific designs
  • Non-determinism, concurrency, fairness,
  • Transition systems, automata

16
Three-step process (contd.)
  • Verification
  • Checking that model satisfies specification
  • Static and exhaustive checking
  • Automatic or semi-automatic

17
Semantics of Finite State Systems
  • Semantics associates behaviors
  • Branching Time semantics
  • the tree of states obtained by unwinding the
    state machine graph
  • possible choices are explicitly represented
  • Linear Time Semantics
  • the set of all possible runs' in the system
  • the set of all infinite paths in the state
    machine

18
Non-determinism
  • This machine is nondeterministic in Idle state
    when req1 and req2 arrive.
  • Non-determinism due to abstraction
  • More than one behaviour for a given input

IDLE
rel2
rel1
req1
req2
req2
M2
M1
req1
19
Generating Formal Models
  • Pre-design activity
  • Automatic Translation from circuits/HDL designs
  • States decided by the latches/registers in the
    ckt.
  • Exponential blow-up in the size (State-explosion
    problem)
  • Usually abstractions required

20
Formal Specifications
  • Verification involves checking that a design
    model meets its specification.
  • Specification states what the system is supposed
    to do
  • Design describes how this is done

21
Formal Specifications
  • Specification
  • Describes unambiguously and precisely the
    expected behavior of a design.
  • In general, a list of properties.
  • Includes environment constraints.
  • Symbolic logic or automata formalisms
  • Consistency and Completeness

22
States, Labels, Transitions Runs
23
Specification of Hardware blocks
  • Properties and Constraints specify possible
    states and transitions
  • They state set of possible valid runs'
  • Valid runs are infinite sequences (or trees) of
    states and transitions
  • Formal specifications are finitistic and precise
    descriptions

24
Specification of Hardware blocks
  • Classification of Properties
  • Safety properties
  • Undesirable states are never reached",
  • Desirable things always happen".
  • Progress or Liveness Properties
  • Desirable state repeatedly reached"
  • Desirable state eventually reached"

25
Examples
  • Safety Properties
  • A bus arbiter never grants the requests to two
    masters
  • Message received is the message sent
  • Elevator does not reach a floor unless it is
    requested
  • Liveness Properties
  • Elevator attends to every request eventually
  • Every bus request is eventually granted
  • Every sent message was received

26
Fairness Constraints
  • In general, not every run in a state machine is a
    valid behavior
  • Arbiter example
  • the run in which master 2 is never granted the
    resource
  • But all runs are included in transition systems
  • Fairness constraints rule out certain runs
  • Example
  • Every request eventually considered
  • The clock tick arrives infinitely often

27
Properties of Hardware blocks
  • Temporal in nature
  • At any time only one units is accessing the bus
  • every request to access the bus is granted
    ultimately.
  • Two Kinds of TL
  • Linear Temporal Logic (LTL)
  • Time is a linear sequence of events
  • Branching time temporal logic (CTL, CTL)
  • Time is a tree of events

28
Syntax of CTL
  • Every atomic proposition is a CTL formula
  • If f and g are formulae then so are
  • Øf, (f Ù g), (f Ú g), (f g), (f g)
  • AG f - in all paths, in all state f (in all
    future, f)
  • EG f - in some path, in all states f
  • AF f - in all paths, in some state f (in every
    future f)
  • EF f - in some future f
  • A(f U g) - in all paths, f holds until g
  • E(f U g) - in some path, f holds until g
  • AX f - in every next state, f holds
  • EX f - in some next state f holds

29
Examples
  • AG (farm_go Ù high_go_B)
  • AGAF (farm_car AF(farm_go))
  • AG (mem_wr U mem_ack)
  • EF (req0 U grant0 )

30
EXAMPLE
  • Which of the following hold ?
  • AG p, EF!q, AX p, AG !q, EG !q, AX(p Ú q)

31
CTL Verification Explicit Enumeration
  • Iterative labeling algorithm that labels all the
    states with sub formulae.
  • Start from the initial labels of atomic
    propositions
  • Iteratively add sub formulae as labels with each
    state based on the following equations
  • EF p p Ú EX p Ú EX(EX p) Ú . . .
  • EG p p Ù EX p Ù EX(EX p) Ù . . .
  • E (q U p) p Ú (q Ù EX p)
  • Ú (q Ù EX(q Ù EX p)) Ú . . .

32
CTL Verification
E !c2 U c1
Phase 1 Label all states satisfying c1 with E
!c2 U c1 Phase 2 Label all states which do not
satisfy c2 and have a successor
state that is already labeled Phase 3 Iterate
Phase 2 until initial state is reached
33
CTL Verification
  • Iteration terminates since states and subformulae
    are finite.
  • If initial states are labeled with the given
    formula then the model checking succeeds
  • If it fails, counterexample can be generated

34
CTL Verification
  • Computation terminates
  • Computation involves backward breadth first
    traversal and calculation of Strongly Connected
    Subgraphs (cycles)

35
Complexity of CTL model checking
  • Algorithm involves backward traversal
  • Linear on the sizes of both formulae and model
  • Size of the model exponential in size of latches
  • Reduction Techniques
  • Symbolic Model checking Techniques
  • Compositional Verification
  • Symmetry based reduction

36
ROBDDs
x1
x2
  • Example
  • Properties
  • Unique representation of f for given
  • variable ordering
  • Checking f1 f2 ROBDD isomorphism
  • Shared subgraphs size reduction
  • Every path might not have all labels
  • Every non-leaf vertex has
  • path(s) to 0 and 1

f x1.x2 x3
x3
0
1
x1
x2
x2
x3
x3
x3
1
0
1
1
1
0
1
0
37
Variable Ordering Problem
f x1.x2 x3.x4 x5.x6

Order 1,3,5,2,4,6
Order 1,2,3,4,5,6
38
Operations on BDDs
  • Operators Take ROBDD arguments, return ROBDD
    result.
  • Complexity polynomial in BDD size
  • BDD size limiting factor in most applications
  • Ongoing research on avoiding BDD blowup
  • Variable ordering, Partitioned BDDs, Implicitly
    conjoined BDDs etc.
  • Quantification with BDDs
  • x1. f(x1, x2, x3) f(0, x2, x3)
    f(1, x2, x3)
  • x1. f(x1, x2, x3) f(0, x2, x3) .
    f(1, x2, x3)
  • Useful in Symbolic Model Checking

39
Model Checking Sequential Circuits
  • Given
  • A sequential circuit
  • Finite state transition graph
  • Flip-flops with next-state logic
  • Transition relation between present and next
    states
  • A property in specialized logic
  • Prove that MODEL satisfies SPECIFICATION
  • In case of failure, counterexample desirable

MODEL
SPECIFICATION
40
Example 3-bit Counter

Model State transition graph defined by X0
NOT(x0) X1 XOR(x1, x0) X2 XOR(x2, x0. x1)
x2
X2
x1
X1
Property State x0, x1, x2 111 is reached
infinitely often starting from state 000
x0
X0
Clk
41
CTL Properties
  • AG AF (x1 x2)
  • x1 or x2 is satisfied infinitely often in the
    future
  • 3-bit counter example
  • The state x0, x1, x2 111 is reached
    infinitely
  • often starting from 000
  • x0 x1 x2 AG AF (x0 x1 x2)

42
Basic Approaches
  • Explicit state model checking
  • Requires explicit enumeration of states
  • Impractical for circuits with large state spaces
  • Useful tools exist EMC, Murphi, SPIN, SMC
  • Symbolic model checking
  • Represent transition relations and sets of states
    implicitly (symbolically)
  • BDDs used to manipulate implicit representations
  • Scales well to large state spaces (few 100 flip
    flops)
  • Fairly mature tools exist SMV, VIS, FormalCheck
    ...

43
Model Checking
  • Reachability analysis
  • Find all states reachable from an initial set S0
    of states
  • Check if a safety condition is violated in any
    reachable state
  • CTL property checking
  • Express property as formula in Computation Tree
    Logic (CTL)
  • Check if formula is satisfied by initial state in
    state transition graph

44
Symbolic Model Checking
  • For 3-bit counter, set of states x0, x1, x2
    000, 010, 011, 001 can be represented by S
    (x0, x1, x2) S(x) x0.
  • BDD
  • Set of state transitions can be represented
  • by N (x0, x1, x2, X0, X1, X2) N (x, X)
  • (X0 x0) (X1 x1 x0)
  • (X2 x2 (x1. x0))

ox
1
0
45
Forward Reachability
  • Start from set S0 of states
  • Set of states reachable in at most 1 step
  • S1 S0 X x in S0 N(x, X)
    1
  • Expressed as Boolean functions
  • Given S0 (x0, x1, x2),
  • S1 (X0, X1, X2) S0 (X0, X1, X2)
  • x0, x1, x2 .
    S0 (x0, x1, x2)
  • N(x0, x1, x2, X0, X1, X2)
  • Given BDDs for S0 and N, BDD for S1 can be
    obtained

S0
S1
46
Forward Reachability
  • Compute S1 from S0, S2 from S1, S3 from S2,
  • Predicate transformer F Si1 F (Si)
  • Continue until Sk1 F (Sk) Sk
  • Least fixed point of F
  • Sk Set of all states reachable from S0
  • Computed symbolically -- using BDDs
  • Very large state sets can be represented
    compactly

S0
Reachable states
47
Backward Reachability
  • Give a set Z0 of states
  • Compute set of states from which some state in Z0
    can be reached.
  • Analogous to forward reachability with minor
    modifications

Z0
48
Checking Safety Conditions
  • Safety condition must ALWAYS hold
  • E.g. Two bits in one-hot encoded state cannot be
    1
  • Z set of states violating safety condition
  • Given S0 set of initial states of circuit,
  • Compute R set of all reachable states
  • Determine if Z intersects R, i.e. (Z R)
    0
  • If YES, safety condition violated
  • Satisfying assignment of (Z R)
    counterexample
  • If NO, circuit satisfies safety condition
  • All computations in terms of BDDs

49
Checking Safety Conditions
  • Start from Z set of bad states
  • Find by backward reachability set of states B
    that can lead to a state in Z
  • Determine if S0 intersects B

S0
B
R
S0
Z
Z
Forward Reachability
Backward Reachability
50
Symbolic Model Checking
  • Given a model with set S0 of initial states and a
    CTL formula f
  • To determine if f is satisfied by all states in
    S0
  • Convert f to g that uses only EX, EG, Ep U q
  • CHECK(g) returns set of states satisfying g
  • If g atomic proposition (e.g., x1. x2 x3),
    CHECK returns BDD for g
  • If g EX p, EG p, Ep U q, CHECK uses
    reachability analysis to return BDD for set of
    states
  • Worst-case exponential complexity
  • Finally, determine if S0 CHECK(g)

51
Model Checkers State of the Art
  • Symbolic model checkers can handle designs with
    500 1000 flip flops
  • For specific design domains, larger state spaces
    have been analyzed.
  • Defining properties in CTL/LTL can be difficult
    and error prone
  • Simpler property specification languages can help
    (E.g., PSL)
  • Monitor based model checking.

52
Queued Write Request Property of SCR

Wrt_Cmd_Decode
Master
Wrt_Arbiter
Slave
Wrt_Decode
4 deep fifo where write_cmd_req is queued in
11 deep fifo to queue in the current owner of a
processor as a slave.
53
Queued Write Request Property
  • Property on queuing of write requests from
    masters in a split bus transaction mode
  • When write command queue for a given master is
    empty, no write data transfers should originate
    from that master.
  • Abstraction for above property Behavior related
    to property needed 3 out of a total of 72
    submodules in SCR. 69 sub-modules were abstracted
    out.
  • Property FSM Assertions in OVL cannot capture
    this property. Separate Property FSM was coded.

54
Assume-Guarantee Basic Idea
Global Property defined on o2
o1
Guarantee
P
Decompose
i1
Assumption
i2

Q
o1
Assumption
o2
Guarantee
i2
P has to satisfy a local property on o1 which is
treated as an assumption by Q to prove the
global property on o2
55
AOF Design
  • Multiple Clock Processing (Root Module AO_CLK)
  • 16 bit Audio Data Processing (Root Module
    AO_CH)
  • Interrupt Request Processing (Root Module
    AO_IRQ)

56
Essential Module Interaction
Global_CLK
BCLKD LRCLKU LRCLKD
AO_CK_DIV
IO_CLK
AO_CH_SF
UDR
GAT
IO_CLK
AO_CH_DMA
STANDBY
DREQ
DACK
57
AOF Property
  • Informal Statement for Property 1
  • When writing parallel data, converting them to
    serial ones, and outputting, the under-run error
    occurs if the next parallel data are not written.
  • Precise Statement for Property 1
  • As long as DACK (Data Acknowledge) is received
    properly in response to DREQ (Data Requests), UDR
    (Data Starvation Signal) should never be
    asserted.

58
Assume-Guarantee Approach
  • Possible to use assume and guarantee in real
    designs.
  • Individual module verification cheaper.
  • Can fully exploit multiple clocks.
  • Promising for SoC designs and designs based on IP
    re-use.

59
Verification Flow
Original HDL Description
Design Abstraction Front-end
Reduced HDL Description
Feedback For Design Error Correction
IFV
IFV Script for Properties
No Design Error
Design Error
Verification Results
Counter Example
Logic Simulator
60
Problems in FV - Solutions
  • Simulation can handle entire designs.
  • State explosion in model checking limits designs
    that can be verified ( less than 500 1000 state
    bits).
  • Solutions
  • Design Abstraction
  • Reduced description (verification model)
  • Fewer state bits ensures completion of state
    traversal process.
  • In FV Divided we solve, united we blowup
    Partition to contain state explosion
    (Compositional Verification).

61
Important Verification Tasks
  • Property Generation and Verification Model
    Generation
  • Property Generation Identifying and defining
    properties that the implementation model has to
    satisfy.
  • Classification of Properties
  • Safety
  • Liveness
  • Fairness

62
Formal Verification Issues
  • Major Efforts
  • Reconstruct representations at various levels of
    abstraction.
  • Data flow graphs.
  • Data transfer graphs.
  • State transition graphs of controllers.
  • Module hierarchies.
  • Block diagram of modules and sub-systems.

63
Formal Verification Issues
  • Reconstruction
  • Reveals underlying interaction in modules.
  • More abstracted information.
  • Aids in defining properties.
  • Evolve verification strategies for each design.

64
Verification Model Generation
  • Implementation Model Transformation
  • For example, Multiple Clock Design ? Single Clock
    Design.
  • Carried out before verification model generation.
  • Design Abstraction
  • Implementation Model typically has two behavioral
    components,
  • Dataflow part and Control Part
  • Dataflow Part Generally easy to debug.
  • Control Part Dominating Source of Error.
  • Design abstraction targets dataflow part Remove
    as much as possible.

65
Design Abstraction
  • Removal or black boxing of module instances.
  • Modification of module interface and module
    declaration.
  • Partial removal of data flow behavior from some
    modules.
  • Convert conditional assignments into fixed
    assignments.
  • Reduce widths of some data registers and bit
    vector constants.
  • Property related design abstraction.
  • Conversion of multiple clock design into a single
    clock version.
  • Automatic generation of properties.

66
Areas Of Application For FV
  • BIST and DFT Logic Controllers and Hookup Logic
  • Buses and Bridges
  • VLIW processors new instructions and pipeline
    behavior
  • Shared memory controller
  • Floating point numeric coprocessor
  • Power management unit

67
Verification Issues
  • Verification Time 3 man months.
  • Design Complexity 700 state bits in the
    implementation model.
  • Implementation model in Verilog RTL
  • Familiarity Low.
  • Activity break up on 3 man months.
  • 2 man months To understand lowest level
    signals.
  • 1 man month For actual verification.
  • Approach clearly not suitable for SoC designs.
  • Concurrent design and verification efforts not
    possible in the above scenario.

68
Other Care Abouts
  • Bug hunting within IPs
  • Bug hunting with IPs
  • Coverage Issues
  • What do the designers want?
  • What do the functional verification engineers
    want?
  • What can the formal verification engineers do
    about these wants? Where do they position
    themselves?

69
Module Verification Issues
  • Verification team develops deep understanding of
    implementation model.
  • Design team codifies
  • Functionality of each module and interaction
    between modules in a suitable and easily
    understandable format.
  • Qualifies the defined set of properties as
    adequate.

70
Other Interesting Approaches
  • Bounded Model Checking
  • Unbounded Model Checking
  • Symbolic Simulation based Model Checking
  • Generalized Symbolic Trajectory Evaluation based
    Model Checking
  • Theorem Proving
  • Formal Verification of Hybrid Systems (Mixed
    signal designs - discrete and continuous
    behavior).

71
Verification Hierarchy
Higher-Order Theorem Proving
First-Order Theorem Proving
Coverage/ Expressive Power
Temporal Logic Based Model Checking
Assume-Guarantee based symbolic simulation/Model
Checking
Equivalence Checking
Equivalence Checking of structurally similar
circuits
Simulation
Degree of Automation
72
Conclusions
  • Verification and design needs to be done
    concurrently.
  • Need to influence implementation choices towards
    easing the formal verification process.
  • Need to capture formally design information at
    various levels of abstraction.
  • FV can prove properties which are difficult for
    simulation.
Write a Comment
User Comments (0)
About PowerShow.com