Subject: RE: [sv-cc] Assertion API errata
From: Bassam Tabbara (bassam@novas.com)
Date: Thu Dec 25 2003 - 09:13:57 PST
Hi Michael and all,
Unfortunately I think the rev you used as a starting point is riddled
with errors; Michael can I ask you to use the attached (will also paste
here) as a starting point and ask you to reintegrate your input. I think
you missed the LRM number we have (did not make it to draft2).
Some comments: Note the changes/addition of attemptStartTime instead of
the "attempt_time", you should not use "attempt_time" for the time
explanation you add but rather cb_time (the time of the callback),
attemptStartTime is always a unique number which gives the attempt a
sort of ID.
I do not integrate your updates here, but defer to you to do it again.
Sorry Michael for this and thanks a lot, I will review it again when you
send out the version.
Thanks.
-Bassam.
--- attached pasted here (this is my local copy, you can also get it
from the original location if you wish ----
Section 28.3.2.1
LRM-121
Change (changes in red and blue):
typedef struct t_vpi_source_info {
PLI_BYTE* PLI_BYTE8 *fileName;
PLI_INT32 startLine;
PLI_INT32 startColumn;
PLI_INT32 endLine;
PLI_INT32 endColumn;
} s_vpi_source_info, *p_vpi_source_info;
typedef struct t_vpi_assertion_info {
PLI_BYTE8 *name *assertName; /* name of assertion */
vpiHandle instance; /* instance containing assertion */
PLI_BYTE8 *defname; /* name of module/interface containing
assertion */
vpiHandle clock; /* clocking expression */
PLI_INT32 assertionType; /* vpiSequenceType, ... vpiAssertType,
vpiCoverType,
vpiPropertyType, vpiImmediateAssertType */
s_vpi_source_info sourceInfo;
} s_vpi_assertion_info, *p_vpi_assertion_info;
int PLI_INT32 vpi_get_assertion_info (assert_handle,
p_vpi_assertion_info);
Section 28.4.2
LRM-121
Change (changes in red and blue):
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 ),
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;
LRM-121
Change (changes in red and blue):
The callback function shall be supplied the following arguments:
1) the reason for the callback
2) a pointer to the time of the callback
2) 3) the handle for the assertion
3) 4) a pointer to an attempt information structure
4) 5) a reference to the user data supplied when the callback was placed
registered.
The attempt information structure contains details relevant to the
specific event that occurred.
- On disable, enable, reset and kill events callbacks, the info
field is absent (a NULL pointer is given as the value of info) NULL.
- On start and success events callbacks, only the attemptStartTime
time field is valid.
- On a failure event callback, the attemptStartTime time and
detail.failExpr are valid.
- On a step callback, the attemptStartTime time and detail.step
elements are valid.
Section 28.5.2
LRM-121
Change (changes in red and blue):
Usage example: vpi_control(vpiAssertionKill, assertionHandle,
attemptStartTime)
vpiAssertionKill
discards the given attempts, but leaves the assertion enabled and does
not reset any state used by this assertion (e.g., past() sampling).
Usage example: vpi_control(vpiAssertionDisableStep, assertionHandle,
attemptStartTime)
vpiAssertionDisableStep
disables step callbacks for this assertion. This has no effect if
stepping not enabled or it is already disabled.
- 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, vpiAssertionClockSteps)
-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Michael Rohleder
Sent: Monday, December 22, 2003 8:06 AM
To: SystemVerilog CC DWG
Subject: [sv-cc] Assertion API errata
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 : Thu Dec 25 2003 - 09:19:22 PST