Subject: Re: [sv-cc] Assertion API errata, 2nd
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Jan 05 2004 - 01:32:21 PST
Hi Bassam,
thanks a lot for reviewing this update. This is great stuff, thanks for all your hard work here...
Also thanks for your answers to my questions; I couldn't resist to add some more comments on this. Please read on.
Best regards and best wishes,
-Michael
Bassam Tabbara wrote:
> Thanks Michael,About your questions:1) Yes it is the detail.step, for any of the "step" callbacks this is used as explained in
> the text.
>
> I would propose that we change the third bullet of the block starting with "The attempt information structure contains ..."
> from "On a failure event, the attemptStartTime ..." to "On a cbAssertionFailure event, the attemptStartTime ...", since this
> is then the only failure event where this statement is true. This will make clear that in case of a "step" callback the next
> bullet holds, but not this bullet.
> 2) attemptStartTime is always the same ... it is the start time of the attempt (of an assertion). You can think of it as a unique
> ID that distinguishes the attempts of any given assertion. So you always get this one so application can tell which attempt it's
> looking at.
>
> It would be good to add some sentence similar to your explanation here as a fourth note, to distinguish the content of
> attemptStartTime from cb_time. Otherwise you immediately start to ask yourself why there are two fields having the same value
> (which is obviously not a true statement).
> Thanks for the updates, I think I'd rather we not add a table just simple explanation should do (I just added "cb_time is .." at
> the beginning of all the lines to minimize confusion. I also corrected the colors below and some fonts, also the description in
> the notes.#############################
>
> 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 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 depends on the reason identified by the reason field, as follows:
> . cbAssertionStart - cb_time is the time when the assertion attempt has been started
> . cbAssertionSuccess, cbAssertionFailure - cb_time is the time when the assertion succeeded/failed.
> . cbAssertionStepSuccess,cbAssertionStepFailure - cb_time is the time when the assertion attempt step succeeded/failed.
> . cbAssertionDisable, cbAssertionEnable, cbAssertionReset, cbAssertionKill - not possible, data supplied is NULL
>
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Michael Rohleder
> Sent: Friday, January 02, 2004 4:53 AM
> To: SystemVerilog CC DWG
> Subject: [sv-cc] Assertion API errata, 2nd
>
> 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! ***
>
>
--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 : Mon Jan 05 2004 - 01:34:13 PST