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.