Subject: Re: VPI requirements for System Verilog
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Sep 24 2002 - 06:19:44 PDT
Hi all,
Some comments about this from an user point of view, mostly to share some experiences. Probably this is useful for defining the next steps. I will share some of our experiences when integration C/C++ models in the following 5 simulators:
. Verilog-XL
. NC-Verilog
. VCS
. ModelSim
. this stuff should also run on the Cadence emulator running a very limited acc_ and tf_ function set
This work has been done more than two years ago, so don't expect me to state the exact tool versions; I will even not mention the actual simulator failing for obvious reasons. Many of the examples were written from memory, some of them might no longer be
the truth for todays versions, although I personally doubt this. This should not be fingerpointing; it should just show some of the problems that can arise. Hopefully we can prevent these kind of problems in one of the next releases of the standard.
Regards,
Michael
Stuart Sutherland wrote:
> > > 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?
I can not quote about VPI, but I know about some problem that hinder binary compatibillity in acc_ and even tf_ functions. I think it is an oversight of the standard not to require binary compatibility; something I would strongly request we do for
SystemVerilog 3.1.
One real world example for a problem that can arise here is the global variable acc_error_flag.
Sounds pretty harmless, isn't it? But one of the simulators I have mentioned redefines this global variable to be the return value of a function [with something like]:
#define acc_error_flag acc_return_error_flag()
The results are:
a) you can no longer assign a value to this variable [which might be considered bad style anyway]
b) the resulting library can not be linked into another simulator (because the acc_return_error_flag() function is missing)
c) a library linked on another simulator requires a global variable acc_error_flag and will therefore either not properly link or behave funny (when it comes towards accessing the variable); if I recall properly we actually had both cases coming up ...
It is properly worth to mention that this was only happening on the Windows platform and the simulator vendor stated that this function is needed due to linker semantics of .dll shared libraries...
> >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.
The biggest hurdle are often the huge amount of ambiguities the 1364 still contains. Yet another example: we had the need to initialize our internal C/C++ code. We had several PLI interface functions defining interfaces and a central one that should then
perform the initialization step [without knowing how many interfaces have been defined]. The most obvious thing to do so is to
. define the interface definition function as CheckTF functions only
. define the central intialization function to be a MiscTF function that performs the initialization in the end_of_compile step
It took us more than one day to find out that one of our simulators issued a reason_synch call before the first end_of_compile step. When we came to a case where the CallTF call was earlier than the MiscTF call (on another simulator) we were warned already
...
Actually nothing in the 1364 defines what is possible and what are illegal orders of execution here...
> 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.
Some big problem we are running into were incompatibilities between some simulators and the standard:
(1)
. IEEE 1364 states that 'real' variables are real registers.
. It is stated nowwhere, but fact is that all simulators can only modify register values throught the PLI; but it is not possible to modify real registers ...
. So when it comes to transfer real values between Verilog and C/C++ you just have a one way street ... There is a workaround for this, but it is more than ugly
. Also, since we have to provide the real number in another format (64 bit reg), we end up in some dependency on the representation of the actual value of a real, which resulted in rather interesting bugs when it came towards the differences of little vs.
big endian machines (Solaris vs. Linux).
(2)
. VCL functions can only be executed on scalar variables. As such it is imperative to define the variables that should be sensed with VCL as scalar. Unfortunately one of our simulators does not provide this information at all (saying the net is not
scalar). If you then code a check to assert this (and don't leave the user alone with a series of useless error message until VCL crashes), you will prohibit the usage of this simulator ...
(3)
. Abortion is handled extremely different. Our code to cleanup VCL registrations crashes usually when we need to abort, because it was impossible to find an execution order that works on all simulators. Although, compared to the other problems, I am
tempted to say that this is merely a feature, not a problem...
-- Quote of the day: "Better to remain silent and be thought a fool than to speak out and remove all doubt." [Abraham Lincoln (1809-1865)]NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( ) when marked, please note: This e-mail and any attachments are confidential and Motorola reserves all rights of privilege in respect thereof. It is intended for the use by the addressee only. Please delete it from your system, if you are not the intended recipient. Any use, disclosure, or copying of the included information is unauthorised. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, ASA Methodology | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
This archive was generated by hypermail 2b28 : Tue Sep 24 2002 - 06:20:17 PDT