Subject: RE: [sv-cc] Assertion API errata, 2nd
From: Bassam Tabbara (bassam@novas.com)
Date: Fri Jan 02 2004 - 18:44:58 PST
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.
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.
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! ***
This archive was generated by hypermail 2b28 : Fri Jan 02 2004 - 18:46:42 PST