6. case study: formal verification ofrisc processors usinghol

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.