Subject: Re: [sv-cc] DirectC C Layer - revised - 'context' functions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Feb 06 2003 - 09:41:50 PST
> > For functions not specified as 'context' the effects of calling PLI or VPI
> > functions or SV functions may be, depending on a function, unpredictable and
> > such calls may crash if the callee requires the context that has not been set
> > properly.
>
> KEVIN:
> I still see no reason for this. If I create a (say) SystemC class instance, I
> should be able to call methods of that class without the context overhead if I
> want, and if there are PLI/VPI handles stored in the class I should be able to
> call functions using them.
Presumably SV compiler will not create data objects in the form of SystemC class
instances. Neither it will translate on the fly the actual arguments of external
function calls from their native representation in SV simulator to SystemC class
instances.
Some of PLI/VPI functions require some global variables set, e.g. current
instance or current task.
Such variables are not always kept up-to-date, rather, they are updated
on demand, specifically, at $task calls.
We don't want such overhead for the all calls of external functions.
So we decided to mark the functions that may indirectly require those variables
as 'context'.
Other calls will not be instrumented and therefore the correctness of the global
variables (current instance or current task) cannot be guaranteed.
You may keep a VPI handle in your priviate SystemC class instance, but there
is no guarantee that if any PLI/VPI function inquires about, say, current
instance, it will get the correct value.
There is something more to this.
We agreed (voted for) that an external function is assumed not to access any
data objects from SV other then its actual arguments, unless it's marked
as 'context'. The rationale was that an external function call should not block
the optimizations. Only the actual arguments may be affected (read/written).
Therefore a call of non-'context' will not be a barrier for optimiziations.
'Context' function, by calling PLI/VPI may access (read/write) any SV data
objects and therefore a call to 'context' function will be considered as
a barrier for optimiziations.
> KEVIN:
> If you want asymmetric behavior I think you should specify which VPI/PLI calls
> will behave differently so that "may crash" is not an option for implementors.
Ideally, a list of all "safe" functions would be presented.
It's very hard to collect such enumeration. So I decided to err on the safer side.
Besides, very likely it will be more than a single list.
Some functions require the context of a call, other functions may access or
modify data.
Andrzej
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 09:42:47 PST