Hi,
> -----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:23 AM
> To: verilog-AMS LRM Committee
> Subject: 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.
[SB] Hmm, wouldn't that give the correct result however you interpreted it?
Note that SV requires that there be no separation between the delay value and the 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 ...
[SB] Good question. #10ns should give you a 10ns delay in any case. I think the idea was that if the time unit specified in the time literal is different than the time scale, then the delay value is scaled according to the ratio.
Suppose you had
`timescale 10ns/1ps
assign #10ns out = ~in;
Then the #10 delay value is scaled to the unit used in the time scale.
This requires dividing by 10, so internally it becomes
assign #1.0000 out = ~in;
Regards,
Shalom
---------------------------------------------------------------------
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:40:07 2010
This archive was generated by hypermail 2.1.8 : Mon Aug 09 2010 - 01:40:11 PDT