9. PLI 2.0 (vpi_) routines
vcomp currently implements a runtime subset of the PLI 2.0 ("VPI") routines.
This means that we provide the ability to access variables, their values and attributes,
but no access to structures that represent the compile-time (ie source) Verilog structures.
This is for a number of reasons - in particular we wanted to get something usefull out as
quickly as possible since the older acc_ routines do not provide for access to a number
of Verilog 2000 structures, also
we are worried about the implications VPI routines might have
for the security of protected IP (ie protected libraries) and wanted to make sure
we get that correct - even in this implementation the places at protected module
boundaries where access to structures stop has (we think) been implemented
conservatively - we are very interested in feedback as to whether or not this
works the way people expect (what can't you discover that you think you should,
9.2 What's missing?
As mentioned above we don't provide access to compile time structures, in essence the
following objects are not supported (as well as the objects derived from them):
- net drivers and load (because some of these are vpiContAssign)
9.3 Connecting VPI routines
Because vcomp is a compiler rather an interpreter we use a slightly different mechanism
for hooking up VPI callback routines - it is based on an extension of the PLI 1.0
interface mechanisms we describe here.
All routines intended to be called as PLI routines (1.0 or 2.0) must be declared
in a -P file - functions must be given a fixed size (and as a result PLI2.0 sizetf
routines are not called)
There are 3 ways you can use this interface to call PLI 2.0 routines:
- Declare a routine in a PLI -P file as you would for a PLI 1.0 routine (with a
call=<routine> directive) and then call
PLI 2.0 routines from it. This mechanism is recomend for people
who want a quick and dirty way to get things running, such a
call will be called PLI1.0-style with reason and data parameters.
- Declare a routine in a PLI -P file, instead of the normal 'misc=', 'call=' routine
declarations - use 'vpi=<routine>' if you do this then the <routine>
will be included in the vlog_startup_routines array maintained by the compiler
to be called before the very beginning of simulation - NOTE this routine will ONLY be
included in the array if one or more PLI tasks declared that reference that <routine>
are actually included in modules that are part of the compiled simulation (see below
how to force this). Even if multiple routines reference <routine> it will
only be called once. This mechanism is recomended for people who are building
portable PLI 2.0 routines. Make sure you include the appropriate 'acc' flags
at the end of the line (see the description here
by default the compiler generates more efficient code but doesn't perform the requisite
bookkeeping to perform all PLI flags - adding these flags causes the compiler to
generate the support you need when you need it - for best results only ask for
what you need.
- If you add a line in a PLI file containing only 'vpi=<routine>' then this
<routine> will be unconditionally forced into to the vlog_startup_routines
and called before the very beginning of simulation - even if the <routine>
is included multiple times from routine declaration (above) it will only be
9.4 Call Backs
The following callbacks are currently not supported:
Notes about implemented callbacks:
- cbSignal - you can hook all signals that can be caught however this may not be wise
take great care what you do in this area.
Also the vcomp runtime uses SIGALRM/SIGVTALRM for the -rtimeout/-timeout flags
resp. (-timeout is the default). Finally in order to synchronize the delivery
of pending signals (and allow you to make other PLI calls safely) signals
will be delivered at a safe event boundary - if your simulation is stuck
in an eventless loop (without @ or # event waits) then the signal may not be
caught. The runtime will also catch SIGINT and try to quit cleanly (flushing
output buffers etc) if you replace SIGINT you may not be able to cleanly
escape from tight simulation loops through ^C without losing output data.
- cbPLIError - only PLI 2.0 errors are reported this way (PLI 1.0 errors are
reported through cbError) - this way vpi_chk_error will always be able to
be called to report the latest logged error that caused the callback
9.5 Misc Notes
The '-Dv' runtime flag forces ALL vpi internal messages to be printed out.