Difference between two process

M

Mad I.D.

I'm having some problem understanding process sensitivity list.

This is the process for latch with positive gate and asynchronous
clear from XST Manual
process (CLR, D, G)
begin
if (CLR=’1’) then
Q <= ’0’;
elsif (G=’1’) then
Q <= D;
end if;
end process;
end archi;

This is the process for latch with inverted gate and asynchrounous
preset (XST Manual)
process (PRE, G)
begin
if (PRE=’1’) then
Q <= "1111";
elsif (G=’0’) then
Q <= D;
end if;
end process;
end archi;

In both: D-data, G-gate...CLR Clear, PRE-preset

I know that this is the original code for inferring macros, but it
puzzles me why is the sensitivity list different? In the first process
there is 'D', and in the other there is no. Can someone please explain
some deeper meaning of the difference :) ?

Thank you very much.
Electronics engineer student
Katholieke Universiteit Leuven, Belgium
 
M

Mad I.D.

/cut

Addition : I tried synthesize both and D should be in both. Bug in XST
Manual.

So I will change my question: Why is D signal in the sensitivity
list ? It makes no sense to me. It puzzles me because if this was a
flip-flop (not a latch) D would be omitted.
 
Joined
Mar 10, 2008
Messages
348
Reaction score
0
Well its surely a fault to omit D in the sensitivity list.

The reason why D should be there in the first place shoud be found in the nature of the D-Latch

Once the Latch active (open) will the output (Q) follow the the input (D).
In order to obtain this must D be able to trigger the process.

This not the case for a Flip/Flop - here will only a rising or falling edge caurse the Q to take the value of D.

Hope it explained your question
Jeppe
 
K

KJ

I'm having some problem understanding process sensitivity list.

This is the process for latch with positive gate and asynchronous
clear from XST Manual
process (CLR, D, G)
This is the process for latch with inverted gate and asynchrounous
preset (XST Manual)
process (PRE, G)
In both: D-data, G-gate...CLR Clear, PRE-preset

I know that this is the original code for inferring macros, but it
puzzles me why is the sensitivity list different? In the first process
there is 'D', and in the other there is no. Can someone please explain
some deeper meaning of the difference :) ?

The lack of 'D' in the sensitivity list is a mistake. In fact if you
synthesize a design with the second one and peruse the warnings you
should see something to the effect that the sensitivity list is
incomplete and it (the synthesis tool) is assuming completeness. What
that means is that the actual design will be implemented as if the
sensitity list did include 'D' (i.e. "process (PRE, D, G)").

At first glance this might seem to be a 'good' thing since the tool
made a correct assumption about what you probably intended in the
first place and it did generate a warning telling you what it was
doing. After thinking some more about this, you could also conclude
that "Hey, I don't need to put *any* signals in the sensitivity list"
because the tool will detect which signals 'should' be there and
generate the appropriate logic [1] and just pop out a few more
warnings...no big deal, right?

The problem is that by doing so, the synthesis tool is violating the
language specification...it is not conforming to the definition of the
language [2]. The reason that this becomes a problem is when you use
any other tool other than a synthesis tool, most specifically a
simulator...they will not do this for you, and there will be no
'warning' because the simulator is quite capable of simulating exactly
what is written it has no reason to assume that you made a mistake in
your sensitivity list (maybe you really don't want the process to wake
up on changes in 'D').

Take the process you described above with 'D' missing and start up a
simulator. Initialize it with 'PRE' if you'd like, then set 'PRE' to
'0' and set 'G' to '1'. The logic is now set up to pass the data from
'D' to 'Q'. So try toggling 'D' back and forth, guess what? 'Q'
doesn't do anything. The reason is because from the simulator's
perspective, the process does not depend on 'D' since it's not in the
sensitivity list. The code will only start executing when there is a
change on either 'PRE' or 'G'. Now try simulating the output VHDL
file that popped out of the synthesis tool that repreesents the actual
implementation. Since the synthesis tool made the assumption that it
should complete the sensitivity list for you, that design will
simulate how you think it should (i.e. changes on 'D' will propogate
to 'Q').

Now ask yourself, when would you ever want to put yourself in the
situation that your original source code simulates differently then
the final implementation? The answer, I hope is 'Never'. That's why
sensitivity list warnings should always be 'cleaned up'. In fact a
better approach when designing with FPGAs or CPLDs is to only use
synchronous processes (i.e. clocked by the rising edge of a clock
signal), never use latches or other combinatorial processes so as to
completely avoid this easily avoidable design problem[3].

Probably more than you wanted to know about sensitivity lists but
since you're an engineering student it's not more than you will
eventually *have* to know to be effective at designing if that's your
goal.

As for your follow up question on why 'D' is not needed for a flip
flop, to expand a bit on Brian's reply, remember that a flip flop
output does not change when the 'D' input changes, it only changes
when you get a rising edge on the clock input. Once that rising edge
occurs, the flip flop 'takes a look' at the 'D' input and put whatever
it finds out on 'Q'. But the thing that triggers the flop is the
clock input...hence 'clock' is the only signal in the sensitivity
list. If you have a flop with an asynchronous reset or preset though,
the signal that causes the flop to reset or preset would also be
listed. Again though the reason is because when 'reset' goes active,
the flop immediately responds and sets 'Q' to '0'.

Kevin Jennings

[1] Actually an empty sensitivity list should be flagged as an error,
but you could also get away with putting *any* signal (even one that
is completely irrelevant to the process.
[2] Tools that conform to VHDL-2008 will allow you to say "process
(all)" (or some syntax like that) so you can conform to the language
and yet not have to worry about maintaining sensitivity lists (which
is a chore).
[3] The implementation of combinatorial processes are subject to
timing issues when a latch is created, whether this latch was
intentional or unintentional. Unintentional latches occur when there
is the potential path through the process that does not assign a value
to a signal that is an output of that process.
 
M

Mad I.D.

/cut

Thank you very much for this excellent explanation !
And thank you Brian Drummond.


Greeting from Croatia (right now :))
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top