/bbs/pub/verilog-ams: Re: transition function

From: Marq Kole <marq.kole_at_.....>
Date: Wed Jan 24 2007 - 02:14:44 PST

Just did that - it ran as predicted (after adding a couple of missing "end" keywords and a semicolon). Kudos for your modelling skills :-)

Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors

Jonathan David <j.david@ieee.org>

Sent by:
owner-verilog-ams@server.eda.org

24-01-2007 10:57

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

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.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Wed Jan 24 02:15:07 2007