Subject: RE: [sv-cc] Updated rev of Reader VPI extension (1/12/04) -- the list of fixes by end of day
From: Bassam Tabbara (bassam@novas.com)
Date: Wed Jan 14 2004 - 08:43:58 PST
Thanks Michael,
Yes I will send out a frame6 version later today so we can all share in the
edit load. About your comments (we can discuss today, just so I don't
forget), this is my list of fixes for today's version (goes into LRM). I
marked in red areas I need input on from the team, Michael ?
- order of routines: Yes indeed! thx for reminding me! (I wanted to raise
this issue today), I wrote "in the standard" because I meant the SV standard
(and did not want to committ to the order yet), there are other vpi routines
(assertion/coverage) that we also need to add. Need to find the order of
those (not in tables)... <<< ideas on this ? What's the best (quick!!) way.
May be we can add 2 tables in the respective chapters ? That'll make it easy
on readers.
- sizeof: Yes that's a bug, thx, I thought I wrote "sizeof(...)". But yes
you are right, I'll look and see which struct to put there instead of "...".
- vpi_close(): a) Yes adding the vpiType is a great idea. b) I think you and
I can compromise on this, we can add vpi_close for
vpiAccessLimitedInteractive but not say that the handles should be
invalidated in that case (only in other 2 modes), fair enough ?
- vpi_get_time(): Two options: (a) leave as is, (b) pull in the
vpi_get_trvs_time() functionality (as Francoise suggested: using "type" in
s_vpi_time as a bit field). There is a risk with updating this, but we can
always file a later errata if the description has bugs.
Thx.
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com <http://www.novas.com/> (408) 467-7893
-----Original Message----- From: Michael Rohleder [mailto:michael.rohleder@motorola.com] Sent: Wednesday, January 14, 2004 5:13 AM To: bassam@novas.com Cc: sv-cc@eda.org Subject: Re: [sv-cc] Updated rev of Reader VPI extension (1/12/04)
Bassam,
Thanks a lot for this nice writeup. Unfortunately I am still not fully satisfied with the description of the content of the s_vpi_extension structure (paper page 19+20); for the following reasons: - it still does not define crystal clear which functions are to be in this structure, and in which order. - IMHO, the new functions added by the Read API (table 30-2, page 9) must also be represented and are still missing
I would have done a proposal update directly on the Frame to speedup the discussion, but can not open it. I assume it is Frame 7, I just have access to Frame 6 ... Bad luck for me poor guy.
Therefore I would like to propose the following changes: Second paragraph on paper page 20, "The structure shall have an entry for every VPI routine." to "The structure shall have an entry for every VPI routine, the order and synopsis of these entries within the structure must exactly match the order of function definitions in chapter 27 of the Verilog Standard, IEEE Std 1364-2001." After this sentence we should either add a sentence similar to "After those entries all new functions defined within table 30-2 are to be added in exactly the order noted in this table." When choosing this option, we need of course to remove the vpi_load_extension from this table. Or we are just adding all functions from this table (again with the exception of vpi_load_extension) _after_ the VPI built-in's to the structure (my personal preference). We then can remove the first sentence of the next paragraph "The order of the VPI routines must be exactly that of the standard", which is IMHO a little bit misplaced there.
A second, more cosmetic change would be in the following example on page 20, to have the h->struct_size being checked against sizeof(s_toolZ_extension) [if using extension functions] or sizeof(s_vpi_extension) [if using no extensions] instead of ...
Besides that, I agree to all your modifications to my comments as you noted in http://www.eda.org/sv-cc/hm/1726.html , [thanks a lot again for your hard work here] with one exception: [MJR] - suggest to call vpi_read_close() for _all_ access modes. Suggest to change the second block after the example on how to call reader_extension_ptr->vpi_get(...) in the second half of page 10 accordingly. There might be cleanup actions required for other access modes as well. We should permit also implementations requiring this ... [BT] I added that it should be called in the modes that rely on database (to close and cleanup) i.e. vpiAccessPostProcess and vpiAccessInteractive. I shyed away from adding it to vpiAccessInteractive because that is the same mode of a regular VPI access to simulator. Calling a vpi_close() would invalidate all the handles created and that does not seem a friendly way to deal with things in that specific mode. >>> IMHO opinion we should still call vpi_read_close() in all cases, even if there is no need for a cleanup for a specific mode in one particular implementation [I regard that this might be a wrong assumption for another implementation]. vpi_read_close also receives the prop parameter of type vpiType, which permits to handle such cases gracefully. So for a more general invocation method and to permit different implementations requiring some cleanup I believe it would be still a benefit to call this function for _all_ access modes. And I am not very concerned about the handles created here, they are either still valid (since thy are belonging anyway to the simulator, or are no longer used (without causing an error), because they are belonging to the reader -- which is terminated at this point in time, isn't it?)
Just some food for thought for the discussion today.
Best regards, -Michael
Bassam Tabbara wrote:
Attached also with fm.Thx.-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.
http://www.novas.com <http://www.novas.com/> (408) 467-7893
--
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 : Wed Jan 14 2004 - 08:45:23 PST