1 / 23

Using UVM: The Condensed Guide For Designers, Debuggers, Test-Writers And Other Skeptics

February 25-28, 2013 DoubleTree , San Jose. Using UVM: The Condensed Guide For Designers, Debuggers, Test-Writers And Other Skeptics. by Gordon Allan Verification Methodologist Mentor Graphics Corp, Fremont CA. What's it all about?. Team, not Tech Results , not Process

israel
Download Presentation

Using UVM: The Condensed Guide For Designers, Debuggers, Test-Writers And Other Skeptics

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. February 25-28, 2013DoubleTree, San Jose Using UVM:The Condensed Guide For Designers, Debuggers, Test-Writers And Other Skeptics byGordon AllanVerification MethodologistMentor Graphics Corp, Fremont CA

  2. What's it all about? • Team, not Tech • Results, not Process • The Chip, not the UVM • Abstraction that Simplifies • Questions & Answers

  3. What's it all about? • Team, not Tech • Design/Verification is a craft, not a science • One part Technology, Two parts Peopleware • Results, not Process • The Chip, not the UVM • Abstraction that Simplifies • Questions & Answers

  4. Peopleware • Verification • Architecture • Infrastructure • DUT-specific • Protocol-specific • Design • Architecture • Micro-architecture • RTL coding • Integration • Management

  5. Usability Requirements • design team is a customer • capture user interface requirements • monitor ease of use... and fix it • customer is always right...?

  6. Usability Requirement:Concurrent Development • DUT first? • missed architectural defects • verification on schedule critical path • Testbench first? • fragile checking - too many fails • difficult to prioritize features/depth • DUT and Testbench in parallel • incremental, prioritized features • address hotspots, design intent at the time • design/verification teamwork

  7. Murphy's Law > Moore's Law

  8. Usability Requirement:Zero UVM or OOP knowledge • Typical activities: • execute a test • turn on some debug • clone and tweak a testcase • Templates • basic test structure • config/setup/stimulusknobs • catch common errors

  9. What's it all about? • Team, not Tech • Results, not Process • Success: "On Time" and "No Bugs" • Tradeoff triangle: Quality vs Cost vs Scope • The Chip, not the UVM • Abstraction that Simplifies • Questions & Answers

  10. Usability Requirement:A config parameter 'Dashboard' • locate all config settings together • easy reference and modification • document of each config group • how they are set • where they are used • document each setting • defaults • available values • how randomized and constrained • where they are used

  11. Usability Requirement:A debug settings dashboard • Debug settings are: • in SV/UVM code • on simulator command line • simulator-specific debug features • Often cryptic • need to read several reference docs • Set and/or document in one file • e.g. debug.svh • one-stop diagnostic panel

  12. What's it all about? • Team, not Tech • Results, not Process • The Chip, not the UVM • Relevant tools and technology • Measure contribution, not complexity • Abstraction that Simplifies • Questions & Answers

  13. Usability Requirement:A well-defined signal interface • single SV file • e.g. top.sv or dut.sv • single module defines the DUT • from the testbench's point of view • all interface hookup to DUT pins • including internal test/force/backdoor • avoid unnecessary indirection • if required, document and log it

  14. Usability Requirement:Easy DUT programming model • a simple representation • DUT registers • other dynamic config / state • accessible to testcase writers • easy to setup DUT internals • easy to determine DUT state • easy to synchronize to high level events

  15. Abstraction • How to makesense of acomplex design?

  16. Abstraction • Code? • does not simplify • transformation,not abstraction

  17. Abstraction • UML? • a different representation • attempts to modularize • Missing the point • abstraction is supposed to simplify!

  18. Abstraction • A simple, easy,intuitive, user interface • ALL details hidden

  19. Usability Requirement:Easy DUT programming model • a simple representation • DUT registers • other dynamic config / state • accessible to testcase writers • easy to setup DUT internals • easy to determine DUT state • easy to synchronize to high level events

  20. What's it all about? • Team, not Tech • Results, not Process • The Chip, not the UVM • Abstraction that Simplifies • Reduces Complexity • Leverages Knowledge • Does not Impose Burdens • Questions & Answers

  21. Usability Requirement:Protocol-centric Stimulus API • Test scenarios • how to set up • what to do • Time domain • what to synchronize • how to parallelize/overlap • Results checking • what to test • Predefined Templates • AND manual overrides

  22. Usability Requirement:A standard waveform setup • Structured DUT activity • leverage the well-defined interface hookup • protocol-centric signal groups • standard abstractions (enums, constants) • Abstracted testbench activity • progress of tests, stimulus, checks • transactions, related to signal groups • Rapid comprehension • maintained in sync with changing design

  23. What's it all about? • Team, not Tech • Results, not Process • The Chip, not the UVM • Abstraction that Simplifies • Questions & Answers • mailto:gordon_allan@mentor.com • http://verificationacademy.com

More Related