Subject: Re: [sv-cc] Assertion API errata
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Jan 02 2004 - 04:50:27 PST
Hi Bassam et all,
thanks a lot. This is exactly what I suspected after reviewing the content of draft2 against my email - there were too many changes
missing that I thought I have seen earlier. Unfortunately I did not have access to eda.org while I crafted the errata (the server
was down over the weekend), so I had no chance to look at the changes list for missing changes (like LRM-121).
Meanwhile I have crafted a new updated errata that will be sent in some seconds after this email.
Happy New and Best Wishes to all of you.
-Michael
Bassam Tabbara wrote:
> 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):
>
> typedefstructt_vpi_source_info {<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
>
> 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;
>
> typedefstructt_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_infosourceInfo;
>
> } s_vpi_assertion_info, *p_vpi_assertion_info;
>
> intPLI_INT32vpi_get_assertion_info (assert_handle, p_vpi_assertion_info);
>
> Section 28.4.2
>
> LRM-121
>
> Change (changes in red and blue):
>
> vpiHandlevpi_register_assertion_cb(
>
> vpiHandleassertion,/* handle to assertion */
>
> PLI_INT32 reason,/* reason for which callbacks needed */
>
> PLI_INT32 (*cb_rtn)(/* callback function */
>
> PLI_INT32 reason,/* callback reason */
>
> p_vpi_timecb_time,/* callback time */
>
> vpiHandle assertion,
>
> p_vpi_attempt_info info,
>
> PLI_BYTE8 *userData ),
>
> PLI_BYTE8 *user_data/* user data to be supplied to cb */
>
> );
>
> typedefstructt_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;
>
> typedefstructt_vpi_attempt_info {
>
> union {
>
> vpiHandlefailExpr;
>
> p_vpi_assertion_step_info step;
>
> } detail;
>
> s_vpi_timeattemptTime,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 placedregistered.
>
> The attempt information structure contains details relevant to the specific event that occurred.
>
> —On disable, enable, reset and kill eventscallbacks, the info field is absent (a NULL pointer is given as the value of info)NULL.
>
> —On start and success eventscallbacks, only the attemptStartTimetimefield is valid.
>
> —On a failure eventcallback, the attemptStartTimetimeand detail.failExprare valid.
>
> —On a step callback, the attemptStartTimetimeand detail.stepelements 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_timestructure) 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! ***
>
>
--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 : Fri Jan 02 2004 - 04:52:15 PST