+ All Categories
Home > Documents > CaseStudy:FormalVerificationofanATM Switch Fabric usingVIS

CaseStudy:FormalVerificationofanATM Switch Fabric usingVIS

Date post: 26-Feb-2022
Category:
Upload: others
View: 3 times
Download: 0 times
Share this document with a friend
29
Case Study: Formal Verification of an ATM Switch Fabric using VIS 5.1 (of 29) Page Introduction 5.2 VIS Tool 5.3 FairisleATM Switch Fabric 5.5 Verification Strategy 5.7 Verification by Model Checking 5.9 Enhancement Techniques for Model Checking 5.18 Verification by Equivalence Checking 5.24 Conclusions 5.27 References 5.29
Transcript

Case Study: Formal Verification of an ATM Switch Fabric using VIS

5.1 (of 29)

Page

Introduction 5.2VIS Tool 5.3Fairisle ATM Switch Fabric 5.5Verification Strategy 5.7Verification by Model Checking 5.9Enhancement Techniques for Model Checking 5.18Verification by Equivalence Checking 5.24Conclusions 5.27References 5.29

Introduction

5.2 (of 29)

The Problem:• The need to produce high integrity communications systems

• ATM (Asynchronous Transfer Mode) switches are basic elements of state-of-the-art networks.

• Need a suitable technology to verify a whole ATM switch

Conventional Approaches:• Post-design Simulation, and Testing Cannot guarantee complete correctness

The Proposed Approach:

• Use Formal Verification based on Model Checking and Equivalence Checking in the VIS tool.

• Develop techniques to avoid state space explosion

VIS

VL2MV

Verification- model checking- equivalence checking- simulation

Synthesis- state minimization- state encoding- restruct, hierarchy

VIS Verification Tool

VIS: Verification Interacting with Synthesis

SIS: Sequential Interactive Synthesis

CTL: Computational Tree Logic

CTL SIS

Verilog

5.3 (of 29)

+ nondeterminism+ symbolic variable

5.4 (of 29)

Simulation in Verilog-XL

AWK program

Seq. equ. checking in VIS

Analyze counterexample in XL

Analyze counterexample in XL

Analyze counterexample in XL

Verilog RTL description

Synopsys-Verilog netlist description

VIS/XL-Verilog netlist description

Model checking in VIS

Model checking in VIS

Synthesize in Synopsys

EDIF generated by Synopsys

Design Flow and Formal Verification (VIS)

Fairisle ATM Switch Fabric

0

1

2

3

output port controllers

0

1

2

3

ATMSwitch

Fabric

dOut0ackIn0dOut1ackIn1dOut2ackIn2dOut3ackIn3

8

18

18

18

1

8

8

8

8

1

1

1

1

dIn0 ackOut0 dIn1 ackOut1 dIn2 ackOut2 dIn3 ackOut3

input port controllers

transmission lines

transmissionlines

1

frameStart

Unused Route Priority Active

5.5 (of 29)

Bit 67 5 4 3 2 1 0

Switch Fabric Behavior

receive frame-start signal

wait for cells to arrive

wait for frame-start signal

pass acknowledgment signal and send data cells to outputs

process header (arbitration)

5.6 (of 29)

1 frame cycle

Switch Fabric Implementation

Decoder

Priority filter

ACK

DATASWITCH

Arbiters

Timing

Data Out

Data In

Frame Start

AckAck Out In

Latches

ARBITRATION

5.7 (of 29)

Latches

Latches

Registers

Verification Strategy

5.8 (of 29)

• Objective: Impl. satisfies Spec. (property and equ. checking)- RTL description in Verilog (Specification)- Netlist description in Verilog (Implementation)- Properties in CTL (safety & liveness properties)

• Problems:- Verification cannot handle large circuits- Hard to consider all initial states of a circuit

• Strategy:- Model checking on abstracted models augmented with several

enhancement techniques- Equivalence checking of submodules of the circuit

Model Checking — Basic Idea

or

5.9 (of 29)

