programmable IPs against their operational ISA model Markus Wedler, - - PowerPoint PPT Presentation

▶
programmable ips
SMART_READER_LITE
LIVE PREVIEW

programmable IPs against their operational ISA model Markus Wedler, - - PowerPoint PPT Presentation

May 19, 2023 445 likes •759 views

Designing Correct Circuits 2010 Gap-Free verification of weakly programmable IPs against their operational ISA model Markus Wedler, Sacha Loitz, Wolfgang Kunz Department of Electrical and Computer Engineering University of

slide-1
SLIDE 1

Designing Correct Circuits 2010

Gap-Free verification of weakly programmable IPs against their operational ISA model

Markus Wedler, Sacha Loitz, Wolfgang Kunz Department of Electrical and Computer Engineering University of Kaiserslautern/Germany

slide-2
SLIDE 2

Designing Correct Circuits 2010

Outline

 Challenges for Formal Verification imposed by

Weakly-Programmable IPs (WPIP)

 Interval Property Checking  Specification Methodology  Gap-Free Specifications  Operational ISA model  Operation-oriented specification  Software Constraints  Completeness considerations  Applications

29.03.2010 Slide-2

slide-3
SLIDE 3

Designing Correct Circuits 2010

Slide-3

Example WPIP FlexiTreP

29.03.2010

slide-4
SLIDE 4

Designing Correct Circuits 2010

Slide-4

Example WPIP FlexiTreP

29.03.2010

Challenges:

 Deep pipelines  hard to control operations in

uppermost stages

 Out-of-order memory access  Implicit use of software constraints for

  • ptimization of the pipeline

 Huge number of configurations  ISA model not available

slide-5
SLIDE 5

Designing Correct Circuits 2010

Slide-5

Standard design flow for ASIPs

SW Algorithm Profiling Additional Instructions Generic Processor Combine ASIP

29.03.2010

slide-6
SLIDE 6

Designing Correct Circuits 2010

Slide-6

Bottom-up Design Flow for WPIPs

Micro- Architecture Algorithm A Micro- Architecture Algorithm B Micro- Architecture Algorithm C

Hallo

Design Pipeline WPIP Functional Blocks Analyze Flexibility Requirements

29.03.2010

slide-7
SLIDE 7

Designing Correct Circuits 2010 AP Int DeInt AP/ Survivor Int DeInt

WPIP FlexiTreP

 MAP

micro-architecture

 Turbo

micro-architecture

 Viterbi

micro-architecture

MAP

LLR BM REC MEM BUF BUF TB

MEM BM REC LLR/TB

29.03.2010 Slide-7

slide-8
SLIDE 8

Designing Correct Circuits 2010

SAT-based Property Checking

Slide-8

Iterative Circuit Model: from i = t to i = t + k

t, t t+1, t+1

Xt Xt+1 st Yt

t+k, t+k

Xt+k s’t+1= st+2 Yt+1 Yt+k

Boolean function to represent property p = 1?

s’t = st+1

Boolean satisfiability problem (SAT) SAT modulo Theory (SMT) problem

29.03.2010

slide-9
SLIDE 9

Designing Correct Circuits 2010

SAT-based Property Checking

 Unsatisfiability guarantees unbounded validity of G(p)  p is specified by a timed Boolean predicate (TBP) in terms of

design signals consisting of:

Boolean connectives (∧,∨,…)

Generated next state operator Xt

 A TBP p refers to bounded inspection interval of time [tf,tl]

Slide-9

t, t t+1, t+1

Xt Xt+1 st Yt

t+k, t+k

Xt+k s’t+1= st+2 Yt+1 Yt+k

Boolean function to represent property p = 1?

s’t = st+1

29.03.2010

slide-10
SLIDE 10

Designing Correct Circuits 2010

RT-level module verification: operation by operation

Typical methodology for Property Checking

  • f SoC modules:
  • Adopt an operational view of the design
  • Each operation can be associated with

certain important control states in which the operation starts and ends

  • Specify a set of properties for every
  • peration, i.e., for every important

control state

  • Verify the module operation by
  • peration by moving along the

important control states of the design

  • The module is verified when every
  • peration has been covered by a set of

properties

Control 1 Control 2

n cycles

Slide-10 29.03.2010

slide-11
SLIDE 11

Designing Correct Circuits 2010

Property Checking of processor pipeline

property instr_XYZ assume: at t: next_instr_can_be_issued(); at t: command_dec(XYZ,res,op1,op2); during[t,t+3]: no_reset; during[t,t+3]: no_interrupt; … prove: at t+3: res == compute_res(XYZ,op1,op2); at t+3: stable_other_regs(res); at t+1: next_instr_can_be_issued(); end "assumptions" "commitments"

Goal: Prove that instructions are performed correctly Spec: Safety properties of type: G(ac) with bounded inspection interval Example: Property in ITL (Interval Language)

