Home Download Documentation FAQ Report a Bug SourceForge page
Previous Contents Next

9. PLI 2.0 (vpi_) routines

9.1 Introduction

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, and vice-versa?).

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):
  • vpiParamAssign
  • vpiDefParam
  • vpiSpecParam
  • vpiUDPDefn
  • vpiModPath
  • vpiTaskCall/vpiFuncCall
  • vpiInitial
  • vpiAlways
  • vpiFrame
  • vpiContAssign
  • 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 called once.

9.4 Call Backs

The following callbacks are currently not supported:
  • cbStmt
  • cbDisable
  • cbStartOfSave
  • cbEndOfSave
  • cbStartOfReset
  • cbEndOfReset
  • cbStartOfRestart
  • cbEndOfRestart
  • cbEnterInteractive
  • cbExitInteractive
  • cbInteractiveScopeChange
  • cbForce
  • cbRelease
  • cpAssign
  • cbDeassign
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.

Previous Contents Next