These no else statements generate latches?

[fl]

Hi,

I have read that it should have complete IF THEN ELSE to avoid latches generated for FPGA application. But I find the following process which was generated from an automatic VHDL generating software.

Does this example have the danger to generate latch or not? Of course, I can implement it (it seems there is no latch yet). I would like to have a clear canalization to know the full story about it.

Thanks,







............
temp_process12_Delay_stepcnt : PROCESS (clk, reset)
BEGIN
IF reset = '1' THEN int_delay_pipe_1(0 TO 2) <= (OTHERS => (OTHERS => '0'));
ELSIF clk'event AND clk = '1' THEN
IF enb_1_1_1 = '1' THEN int_delay_pipe_1(0) <= dcnt;
int_delay_pipe_1(1 TO 2) <= int_delay_pipe_1(0 TO 1);
END IF;
END IF;
END PROCESS temp_process12_Delay_stepcnt;

 

[Andy]

On Tuesday, February 11, 2014 6:11:54 AM UTC-6, fl wrote:
> I would like to have a clear canalization to know the full story about it..

Perhaps you meant "canonization"?

This is perhaps the most mis-understood and ill-instructed concept of logic synthesis: the synthesis of storage, and more practically, how to avoid synthesizing a latch, which is a type of storage element.

Generally speaking, anytime a signal or variable is required to retain its value from a previous execution of the process that assigns it, a storage element is synthesized to remember that value.

Whether the storage is synthesized as a register or a latch is based on the conditions under which the previous value was stored. It if was stored only upon the edge of another signal, then a register is synthesized to hold the value. If not, then a latch is synthesized to hold the value.

How can one avoid unintentionally synthesizing a latch? Avoid having to remember a previous value that was not stored on a clock edge. Within most clocked processes*, it is impossible to synthesize a latch, because storage within them always occurs on a clock edge.

That leaves combinatorial processes. If you can avoid combinatorial processes, then your chances of synthezising latches reduce to zero*.

If you need or desire to use combinatorial processes, the oft-stated advice is to "add an else for every if". The problem is, this is neither necessary nor sufficient to avoid latches.

To avoid a latch in a combinatorial process, ensure that every execution path through the combinatorial process assigns a value to every signal or variable ever assigned by the process.

You could do that within else statements for every if statement, but that inspection for completeness during review is extremely difficult, because you still have to confirm that every signal/variable gets assigned at least somewhere for every possible path through the conditional statements.

A better approach for combinatorial processes is to provide default assignment statements for every signal and variable assigned by the process (note these assignments cannot simply assign a signal with its current value, or you defeat the whole purpose of avoiding latches.) Execute these default assignments right up front in the process, before any conditional statements could interfere with their execution.

When using variables exclusively for combinatorial logic within a clocked process, the same approach works to avoid inadvertently synthesizing a register from a variable (if that is forbidden in your organization or project). Just make sure every variable has a default assignemnt statement immediately folowing the "if rising_edge(clk) then" statement, but prior to any further conditional statements, and none of your variables will synthesize to a register either.

Notice a pattern here? It doesn't matter what kind of storage element you are trying to avoid, the rules are the same.

*There's always a catch... Within clocked processes, it is possible to define combinatorial outputs that are functions of registers represented by local variables. These combinatorial output signal assignments are placed within the process, but after the "end if" for the clock edge detection (just before the "end process" statement.) In this region, if a signal is only sometimes assigned, a latch can also be synthesized. If you have conditional statements in this region, then also include default assignments at the beginning of this region. If you don't use these types of outputs, then you don't have to worry about it.

Andy

 

[Brian Drummond]

On Tue, 11 Feb 2014 04:11:54 -0800, fl wrote:

Hi,

I have read that it should have complete IF THEN ELSE to avoid latches
generated for FPGA application. But I find the following process which
was generated from an automatic VHDL generating software.

Does this example have the danger to generate latch or not? Of course, I
can implement it (it seems there is no latch yet). I would like to have
a clear canalization to know the full story about it.

ELSIF clk'event AND clk = '1' THEN
IF enb_1_1_1 = '1' THEN int_delay_pipe_1(0) <= dcnt;
int_delay_pipe_1(1 TO 2) <= int_delay_pipe_1(0 TO 1);
END IF;
END IF;

No it won't implement latches, because the incomplete IF statement is in
a clocked process. So it will implement registers instead : if the
condition is false, the register will retain its current value.

I recommend simplifying to "if rising_edge(clk) then ..." but that is
less important.

In a different process without a proper clock expression, yes you could
get latches.

- Brian

 

[GaborSzakacs]

Brian Drummond wrote:

On Tue, 11 Feb 2014 04:11:54 -0800, fl wrote:

Hi,

I have read that it should have complete IF THEN ELSE to avoid latches
generated for FPGA application. But I find the following process which
was generated from an automatic VHDL generating software.

Does this example have the danger to generate latch or not? Of course, I
can implement it (it seems there is no latch yet). I would like to have
a clear canalization to know the full story about it.

ELSIF clk'event AND clk = '1' THEN
IF enb_1_1_1 = '1' THEN int_delay_pipe_1(0) <= dcnt;
int_delay_pipe_1(1 TO 2) <= int_delay_pipe_1(0 TO 1);
END IF;
END IF;

No it won't implement latches, because the incomplete IF statement is in
a clocked process. So it will implement registers instead : if the
condition is false, the register will retain its current value.

I recommend simplifying to "if rising_edge(clk) then ..." but that is
less important.

In a different process without a proper clock expression, yes you could
get latches.

- Brian

Just a clarification. The edge-triggered (clocked) process will create
registers whether or not there is an incomplete IF statement. However
the incomplete IF will cause the Q output of those registers to feed
back to the D inputs, or alternately use a clock enable to hold
the register's current state depending on the architecture you target.
For most FPGA's internal (fabric) flops this would not be an issue.
There are some cases like IOB flops where feedback or clock enables
might prevent the tools from placing the register in the IOB, or force
the tools to replicate the register to allow a copy without
self-feedback to be placed in the IOB.

--
Gabor