Subject: Re: issue 1.4: No clear relationship to other APIs
From: Michael Rohleder (Michael.Rohleder@motorola.com)
Date: Thu Nov 07 2002 - 06:42:36 PST
Let me try to reiterate what I said:
* I want not to prohibit PLI/VPI calls in DirectC functions.
* I want a method to distinguish DirectC functions that
a) do only read/write their arguments and call no function of another API [no side effects]
b) do call functions of another API, but do not change the simulator state (read-only)
c) do call functions of another API, and do change the simulator state
This distinction is meant to be a hint for the tool vendors, which can be used to control their optimizations
* It might be useful to define a 'synchronization' function that can be used in case b) and c) to bring the other API's into a
known state. I am not religous here, but this sounds good to me.
* It could be in the discretion of the of the tool vendor to
- validate the above hints (it should be clearly stated in the standard that a wrong hint can lead to unpredictable results)
- perform corresponding optimizations
I am sorry, but I don't see how this makes the interface more heavyweight or complicated. It just tries to prevent some problems
upfront.
Some more comments are interspersed.
Regards,
Michael
Andrzej Litwiniuk wrote:
> Francoise wrote:
>
> > It is technically possible to call VPI and PLI from inside
> > a directC function.
Yes.
> > It is also technically possible to prevent such VPI and PLI calls to have
> > any effect. The SV engine can remember that it is calling a directC function
> > can make the VPI nd PLI functions have no efffect other than may be giving a
> > warning message.
Yes. But this would restrict people from using VPI and PLI functions in general in DirectC. I think I heard that some people
(including me) think it would not be good to enforce such a restriction.
> Many of PLI functions refer to the current instance or current task/function.
> In order for them to work, compiler must set some variables before
> the call. Roughly speaking, all $pli calls are instrumented somehow.
> Similar instrumentation would be needed for DirectC calls if PLI/VPI
> could be safely called from inside of a C function, otherwise PLI function
> would simply crash.
I have had the pleasure to maintain several PLI functions and have even written a good bunch on my own (Never did VPI, because it is
not supported by all vendors of simulators we are using). A good portion of them were either using parameters that were stored
globally or in structures refered by global pointers for various reasons. I can always use a tf_i... function instead of tf_... as
an example. There are also very common PLI functions that do not need this parameters (io_printf()...).
> Yes, "SV engine can remember that it is calling a directC function"
> but this will involve some overhead, perhaps small, yet an overhead
> totally undue for simple C calls.
Correct. I would like to have both. Permit PLI/VPI functions, but don't pay an extra fee for this, because optimization is not
possible for the functions where this is not been done.
> > While looking back at the original goals of the directC interface, I read
> > that we want to design a simple, easy to use, fast performance, limited
> > functionality C interface which directly access simulation objects.
Please explain, which of the above goals
- speaks against permitting PLI/VPI calls
- having some notation that hints the tools about what is going on
> > Francoise
>
> Exactly!
> Either generality or simplicity with performance, I'm afraid.
>
> Adding more and more capabilities to DirectC calls seem to defy
> the original requirements and brings DirectC dangerously close to PLI.
> So, why not to stick with PLI for more sophistaicated needs and
> spare (leave intact!) the simple DirectC for simple needs?
>
> Thanks,
> Andrzej
This archive was generated by hypermail 2b28 : Thu Nov 07 2002 - 06:43:12 PST