Verification Driven Formal Architecture Verification Driven Formal Architecture and and Architecture ModelingArchitecture Modeling

Sharad Malik, Yogesh Mahajan, Carven ChanSharad Malik, Yogesh Mahajan, Carven Chan, , Ali BayazitAli BayazitPrinceton UniversityPrinceton University

Wei QinWei Qin

Boston UniversityBoston University

Intel Haifa SymposiumIntel Haifa SymposiumJuly 10, 2007July 10, 2007

2

Overall MotivationOverall Motivation

Growing “verification gap” between size of designs that can be Growing “verification gap” between size of designs that can be

verified and designs that can be fabricatedverified and designs that can be fabricated

(Source: SIA Roadmap, 2001) (Source: SIA Roadmap, 2001)

VerificationGap

3

What makes hardware verification hard?What makes hardware verification hard?

1.1. High computational complexity/concurrencyHigh computational complexity/concurrency State space explosion!State space explosion!

2.2. Tasks need intensive human effortTasks need intensive human effort Incomplete/hard-to-analyze specificationsIncomplete/hard-to-analyze specifications

Mapping specification to implementationMapping specification to implementation Complex “correctness criteria” Complex “correctness criteria”

Main Cause: Inappropriate Design ModelsMain Cause: Inappropriate Design Models

RTL?RTL? System C?System C?

Despite available tools:

Functional simulation,

Emulation,

Formal verification

4

Requirements for a Verification-Friendly Model Requirements for a Verification-Friendly Model

Enable automation of common tasksEnable automation of common tasks

Model must make it possible to provide answers toModel must make it possible to provide answers toWhat to verify? (generate verification tasks) What to verify? (generate verification tasks)

How to verify? (map tasks to available tools)How to verify? (map tasks to available tools)

How do know how much has been verified? (coverage)How do know how much has been verified? (coverage)

How to minimize overlap of coverage? (efficient verification)How to minimize overlap of coverage? (efficient verification)

The model must be analyzable by automated toolsThe model must be analyzable by automated tools

5

Requirements for a Verification-Friendly Model Requirements for a Verification-Friendly Model

Appropriate modeling of concurrencyAppropriate modeling of concurrency

Model must separate out concurrent interactions via Model must separate out concurrent interactions via Shared data valuesShared data values

Generally a property of the algorithm/protocol Shared resourcesShared resources

Generally a property of the implementation

Separate algorithm aspects from implementation aspectsSeparate algorithm aspects from implementation aspects

6

Requirements for a Verification-Friendly Model Requirements for a Verification-Friendly Model

What to do when the verification does not complete?What to do when the verification does not complete?

(For emerging runtime checking/recovery designs(For emerging runtime checking/recovery designs [Malik ’06] [Malik ’06] ))

Model must provide answers to : Model must provide answers to : What to monitor, and when? What to monitor, and when?

How to recover?How to recover?

Explicit mapping of algorithm aspects to implementationExplicit mapping of algorithm aspects to implementation

7

Limitations of RTL Models for VerificationLimitations of RTL Models for Verification

Hard for analysis to determine what the design is Hard for analysis to determine what the design is computingcomputingNo information on No information on computation on units of datacomputation on units of data

Need additional inputs on computational Need additional inputs on computational requirements/propertiesrequirements/propertiesGenerally natural language specificationGenerally natural language specification

ForSpec, Sugar/PSL are partial specificationsForSpec, Sugar/PSL are partial specifications

Human intensive effort Human intensive effort Costly, inefficient, incomplete and error proneCostly, inefficient, incomplete and error prone

8

What about SystemC/System-Verilog?What about SystemC/System-Verilog?

Covers multiple design levelsCovers multiple design levelsHigher levels (e.g. transaction-level modeling)Higher levels (e.g. transaction-level modeling)

Help with simulation productivityHelp with simulation productivity Some notion of end-to-end descriptions of data-computationSome notion of end-to-end descriptions of data-computation Not easily analyzableNot easily analyzable

Lower levels Lower levels Essentially RTL with better macrosEssentially RTL with better macros Motivated by designer productivityMotivated by designer productivity

Fewer lines of code designer productivity Underlying model is still an executable model, not an analyzable one Underlying model is still an executable model, not an analyzable one

No way to relate designs across different levelsNo way to relate designs across different levels

9

Proposed Modeling Framework: CharacteristicsProposed Modeling Framework: Characteristics

Describes concurrent computation on units of dataDescribes concurrent computation on units of data

Separates concurrent interactions due to:Separates concurrent interactions due to:shared data valuesshared data values

related to algorithm/protocolrelated to algorithm/protocol

shared resourcesshared resources related to the implementationrelated to the implementation

Easy to relate models across multiple levels of frameworkEasy to relate models across multiple levels of framework

