2

For example in an unclocked process, all signals have to be set in every case to prevent latches from being implemented. But is this also the matter in a clocked process? I keep thinking this is not the case, but a friend of mine tells me I have to set all signals in all cases to prevent the synthesis from introducing latches even here.

Xiph
  • 23
  • 3

3 Answers3

2

A properly implemented clocked process will create registers where an unclocked process would create latches.

And registers are different from latches, especially in our ability to predict their timings; as well as being better supported in FPGAs, so this is usually a Good Thing.

"Properly implemented" means that ONLY Clock and (maybe) Reset) are in the sensitivity list.

  • Brian's answer is spot on, I just wanted to mention that the words "latch", "flip-flop", and "register" are often used interchangeably. To me, a "latch" is level sensitive but a "flip-flop" is edge sensitive, and a "register" can be either. If you have a clocked process, the inferred storage elements will use that clock specification. –  Nov 22 '13 at 13:08
  • Interesting, I always understood "register" to mean "n-wide flipflop" where n usually > 1. But the TTL Data Book does use "register" to cover both flipflop and latch. (74LS374 vs 74LS373) Perhaps usage has drifted since? –  Nov 22 '13 at 13:16
  • The use of level-sensitive registers is less common at the board and FPGA level these days, but latches are still smaller than flip-flops (if you are counting transistors) and high-performance IC designs with multi-phase non-overlapping clocks can make good use of them (as an example). –  Nov 22 '13 at 13:22
  • Certainly if you are working in a tech that supports multi-phase clocks, then yes, latches are still a viable option. I think I rather shocked a recent graduate by suggesting their use... –  Nov 22 '13 at 13:28
  • A register file can be comprised of D latches. The term [register](http://whatis.techtarget.com/definition/register) has a computer architecture meaning implying 'storage'. IEEE Std 1076.6-2004 denotes the classes of storage as 'edge-sensitive storage' and 'level-sensitive storage'. Note that we generally give a wider meaning to register than the linked reference, special purpose or I/O registers can be uncoupled from the instruction size. –  Nov 22 '13 at 22:24
1

I was surprised recently because the following code produces latches, even though only clock and reset are on the sensitivity list:

library ieee;
use ieee.std_logic_1164.all;

entity unwanted_latches is
    port (
        clock: in std_logic;
        reset: in std_logic
    );
end;

architecture rtl of unwanted_latches is

    function update_vector(vector: std_logic_vector) return std_logic_vector is
        variable return_value: std_logic_vector(vector'range);
    begin
        return_value := vector;
        return_value(0) := not return_value(0);
        return return_value;
    end;

    signal my_vector: std_logic_vector(7 downto 0) := (others => '0');

begin

    update_my_vector: process (clock, reset) begin
        if reset then
            my_vector <= (others => '0');
        elsif rising_edge(clock) then
            my_vector <= update_vector( my_vector );
        end if;
    end process;

end;

The exact message output by Quartus 12.1 is:

Warning (10631): VHDL Process Statement warning at unwanted_latches.vhd(25): inferring latch(es) for signal or variable "my_vector", which holds its previous value in one or more paths through the process

So, my strict answer to your question would have to be: yes, a clock process can introduce latches. But I'm more inclined to agree with @MartinThompson that this is a tool problem.

rick
  • 1,626
  • 11
  • 18
  • OK. So it at least messed up on the warning. Did you check the netlist? Is there actually a latch there? It is an error and you should report it. – Jim Lewis Nov 22 '13 at 18:37
  • This is a stripped-down example and it shows no latches on the netlist viewer. However, my actual project is larger, and there I see real latches. Altera is aware of the problem - it happens when the process has an asynchronous reset, and some of the bits remain constant. Here's [what they say](http://bit.ly/1fsxBwa): _Due to a problem in the Quartus® II software, you may see this warning if your code implements an incrementer or decrementer with an asynchronous reset where some of the bits remain constant. [...] It is safe to ignore the warning in this case as no latches are implemented._ – rick Nov 22 '13 at 20:37
  • Thanks for providing the Altera link for **Warning** (10631). "It is safe to ignore the warning in this case as no latches are implemented." The point Jim was trying to focus on. –  Nov 22 '13 at 21:56
  • 1
    Sounds like you are getting the hardware you need. I file this under synthesis tool humor. My favorite (maybe historic) has to do with a case statement: "Warning: Ignoring others because all conditions are specified". Seeing this warning one might wonder, what do they do if I leave the others off: "Error: Missing others with case statement". :) – Jim Lewis Dec 15 '13 at 19:47
0

Sounds like there may be a terminology issue...

  • Flipflops are edge-triggered storage elements
  • Latches are level-sensitive storage elements

You can't get a latch in a clocked process that's done right - just the clock in the sensitivity list (and if the reset is asynchronous, that too). Any tool which produces latches from that description is broken.

(I guess it's possible that, in olden times, you might get flipflops that you didn't want if you didn't initialise signals that weren't supposed to the made into flipflops, but there's a lot of ancient but wrong "lore" around where VHDL is concerned)

Martin Thompson
  • 16,395
  • 1
  • 38
  • 56