Is the use of records the solution to all latch problems in VHDL

Question

I was recently told that the solution to all (most) problems with unintended latches during VHDL synthesis is to put whatever the problematic signal is in a record.

This seems like it's a little bit too good to be true, but I'm not that experienced with VHDL so there could be something else that I'm not considering.

Should I put all my signals in records?

Answer 1

No, you should not put all your signals in records. This will quickly become very confusing and you will not gain anything by using the record.

One way that a record may help you avoid latches, is if you register an entire record in a clocked process, you are really registering all of the components of the record. This takes one line of code, instead of possibly tens of lines. In the case where you have many elements which all need to be treated the same, a record can save you "silly mistakes", and possibly save you from creating a latch.

As stated by others, a record doesn't have any specific synthesis interpretation. It is simply a group of signals that you are grouping together for coding-convenience.

Answer 2

I don't see how this would help - a record (or even just parts of a record) can become a latch just as easily as a signal. A latch is generated if a signal keeps its state through some combinatorial process (i.e., is not assigned a value on ALL paths through the process). The same holds for constituents of a record.

Records can be useful to group related signals for readability, but synthesis-wise a record is pretty much equivalent to a bunch of individual signals.

My personal suggestion to avoid latches: avoid combinatorial processes. Make all processes clocked, and do combinatorial logic at the architecture level.

Answer 3

A record is just another way of grouping other types, similar to using an array for grouping of a std_logic to std_logic_vector, so there is nothing magical about records that make them better for avoiding latches in a design.

If you get unintended latches in your design, what I guess you think of as "latch problems", it is because you coding style specifies latches, and you should change the coding style, as @zennehoy also suggests.

One approach can be to define some code templates for different constructions that you use, and then stick to these known and working templates.

The template for a flip-flop (FF) with asynchronous reset can be:

process (clk_i, rst_i) is
begin
  -- Clock
  if rising_edge(clk_i) then
    ... Control structures with Qs assign by function for Ds
    ... Synchronous reset is just another branch
  end if;
  -- Reset (asynchronous) if required
  if rst_i = '1' then
    ... Qs assign with constant reset value for so or all Qs
  end if;
end process;

Use concurrent signal assigns when possible, and more complex expressions can be done through use of concurrent function call, where a function is used outside a process like:

z_o <= fun(a_i, b_i);

If a process is used to create combinatorial logic, then a common pitfall and cause for latches in VHDL is to forget a signal in the sensitivity list. However, VHDL-2008 has a solution for this, since you can use (all) as sensitivity list, whereby all signal used in the process are implicitly included in the sensitivity list. So if you use VHDL-2008, then your template for combinatorial processes can be:

process (all) is
begin
  z_o <= a_i and b_i;
end process;

These template should be all you need for typical synthesizable design, and these will keep your design latch free.