Ensures model is easily analyzableEnsures model is easily analyzable

10

Multilevel Modeling for VerificationMultilevel Modeling for Verification

Architecture

Microarchitecture

RTL

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

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

RTL•Structural details of implementation

11

Architectural ModelArchitectural Model

Computation: Concurrent transaction instances operating on dataComputation: Concurrent transaction instances operating on data Instances of a transaction classInstances of a transaction class Transaction instances are indivisible unitsTransaction instances are indivisible units

Data resides in state elementsData resides in state elements

Types of architectural state: register, memory, queuesTypes of architectural state: register, memory, queues

Transaction instances communicate via shared stateTransaction instances communicate via shared state

““Data availability” constrains the concurrencyData availability” constrains the concurrency

in

Shared memory

reg

queueoutT1 T2

result

12

Architecture Model: ExamplesArchitecture Model: Examples

Shared memory

reg

P1reg

P2

Shared memory multiprocessor

ParseStream

HuffmanDecode

ZigZagReorder

DeQuantize IDCT

Set Huffman

Table

SetQuantization

Table

JPEG decoding

8x8 image block

Huffmantable

DeQuantize

table

FilesI/O

controlbits

13

Architecture Model: Describing a TransactionArchitecture Model: Describing a Transaction

Transaction decomposed into Transaction decomposed into steps steps in in transaction graphtransaction graph

Each step has assignments (state updates), followed by predicate Each step has assignments (state updates), followed by predicate

evaluations (do not update state)evaluations (do not update state)

Edge conditions determine path through transaction graphEdge conditions determine path through transaction graph

TransactionGraph

start step

s’f(s)

w

end step

w = P(s’)state updates:

predicates:

…

1

2

out-edges ordered

1

2

edge predicate

…

1

14

Architecture Model SemanticsArchitecture Model Semantics

Transaction instances are indivisibleTransaction instances are indivisible

Concurrent execution of transaction instancesConcurrent execution of transaction instances Architectural state update is the union of individual state updates.Architectural state update is the union of individual state updates.

Conflicting updates Conflicting updates Error Error

Framework supports multiple concurrency semantics:Framework supports multiple concurrency semantics: Synchronous, i.e. all enabled transaction instances execute simultaneouslySynchronous, i.e. all enabled transaction instances execute simultaneously

Asynchronous, any subset of enabled transaction instances execute Asynchronous, any subset of enabled transaction instances execute simultaneouslysimultaneously Interleaving/Serializability is a special case of this – subset limited to cardinality oneInterleaving/Serializability is a special case of this – subset limited to cardinality one

Or any combination of those, e.g. locally synchronous, globally asynchronousOr any combination of those, e.g. locally synchronous, globally asynchronous

15

Architecture Model: Transaction Examples Architecture Model: Transaction Examples

start endR D1 W D2 D3

Instruction in processor

JPEG Parse-Stream/Control Transaction

Decodeheader

Decodersetup

SOFmarker?

is_SOI

not_SOI

Interpretmarkers

is_SOF

not_SOF

is_SOS

not_SOS

SOSmarker?

Interpretframe

header

Interpretmarkers

Interpretscan

header

is_D

QT i

s_D

HT

is_SOSis_SOF

is_DQT is_DHT

is_DQT is_DHT

1

2

16

Architecture Modeling Example DetailArchitecture Modeling Example Detail

17

Architectural ModelArchitectural Model

Adds how resource constraints influence concurrencyAdds how resource constraints influence concurrency

Captures how transactions share resourcesCaptures how transactions share resourcesAcross different transaction classesAcross different transaction classes

Example: Shared memory in multiprocessor systemsExample: Shared memory in multiprocessor systems

Across different transactions in the same class Across different transactions in the same class Example: Pipelined instruction processingExample: Pipelined instruction processing

Resource arbitration modeled using Resource arbitration modeled using resource managersresource managers

18

ResourcesResources Resource tokens model concurrency constraints due to sharingResource tokens model concurrency constraints due to sharing

Hardware function—ALUHardware function—ALU

ALU_resourceALU_resource

Reg_resourceReg_resource

Data dependence—register file entriesData dependence—register file entries

19

Resource ManagersResource Managers

Arbitration of resources is done by resource managersArbitration of resources is done by resource managersTransaction instances request/release/retain resources Transaction instances request/release/retain resources

Resource managers grant resources Resource managers grant resources

Resource managers are described as FSMsResource managers are described as FSMs

20

Architecture Model: Describing a TransactionArchitecture Model: Describing a Transaction

ResourceManager

Steps require resources to executeSteps require resources to execute

Resource requests: allocate, release, Resource requests: allocate, release, retainretain

