Glad my example could help.. may be we should run it thru a simulator before we get to press.. :) Jonathan David j.david@ieee.org jb_david@yahoo.com http://ieee-jbdavid.blogspot.com Mobile 408 390 2425 Work: jbdavid@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: Wednesday, January 24, 2007 12:51:05 AM Subject: Re: transition function 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 Mobile 408 390 2425 Work: jbdavid@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 MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, 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 Wed Jan 24 01:57:57 2007
This archive was generated by hypermail 2.1.8 : Wed Jan 24 2007 - 01:58:11 PST