Re: How do variables get synthesized in this case?

On Mar 16, 11:12 pm, kennheinr...@xxxxxxxxxxxx wrote:
Duke,

As has been mentioned, this code will get optimized away.  But what
you *might* have been asking (and I'm taking a shot in the dark here)
is, were you to have forced the simulator to explicitly keep the
process around, and trace what it did, what would you have seen? In
that case, the values you would see would be more or less consistent
with what you'd expect if x,y,z were plain ordinary variables in your
favorite imperative programming language (C or perl or whatnot) - the
fact that none of the values of any of the variables get re-used in
successive executions of the process means there's nothing
"interesting" going on from a synthesis point of view. By interesting,
I mean inferring latches or flip-flops.

And from a slightly more contrarian position: were "a","b" or "d" to

erratum: for "a","b", or "d" : read "b" or "d"



have been declared as impure 0-ary functions performing I/O (textio,
asserts, reports, etc), then one could argue that, from a *simulation*
point of view, that the process is not, in the strictest sense, navel-
gazing. But for synthesis, I concur with the majority opinion - your
code will simply vanish.

 - Kenn- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Ignoring the impacts of optimization (deleting unused outputs, and
everything that only drives them), there are some problems with the
code.

Specifically, z is not always assigned a value, which would result in
a latch were z not to be optimized out in the first place, whether z
were a variable or signal. Latches are an inherent risk in
combinatorial processes. The same situation in a clocked process
merely results in a clock disable on a register, and/or (with
variables) a mux between the input and output of the register, where z
might be referenced subsequently. Interestingly, the output of the
implied clock-disabling feedback mux, before the register input, is
exactly what is needed for successive references to the conditionally
assigned variable.

Because y is overwritten in each loop iteration, the whole loop
collapses to just the last iteration of the loop, ignoring the
previous iterations. This has nothing to do with signals vs variables.
The typical impact on truly iterative loops of variables vs signals is
that since signals do not get updated until the process suspends,
there is no real iteration upon signals inside a loop (assuming there
are no wait statements in the loop). Since variables do update
immediately, iteration upon the variable is possible, it is just not
demonstrated in the example. Just remember that all loops not
containing wait statements are simply unrolled during synthesis. Not
all synthesis tools can handle loops with wait statements (i.e.
waiting on the next clock edge), but that is probably beyond the
intended scope of discussion.

Because sensitivity lists are ignored in synthesis, the synthesis of x
is unrelated to variable vs signal behavior. Were x a signal, the
synthesis result would assume x were also in the sensitivity list, and
the resulting behavior would be identical to that of a variable x. In
simulation, if x were a signal, and included in the process
sensitivity list, it would cause the process to immediately run again
with the updated value of x, thus allowing propagation to the
subsequent references to x within the process.

So, in effect, most of the behavior of the code, even ignoring the
effects of optimization during synthesis, really does not have much to
do with variable vs signal behavior.

Andy

.

Relevant Pages

  • Re: How do variables get synthesized in this case?
    ... asserts, reports, etc), then one could argue that, from a *simulation* ... I missed seeing the loop in the def-use graph ... This has nothing to do with signals vs variables. ... there is no real iteration upon signals inside a loop (assuming there ...
    (comp.lang.vhdl)
  • Yow! LOOP macros are LOOPY!
    ... By relying entirely on procedure calls to express iteration, ... to but cleaner than C's FOR loop. ... other macros going around at the time other than MacLisp's ... (bind (vi (vector-ref v i))) ...
    (comp.lang.scheme)
  • Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions
    ... the terminology is less useful than it might be. ... though a "message loop" could arguably be claimed to be ... considering in a particular iteration but what is true for _ALL_ ... watching the "polling" version eating up every single CPU cycle ...
    (alt.lang.asm)
  • Re: Histogram of character frequencies
    ... generated object code may simply be a loop in which elements are ... believe any C compiler anywhere would reject it. ... On the first iteration of the loop you test the end of file indicator ...
    (comp.lang.c)
  • Re: AFP protocol
    ... if you are using an AUI connector. ... because it was using all fifteen signals ... cables were/are plenty flexible enough to make loops. ... ever saw the stuff was a loop pulled out of a wall (or was in down from ...
    (uk.comp.sys.mac)
Loading