Enhancing Verification Efficiency: Reuse Strategies from the 2005 Seminar with Itai Nadler
This document discusses key concepts and strategies presented by Itai Nadler in the 2005 Verification Leadership Seminar, focusing on the advantages of reuse in verification processes. Highlights include methods to shorten verification time, facilitate knowledge transfer, and reduce unfound bugs. It emphasizes the importance of organizational infrastructure and modular architecture, the role of integrated documentation, and leveraging expertise from IP verification engineers. A case study also illustrates practical applications of these concepts in system validation.
Enhancing Verification Efficiency: Reuse Strategies from the 2005 Seminar with Itai Nadler
E N D
Presentation Transcript
Verification reuse Itai Nadler Verification leadership seminar 2005
DV reuse – introduction • Reuse (obvious) advantages - Shortens the verification time. - It’s a mean of transferring knowledge between teams. - Will decrease the chance for unfound Bugs !!! • There are two kinds of reuse - across similar projects ( next generation designs or similar designs) - Between IP developments and system development.
Basic requirements for easy reuse • Organization infrastructure - Shared data base for common Verification Components - Adopting similar verification methodologies across the organization. - When possible , joint specification of the VC by all optional users. • Building a VC dedicated for reuse - High quality documentation. - Modular architecture ( for instance make it easy to replace the registers description ). - Build a hardware interface - Build a User interface
IP to System reuse • Leverage the knowledge of the IP verification engineer. - IP engineer can recommend a basic set of tests which ensures the proper integration of the IP. - The same thing could also be done by issuing a reduced set of verification goals. • Building the VC for reuse in system - Checkers and scoreboards should be based on monitors ( and not the drivers). - Co-exist with other VC and with several instantiation of the same VC. - When possible , the system verification engineer should be involved in the specification of the VC, in order to adjust the VC for system special needs ( for example different handling of interrupts ).
Interesting case of reuse • The following slide was presented by Roy Sofer in the 2003 Verisity users group convention.
S D R A M PC PC SoC EMIF MIPS Eth eVC GMII eVC Ethernet MAC master Host Protocol eVC Eth eVC GMII slave Intr • Need to shift the already written • e-drivers/BFM to c-code that will • be executed by the CPU. • We get the 2 Master Problem. • The CPU become a degenerate • master of a test. • Almost all the Host side eVC • transaction should be called by • the CPU OPCODE WR_RD CMD OPCODE Back-Door eVC Legend : Virtual “rd_wr_vbus” function DV PDR Release w/o change System VBUS eVC According to eRM/sVM -eVC Drivers and test become passive. -only the monitor is still active • Our goal is to extend the eRM/sVM methodology and reuse the whole IP DV • Activate the IP DV Drivers/BFM and tests within SoC test (no change in IP DV – transparent) • No static verification (no pre-defined tests) • One master of the test flow VBUS eVC