Subject: RE: [sv-cc] Some more thought on the bootstrapping process
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Fri Dec 19 2003 - 09:23:46 PST
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
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 09:24:57 PST