Verification Driven Formal Architecture and ?Architecture Modeling - PowerPoint PPT Presentation

1 / 33
About This Presentation
Title:

Verification Driven Formal Architecture and ?Architecture Modeling

Description:

Title: Design Productivity Crisis Author: user Last modified by: Sharad Malik Created Date: 6/17/1995 11:31:02 PM Document presentation format: On-screen Show – PowerPoint PPT presentation

Number of Views:187
Avg rating:3.0/5.0
Slides: 34
Provided by: acil150
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com