6. Case Study: Formal Verification of RISC Processors using HOL

Transcription

1 6. Case Study: Formal Verification of RISC Processors using HOL Page Motivation 6.2 Hierarchical RISC Model 6.12 Deriving Formal Specifications 6.13 Verification Tasks 6.17 Pipeline Correctness 6.19 Processor Specific Definitions 6.27 Experimental Results 6.29 Conclusions 6.31 References 6.32 Motivation Microprocessors containing 5M gates, doubling of frequency per generation, transistor scale by 3% per generation Conventional approaches (simulation, test) cannot guarantee complete correctness In 1994, problems with Intel Pentium and Pentium Pro microprocessors. Cost of correction about $25 M Microprocessors are used in many areas of safety-critical applications Goal: Use of formal hardware verification as a complement approach for achieving design correctness of pipelined microprocessors. 1994, 2 S. Tahar 6/7/1 6.1 (of 32) 1994, 2 S. Tahar 6/7/1 6.2 (of 32) Hardware Verification Model-checking based verification + fully automatic restrictive and the formalism is insufficient for complex circuits Theorem-prover based verification + powerful and unrestricted interactive and usable only by experts Automation can be achieved by restricting to classes of circuits, e.g. arithmetic circuits, signal processors,... RISC Processors as a class of real circuits State-of-the-Art A lot of microprocessor verification projects using different theorem provers (HOL, Boyer-Moore, SDVS) Verification of one specific processor - FM851[Hunt, 1985] - VIPER [Cohn, 1989] - Tamarack-3 [Joyce, 1989] Interpreter model [Windley, 199] used for microprogrammed not pipelined processors No existing methodology for pipelined architectures and especially for RISC processors 1994, 2 S. Tahar 6/7/1 6.3 (of 32) 1994, 2 S. Tahar 6/7/1 6.4 (of 32)

2 RISC Processors Multiple Layered Architecture Advantages: Popular and used in a wide range of applications Smaller and simpler instruction set than CISCs Hierarchical and well structured Problems: Reasoning about the pipeline verification Complexity of contemporary RISC-Processors Restriction to the core architecture Core Architecture: RISC processor base Basic pipeline Basic instruction set (integer, logic, load/ store, control) Protected Architecture Numeric Architecture Core Architecture 1994, 2 S. Tahar 6/7/1 6.5 (of 32) 1994, 2 S. Tahar 6/7/1 6.6 (of 32) Hierarchical VLSI Design Formal Verification of Microprocessors Architecture RTL Design Logic Gates Net. ADD Ri Rj SUB Ri Rj JMP ### MOV Ri Rj MEM PC RF Instr. Set Prog. Model HW-Design Transistor Net. Specification Proof Implementation Layout Behavioral Description Structural Description 1994, 2 S. Tahar 6/7/1 6.7 (of 32) 1994, 2 S. Tahar 6/7/1 6.8 (of 32)

3 RISC Instruction Execution DLX Pipeline Structure RISC Instruction: Pipeline Stages: Clock Phases: 1 Instruction Cycle u u+1 IF ID WB t t+1 t t+n s φ 1 φ 2 φ 3 φ 4 1 Clock τ Bus pr. τ τ+n p 1 Pipeline Stage RF read Instruction Classes ALU LOAD STORE CONTROL Pipeline stages IF_X ID_X ALUOUT A op B MEM_A WB_A IF_X IR M [PC] PC PC+4 A RF [rs1] φ2 B RF [rs2] φ2 IR1 IR EX_L MEM_L RF [rd] LMDR ID_X EX_S M [DMAR] SMDR IF_X ID_C φ1 1994, 2 S. Tahar 6/7/1 6.9 (of 32) 1994, 2 S. Tahar 6/7/1 6.1 (of 32) Instruction Classes RISC Verification Model Class instruction: corresponds to the set of instructions with similar semantics, e.g. ALU, FLP, LOAD, CONTROL abstracts the behavior of a group of instructions, e.g. ALU:= (ADD,SUB,SHIFT,OR,) Class Level: set of all instruction classes Class abstraction oriented proofs: -reducing the verification overhead -reasoning about few class instructions -instantiating the obtained theorems for instructions at the architectural level Architecture Level Class Level Stage Level Phase Level Hardware (EBM) Abstraction 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32)

