Verifying A Gigabit Ethernet Switch Using SMV

1
Verifying A Gigabit Ethernet Switch Using SMV

• Yuan Lu Mike Jorda
• Enterprise Switching
• Broadcom Corporation

2
Outline

• Introduction
• DUT L2 table logic in BCM5690
• Model Reduction
• Design Debugging
• Error stimulus and error visibility
• Improving Model Checking
• Rigorous performance analysis
• Verifying scenario with multiple requests
• Conclusion

3
Introduction

• The L2 table logic is difficult to verify due to
• dynamic nature and concurrency
• lack of exact specification
• Our verification decision
• discover bugs, not prove the design
• based on Cadence SMV (M98)
• Related Work
• Regular structures (M98, CCLW99, C98)
• pipelines, arbiters, and arithmetic circuits
• gt100 high-quality bugs in Pentium IV (B01)
• Commerical formal verification tools
• Jasper, Real Intent, Synopsys, 0-In, etc.

4
Design Micro-architecture

• L2 table logic supports
• a hash table maps addresses to ports
• 2K buckets with 8 entries per buckets
• can statically or dynamically update entries
• can statically or dynamically age out entries

5
Verification Difficulties

• Learns can be cancelled due to states
• impossible to predict without knowing states
• difficult to write checkers
• Lookups, learns, and agings are prioritized
• starvation should be checked
• There are many corner case scenarios
• aging is starved
• aging happens on the last bucket
• Lesson difficult to verify by simulation
• Our goal is to discover bugs
• lack of gold model, and exact specification

6
Model Reduction

• Verification decisions
• Write as many as possible properties
• at least 1 property per two signals
• Apply aggressive abstraction
• shorten debugging time
• Model reduction
• Hash table buckets are symmetric when aging is
  disabled
• Similar symmetry exists within a bucket
• The 48-bit MAC addresses can be reduced
• Requests from ports are independent
• not all the ports are modeled

7
Model Reduction (Cont)
After model reduction
8
Environment Simplification

• Difficult for SMV to verify the model with
  multiple packets to a port
• gt84 clocks separate two packets to a port
• Interference among ports is our focus
• Our decision model one packet every port
• discuss scenario with multiple packets later
• Model reduction are accomplished by recoding the
  RTL in ePerl
• reconfigurable
• properties are also written in ePerl

9
Design Debugging

• Over 200 properties are written
• 35 abstracted configurations are verified
• Runtime ranges from 15 sec to 2 hrs
• 4 man-month to finish the process
• Total 22 bugs are found
• A parallel simulation effort at higher level
• 4 bugs are found by simulation
• stimulate the bugs and make them visible
• Are these bugs high-quality bugs?

10
Bug Quality

• To understand bug quality, we defines
• Error stimulus (ES)
• measures the shortest way to trigger bugs
• Example ES(B)1/2K where packet B goes to the
  same bucket of an existing packet A
• Error visibility (EV)
• measures the shortest way to propagate the bug to
  the block interface
• Our definition is limited and ad hoc
• further research is under discussion

11
Bug Quality
0
-2
-4
-6
-8
-10
-12
-14
bugs
-16
5
10
15
20
12
Rigorous Performance Analysis

• Design assumption
• Average 21 margin is reserved for learns
• SMV find case where learn happen very late
• A similar trace on the full model shows that the
  margin for learns reduces to 3
• not a bug, but potentially destructive
• Impossible to catch by simulation
• even difficult to see in chip validation
• Consequence designer fix the assumption

13
Verifying Scenario with Multiple Request

• Intuition Residue states from first packet
  affects subsequent packet processing
• Idea we model residue states using initial
  states on the abstract model, i.e.,
• Q ? I where I is set of initial states
• Finding Q is computationally expensive
• Instead, we compute projection of Q on a subset
  of variables
• we compute the reachable states Q for this
  subset using I
• use Q ? I to approximate Q
• Consequence One bug is found

14
Conclusion

• Using SMV, we have discovered 22 bugs
• Some bugs are difficult to catch using
  traditional simulation methods
• Formal analysis can help to analyze difficult
  performance issues
• The design has been in production for over two
  years without bugs in this block
• Left questions
• Can we automate this process
• What is formal definition of bug quality