std_logic_vector signals in sensitivity list process

[KJ]

I was wondering how the synthesis tool considers result_ready to be
"unconnected."
Doesn't
result_ready <= not (result_ready);
mean that result_ready is actually connected somewhere (to the input
of the inverter, in this case)?

It does only if the logic that depends on 'result_ready' has not been
optomized away because that logic doesn't affect a top level output pin.

Logic gets optomized away when there is not top level output pin of the
device that gets affected by any of the outputs of that logic. That doesn't
mean that the outputs of all entities necessarily need to be directly
connected to pins though since a signal could be the input to some other
logic that does affect an output pin.

As an example, let's say you write code for a free running counter and the
output of that entity is a simple pulse that goes active for one clock cycle
when the counter reaches 1000. Let's say that output then feeds into an
accumulator that when it sees this pulse, latches and holds it set until
some external read signal from an output pin is set (perhaps an external CPU
polling to see what the status is). In response to that read signal, the
accumulator outputs the result of the accumulator and then clears itself
when the read ends.

Now, the free running counter entity has no direct connection to any
external I/O pins but it affects logic that does have such a connection (the
accumulator). But let's say at the top level of your design you neglect to
connect the output pin of the counter entity to the input of the
accumulator. In that situation, the synthesis logic would see that the
counter logic can be optomized away since it doesn't affect any output pins
simply because you didn't connect things properly.

Or, presumably the free running counter has a clock input and a reset input.
What if you connect the reset to a constant that happens to be '1', or the
clock to a constant. Again, the whole thing gets optomized away.

In all of these cases, you can stare at your counter code all day looking
for something wrong that would explain why it is getting optomized away and
you won't find it because the problem is not with the counter code, but with
how that counter is being connected to other logic.

In any case, the way you go about finding these problems is to simulate. If
you do so, you should find that functionally the design is not doing what it
should be doing for some reason. Once you find that reason, run it through
synthesis again.

Kevin Jennings

 

[Ponceludon de Malavoy]

It does only if the logic that depends on 'result_ready' has not been
optomized away because that logic doesn't affect a top level output pin.

Logic gets optomized away when there is not top level output pin of the
device that gets affected by any of the outputs of that logic. That doesn't
mean that the outputs of all entities necessarily need to be directly
connected to pins though since a signal could be the input to some other
logic that does affect an output pin.

As an example, let's say you write code for a free running counter and the
output of that entity is a simple pulse that goes active for one clock cycle
when the counter reaches 1000. Let's say that output then feeds into an
accumulator that when it sees this pulse, latches and holds it set until
some external read signal from an output pin is set (perhaps an external CPU
polling to see what the status is). In response to that read signal, the
accumulator outputs the result of the accumulator and then clears itself
when the read ends.

Now, the free running counter entity has no direct connection to any
external I/O pins but it affects logic that does have such a connection (the
accumulator). But let's say at the top level of your design you neglect to
connect the output pin of the counter entity to the input of the
accumulator. In that situation, the synthesis logic would see that the
counter logic can be optomized away since it doesn't affect any output pins
simply because you didn't connect things properly.

Or, presumably the free running counter has a clock input and a reset input.
What if you connect the reset to a constant that happens to be '1', or the
clock to a constant. Again, the whole thing gets optomized away.

In all of these cases, you can stare at your counter code all day looking
for something wrong that would explain why it is getting optomized away and
you won't find it because the problem is not with the counter code, but with
how that counter is being connected to other logic.

In any case, the way you go about finding these problems is to simulate. If
you do so, you should find that functionally the design is not doing what it
should be doing for some reason. Once you find that reason, run it through
synthesis again.

Kevin Jennings

Thank you, Kevin, for that explanation. This is a really enlightening
thread!