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

John,
I am OK with what your update.
Thanks for the detailed explanation.
Ben

On Wed, May 26, 2010 at 3:23 PM, Havlicek John-R8AAAU
<r8aaau@freescale.com>wrote:

> Hi Ben:
>
> I think the LRM currently says several things:
>
> 1. The action block, hence $error, executes at time 90.
>
> 2. When $error executes, it must write out the current runtime.
>
> 3. If the tool specific message printed when $error executes also prints
> information about the interval of evaluation, then that information must be
> consistent with the rule on p. 340 regarding the interval of evaluation in
> the presence of global clocking future sampled value funtions. This implies
> that if the tool prints the fail time or the end time of evaluation, that
> printed time must be "80", as in "a1 failed at time 80". The message "a1
> failed at time 80" will be printed as part of the execution of $error, hence
> this message will actually get printed at time 90. The overall message
> might look like:
>
> error: $error executed at time 90; a1 started at time 80 and failed at
> time 80; <user provided message>; blah blah blah
>
> Allowing the tool to print the message at time 80 instead of time 90
> involves changing the LRM in a non-backward-compatible way. My
> understanding was that that is out of the scope of this Mantis item.
>
> J.H.
>
> ------------------------------
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Wednesday, May 26, 2010 5:08 PM
> *To:* Havlicek John-R8AAAU
> *Cc:* Bresticker, Shalom; sv-ac@server.eda.org
> *Subject:* 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.