Verification Driven Formal Architecture and ?Architecture Modeling

1
Verification Driven Formal Architecture and
?Architecture Modeling

• Sharad Malik, Yogesh Mahajan, Carven Chan, Ali
  Bayazit
• Princeton University
• Wei Qin
• Boston University
• Intel Haifa Symposium
• July 10, 2007

2
Overall Motivation

• Growing verification gap between size of
  designs that can be verified and designs that can
  be fabricated
• (Source SIA
  Roadmap, 2001)

Verification Gap
3
What makes hardware verification hard?

• High computational complexity/concurrency
• State space explosion!
• Tasks need intensive human effort
• Incomplete/hard-to-analyze specifications
• Mapping specification to implementation
• Complex correctness criteria
• Main Cause Inappropriate Design Models
• RTL? System C?

Despite available tools Functional simulation,
Emulation, Formal verification
4
Requirements for a Verification-Friendly Model

• Enable automation of common tasks
• Model must make it possible to provide answers to
• What to verify? (generate verification tasks)
• How to verify? (map tasks to available tools)
• How do know how much has been verified?
  (coverage)
• How to minimize overlap of coverage? (efficient
  verification)
• The model must be analyzable by automated tools

5
Requirements for a Verification-Friendly Model

• Appropriate modeling of concurrency
• Model must separate out concurrent interactions
  via
• Shared data values
• Generally a property of the algorithm/protocol
• Shared resources
• Generally a property of the implementation
• Separate algorithm aspects from implementation
  aspects

6
Requirements for a Verification-Friendly Model

• What to do when the verification does not
  complete?
• (For emerging runtime checking/recovery designs
  Malik 06 )
• Model must provide answers to
• What to monitor, and when?
• How to recover?
• Explicit mapping of algorithm aspects to
  implementation

7
Limitations of RTL Models for Verification

• Hard for analysis to determine what the design is
  computing
• No information on computation on units of data
• Need additional inputs on computational
  requirements/properties
• Generally natural language specification
• ForSpec, Sugar/PSL are partial specifications
• Human intensive effort
• Costly, inefficient, incomplete and error prone

8
What about SystemC/System-Verilog?

• Covers multiple design levels
• Higher levels (e.g. transaction-level modeling)
• Help with simulation productivity
• Some notion of end-to-end descriptions of
  data-computation
• Not easily analyzable
• Lower levels
• Essentially RTL with better macros
• Motivated by designer productivity
• Fewer lines of code ? designer productivity
• Underlying model is still an executable model,
  not an analyzable one
• No way to relate designs across different levels

9
Proposed Modeling Framework Characteristics

• Describes concurrent computation on units of data
• Separates concurrent interactions due to
• shared data values
• related to algorithm/protocol
• shared resources
• related to the implementation
• Easy to relate models across multiple levels of
  framework
• Ensures model is easily analyzable

10
Multilevel Modeling for Verification
Design Specs

• Architecture level
• Data-centric view of computation
• Functional transactions on data

Architecture

• Microarchitecture level
• Retain data-centric view
• Detail implementation of transactions
• Model sharing of physical resources

Microarchitecture
RTL

• RTL
• Structural details of implementation

11
Architectural Model
queue
result
in
out
T1
T2
reg
Shared memory

• Computation Concurrent transaction instances
  operating on data
• Instances of a transaction class
• Transaction instances are indivisible units
• Data resides in state elements
• Types of architectural state register, memory,
  queues
• Transaction instances communicate via shared
  state
• Data availability constrains the concurrency

12
Architecture Model Examples
Set Quantization Table
Set Huffman Table
Parse Stream
Huffman Decode
ZigZag Reorder
DeQuantize
IDCT
8x8 image block
JPEG decoding
P2
P1
Shared memory multiprocessor
13
Architecture Model Describing a Transaction
w
edge predicate
1
Transaction Graph

s?f(s)
state updates
w P(s)
predicates
1
end step
start step
2
1
out-edges ordered
2

• Transaction decomposed into steps in transaction
  graph
• Each step has assignments (state updates),
  followed by predicate evaluations (do not update
  state)
• Edge conditions determine path through
  transaction graph

14
Architecture Model Semantics

• Transaction instances are indivisible
• Concurrent execution of transaction instances
• Architectural state update is the union of
  individual state updates.
• Conflicting updates ? Error
• Framework supports multiple concurrency
  semantics
• Synchronous, i.e. all enabled transaction
  instances execute simultaneously
• Asynchronous, any subset of enabled transaction
  instances execute simultaneously
• Interleaving/Serializability is a special case of
  this subset limited to cardinality one
• Or any combination of those, e.g. locally
  synchronous, globally asynchronous

15
Architecture Model Transaction Examples
Instruction in processor
D3
start
end
D1
D2
W
R
JPEG Parse-Stream/Control Transaction
Interpret scan header
SOS marker?
Interpret frame header
is_SOS
is_SOF
Decoder setup
SOF marker?
2
is_SOI
not_SOF
is_DQT ? is_DHT
1
not_SOS
is_SOS
is_SOF
Decode header
Interpret markers
Interpret markers
is_DQT ? is_DHT
not_SOI
is_DQT ? is_DHT
16
Architecture Modeling Example Detail
17
?Architectural Model

• Adds how resource constraints influence
  concurrency
• Captures how transactions share resources
• Across different transaction classes
• Example Shared memory in multiprocessor systems
• Across different transactions in the same class
• Example Pipelined instruction processing
• Resource arbitration modeled using resource
  managers

18
Resources

• Resource tokens model concurrency constraints due
  to sharing