29.03.2010 Slide-11

slide-12
SLIDE 12

Designing Correct Circuits 2010 Control 1 Control 2

/ data_path_control_signals

data path

CPU verification: instruction by instruction

Property 1: G(acontrol 1  ccontrol 2) Property 2: G(acontrol 2  ccontrol …)

n cycles

Slide-12

slide-13
SLIDE 13

Designing Correct Circuits 2010

RT-level module verification: operation by operation

Typical methodology for property checking

  • f SoC modules:
  • Adopt an operational view of the design
  • Each operation can be associated with

certain important control states in which the operation starts and ends

  • Specify a set of properties for every
  • peration, i.e., for every important

control state

  • Verify the module operation by
  • peration by moving along the

important control states of the design

  • The module is verified when every
  • peration has been covered by a set of

properties

Control 1 Control 2

n cycles

Slide-13 29.03.2010

How to guarantee that every scenario is covered?

slide-14
SLIDE 14

Designing Correct Circuits 2010

Mutation coverage

A set of (operational) properties P is complete for a design C with respect to a set of mutations M={C1,…,Cn}, if C satisfies the properties in P and for every mutation Ci at least one property fails. Problems:

 Criterion design-dependent  Do the mutations reflect designer mistakes?

29.03.2010 Slide-14

slide-15
SLIDE 15

Designing Correct Circuits 2010

Completeness

A set of (operational) properties P is complete if every two designs C1, C2 satisfying the properties in P are sequentially equivalent.

29.03.2010 Slide-15

∧p(x,s2,o2)

p∈P

empty model for C1 empty model for C2 x

∧p(x,s1,o1)

p∈P

1! 1! 1?

  • K. Claessen: “A Coverage

Analysis for Safety Property Lists”, FMCAD 2007

  • J. Bormann and H. Busch:

„Method for determining the quality of a set of properties” European Patent Application, Publication Number EP1764715, 2005.

slide-16
SLIDE 16

Designing Correct Circuits 2010

Completeness

 Practical extensions:  Allow explicit constraints on

inputs of designs

 Weaken sequential equivalence

condition by introduction of determination requirements

 Decompose proof with respect to the given properties p∈P.  Sucessor /Case-Split Test:

Every input trace can be covered with a uniquely determined sequence of properties (pi | i ∈ ℕ) such that the determination intervals match without gaps.

 Determination Test:

Every property uniquely determines the outputs within its determination interval.

29.03.2010 Slide-16

∧p(x,s2,o2)

p∈P

empty model for C1 empty model for C2 x

∧p(x,s1,o1)

p∈P

1! 1! 1?

slide-17
SLIDE 17

Designing Correct Circuits 2010

Completeness

 Decompose proof with respect to the given properties p∈P.  Sucessor /Case-Split Test:

Every input trace can be covered with a uniquely determined sequence of properties (pi | i ∈ ℕ) such that the determination intervals match without gaps.

 Determination Test:

Every property uniquely determines the outputs within its determination interval.

29.03.2010 Slide-17

state insig

  • utsig1
  • utsig2
slide-18
SLIDE 18

Designing Correct Circuits 2010

Operational ISA model

 Due to specific programming models WPIPs often lack a

classical ISA model

 Instructions correspond to hundreds of classical RISC

instructions (referred to a nuclei)

 Semantics often implicitly given by functional blocks

(operations) involved in the execution How to specify functional behavior of a WPIP?

29.03.2010 Slide-18

slide-19
SLIDE 19

Designing Correct Circuits 2010

Operational ISA model

 The operational ISA model for a WPIP consists of:  A relation OISA ⊆ I × O between the set of instructions I

and the set of (pipeline) operations O

 Timed Boolean predicates:

 instriFetched(): determines whether the instruction

i ∈ I is issued into the pipeline at a time-point t

 opo(): specifies functionality of the operation o ∈ O

29.03.2010 Slide-19

…

FE

  • 1
  • 2
  • 3
  • 4
  • n
  • p1
  • p2
  • p3
  • p4
  • p5
  • pk

Instrreg

slide-20
SLIDE 20

Designing Correct Circuits 2010

Operational ISA model

Manual specifications given by the verification engineer

 OISA ⊆ I × O  instriFetched(): determines whether the instruction

i ∈ I is issued into the pipeline at a time-point t

 opo(): specifies functionality of the operation o ∈ O

Everything else will be generated automatically!

Slide-20

slide-21
SLIDE 21

Designing Correct Circuits 2010

Operational ISA model

 Timed Boolean predicates that are automatically generated

from operational ISA model:

 instriPerformed() = ∧(i,o) ∈ OISA opo()  opoTriggered() = ∨(i,o) ∈ OISA instriFetched()  Per-Instruction properties:

 instriExec()= nextInstrState() ∧ instriFetched()

 instriPerformed() ∧ Xt(i) nextInstrState()

 Per-Operation properties:

 opoExec()=

