Subject: Re: [sv-cc] Some more thought on the bootstrapping process
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Dec 18 2003 - 10:13:43 PST
I don't see the need for user_data. Let's remove it.
At 04:45 PM 12/17/2003 -0500, 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
>==============================================================================
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 10:14:16 PST