140 likes | 156 Views
Explore teaching methods for functional verification labs, including design automation techniques and mechanics. Agenda includes lab administration, grading, and student team sizes. Emphasizes reuse, regression testing, and code coverage.
E N D
Teaching Functional Verification: Lab Mechanics Design Automation Conference Sunday, June 9, 2002
Agenda • Administration • Lab 1 • Lab 2 • Lab 3 • Grading
Administration • Length of labs • Lab 1 – 1 week • Lab 2 – 4 weeks • Lab 3 – 4-6 weeks • Instructor/TA Availability • Lab 1 – e-mail/office hours • Lab 2 – e-mail/office hours/1-2 lab days • Lab 3 – e-mail/office hours/3-4 lab days
Administration (continued) • Website with lab specifications • Student Message Board • Students helping students • Monitored/Administrated by Instructor • Student Team Sizes • Lab 1 – Individual • Lab 2 – Individual • Lab 3 – Individual or groups of 2 • Individual requires more time
Lab 1 • Focused on directed type testing • Black box approach • No visibility into RTL • Input to output type tests • Bus Functional Models (BFM) provided • Students need only to use the BFM’s • Bugs fixed by setting “error” input signal • Students hand in bug analysis
Post Lab 1 exercise • Discuss deficiencies of lab 1 • Specification • Directed nature • Discuss better approach • Pseudo-random stimulus • Self-checking • Discuss nature of bugs
Lab 2 • Build upon lab 1 and lecture material • Given starting point reference from solution (better approach) of lab 1 • Introduce High Level Verification Languages (HVL’s) • Grey box approach • Provide a testplan from lab 1 • Introduce students to debug
Lab 2 (continued) • Bug fixes are done by “forcing” internal nets • If using VHDL, use procedures with FLI calls • This reduces instructors maintenance work load on design • If using Verilog/HVL, force nets directly • Introduce students to “regression” • Provide ability for students to regress • Students hand in testplan and bug analysis
Post Lab 2 exercise • Discuss deficiencies of lab 2 • When are we done? • Coverage • Maintenance of code in environment • Lab 1 solution not well commented • Reuse • Discuss nature of bugs • Establish Coding guidelines for regression purposes (pass, fail, etc)
Lab 3 • Builds upon lab 2 and lecture material • Provide lab 2 solution • Coverage oriented • Provide mechanism for code coverage • Provide functional coverage goals • Testplan becomes more of a functional coverage plan • Same approach as lab 2 for bug fixes and debug • Students hand in testplan
Grading • Lab 1 • Bug analysis • Lab 2 • Testplan and bug analysis • Lab 3 • Perform “escape analysis” for each group • “Panel” session • What bugs were found • What techniques were used • Poke holes in environment • Ensure environment followed testplan
Grading (continued) • Complete bug discovery isn’t necessary for “A” • Testplan • Environment • Methodology
Summary • Each lab builds upon itself • Emphasizes reuse and maintenance • Labs emphasize lecture material • Testplan • Pseudo-random • Self-checking • Regressions • Coverage
Summary (continued) • Labs are time intensive • Students time • Instructors time • May opt to have some classes as “lab sessions” depending on schedule and syllabus