From: Steven Sharp (firstname.lastname@example.org)
Date: Wed May 01 2002 - 15:08:33 PDT
>How cutting and pasting the code from each of our simulators where we
>handle the statement:
> assign a = foo[i];
There are a number of problems with that idea. First of all, it isn't
what the standard says to do. Second, it may give different answers in
different simulators, which is undesirable. Third, it may not give the
Continuous assignments never have side effects (unless they call a function
with a side effect). So if a simulator evaluates one unnecessarily, it
doesn't change the visible behavior. So it doesn't matter much that
some simulators may evaluate them more often than others do. But procedural
code can easily have side effects, such as printing or incrementing counters.
So any difference in how they treat this sensitivity will cause variations
in the "standard" behavior.
Another thing about not having side effects is that continuous assignments
don't have to worry about the value of i changing during evaluation. When
the evaluation reads foo[i] and later waits on foo[i], it is waiting for
a change to the same value that it read. This is not necessarily the case
with @*. Consider the code
for (i = 0; i < 16; i = i + 1)
out[i] = foo[i];
The foo[i] that it read includes foo through foo. However, at
the event control, foo[i] is foo, which is not a value that it read.
In fact it is out of range, so it is always x and will never change. So
waiting on foo[i] to change value is not the desired behavior for the @*.
To get correct combinational behavior requires waiting for any of foo
through foo to change. If foo is a vector, the standard ensures this
because it waits on all of foo. If foo is a memory, then we have a
The far greater flexibility of procedural blocks means that they can create
situations that the simulator never had to deal with for continuous assigns.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
sponsored by Boyd Technology, Inc.