nextInstrState() ∧ opoTriggered()  opo()

29.03.2010 Slide-21

Just another

  • peration
slide-22
SLIDE 22

Designing Correct Circuits 2010

 Determine every pair of opk, opj k ≠ j

that refer to the same resource with time slack t

 For all related instructions ik, ij store (ik, ij, opk, opj ,t) in

conflict list

Hazards imply software constraints

29.03.2010 Slide-22

…

FE

  • 1
  • 2
  • 3
  • 4
  • p1
  • p2
  • p3
  • p4
  • p5
  • pk

Instrreg shared resource

slide-23
SLIDE 23

Designing Correct Circuits 2010

Hazards imply software constraints

29.03.2010 Slide-23

 For every conflict (ik, ij, opk, opj ,t)

in conflict list decide:

 Store automatically generated constraint that forbids

sequences where ik follows ij after t clock cycles

 Manually find weaker constraint

 swConstraintj,k()= instrikFetched()flagsik()

…

FE

  • 1
  • 2
  • 3
  • 4
  • p1
  • p2
  • p3
  • p4
  • p5
  • pk

Instrreg shared resource

slide-24
SLIDE 24

Designing Correct Circuits 2010

Software compliance with constraints

29.03.2010 Slide-24

 Strong abstraction feasible for checking compliance of

software with detected and now explicitly specified constraints

…

FE

  • 1
  • 2
  • 3
  • 4
  • p1
  • p2
  • p3
  • p4
  • p5
  • pk

Instrreg shared resource

slide-25
SLIDE 25

Designing Correct Circuits 2010

Software compliance with constraints

29.03.2010 Slide-25

…

FE

  • p1
  • p2
  • p3
  • p4
  • pn
  • p1
  • p2
  • p3
  • p4
  • p5
  • pk

Instrreg

 Strong abstraction feasible for checking compliance of

software with detected and now explicitly specified constraints

 Empty models for operations (only signal names)  TBPs opkabstr() describe abstracted behavior

 Consider behavior of flagsik() only

  • p2abstr()
slide-26
SLIDE 26

Designing Correct Circuits 2010

Completeness by construction

 Case split and successor tests obviously hold and this can

easily be verified by a completeness checker Problem:

 TBPs for operations opo() only describe modified values for

involved state holding elements ⇒ other registers/memory cells remain undetermined

 Description of default behavior is required  keep value  take default value  Tedious identification of situations where default behavior

needs to be applied is completely automated

Slide-26 29.03.2010

slide-27
SLIDE 27

Designing Correct Circuits 2010

27

Experimental Results

 HW verification:  MAP and FlexiTreP, two

WPIPs for channel decoding were successfully verified.

 During the verification

subtle HW bugs were discovered which had escaped sign-off simulation before

 FlexiTreP has been

taped out successfully

 65nm low power technology  41741 standard cells, 15 macros  Die size without interface 0.74 mm2  360Mhz, core power ~100mW@1.1V  Logic utilization 77%  Silicon available since March 2009

ARM1176 CORE WIFLEX ASIP UWB-LDPC SME Mephisto TRX OFDM ARM1176 + SME RX-BIT + HARQ TRX OFDM TRX OFDM TRX OFDM Mephisto Mephisto Mephisto SME SME Mephisto SME EXT SME 80C51 TX-BIT NoC perf

LETI MAGALI MPSoC Chip

4G mobile baseband IP demonstrator

slide-28
SLIDE 28

Designing Correct Circuits 2010

Design characteristics

29.03.2010 Slide-28

MAP FlexiTreP # Instructions 16 104 Lines of RTL Code 22689 114040 Lines of ADL Code 1521 8634 # Operations (properties) 28 83 # Generated properties 14 52 CPU Time regression 37,67 s 18h Memory Usage 593 MB 14,3 GB Intel(R) Xeon(R) CPU E5440 @ 2.83GHz / SUSE 11.1

slide-29
SLIDE 29

Designing Correct Circuits 2010

Bugs discovered by FV

 Wrong sign extensions: res = op1 + op2  Wrong saturation condition in stage 13 out of 14  Confirmed bug in RTL code generation for nested if-then-

else statement of commercial ASIP design tool identified

 Scenario for a race condition of parallel value assignments

to the same variable identified

 Software constraints have been ignored by some programs

29

slide-30
SLIDE 30

Designing Correct Circuits 2010

Results for automatic completion

 FlexiTreP (for industrial application)  Automatic completion of the OISA model revealed

several inconsistencies/gaps within the property suite

 All inconsistencies have been successfully resolved  All gaps have been closed 

MAP

 SW-constraints and TBPs for default behavior have

  • riginally been set up manually.

 Automatic analysis revealed that the manual process

missed important software constraints

 Completeness of the generated property set successfully

proven with OneSpin 360 MV

 Additional manual effort one week

Slide-30