Efficient Verification Environment with Synopsys Vera & VCS

1. Efficient Verification Environment with Synopsys Vera & VCS Alexander Gnusin

2. Environment Concepts & Techniques Concepts: • “Dynamic Snapshot” Concept • Data Sharing: Shadowing Concept • Configurations Concept • Fast Initialization Concept • Short Regressions Concept Techniques: • Reusable project environment & scripts • Compilation techniques • Fast Initialization techniques • Random Testing techniques

3. Problems with previous environment • Difficulties to preserve constant stability: Regression preparation • User code variations: RCS User1 User2 User3

4. Problems with previous environment(cont) • Fear to update “stable” code in user directory: Updated Code Relelase • Inherent instability of latest RCS design versions: Modifications Anybody RCS database Modifications Any Time

5. Dynamic Snapshot concept • We need to admit, that latest design presentation in RCS DB is unstable • However, everybody wants to have updated and functionally stable design! • Solution: constantly maintain stable design outside of RCS DB, in the write-protected project area • This stable design does not replace RCS DB: it complements it!

6. Maintaining stable design • Designers can make as many CI/CO operations with RCS DB as they want • Designers inform test engineer when they have functionally stable version. • Verification engineer runs short functional-specific regression to verify updated module(s). • In a case of success, verification engineer updates stable design representation Test Engineer RCS DB Stable design

7. RCS RCS DB Filtering Stable DB User1DB User2 DB User3 DB Users “Delta” files Shadowing concept • Users and Stable DB directory directory structure is the same • However, users directories are initially empty • If file is not found in User DB, take it from Stable DB • Users DB contains only files User change • Best practice: minimize amount of files in user’s directory!

8. Two types of project data • Stable data (common) • Data-under-development: • Versions: functionally stable shared development space • Users: users directories to override the portion of shared data Users Common Versions Scripts, Documents, Models, PLI etc Shared development space Users shadowing

9. Configurations concept • Maintain different top-levels based on the same design and verification library • Pair of matching design and verification Top Levels forms the Project Configuration Top1 Top2 Top3 CFG1 OpenVera Domain Vera Modules Library Verilog Domain Top1 Top2 Top3 Verilog Modules Library

10. Core1 Top Core2 Core1 Top Core2 Solution for Integration project OpenVera Domain • Core1, Core2: core-level configurations • Top : top-level configuration Vera Modules Library All configurations, as core-level, as system and chip-level, reuse the same design and verification library components. Solves data synchronization problems in integration SOC projects Verilog Modules Library Verilog Domain

11. All possible configurations General configuration “Defines” area Useful configurations Multiple project configurations • Assumption: Chip-level interface is stable. • Different verification environment is required for the same chip • Our project example: • Configuration 1: LL BFM and test interface, Bus Checkers, Vera Checker • Configuration2: TXRX BFM and test interface,no Vera Checker run_vcs –test <test_name> -cfg <config_name>

12. Project Configuration Files dirs.include dirs.define dirs.create TB VERILOG /tb/verilog/top /tb/verilog/top1 /tb/verilog/init TB VERA /tb/vera/checker/obj /tb/vera/tests /tb/vera/tests/include DESIGN /design/module1/rtl /design/module2/rtl /design/module3/rtl /design/module4/rtl /design/memories SYN /syn/constraints /syn/db /syn/reports CONFIGURATION TOP TB VERA /tb/vera/top /tb/vera/tests/include /tb/verilog/top TB VERILOG /tb/verilog/top COMMON /models/pci_bfm/ /models/rio_bfm/ pli/pci /pli/rio DESIGN /design/module1/rtl /design/module2/rtl CONFIGURATION TOP1 TB VERA /tb/vera/top1 /tb/vera/tests/include /tb/verilog/top1 ………….. CONFIGURATION TOP TESTS /tb/vera/tests RESULTS /tb/results VLOG_TOP /tb/verilog/top TB_INIT /tb/verilog/init VERA_TOP /tb/vera/top LIB /design/Lib CONFIGURATION TOP1 TESTS /tb/vera/tests RESULTS /tb/results VLOG_TOP /tb/verilog/top1 TB_INIT /tb/verilog/init VERA_TOP /tb/vera/top1 LIB /design/Lib

