[sv-cc] Assertion API errata, 2nd

Subject: [sv-cc] Assertion API errata, 2nd
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Jan 02 2004 - 04:52:38 PST

Hi all,

here is the updated Errata for the Assertion API section, after taking Bassam's LRM-121 into account, that did not
make it for the SV 3.1a LRM, draft2. I hope that Bassam is able to review this, before we can finalize it; here are
still two questions, which I would like to request that they are somewhat clarified within the text, otherwise other users might
feel the same uncertainity I feel now...:

Question1:
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.

Question2:
I am feeling a little uncertain about the difference between our latest addition, the content of the field cb_time,
and the content of attemptStartTime. What is the exact difference of the content of both fields. Originally
I thought that cb_time is the actual time of the callback happening, but Bassam's last reply stated that the Note
should be related to cb_time ... So I got it wrong obviously :~(.
So Bassam, please help and fill in the table 2 of the alternative Note (see below)

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 and Happy New Year!

-Michael

########################################################################################

Assertion API errata update as of 2-Jan-2004
[all references related to SV 3.1a draft 2, and assume an earlier application of the changes defined in LRM 121]

Section 28.4.2, "Placing assertion callbacks"

update this part of LRM-121

[paper page 341, prototype for vpi_register_assertion_cb()]

Change (changes in red and blue):

      /* typedef for vpi_register_assertion_cb callback function */
      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, /* attempt related information */
         PLI_BYTE8 *user_data /* user data entered upon registration */
      );

      vpiHandle vpi_register_assertion_cb(
            vpiHandle assertion, /* handle to assertion */
            PLI_INT32 reason, /* reason for which callbacks needed */
            PLI_INT32 (*cb_rtn)( /* callback function */
                  PLI_INT32 reason, /* callback reason */
                  p_vpi_time cb_time, /* callback time */
                  vpiHandle assertion,
                  p_vpi_attempt_info info,
                  PLI_BYTE8 *userData ),
            vpi_assertion_callback_func *cb_rtn,
            PLI_BYTE8 *user_data /* user data to be supplied to cb */
      );

      typedef struct t_vpi_assertion_step_info {
            PLI_INT32 matched_expression_count;
            vpiHandle *matched_exprs; /* array of expressions */
            p_vpi_source_info *exprs_source_info; /* array of source info */
            PLI_INT32 stateFrom, stateTo; /* identify transition */
      } s_vpi_assertion_step_info, *p_vpi_assertion_step_info;

      typedef struct t_vpi_attempt_info {
            union {
                  vpiHandle failExpr;
                  p_vpi_assertion_step_info step;
            } detail;
            s_vpi_time attemptTime, attemptStartTime; /* Time attempt triggered */
      } s_vpi_attempt_info, *p_vpi_attempt_info;

[at paper page 342, add the following 3rd Note at the end of this section]

NOTES

3 -- the content of the cb_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, data supplied is NULL

or alternative (Bassam, please fill in the correct information, I am unable to do this :-( ... )

3 -- the content of the cb_time field and the attemptStartTime field in the attempt related information
       is dependent on the content of the reason field, as identified in the following table:

o------------------o-----------------------------------o----------------------------------o
| reason | cb_time | attemptStartTime |
o------------------o-----------------------------------o----------------------------------o
|cbAssertionStart | time when the assertion attempt | |
| | has been started | |
|cbAssertionSuccess| time when the successful | |
| | assertion attempt has been started| |
|cbAssertionFailure| time when the failing assertion | |
| | attempt has been started | |
|cbAssertionStepSuccess| time when the assertion attempt| |
| | related to the the successful step| |
| | has been started | |
|cbAssertionStepFailure| time when the assertion attempt| |
| | related to the the failing step | |
| | has been started | |
|cbAssertionDisable| | not possible, info not supplied |
|cbAssertionEnable | | not possible, info not supplied |
|cbAssertionReset | | not possible, info not supplied | |cbAssertionKill
| | not possible, info not supplied |
o------------------o-----------------------------------o----------------------------------o 

--

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                  | \ \
  _( (_ |  _   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 : Fri Jan 02 2004 - 04:53:35 PST