Frequently Asked Questions
- Does vcomp do incremental compilation?
- I tried to use $dumpvars and it told me 'Unknown user or system task'
- My vcomp binaries are enormous!
- Why do you use static libraries rather than shared ones?
No, not yet, the compiler is already pretty fast and makes some use of SMP on SMP
capable servers for added speed
$dumpvars, $dumpfile, $dumpoff, $dumpon, $dumpall, $dumplimit and $dumpflush are all
implemented and part of the standard runtime, however in order to access them you need
to add '-P /usr/local/lib/vcomp/vcd.tab' to the vcomp command line.
We recommend you use these tasks (and other similar PLI routines that allow
arbitrary signal tracing) with caution. Because, once one of them has been
instantiated, they result in many compiler options being disabled simulation
efficiency can be grossly impacted. This is because the compiler cannot know
whether they may wish to access any or all variables in your simulation and as a
result must be prepared to schedule events on all variables - not only does
this slow down simulation but it results in the disabling of low level
code scheduling and other more common high-level language optimization
techniques across individual statements.
The best way to use them is to `ifdef them out until you need them, then recompile
them back in when you want to use them. The down side of this is that this
may result in reordering of 0-time event races you may be trying to debug.
Most of that space is the run-time version of the symbol table - it
is unused unless you use the acc_* routines for traversing the hierarchy
Because some of the well used paths in the runtime scheduler are of the order of 10s of instructions long
shared libraries would make some simulations run 10-40% slower