std_logic_vector signals in sensitivity list process

[Steven Kauffmann]

On Jan 4, 6:17 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

On Fri, 4 Jan 2008 00:32:21 -0800 (PST), Steven Kauffmann



steven.kauffm...@gmail.com> wrote:
On Dec 24 2007, 4:45 pm, kennheinr...@sympatico.ca wrote:
On Dec 24, 3:10 am, Steven Kauffmann <steven.kauffm...@gmail.com
wrote:
Because I thought that a sensitivity list wakes up a process when
there's an event on the signals in its list. I write the following
process.

process(output_complex_algorithm)
begin
result_ready <= not(result_ready);
end process;

I thought that when the output of the complex algorithm changed, the
result_ready signal would also change because of the sensitivity list.
This is not working in hardware. The reason for that, I think, is that
the signal output_complex_algorithm is not used in the process, only
in the sensitivity list. The sensitivity list is not a comparator but
these signals are directly connected with some logic as you said. But
because I don't use the signals in the sensitivity list, it's not
working. Is this correct what I'm saying?

As KJ says, this is certainly valid VHDL and should do what you expect in
simulation.

But the trouble is that synthesis tools cannot generally translate VHDL into
hardware (this is equally true for all the hardware-C efforts out there; any C
or C++ construct capable of translation into hardware already has a VHDL
equivalent.) Now some of these limitations are due to the current state of the
synthesis tools (whether VHDL or other) but some are fundamental to what is
achievable in hardware.

KJ also wrote something about the synthesize warnings: incomplete
sensitivity list and combinatorial loop.
I receive the warning about the combinatorial loop but not about about
the incomplete sensitivity list. During the place and route process I
receive errors that the signal result_ready is going to be trimmed. If
I turn off the option "trim unconnected signals" the error disappears.
But I don't know if this is a good solution to solve the problem.

The upshot is that, for synthesis, you need to "think hardware" first and
foremost, and create something that WILL synthesise. Then and only then, worry
about the sensitivity list to provide the simulator with information to make the
simulation behaviour match the real hardware.

Again as KJ says, the "clean" way in this case is for "complex_algorithm" to
provide a data_valid signal.

But assuming it cannot, (e.g. it's someone else's code) we have to find a way
around the problem.

As you already mentioned, a data_valid signal is the best solution but
not always possible. Because the code of the complex algorithm is not
written by myself, I prefer not to edit it.

Which is to detect and announce changes in the output from "complex_algorithm".

Thinking hardware; you are right that a comparator is part of the solution. But
we are detecting changes in the output; therefore comparing the output with an
old copy of the output will work.

You also said that "complex_algorithm" took an unknown number of clock pulses;
implying it is a clocked component, so assume it produces at most one result per
clock. (Two per clock is possible; let's not discuss that here!) Therefore we
can use the same clock to clock a storage element for our "old copy".

Like some others already mentioned, a comparator is not always a good
idea because in some cases it won't see a change. In my design such
cases are not ok. I have to see every change, even when the result of
the output is the same as the previous one.

But after reading this thread, I think I have to choose between two
thinks.

1) Adding a data valid signal (best solution but also requires the
most effort because the code is not written myself).

2) Using a comparator and keep in mind that this solution has some
limitations.

[...]

Sorry if this is a bit pedantic, but I hope that the step by step approach makes
it clear.

It's clear for me and is very useful.

Thank you all

 

[Mike Treseler]

Steven Kauffmann wrote:

During the place and route process I
receive errors that the signal result_ready is going to be trimmed. If
I turn off the option "trim unconnected signals" the error disappears.
But I don't know if this is a good solution to solve the problem.

Any signal or variable that does not
affect an output port is ignored for synthesis.
If the signal "result_ready" is just used for debug,
ignore the warning.
Otherwise, use it to drive a handshake output port.

As you already mentioned, a data_valid signal is the best solution but
not always possible. Because the code of the complex algorithm is not
written by myself, I prefer not to edit it.

I would write a testbench for the "complex" entity,
make the addition, and verify that that everything
still works. If I decide to use existing code,
it becomes my responsibility to maintain it.

1) Adding a data valid signal (best solution but also requires the
most effort because the code is not written myself).

It might not be more effort in the end.
That code has bitten one, and may bite again.


-- Mike Treseler