140 likes | 215 Views
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
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