Subject: RE: VPI requirements for System Verilog
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Sep 10 2002 - 19:50:09 PDT
A very well thought out requirements analysis! I've inserted my 2 cents
worth below.
Stu
At 04:59 PM 9/10/2002, Michael McNamara wrote:
>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
> >
I agree in regards to not enhancing the ACC library. I'd love to see the
1364 standards group deprecate the ACC library (but leave it in the LRM as
informative text). The VPI library replaces the ACC, in a substantially
better way. The TF library access to memory arrays should also be
deprecated, as the VPI provides much cleaner and portable access.
The TF library is still useful, however, as its limited and predictable
access to the simulation data structure allows simulation compilers to do
much more aggressive optimizations.
In retrospect, I think it was an error not to have made some minor
extensions to the TF library for Verilog-2001. The TF library should have
defined what would happen when new constructs were used as task/function
arguments, such as signed reg types or multidimensional
arrays. SystemVerilog should define how the TF library will handle the
many new objects that can be legal task/function arguments. It should not
be difficult to define. The definition may well be "illegal" for some
objects, such as multidimensional arrays.
> > 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...
I agree with Mac. The VPI should take the same approach as
Verilog-2001. New type constants and methods were added to support
anything new in Verilog-2001, but the old 1995 constants and methods still
worked. There were a couple of exceptions to that, but we tried very hard
to maintain full backward compatibility. The most glaring exception was
trying to add support for multidimensional arrays while maintaining
backward compatibility with the old 1995 access methods. We ended up
having to keep the old methods and types for memory arrays, and add whole
new methods and types for multidimensional arrays (which also access memory
arrays). SystemVerilog's vastly extended array types may prove to be a
challenge to implement with the current Verilog-2001 access methods.
> > 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.
Again, the Verilog-2001 general philosophy should be maintained. If an
object exists in the "instantiated" simulation data structure, then the VPI
needs to be able to access the object and its properties.
> > 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)
> >
In my opinion, the DirectC/Cblend like integration of C functions with
SystemVerilog is extremely important. It will both greatly simplify the
work user's must do to integrate foreign models or just access some
functionality from a C library. On the other hand, there will likely
always be capabilities of the VPI can do that will be desirable to IP
providers and those who write foreign models. Access to the event queue is
one example. Ultimately, both a direct interface and a VPI interface will
be needed for foreign models.
> > R6: abstracted data
> > VPI should not make any assumption about the underlined data
> > implementation in SV
> >
Agreed.
> > R7: concurrency
> > VPI should allow multiple concurrent VPI applications to read and
> > write to the simulation data
> >
Agreed. The same rules as in the HDL for wired nets and shared variables
should be followed.
> > 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.
The primary incompatibility I've seen is the many doors that the 1364
standard leaves open in both the HDL and the PLI. EDA vendors can and do
extend the language, and add proprietary VPI types and access methods to
support those extensions. Obviously, any code that uses non-standard
constants or functions is not going to be binary compatible across
simulators.
In addition, there are still plenty of ambiguities in how the HDL code will
look in a simulation data structure. I think the VPI does a pretty good
job of providing a compatible layer between PLI applications and simulation
data structures--certainly much better than the TF and ACC libraries--but
there is still the possibility that some small difference in interpreting
the 1364 standard will result in non-compatible binary code. I suppose
POSIX and every other standard suffers from that possibility, as well. I
hope as EDA vendors run into interpretation issues, they will share them
with the 1364 standards group so that the standard can improve.
> >
> > Francoise
> >
>
>--
> _
> // Michael McNamara, Sr VP Technology <mac@verisity.com>
> _ // 650-934-6888, 408-930-6875 Cell <http://www.verisity.com>
> \\ // ___ ____ _ ___ _ ___ _ _ ___ ___ __ _ _ _ _
> \\// |_ |___)|(___ |' | ` \ / | \ |_ (__ | / _ |\ |
> \/ |__ | \ | ___)| | | |__/ |__ __)| \_/ | \|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Tue Sep 10 2002 - 19:53:21 PDT