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.
Received on Tue Jan 23 02:10:21 2007