1 / 24

Promising Directions in Hardware Design Verification

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

ira
Download Presentation

Promising Directions in Hardware Design Verification

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Check that RTL conforms to Spec Catch design errors early RTL Netlist Silicon Design verification Req/Spec

  4. What can be done? Part1 Part2

  5. Formal design verification RTL Yes Checker No Formal Spec

  6. Model checking Clarke-Emerson 81, Queille-Sifakis 81 Bryant 86, McMillan 92, … init bad 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 P1 P2 src op dst FETCH EXECUTE WRITE-BACK

  9. regs opr res src op dst

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

  11. op isaRegs 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 • Abstraction • Divide and conquer

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

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

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

  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 Inputgeneration Coverageanalysis

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

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

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

  21. Coverage-guided simulation Simulation Inputgeneration Coverageanalysis

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

  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

More Related