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

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.