Automatic Verification of In-Order Execution in Microprocessors with Fragmented Pipelines and Multicycle Functional Units

1
Automatic Verification of In-Order Execution in
Microprocessors with Fragmented Pipelines and
Multicycle Functional Units

• Prabhat Mishra Nikil Dutt Alex Nicolau
• Center for Embedded Computer Systems
• University of California, Irvine, USA

Hiroyuki Tomiyama ISIT, Japan
2
Outline

• Introduction
• Verification Flow
• Modelling of Processor Pipelines
• Verification of In-Order Execution
• A Case Study
• Conclusion

3
Introduction

• Embedded Systems continue to face higher
  performance requirements.
• deeply pipelined processor architectures are
  employed
• System architects need modelling techniques
• to explore, evaluate, and customize different
  processor pipeline configurations
• A major challenge Validation of specification
• whether it has certain architectural style
• We propose a top-down pipeline verification
  approach.

4
ADL Driven Exploration Flow
Processor IP Library
Processor Core
Feedback
ADL Specification
Compiler
Obj
Application
Simulator
ADL Architecture Description Language
5
Verification Flow
Processor IP Library
Processor Core
Feedback
ADL Specification
Properties
Verified
FSM Model
Failed
Application
Compiler
Obj
Simulator
6
A Fragment of the Processor Pipeline
Stagei-1
Stagei
Pipeline Latch Instruction Register
(IR) Latchji IR i, j
Stagei1
IR i, j receives instructions from p parent
units and sends them to q children units
7
Processor Pipeline Flow Conditions
Time
t
t1
t
t1
t
t1
Stage
i
i
i
i1
i1
i1
Normal Flow
Nop Insertion
Stall
Flow conditions for pipeline latches
t
t1
Time
t
t1
t
t1
pc
pc
pc
new
pc
pc
PC
PC
PC
Sequential Execution
Branch Taken
Stall
Flow conditions for Program Counter (PC)
8
Modelling of Processor Pipelines

• Processor Pipeline Description in ADL
• The EXPRESSION ADL captures structure and
  behaviour of the processor pipeline.
• The ADL captures the pipeline flow conditions for
  normal flow, stalling, and nop insertion.
• Generate FSM Model of the Processor Pipeline
• Model flow conditions in FSM
• Model State Transition Functions

9
FSM Model of Processor Pipelines

• Define a state of the n-stage pipeline as values
  of
• Program Counter
• Pipeline Latches / Instruction Registers
• S(t) lt PC(t), IR1,1(t), IR1,2(t), ., IRn-1,
  nn-1(t) gt
• where, stage i has ni pipeline latches.
• Modelling flow conditions in FSM
• A latch IRi,j ( j-th latch in stage i ) is
  stalled
• Due to stall of children
• Due to hazards, exceptions etc. on that latch
• condSTIR i,j STIR i,j STchildIR i,j
  STselfIR i,j

10
Modeling state transition functions

• PC(t1) S(t) State of the
  pipeline
• fNSPC(S(t), I(t)) I(t) Set of
  external signals
• PC(t) L if condSEPC(S(t), I(t)) 1
• target if condBTPC(S(t), I(t)) 1
• PC(t) if condSTPC(S(t), I(t))
  1
• IRi,j(t1)
• fNS IR i,j(S(t), I(t))
• IRi-1,j(t) if condNFIR i,j(S(t), I(t))
  1
• IRi,j(t) if condSTIR i,j(S(t), I(t))
  1
• nop if condNIIR i,j(S(t),
  I(t)) 1

11
Verification of In-Order Execution

• Determinism all state registers must be
  deterministic
• Three state functions must cover all possible
  combinations
• condSEPC condSTPC condBTPC 1
• condNFIR i,j condSTIR i,j condNIIR i,j 1
• Two conditions are disjoint for each next state
  function
• condxPC . condyPC 0
• conduIR i,j . condvIR i,j 0

12
Verification of In-Order Execution

• In-Order Execution State transitions of adjacent
  instruction registers must depend on each other.
• An instruction register cannot be in normal flow
  if all the parent instruction registers (adjacent
  ones) are stalled.
• condSTIR i-1,j . condNFIR i,k 0 ( for all i,
  j, k )
• If such a combination is allowed, the instruction
  is duplicated and stored into both IRi-1,j and
  IRi,k in the next cycle.

IRi-1,j
Stall
IRi,j
Normal Flow
13
Verification of In-Order Execution

• Finiteness The previous two properties do not
  guarantee that execution of instructions will be
  completed in a finite number of cycles.
• A stage must flow within a finite number of
  cycles if all the later stages are idle.
• condxIR i,j ( ) can be a
  function of external signals and IRk,y where k gt
  i, but cannot be a function of IRk,y where k lt i

14
Automatic Verification Framework
Processor Core
EXPRESSION ADL
FSM Model
Equations
Eqntott
Espresso
Success
Analyze
Failure
15
A Case Study

• Applied the methodology on single-issue DLX
  processor
• ADL Specification
• (DecodeUnit Decode
• (CONDITIONS
• (NF ANY ANY)
• (ST ALL)
• (NI ALL ANY)
• (SELF )
• )
• )
• Flow Conditions
• condSTDEC STEX . STM1 . STA1 . STDIV

A fragment of the DLX pipeline
16
A Case Study

• A small trace of the property checking in our
  validation framework
• condNFDEC condSTDEC condNIDEC
• STPC . (STEX STM1 STA1 STDIV )
• (STEX . STM1 . STA1 . STDIV )
  
• STPC . (STEX STM1 STA1 STDIV )
• (STEX STM1 STA1 STDIV ) . (STPC STPC )
  
• (STEX . STM1 . STA1 . STDIV)
• 1

17
A Case Study

• Violation of In-Order Execution scenarios
• Multiply followed by addition operation
• Leads to out-of-order execution
• Modified stall condition for decode in ADL
• Two operations completed execution at the same
  time
• Potential for data loss since WB can write only
  one data per cycle
• Added feedback paths
• The complete verification took 41 seconds on 333
  MHz Sun Ultra-5 with 128M RAM.

18
Summary

• Validation of specification is a major challenge
• We propose a top-down pipeline verification
  approach
• Specify the processor pipeline in ADL
• Generate FSM model of the processor pipeline
• Verify in-order execution using a set of
  properties
• We present an automatic validation framework.
• We applied our methodology on DLX processor.
• The future work includes
• Support for hazards and multiple exceptions
• Extending the verification technique towards VLIW
  and Superscalar architectures