[sv-cc] user data

In a subsequent email thread, Michael said that he liked the user_data
field.
I found another email of mine in January 2004 asking again to remove the
user_data.
I cannot find any written information of how it is used and whether or no my
request
was discussed.
So I would say again, let's remove it.

Francoise
    '



-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Joao
Geada
Sent: Friday, December 19, 2003 12:24 PM
To: Michael.Rohleder@motorola.com; Joao.Geada@synopsys.com
Cc: Bassam Tabbara; Sv-Cc
Subject: RE: [sv-cc] Some more thought on the bootstrapping process

Michael,

good feedback. My comments interspread below

============================================================================
==
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: Michael Rohleder [mailto:michael.rohleder@motorola.com]
> Sent: Friday, December 19, 2003 8:37 AM
> To: Joao.Geada@synopsys.COM
> Cc: Bassam Tabbara; Sv-Cc
> Subject: Re: [sv-cc] Some more thought on the bootstrapping process
> 
> 
> Joao,
> 
> thanks for this writeup. Just some minor comments from my side:
> w.r.t. 1)
>  - the parameter varargs should be a syllable (...). We should also 
> mention that we the POSIX style of variable arguments must be used (I
think this is contained in stdarg.h). Otherwise we might easily run into
compatibility issues ...

   yes, POSIX/ANSI stdargs should be used and function prototype should
state
   "..." rather than "varargs". I was copying from the 1364-2001 phrasing,
   but that is clearly out of date now.


>  - this would lead to two definitions: a generic extension capability, and
a second definition for the reader API specific stuff.
>  I would suggest we focus on the second and have an eye that this could be
extended to the first, just to stay on track ...
> w.r.t. 2)

   If what you are saying is: design general extension loading facility but
   use it only for the purposes of the reader extension, then yes, I agree.

>  - you forgot my suggestion of a size field reflecting the actual size 
> of the data structure. This is a minimum requirement for being able to 
> check against a function expected that is actually not within the data
structure. Otherwise the check already might cause a failure (since it
exceeds the data structure size and might land in nowhere's land ...).

   Yes, sorry, I did forget. I do believe it is a very good suggestion as it
   allows an extra checking step prior to doing the cast.

>  - your proposal suggests that the reader version of 
> vpi_load_extension() actually loads or connects to the waveform DB. This
is also my understanding. Francoise said this is not the case. Please
clarify.

   The intent is that the invocation of the entry point causes the DB to be
connected to the extension.

>  - I like the user_data field. Such a field proofed to be useful in many
cases. Please keep it.
> w.r.t. 3)
>  - we should define a 'standard' name & version # for the reader API 
> extension. (or better to say for the corresponding data structure ...) 
> w.r.t. 4)

   Note that the extension name will depend on the DB being read: VCD, FSDB,
VPD, DAI, ...
   What should be well defined is the API set that the readers provide.

>  - I am not sure I would define the specifics mentioned in step 4); I 
> believe it is sufficient to say upon finding a call of
> vpi_load_extension("EXTENSION") a library with this name has to be 
> loaded (by some means - an user should not care about this ...).
> Do we need to describe the full process here; I like this to be an
example, but not normative ...

  Yes, it is probably going into much implementation detail, but it is
helpful for discussions in committee.
  I do not have a problem with this not being normative.

>  - Since you are soo keen about not having to use dlopen() [yes, yes, I
know about VCS ...], there is one implicit problem here:
> This would basically require extension vendors to deliver a *.a 
> archive _and_ an a *.so/*.sl/*.lib shared library [you can not link a 
> shared lib statically ...].

  Hm, VCS can deal with dynamic libraries, it is just that for most VPI
applications the dynamic approach does not allow
  a convinient way of describing the capabilities of the function attached
to the simulator.
  For the purposes of the reader the dynamic version would be better in
general.
  However, I do believe it is important to permit the system to work both in
static and dynamic form, as it would allow
  a third party to build a specific application and deliver it without
having to worry about shipping all the extra
  shared libraries (that a user could change)

>  - There is also one possible twist:
>     . you said that the user is responsible for supplying the 
> appropriate number and form of variable arguments; this is O.K. when there
is only one possible extension type (since then these arguments are know).
>     . when you want to permit other kinds of extensions, the required 
> arguments are not known. On the other side it is impossible for the 
> vpi_load_extension() to know which kind of extension is library being
loaded. Is there a possible twist? I believe not, we are just calling the
corresponding function ... but this might be worth some thoughts.

  Note that a user is explictly requesting a specific extension (not a
general "reader", but a "VPD" reader say),
  so they ought to know which specific arguments it requires.

>     . on the other side this kind of calling mechanism is designed to 
> be user-unfriendly. In cases where the user erroneously calls an 
> extension of type "X", but expects an extension of type "Y", the code 
> must fail with a seg-fault, bus-error or similar user-friendly 
> messages. The problem is that the extension bootstrap function 
> EXTENSION() already processes the variable arguments received before you
check the extension name returned by it. It this is wrong, it is very likely
that it fails already while processing those arguments ... And then there is
no chance to validate the reason for the fail !?!

  I am not sure how to improve this. It is possible to detect errors, by
having the extension entry point function
  guard itself against bad arguments by trapping all signals for the
duration of the entry point and, should any signal
  be thrown the function should abort returning NULL.
  Do you have a better suggestion? The approach is practical but not very
"elegant".

> That's all I have to say.
> 
> Best regards,
> -Michael


Thank you again for the good feedback,

Joao