1 / 6

Verification reuse

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 !!!

morty
Download Presentation

Verification reuse

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. Verification reuse Itai Nadler Verification leadership seminar 2005

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

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

  4. 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 ).

  5. Interesting case of reuse • The following slide was presented by Roy Sofer in the 2003 Verisity users group convention.

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

More Related