Subject: Re: [sv-cc] Assertion errata--items to discuss on 12/17 meeting
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Thu Dec 11 2003 - 10:39:09 PST
Bassam, Swapnajit,
many thanks for your open ears about this topics.
I think point 1) we should ignore for now. This is a bigger issue with the whole of VPI/PLI and I have not much hopes that it will
be really and completely solved (by properly using const). There is also a great chance that we might break existing code ... As
said, this is an issue in PLI & VPI overall. But I will have some look on _documenting_ arguments that are actually to be treated as
const ... at least for the code we are adding now.
Point 2) could be solved by a simple typedef, which is what we should do IMHO. A possible solution for this might look like:
/* typedef for vpi_register_assertion_cb callback function to improve readability */
typedef PLI_INT32 (vpi_assertion_callback_func)(
PLI_INT32, /* reason -- callback reason */
p_vpi_time, /* cb_time -- callback time */
vpiHandle, /* assertion -- handle to assertion */
p_vpi_attempt_info, /* info -- structure holding information for this attempt */
PLI_BYTE8* /* userData */ );
vpiHandle vpi_register_assertion_cb(
vpiHandle assertion, /* handle to assertion */
PLI_INT32 reason, /* reason for which callbacks needed */
vpi_assertion_callback_func* cb_rtn, /* callback function */
PLI_BYTE8 *user_data /* user data to be supplied to cb */
);
/* I am writing this out of my ill brain, might be that I got the typedef syntax wrong ...; but I think the readability is improved
significantly. If I didn't make everything wrong the functionality should be exactly like the one in Bassam's errata */
Point 3) and 4) are non-issues in my eyes. I mostly agree to Bassam's comments.
That's all. Don't make too much noise about this. Thanks again for your hard work on this.
Best regards,
-Michael
Bassam Tabbara wrote:
> Ok Michael,
>
> So let's discuss this next week (thx Swapnajit). Let me just list all of
> them here, although I think only one item (before Michael's) I ignored
> (cleaning up the callback function, marked with "**" below), and I meant
> that it did not affect "voting" and too hard to fix quickly, not to
> ignore altogether of course, sorry about that. Anyway, here's the list
> of all the items.
>
> 1) (Michael): > Just as a side note - and it very likely falls more or
> less in the hands of the IEEE committee, since this is a problem for the whole of PLI - what about using the const qualifier for
> some of the strings (or at least indicating which arguments are never touched)? I am pretty sure this is the
> case for several parameters and/or structure elements; so we should indicate its intended use - including whether it can/will be
> modified.
>
> Bassam sez: Michael, yes, I understand what you mean, but can't put my
> finger on specifics (without a detailed look) since the parameters
> (vpiType for example) are already constants, and most of the passed
> elements to the calls are pointers allocated user side in most cases.
>
> **2) (Francoise + Michael): > > > For the assertion errata, I think it
> is confusing (when I
> > read) to
> > > > embed the prototype of the callback function in
> > > > vpi_register_assertion_cb.
> > > >
> > > > I would prefer if there would be a function prototype used
> and
> > > > defined.
>
> Bassam sez: I 100% agree ! I was *also* confused when I was listing the
> errata :-(. I'm just worried addressing it may mess things up in the
> short time we way, but we can give it a go of course.
>
> -------I think the following are not really debatable...-------
>
> 3) (Francoise) > The following sentence :
> > 2) a pointer to the time of the callback
> > should be changed to:
> > 2) a pointer to the time of the assertion attempt
>
> Bassam sez: I would rather we word it like any other "callback", meaning
> you get callback reason and the "time the callback got flagged" ....
> Would rather not inject assertion attempt time (confusing since there
> are many callbacks for different reasons, easier to say "time of the
> reason", do you see where I am coming from ?
>
> 4) (Francoise)
> > Replace (incomplete sentence)
> > - For the following operator, the second argument shall be a
> > valid assertion handle, the third argument shall
> >
> > be an attempt start-time (as a pointer to a correctly
> > initialized s_vpi_time structure) and the fourth argument
> >
> > shall be a step control constant.
> >
> > Usage example: vpi_control(vpiAssertionEnableStep,
> > assertionHandle, attemptStartTime,
> >
> > With:
> > - For this operation, the second argument shall be a valid
> > assertion handle, the third argument shall
> >
> > be an attempt start-time (as a pointer to a correctly
> > initialized s_vpi_time structure) and the fourth argument
> >
> > shall be a step control constant.
> >
> > Usage example: vpi_control(vpiAssertionEnableStep,
> >assertionHandle, attemptStartTime, assertionEnableStep)
>
> Bassam sez: I see 2 things in Francoise recommendation:
> A) "For this operation": Actually the whole paragraph uses for "For the
> following operator" and then talks about it ... That's the flow chosen.
> B) "assertionEnableStep": No, it is correct as is (consistent with the
> rest), there is a page break, the last argument is on the next page (see
> the document) and it should be *vpiAssertionClockSteps* anyway. Just an
> artifact, may be I did not explain this well.
>
> 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 : Thu Dec 11 2003 - 10:50:53 PST