4 Deriving Formal Specifications Deriving Formal Specifications Architecture and class levels: Specified using the instruction cycle time granularity Derived automatically from the instruction set Example: - Manual: ADD:= RF[rd] RF[rs1] + RF[rs2] - Architecture Level: ADD_Instr (...):= u:inst_cycle. RF(u+1)[rd(u)] = RF(u)[rs1(u)] + RF(u)[rs2(u)] - Class Level: ALU_Instr (...):= u:inst_cycle. RF(u+1)[rd(u)] = RF(u)[rs1(u)] op RF(u)[rs2(u)] Stage and phase levels: Specified using the clock cycle or the clock phase time granularities Derived automatically from the pipeline structure Example: - Common ID-stage: ID_Instr (...):= t: Clk_cycle. A(t+1) = RF(t) [rs1(t)] B(t+1) = RF(t) [rs2(t)] IR1(t+1) = IR(t) 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32) EBM of DLX (simplified) Hardware Formal Description ext_trap ackn Trap Control Bypass Logic IR3 IR2 IR1 IR Main Decode imem_data Instr Memory Control Unit PC and Branch Logic imem_addr rd lmdr_mux rw smdr_mux alu_op a_mux,b_mux Imm rs1 rs2 Datapath WB MEM EX ID IF alu_op Reg. File ALUout1 A ALUout ALU B Reg. File LMDR DMAR rw dmem_addr dmem_data SMDR Memory Data EBM: Specified as a hardware structure (net list) Derived automatically from a schematic in CADENCE Formally described as a hierarchy of predicates: EBM (PC, I-MEM, RF,, A, B,, IR, IR1, ) = rs1,rs2,rd,alu_op,rw, imem_adr,. DataPath (RF, A, B, Aluout, alu_op, ) Control_Unit (PC, IR, rw, imem_adr, ) Instr_Memory (I-MEM, imem_adr, ) Data_Memory (D-MEM, dmem_adr, rw, ) 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32)

5 Verification Tasks Goal: Any instruction sequence of the RISC architecture is correctly executed by the implementation (EBM) Step1: instructions I 1 EBM Instruction Level Step 2: SW_Contraints, EBM I i I ns time Correct_Instr_Pipelining Step 1: Correctness of Single Instructions Goal: The EBM implements the semantics of the instruction set correctly Hierarchical proof of the Class Level: EBM Phase Level Phase Level Stage Level Stage Level Class Level Instantiations for each architectural instruction: EBM Phase Level Stage Level Instruction Level Automatic goal settings using parameterized functions Automatic proofs using parameterized proof scripts 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32) instructions I 1 t 1 Step 2: Pipeline Correctness I i t i I ns 1Clock Goal: all combinations of n s instructions in the pipeline are executed without conflicts t ns time Pipeline Conflicts Resource conflicts (structural hazards) arise from the simultaneous use of resources Data conflicts (data hazards) occur due to data dependencies between the instructions in the pipeline Control conflicts (control hazards) arise due to the linear pipeline flow caused by control instructions Correct_Instr_Pipelining:= I 1 I ns :class_instruction. ( Resource_Conflict (I 1 I ns )) ( Data_Conflict (I 1 I ns )) ( Control_Conflict (I 1 I ns )) 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/1 6.2 (of 32)

