Re: suggestion

From: Kevin Cameron <dkc_at_.....>
Date: Thu Aug 30 2007 - 10:50:41 PDT
Bresticker, Shalom wrote:
> Again, in SystemVerilog, you can write #1.2345ns.

I think that is fairly unambiguous as a statement, the question for me 
(and Ken) is how to do it with a parameter or variable - and I think 
using 'realtime' (didn't remember that was a type in SV) would be the 
way to go i.e.:

    parameter *realtime* td = 1ns;
    ...

    always @(posedge clk) begin
       q = #td d;
    end
      

While working the "s" or "ns" into the delay statement might avoid 
confusion I'm not sure it can be done cleanly since mixing variables and 
type qualifiers is a bit messy - I'd probably go for something like a 
type-cast if I had to do it e.g.:

    parameter *real* td = 1; // ns
    ...

    always @(posedge clk) begin
       q = #(ns)td d;
    end
      

Kev.

>  
> Shalom
>
>     ------------------------------------------------------------------------
>     *From:* owner-verilog-ams@server.eda.org
>     [mailto:owner-verilog-ams@server.eda.org] *On Behalf Of *Scott
>     Cranston
>     *Sent:* Thursday, August 30, 2007 3:08 PM
>     *To:* Kevin Cameron
>     *Cc:* Ken Kundert; verilog-AMS LRM Committee
>     *Subject:* RE: suggestion
>
>     My opinion is that the notion of the "absoluteness" of the delay
>     should be present in the delay specification itself. Otherwise you
>     have to look back to the definition of the variable to determine
>     this - which leads to confusion.
>      
>           -- Scott
>      
>
>         ------------------------------------------------------------------------
>         *From:* Kevin Cameron [mailto:dkc@grfx.com]
>         *Sent:* Thursday, August 30, 2007 1:33 AM
>         *To:* Scott Cranston
>         *Cc:* Ken Kundert; verilog-AMS LRM Committee
>         *Subject:* Re: suggestion
>
>
>         Maybe you want a new type (say) realtime e.g.:
>
>           realtime td = 1.2345ns;
>
>           # td;          // as near a 1.2345ns delay as poss.
>
>         Kev.
>
>         Scott Cranston wrote:
>>         I don't have any concrete ideas on the syntax, although it does not seem
>>         that difficult to work out, but I don't think you need a time unit
>>         specifier, like 1ns - you would only need to specify the scale factor
>>         (p, n, u) which is already there in the language. The notion of time
>>         (and hence the units, seconds) is already present by virtue of the fact
>>         that you are specifying a delay.
>>
>>         As far as using a variable with a scale factor, you could easily write
>>
>>         #(td * 1n)
>>
>>         or you could even build a unit specifier into the proposed syntax
>>         itself, something like:
>>
>>         #{1n}(td)
>>
>>         In general it is better to be as clear and straightforward as possible,
>>         IMO.
>>
>>                -- Scott
>>
>>
>>
>>
>>
>>           
>>>>>>         -----Original Message-----
>>>>>>         From: Ken Kundert [mailto:ken@designers-guide.com]
>>>>>>         Sent: Wednesday, August 29, 2007 1:56 PM
>>>>>>         To: Scott Cranston
>>>>>>         Cc: verilog-AMS LRM Committee
>>>>>>         Subject: Re: suggestion
>>>>>>
>>>>>>         Scott,
>>>>>>            Would it be keying off the presence of ns? How would
>>>>>>         this work if I wanted to use a variable? Would I use
>>>>>>            #(td ns);
>>>>>>         Wouldn't that imply that s, ms, us, ns, ps, fs, etc. would
>>>>>>         all have to be keywords?
>>>>>>
>>>>>>         -Ken
>>>>>>
>>>>>>         Scott Cranston wrote:
>>>>>>                   
>>>>>>>         What you really want is a way to specify time absolutely, correct?
>>>>>>>
>>>>>>>         Something like #(1ns) where the 1ns is not scaled.
>>>>>>>
>>>>>>>         That seems like a clearer way to do what you want.
>>>>>>>
>>>>>>>            -- Scott
>>>>>>>
>>>>>>>
>>>>>>>                     
>>>>>>>>>>>         -----Original Message-----
>>>>>>>>>>>         From: owner-verilog-ams@eda.org
>>>>>>>>>>>         [mailto:owner-verilog-ams@eda.org] On Behalf Of Ken Kundert
>>>>>>>>>>>         Sent: Tuesday, August 28, 2007 11:44 PM
>>>>>>>>>>>         To: verilog-AMS LRM Committee
>>>>>>>>>>>         Subject: suggestion
>>>>>>>>>>>
>>>>>>>>>>>         All,
>>>>>>>>>>>            It would be very handy to have access to the
>>>>>>>>>>>                             
>>>>>>         `timescale value
>>>>>>                   
>>>>>>>>>>>         from within a model so that we can write delays in
>>>>>>>>>>>                             
>>>>>>         terms of time
>>>>>>                   
>>>>>>>>>>>         rather than ticks.
>>>>>>>>>>>
>>>>>>>>>>>         Just to throw something out, say $tick returns the
>>>>>>>>>>>                             
>>>>>>         length of a
>>>>>>                   
>>>>>>>>>>>         tick in seconds. Then one can use it in the digital
>>>>>>>>>>>                             
>>>>>>         portion of the
>>>>>>                   
>>>>>>>>>>>         model as in the following example (a d flip-flop that
>>>>>>>>>>>                             
>>>>>>         implements
>>>>>>                   
>>>>>>>>>>>         1n of delay regardless of how `timescale was specified) ...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         parameter real td = 1ns;
>>>>>>>>>>>         ...
>>>>>>>>>>>
>>>>>>>>>>>         always @(posedge clk) begin
>>>>>>>>>>>            q = #(td/$tick) d;
>>>>>>>>>>>         end
>>>>>>>>>>>
>>>>>>>>>>>         -Ken
>>>>>>>>>>>
>>>>>>>>>>>         --
>>>>>>>>>>>         This message has been scanned for viruses and
>>>>>>>>>>>                             
>>>>>>         dangerous content by
>>>>>>                   
>>>>>>>>>>>         MailScanner, and is believed to be clean.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                             
>>
>>           
>
>
>         ------------------------------------------------------------------------
>
>         mailto:dkc@grfx.com <mailto:dkc@grfx.com>
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean. 
>


-- 
http://www.grfx.com
mailto:dkc@grfx.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Aug 30 10:51:21 2007

This archive was generated by hypermail 2.1.8 : Thu Aug 30 2007 - 10:51:29 PDT