disadvantages of inferring latches

Hi all,

I always hear from FPGA designers that latches are "dangerous" and that it'=
s very important avoiding them. I wonder what are the technical risks resul=
ting by using latches. As far as I understand, the main problem is that FPG=
As don't have built in hard latches so the synthesizer has to implement it =
from logic blocks and then the race condition in the resulting logic is har=
d/impossible to be analyzed.
Is this main disadvantage latches? are there any other issues regarding lat=
ches which shall be considered?

Thanks,

Ron

On 11/17/2014 4:17 AM, ronhk25 wrote:
> Hi all,
>
> I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed.
> Is this main disadvantage latches? are there any other issues regarding latches which shall be considered?

It is not that latches are inherently bad.  The problem is that they can 
be inferred unintentionally.  The only time I remember using a latch in 
a design was way back when the 8085 CPU was around.  I recall that they 
multiplexed the address with the data or with itself (upper/lower) and 
to get the best address setup time a latch was used, 74LS373 rather than 
the 74LS374 register.  The address would flow through ahead of the edge 
of the clock that would hold it giving more address setup time.

I believe that most programmable logic will implement latches ok.  I'm 
not sure what race condition you are referring to.  The only problem I 
can see is that if you use them in the wrong place they will let signals 
flow through successive latches rather than holding like registers will 
do.  Oh yes, the static timing analysis program is incapable of 
calculating any timing analysis on them, so that is a real problem.

I have never needed a latch in any HDL design I have worked on.  Do you 
see a use for latches in your design?

-- 

Rick

Hi Ron,

ronhk25 <ronhk25@gmail.com> wrote:
> I always hear from FPGA designers that latches are "dangerous" and 
> that it's very important avoiding them. 

What is 'dangerous' is not the latch in itself, rather the implicit 
instantiation of a latch because of an incomplete assignment. This is 
usually a sign something has been 'forgotten' by the designer, hence the 
danger.

> I wonder what are the technical risks resulting by using latches.

AFAIK, timing analysis may have problems because it performs setup/hold 
times verification based on clock propagation. If your enable signal is 
slower than the data in your latch you'll have issues that are hard to 
spot during timing analysis.

> As far as I understand, 
> the main problem is that FPGAs don't have built in hard latches [...]

Not true, there are devices with built in latches (ex. ProAsic from 
Microsemi) that are readily available even for automatic triplification 
to enhance radiation tolerance.

I've never found the need to use a latch.

HTH,

Al

You've got it almost correct.  The only mistake is that it's not that they =
are 'hard/impossible to be analyzed' though, it's because the race conditio=
ns will cause the latch to fail if constructed out of logic blocks rather t=
han a hard latch.  A flip flop would fail in the same way if constructed ou=
t of logic blocks as well.

Kevin Jennings

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,=
 17 =D7=91=D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2014 11:17:04 UTC+2, =D7=9E=
=D7=90=D7=AA ronhk25:
> Hi all,
>=20
> I always hear from FPGA designers that latches are "dangerous" and that i=
t's very important avoiding them. I wonder what are the technical risks res=
ulting by using latches. As far as I understand, the main problem is that F=
PGAs don't have built in hard latches so the synthesizer has to implement i=
t from logic blocks and then the race condition in the resulting logic is h=
ard/impossible to be analyzed.
> Is this main disadvantage latches? are there any other issues regarding l=
atches which shall be considered?
>=20
> Thanks,
>=20
> Ron

RIK and HTH thanks for your reply,

