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 • 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 T2 reg Shared memory

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

13. Architecture Model: Describing a Transaction w edge predicate • 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 1 Transaction Graph … s’f(s) state updates: w = P(s’) predicates: 1 end step start step 2 1 out-edges ordered 2 …

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 D1 D2 end W R JPEG Parse-Stream/Control Transaction Interpret scan header Interpret frame header SOS marker? is_SOS is_SOF Decoder setup SOF marker? 2 is_SOI not_SOF 1 is_DQT  is_DHT 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 function—ALU ALU_resource Data dependence—register 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. Computation modeled as transactions Uncluttered by implementation details Interactions only due to shared data Is executable as well as analyzable 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 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

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