Connecting High Level Models and RTL: an Ongoing Battle

1
Connecting High Level Models and RTL an Ongoing
Battle

• Jesse Bingham
• Intel
• Feb 25 2009

2
Big Picture
FPV
Architecture
CDC, TOV
This red arrow is the problem de jour
RTL
Netlists
FEV
Layout/Backend
Diagram unapologetically stolen from Erik
3
Motivation for Formal Verification
Formal Verification (ideal case) full coverage
of design space
Formal Verification (real life) full coverage
in some areas
Simulation spot coverage of design space
Also stolen from Erik
4
Another Dimension
Formal specification
FEV Arithmetic FV _at_Intel
Todays Topic (formal)
Todays Topic (checker)
Property coverage
Traditional Simulation-based Testing
Theorem proving
Bounded Model Checking
Type-checking
State/behavior coverage
5
Overview

• Protocols naturally succinctly specified by
  high level models (HLM)
• In a sense, all RTL safety properties are
  captures by the HLM
• Actual HW design (RTL) is hand-written by
  engineers
• How do we establish that RTL adheres to its HLM?
• What does adherence even mean mathematically?
• Two approaches
• Checker HDL code that watches the design
  during simulation, raises alarms if it detects
  non-adherence
• Most of this talk is about checkers
• Formal Proof prove that checker can never ever
  ring alarm
• having the checker is obviously a prerequisite
  for formal proof
• Notoriously hard problem in FV
• but getting more and more important in HW design

6
HW Protocols

• Distributed components exchanging messages
• Control Oriented
• Cannot be specified by input/output relations
• State is king
• Typically message latency insensitive (though
  message ordering often matters)
• Naturally specified at high level using guarded
  command languages (Murphi, TLA, Unity, etc)
• well call this the high level model (HLM)
• we use Murphi, but this work is independent of
  the particular modeling language

7
HLM Guarded CommandsDijkstra 1975

• Guard predicate on states
• Command function mapping states to states
• Guarded Command (GC) a guard a command
• Command is only allowed to fire if guard is true
• Called rules or rulesets in Murphi

Rule go to park NOT raining gt location
nearest_park() end
Ruleset food FOOD have picnic hungry AND
NOT raining gt location nearest_park()
eat(food) end
8
HLM Behaviors Properties
enabled GC fires
initial state

• State invariants all reachable states are okay
• Cache always has at most one entry for each
  address
• More general safety properties
• Cache returns most recently written data to a
  read request
• Liveness (typically assuming fairness)
• If you send a read request, cache will eventually
  return data

9
Register Transfer Level (RTL)

• Clock/state accurate (or at least close)
• Pipelines
• Schedulers
• Special logic
• Design-for-test
• Clock gating
• Reset
• Written in hardware description language like
  System Verilog or VHDL (we use SV)
• Can be formalizes as finite state automata or
  Kripke structures we wont do that today

FV methods and CAD tools below RTL have advanced
to the point where one can (if they choose to)
safely think of RTL as the real Silicon
10
Refinement Map

• A function RM taking RTL states to HLM states is
  called a refinement map
• Intuitively, RM(r) is the HLM state that
  summarizes RTL state r
• Many-to-one in general
• Human writes this in our methodology
• Generalization RM depend on RTL signals at fixed
  offsets from current cycle
• Useful for dealing with RTL pipelines

11
Behavioral Refinement
a guarded command fires
initial state

HLM Behavior
Refinement map

RTL Behavior
one RTL clock cyle
reset state
Each RTL clock cycle corresponds to zero or more
guarded commands firing
12
Checking Refinement
GC_prediction(r)

Next
HLM
RM(r)
RM(r?)
?
r?
RTL
r
one RTL clock cyle
13
Running ExampleToy Cache Controller
CPU
Cache Controller
Main Memory
14
Cache Controller HLM
Cpu2Cache
State ? Invalid,Dirty,Clean
Data
Addr




CacheArray



