Re: transition function

Marq,

Yes the pending transitions that are deleted refer to the transition 
that have already been scheduled in the event queue but have not yet 
started. Also any currently active transitions (interrupted transitions) 
at this point will end - the output values will be calculated using the 
new rise and fall times. Agree that it needs to be clarified bit more 
clearly in the transition section with an example as specified by 
Jonathan. The interrupted transitions are reasonably well explained in 
the LRM.

cheers,
Sri

Marq Kole wrote:
> 
> Jonathan,
> 
> Thanks for the explanation and the example. So does the "pending" in 
> section 4.4.9 refer (only) to the event queue? Then some rewording of 
> this section seems to be appropriate to make that more clear. Your 
> example would then be an appropriate addition to this part.
> 
> Cheers,
> Marq
> 
> 
> Marq Kole
> Competence Leader Robust Design
> 
> Research
> NXP Semiconductors
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Jonathan David <j.david@ieee.org>*
> 
> Sent by:
> owner-verilog-ams@server.eda.org
> 
> 23-01-2007 17:23
> 
> 	
> To
> 	Marq Kole <marq.kole@nxp.com>
> verilog-ams <verilog-ams@server.eda-stds.org>
> cc
> 	
> Subject
> 	Re: transition function
> Classification
> 	
> 
> 
> 	
> 
> 
> 
> 
> 
> Marq,
> 
> It has to do with a case where your transition statement has been 
> further variableised..(is that a word?)
> 
> @(initial_step("tran")) begin
>  td = 0;
>  tr = 2n;
>  tf = 3n;
>  vout = 0.5; // initial value
> end
> @(timer(1n)) begin
>   td = 1n;
>   vout =1; // schedules a transition start at 2n, end at 4n;
> @(timer(3n)) begin
>  td = 0.5n;
>   vout = 0; // schedules a transition to start at 3.5n and end at 6.5n, 
> which means that the transition started at 1n won't finish first
> end
> @timer(3.1n) begin
> td = 0.2n;
> vout = 0.5 // schedules a transition to start at 3.3n and (since the 
> current voltage is still > 0.5v) end at 6.3n = since this starts before
> // the transition set at 3n, that transition is entirely deleted..
> 
> 
> V(out) <+ transistion(vout, td, tr, tf);
> 
>  
> Jonathan David
> j.david@ieee.org
> jb_david@yahoo.com_
> __http://ieee-jbdavid.blogspot.com_ <http://ieee-jbdavid.blogspot.com/>_
> Mobile 408 390 2425
> Work:
> jbdavid@scintera.com_
> _ <http://www.scintera.com/>_ 
> <http://www.scintera.com/>_http://www.scintera.com_ 
> <http://www.scintera.com/>_
> 408 636-2618
> 
> 
> ----- Original Message ----
> From: Marq Kole <marq.kole@nxp.com>
> To: verilog-ams <verilog-ams@eda-stds.org>
> Sent: Tuesday, January 23, 2007 7:56:55 AM
> Subject: RE: transition function
> 
> 
> Martin,
> 
> You're absolutely right - this way it is an ordinary race condition and 
> not specific to the transition function. OK, another try: if we do not 
> assign the transition results to a variable but instead in a 
> contribution statement
> 
> analog
>  V(out) <+ transition(x1, 5n, 5n);
> 
> analog begin
>  V(out) <+ transition(x2, 15n, 5n);
>  V(out) <+ transition(x3, 10n, 5n);
> end
> 
> Then there is no race condition in the regular sense, but as far as I 
> understand section 4.4.9 it still introduces ambiguity. Unless the 
> transitions in this case do not make a series of pending transitions, 
> but rather sum, i.e. are equivalent to:
> 
> analog
>  V(out) <+ transition(x1, 5n, 5n) + transition(x2, 15n, 5n) + 
> transition(x3, 10n, 5n);
> 
> or (depending on the order of evaluation or the analog blocks):
> 
> analog
>  V(out) < + transition(x2, 15n, 5n) + transition(x3, 10n, 5n) + 
> transition(x1, 5n, 5n);
> 
> Then I'm confused: what does the paragraph from section 4.4.9 that 
> mentions deleting pending transitions refer to?
> 
> Cheers,
> Marq
> 
> 
> Marq Kole
> Competence Leader Robust Design
> 
> Research
> NXP Semiconductors
> 
> 
> _
> 
> 
> 
> 
> *
> "Martin O'Leary" <oleary@cadence.com>*
> 
> 23-01-2007 16:28
> 
> 	
> To
> 	"Marq Kole" <marq.kole@nxp.com>
> "verilog-ams" <verilog-ams@eda-stds.org>
> cc
> 	
> Subject
> 	RE: transition function
> Classification
> 	
> 
> 
> 
> 	
> 
> 
> _
> 
> 
> 
> 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 <http://www.mailscanner.info/>_ 
> <http://www.mailscanner.info/>*_MailScanner_* 
> <http://www.mailscanner.info/>*_*_, and is
> believed to be clean.
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by _* <http://www.mailscanner.info/>_ 
> <http://www.mailscanner.info/>* 
> <http://www.mailscanner.info/>*_MailScanner_* 
> <http://www.mailscanner.info/>*_*_, and is
> believed to be clean.
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by _* <http://www.mailscanner.info/>_ 
> <http://www.mailscanner.info/>* 
> <http://www.mailscanner.info/>*_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* <http://www.mailscanner.info/>, and is
> believed to be clean. _*

-- 
Srikanth Chandrasekaran
Design Technology (Tools Development)
Freescale Semiconductor Inc.
Ph: +91-120-439 7021 F: x5199

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.