Latch inference when default is missing in case statement

[We Ech Dee Ell]

Dear Group,

It is said that if default statement is missing in case statement,
then a latch is inferred.
But I am not able to understand this.

What is meant by latch inference? and why would a latch be inferred if
case statement does not have default statement.
If some cases are missed and default is also not there in a case
statement, then it should simply read 'x' or '-' for those cases.
Why is this latch inference coming into picture?

Please help.

Thanks

 

[We Ech Dee Ell]

I also found a related article :
http://www.asic-world.com/verilog/verilog_one_day2.html

But it does not explain WHY?

 

[Tricky]

I also found a related article :http://www.asic-world.com/verilog/verilog_one_day2.html

But it does not explain WHY?

This is only a problem if you have asynchronous logic. Synchronous
logic will never create latches (because you are always creating
registers).

the problem comes because if you dont define what happens in all
states, then you are asking the circuit to remember a state. look at
the following code:

process(ip, a)
begin
if ip = '1' then
op <= a;
end if;
end process;

now, the output only changes when "ip" = '1'. when "ip" = '0' then op
holds it's state. This is a latch. to prevent the formation of
latches, you must provide paths for all states:

process(ip,a,b)
begin
if ip = '1' then
op <= a;
else
op <= b;
end if;
end process;

Here we have created a mux, so no latches are required.

 

[KJ]

What is meant by latch inference?

It means that a transparent latch will be created based on the logic
in the source code. A transparent latch is something of the form...

process(C, D)
begin
if (C= '1') then
Q <= D;
end if;
end process;

This is just one example

and why would a latch be inferred if
case statement does not have default statement.

Because the definition of the VHDL language (and most others) is that
unless specifically assigned, a signal does not change values. In the
above example, if 'C' is not equal to '1' then signal 'Q' will not be
updated because the 'Q <= D' statement will not be executed.

If some cases are missed and default is also not there in a case
statement, then it should simply read 'x' or '-' for those cases.

What should 'read' 'x' or '-'? Then ask yourself why? If the last
value that was assigned to signal 'Q' in the above was '1', and now
'C' is no longer equal to '1', then wouldn't you expect 'Q' to retain
the value of '1'? Not 'x' or '-'.

KJ

 

[Andy]

The idea of an HDL description that requires "remembering" the state
of a signal will generate a latch is spot-on. Anytime a combinatorial
process executes but somehow avoids assigning an output, it must
remember the previous value of the output.

Rather than focusing on defaults in case statements and else's for
every if, there are two simple coding rules for avoiding latches:

1. Avoid combinatorial processes; use clocked processes instead.
Clocked processes cannot create latches.

2. If you have to use a combinatorial process, create default
assignments to every signal/variable driven by the process right up
front, before any conditional statements, etc., so that every
execution will result in assigning a value to them, and nothing needs
remembering. This is far simpler to remember, write, and review than
rules about else's for every if, defaults for every case, etc.

Taking the example provided, and applying rule #2:

process(ip,a,b)
begin
op <= b; -- default assignment
if ip = '1' then
op <= a;
end if;
end process;

In this trivial example, the benefits of this approach may not be
apparent. But how difficult would it be if you had multiple outputs,
and multiple levels of if-statement logic, to determine whether or not
there was an execution path that avoided assigning something to one of
those outputs?

Note that the default assignment could be to '0', '1', b, 'X', etc. Do
not use op <= op, for obvious reasons.

Note also that assignments to 'X' or '-' may not simulate as expected
(or like the hardware may behave) if you are subsequently checking to
see if op = '1' or similar.

Andy

 

[We Ech Dee Ell]

Thanks All, your answers made it very clear to me.
But I just had one more doubt while reading the replies above.

Why do only asynchronous logic create latches and not the synchronous
ones?
A small example like the ones above would be really appreciated.

 

[Tricky]

Thanks All, your answers made it very clear to me.
But I just had one more doubt while reading the replies above.

Why do only asynchronous logic create latches and not the synchronous
ones?
A small example like the ones above would be really appreciated.

Techincally, a synchronous register is a latch. Just in this case the
data is remembered when the clock changes from 0 to 1 (or vice versa
if its falling edge). But because this is such a useful concept FPGAs
are filled with them. Other types of latches are more custom but are
made out of logic gates and therefore timing between them cannot be
analysed (like it can from register to register)

