Subject: Re: [sv-cc] Some more thought on the bootstrapping process
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Dec 19 2003 - 05:36:54 PST
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 ...
- 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)
- 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 ...).
- 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.
- 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)
- 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 ...
- 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 ...].
- 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.
. 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 !?!
That's all I have to say.
Best regards,
-Michael
-
Joao Geada wrote:
> Bassam,
>
> here go some more thoughts on the bootstrapping process
> (I'll avoid any further use of the word "bootstrapping" as this led to confusion before)
>
> 1- due to everyone's intent to make this something that may be used later,
> it would probably be a good idea to name the function
> vpi_load_extension(PLI_BYTE8 *extension_name, varargs)
> with the var args list containing all the further arguments.
> The exact number of additional arguments required would be defined by the
> extension category. For the reader extension, there would be 2 extra arguments:
> name of waveform to be opened (NULL for interactive)
> mode to open waveform
>
> 2- vpi_load_extension would return a pointer to a structure with the following
> definition:
>
> typedef struct {
> void *user_data;
>
> // below this point user applications MUST NOT modify any values
> PLI_INT extension_version;
> PLI_BYTE8 *extension_name;
>
> // one function pointer for each of the defined VPI routines
> // NOTE that each function pointer has to have the correct prototype
> PLI_INT32 (*vpi_chk_error)(error_info_p);
> ...
> PLI_INT32 (*vpi_vprintf)(PLI_BYTE8 *format, ...);
> } vpi_extension_s, *vpi_extension_p;
>
> This form allows users to verify that they have the right version of the
> right extension, gives users some way of attaching data with a particular
> load of an extension and has entries for each and every vpi function.
> This permits quite straightforward usage pattern (taking portion of
> the example on section 29.7.5 of your proposal):
>
> fsdb_reader = vpi_load("fsdb", "foo.fsdb", vpiAccessPostProcess);
> scope = fsdb_reader->vpi_handle_by_name("top.m1.s1", NULL);
> loadCollection = fsdb_reader->vpi_create(vpiObjCollection, NULL, NULL);
> itr = fsdb_reader->vpi_iterate(vpiNet, scope);
> ...
>
> 3- if vendors want to do proprietary extensions, those extensions must *only*
> have the effect of making the vpi_extension_s structure larger and any non
> standard content must occur *after* all the standard stuff. This would permit
> the extended "object" to be used as if it was a normal object by any applications
> that wish to stick with the standard, but still permit applications to go beyond
> by casting the return to the vendor extended structure, eg
>
> typedef struct {
> // inline copy of vpi_extension_s
> void *user_data;
> ...
> PLI_INT32 (*vpi_vprintf)(PLI_BYTE8 *format, ...);
>
> // vendor "foo" extension with 1 new routine
> int (*foobar)(int)
> } vendor_extension_s;
>
> Example of use of such mechanism:
>
> vpi_extension_p *h;
> vendor_extension_s *p;
>
> h = vpi_load_extension("foo", <args>);
> if (h && h->version == right_version && !strcmp(h->extension_name, "foo") {
> p = (vendor_extension_s*) h;
> // can now use p to access all the stuff, including the vendor extension "foobar"
> }
>
> 4- specific details on the "vpi_load_extension" functionality:
>
> this function is responsible to load a copy of a vpi extension into the running
> system. Given the invocation
> vpi_load_extension("EXTENSION", "a", "b", ...)
> It has to perform the following tasks
>
> 1) check whether the symbol "EXTENSION" exists in the system. If not
> dlopen() the shared library "libEXTENSION.so". Note that the location
> and exact file extension of the shared library depends on the platform
> and the vendor toolset.
> Note that the reason to check the symbol existence first is to:
> a) permit for static linking implementations
> b) avoid duplicate loading of libraries if that library already loaded
>
> 2) invoke the function named "EXTENSION", which must have the prototype
> vpi_extension_p *EXTENSION(va_list ap)
> supplying it with all the all the remaing arguments provided to the
> vpi_load_extension call.
> Return the value returned by this call to the caller of vpi_load_extension
>
> Notes:
> a) for extension providers: the *only* symbol to be exported from this
> extension library must be the function whose name matches the extension
> (ie for the "foobar" extension, the only visible symbol in the library
> should be the symbol "foobar"). This will ensure that multiple extensions
> do not clash, whether statically or dynamically loaded into a tool.
> b) for users: supplying insufficient or incorrect arguments to the vpi_load_extension()
> (specifically, the additional arguments that are to be delivered to the
> extension library's entry point) could cause "unpredictable" behavior ;-)
>
> 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
> ==============================================================================
--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 : Fri Dec 19 2003 - 05:38:43 PST