1. Promising Directions in Hardware Design Verification Shaz Qadeer Serdar Tasiran Compaq Systems Research Center

2. 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

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

4. What can be done? Part1 Part2

5. Formal design verification Checker RTL Formal Spec Yes No

6. Model checking initbad Clarke-Emerson 81, Queille-Sifakis 81 Bryant 86, McMillan 92, … Problem : State space explosion !

7. 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)

8. regs op src dst P1 P2 FETCHEXECUTEWRITE-BACK

9. regs op src dst opr res

10. Opr Res Ctrl Regs Pipeline = Regs || Opr || Res || Ctrl

11. isaRegs op src dst ISA Correctness condition : P1.op = NOP  P2.op = NOP  regs = isaRegs

12. 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

13. opr res isaRegs op src dst P1.dst P1.op Opr’ Res’ Abstraction

14. Regs || Opr || Res || Ctrl || ISA  Opr’ || Res’ Regs || Opr’ || Res’ || Ctrl || ISA satisfies I Regs || Opr || Res || Ctrl || ISA satisfies I

15. Assume-guarantee reasoning Regs || Opr || Res || Ctrl || ISA  Opr’ || Res’ Regs || Opr’ || Res || Ctrl || ISA  Res’ Regs || Opr || Res’ || Ctrl || ISA  Opr’

16. 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

17. Coverage-guided simulation Simulation Coverage analysis Input generation

18. 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

19. 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

20. 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

21. Coverage-guided simulation Simulation Coverage analysis Input generation

22. 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

23. Applications DEC/Compaq –Kantrowitz-Noack 96 IBM –Benjamin et al. 99 Intel –Ur-Yadin 99 Synopsys –Ho et al. 00

24. Conclusions Ideally –design+verification –compositional model checking –exhaustive and scalable Really –unstructured non-hierarchical designs –compositional reasoning difficult –make simulation smarter