Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
6. Case Study: Formal Verification of RISCProcessors using HOL
6.1 (of 29)
MotivationRISC Verification Model Deriving Formal Specifications Verification TasksPipeline Correctness Processor Specific Definitions Experimental Results ConclusionsReferences
Page
6.26.96.106.146.166.246.276.286.29
RISC Processors
6.2 (of 29)
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
Multiple Layered Architecture
Core Architecture:
• RISC processorbase
• Basic pipeline
• Basic instructionset (integer, logic,load/ store, control)
Protected Architecture
Numeric Architecture
Core Architecture
6.3 (of 29)
Hierarchical VLSI Design
Architecture
RTL Design
Logic Gates Net.
Transistor Net.
Layout
6.4 (of 29)
Formal Verification of Microprocessors
Prog. ModelInstr. Set HW-Design
Specification ImplementationProof
Behavioral Description Structural Description
M E M
PC
RF
••
6.5 (of 29)
A D D Ri Rj S U B Ri Rj J M P ### M O V Ri Rj
••••
RISC Instruction Execution
1 Instruction Cycle
t+ns... ...Pipeline Stages:
t+2
+1 ...... +np
IF ID WB
t t+1
1 Clock
......u u+1RISC Instruction:
Clock Phases:
Bus pr.
1
2
3
4
RF read
1 Pipeline Stage
6.6 (of 29)
MIPS PipelineStructure
6.7 (of 29)
Pipeline stagesIF ID EX MEM WB
Inst
ruct
ion
Cla
sses
ALU IF_X ID_X ALUOUTA op B MEM_A WB_A
LOAD IF_XA RF [rs1]
2
B RF [rs2]2
IR1 IR
EX_L MEM_L RF [rd] LMDR1
STORE IR M [PC]
PC PC+4ID_X EX_S M [DMARSMDR –
CONTROL IF_X ID_C – – –
Instruction Classes
6.8 (of 29)
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
RISC Verification Model
Architecture Level
Phase Level
Stage Level
Class Level
Hardware (RTL)
Abstraction
6.9 (of 29)
Deriving Formal Specifications
6.10 (of 29)
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)]
Deriving Formal Specifications
6.11 (of 29)
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)
RTL of MIPS(simplified)
LMDR
DMAR SMDRALUout
A B
rs1 rs2
Imm
ControlUnitrd
ALUout1
Dat
aMem
ory
dmem_addr
dmem_dataMEM
EX
ID
WB
Datapath
IR3
IR
IR2
IR1
IFInstr Memory imem_addr
imem_data
Bypass Logic
PC andBranchLogic
Main Decode
TrapControl
ackn
ext_trap
rw
alu_op
a_mux,b_mux
smdr_mux
lmdr_mux
rw
alu_op ALU
Reg.File
Reg.File
6.12 (of 29)
Hardware Formal Description
6.13 (of 29)
RTL:
• Specified as a hardware structure (net list)
• Derived automatically from a schematic in CADENCE• Formally described as a hierarchy of predicates:
RTL (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, …)
Verification Tasks
Goal: Any instruction sequence of the RISC architecture is correctly executed by the implementation (RTL)
Step1: RTL Instruction Level
Step 2: SW_Contraints, RTL Correct_Instr_Pipelining
I1
time
inst
ruct
ions
IF ID EX MEM WB… IF ID EX MEM WB
Ii IF ID EX MEM WB… IF ID EX MEM WB
Ins IF ID EX MEM WB
6.14 (of 29)
Step 1: Correctness of Single Instructions
6.15 (of 29)
Goal: The RTL implements the semantics of the instruction set correctly
• Hierarchical proof of the Class Level:RTL Phase LevelPhase Level Stage Level Stage Level Class Level
• Instantiations for each architectural instruction:RTL Phase Level Stage Level Instruction Level
Automatic goal settings using parameterized functions Automatic proofs using parameterized proof scripts
Step 2: Pipeline Correctness
Goal: all combinations of ns instructions in the pipeline are executed without conflicts
1t0
it0
nst0
1Clock
I1
time
inst
ruct
ions
IF
6.16 (of 29)
ID EX MEM WBIi
…
…
Ins
IF ID EX MEM WBIF ID EX MEM WB
IF ID EX MEM WBIF ID EX MEM WB
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:= I1 … Ins: class_instruction.
( Resource_Conflict (I1 … Ins))( Data_Conflict (I1 … Ins)) ( Control_Conflict (I1 … Ins))
6.17 (of 29)
• All possible conflict combinations between ns 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
Facilitating the Pipeline Conflict Verification
6.18 (of 29)
Example: Data Conflicts
Verification goal:SW_Contraints, RTL
- Read-After-Write (RAW)- Write-After-Read (WAR)- Write-After-Write (WAW)
Data_Conflict (I1 … Ins):= Multiple_RAW_Conflict (I1 … Ins) Multiple_WAR_Conflict (I1 … Ins) Multiple_WAW_Conflict (I1 … Ins)
Multiple_RAW_Conflict (I1 … Ins) Multiple_WAR_Conflict (I1 … Ins) Multiple_WAW_Conflict (I1 … Ins)
6.19 (of 29)
RAW Data Conflict Specification
Multiple Conflict:
i ji, j
(i, j = 1 ... ns) (i < j)
Dual Conflict: i jStage_RAW_Conflict (…)Phase_RAW_Conflict (…)
it0
nst0
1t0 time
inst
ruct
ions I1
…Ii
…Ins
Multiple_RAW_Conflict (I1 … Ins):=
i0Dual_RAW_Conflict ((I , t ), (I , t +j-1))i
0
i
6.20 (of 29)
0Dual_RAW_Conflict ((I , t ), (I , t )):=j0
RAW Data Conflict Specification
Stage Level Conflict:Stage_RAW_Conflict (…):=
i jStage_Range (Ii, si, r) Stage_Domain (Ij, sj, r)
j(t - t ) (s - s )i0 0
it0
jt0itW
jtR
Ii
Ij
si
sj
Phase Level Conflict:Phase_RAW_Conflict (…):=
i j(pj pi) Phase_Range (Ii, si, pi,r)
j j jPhase_Domain (I , s , p ,
j i(t0 - t0) (s - s )
i/j0ij
R W
Si Sj
…p1 … pnp
Pj
Pi
6.21 (of 29)
RAW Data Conflict Verification
Ultimate goal:
Step 1: Ii Ij.
¬ Dual_RAW_Conflict ((I ,
Step 2: (¬ Dual_RAW_Conflict) (¬ Multiple_RAW_Conflict)
(¬ Stage_RAW_Conflict) Step 2 is straightforward
Step 1 is equivalent to: [ ](¬ Phase_RAW_Conflict)
I1 … Ins.¬ Multiple_RAW_Conflict (I1 … Ins)
i j t0 t0.i i j
0t ), (I , t ))j0
6.22 (of 29)
Stage RAW Data Conflict Verification
Goal: i j si sj. r.
¬ Stage_RAW_Conflict (…)
Tactic: DATA_CONFLICT_TAC Stage_RAW_Conflict
Subgoals:i j(I = LOAD), (I = ALU),[ ](si = WB), (sj = ID), (r = RF)
Resolution in software (“delayed load”):SW_Constraint:=[(I = LOAD) (Ii j = ALU) (r = RF) 3)
i I I . t t .j0 0
j i( t0 - t0) 3
j
6.23 (of 29)
] (( t - t )i0 0
Processor Specific Definitions
6.24 (of 29)
• Enumeration types for pipelinecharacteristics: pipeline_stage = IF | ID | EX | MEM | WB clock_phase = |
• Enumeration types for class, stage and phase instructions: class_instruction = ALU | ALU_I | LOAD | STORE | CONTROL stage_instruction = …phase_instruction = …
• Enumeration types for level corresponding resources: CL_resource = PC | RF of RF_addr | I_MEM | D_MEM | IAR SL_resource = …PL_resource = …
RISC Verification Methodology
6.25 (of 29)
RTL
ADD Ri Rj SUB Ri Rj JMP ###
MOV Ri Rj•••
Pipeline CorrectnessSemanticalCorrectness
Architecture Level Class Level
Stage Level
Phase Level
RTL
Model Construction
Phase Level
Stage Level
Arch. Level
Class Level
Class Abstraction
SW-Constr.
Experimental Results
6.26 (of 29)
Verification Goal Time in sec CommentsPredicates Extractions 1841.39 -Resource Conflicts 986.69 0 ConflictsRAW Conflicts 581.59 2 Conflict casesWAR Conflicts 536.86 0 ConflictsWAW Conflicts 576.55 0 ConflictsControl Conflicts 124.49 1 Conflict case Pipeline Correctness 4647.57 - Semantical Correctness 960.50 - MIPS Verification 5608.07 (1h 33min)
• RISC core CPU• 32 bit architecture• 51 instructions• 5 stage pipeline
• implemented in CADENCE
• Complexity: 150,000 transistors
• verified down to RTL in HOL
6.27 (of 29)
Experimental Results (MIPS Processor)
• Theorem-prover based verification could be automated by restricting to classes of circuits: RISC processors
• Novel hierarchical Specification and Verificationmodel• 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 (MIPS)
Conclusions
6.28 (of 29)
References
6.29 (of 29)
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. 159-225.
2. 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. 111-120.