Subject: RE: VPI requirements for System Verilog
From: Michael McNamara (mac@verisity.com)
Date: Tue Sep 10 2002 - 16:59:28 PDT
Francoise Martinolle writes:
> Here are the long awaited requirements for VPI SV.
> Be aware that I will be on vacation starting 9/12 until 9/23 and will not
> be able to respond to any questions or comments during that time
>
> R1: Basic requirements
> PLI 1.0 should not be enhanced. PLI 1.0 was not enhanced to support
> Verilog 2001. VPI which is Object-Oriented is more easily
> extensible and should be enhanced to support SV. VPI has already
> been enhanced to support Verilog 2001. VPI SV should be defined as
> ANSI-C API
>
> R2: Functional requirements
> VPI information model should be enhanced to support the new
> systemVerilog constructs. VPI access and modification of values
> should be enhanced to support new value data types and new object
> types in SV. VPI should be enhanced to support simulation
> interaction and control of systemVerilog simulation
>
> R3: compatibility
> Should we ensure backward compatibility? basically this would mean
> that no existing VPI function prototype or data type will be
> changed and that no type/method/property will disappear with VPI
> SV. If a data type or function needs to be enhanced to support SV,
> then this would require to create a new data type or function to
> support SV. Should old VPI code continue to work on SV? Should
> new VPI work on Verilog?
Tough issue for this are the vpi_iterate(), vpi_scan(), and
vpi_handle() family of functions. A strict interpretation of your R3
is that these existing functions should silently ignore the new
constructs; and that we must provide new functions that would support
the old and new functions. This seems non useful.
In my opinion, tt would be more useful for the existing iterators to
indeed return handles to the new objects, and for new vpiTypes to be
defined, and returned, and hence old code that is ignorant of the new
vpiTypes will either fall off the user's case statement, or get into
the users default case, and be appropriately error handled.
Again, we should set as our goal creating a useful programming
language, in which the seams of stitching are as invisible as
possible, while also maintaining backwards compatibility.
My fear of R3 is that we will end up with a fourth API: tf, acc, vpi,
and svapi...
> R4: scope of VPI enhancements:
> Currently VPI is only aimed at providing access to the SV core
> design language features; what do we do if testing and assertion
> language features are added to the SV language. Should VPI also
> provide access to the testing and assertion language constructs?
> and how? One may only be interested in the design model and not in
> the testing or assertions. Should we provide different methods to
> retrieve either of these elements?
It is my opinion that certainly at the date where we reasonable expect
users to use this language, there must be API access to every
construct in the design.
> R5: Foreign models development and integration
> VPI SV should allow the registration of foreign models written in C
> or C++ user-defined foreign functions should be extended to return
> the new data types of SystemVerilog. VPI-SV should allow easier
> integration of foreign models than the VPI registration mechanism
> (aka DirectC or through attributes)
>
> R6: abstracted data
> VPI should not make any assumption about the underlined data
> implementation in SV
>
> R7: concurrency
> VPI should allow multiple concurrent VPI applications to read and
> write to the simulation data
>
> R8: Binary or source portability of VPI SV applications across different SV
> simulators
>
> In the past VPI applications written for Verilog 1364 are only
> source portable across various simulators and need to be recompiled
> for each simulator vendor. However many applications can be written
> to be also binary compatible and users have taken the advantage of
> it.
If it is indeed the case that VPI applications are not binary
compatible, than I am very disappointed.
Q1: Is there an oversight, or worse, a requirement in the definition
of the VPI in 1364-1995 and/or 1364-2001 that mandates binary
incompatibility?
The VPI was invented after I ceased to be running the engineering of
VCS, and hence I had no direct input into the development of VCS's VPI
support. I do know that it was some time after 1364-1995 came out
before VCS supported the VPI.
Q2: Do people have direct examples of the fact that one cannot compile
a VPI application once, and link it in to any 1364-1995 simulator?
I do know that my engineering team at SureFire and Verisity release a
single verilog library (sv_pli.a) for use with any Verilog simulator,
with our SureCov product. However it is quite liekly that we did not
use any VPI calls in this library, as support for VPI in all
simulators could not be assumed; while it is the case that every
simulator does support tf & acc routines.
>
> Francoise
>
--
_
// Michael McNamara, Sr VP Technology <mac@verisity.com>
_ // 650-934-6888, 408-930-6875 Cell <http://www.verisity.com>
\\ // ___ ____ _ ___ _ ___ _ _ ___ ___ __ _ _ _ _
\\// |_ |___)|(___ |' | ` \ / | \ |_ (__ | / _ |\ |
\/ |__ | \ | ___)| | | |__/ |__ __)| \_/ | \|
This archive was generated by hypermail 2b28 : Tue Sep 10 2002 - 16:59:53 PDT