FW: [sv-cc] Some more thought on the bootstrapping process

 

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Francoise Martinolle
Sent: Thursday, December 18, 2003 1:14 PM
To: Joao.Geada@synopsys.com; Bassam Tabbara
Cc: Sv-Cc
Subject: Re: [sv-cc] Some more thought on the bootstrapping process

<x-flowed>
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
>=======================================================================
>=======


</x-flowed>