Showing posts with label Latch. Show all posts
Showing posts with label Latch. Show all posts

Are latches really bad for a design?


It is not completely correct to say that we have to avoid latches in our designs. In one of our recent projects we went a good extent debating only the disadvantges of using latches and then we had to can all the latches because many were not convinced. There are cases where you can safely use latches, just that you have to be little careful and the designer needs to be really sure of the impending functionality. In this post lets look at all possible cases where latches are preferred and where they are not. If you think if any of the statements are wrong, lets have a healthy debate.

The bad guys (Please add more):
1. One of the main reasons that latches are not used in designs is due to combinational loop back and subsequent oscillation which creates super problems in simulation, and also simulation Vs synthesis mismatches.
2. Due to controllability issues in latches unlike FF's, they can significantly harm STA/DFT and thereby reduce coverage in both cases.
3. The major factor for the above uncontrollability are Glitches in the enable pin of the latches that can cause unrecoverable failure
4. Last but not the least.. :-) the biggest culprit of all... inferred latches after synthesis due to bad coding styles.

Advantages:
1. Latches consume less power and area compared to FF's
2. If the design is not power aware, FF's are prefered and almost all the latches could be replaced by FF's without affaecting functionality.
3. Remember that the decode of a latched address can begin before the latch is actually closed..:-)

Corrective Measures:
1. A glitch-free enable helps if latches are unavoidable.
2. If you are synthesizing the code that generates the enable, please consider the direct instantiation of the logic using gates that drives the enable to the latch. Now you can be double sure!
3. A good input hold time ensures that the data is held long enough before you close the latch. If your latch enable is derived from a clock, the latch will lag the clock, requiring the latch's D inputs to be held valid after the clock edge.

NOTE: The latch has a disadvantage of being "transparent" till the clock makes the latch the value of the input. The FF samples the input on the risinf or falling edge of the clock.

Bottomline:
If you are not careful.... when developing synchronous digital designs, latches can generate asynchronous circuits that become unstable.

"Latch" Vs "Flip Flop"


Welcome to the most popular title on this Blog ;-))))) !!!


A flip-flop is Edge sensitive: Output only changes on rising (or falling) edge of clock.
A latch is Level sensitive: Output changes whenever clock/Enable is high (or low)

A common implementation of a flip-flop is a pair of latches (Master/Slave flop).

Latches are sometimes called “transparent latches”, because they are transparent (input directly connected to output) when the clock is high.

The clock to a latch is primarily called the “enable”.

For more information have a look at the picture below.








Deprecated Hardware:

Latches:
  1. Use flops, not latches
  2.  Latch-based designs are susceptible to timing problems
  3. The transparent phase of a latch can let a signal “leak” through a latch — causing the signal to affect the output one clock cycle too early
  4. It’s possible for a latch-based circuit to simulate correctly, but not work in real hardware, because the timing delays on the real hardware don’t match those predicted in synthesis
Flip-flops:
  1. Limit yourself to D-type flip-flops
  2. Some FPGA and ASIC cell libraries include only D-type flip flops. Others, such as Altera’s APEX FPGAs, can be configured as D, T, JK, or SR flip-flops.

  • For every signal in your design, know whether it should be a flip-flop or combinational. Examine the log file e.g. dc shell.log to see if the flip-flops in your circuit match your expectations, and to check that you don’t have any latches in your design.
  • Do not assign a signal to itself (e.g. a <= a; is bad). If the signal is a flop, use an enable to cause the signal to hold its value. If the signal is combinational, then assigning a signal to itself will cause combinational loops, which are very bad.
If you are looking for code snippets for following types of harware, please leave a comment.
  1. Flops with Waits and Ifs
  2. Flops with Synchronous Reset
  3. Flops with Chip-Enable
  4. Flops with Chip-Enable and Mux on Input
  5. Flops with Chip-Enable, Mux's, and Reset