RE: 0003177: Real numbers with scale factors in digital delays

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Mon Aug 09 2010 - 01:04:49 PDT

Hi,

There may be a conflict with SystemVerilog on this point.
In SV, a delay value may be a time literal.
This is the description of time literals:

"5.8 Time literals

Time is written in integer or fixed-point format, followed without a space by a time unit (fs ps ns us ms s).
For example:

2.1ns
40ps

The time literal is interpreted as a realtime value scaled to the current time unit and rounded to the current time precision."

Regards,
Shalom

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Geoffrey.Coram
> Sent: Friday, August 06, 2010 10:16 PM
> To: verilog-AMS LRM Committee
> Subject: Re: 0003177: Real numbers with scale factors in digital delays
>
> Hi, Ken -
> I had a quick look through the 1364 Verilog LRMs, and I found
> that 1364-1995 (on which V-AMS was originally built) and -2001,
>
> delay_value ::=
> unsigned_number
> | parameter_identifier
> | specparam_identifier
> | mintypmax_expression
>
> whereas in 1364-2005,
>
> delay_value ::=
> unsigned_number
> | real_number
> | identifier
>
> I assume the semantics in 2.3.1 just weren't updated to reflect
> the addition of real_number in the BNF when the new BNF was
> brought over from 1364. I support your proposal.
>
> -Geoffrey
>
>
>
> Ken Kundert wrote:
> > All,
> > I have found an inconsistency in the 2.3.1 version of the LRM. In
> > particular on page 15 is says ...
> >
> > Scale factors are not allowed to be used in defining digital
> delays
> > (e.g., #5u).
> >
> > However, the BNF uses delay_value to represent a digital delay, and
> on
> > page 331 it says that delay_value may be a real number, and on page
> 351
> > a real number is allowed to have a scale factor.
> >
> > This conflict within the LRM should be eliminated. I see no reason
> for
> > this restriction, and in fact one existing commercial implementation
> > allows this, seemingly without difficulty. I believe having arbitrary
> > restrictions like this in the language reduces its usability and in
> this
> > case it reduces it readability. I propose that we delete the
> restriction
> > on page 15.
> >
> > I would like to get this issue put on the agenda for an upcoming
> > meeting. It's ID in Mantis is 0003177.
> >
> > -Ken

---------------------------------------------------------------------
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 Mon Aug 9 01:05:44 2010

This archive was generated by hypermail 2.1.8 : Mon Aug 09 2010 - 01:05:53 PDT