6 Facilitating the Pipeline Conflict Verification All possible conflict combinations between n s potential instructions in the pipeline: multiple conflicts Conflicts between pairs of instructions: dual conflicts - multiple conflicts are specified in terms of dual conflicts - verification of multiple conflicts is deduced from that of dual conflicts Conflict specifications based on the hierarchy levels of the RISC model - multiple and dual conflicts are considered for each specific level - independent hierarchical proof at each level possible - Read-After-Write (RAW) - Write-After-Read (WAR) - Write-After-Write (WAW) Example: Data Conflicts Data_Conflict (I 1 I ns ):= Multiple_RAW_Conflict (I 1 I ns ) Multiple_WAR_Conflict (I 1 I ns ) Multiple_WAW_Conflict (I 1 ) Verification goal: SW_Contraints, EBM Multiple_RAW_Conflict (I 1 I ns ) Multiple_WAR_Conflict (I 1 I ns ) Multiple_WAW_Conflict (I 1 ) I ns I ns 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32) RAW Data Conflict Specification RAW Data Conflict Specification instructions I 1 t 1 I i t i I n s t ns time Stage Level Conflict: Stage_RAW_Conflict ():= ( t j - t i )< (s i - s j ) Stage_Range (I i, s i, r) Stage_Domain (I j, s j, r) I i t i I j t j s i s j R W t j t i Multiple Conflict: Multiple_RAW_Conflict (I 1 I ns ):= Dual_RAW_Conflict ((I i, t i ), (I j, t i +j-1)) i, j (i, j = 1... n s ) (i < j) Dual Conflict: Dual_RAW_Conflict ((I i, t i ), (I j, t j )):= Stage_RAW_Conflict () Phase_RAW_Conflict () Phase Level Conflict: Phase_RAW_Conflict ():= ( t j - t i )= (s i - s j ) (p j < p i ) Phase_Range (I i,s i,p i,r) Phase_Domain (I j, s j, p j, S i S j p 1 P j R W τ i/j τ j τ i P i p n p 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32)

7 ADD Ri Rj SUB Ri Rj JMP ### MOV Ri Rj RAW Data Conflict Verification Ultimate goal: I 1 I ns. Multiple_RAW_Conflict (I 1 ) Step 1: I i I j. t i t j. Dual_RAW_Conflict ((I i, t i ), (I j, t j )) Step 2: ( Dual_RAW_Conflict) ( Multiple_RAW_Conflict) Step 2 is straightforward Step 1 is equivalent to: Stage_RAW_Conflict) [( Phase_RAW_Conflict) ] I ns Stage RAW Data Conflict Verification Goal: I i I j. t i t j. s i s j. r. Stage_RAW_Conflict () Tactic: DATA_CONFLICT_TAC Stage_RAW_Conflict Subgoals: (I i = LOAD), (I j = ALU), [(s i = WB), (s j = ID), (r = RF) ] ( t j - t i ) > 3 Resolution in software ( delayed load ): SW_Constraint:= [(I i = LOAD) (I j = ALU) (r = RF)] (( t j - t i ) > 3) 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32) Processor Specific Definitions RISC Verification Methodology Enumeration types for pipeline characteristics: pipeline_stage = IF ID EX MEM WB clock_phase = φ 1 φ 2 Enumeration types for class, stage and phase instructions: class_instruction = ALU ALU_I LOAD STORE CONTROL stage_instruction = phase_instruction = Arch. Level Class Level Class Abstraction Stage Level Phase Level Model Construction EBM Enumeration types for level corresponding resources: CL_resource = PC RF of RF_addr I_MEM D_MEM IAR SL_resource = PL_resource = Semantical Correctness Architecture Level Class Level Stage Level Phase Level EBM SW- Constr. Pipeline Correctness 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32)

8 Experimental Results Experimental Results (DLX Processor) Verification Goal Time in sec Comments Predicates Extractions Resource Conflicts Conflicts RAW Conflicts Conflict cases WAR Conflicts Conflicts WAW Conflicts Conflicts Control Conflicts Conflict case Σ Pipeline Correctness Σ Semantical Correctness Σ DLX Verification (1h 33min) RISC core CPU 32 bit architecture 51 instructions 5 stage pipeline implemented in CADENCE Complexity: 15, transistors verified down to gate level in HOL 1994, 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/1 6.3 (of 32) Conclusions Theorem-prover based verification could be automated by restricting to classes of circuits: RISC processors Novel hierarchical Specification and Verification model Overhead reduction using the notion of instruction classes Two independent verification tasks: - semantical and - pipeline correctness Automatic verification using few generalized tactics Processor independent verification methodology Overall methodology implemented in the HOL system Application on a typical RISC processor (DLX) References 1. S. Tahar and R. Kumar: A Practical Methodology for the Formal Verification of RISC Processors; Formal Methods in Systems Design, Vol. 13, No. 2, September 1998, Kluwer Academic Publishers, pp S. Tahar and R. Kumar: Formal Specification and Verification Techniques for RISC-Pipeline Conflicts; The Computer Journal, Vol. 38, No. 2, July 1995, Oxford University Press, pp and other papers available at , 2 S. Tahar 6/7/ (of 32) 1994, 2 S. Tahar 6/7/ (of 32)