Subject: Re: VPI requirements for System Verilog
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Thu Sep 26 2002 - 15:30:01 PDT
Michael,
The experiences you have shared are very valuable. I agree with anything
you have shared. The curiosity in my really wants to know which products
had which problems, but you are probably right in not sharing that.
I am involved with both the IEEE 1364 standards group, specifically as
co-chair of the PLI task force, and with the Accellera SystemVerilog
standards committee. So I'd like to give my opinion on these issues from
both perspective.
On the SystemVerilog side, it is my opinion, all the things you indicated
fall squarely in the IEEE 1364 committee's lap. The SystemVerilog
committees have the charter to define extensions to 1364, not to fix
problems in the IEEE standard. Nor can Accellera force the IEEE 1364 to
require binary compatibility for the entire PLI. That would be more than
just extending what is already in the 1364 standard. But if/when the
SystemVerilog CC committee begins to define enhancements to the 1364 PLI
libraries, great care should be taken not to repeat these types of errors
and ambiguities.
From my IEEE perspective, we on the PLI task force are not ignorant of
many of these issues. We have tried hard to clarify ambiguities where we
can, and I think you will see a tremendous improvement in that area between
the 1995 and 2001 standards. In many cases, however our hands were tied by
several factors.
First was--and as far as I know still is--a strong mandate within the 1364
working group to not break existing applications. Rare exceptions to that
mandate have been made, such as adding new keywords, but in general, we are
bound by the rule that if a Verilog model or PLI application is working on
some commercial product, and is within the current wording of the
standard--we cannot change the standard in a way that would make that model
or application or product no longer work. This policy has been a
particular challenge within the PLI standard. As you noted, several major
products have taken very different approaches in some areas of PLI
implementation. If the 1364 committee were to now say that only one of
those approaches is correct, it would break applications that were based on
the other products. Hence, in many, many of our PLI task force meetings,
we had to deliberately leave a certain level of "freedom" in how the PLI
would be implemented.
A second compelling argument for this "freedom" in the standard is that the
1364 standard should not over-constrain how things are implemented, and
thus kill opportunities for EDA vendors to distinguish their products by
how efficient their implementations are. Event scheduling, and other
aspects of simulation need to have a certain amount of freedom (ambiguity)
in order to encourage vital competition in the EDA industry.
The 1364 PLI task force was also inhibited somewhat due to the nature of
the document that we had to start with. That document was originally the
Gateway Design Automation PLI user's manual. It was not written from the
perspective of what is needed to implement the PLI, it was written to
provide users of one specific product, Verilog-XL, insights and examples of
how to write PLI applications for that one product. It has not been easy
to turn that sketchy user's guide into something that approaches an
implementation standard. I wish the IEEE would put forth the money
necessary to scrap the user's guide approach and totally rewrite the entire
1364 LRM, but that has yet to happen.
The final reason for the current state of the PLI, is a past history of a
lack of interest by some of the major simulator companies to invest in
helping to define the standard. For almost the entire time the 1364-1995
and 1364-2001 PLI sections were being defined, only one major simulator
vendor, Cadence, had representatives on the PLI task force. Cadence was
very actively involved in defining the PLI for 1364-1995 and 2001, but were
not always willing to remove ambiguities from the PLI that would prevent
them from distinguishing their two simulators. Viewlogic and then Synopsys
never participated on the PLI task force. Fortunately, we did have
representation from someone who was very familiar with how the VCS PLI was
implemented. He could answer questions on VCS PLI behavior, but had no
influence on the changing the product. For most of the process of
generating the 1364-2001 standard, Model Technology took the position that
they would just implement what was defined, but would not participate in
the definition. In the very last few months that the 1364-2001 standard
was being created, Model Tech did get involved on the PLI task force, and
provided very valuable feedback on ambiguities in all three libraries. The
PLI task force was able to squeeze in dozens of clarifications based on
that feedback before the standard went to ballot.
In the past year, I have seen a very definite change in the attitudes of
these major EDA vendors. I am confident that when the 1364 PLI task force
begins work on Verilog-200x, all of the major simulator companies--and
hopefully some of the smaller ones--will invest the personnel and time
required to do things right.
Please don't take the explanations (excuses) above as an endorsement from
me. I do not agree with the policy of being ambiguous so that old
applications won't break. I understand the reasoning behind it, but don't
agree with it. As a user, I feel the 1364 standard should not allow the
freedoms that it does in a number of areas, both in the PLI and in the
HDL. To do this in the PLI, however, EDA vendors need to actively
participate in the defining of the PLI standard, and be committed to
changing their products based on the decisions made. Users must also be
willing to accept that if products change to all implement the PLI the same
way, they may have to make changes to existing PLI applications. Frankly,
I fear users are willing to "say" they want things like consistent PLI
behavior in all products and binary compatibility, but I'm not so sure that
all users are willing to pay the cost of updating existing applications in
order to achieve what they say they want.
Stu
At 06:19 AM 9/24/2002, Michael Rohleder wrote:
>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 \ \_/ ////)
> \ /_______________________________________________\ /
> \ _/ \_ /
> / / \ \
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 : Thu Sep 26 2002 - 15:31:42 PDT