Cache2Mem
15
Cache Controller HLM GCRecv_Store
Ruleset i CacheIndex Recv Store"
Cpu2Cache.opcode Store CacheArrayi.State !
Invalid CacheArrayi.Addr
Cpu2Cache.Addr gt CacheArrayi.Data
Cpu2Cache.Data CacheArrayi.State Dirty
Absorb(Cpu2Cache) end
16
Cache Controller HLM GCEvict
Ruleset i CacheIndex Evict"
CacheArrayi.State ! Invalid gt if
(CacheArrayi.State Dirty) begin
Cache2Mem.opcode WriteBack Cache2Mem.Addr
CacheArrayi.Addr Cache2Mem.Data
CacheArrayi.Data end CacheArrayi.State
Invalid end
17
Cache Controller RTL
Cpu2Cache
Cache State Addr Array
Cache Data Array
Pipe stage 1
Hit?
Eviction Logic
Pipe stage 2
Cache2Mem
18
Store with Eviction
Cpu2Cache
Store(A0,D0)
Cache State Addr Array
Cache Data Array
Pipe stage 1
Hit?
Store(A0,D0)
Dirty,A1
D1
Dirty,A0
D0
Eviction Logic
Pipe stage 2
Store(A0,D0)
WriteBack(A1,D1)
WriteBack(A1,D1)
Cache2Mem
19
Store with Eviction Revisited
When do the HLM GCs happen in the RTL?
Store
Evict
Store(A0,D0)
Cache State Addr Array
Cache Data Array
Pipe stage 1
Hit?
Store(A0,D0)
Dirty,A1
D1
Dirty,A0
D0
Eviction Logic
Pipe stage 2
Store(A0,D0)
WriteBack(A1,D1)
WriteBack(A1,D1)
20
Key Point 1
Pipelining causes GCs that are atomic in the HLM
to be non-atomic in the RTL. This non-atomicity
must be handled by the refinement map.
21
Key Point 2
In the HLM GCs are interleaved while the RTL
can exhibit true GC concurrency. This must be
resolved by the GC prediction.
22
Cache Controller Refinement Map(conceptual)
function HLM_STATE RM() // refinement map
function HLM_STATE HLM HLM.CacheArray.State
RTL.AddrArray.State HLM.CacheArray.Addr
RTL.AddrArray.Addr HLM.CacheArray.Data
RTL.DataArray_at_1 HLM.Cpu2Cache
RTL.Cpu2Cache_at_-1 HLM.Cache2Cpu
RTL.Cache2Cpu_at_1 return(HLM) end
ltsignalgt_at_k denotes the value ltsignalgt will have k
clock cycles in the future (k can be negative
too, to refer to the past)
23
Cache Controller Refinement Map(with only
non-positive temporal offsets)
function HLM_STATE RM() // refinement map
function HLM_STATE HLM HLM.CacheArray.State
RTL.AddrArray.State_at_-1 HLM.CacheArray.Ad
dr RTL.AddrArray.Addr_at_-1
HLM.CacheArray.Data RTL.DataArray
HLM.Cpu2Cache RTL.Cpu2Cache_at_-2 HLM.Cache2Cpu
RTL.Cache2Cpu_at_ return(HLM) end
ltsignagt_at_-k can be constructed using System
Verilogs past operator
24
Store with Eviction Re-Revisited
HLM
RTL
Store(A0,D0)
Cache State Addr Array
Cache Data Array
Pipe stage 1
Store(A0,D0)
D1
D0
Dirty,A1
Dirty,A0
Pipe stage 2
Store(A0,D0)
WriteBack(A1,D1)
WriteBack(A1,D1)
25
Cache Controller GC Prediction
function HLM_STATE Next_HLM_STATE(HLM_STATE hs)
if (RTL.Cpu2Cache.Valid_at_-2) begin i
get_target_cache_index()_at_-2 if
(will_need_eviction()_at_-2) hs
Evict(hs,i) if (RTL.Cpu2Cache.Op_at_-2 STORE)
hs Recv_Store(hs,i) else if
(RTL.Cpu2Cache.Op_at_-2 LOAD) hs
Recv_Load(hs,i) end ... // figure out
when to fire Send_Memory_Request // and
Recv_Memory_Response end
Can result in 0, 1, or 2 GCs fired
26
Back-to-back Stores with Eviction
HLM
RTL
Store(A0,D0)
Store(A2,D2)
Data Array
State Addr Array
Pipe stage 1
D2
Dirty,A2
Store(A0,D0)
Store(A2,D2)
Dirty,A1
D1
Dirty,A0
D0
Pipe stage 2
Store(A0,D0)
WriteBack(A1,D1)
Store(A2,D2)
WriteBack(A1,D1)
27
FYI, we do everything inSystem Verilog

