Subject: Re: [sv-cc] RE: Feedback on Read API (VPI enhancement)
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Dec 17 2003 - 11:23:46 PST
Hi all,
let me try to identify the root mechanics of this discussion (to see whether I really understood or just believed to do so) and
further try to enhance it a little bit. Hope this closes down this issue.
I believe I heard:
- we should not define how to link in a library (static vs. dynamic);
the only definition to be made is that the SystemVerilog application (I intentionally do not say simulator here!) is
responsible for loading the appropriate reader API library (by whatever means).
- there is a naming convention that defines the name of a bootstrap function within this library. Suggestion from
Joao is that the name is equivalent to the name of the library. This bootstrap function (and only this one) is being
called after loading the reader API library.
- this bootstrap function is responsible for providing a data structure of type <whatever>, which contains/defines
all functions provided by this library. The content of the data structure <whatever> is defined by the reader API
and basically defines a function pointer for every function of the reader api.
- also the bootstrap function is the function responsible for loading the actual waveform information (this does not
imply that the data is stored on disk, the function might just connect to another process, but this is invisible to the
actual application).
- all further function calls for retrieving waveform information are directed over the function tray provided by the
bootstrap function.
I would like to suggest the following enhancements of these definitions (inserted and marked as red):
- we should not define how to link in a library (static vs. dynamic);
the only definition to be made is that the SystemVerilog application (I intentionally do not say simulator here!) is
responsible for loading the appropriate reader API library (by whatever means).
- there is a naming convention that defines the name of a bootstrap function within this library. Suggestion from
Joao is that the name is equivalent to the name of the library. This bootstrap function (and only this one) is being
called after loading the reader API library.
No other symbol (function,global objects) should be exported by this library that is externally visible.
(* I intentionally say the weaker "should" instead of making it an error, but I believe helps to avoid clashes).
- this bootstrap function is responsible for providing a data structure of type <whatever_t>, which contains/defines
all functions provided by this library. The content of the data structure <whatever_t> is defined by the reader API
and basically defines a function pointer for every function of the reader api.
We should additionally define the following:
The data structure <whatever> contains the following two fields in slot 0 and 1:
size_t size; /* must be set to sizeof(<whatever_t>) */
long struct_version; /* version identifier, must be set to 1 for SV 3.1a or come up with a nice #define */
plus the following two rules:
Subsequent versions of this data structure <whatever_t> must only extend it by adding members at the end,
previously existing entries must not be changed, removed or re-ordered (this permits upward compatibility
to a maximum extend).
Unsupported member functions must be set to NULL, thus informing about a feature that is not supported.
(we might want to state the mandatory functions in the data structure ...)
- also the bootstrap function is the function responsible for loading the actual waveform information (this does not
imply that the data is stored on disk, the function might just connect to another process, but this is invisible to the
actual application).
We should define the return value of NULL (no function tray) to identify a failing load of the waveform info.
- all further function calls for retrieving waveform information are directed over the function tray provided by the
bootstrap function.
Finally a simple example would be really useful here; sthg like ... (just to illustrate this ...)
SV application loads READER.so
SV application calls READER()
READER() then loads/connects to, or otherwise creates the waveform information specified by calling READER
if failure returns NULL <-- it is illegal to proceeed with reader code in this case
if success returns a pointer to a function tray; basically of type <whatever_t>*
any subsequent access to waveform information is done by this pointer, basically:
<whatever_t>* FunctionTray;
<derive name of READER from the library name>
FunctionTray = READER(<args>);
if (FunctionTray != NULL)
{
/* access waveform database by FunctionTray-><functionname>()*/
x = FunctionTray-><functionname>(<args>);
}
else
{
/* failure, do error handling here*/
}
Hope this is useful. Let me know what is wrong and bring me straight to the most simple solution.
But not more simple ;-), please.
Best regards,
-Michael
Joao Geada wrote:
> Francoise,I don't think that the case where we have 2 simulators linked together is common enough or an already solved
> problemprior to the read VPI to require a read VPI solution.Even prior to dealing with the read side VPI a significant number of
> other issues would also have to be dealt with,including ensuring that common symbols from each simulator do not clash, handling of
> link time issues relatedto normal VPI/PLI applications (which simulator would they link to?), handling of link time issues related
> to systemtasks (when invoking $random, which one would you get?), etc. Linking simulators together is better handled by
> otherstandards (VMC, etc) and not as an extension to VPI.As for static linking: the easy answer is that it doesn't matter: the
> only exported function from each of the read librariesis the entry point routine and that is unique across libraries. All the
> other functions can only be accessed via the functionvector and therefore do not (should not) be exported as symbols from the
> library. Joao
>
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 377 Simarano Drive, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
>
> -----Original Message-----
> From: Francoise Martinolle [mailto:fm@cadence.com]
> Sent: Wednesday, December 17, 2003 11:47 AM
> To: Joao.Geada@synopsys.COM; Joao.Geada@synopsys.COM; bassam@novas.com; Sv-Cc
> Cc: Ghassan Khoory
> Subject: RE: [sv-cc] RE: Feedback on Read API (VPI enhancement)
>
> Joao,
>
> your proposal does not cover the case where there are 2 simulators vcs and ncverilog and an application wants to use
> both VPI from vcs and VPI from NCV. Yours is very specific to the read API.
> My proposal is to add a specific tool routine to invoke in order to get the VPI function tray supported by that tool.
>
> My proposal is general enough that it can be extended to cover any situation.
> Also your proposal cannot support the case when the tools need to be statically linked together?
>
> Francoise
> '
>
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Dec 17 2003 - 11:26:06 PST