Subject: RE: [sv-cc] open issue: exported function = virtual function?
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 26 2003 - 12:08:03 PST
Andrzej,
Very interesting line of reasoning here.
In general I support this notion.
There should be one restriction that I don't
think was clearly mentioned at the right place.
We should discuss this in our 10:00am meeting tomorrow.
BTW, if Ghassan can't get the conference scheduled,
we can use my Raindance conference id, which is available
24/7 for spontaneous teleconference meetings.
Please see below for my comment.
Regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Wednesday, March 26, 2003 11:06 AM
> To: sv-cc@server.eda.org
> Subject: [sv-cc] open issue: exported function = virtual function?
>
>
> Team,
>
> While revising the SV layer of DPI and nit-picking, I noticed that
> some restrictions for exported functions seemed to be missing.
>
> For imported functions the same "type signature" is required
> and most likely
> something like this is needed for exported functions.
>
> In "1.3 Global name space ..." we have:
> "Each exported function must have a unique name". (Wrote it myself:-)
>
> Does it mean 1-1 mapping? "For each cname of an exported
> function there must be
> exactly one source code definition of the exported function"?
>
> This led to a more fundamental issue: do we want the exported
> functions
> to be virtual functions?
>
> Initially our intent was (and perhaps still is) to have =one=
> SV function
> per exported cname. In other words, there will be one source
> code definition
> (SV implementation) of each exported function.
>
> Conceptually such a function will have its own declaration in
> every instance
> of a module that contains the function's definition (just like in any
> block-structure programming language).
> In the simple scenarios all 'instances' of a function
> declaration will share
> the same executable code (and, of course, the same source code).
> Hence the C programmer will know where to look for a SV source code of
> an exported function called from C.
>
> The same function executed with different instances will
> access different data,
> what is our primary goal, but usually the same code will be executed.
>
> It may happen, however, that the same source code definition
> of a function
> will give rise to several specialized versions (clones) of the code.
> It may happen because of the reasons transparent to the
> users, like compiler
> optimizations, or because of more visible factors, like
> parameters, defparams,
> type parameters.
> This is where the restriction "unique signature per exported
> cname" comes
> to the picture. (It somehow didn't make into LRM).
>
> Presumably the sole intent of such restriction "one signature
> per cname"
> is the correctness. For C code only the signature of the
> exported function
> matters. Same C code must be used for a call of an exported functions,
> regardless of the instance, and consequently, regardless of
> the eventual
> SV code to be executed. It is SV implementation's job to identify the
> right code for a given instance.
>
> Susprisingly (for me, Joao wasn't surprised at all!) the restriction
> "one signature per cname" does =not= mean "one source code per cname".
> Actually, it doesn't matter what was the source code, as long
> as the signature
> matches. SV implementation will have to identify the right
> code anyway.
DOUG: This is fine. However, there should be the restriction that
only all export function cname's used in a given declarative scope
should be unique. This "virtual function" mechanism would only
work when selecting between function variants in different
instantiated declarative scopes.
>
> So it is conceivable to export =different= SV functions under
> the same cname,
> as long as they have same signature.
> Therefore different SV source code definitions will
> correspond to the same
> name, and the right definition will be picked up on per-instance base.
> Isn't it a mechanism of virtual functions?
> Implementation wise, I don't see any issues.
>
> It could become, however, an issue for C programmers, with
> debugging their mixed
> C/SV code, that a single function may have different
> definitions (this is
> typical in OO world, but not in the oldfashioned world of C).
>
> The sole issue is: do we want such a mechanism of virtual SV
> functions?
>
> I'm not sure, but we may need to accept it because of exports
> in 'generate'.
>
> It's kind of funny, how a tiny understatement opens a door to
> a bigger problem.
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Wed Mar 26 2003 - 12:09:27 PST