• Actual design under verificaiton
• written by HW designers
• Test bench
• written by HW validators
• HLM
• written in Murphi by FV team in consultation with
  Architects
• compiled into SV by a tool we wrote
• Refinement Map
• hand-written in SV by FV team
• GC Prediction
• hand-written in SV by FV team

28
Formal Proofof Refinement
29
Formal Proof of Refinementversion 1.0 looks
like FEV
Can be decided by SAT- or BDD-based solver engine
Next(RM(?))
HLM
RM(?)
?
RM(??) Next(RM(?))
RM(??)
This will most certainly fail for some
unreachable RTL states! Rats!
RTL
??
?
one RTL clock cyle
Totally symbolic RTL state (represents all
possible RTL states)
Also might blow-up
30
Formal Proof of Refinementversion 2.0 write an
invariant
Can be decided by SAT- or BDD-based solver engine
Next(RM(?))
RM(?)
HLM
Inv(?) ? RM(??) Next(RM(?))
RM(??)
But concocting Inv is difficult, not to mention
you need to also prove Inv is invariant
RTL
??
?
one RTL clock cyle
Totally symbolic RTL state (represents all
possible RTL states)
Also might blow-up
31
Formal Proof of Refinementversion 3.0 Model
Checking

• start from initial state of env-HLM RTL
• compute forward reachability via symbolic model
  checking
• verify that checker never fires.

HLM of Environment
RTL checker
Will likely blow-up Probably need to restrict
behaviors e.g. use 4 addresses rather than 232
32
Open Problems

• Refinement map is part of spec or is it?
• Formal proof best approach?
• I spent 1.5 years banging my head on the formal
  side the fact that Ive retreated to checkers
  says something
• Tool issues pain in the butt
• Generated System Verilog has hit 4 bugs so far in
  expensive third-party simulator
• HLM/RTL discrepancies can we weaken our notion
  of refinement to allow for reasonable mismatches?
• E.g. HLM transmits message instantaneously, while
  RTL scheduling causes arbitrary delay before
  transmission

33
Partial Bibliography

• Using formal HLM as a checker
• Linking simulation with Formal Verification at a
  Higher Level, Tasiran, Batson, Yu, 2004
• Runtime Refinement Checking of Concurrent Data
  Structures, Tasiran Qadeer, 2004
• Original Murphi paper
• Protocol Verification as a Hardware Design Aid,
  Dill, Drexler, Hu, Yang, 1992
• Formal verification of refinement maps for
  hardware
• Automatic Verification of Pipelined
  Microprocessor Control, Burch Dill, 1994
• Protocol Verification by Aggregation of
  Distributed Transactions, Park Dill, 1996
• A Methodology for Hardware Verification using
  Compositional Model Checking,McMillan, 2000
• The Formal Design of 1M-gate ASICs, Eiriksson,
  2000
• Theory involving refinement in the face of
  fairness
• On the Existence of Refinement Maps, Abadi
  Lamport, 1991
• Commercial Tools
• BlueSpec (BlueSpec Inc.)
• Pico (Synfora)
• SLEC (Calypto)

