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. 2 Overall Motivation u Growing “verification gap” between size of designs that can be verified and designs that can be fabricated (Source: SIA Roadmap, 2001) (Source: SIA Roadmap, 2001) Verification Gap

3. 3 What makes hardware verification hard? 1. High computational complexity/concurrency s State space explosion! 2. Tasks need intensive human effort s Incomplete/hard-to-analyze specifications s Mapping specification to implementation t Complex “correctness criteria” Main Cause: Inappropriate Design Models RTL?System C? Despite available tools: Functional simulation, Emulation, Formal verification

4. 4 Requirements for a Verification-Friendly Model Enable automation of common tasks u Model must make it possible to provide answers to s What to verify? (generate verification tasks) s How to verify? (map tasks to available tools) s How do know how much has been verified? (coverage) s How to minimize overlap of coverage? (efficient verification) The model must be analyzable by automated tools

5. 5 Requirements for a Verification-Friendly Model Appropriate modeling of concurrency u Model must separate out concurrent interactions via t Shared data values u Generally a property of the algorithm/protocol t Shared resources u Generally a property of the implementation Separate algorithm aspects from implementation aspects Separate algorithm aspects from implementation aspects

6. 6 Requirements for a Verification-Friendly Model What to do when the verification does not complete? (For emerging runtime checking/recovery designs [Malik ’06] ) u Model must provide answers to : s What to monitor, and when? s How to recover? Explicit mapping of algorithm aspects to implementation

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

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

9. 9 Proposed Modeling Framework: Characteristics u Describes concurrent computation on units of data u Separates concurrent interactions due to: s shared data values t related to algorithm/protocol s shared resources t related to the implementation u Easy to relate models across multiple levels of framework u Ensures model is easily analyzable

10. 10 Multilevel 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. 11 Architectural Model u Computation: Concurrent transaction instances operating on data s Instances of a transaction class s Transaction instances are indivisible units u Data resides in state elements u Types of architectural state: register, memory, queues u Transaction instances communicate via shared state u “Data availability” constrains the concurrency in Shared memory reg queue out T1 T2 result

12. 12 Architecture Model: Examples Shared memory reg P1 reg P2 Shared memory multiprocessor Parse Stream Huffman Decode ZigZag Reorder DeQuantizeIDCT Set Huffman Table Set Quantization Table JPEG decoding 8x8 image block Huffman table DeQuantize table Files I/O control bits

13. 13 Architecture Model: Describing a Transaction u Transaction decomposed into steps in transaction graph u Each step has assignments (state updates), followed by predicate evaluations (do not update state) u Edge conditions determine path through transaction graph Transaction Graph 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. 14 Architecture Model Semantics u Transaction instances are indivisible u Concurrent execution of transaction instances s Architectural state update is the union of individual state updates. t Conflicting updates  Error u Framework supports multiple concurrency semantics: s Synchronous, i.e. all enabled transaction instances execute simultaneously s Asynchronous, any subset of enabled transaction instances execute simultaneously t Interleaving/Serializability is a special case of this – subset limited to cardinality one s Or any combination of those, e.g. locally synchronous, globally asynchronous

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

16. 16 Architecture Modeling Example Detail

17. 17  Architectural Model u Adds how resource constraints influence concurrency u Captures how transactions share resources s Across different transaction classes t Example: Shared memory in multiprocessor systems s Across different transactions in the same class t Example: Pipelined instruction processing u Resource arbitration modeled using resource managers

18. 18 Resources  Resource tokens model concurrency constraints due to sharing Hardware function—ALU ALU_resource Reg_resource Data dependence—register file entries

19. 19 Resource Managers u Arbitration of resources is done by resource managers s Transaction instances request/release/retain resources s Resource managers grant resources u Resource managers are described as FSMs

20. 20  Architecture Model: Describing a Transaction Resource Manager u Steps require resources to execute u Resource requests: allocate, release, retain u Architectural level step may be refined into multiple  -architectural steps u Resource manager has a time- stationary [Kogge ’81] view of the computation Architectural µArchitectural refinement

21. 21  Architecture Model Semantics u Transaction instances are no longer indivisible s Transaction steps are indivisible units u Enabled transaction steps (from different transaction instances) execute concurrently, with parallel state updates s Conflicting state updates  error u Framework supports multiple concurrency semantics: s Execution of multiple steps can be synchronous, asynchronous (including interleaving), or a hybrid

22. 22  Architecture Modeling Example Detail

23. 23 Resource Manager  Architecture, Complete Model Data stationary Time stationary T1T1T1T1 T2T2T2T2 T3T3T3T3 … … PC Reg entries ALU transactions Hardware, resources, managers Regfile Manager ALU Manager … [Kogge ’81]

24. 24 RTL Model u Structural details u Completely time-stationary u Synthesize from  Architecture u Verify using limited equivalence checks..

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

26. 26 Model Features  Computation modeled as transactions  Uncluttered by implementation details  Interactions only due to shared data  Is executable as well as analyzable 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 Architecture Level  Architecture  Architecture Level Explicit modeling of relevant information Explicit modeling of relevant information

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

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

29. 29 Formal verification across models u Microarchitecture (  ) implements some architecture (  ) u A correspondence ‘ c’ between levels can be established s Function correspondence for each f  in  : c (f  ) = f   State elements correspondence: c (S  )  c (S  )  Transactions correspondence: c (T  ) = c (T  )

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

31. 31 Model Use: Runtime Validation u Suitability of microarchitectural model s Transactions provide “units of computation” s Direct modeling of resource sharing u Applications s Operational reliability: modular redundancy t Spatial, temporal, hybrid redundancy s Generic recovery t Delayed commit (Forward error recovery) t Rollback (Backward error recovery) t Reduced complexity, alternative mode of operation

32. 32 Comparative Analysis multi- level? spec?impl?data-centric?resources?analyzable?domain nML, LISA instructionsµP SystemCbehavioralx Metropolis SystemC with Extensions behavioral Kahn-process net Prod-consumer(deadlock)DSP Process calculi HOPoperationalxverificationhardware ForSpec Bluespecoperationalhardware Guarded commands transactional Synchronized transitions transactional Petri nets basic OSMs FSM/Statecharts(reachability)control/basic RTLxhardware Libertyprocessors Ptolemyembedded arch-µarchverificationhardware

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