Architectural level step may be refined Architectural level step may be refined into multiple into multiple -architectural steps-architectural steps

Resource manager has a time-Resource manager has a time-

stationary stationary [Kogge ’81][Kogge ’81] view of the view of the computationcomputation

ArchitecturalArchitectural

µArchitecturalµArchitectural

refinementrefinement

21

Architecture Model SemanticsArchitecture Model Semantics

Transaction instances are no longer indivisibleTransaction instances are no longer indivisibleTransaction steps are indivisible unitsTransaction steps are indivisible units

Enabled transaction steps (from different transaction Enabled transaction steps (from different transaction

instances) execute concurrently, with parallel state instances) execute concurrently, with parallel state

updatesupdatesConflicting state updates Conflicting state updates error error

Framework supports multiple concurrency semantics:Framework supports multiple concurrency semantics:Execution of multiple steps can be synchronous, asynchronous Execution of multiple steps can be synchronous, asynchronous

(including interleaving), or a hybrid(including interleaving), or a hybrid

22

Architecture Modeling Example DetailArchitecture Modeling Example Detail

23

Resource Manager

Architecture, Complete ModelArchitecture, Complete Model

Data stationaryData stationary Time stationaryTime stationary

TT11

TT22

TT33

…… ……

PCPC

Reg entriesReg entries

ALUALU

transactionstransactions Hardware, resources, managersHardware, resources, managers

RegfileManager

ALUManager

……

[Kogge ’81][Kogge ’81] [Kogge ’81][Kogge ’81]

24

RTL ModelRTL Model

Structural detailsStructural details

Completely Completely time-stationarytime-stationary

Synthesize from Synthesize from ArchitectureArchitecture

Verify using limited Verify using limited equivalence checksequivalence checks

.

.

25

RTL in the Proposed FlowRTL in the Proposed Flow

Synthesize RTL from microarchitecture modelSynthesize RTL from microarchitecture modelFor each transaction, synthesize the sequencer for its stepsFor each transaction, synthesize the sequencer for its stepsFor each resource manager, FSM for its allocation policyFor each resource manager, FSM for its allocation policyLogic for physical resources (library/custom)Logic for physical resources (library/custom) Interconnections between resourcesInterconnections between resources

Verify the synthesized RTL versus microarchitectureVerify the synthesized RTL versus microarchitectureGranularity of checks is per transaction/per resource manager/ Granularity of checks is per transaction/per resource manager/

per resourceper resourceSimilar to equivalence check between RTL and gate level Similar to equivalence check between RTL and gate level

Hand off to RTL flowHand off to RTL flow

26

Model FeaturesModel Features

Computation modeled as transactions Computation modeled as transactions

Uncluttered by implementation detailsUncluttered by implementation details

Interactions only due to shared dataInteractions only due to shared data

Is executable as well as analyzableIs executable as well as analyzable

Computation modeled as transactions Computation modeled as transactions

Models physical resource sharing Models physical resource sharing

Interactions due to shared data as Interactions due to shared data as

well as due to shared resourceswell as due to shared resources

Is executable as well as analyzableIs executable as well as analyzable

Architecture Level ArchitectureArchitecture Level

Explicit modeling of relevant informationExplicit modeling of relevant information

27

How does this help with verification?How does this help with verification?

Architectural ModelArchitectural Model Can reason about computation paths in terms of dataCan reason about computation paths in terms of data

Coverage of different classes of data (instructions/packets) in simulationCoverage of different classes of data (instructions/packets) in simulation Automated property and model construction for model checkingAutomated property and model construction for model checking

Architecture ModelArchitecture Model Can reason about how computation uses resourcesCan reason about how computation uses resources

Coverage of usage requests and grants in simulationCoverage of usage requests and grants in simulationHazards, deadlocks, resource overloading…Automatically derive properties involving sequencing and temporal

properties Automated property and model construction in model checkingAutomated property and model construction in model checking

Verification across levelsVerification across levels Is the Is the Architecture model a refinement of the architectural model?Architecture model a refinement of the architectural model?

Explicit modeling of relevant information Explicit modeling of relevant information greater automation. greater automation.

28

Model Use: Coverage Metric, Functional TestingModel Use: Coverage Metric, Functional Testing

Possibilities for alternative Coverage MetricsPossibilities for alternative Coverage Metrics Observe every edge/path in the transaction?Observe every edge/path in the transaction? Observe every transaction/ sequences of transactions?Observe every transaction/ sequences of transactions? Observe all transitions of the Resource Manager FSMObserve all transitions of the Resource Manager FSM Observe different ways of allocating resources between transactionsObserve different ways of allocating resources between transactions

