[sv-cc] Assertion API errata

Subject: [sv-cc] Assertion API errata
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Dec 22 2003 - 08:06:15 PST

Hi all,

please find below the remaining Errata for the Assertion API. It contains my two action items
(using a typedef for the cb_rtn function, and provide list for the possible content of attempt_time)
plus three more items I found:
 - the first parameter of the vpi_register_assertion_cb() function has still no name (I thought I have
seen that Bassam already fixed this, but it is not in draft2)
 - the name of the time data slot is attemptTime, despite the fact that we are talking about attempt_time
   in the corresponding text
 - for whatever reason there is a comma after attemptTime, instead of a semicolon
[if this crosses some changes David has to make for Draft3, sorry, but I think it is worth to note].
And just as a sidenote, we are rather inconsistent with variable naming; sometimes the StateFrom
style, sometimes the exprs_source_info style is used. Not important, but it looks rather
inconsistent ...

Best regards,
-Michael 

----

Assertion API errata update as of 20-Dec-2003
[all references related to SV 3.1a draft 2]

######################################################################
* section 28.4.2, "Placing assertion callbacks", paper page 341, prototype for vpi_register_assertion_cb():

OLD:

vpiHandle vpi_register_assertion_cb(
   vpiHandle,           /* handle to assertion */
   PLI_INT32 reason,    /* reason for which callbacks needed */
   PLI_INT32 (*cb_rtn)( /* callback function */
      PLI_INT32 reason,
      vpiHandle assertion,
      p_vpi_attempt_info info,
      PLI_BYTE8 *userData ),
   PLI_BYTE8 *user_data /* user data to be supplied to cb */
);
...
typedef struct t_vpi_attempt_info {
   union {
      vpiHandle failExpr;
      p_vpi_assertion_step_info step;
   } detail;
   s_vpi_time attemptTime,
} s_vpi_attempt_info, *p_vpi_attempt_info;

NEW:

/* typedef for vpi_register_assertion_cb callback function */
typedef  PLI_INT32 (vpi_assertion_callback_func)(
   PLI_INT32 reason,         /* callback reason */
   vpiHandle assertion,      /* handle to assertion */
   p_vpi_attempt_info info,  /* attempt related information */
   PLI_BYTE8 *user_data      /*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 */
);
...
typedef struct t_vpi_attempt_info {
   union {
      vpiHandle failExpr;
      p_vpi_assertion_step_info step;
   } detail;
   s_vpi_time attempt_time;
} s_vpi_attempt_info, *p_vpi_attempt_info;

######################################################################
* section 28.4.2, "Placing assertion callbacks", paper page 342, add a 3rd Note:

NEW:

3 -- the content of the attempt_time field is dependent on the reason identified by the reason field, as follows:
       . cbAssertionStart - time when the assertion attempt has been started
       . cbAssertionSuccess, cbAssertionFailure - time when the successful/failing assertion attempt has been started
       . cbAssertionStepSuccess,cbAssertionStepFailure - time when the assertion attempt related to the the successful/failing step
has been started
       . cbAssertionDisable, cbAssertionEnable, cbAssertionReset, cbAssertionKill - not possible, info field is not supplied (NULL)

Question:
Just out of curiousity, which field is valid in case of cbAssertionStepFailure, the detail.fail or the detail.step field?
The standard says, in case of a failure event, the detail.fail is valid, and in case of a step event the detail.step
elements are valid. IMHO cbAssertionStepFailure is both, failing and a step event. Since both fields are a union,
only one of both fields can be selected. Just by feeling I would say, that in this case the detail.step field is the
correct one, but we should be more explicit.

--

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 : Tue Dec 23 2003 - 11:06:01 PST