[sv-ac] RE: Updated version of 2328

From: Little Scott-B11206 <B11206@freescale.com>
Date: Tue Feb 01 2011 - 06:20:59 PST

Hi Shalom:

Thanks for the feedback.

The motivation for not sampling variables of time and realtime is that if someone is assigning the simulator time to a variable it doesn't make sense to sample it because they want the value of time in the current timestep. The distinction isn't due to the type it is due to the expected usage of a variable of that type. I understand that the type doesn't force a usage. It might be nice to have a simple way to force a variable to be "unsampled". That has been discussed before. Maybe we should consider it again.

Ah, ok, I see your point on 16.6. That wording is found several places in the LRM. I think it deserves a bit of clarity. Would the following be more clear? "Functions that appear in expressions shall be automatic or preserve no state information, and they shall have no side effects."

In 17.2, how about, "All checker formal arguments are inputs and they are processed in a similar way as property formal arguments, but the data types of checker formal arguments are those legal for a property (see 16.13) and string."?

Thanks,
Scott

> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Tuesday, February 01, 2011 6:45 AM
> To: Little Scott-B11206; sv-ac@eda.org
> Subject: RE: Updated version of 2328
>
> Hi, Scott.
>
>
> On 16.5:
>
> There is nothing inherently "time-y" about the realtime data type.
> 6.12 is very explicit that real and realtime are the same and are
> completely interchangeable.
> The keyword 'realtime' only exists for convenience.
>
> Similarly, the data type 'time' is a synonym for 'logic [63:0]'.
> A time variable can be used for non-time 64-bit values, and time values
> can be held in non-time data types.
>
> There is no need to make a distinction here between the time/realtime
> data types and other data types.
>
>
> In 16.6 et al, did you intent to require that all functions be
> automatic? Is that really backward-compatible?
>
>
> In 17.2, you should fix the grammar at the end of "All checker formal
> arguments are inputs and they are processed in a similar way as
> property formal arguments, but the data types of checker formal
> arguments besides those legal for a property (see 16.13), may also be
> string."
>
>
> Regards,
> Shalom
>
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Little Scott-B11206
> > Sent: Tuesday, February 01, 2011 2:23 PM
> > To: sv-ac@eda.org
> > Subject: [sv-ac] Updated version of 2328
> >
> > Hi all:
> >
> > I have posted an updated proposal for 2328. You can find it on the
> > mantis page as _v1.
> >
> > http://www.eda-twiki.org/svdb/view.php?id=2328
> >
> > Thanks,
> > Scott
>
> ---------------------------------------------------------------------
> 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.
Received on Tue Feb 1 06:21:57 2011

This archive was generated by hypermail 2.1.8 : Tue Feb 01 2011 - 06:22:11 PST