A D-type can be made from 4x nand gates. See here:
http://www.play-hookey.com/digital/d_nand_latch.html

 

[KJ]

Thanks All, your answers made it very clear to me.
But I just had one more doubt while reading the replies above.

Why do only asynchronous logic create latches and not the synchronous
ones?

Well, as Tricky mentioned, registers can also be considered latches as
well...but I think what you're looking for is a bit more practical
answer for why.

The short answer though is that what you've stated is somewhat
backwards. The answer to the question "Why do only asynchronous logic
create latches and not the synchronous ones?" is "Latches are used to
implement combinatorial processes that feedback on themselves whereas
registers are used to implement edge sensitive processes." The more
detailed answer is coming up.

A small example like the ones above would be really appreciated.

The following code might not be the typical form one sees for a latch
or a register, but it was chosen to illustrate the point.

[1] y <= x when (C = '1'); -- Example of code that creates a latch:
[2] y <= x when (C = '1' and C'event); -- Example of code that creats
a flip flop:

Obviously, the only source code difference between [1] and [2] is the
inclusion of "C'event". VHDL defines that C'event equates to 'any
time signal C changes'. Focusing just on synthesis of digital logic
here, the phrase 'any time signal C changes' means that signal C must
have
- Changed from a high to low (i.e. 1 to 0)
- Changed from a low to high (i.e. 0 to 1)

So now one can say that "C = '1' and C'event" equates to "C is 1 and C
has changed from either low to high or from high to low". But if "C
is 1" is true, then obviously C must have changed from low to high.
So now you can look at the condition "C = '1' and C'event" and
conclude that C must have had an a rising edge occur.

Now look at the condition in [1]. Here you don't have the "C'event"
condition, it is simply "C = '1'". This is true whenever signal C is
high (i.e. a logic 1). This condition *starts* at the rising edge of
C, but it is not a small interval of time, rather it is true frmo the
rising edge of C up to the point where the falling edge of C occurs.

Now look at the left part of the assignment in [2], "y <= x" in
addition to what you now now about the "C = '1' and C'event" logic.
What this means is that the signal x will only be copied over to y
during the small interval of time when the rising edge of signal C is
occurring. The digital logic primitive that samples a signal at the
rising edge of some other input signal and stores that result is a
flip flop (also known as register).

Now look at the left part of the assignment in [1], "y <= x" in
addition to what you now now about the "C = '1'" logic. What this
means is that the signal x will only be copied over to y during the
interval when signal C is high. In particular, if C is high, then any
change to x will immediately show up on y, you don't need to wait for
a rising edge on C. The digital logic primitive that samples a signal
as long as some other input signal is high and stores that result is a
transparent latch (or simply a latch).

To bring it all around to wrap it up then, it is simply the appearance
of the C'event in an outermost "if" statement in a process [3] that
causes the synthesis software to say "Ah ha! I need to put in a flip
flop here". Since a flip flop is chosen, the process is a synchronous
process. If a process does not have a C'event in an outermost "if"
statement, rather just a "C = '1'" form that causes the synthesis
software to say "Ah ha! I need to put in (or cobble together from
logic) a transparent latch here". Since a latch is chosen, the
process is a combinatorial process.

The pattern matching on the source code by the synthesis tool that
results in what I called "Ah ha!..." is typically called inferring.
Therefore, one can look at things like [1] and say something like
"synthesis will infer a latch to implement [1]" and "synthesis will
infer a flip flop to implement [2]"

Kevin Jennings

[3] The C'event can also be obscured somewhat. The preferred form
for writing a clocked process would use "if rising_edge(C) then...".
The IEEE standard libraries define the function "rising_edge" and that
definition includes the C'event. It is slightly more complicated than
just "C = '1' and C'event" but that complication has to do with
simulation (where metavalues of 'X', '-', 'Z' are valid) not synthesis
(where the value of any signal is either 0 or 1.

 

[Andy]

Well said, with enough detail to show how things really work.

To simplify it a little, a "clocked" or "Synchronous" process only
updates on the edge of a clock signal (with the possible addition of
an asynchronous reset). Therefore any "memory device" the process
infers is of an edge-sensitive type, which is a flip flop.

A combinatorial process updates when any of the inputs change
(assuming they are correctly included in the sensitivity list), and
therefore memory elements that the process infers are level-sensitive,
which are latches.

Andy