Re: [sv-ac] RE: proposal for 2732

John,
<*If, as part of the tool specific message printed by*
*$error, a tool reports the ending or failing time of this evaluation
attempt, the time*
*reported must be 80.*>
The LRM seems to provide lots of freedom on this issue. The "must" may be
too strong. Do we really want to make that strong of a statement? I don't
know what others think about this, but it would be ok with me to just say:
A tool may report the ending or failing time of this evaluation attempt at
time 80 instead of 90.

[Ben]
It does not bother me that the time step that is displayed
automatically as part of $error ("the simulation run time") is also 90
because engineers who analyze the cause of the error at that time will
look at the conditions in the previous time steps. We're used to
that, as often all types of error messages are always around the
location of the error message. This is true for compilation errors
and simulation errors.
Ben Cohen

On Wed, May 26, 2010 at 11:45 AM, Havlicek John-R8AAAU <r8aaau@freescale.com
> wrote:

> Hi Shalom:
>
> 20.9 (p. 528) says that the message printed by $error is tool specific,
> but it must include the simulation runtime at which $error is called.
>
> In 16.9.4, the paragraph beginning at the bottom of p. 340 and ending at
> the top of p. 341 is:
>
> "A tool specific message that reports the starting or ending time step
> of an evaluation attempt of an assertion containing global clocking
> future sampled functions shall be consistent with the definition above
> of the interval of simulation time steps for the evaluation attempt. The
> message may also report the time step in which it is written, which may
> be that of the global clocking tick that follows the last tick of the
> assertion clock."
>
> The "definition above" says that the interval of evaluation does not
> extend to the next tick of the global clock, where the action block
> executes. See the preceding paragraphs on p. 340.
>
> So, I think this gives a tool the flexibility to report to the user that
> the fail occurs at time 80, even though $error executes at time 90. It
> doesn't require the tool to do this, but if the tool reports the
> interval of evaluation, it has to report it ending at 80, not 90.
>
> We had to delay execution of the action block to allow reasonable
> implementation in simulation.
>
> It might be worth considering relaxing the requirement in 20.9 that the
> runtime when $error executes be printed.
>
> However, the scope of this Mantis is just to clarify what is already in
> the LRM as it pertains to the particular example.
>
> Best regards,
>
> J.H.
>
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Wednesday, May 26, 2010 12:09 AM
> To: Havlicek John-R8AAAU; sv-ac@server.eda.org
> Subject: RE: proposal for 2732
>
> John,
>
> If $error is executed at time 90, then the time step that is displayed
> automatically as part of $error ("the simulation run time") is also 90?
> That doesn't seem to give a friendly, intuitive behavior to the user.
>
> Thanks,
> Shalom
>
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Havlicek John-R8AAAU
> > Sent: Wednesday, May 26, 2010 7:15 AM
> > To: sv-ac@server.eda.org
> > Subject: [sv-ac] proposal for 2732
> >
> > Hi Folks:
> >
> > I've uploaded a proposal for 2732 in Mantis. Please see the files
> > uploaded to the Mantis item.
> >
> > J.H.
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution by
> others is strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.