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

Sorry,

I don't understand why you think I implied a default timescale.
It is true that most tools have a default and that it differs between tools, but I don't believe I related to that at all.

Please clarify.

Thanks,
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 12:23 PM
> To: verilog-AMS LRM Committee
> Subject: RE: 0003177: Real numbers with scale factors in digital delays
>
> Hi Shalom,
>
> On your last remark - this would imply a default timescale directive -
> 1364-2005 (19.8, p.358) says that is simulator-specific and does not
> even offer a suggestion. I do agree that most users would apply a
> `timescale 1ns/1ps but that's not something to build a standard on.
>
> Simple test case:
>
> `timescale 1ns/1ps
>
> module test1 (output out, input in);
> assign #10ns out = in;
> endmodule // test1
>
> `timescale 10ns/1ps
>
> module test2 (output out, input in);
> assign #10ns out = in;
> endmodule // test2
>
> `timescale 1ns/1ps
>
> module tb1;
>
> reg in;
>
> initial
> in = 0;
>
> always
> #20 in = ~in;
>
> test1 mut1 (out1, in);
> test2 mut2 (out2, in);
>
> endmodule // tb1
>
> `timescale 10ns/1ps
>
> module tb2;
>
> reg in;
>
> initial
> in = 0;
>
> always
> #2 in = ~in;
>
> test1 mut1 (out1, in);
> test2 mut2 (out2, in);
>
> endmodule // tb2
>
> `timescale 1ns/1ps
>
> module test_timescale_time_value_tb;
>
> tb1 tut1;
> tb2 tut2;
>
> initial
> #1000 $finish;
>
> endmodule // test_timescale_time_value_tb
>
> Unfortunately, my Verilog compiler does not seem to allow time values
> in a delay - it "expects" another token than the 'ns' found here. As
> far as I can tell the above code is SV compliant ...
>
> Perhaps somebody wants to try this and tell me the results (or tell
> what I need to change in the test case without removing the time values
> from the delays).
>
> Marq
>
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Monday 9 August 2010 10:40
> To: Marq Kole; verilog-AMS LRM Committee
> Subject: RE: 0003177: Real numbers with scale factors in digital delays
>
> 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.
>

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