Decompose testing at three levels of interaction:Decompose testing at three levels of interaction: transaction-transaction (correctness of computation)transaction-transaction (correctness of computation) transaction-resource (progress of computation)transaction-resource (progress of computation) resource allocations (consistency, feasibility of computation)resource allocations (consistency, feasibility of computation)

ExamplesExamples Check that a transaction, when unconstrained by resources, is not permanently blocked Check that a transaction, when unconstrained by resources, is not permanently blocked

on all edges; it must run to completionon all edges; it must run to completion

Current RTL methodologies have related goals, but rely on human effort and Current RTL methodologies have related goals, but rely on human effort and

biased random simulation to achieve thembiased random simulation to achieve them

29

Formal verification across modelsFormal verification across models

Microarchitecture (Microarchitecture () implements some architecture () implements some architecture ())

A correspondence ‘A correspondence ‘c’ c’ between levels can be established between levels can be established Function correspondence for each fFunction correspondence for each f in in : : cc(f(f) = f) = f

State elements correspondence: State elements correspondence: cc(S(S) ) cc(S(S))Transactions correspondence: Transactions correspondence: cc(T(T) = ) = cc(T(T))

30

Formal verification across modelsFormal verification across models

Equivalence check functions fEquivalence check functions f and c(f and c(f))

Verify that state sVerify that state s is an abstraction of c(s is an abstraction of c(s))E.g queue can abstract a finite sized bufferE.g queue can abstract a finite sized buffer

Verify end-to-end correctness of each transactionVerify end-to-end correctness of each transactionFor same data inputs, execution paths For same data inputs, execution paths and and

d at the two levels are functionally equivalent. d at the two levels are functionally equivalent.

This check can use the previous properties as lemmasThis check can use the previous properties as lemmas

Verify data interactions between transactionsVerify data interactions between transactions i.e. there are no Read-After-Write errors, etc.i.e. there are no Read-After-Write errors, etc.

31

Model Use: Runtime ValidationModel Use: Runtime Validation

Suitability of microarchitectural modelSuitability of microarchitectural modelTransactions provide “units of computation”Transactions provide “units of computation”

Direct modeling of resource sharingDirect modeling of resource sharing

ApplicationsApplicationsOperational reliability: modular redundancyOperational reliability: modular redundancy

Spatial, temporal, hybrid redundancySpatial, temporal, hybrid redundancy

Generic recoveryGeneric recovery Delayed commit (Forward error recovery)Delayed commit (Forward error recovery) Rollback (Backward error recovery)Rollback (Backward error recovery) Reduced complexity, alternative mode of operationReduced complexity, alternative mode of operation

32

Comparative AnalysisComparative Analysismulti-multi-

level?level?spec?spec? impl?impl?

data-data-

centric?centric?

resourcesresources

??

analyzablanalyzabl

e?e?domaindomain

nML, LISAnML, LISA •• instructionsinstructions µPµP

SystemCSystemC •• •• •• behavioralbehavioral xx

MetropolisMetropolis •• •• •• ••

SystemC with SystemC with

ExtensionsExtensions•• •• •• behavioralbehavioral

Kahn-process netKahn-process net •• ••Prod-Prod-

consumerconsumer(deadlock)(deadlock) DSPDSP

Process calculiProcess calculi •• ••

HOPHOP •• •• •• operationaloperational xx verificationverification hardwarehardware

ForSpecForSpec •• ••

BluespecBluespec •• •• operationaloperational •• hardwarehardware

Guarded Guarded

commandscommands•• transactionaltransactional ••

Synchronized Synchronized

transitionstransitions•• transactionaltransactional ••

Petri netsPetri nets •• •• •• basicbasic

OSMsOSMs •• •• • • ••

FSM/StatechartsFSM/Statecharts ••(reachabilit(reachabilit

y)y)

control/control/

basicbasic

RTLRTL •• •• xx hardwarehardware

LibertyLiberty •• •• processorsprocessors

PtolemyPtolemy •• •• embeddedembedded

arch-µarcharch-µarch •• •• •• •• •• verificationverification hardwarehardware

33

ConclusionsConclusions

Top-down modeling framework for supporting hardware design verificationTop-down modeling framework for supporting hardware design verification

Architecture LevelArchitecture Level Provide functional specification in terms of transactions that describe computation on Provide functional specification in terms of transactions that describe computation on

units of dataunits of data Concurrency captured through shared dataConcurrency captured through shared data

architecture Levelarchitecture Level Describe how architecture level is implemented using shared resourcesDescribe how architecture level is implemented using shared resources Concurrency described through shared resourcesConcurrency described through shared resources

RTL LevelRTL Level Synthesized from Synthesized from architecture levelarchitecture level Validated using specific equivalence checksValidated using specific equivalence checks

Validation enabled through explicit information on computation and resource Validation enabled through explicit information on computation and resource

usageusage