RE: #delay

FYI, ## is already used in SystemVerilog to represent a "cycle delay", where
a cycle is defined using a "clocking" definition.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Kevin Cameron
> Sent: Tuesday, March 04, 2008 8:29 PM
> To: Ken Kundert
> Cc: verilog-AMS LRM Committee
> Subject: Re: #delay
> 
> 
> Why not use a different operator (say) '##' for unscaled times, I think
> that would be less ambiguous, i.e. '#5k' is a reasonable shorthand for
> 5000 ticks, and I wouldn't like to have to explain why "#5M" isn't the
> same as "#5e6".
> 
> Kev.
> 
> Ken Kundert wrote:
> > All,
> >     One ugly aspect of Verilog that was inherited into Verilog-AMS is
> > its use of time units, as specified with the 'timescale directive.
> > Using time units acts to normalize time to some convenient unit.
> While
> > this might make sense in digital descriptions where delays are all
> > about the same size, but it almost never preferred in analog
> > descriptions. Furthermore, it makes trying to understand a module
> > difficult because you must know the time unit to understand any of
> the
> > delays, and the time unit can change on each module.
> >
> > To address this problem, I have adopted the convention of always
> > defining `tick immediately after the `timescale statement, and then I
> > use this to allow me to specify time delays in absolute times.
> >
> > `timescale 1ns/1ps
> > `define tick 1n
> > ...
> > always #(50n/`tick) clk = ~clk;
> >
> > Even this is not so great as the time unit and `tick sometimes get
> out
> > of sync.
> >
> > I was looking in the LRM and noticed that in Section 2.6.2 on real
> > constants, the SI scale factors are specifically excluded from use in
> > digital delays (ex. #50n is illegal).
> >
> > Perhaps we can instead say that if a scalefactor is used in a digital
> > delay, it indicates that the delay is specified in seconds rather
> than
> > in multiples of the time unit. That would clean up a particularly
> ugly
> > aspect of Verilog-AMS and make our models much easier to read and
> write.
> >
> > -Ken
> >
> 
> 
> --
> 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.