Subject: RE: [sv-cc] DPI context - setting/preserving&resetting a scope
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Mar 13 2003 - 22:16:33 PST
Team,
Some discussion below on interleaved DPI functions...
> -----Original Message-----
> From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
>
>
> Hello Andrzej,
>
> thanks a lot for bringing this up. My comments are interspersed.
>
> -Michael
>
> Andrzej Litwiniuk wrote:
>
> > Joao,
> >
> > Consider the folowing sequence of DPI calls (interleaved context and
> > non-context functions):
> > SV --> context_cfunc1 --> SV --> non_context_cfunc2 --> SV
> >
> > The scope set at the call of context_cfunc1 is preserved
> and that way
> > still avaialble while non_context_cfunc2 is executed; we don't want
> > to do anything with a scope (overhead!) for non-context
> calls, do we?
>
> I don't think it makes sense to dive into such details. I
> would simply stay with banning calling SV functions from non-context
> functions.
>
> Calling SV from a non-context function is considered illegal
> and the result is therefore undefined. This should be also true, when
> the context might be set by other means. Make it simple for
> users: if you call SV from a non-context function, you do something
> illegal - that's it.
DOUG: I don't like this restriction, Michael.
a) It's a detail that would be hard for users to figure out
without carefully scruitinizing the LRM.
b) In John's scenarios, it is quite imaginable that an SV export
function will be called from non-context c functions.
(Most likely PLI/VPI functions or some other kind of C
code integration such as SystemC models linked with a
SystemVerilog simulator
I think the rule to handle Andrzej's sequence is pretty simple:
Context callees inherit default scope (i.e. context) from callers.
A context callee is defined to be any SV export function, or any
context external function.
For non-context external functions there is no default scope.
Thus the non_context_cfunc2 would have NO default scope.
Any queries regarding the current scope would return NULL handles.
This makes sense as per the definition of non-context external funcs.
However, why should we restrict non_context_cfunc2 from manually
setting a scope with svSetScope(), and then calling an export function?
>
> > I have no problem with such a scenario; I don't want to prohibit it.
> > It simply makes the description of semantics more complicated.
> > Because what's weird in this scenario, is that non-context function
> > called from SV may successfully call an exported SV function.
> > Of course, this could be viewed in a different way, too: a
> context function
> > is allowed to call SV also indirectly, regardless whether a
> call chain goes
> > thru SV functions and non-context functions, or not:
> > SV --> context_cfunc1 --> ....... --> SV
> > [transparent call chain]
>
> Of course this is just true, if a context function is called
> at an earlier point in time. You can not control this, another user
> might instantiate the corresponding SV function and call the
> DPI function without a context set. This would be a real problem and
> hard to identify. At the end, it would compromise reuse. Not nice.
DOUG: I think I agree with Michael. From what I understand of Andrzej's
proposal here, it seems like he is proposing sending context information
down a call chain, even through non-context functions, until a context
function is hit. At that time the "inherited" context info would be
default scope. If that is the case, I think that is too complex.
The simple rule I defined above should be sufficient for any practical
modeling scenario I can think of.
Any disagreements?
Regards,
Doug
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 22:17:24 PST