Promising directions in hardware design verification
Download
1 / 24

Promising Directions in Hardware Design Verification - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

Promising Directions in Hardware Design Verification. Shaz Qadeer Serdar Tasiran Compaq Systems Research Center. Hardware design verification. Verification consumes more than 70% of resources compute cycles human cycles Time to market affected Bugs remain undetected

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Promising Directions in Hardware Design Verification' - ira


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Promising directions in hardware design verification

Promising Directions in Hardware Design Verification

Shaz Qadeer

Serdar Tasiran

Compaq Systems Research Center


Hardware design verification
Hardware design verification

  • Verification consumes more than 70% of resources

    • compute cycles

    • human cycles

  • Time to market affected

  • Bugs remain undetected

  • Conventional simulation inadequate

  • Better approaches needed


Design verification

Check that RTL conforms to Spec

Catch design errors early

RTL

Netlist

Silicon

Design verification

Req/Spec


What can be done
What can be done?

Part1

Part2


Formal design verification
Formal design verification

RTL

Yes

Checker

No

Formal Spec


Model checking
Model checking

Clarke-Emerson 81, Queille-Sifakis 81

Bryant 86, McMillan 92, …

init

bad

Problem : State space explosion !


Compositional model checking
Compositional model checking

  • Abstraction followed by divide and conquer

  • Case studies

    • STARI chip (Tasiran-Brayton 97)

    • Tomasulo’s algorithm (McMillan 97, Henzinger-Qadeer-Rajamani 98)

    • Coherence protocol processor (Eiriksson 98)

    • VGI parallel DSP (Henzinger-Liu-Qadeer-Rajamani 99)

    • Microarchitecture (Jhala-McMillan 01)


Promising directions in hardware design verification

regs

P1

P2

src

op

dst

FETCH

EXECUTE

WRITE-BACK


Promising directions in hardware design verification

regs

opr

res

src

op

dst


Promising directions in hardware design verification

Pipeline =

Regs || Opr || Res || Ctrl

Regs

Opr

Res

Ctrl


Promising directions in hardware design verification

op

isaRegs

src

dst

ISA

Correctness condition :

P1.op = NOP  P2.op = NOP  regs = isaRegs


Verification problem
Verification problem

Pipeline || ISA =

Regs || Opr || Res || Ctrl || ISA

satisfies the invariant

I: P1.op = NOP  P2.op = NOP  regs = isaRegs

  • Abstraction

  • Divide and conquer


Promising directions in hardware design verification

Abstraction

op

isaRegs

src

dst

opr

Opr’

P1.op

Res’

res

P1.dst


Abstraction

Regs || Opr || Res || Ctrl || ISA satisfies I

Abstraction

Regs || Opr’ || Res’ || Ctrl || ISA satisfies I

Regs || Opr || Res || Ctrl || ISA  Opr’ || Res’


Assume guarantee reasoning
Assume-guarantee reasoning

Regs || Opr’ || Res || Ctrl || ISA  Res’

Regs || Opr || Res’ || Ctrl || ISA  Opr’

Regs || Opr || Res || Ctrl || ISA  Opr’ || Res’


Promising directions in hardware design verification
But…

  • Compositional techniques require

    • manual effort

    • design+verification methodology

  • Validation relies heavily on simulation

    • hand-written tests

    • random inputs

  • Validation quality

    • hard to quantify

    • difficult to improve


Coverage guided simulation
Coverage-guided simulation

Simulation

Inputgeneration

Coverageanalysis


Coverage guided simulation1
Coverage-guided simulation

Coverage FSM

State-Space

Non-covered state in coverage module

Path to be covered

fabs : Abstraction mapping

fabs

fabs

Implementation State-Space


Coverage guided simulation2
Coverage-guided simulation

Coverage FSM

State-Space

Uncovered state

Path to be covered

fabs : Abstraction mapping

fabs

fabs

Implementation State-Space

One corresponding path in implementation


Coverage module for pipeline

P1.op = NOT

P2.op = NOP

src != P2.dst

P1.op = NOT

P2.op = NOP

src = P2.dst

P1.op = NOP

P2.op = NOP

src != P2.dst

P1.op = NOP

P2.op = NOP

src = P2.dst

P1.op = NOT

P2.op = NOT

src = P2.dst

P1.op = NOP

P2.op = NOT

src != P2.dst

P1.op = NOP

P2.op = NOT

src = P2.dst

P1.op = NOT

P2.op = NOT

src != P2.dst

Coverage module for pipeline

  • Recommended practice: construct coverage modules along with design


Coverage guided simulation3
Coverage-guided simulation

Simulation

Inputgeneration

Coverageanalysis


Input sequence generation
Input sequence generation

  • Difficult SAT problem

  • Environment constraints on implementation inputs:

    • Combinational: e.g. input to processor must be legal instruction

    • Sequential: e.g. branch delay slots


Applications
Applications

  • DEC/Compaq

    • Kantrowitz-Noack 96

  • IBM

    • Benjamin et al. 99

  • Intel

    • Ur-Yadin 99

  • Synopsys

    • Ho et al. 00


Conclusions
Conclusions

  • Ideally

    • design+verification

    • compositional model checking

    • exhaustive and scalable

  • Really

    • unstructured non-hierarchical designs

    • compositional reasoning difficult

    • make simulation smarter