RIK, regarding your question- in some cases while using combinatorical logi=
c based state machines, i would like that some signals will keep their curr=
ent values as a default (unless some defined conditions are met). I think t=
hat this will result with latch since we get an asynchronous process (async=
hronous decoders for the next state and for the output registers) with a si=
gnal that its default value is its current value (i'm not that experinced w=
ith asynchronous design so please correct me if i'm wrong...).=20
I agree that latches are not sound that usefull but sometimes i find myself=
 choosing not to use asynchronous processes in order to avoid from inferred=
 latches.

> RIK, regarding your question- in some cases while using combinatorical lo=
gic based state machines, i would like that some signals will keep their cu=
rrent values as a default (unless some defined conditions are met).

This will result in a design that fails.  If you're lucky it just never wor=
ks, if you're not lucky you find that it doesn't work as you're manufacturi=
ng is trying to build 1000 boards and find they are 'flaky'.  Take what you=
 think to be a 'working' design' and spray some cold spray on the part and =
watch it fail.

If you're doing FPGA designs and you're using a part that does not have har=
d latches, then you would be best off to abandon any use of combinatorial s=
tate machines before you get burned.

Kevin Jennings

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,=
 17 =D7=91=D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2014 11:17:04 UTC+2, =D7=9E=
=D7=90=D7=AA ronhk25:
> Hi all,
>=20
> I always hear from FPGA designers that latches are "dangerous" and that i=
t's very important avoiding them. I wonder what are the technical risks res=
ulting by using latches. As far as I understand, the main problem is that F=
PGAs don't have built in hard latches so the synthesizer has to implement i=
t from logic blocks and then the race condition in the resulting logic is h=
ard/impossible to be analyzed.
> Is this main disadvantage latches? are there any other issues regarding l=
atches which shall be considered?
>=20
> Thanks,
>=20
> Ron

Rick and Al thanks for your reply,=20

RIK, regarding your question- in some cases while using combinatorial logic=
 based state machines, I would like that some signals will keep their curre=
nt values as a default (unless some defined conditions are met). I think th=
at this will result with latch since we get an asynchronous process (asynch=
ronous decoders for the next state and for the output registers) with a sig=
nal that its default value is its current value (I=E2=80=99m not that exper=
ienced with asynchronous design so please correct me if I=E2=80=99m wrong..=
.).=20
I agree that latches are not sound that useful but sometimes I find myself =
choosing not to use asynchronous processes in order to avoid from inferred =
latches.

ronhk25 wrote:
> בתאריך יום שני, 17 בנובמבר 2014 11:17:04 UTC+2, מאת ronhk25:
>> Hi all,
>>
>> I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed.
>> Is this main disadvantage latches? are there any other issues regarding latches which shall be considered?
>>
>> Thanks,
>>
>> Ron
> 
> RIK and HTH thanks for your reply,
> 
> RIK, regarding your question- in some cases while using combinatorical logic based state machines, i would like that some signals will keep their current values as a default (unless some defined conditions are met). I think that this will result with latch since we get an asynchronous process (asynchronous decoders for the next state and for the output registers) with a signal that its default value is its current value (i'm not that experinced with asynchronous design so please correct me if i'm wrong...). 
> I agree that latches are not sound that usefull but sometimes i find myself choosing not to use asynchronous processes in order to avoid from inferred latches.

There is a difference between an "asynchronous state machine" and
"asynchronous" process included within a 2-proces (synchronous)
state machine.  The latter is often used, although generally not
preferred by serious FPGA designers.  If your decode logic is
just for the "next" state, and the current state comes from a
clocked register (edge-triggered flip-flop), then the correct
way to retain the current state is to assign the output of
the flop to the next state, rather than assigning next state to itself,
which infers a latch.

-- 
Gabor

Hi Ron,

ronhk25 <ronhk25@gmail.com> wrote:
[]
> RIK, regarding your question- in some cases while using combinatorial 
> logic based state machines, I would like that some signals will keep 
> their current values as a default (unless some defined conditions are 
> met). 

Why do you want to implement combinatorial logic based state machines in 
the first place? What is the use case where there's a need for such an 
FSM w.r.t. clocked FSM?

> I think that this will result with latch since we get an 
> asynchronous process (asynchronous decoders for the next state and for 
> the output registers) with a signal that its default value is its 
> current value (I&rsquo;m not that experienced with asynchronous design so 
> please correct me if I&rsquo;m wrong...).

A signal whose 'default value is its current value' is hard for me to 
picture. Default is tipically that value the system is at rest when 
coming up, how can this value depend on the current value?

> I agree that latches are not sound that useful but sometimes I find 
> myself choosing not to use asynchronous processes in order to avoid 
> from inferred latches.

Think about the behavior you want to attain in the first place and only 
then reason in terms of asynchronous and/or synchronous.

Remember always that timing analysis is critical for the *correct* 
functioning of your logic. If your design fails to meet design 
constraints it will likely fail the 'cold spray' test KJ 
mentioned...sooner or later!

Al

Hi,

>>  I would like that some signals will keep their current values as a
default

Couldn't I always map it to a conventional (Mealy) machine with purely
registered state and purely combinational logic. 

For example, take this little state machine with cmd input
- 0: hold value
- 1: increment
- 2: decrement
- 3: apply the last operation ("keep current value")

The default / last command has simply become part of the registered state.

input wire [1:0] cmd;
reg [31:0] count = 0;
reg [1:0] lastCmd = 0;
always @(posedge clk) begin
  if (cmd != 3) begin
    lastCmd <= cmd;
    case (cmd)
      0: begin end
      1: count <= count+1; 
      2: count <= count-1; 
      /* 3: is impossible */
    endcase
  end else begin
    case (lastCmd)
      0: begin end
      1: count <= count+1; 
      2: count <= count-1; 
      /* 3: is impossible */
    endcase
  end
end
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com