Transcript SNUG 2002

Efficient Verification Environment
with Synopsys Vera & VCS
Alexander Gnusin
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
Problems with previous environment
• Difficulties to preserve constant stability:
Regression preparation
• User code variations:
User1
RCS
User2
User3
Problems with previous
environment(cont)
• Fear to update “stable” code in user directory:
Update
d
Code
Relelas
e
• Inherent instability of latest RCS design
versions:
Anybody
Modifications
Modifications
Any Time
RCS database
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!
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
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!
RCS DB
RCS
Filtering
Stable DB
User1DB
User2 DB User3 DB
Users “Delta” files
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
Common
Scripts,
Documents
, Models,
PLI etc
Versions
Users
Shared
development
space
Users
shadowing
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
Top1
Top2
Verilog Modules Library
Top3
Verilog
Domain
Solution for Integration project
OpenVera
Domain
Core1
Top
Core2
•Core1, Core2: core-level
configurations
•Top : top-level configuration
Vera Modules Library
Core1
Top
Verilog Modules Library
Verilog
Domain
Core2
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
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>
All possible configurations
General configuration
Useful configurations
“Defines” area
Project Configuration Files
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
dirs.include
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
…………..
dirs.define
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
RESULTS
VLOG_TOP
TB_INIT
VERA_TOP
LIB
/tb/vera/tests
/tb/results
/tb/verilog/top1
/tb/verilog/init
/tb/vera/top1
/design/Lib
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
Test.
vro
run_vera –test test.vr
run_vcs –test test.vr
run_vcs –test test.vr –incr …
Precompile
d
Vera
modules
Compiled
Verilog
(simv)
Open Vera
Domain
Verilog
Domain
Compilation strategies: Regression
• Compile All Vera Test Cases from Regression List:
• Compile Verilog Domain and run generated simv file with each
one of compiled test cases
T1.vr
o
T2.vr
o
T3.vr
o
run_vera –regress ex.vr
run_vcs –regress ex.vr
Precompile
d
Vera
modules
Open Vera
Domain
Compiled
Verilog
(simv)
Verilog
Domain
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:
Test
1
Test
2
Test
3
Compiled
Vera Top
level
Compiled
Verilog
(simv)
Open Vera
Domain
Verilog
Domain
One simulation run for the whole regression!
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
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
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
rl
rn
value
low
probability
high
rh
value
low
high
value
low
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 );
}
}
high
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>
……
end
=
<register_value>;
//<logical address>
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
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 2
Regression 3
Regression 1
Regression 4
Regression 5
Stable
Design
Project environment GUI: Test manager
Project environment GUI: Test manager
Project environment GUI: Test manager
Project environment GUI: Test manager
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