Model Checker

True / Counterexample

Property

Structure

Hardware Design

Behavior Model

Model Checking on the Fabric

5.10 (of 29)

Problem in property checking: state space explosion

- 210 latches in the design 2 210 states (assuming no state reduction skill by the tool)

Solutions:

• Environment abstraction: restrict the possible inputs according to the expected behavior (e.g. frames of 64 clock cycles)

• Component abstraction: abstract the target component by some rules (e.g. reduce the dataswitch paths from 8 bits to 1 bit)

Abstraction Techniques

Inputs

5.11 (of 29)

Inputs

ComponentAbstraction

Target CircuitsAbstracted Circuits

Environment State Machine(Environment Abstraction)

Abstracted Fabric

444

11111

1111

1

11

11111

ackOut0 ackOut1ackOut2 ackOut3

dIn0[0:3]

5.12 (of 29)

dIn3[0:3]

dIn0[0]dIn1[0]

dIn3[0]

4

dIn1[0:3] 4dIn2[0:3] 4

4

161632

Reg

iste

rs

Reg

iste

rs

4

2

12

frameStart

ackIn0ackIn1ackIn2ackIn3

dIn2[0]

1 dOut0[0]1 dOut1[0]1 dOut2[0]1 dOut3[0]

outputDisable[0:3] xGrant[0:3] yGrant[0:3]

Reg

iste

rsR

egis

ters

DATASWITCH

ARBITRATION

Prio

rit

y filte

r

Dec

oder

Tim

ing

Arb

iter

ACK

8 bits to 4 bits (arbitration)

8 bits to 1 bit (dataswitch)

Why do we need an environment machine?

5.13 (of 29)

1.Explicit input values required in CTL we use nondeterministic register variables to express inputs

2.No description of explicit time points in CTL we use explicit states to express timing information

3.Imitates the behavior of port controllers and hence constraints the number of possible inputs of the fabric

We use 8 state environment machine to ease the CTL expressions

8-state Environment Machine

S1 S7S5S4S3State

ackOut

5.14 (of 29)

ackIn

Frame Start

dIn

dOut

S0ts

S2th

S6te

How do we extract properties from Spec?

Example: Timing block

5.15 (of 29)

RUN WAIT

ROUTE

frameStart = 1 / routeEnable = 0

How do we extract properties from Spec?

5.16 (of 29)

Generally, properties are based on FSM specification

• Liveness (something good will eventually happen)Example: If framStart = 0 in “wait” state, the fabric will eventuallymove

to “route” state.CTL: AG (A (frameStart = 0 state = wait) U (state = route))

• Safety (nothing bad will ever happen)Example: If (frameStart = 0 and anyActive = 1) in “wait” state, its next

state must be “route”.CTL: AG (state = wait frameStart = 0 anyActive = 1

AX (state = route))

Properties CPU time (seconds)

Memory usage (MB)

Nodes allocated

Property 1 3933.9 40.3 84,199,139

Property 2 4550.7 4.3 90,371,031

Property 3 14.8 2.8 368,749

Property 4 3593.4 32.4 93,073,140

Property 5 833.0 4.5 28,560,871

Property 6 3679.7 40.9 79,687,784

Property 7 414.8 5.3 4,180,124

Property 8 1037.9 11.6 29,755,252

Unreasonable CPU time (1 to 2 hours machine time)

Develop enhancement techniques

5.17 (of 29)

Results of Model Checking

Enhancement Techniques of Model Checking

5.18 (of 29)

1.Cascade Property Division• Divide a property into several seq. related sub-properties• Penalty: Environment machines are required

2.Parallel Property Division• Split a property into several parallel sub-properties checked on

abstracted models stripped from the design• Penalty: Disassemble circuits at some specific locations

3.Latch Reduction• Reduce the primary inputs and outputs of state holding elements (i.e.

latches)• Penalty: Re-evaluate the timing behavior of circuits

Cascade Property Division (Example)

5.19 (of 29)

