Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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

These are the Lecture Slides of Functional Verification which includes Reusable Verification Components, Verilog Implementation, Implementation, Autonomous Generation and Monitoring, Input and Output Paths, Verifying Configurable Designs, Reusable Test Harness, Testcase Specific Code, Abstraction etc. Key important points are: Introduction, Verification Using Rulebase, Brief Review, Genbuff, Modeling the Environment, Formulating Rules, Running Rulebase, Timing Diagrams, Partition Selection, Com

Typology: Slides

2012/2013

Uploaded on 03/22/2013

dhritiman
dhritiman 🇮🇳

4.7

(6)

107 documents

1 / 39

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Introduction to Formal
Verification using Rulebase
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27

Partial preview of the text

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