A perfect example for the usage of the user_data field could be found in the OMI interface standard (IEEE 1499). There is also a function tray that uses such a field, and the related functions are making extensive use of this data. I still like it and still believe it makes perfect sense. Please keep it. Regards, -Michael Warmke, Doug wrote: >Hello All, > >My understanding of the extension system is as follows. > >1. An IP or content provider creates an extension, with .h file > and object code. They provide documentation on how to use > it to their customers. > >2. Part of the provider-specific use model may involve the use > of a user_data field. As we all know, this can save users the > trouble of hashing handles or other data, when an implicit hash > already exists in the provider's implementation. > >So let's leave user_data there. >A SystemVerilog implementation doesn't have use for it, >but I don't see why we should remove it and strip the >capability from extension providers. > >Thanks, >Doug > > > >>-----Original Message----- >>From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On >>Behalf Of Francoise Martinolle >>Sent: Wednesday, April 20, 2005 10:04 AM >>To: sv-cc@eda.org >>Subject: 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> >> >> >> >> -- NOTE: The content of this message may contain personal views which are not neccessarily the views of Freescale, unless specifically stated. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Freescale Semiconductor Fax: +49-89-92103-680 |( \ / / | Freescale Halbleiter Deutschland GmbH | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@freescale.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \ The information contained in this email has been classified as: General Business Information ( ) Freescale Internal Use Only ( ) Freescale Confidential Proprietary ( ) *** This note may contain Freescale Confidential Proprietary or Freescale 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! ***Received on Thu Apr 28 11:02:36 2005
This archive was generated by hypermail 2.1.8 : Thu Apr 28 2005 - 11:02:49 PDT