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

Good point - the problem would appear if the time unit uses 's' and the sale factor would use 'f', 'p', 'n', 'u', or 'm'. Would require a separator between scale factor and time unit.

Just for my understanding - if I read your description then if I would have

`timescale 1ns/1ps
assign #10ns out = ~in;

then the 10ns delay would be scaled by the 1ns time unit? I would expect that I would get 10ns delay irrespective of the timescale unit directive, only taking the timescale precision directive into account. Otherwise I would get #10ns = 10n * 1ns = 10as ...

If there is no scaling to the timescale unit then #10ns would be the same as #10n s ...

Cheers,
Marq

-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Monday 9 August 2010 10:15
To: Marq Kole; verilog-AMS LRM Committee
Subject: RE: 0003177: Real numbers with scale factors in digital delays

But if you want to use both?

3.0mus ?

I suppose you could do that. It would look funny...

Shalom

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Marq Kole
> Sent: Monday, August 09, 2010 11:11 AM
> To: verilog-AMS LRM Committee
> Subject: RE: 0003177: Real numbers with scale factors in digital delays
>
> Hi Shalom,
>
> There is no conflict as there is no overlap in the allowed time units
> (fs ps ns us ms s) in SV and the allowed scale factors of V-AMS (a f p
> n u m k K M G T P). All time units require the 's' while the scale
> factors do not allow the 's'.
>
> Cheers,
> Marq
>
>
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Bresticker, Shalom
> Sent: Monday 9 August 2010 10:05
> To: Geoffrey.Coram; verilog-AMS LRM Committee
> Subject: RE: 0003177: Real numbers with scale factors in digital delays
>
> 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.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

---------------------------------------------------------------------
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.