RE: transition function

Marq,
so the same problem arises without transition e.g.;
 
analog 
   y = $tablemodel("file1",....);

analog begin 
   y = $tablemodel("file2",......);
   y = $tablemodel("file3",......);
end 
 
Thanks,
--Martin


________________________________

	From: owner-verilog-ams@eda.org
[mailto:owner-verilog-ams@eda.org] On Behalf Of Marq Kole
	Sent: Tuesday, January 23, 2007 9:54 AM
	To: verilog-ams
	Subject: RE: transition function
	
	

	Martin, 
	
	Maybe I need to rearrange my example, as I intended it as
multiple changes on the same signal (y) rather than multiple transitions
using the same argument (x1). So the same story applies to: 
	
	analog 
	   y = transition(x1, 5n, 5n); 
	
	analog begin 
	   y = transition(x2, 15n, 5n); 
	   y = transition(x3, 10n, 5n); 
	end 
	
	The notable differences should be in the delay, not in the
expression argument. 
	
	Cheers, 
	Marq 
	
	
	Marq Kole
	Competence Leader Robust Design
	
	Research
	NXP Semiconductors
	
	
	
	





"Martin O'Leary" <oleary@cadence.com> 

23-01-2007 15:40 

To
"Marq Kole" <marq.kole@nxp.com>
"verilog-ams" <verilog-ams@eda-stds.org> 
cc
Subject
RE: transition function 
Classification

	




	Marq, 
	I believe this refers to muliple changes (transitions) on a
single signal feed to a transition operator over time not to multiple
transition operators with the same signal as argument. 
	  
	The examples do however bring up interesting questions about
race conditions around analog variable assignment. 
	  
	Thanks, 
	--Martin 
	
	
________________________________

	From: owner-verilog-ams@eda.org
[mailto:owner-verilog-ams@eda.org] On Behalf Of Marq Kole
	Sent: Tuesday, January 23, 2007 2:06 AM
	To: verilog-ams
	Subject: transition function
	
	
	All, 
	
	Transition functions can introduce ambiguities on signals that
have multiple transitions defined for them. According to section 4.4.9
of the Verilog-AMS 2.2 LRM: 
	
	"With different delays, it is possible for a new transition to
be specified before a previously specified transition starts. The
transition function handles this by deleting any transitions which would
follow a newly scheduled transition. A transition function can have an
arbitrary number of transitions pending." 
	
	Consequently, it seems to me that when a new transition is
applied to a signal that already has a transition pending then the new
transition is added to the transition function if the new delay is
larger, but any existing transition with a larger delay would be
removed. 
	
	However, if the transitions are applied in different concurrent
analog constructs the order of evaluation of these analog constructs
becomes important.
	
	Would there be any problem with assigning all transitions
defined on a signal, unless the transitions are assigned in a single
analog block? So: 
	
	analog 
	   y = transition(x1, 5n, 5n); 
	
	analog begin 
	   y = transition(x1, 10n, 5n); 
	   y = transition(x2, 15n, 5n); 
	end 
	
	Would have all three transitions pending for signal y,
independent of the order of evaluation of the two analog blocks, and: 
	
	analog 
	   y = transition(x1, 5n, 5n); 
	
	analog begin 
	   y = transition(x2, 15n, 5n); 
	   y = transition(x1, 10n, 5n); 
	end 
	
	Would only have the transitions from signal x1 pending, as the
transition from signal x2 in the second analog block is deleted per
section 4.4.9 as the second transition from signal x1 has a shorter
delay. Again, independent of the order of evaluation of the two analog
blocks. 
	
	The above approach would keep the concurrency of multiple analog
blocks, while at the same time being backwards compatible with the
Verilog-AMS 2.2 LRM. The only alternative I see is to disallow
transitions from multiple analog blocks. Any other suggestions? 
	
	Cheers, 
	Marq 
	
	
	Marq Kole
	Competence Leader Robust Design
	
	Research
	NXP Semiconductors
	
	-- 
	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 <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.