Re: [sv-cc] Updated rev of Reader VPI extension (1/12/04)

Subject: Re: [sv-cc] Updated rev of Reader VPI extension (1/12/04)
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Jan 14 2004 - 05:13:09 PST

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
> (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 - 05:14:21 PST