Why sensetivity list?

[valentin tihomirov]

What is the reason for sensetivity list? In HW all signals are in
sensetivity list. Surprisingly, complete sensitivity list may lead to
improper simulation results, especially for comb logic. Is it true? Why
simulator cannot do its job finding which signals should be in sensetivity
list?

 

[Mike Treseler]

valentin tihomirov wrote:

What is the reason for sensetivity list?

VHDL processes loop forever without a WAIT.
A sensitivity list entry is the conventional way
to imply a wait.

In HW all signals are in sensetivity list.

The only signals I ever put in a sensitivity
list are reset and clock.

Surprisingly, complete sensitivity list may lead to
improper simulation results, especially for comb logic.

Consider using the synchronous template
for your synthesis processes.



-- Mike Treseler

 

[valentin tihomirov]

It is often recommended to divide process into comb and reg parts. I would
do everything in a reg process; however, it seems impossible in synch
process to drive intermediate combinatoric signals for re-use. Therefore,
comb process is mandatory. As opposed to synch process launching on CLK and
RST, it often reacts on great number of signals.
Combinatoric process will not loop forever until you have an oscillating
asynch feedback. But declaring signals in sensetivity list do not prevent
the oscillation. Why simulator cannot do the task any synthesier must,
simulator's job is predicting behaviour of HW, isn't it? Thanks.

 

[Walter Dvorak]

valentin tihomirov <valentinNOSPAM@abelectron.com> wrote:

But declaring signals in sensetivity list do not prevent
the oscillation. Why simulator cannot do the task any synthesier must,
simulator's job is predicting behaviour of HW, isn't it? Thanks.

just my 2 euros: Because a (behavioral) vhdl-simulator
isnt perfect. The main stream like ModelSim require a complete
sensitivity list for a correct simulation. Maybe thats not valid for
all simulation tools. IMO that's more a program specific limitation.

i'm with you: In general the simulation tool *could*
do the same what the synthesis tool can do.

WD
--

 

[Jan Decaluwe]

valentin tihomirov wrote:

It is often recommended to divide process into comb and reg parts.

That's right - but not by those (perhaps a small minority) who
take the trouble to seriously compare code quality and quality
of results with the synchronous process based alternative.

I would
do everything in a reg process; however, it seems impossible in synch
process to drive intermediate combinatoric signals for re-use.

If you need to "re-use" the comb signal in the same module, you could
broaden the scope of your synchronous process (put more of the logic
in there). If it's in another module, you could broaden the scope of
the module (more hierarchy is not always better.) Otherwise, using
the comb signal in another module is not a good idea, as it creates
a combinatorial timing path between modules - hard to get right.

Therefore,
comb process is mandatory.

Only very occasionally, therefore.

As opposed to synch process launching on CLK and
RST, it often reacts on great number of signals.
Combinatoric process will not loop forever until you have an oscillating
asynch feedback. But declaring signals in sensetivity list do not prevent
the oscillation. Why simulator cannot do the task any synthesier must,
simulator's job is predicting behaviour of HW, isn't it? Thanks.

The task of an event-driven simulator is to correctly
execute an event-driven algorithm. That is a very general paradigm,
which is not specific to a particular kind of hardware, and in
fact doesn't even require that a hardware implementation is
possible.

If this sounds odd to you, remember that both Verilog and VHDL
were created as simulation languages years before the first synthesis
tools (with their subsets and limitations) for them came along.
At the time, it could not be foreseen that synthesis would
be viable and that the RTL level would be such a popular application.

Regards, Jan

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Mike Treseler]

valentin tihomirov wrote:

It is often recommended to divide process into comb and reg parts.

This is a matter of style.
There is no technical advantage to combinational processes.
I prefer having registers on all process outputs.

I would
do everything in a reg process; however, it seems impossible in synch
process to drive intermediate combinatoric signals for re-use.

Reuse might mean "used in the same project"
Any expression using the same combinational
input variable directly ought
to be in the same process. It is ok to
have lots of logic in a single process.

Reuse might mean "used in a future project"
The easiest piece of code to reuse is
the smallest testable unit, namely
a complete entity-architecture with a testbench.

-- Mike Treseler

 

[valentin tihomirov]

If this sounds odd to you, remember that both Verilog and VHDL
were created as simulation languages years before the first synthesis
tools (with their subsets and limitations) for them came along.
You're right! I'm starting to forget what that HDL achronim means.

 

[Jim Lewis]

Not an unreasonable request.

Consider the following concurrent statement. The
sensitivity list is automatically inferred to be
all signals read in the statement.

Y <= A when Sel = '1' else B ;

This is very similar to:

process(A, B, Sel)
begin
if Sel = '1' then
Y <= A ;
else
Y <= B ;
end if ;
end process ;


Currently for registers and non-RTL applications, an
incomplete senstivity list is useful.

In SystemVerilog they are introducing a modifier in
their processes (always blocks) that indicates that it
is combinational logic. A similar feature will be
proposed for VHDL. Translating the SV feature it will
make the above process look something like the following:

process_comb
begin
if Sel = '1' then
Y <= A ;
else
Y <= B ;
end if ;
end process ;

This is actually a cool feature as first it does not
require any maintence of the sensitivity list. Second
it increases safety as if you were to inadvertently
create a latch, it would result in an error in a synthesis
tool (very useful when you consider the combinational
logic portion of a statemachine).

The following code would create an error during synthesis:
process_comb
begin
if Sel = '1' then
ALat <= A ;
end if ;
end process ;

Please note that when we announce that VHDL-200X release
one has been made, make sure to tell your simulator and
synthesis tool vendor that you want it. All tool
improvements are market driven. If you don't ask they
don't consider it a good investment.

Best Regards,
Jim Lewis


VHDL-200X Fast-Track Co-Team Leader
VHDL-200X Modeling and Productivity Team Leader
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




valentin tihomirov wrote:

What is the reason for sensetivity list? In HW all signals are in
sensetivity list. Surprisingly, complete sensitivity list may lead to
improper simulation results, especially for comb logic. Is it true? Why
simulator cannot do its job finding which signals should be in sensetivity
list?

 

[Kumaran Selvaratnam]

Basically, like other postings mentioned sensitivity list denotes which
signals triggers the execution of the particular process.

This means
1. All combinational logic process sensitivity lists need to have all
the input signals
2. For a sequential logic it is sufficient enough to have the clock
signal (for synchronous reset case)
FOr asynchronous reset case, it is enough to have reset and clock
signals in the sensitivity list.

Kumaran

valentin tihomirov wrote:

What is the reason for sensetivity list? In HW all signals are in
sensetivity list. Surprisingly, complete sensitivity list may lead to
improper simulation results, especially for comb logic. Is it true? Why
simulator cannot do its job finding which signals should be in sensetivity
list?