Hardware functionALU
ALU_resource
Data dependenceregister file entries
Reg_resource
19
Resource Managers

• Arbitration of resources is done by resource
  managers
• Transaction instances request/release/retain
  resources
• Resource managers grant resources
• Resource managers are described as FSMs

20
?Architecture Model Describing a Transaction

• Steps require resources to execute
• Resource requests allocate, release, retain
• Architectural level step may be refined into
  multiple ?-architectural steps
• Resource manager has a time-stationary Kogge
  81 view of the computation

Architectural
refinement
µArchitectural
Resource Manager
21
?Architecture Model Semantics

• Transaction instances are no longer indivisible
• Transaction steps are indivisible units
• Enabled transaction steps (from different
  transaction instances) execute concurrently, with
  parallel state updates
• Conflicting state updates ? error
• Framework supports multiple concurrency
  semantics
• Execution of multiple steps can be synchronous,
  asynchronous (including interleaving), or a
  hybrid

22
?Architecture Modeling Example Detail
23
?Architecture, Complete Model
Resource Manager
T1
PC
T2
Regfile Manager
Reg entries
ALU Manager
T3
ALU



Data stationary
Time stationary
Kogge 81
Kogge 81
transactions
Hardware, resources, managers
24
RTL Model
.

• Structural details
• Completely time-stationary
• Synthesize from ?Architecture
• Verify using limited equivalence checks

.
25
RTL in the Proposed Flow

• Synthesize RTL from microarchitecture model
• For each transaction, synthesize the sequencer
  for its steps
• For each resource manager, FSM for its allocation
  policy
• Logic for physical resources (library/custom)
• Interconnections between resources
• Verify the synthesized RTL versus
  microarchitecture
• Granularity of checks is per transaction/per
  resource manager/ per resource
• Similar to equivalence check between RTL and gate
  level
• Hand off to RTL flow

26
Model Features
?Architecture Level
Architecture Level

• Computation modeled as transactions
• Models physical resource sharing
• Interactions due to shared data as well as due to
  shared resources
• Is executable as well as analyzable

• Computation modeled as transactions
• Uncluttered by implementation details
• Interactions only due to shared data
• Is executable as well as analyzable

Explicit modeling of
relevant information
27
How does this help with verification?

• Architectural Model
• Can reason about computation paths in terms of
  data
• Coverage of different classes of data
  (instructions/packets) in simulation
• Automated property and model construction for
  model checking
• ?Architecture Model
• Can reason about how computation uses resources
• Coverage of usage requests and grants in
  simulation
• Hazards, deadlocks, resource overloading
• Automatically derive properties involving
  sequencing and temporal properties
• Automated property and model construction in
  model checking
• Verification across levels
• Is the ?Architecture model a refinement of the
  architectural model?
• Explicit modeling of relevant information ?
  greater automation.

28
Model Use Coverage Metric, Functional Testing

• Possibilities for alternative Coverage Metrics
• Observe every edge/path in the transaction?
• Observe every transaction/ sequences of
  transactions?
• Observe all transitions of the Resource Manager
  FSM
• Observe different ways of allocating resources
  between transactions
• Decompose testing at three levels of interaction
• transaction-transaction (correctness of
  computation)
• transaction-resource (progress of computation)
• resource allocations (consistency, feasibility of
  computation)
• Examples
• Check that a transaction, when unconstrained by
  resources, is not permanently blocked on all
  edges it must run to completion
• Current RTL methodologies have related goals, but
  rely on human effort and biased random simulation
  to achieve them

29
Formal verification across models

• Microarchitecture (?) implements some
  architecture (?)
• A correspondence c between levels can be
  established
• Function correspondence for each f? in ? c(f?)
  f?
• State elements correspondence c(S?) ? c(S?)
• Transactions correspondence c(T?) c(T?)

30
Formal verification across models

• Equivalence check functions f? and c(f?)
• Verify that state s? is an abstraction of c(s?)
• E.g queue can abstract a finite sized buffer
• Verify end-to-end correctness of each transaction
• For same data inputs, execution paths ?
  and d
  at the two levels are functionally
  equivalent.
• This check can use the previous properties as
  lemmas
• Verify data interactions between transactions
• i.e. there are no Read-After-Write errors, etc.

31
Model Use Runtime Validation

• Suitability of microarchitectural model
• Transactions provide units of computation
• Direct modeling of resource sharing
• Applications
• Operational reliability modular redundancy
• Spatial, temporal, hybrid redundancy
• Generic recovery
• Delayed commit (Forward error recovery)
• Rollback (Backward error recovery)
• Reduced complexity, alternative mode of operation

32
Comparative Analysis
multi-level? spec? impl? data-centric? resources? analyzable? domain
nML, LISA instructions µP
SystemC behavioral x
Metropolis
SystemC with Extensions behavioral
Kahn-process net Prod-consumer (deadlock) DSP
Process calculi
HOP operational x verification hardware
ForSpec
Bluespec operational hardware
Guarded commands transactional
Synchronized transitions transactional
Petri nets basic
OSMs
FSM/Statecharts (reachability) control/basic
RTL x hardware
Liberty processors
Ptolemy embedded
arch-µarch verification hardware
33
Conclusions

• Top-down modeling framework for supporting
  hardware design verification
• Architecture Level
• Provide functional specification in terms of
  transactions that describe computation on units
  of data
• Concurrency captured through shared data
• ?architecture Level
• Describe how architecture level is implemented
  using shared resources
• Concurrency described through shared resources
• RTL Level
• Synthesized from ?architecture level
• Validated using specific equivalence checks
• Validation enabled through explicit information
  on computation and resource usage