Sensitivity list

I have been reading a Xilinx Application Note, no. 105, A CPLD VHDL
Introduction, and came across the following statement in relation to
VHDL Processes:
" ... a designer new to VHDL must remember that all processes run in
parallel. In order to process VHDL code, however, a compiler must still
decide when to evaluate the process in order to successfully simulate
and synthesise the code."

I understand why simulation requires a sensitivity list, but the
suggestion that synthesis requires the list does puzzle me as it seems
that the body of the process sufficiently defines the logic that is
needed.

It would be much appreciated if anyone in the group could please explain
to me what part, if any, the sensitivity list plays in synthesis. I
know that, in practice, you are unlikely to want to synthesise a design
without running a simulation but I would be interested in the answer
just the same.

Thanks,
Best regards,
John

John Monro

On Fri, 17 Jun 2005 17:46:39 +1000, John Monro
<> wrote:


>I understand why simulation requires a sensitivity list, but the
>suggestion that synthesis requires the list does puzzle me as it seems
>that the body of the process sufficiently defines the logic that is
>needed.

Your statement puzzles me far more than VHDL does.

VHDL's behaviour, and therefore the logic that synthesis must create,
is defined for simulation. If the simulation needs a sensitivity list,
then by definition so does the synthesis. The whole point is that
any synthesisable piece of VHDL should behave just the same in
hardware as it does in simulation (apart from physical time delays).
Don't let any synthesis vendor tell you different.

However, I think I see what you're getting at (and it's been discussed
here many times before). The killer answer is: by changing the
sensitivity list, you change the meaning of a process and therefore
you change the logic that would be required.

Sometimes people get frustrated by this because, for a given
*synthesisable* process, there is only one possible sensitivity
list for which the process is still sensibly synthesisable. But
of course this doesn't make the sensitivity list redundant.

For example, take a look at this 2-to-4-line decoder process:

decoder: process (A, ena)
begin
Y <= (others => '0');
case A is
when "00" => Y(0) <= enable;
when "01" => Y(1) <= enable;
when "10" => Y(2) <= enable;
when "11" => Y(3) <= enable;
when others => null;
end case;
end process;

For this to be meaningful for synthesis, there is no choice
but to make the sensitivity list "(A, ena)". So why not
get rid of it? Well, I would say that the first line of
procedural code
Y <= (others => '0');
is also essential for synthesis, and surely tools could infer
it automatically. But we don't do that, because we want our
VHDL to describe the functionality correctly for both
synthesis and simulation. The same argument should also
apply to the sensitivity list.

We could change the sensitivity list to have, for example,
only (A) in it; we would still have a legal, simulatable
piece of VHDL; but it would behave differently, and its
behaviour would be difficult or impossible to synthesise.

There *is* a very good case for a wildcard sensitivity
list similar to Verilog's "@*", but that is emphatically
not the same as letting the tools guess - it tells the
tools exactly what to do (add every input to the list).
Indeed, I think you'll find that the VHDL-200x fast-track
development is adding precisely that to the language.

In clocked processes, the sensitivity list is similarly
important to the code's meaning.

Remember that a process with a sensitivity list is exactly
equivalent to the same process code without sensitivity list
but with a corresponding "wait on ()" statement at the end.
The sensitivity list is not merely a clue to simulators about
how to schedule the simulation; it directly affects the
meaning of the code. The body of a process with a sensitivity
list most certainly is NOT sufficient to define its behaviour,
because the sensitivity list effectively adds a line of code
to the end of the process!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Hi,

I have read the post attentively.

Following question:

In my VHDL testbench I have a process without sensitivity list.
Within this process I call several procedures.
At a certain point one of the procedures gives back
a signal called "bypass_next_procedure".
How can I check this signal in my main process ? I mean
I have no sensitivity list!
Any suggestions ?

Rgds
André

process
begin
procedure_1(clock, data_out);
procedure_2(clock, data_out);
procedure_3(clock, data_out, bypass_next_procedure);

wait until rising_edge(clock);

-- This if-statement would require 'bypass_next_procedure' to
-- be in the sensitivity list, but I have a "wait" at the end
-- of the process (?!)
if bypass_next_procedure='0' then
procedure_4(clock, data_out);
end if;


procedure_5(clock, data_out);
wait;
end process;

ALuPin@web.de

My suggestion is, if you don't need 'bypass_next_procedure'
outside of your main process, declare it as a variable within the main
process. You really only __need__ a signal for communication between
processes.

Additionally, not having a signal in a sensitivity list doesn't mean you
can't read it. It just means the process won't trigger in response to a
change in the said signal. In your testbench main process you don't want
to react to a change in 'bypass_next_procedure'. Usually a test-bench
main process starts at simulation begin and terminates the simulation
when all tests have been completed (i.e. the process runs exactly once).