13. Test.vro Compiled Verilog (simv) run_vera –test test.vr run_vcs –test test.vr Compilation strategies: Single Test • Compile Vera Test, defined as an extern task called from Vera Top module • Compile Verilog Domain + Run Test • Incremental Test invocation: reuse simv from current or different test Precompiled Vera modules Open Vera Domain Verilog Domain run_vcs –test test.vr –incr …

14. Compile Verilog Domain and run generated simv file with each one of compiled test cases T1.vro T2.vro T3.vro Compiled Verilog (simv) run_vera –regress ex.vr run_vcs –regress ex.vr Compilation strategies: Regression • Compile All Vera Test Cases from Regression List: Precompiled Vera modules Open Vera Domain Verilog Domain

15. Test1 Test2 Test3 Compilation Strategies with Vera5.2 • Compile All Vera Test Cases from Regression List • Compile Verilog Domain (create simv file) • Run simv only once, dynamically loading and unloading each one of compiled Vera Test cases: Compiled Vera Top level Open Vera Domain Compiled Verilog (simv) Verilog Domain One simulation run for the whole regression!

16. OVA in Test Environment • Black-Box Verification approach is not always effective • Use Assertion monitors to track important internal design features • Checker uses Assertion monitors information to make final decision • Assertions “firing” statistics represents functional coverage of tests. DUT BFM BFM Mon Mon Design-specific assertions checker Reuseable Black Box Checker

17. Writing test cases in Vera Domain • Fast standalone compilation: compile test case only for syntax check • Fast debugging with VCS: use the same simv executable for consequent runs • Fast regressions: run the same simv with different Vera tests • Direct communication with Vera models: adaptive testing • Advanced Random verification support • Advanced file I/O features

18. Randomization functions in Vera • RL(low limit, high limit) – generates random integer within specified limits, giving more probability to low numbers • RN(low limit, high limit) – generates random integer within specified limits • RL(low limit, high limit) – generates random integer within specified limits, giving more probability to high numbers probability probability probability rl rn rh value value value low high low high low high for (i=0; i< 20; i=i+1) { randcase { 70: Send_Nwrite ( rl(0,2), 64, 0, 3, rn(0,2), 8*rh(1,31), 0 ); 30: Send_Conf_READ ( rl(0,2), 0, 16, 2, rn(0,2), 8*rh(1,31), 0 ); } }

19. Fast Initialization Support • Problem: register initialization takes too long time! • Solution: fast initialization for both Design and Checker • Initialization file should be the same for Verilog and Vera: Vera can parse text file; Verilog cannot. So, initialization file contains valid verilog task , which is included to verilog code compilation. At the same time, Vera Checker parses this file, extracting from file data and comments all needed info. run_vcs … -init init_file.v Used by Vera Checker task force_regs; begin force <hier_register_name> = <register_value>; //<logical address> …… end

20. Short regressions concept • Advances of VCS&Vera significantly reduced regression runtimes. • If so, why wait until the end of the week? Everybody can run 0.5 hr short regression! • Functional-oriented regressions: create different regressions targeted different functional blocks. • It does not replace, but complements main regression run, assuring constant stability of stable design DB Short regressions are used by verification engineers during updated files check

21. Short regressions concept (cont.) • By running short regressions on the stable design, we significantly increase it’s stability, verifying it constantly from different functional angles: Regression 3 Regression 4 Regression 2 Stable Design Regression 1 Regression 5

22. Project environment GUI: Test manager

23. Project environment GUI: Test manager

24. Project environment GUI: Test manager

25. Project environment GUI: Test manager

26. TCL for EDA web project • Applications: netman, pman, lcmon, etc • Productivity scripts for Verification, Synthesis, STA and DFT • Methodology Articles and Presentations • Current presentation & sample scripts will appear soon www.TCLforEDA.net