Latches in RTL – Why you should avoid on FPGAs

Latches inferred‘ – Often you should have come across this warning message (sometimes tons of these!) by FPGA Synthesisers while synthesising a design described in RTL. Most probably, latches have got inferred because somewhere in your RTL, you have a flawed combinational logic which failed to cover all conditions of input. These warnings have to taken as critical ones as latches are bad on FPGAs. They are bad because they may not work as simply as it looks like, or as intended. We will take a dive to find out why.

Case Study – Modelling a D-latch in RTL on FPGA

Let’s model a simple D-latch to understand how a latch behaves on FPGA. This is how a simple D-latch looks like:

D-latch

Boolean expression for Q^{+} = \overline{(\overline{(D \cdot C) + Q}) + (C \cdot \overline{D})}

K-map reduced expression for Q^{+} = \overline {C} \cdot Q + C \cdot D

Describe the expression in VHDL:

entity d_latch is

    port (
            d : in    std_logic  ; -- Data input, D
            c : in    std_logic  ; -- Latch-clock
            q : inout std_logic    -- Data output, Q
         ) ;

end d_latch;

architecture archi_d_latch of d_latch is

begin

   q <= ((not c) and q) or (c and d);

end architecture ;


Proceed to synthesis directly because Simulator cannot resolve the combinatorial loop on Q due to infinite triggering (same in Verilog/SV as well) …

I have used Vivado 2018.3 with Basys-3 board, and it didn’t pop-up any warnings interestingly … proceed to PAR and bit file generation with switches mapped to inputs and LEDs to output …

You should get DRC error as: combinatorial loop exists in your design, and hence it may produce unpredictable results due to unpredictable timing. We will talk about this error later. For the time being, let us safely bypass this error by flagging to Synthesiser and proceed at our own risk (I said ‘safely’ because this won’t fry the board or so!). Burn the bit file to the FPGA and observe the behavior of our D-latch.

Weird enough, the behavior should be looking like an AND gate with D and C as inputs, Q as output! The latch fails to store the last value at Q when C = 0 . So what went wrong!?

Static Hazards

The problem lies in the way we solved K-map expression.

D-latch K-map

The problem with this reduced expression is that, there is a static-1 hazard here.

This glitch of 0 at Q^{+} happens when there is a transition in the current state, [C, D, Q]: [0,1,1] \leftrightarrow [1,1,1] within the \color{orange} {orange} group shown below in the K-map. i.e., Q^{+} momentarily changes from 1 \rightarrow 0 and it in turns changes the ‘input’ Q (because it is fed back) from 1 \rightarrow 0 , right when the clock C changes from 1 \rightarrow 0 . This should be causing hold violation, and the latch fails to latch the value 1 which was at Q just before the clock transition.

Remove the Static Hazards

So, yea static hazards made the latch function like a mere AND gate. Let’s try to fix the hazard. Thanks to Huffman …

A theorem proved by Huffman tells us that by adding a redundant loop will eliminate the hazard

– Wikipedia

So if you add the redundant term (Q \cdot D) into the K-map expression (the group in \color{orange} {orange} color):

D-latch fixed K-map

The new hazard-free expression for Q^{+} = (\overline {C} \cdot Q) + (C \cdot D) + (Q \cdot D)

Describe the above expression in VHDL:

entity d_latch is

    port (
            d : in    std_logic  ; -- Data input, D
            c : in    std_logic  ; -- Latch-clock
            q : inout std_logic    -- Data output, Q
         ) ;

end d_latch;

architecture archi_d_latch of d_latch is

begin

   q <= ((not c) and q) or (c and d) or (q and d) ;

end architecture ;


Synthesise, PAR, and burn the bit file to FPGA. This should work as a D-latch now if you are lucky enough.

I said ‘lucky enough’ because I will like to draw your attention to the DRC error we bypassed on the way to the board. The above prototype works on an FPGA because it’s highly unlikely that you are causing any setup violations at the latch being tested; we humans are quite slow with switching of the inputs C and D . So, yea, we get away with it!

Takeaways

Most of the modern FPGAs don’t have hardened latch cells in the library. Hence, if modelled in RTL, they are synthesised naively using LUTs with combinatorial feedback loop. Designs with inherent combinatorial loops, for e.g., latches, cannot be properly synthesised/tested/validated by FPGA synthesisers. The feedback, clock, and data paths have to be properly timed for every latch to meet setup and hold times, which itself are unknown quantities here! Latches are hence highly unrecommended in RTL because of unpredictability and difficulty in timing validation.

So, Latches are as complex as how simple it looks – contradictory, but true!

Inspiration

This blog post is inspired from one of the discussions at Electrical Stack Exchange where a fellow user asked about the synthesisability of D-latch on FPGAs.

Thanks to him/her 🙂

Support

Leave a comment or visit support for any queries/feedback regarding the content of this blog.
If you liked Chipmunk , don’t forget to follow!:

Loading

2 COMMENTS

comments user
Katelyn

This is dataflow model. What if I infer latch in behavioral way????

    comments user
    chipmunk

    Good question. Most of the FPGAs nowadays don’t include real latches, so they will still infer the latch on LUTs, not any dedicated macro cells. So all the pointers about the timing requirement of the dataflow model apply in this scenario as well. But if modelled in behavioural way, you can simulate the model without infinite triggering.

Queries?! Leave a comment ...

Proudly powered by WordPress | Theme: HoneyPress by SpiceThemes