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 Conventional simulation inadequate Better approaches needed

Design verification Check that RTL conforms to Spec Catch design errors early Req/Spec RTLNetlistSilicon

What can be done? Part1 Part2

Formal design verification Checker RTL Formal Spec Yes No

Model checking initbad Clarke-Emerson 81, Queille-Sifakis 81 Bryant 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 FETCHEXECUTEWRITE-BACK

regs op src dst opr res

Opr Res Ctrl Regs Pipeline = 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.Abstraction 2.Divide and conquer

opr res isaRegs op src dst P1.dst P1.op Opr’ Res’ 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 Coverage analysis Input generation

Coverage FSM State-Space f abs Implementation State-Space f abs : Abstraction mapping f abs Non-covered state in coverage module Coverage-guided simulation Path to be covered

Coverage-guided simulation Coverage FSM State-Space Implementation State-Space f abs : Abstraction mapping f abs 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 = NOT P2.op = NOP src = P2.dst P1.op = NOT P2.op = NOT src = P2.dst P1.op = NOT P2.op = NOP src != P2.dst P1.op = NOT P2.op = NOT src != P2.dst P1.op = NOP P2.op = NOP src != P2.dst P1.op = NOP P2.op = NOT src != P2.dst P1.op = NOP P2.op = NOP src = P2.dst P1.op = NOP P2.op = NOT src = P2.dst

Coverage-guided simulation Simulation Coverage analysis Input 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 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