If you still want to keep 'bypass_next_procedure' as a signal in the
main process just add a 'wait for 0 ns;' after every assignment to
'bypass_next_procedure'. This will make sure that any following ifs etc.
read the updated value of 'bypass_next_procedure'

Hope this helps

Charles

Charles Gardiner

On 17 Jun 2005 04:18:41 -0700, wrote:

>In my VHDL testbench I have a process without sensitivity list.
>Within this process I call several procedures.
>At a certain point one of the procedures gives back
>a signal called "bypass_next_procedure".
>How can I check this signal in my main process ? I mean
>I have no sensitivity list!
>Any suggestions ?

I don't really see what you are trying to do, but here are
some general suggestions that may be useful...

1) Use variables. You can pass variables into and out of
procedures, and of course they update immediately.
Signals are the right mechanism for communicating
from one process to another. Variables are the right
mechanism for storing data within one process.

2) Don't forget that you can do
wait on some_signal;
ANYWHERE in a process that doesn't have a sensitivity list.
The wait will hang until there is an event on the signal.

3) It is very, very unusual for a sensitivity list to be useful
in testbench code.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Jonathan Bromley wrote:
> On Fri, 17 Jun 2005 17:46:39 +1000, John Monro
> <> wrote:
>
>
>
>>I understand why simulation requires a sensitivity list, but the
>>suggestion that synthesis requires the list does puzzle me as it seems
>>that the body of the process sufficiently defines the logic that is
>>needed.
>
>
> Your statement puzzles me far more than VHDL does.
>
> VHDL's behaviour, and therefore the logic that synthesis must create,
> is defined for simulation. If the simulation needs a sensitivity list,
> then by definition so does the synthesis. The whole point is that
> any synthesisable piece of VHDL should behave just the same in
> hardware as it does in simulation (apart from physical time delays).
> Don't let any synthesis vendor tell you different.
>
> However, I think I see what you're getting at (and it's been discussed
> here many times before). The killer answer is: by changing the
> sensitivity list, you change the meaning of a process and therefore
> you change the logic that would be required.
>
> Sometimes people get frustrated by this because, for a given
> *synthesisable* process, there is only one possible sensitivity
> list for which the process is still sensibly synthesisable. But
> of course this doesn't make the sensitivity list redundant.
>
> For example, take a look at this 2-to-4-line decoder process:
>
> decoder: process (A, ena)
> begin
> Y <= (others => '0');
> case A is
> when "00" => Y(0) <= enable;
> when "01" => Y(1) <= enable;
> when "10" => Y(2) <= enable;
> when "11" => Y(3) <= enable;
> when others => null;
> end case;
> end process;
>
> For this to be meaningful for synthesis, there is no choice
> but to make the sensitivity list "(A, ena)". So why not
> get rid of it? Well, I would say that the first line of
> procedural code
> Y <= (others => '0');
> is also essential for synthesis, and surely tools could infer
> it automatically. But we don't do that, because we want our
> VHDL to describe the functionality correctly for both
> synthesis and simulation. The same argument should also
> apply to the sensitivity list.
>
> We could change the sensitivity list to have, for example,
> only (A) in it; we would still have a legal, simulatable
> piece of VHDL; but it would behave differently, and its
> behaviour would be difficult or impossible to synthesise.
>
> There *is* a very good case for a wildcard sensitivity
> list similar to Verilog's "@*", but that is emphatically
> not the same as letting the tools guess - it tells the
> tools exactly what to do (add every input to the list).
> Indeed, I think you'll find that the VHDL-200x fast-track
> development is adding precisely that to the language.
>
> In clocked processes, the sensitivity list is similarly
> important to the code's meaning.
>
> Remember that a process with a sensitivity list is exactly
> equivalent to the same process code without sensitivity list
> but with a corresponding "wait on ()" statement at the end.
> The sensitivity list is not merely a clue to simulators about
> how to schedule the simulation; it directly affects the
> meaning of the code. The body of a process with a sensitivity
> list most certainly is NOT sufficient to define its behaviour,
> because the sensitivity list effectively adds a line of code
> to the end of the process!

Jonathan,

Thanks for the very comprehensive reply. As a relative beginner in VHDL
I try to relate everything to my hardware experience, and your reply
has helped me do that. My question was to aid my understanding of the
processes and I agree that there would be no point in having different
code for the simulation and for the synthesis.


Regards,
John

John Monro

writes:

> How can I check this signal in my main process ? I mean
> I have no sensitivity list!

The signal assignment ist supposed to take place at the next
`wait'-statement.

BTW: A process using `wait' *can't* at the same time have a
sensitivity list.

-- Marcus

Marcus Harnisch