RE: suggestion

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Aug 30 2007 - 06:25:11 PDT
Again, in SystemVerilog, you can write #1.2345ns.
 
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.
				
				
				                    

			
			  



		
________________________________

		 
		<http://www.grfx.com> mailto:dkc_ f rom _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. 


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

This archive was generated by hypermail 2.1.8 : Thu Aug 30 2007 - 06:25:46 PDT