Introduction - Functional Verification - Lecture Slides, Slides of Computer Science

Download Introduction - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Introduction to Formal

Verification using Rulebase

Today's Topics

 Brief review

 Introduction to the GenBuff example

 Modeling the environment

 Formulating Rules

 Running Rulebase

RuleBase Model Checker

design (HDL)

environ. (EDL)

spec (sugar)

RuleBase

pass / fail

GenBuf Example

GenBuf is a design block that queues words of data (32 bits) sent by four senders. GenBuf then transmits the data to two receivers. The four senders are equivalent and the two receivers are equivalent.

STOB_REQ(0) BTOS_ACK(0) Sender0 DI_0_(0..31)

Sender

Sender

Sender

G E N B U F

STOB_REQ(1) BTOS_ACK(1) DI_1_(0..31) STOB_REQ(2) BTOS_ACK(2) DI_2_(0..31) STOB_REQ(3) BTOS_ACK(3) DI_3_(0..31)

BTOR_REQ(0) RTOB_ACK(0)

BTOR_REQ(1) RTOB_ACK(1)

Receiver

Receiver

D0(0..31)

GenBuf Recevier Description

 Communication w/ Receivers takes place by means of a 4-phase handshaking When GenBuf has data, it will choose a receiver (y=0 or 1) and will initiate a data transfer by asserting BTOR_REQ(y) ("Buffer to Receiver Requests y") When the receiver is ready, it will assert RTOB_ACK(y) ("Receiver to Buffer Acknowledge") One cycle after RTOB_ACK(y) is asserted, GenBuf will put the data on the data bus (DO(0..31)) The receiver will indicate to GenBuf that it has read the data by deasserting RTOB_ACK(y)  GenBuf should wait for RTOB_ACK(y) to be deasserted before it starts a new transaction  GenBuf uses a fair scheme to select the Receiver

Sender to GenBuf Signal Name (^) Description

STOB_REQ(0) Request Input for senders 0-

DI_0_(0..31) Data in for Sender

DI_1_(0..31) Data In for Sender

DI_2_(0..31) Data In for Sender

DI_3_(0..31) Data In for Sender

GenBuf to Sender Signal Name Description

BTOS_ACK(0..3) Acknowledgment for Senders 0-

I/O Specification for Sender

Other inputs to GenBuf Signal Name (^) Description

RST Reset Signal: Active High (set to 1 for 2 cycles then to 0)

CLK Clock (set to 1)

ERROR_FOUND(1..6) Set to 0

Other Inputs

Classification of Properties

 Functional correctness - does the arbiter issue a

grant within 4 cycles of receiving a request?

 Safety properties - does the arbiter only issue a

grant if a request is raised?

 Liveness properties - does the arbiter eventually

issue a grant for every request?

CTL Operators

 Path quantifiers  A - for all paths  E - there exists a path  Tense Operators  X p - p holds at the next cycle  F p - p holds sometime in the future  G p - p holds globally from the present time p U q - p holds until q holds

• Temporal Operators
• AX , AF , AG , AU , EX , EF , EG , EU

Sugar - Bounded-Range Operators

 AX[i]

Shorthand for n times AX

• AG(req -> AX2)
• AG(req -> AX AX ack )

 ABFi..j

Constrains AF between i and j clocks

• AG(req -> ABF1..2)
• AG(req -> AX(ack | AX (ack)) )

Sugar - sequences

 {e0,e1,e2,...}(f)  f must hold on the last cycle of all computations that agree with the sequence e0 at cycle 0, e1 at cycle 1, e2 at cycle 2, etc.

 Example: ”every req on cycle X that gets a gnt at cycle X+1 and doesn't get retried at cycle X+2, should cause busy to be active at cycle X+2"  AG {[*],req,gnt,!retry}(busy)

Sugar - until

 CTL A[q U r]

r must occur eventually

• strong operator: makes demand on terminating condition r can occur in the current state, in which case q may not appear at all q need not hold at the time r holds
• AG(req -> A[busy U ack] )

 Sugar q until r

Weak version: does not require r eventually occur  Sugar q until! r Strong version - equivalent to AU

Modeling the Environment

 Study block interfaces in detail

 Plan hierarchical structure of environment

models, grouping related signals & reusing

components where possible

 Decide how to model each input - which inputs

should be nondeterministic

 Code the logic in EDL

 Take time to verify environment model -

especially if complex

Key Environment Concepts

 Fairness

 Invariants