From: Michael McNamara (mac@verisity.com)
Date: Wed May 01 2002 - 17:06:52 PDT
Precedence: bulk
Steven Sharp writes:
>
> >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
> desired behavior.
>
> Continuous assignments never have side effects (unless they call a function
> with a side effect).
But isn't that a side effect? One can not be half pregnant.
Everything that can be in a function, can also be in a procedural
code block.
> 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.
Again, a fucntion can be in a continuous assign, so you can tell how
a given simulator executes a given continuous assign, which could be
useful for implementing toggle or code coverage tools by the way...
> 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
>
> always @*
> for (i = 0; i < 16; i = i + 1)
> out[i] = foo[i];
>
> The foo[i] that it read includes foo[0] through foo[15]. However,
> at the event control, foo[i] is foo[16], 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[0] through foo[15] 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 problem.
This actually is a very good example... Where were you that day we
passed this feature??? :-) [You very well may have been on the call,
but the question from Dennis of Xilinx was the precipitating event
that lead us to this question]
> 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 actually is the point of @* : to permit the user to create safe,
fairly complex continuous assignments using structures like for,
while, if, repeat; which can not be (easily) done today.
Let us think on this. Clearly we need to craft an errata, or at
least a common practise. From my compiler background, the way I
would implement @*, were I still writing Verilog simulators, is to do
a def-use analysis, to find the upwards exposed uses of variables and
put in the sensitivity list precisely these.
Given your quite good example, there are three variables that are in
the region of code guarded by the @*: i, out and foo.
There is no use of 'i' in the code region that isn't unambigously
defined by a statement in the code region that will be executed
before the use.
Nothing in 'out' is ever used by any statement in the code region.
The locations 'foo[0]' through 'foo[15]' are used, without having a
previous definition.
No other variable is used or defined.
Hence the right answer is to map 'always @*' to
'always @( foo[0] or foo[1] or ... foo[15] )'
Again, it is clear that it is completely unimportant what value 'i'
has before the block is entered.
Further, the block won't do anything meangingful if foo[216] changes.
If out[4] is changed by some other process, it is necessary that this
block not be run 'for the fun of it', overwriting this block.
> Steven Sharp
> sharp@cadence.com
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.