34
Backups
35
Cache Controller HLM(typedefs var decls in
Murphi)
type ---- Type declarations ---- ltsnipgt
CACHE_ENTRY record State enum Invalid,
Dirty, Clean Addr ADDR Data
DATA end ltsnipgt var ---- State
variables ---- CacheArray array
0...CACHE_SIZE-1 of CACHE_ENTRY Cpu2Cache
CPU2CACHE_MSG Cache2Cpu CACHE2CPU_MSG
Mem2Cache MEM2CACHE_MSG Cache2Mem
CACHE2MEM_MSG
36
Guarded Commands Formalized

• State space S type consistent assignments to
  variables
• Init subset of state space specifying initial
  states
• A guarded command (GC) is a pair (g,c), where
• g S ?True,False is called the guard GC is
  enabled in state s if g(s) True
• c S ? S is called the command GC fires from s
  to c(s)
• Semantics HLM can transition from s to s? iff
  there exists a GC that
• is enabled in s
• fires from s to s?
• Nondeterminism arrises when multiple GCs are
  enabled
• In practice GCs are often parameterized
• We assume that the stuttering GC (?s.True , ?s.s
  ) is implicit

37
Refinement Formalized

• Let H and R be respective state spaces of HLM and
  RTL
• A function RM R ? H is called a refinement map
• Intuitively, RM(r) is the HLM state that
  summarizes RTL state r
• Many-to-one in general
• Human writes this in our methodology
• We generalize this so that RM Rw ? H , for some
  fixed w
• Hence RM maps a fixed length sequence of RTL
  states to H
• Useful for dealing with RTL pipelines

38
Cache Controller HLM GCs (1/2)
Ruleset i CacheIndex Recv Store"
Cpu2Cache.opcode Store CacheArrayi.State !
Invalid CacheArrayi.Addr
Cpu2Cache.Addr gt CacheArrayi.Data
Cpu2Cache.Data CacheArrayi.State Dirty
Absorb(Cpu2Cache) Ruleset i CacheIndex Recv
Load" Cpu2Cache.opcode Load
CacheArrayi.State ! Invalid
CacheArrayi.Addr Cpu2Cache.Addr gt
Cache2Cpu.Data CacheArryi.Data
Absorb(Cpu2Cache) Ruleset i CacheIndex
Evict" CacheArrayi.State ! Invalid gt if
(CacheArrayi.State Dirty) begin
Cache2Mem.opcode WriteBack Cache2Mem.Addr
CacheArrayi.Addr Cache2Mem.Data
CacheArrayi.Data end CacheArrayi.State
Invalid
39
Cache Controller HLM GCs (2/2)
Ruleset i CacheIndex a Addr Send Memory
Request" CacheArryi.State Invalid gt
Cache2Mem.opcode Get Cache2Mem.Index i
Cache2Mem.Addr a end Ruleset i CacheIndex
Recv Memory Response" Mem2Cache.opcode
Response gt CacheArryMem2Cache.Index.Data
Mem2Cache.Data CacheArryMem2Cache.Index.Addr
Mem2Cache.Addr CacheArryMem2Cache.Index.St
ate Clean Absorb(Mem2Cache) end
40
Load Miss (moot)
Cache2Cpu
Cpu2Cache
Response(D0)
Load(A0)
Cache State Addr Array
Cache Data Array
Pipe stage 1
Hit?
Get(A0)
D0
Clean,A0
Eviction Logic
Pipe stage 2
Get(A0)
Get(A0)
Response(A0,D0)
Cache2Mem
Mem2Cache
41
Cache Controller Refinement Map(conceptual)
function HLM_STATE RM() // refinement map
function HLM_STATE HLM for (int i0 i lt
CACHE_SIZE i) begin HLM.CacheArrayi.State
RTL.AddrArrayi.State HLM.CacheArrayi.A
ddr RTL.AddrArrayi.Addr
HLM.CacheArrayi.Data RTL.DataArrayi_at_1
end HLM.Cpu2Cache RTL.Cpu2Cache_at_-1
HLM.Cache2Cpu RTL.Cache2Cpu
return(HLM) end
ltsignalgt_at_k denotes the value ltsignalgt will have k
clock cycles in the future (k can be negative too)