( ESNUG 380 Item 11 ) ------------------------------------------- [10/25/01]
Subject: ( ESNUG 378 #12 ) VCS Flags And Their Impact On Simulation Speed
> After being away from using it for four years, the VCS documentation
> hasn't changed much if at all. Finding out all of the new switches
> added or the performance adds to VCS isn't possible: the shipped
> docs still have Chronologic plastered all over them and there is a
> serious lack of any documentation available on the Solvnet site. (I
> had to resort to going through my SNUG handouts of previous years to
> find out about the latest and great issues with VCS).
>
> - Gregg Lahti
> Corrent Corp Tempe, AZ
From: Mark Warren <mwarren@synopsys.com>
Hi, John,
Gregg Lahti's letter got me concerned that many VCS customers might not be
running VCS as fast as they could. VCS does not have nearly as many switches
as DC, but it is very important to understand the affect of switches on VCS'
performance. Please post this reply to show your readers a quick overview
about maximizing VCS performance.
Over the years, VCS has added many optimizations aimed at increasing the
performance of all types of Verilog code. At compile-time, VCS must make
most decisions about how to perform these optimizations. In default behavior
(no switches), VCS will perform some optimizations, but it's important to
understand that some switches can turn on much more aggressive optimizations,
while other switches turn on debugging or PLI visibility (which hinders VCS
speed optimizations.) These differences can often make a big difference
(3X+) to the performance that you see!
VCS flags for better performance:
+rad performs aggressive optimization for RTL or (non-timing) gate
level. A *lot* of effort have gone into these Radiant optimizations.
This is the single best way to get the largest speedups in VCS.
+nospecify ignore path delays and timing checks for a functional
gate sim.
+notiminchecks just ignore timing checks
+timopt perform aggressive timing optimizations (for SDF gate sims)
-Mupdate use incremental compile to only recompile modules that
functionally changed
+nocelldefinepli+2 do not dump or use PLI access from within
library cells
+vcsd use more efficient Direct Kernel Interface for VirSim dumping
+2state convert entire design (except certain constructs) to 2 states
for more speed/capacity
VCS debug/PLI flags that hurt speed/memory performance:
+cli globally turn on interactive debug
-line allow line stepping in the interactive debugger
+acc obsolete flag to allow global PLI access
-I obsolete flag for interactive GUI debug
-RI compile and run interactive debug with VirSim GUI
-PP allow virSim VCD+ binary dumping for post-processing debug
-X* version specific flags to work around specific bugs
-P pli.tab which contains acc=rw,cbk:* globally turns on PLI access
Other tips/warnings on VCS performance:
Use the latest release of VCS. VCS6.0 was released January 2001 and it
contains many gate-level and RTL performance updates.
Occasionally using aggressive optimizations like +rad will expose race
conditions which cause simulation mismatches. Race conditions should be
avoided as much as possible. VCS comes with both dynamic and static race
utilities (+race and +race=all), plus Synopsys offers LEDA linting and rules
checkers that can help find the ambiguous coding styles that cause races.
If you don't want to use LEDA, use VeriLint, or HDLlint, SureCov, or any of
a dozen other commercial linters. The important thing is to detect and
remove those race conditions! Often +rad can give a 3X speedup for many
designs, so it is worth the effort to debug races in order to utilize +rad
for all your regressions.
VCS also comes with a profiler (+prof) that should be used periodically to
see if any blocks of your design are hogging up too much CPU time. The
output of the profiler is easy to read.
- Mark Warren
Synopsys, Inc. Cupertino, CA
|
|
