Promising Directions in Hardware Design

VerificationShaz Qadeer

Serdar TasiranCompaq Systems Research

Center

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

Req/Spec

RTL

Netlist

Silicon

What can be done?

Exhaustive Automatic Scalable

Simulation Model checking Compositional model checking

Coverage-guided simulation

Part1

Part2

Formal design verification

Checker

RTL

Formal Spec

Yes

No

Model checking

init bad

Clarke-Emerson 81, Queille-Sifakis 81Bryant 86, McMillan 92, …

Problem : State space explosion !

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)

regs

op

src

dst

P1 P2

FETCH EXECUTE WRITE-BACK

regs

op

src

dst

opr res

Opr Res

Ctrl

RegsPipeline =

Regs || Opr || Res || Ctrl

isaRegs

op

src

dst

ISA

Correctness condition :P1.op = NOP P2.op = NOP regs = isaRegs

Verification problem

Pipeline || ISA = Regs || Opr || Res || Ctrl || ISA

satisfies the invariant

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

1. Abstraction2. Divide and conquer

opr

res

isaRegs

op

src

dst

P1.dstP1.op

Opr’

Res’

Abstraction

Abstraction

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

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

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

Assume-guarantee reasoning

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

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

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

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

Simulation

Coverageanalysis

Inputgeneration

Coverage FSMState-Space

fabs

Implementation State-Space

fabs : Abstraction

mappingfabs

Non-covered state in

coverage module

Coverage-guided simulation

Path to be covered

Coverage-guided simulation

Coverage FSMState-Space

Implementation State-Space

fabs : Abstraction

mappingfabs fabs

Path to be covered

One corresponding path in

implementation

Uncovered state

Coverage module for pipeline

• Recommended practice: construct coverage modules along with design

P1.op = NOTP2.op = NOPsrc = P2.dst

P1.op = NOTP2.op = NOTsrc = P2.dst

P1.op = NOTP2.op = NOPsrc != P2.dst

P1.op = NOTP2.op = NOTsrc != P2.dst

P1.op = NOPP2.op = NOPsrc != P2.dst

P1.op = NOPP2.op = NOTsrc != P2.dst

P1.op = NOPP2.op = NOPsrc = P2.dst

P1.op = NOPP2.op = NOTsrc = P2.dst

Coverage-guided simulation

Simulation

Coverageanalysis

Inputgeneration

• Difficult SAT problem• Environment constraints

on implementation inputs: – Combinational: e.g. input to

processor must be legal instruction

– Sequential: e.g. branch delay slots

Input sequence generation

Applications• DEC/Compaq

– Kantrowitz-Noack 96

• IBM – Benjamin et al. 99

• Intel– Ur-Yadin 99

• Synopsys– Ho et al. 00

Conclusions• Ideally

– design+verification– compositional model checking– exhaustive and scalable

• Really– unstructured non-hierarchical designs– compositional reasoning difficult– make simulation smarter