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
Top Related