Property 7: If input port 0 chooses output port 0 with priority, the value on ackOut0 will be the input of ackIn0.

CTL: AG ((dIn0[3:0] = 0011 dIn1[1] = 0 dIn2[1] = 0 dIn3[3]= 0 state= S2) AX AX AX (ackOut0== ackIn0));

• sub-prop. 1: AG ((.....) AX AX AX (state = S5 xGrant[0] = 0 yGrant[0] = 0 outputDisable[0] = 0));

• sub-prop. 2:AG ((....) ackOut0 == ackIn0);

Easy proof: (sub-property 1 sub-property property 7

(+) enhance model checking by 41 times

(-) environment machine with outputs for intermediate signals (i.e. xGrant, yGrant, outputDisable)

Parallel Property Division (Example)

5.20 (of 29)

Property 3: From th+1 (state S3) to th+4 (state S6), the default value (zero) is put on the data output ports.

CTL: AG((state = S3 state = S4 state = S5 state = S6) dOut0 = 0 dOut1 = 0 dOut2 = 0 dOut3 = 0);

• sub-prop. i: AG (state = S3 state = S4 state = S5

(i=1,2,3,4) state = S6 dOut0[i] = 0);

Easy to prove: (sub-property1 sub-property2 sub-property 3 sub-property 4) property 3

(+) enhance model checking by 73 times (-) decompose the fabric circuit in 4 units

Parallel Property Division (cont’d)

1

1

1

1

fabric unit0

fabric unit1

fabric unit2

fabric unit3

dOut0[0]

dOut1[0]

dOut2[0]4 x

OR

ackOut0 0ackOut1 0ackOut2 0ackOut3 0

ackOut0 1ackOut1 1ackOut2 1ackOut3 1

ackOut0 2ackOut1 2ackOut2 2ackOut3 2

ackOut0 3ackOut1 3ackOut2 3ackOut3 3

ackOut0 1

ackOut1 1

ackOut3

ackOut2 1

dOut3[0]

1

1

frameStart

dIn2[0:3]dIn3[0:3]

dIn0[0:3]dIn1[0:3]

44

44

ackIn0

ackIn1

ackIn2

ackIn3

1

Prio

rit

y filte

r

444

11111

1111

1

11

1111

1 dOut3[0]

ackOut0 ackOut1

ackOut2 ackOut3

1

4444

444

Arbitration

5.21 (of 29)

dIn0[0:3] 4dIn1[0:3]dIn2[0:3]dIn3[0:3]

dIn0[0]

dIn2[0]dIn3[0]

Tim

ing

Arb

iter

Reg

iste

rs

Prio

rity fil

ter

outputDisable[0:3] xGrant[0:3] yGrant[0:3]

11dIn1[0] 1

11

Dec

oder

1 dOut3[0]

2

12

8 4 4

Reg

iste

rs

Reg

iste

rs

Reg

iste

rs

ackIn31ackOut1 1ackOut03

3

ackOut23 1 AcknowledgmentackOut33 1

frameStart

Dataswitch

dIn0[0]dIn1[0]

dIn3[0]

xGrant[0:3]

yGrant[0:3]dIn0[0:3] 4

dIn1[0:3] 4dIn2[0:3] 4

dIn3[0:3] 4

Arbitration

161632

Dec

oder

Reg

iste

rsR

egis

ters

Reg

iste

rs

Tim

ing

Arb

iter

Reg

iste

rs

4

2

12 outputDisable[0:3]

frameStart

Dataswitch

ackIn0ackIn1ackIn2ackIn3

dIn2[0]

1 dOut0[0]1 dOut1[0]1 dOut2[0]

Acknowledgment

Latch Reduction

5.22 (of 29)

• Influence of latches on model checking- Original fabric (210 latches impossible to check- Abstracted fabric (85 latches): up to 4000 seconds- Abstracted fabric unit (54 latches) 50 seconds

• Example — Property 2: Data bytes in a cell are transferred from input port 0 to output port 0 sequentially with 4 clock cycle delay.

CTL: EG (state = S3 -> AX AX AX AX (dOut0 = dIn0S3));

Reduce a set of primary output latches and check the property:CTL: EG (state = S3 -> AX AX AX (dOut0 = dIn0S3));

(+) Enhance model checking by 200 times using latch reduction (-) Re-evaluate the timing behavior

Enhanced Results of Model Checking

Properties CPU time w/o enhancement(s)

Enhancement techniques

CPU time with enhancement (s)

Speed- up

Property 1 3933.9 latch red. 27.8 142

Property 2 4550.7 latch red. 23.1 197

Property 3 14.8 - - -

Property 4 3593.4 parallel div. 48.9 74

Property 5 833.0 parallel div. 72.5 11

Property 6 3679.7 latch red. 34.1 51

Property 7 414.8 cascade div. 10.0 41

Property 8 1037.9 latch red. 46.1 23

5.23 (of 29

Principle of Sequential Equivalence Checking

- Combinational circuit: straightforward- Sequential circuit: must consider all initial states

Hard to handle large circuits

EQU ?

No

Counter-example

5.24 (of 29)

YesInputs Outputs

RTL Spec.

Netlist Imp.

Equivalence Checking

... ...

Arbiter0 ... Arbiter3

5.25 (of 29

Dataswitch0 ... Dataswitch3

Timing Arbiters Priority_decode Dataswitch Pause

Arbitration In_latches Out_latches Pause_dataswitch

• Objective: Impl. (Netlist) equivalent to Spec. (RTL)

Apply equivalence checking hierarchically on submodules of the switch fabric in a bottom-up fashion

Switch_fabric

Acknowledg.

Results of Equivalence Checking

5.26 (of 29)

Component CPU time (seconds)

Number of latches

Acknowledgment 1.4 0In_latches 4.2 32Out_latches 4.2 32Pause 4.0 32Arbiter_i 1.4 3Arbiters 13.3 12Priority_decode 26.9 16Timing 0.3 2Dataswitch_i 1855.8 16Arbitration 67860.0 30Dataswitch failed 64Pause_dataswitch failed 96Switch_fabric failed 190

Conclusions

5.27 (of 29)

• Simulation is still a powerful verification tool, but it is not sufficient

• Model checking efficiently used in the verification of high-level RTL design and control circuity

• Environment abstraction and component abstraction play an important role in easing model checking

• Property cascade division, property parallel division and latch reduction are efficient enhancement techniques to model checking

• Equivalence checking applied efficiently in the verification of synthesized submodules

Conclusions (cont‘d)

5.28 (of 29)

Human effort (not including time for learning the tool and development of abstraction/enhancement techniques):

The human time for formal verification is almost the same as that for simulation in a design.

Project phases Time(man-days) Code (# lines)

RTL description 10 580 (Verilog)

Netslist description 3 647 (Verilog)

Simulation 3 102 (testbench)

Model checking 3 200 (env. mach.)

Equivalence checking 1 0

Total 20 1529

References

5.29(of 29)

1. J. Lu and S. Tahar: Practical Approaches to the Automatic Verification of an ATM Switch Fabric using VIS; Proc. IEEE 8th Great Lakes Symposium on VLSI (GLS-VLSI'98), Lafayette, Louisiana, USA, February 1998, IEEE Computer Society Press, pp. 368-373.

2. J. Lu and S. Tahar: On the Formal Verification and Reimplementation of an ATM Switch Fabric Using VIS; Technical Report No. 401, Concordia University, Department of Electrical and Computer Engineering, September 1997.

3. Jianping Lu: On the Formal Verification of ATM Switches; MaSc Thesis, Concordia University, Department of Electrical and Computer Engineering, May 1999.

Technical report with source code available on-line at:http://hvg.ece.concordia.ca/Publications/TECH_REP/VIS_TR97/VIS_TR97.html

other papers on ATM switch verification can be found at:http://hvg.ece.concordia.ca/Research/APPL/atmsv.php


Recommended