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

Subject: [sv-cc] Some more thought on the bootstrapping process
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Wed Dec 17 2003 - 13:45:14 PST

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 : Wed Dec 17 2003 - 13:45:52 PST