what is the problem with latch inference?

Discussion in 'VHDL' started by VHDL Guy, Sep 28, 2006.

  1. VHDL Guy

    VHDL Guy Guest

    I am in the process of reviewing someone else's code that will be
    synthesized in an FPGA. I am not so much concerned with the amount of
    space the design will consume on the FPGA as I believe the FPGAs being
    used are pretty big, although I realize that best coding styles
    recommend that code footprint be as small as possible.

    In the code I am looking at, there are multiple situations in which
    if/then statements without clock inputs do not have else conditions.
    >From what I've read on this forum and in some books, I believe that

    when synthesized this can cause a latch to be inferred to hold the
    value of the signal when not re-assigned.

    However, it seems to me that the latch inference will still allow the
    design to function as intended. Is this correct?

    Why are VHDL code writers cautioned against allowing latches to be
    inferred? Do latches cause unreliable circuitry when synthesized in an
    FPGA? If so, what are the technical/electrical problems that make
    latches unreliable?

    Is inference of registers or flip-flops (by clocked if/then statements
    without else statement) also a problem along these same lines?

    I've been reading this group quite a bit lately and have learned quite
    a few things from it. Thanks for your responses and guidance in
    advance.

    Regards,
    Vic
     
    VHDL Guy, Sep 28, 2006
    #1
    1. Advertising

  2. VHDL Guy

    David Ashley Guest

    VHDL Guy wrote:
    > I am in the process of reviewing someone else's code that will be
    > synthesized in an FPGA. I am not so much concerned with the amount of
    > space the design will consume on the FPGA as I believe the FPGAs being
    > used are pretty big, although I realize that best coding styles
    > recommend that code footprint be as small as possible.
    >
    > In the code I am looking at, there are multiple situations in which
    > if/then statements without clock inputs do not have else conditions.
    >>From what I've read on this forum and in some books, I believe that

    > when synthesized this can cause a latch to be inferred to hold the
    > value of the signal when not re-assigned.
    >
    > However, it seems to me that the latch inference will still allow the
    > design to function as intended. Is this correct?
    >
    > Why are VHDL code writers cautioned against allowing latches to be
    > inferred? Do latches cause unreliable circuitry when synthesized in an
    > FPGA? If so, what are the technical/electrical problems that make
    > latches unreliable?
    >
    > Is inference of registers or flip-flops (by clocked if/then statements
    > without else statement) also a problem along these same lines?
    >
    > I've been reading this group quite a bit lately and have learned quite
    > a few things from it. Thanks for your responses and guidance in
    > advance.
    >
    > Regards,
    > Vic
    >


    I can't speak with a lot of weight, but in my experience when I
    have latches inferred they simulate fine, but an actual synthesized
    circuit just doesn't...work right. And I think perhaps different
    synthesizers might behave differently. It might even change
    from build to build.

    In thinking about it, an inferred latch might suffer from
    setup and hold instability. We're talking about a non-clocked
    output that sometimes wants to change its value. How does
    the synthesizer work this out? Perhaps it routes the output
    back around to the input, and that becomes the setting for
    all states not covered otherwise. So you've got then
    combinatorial feedback...which might be dangerous and
    unpredictable.

    So in general it might be a cause for trouble, and people have
    just gotten burned too many times and it's now taboo.

    Keep in mind VHDL as a language must be interpreted
    by the synthesizer, and there is no guarantee that perfectly
    valid VHDL can be reduced to logic gates that exist on
    FPGA's perfectly. I think the standard probably only
    dictates how a simulator must behave, not what a
    synthesizer must do.

    Hope this was useful.

    -Dave
    --
    David Ashley http://www.xdr.com/dash
    Embedded linux, device drivers, system architecture
     
    David Ashley, Sep 29, 2006
    #2
    1. Advertising

  3. VHDL Guy

    Peter Guest

    VHDL Guy skrev:

    > In the code I am looking at, there are multiple situations in which
    > if/then statements without clock inputs do not have else conditions.
    > >From what I've read on this forum and in some books, I believe that

    > when synthesized this can cause a latch to be inferred to hold the
    > value of the signal when not re-assigned.
    >
    > However, it seems to me that the latch inference will still allow the
    > design to function as intended. Is this correct?
    >
    >


    Hi,

    Latches is often the result of forgotten ELSE statements and will
    generate warnings during synthesis. The problem with latches is hold
    time. If input data and the latch enable signal changes on the same
    clock edge, the latch may latch a mixture of old and new data depending
    on the delay in each signal path.

    /Peter
     
    Peter, Sep 29, 2006
    #3
  4. VHDL Guy

    KJ Guest

    "David Ashley" <> wrote in message
    news:...
    > VHDL Guy wrote:
    >> In the code I am looking at, there are multiple situations in which
    >> if/then statements without clock inputs do not have else conditions.
    >>>From what I've read on this forum and in some books, I believe that

    >> when synthesized this can cause a latch to be inferred to hold the
    >> value of the signal when not re-assigned.

    Yes, that is correct. Per the VHDL standard (and is generally the case with
    software languages too for that matter), the value of a signal will remain
    unchanged unless it is explicitly reassigned. So if the 'if' condition is
    not met, then the signal will hold it's current state.

    >>
    >> However, it seems to me that the latch inference will still allow the
    >> design to function as intended. Is this correct?

    In simulation yes, in a real board, possibly but only under 'just the right
    conditions'. At best it will fail outright and the designer can work on
    fixing it. At worst it will be a persistent 'flaky' problem with symptoms
    like...."It works fine for a bit then when it heats up it stops working,
    then when I hit it with cold spray it works again....must be a 'heat
    problem' with the chip"...and then you'll go off chasing mysterious "heat
    problems" that will be far off the beaten path of what the true problem is.

    >>
    >> Why are VHDL code writers cautioned against allowing latches to be
    >> inferred?

    Unless the underlying hardware in the part has an actual hardware latch then
    you will have a problem when trying to synthesize a latch from basic logic
    because you have no control over timing delays and race conditions. If
    there is a built in latch in the hardware for the generic part itself, the
    chip designer CAN control timing delays and race conditions and give you a
    reliable latch. That's the key difference, the chip designer has control
    over things that the VHDL writer does not which are critically important for
    making a latch.

    >> Do latches cause unreliable circuitry when synthesized in an
    >> FPGA? If so, what are the technical/electrical problems that make
    >> latches unreliable?

    The basic process template for a latch is
    process(LE)
    begin
    if (LE = '1') then
    Y <= X;
    end if;
    end process;

    An alternative exactly equivalent representation (that you should also look
    for in your code by the way) is
    Y <= (LE and X) -- #1
    or (not(LE) and Y); -- #2

    The problem is that there is an inherent race condition when LE switches
    from '1' to '0' and line #1 is going to no longer be true and has to hand it
    over to line #2. What if the logic needed to implement #1 is 'faster' than
    line #2? Because line #1 will be false (because LE is switching from 1 to
    0) then Y will get to 0 and line #2 (the slower path) will latch Y with a 0.

    If you remember Karnaugh maps you can 'solve' this problem by adding
    redundant logic terms and write
    Y <= (LE and X) -- #1
    or (not(LE) and Y) -- #2
    or (X and Y); -- #3

    This third form has a 'cover' term line #3 that solves the race condition.
    'LE' switching is no longer causing a race condition because if the input
    'X' and output 'Y' are both '1' then 'Y' will remain a '1' regardless of
    what 'LE' is doing. The problem is that any synthesizer will be able to
    spot it as a redundant logic term and will reduce it out taking you right
    back to the previous form...which has the race condition.

    The VHDL designer might then be tempted to write it with the cover term and
    add signal attributes to prevent 'Y' from being optomized. The problem with
    that approach is that those attributes are always vendor and tool specific,
    if you change either one then the "don't reduce this darn it" attribute will
    be ignored.

    You'll also have the additional task of physically verifying (for at least
    one instance of your latches but probably all) that the final fitted code is
    exactly what you intended since, if you use the attribute incorrectly (like
    missspeellll it somewhere) it will be ignored without any warning.

    If your particular part DOES have a native hardware latch, then you need to
    physically verify that ALL latch instances result in the proper final fitted
    equations. For the above set you'll probably see something like
    Y.LE = LE; -- This is the LE input to the latch
    Y.EQN = X -- This is the 'D' input to the latch
    As I said, you'll need to do this with each instance of a latch to make sure
    that there isn't something in the way you coded it in one place that
    confused the fitter. The most common way to confuse some is if you have
    something like "if ((This or That) = '1') then". The tool might synthesize
    it to what you want but you'll have to check.

    If that's how you want to spend your engineering man hours, that's up to
    you....but I'm sure it's not. So, that's why you never want to use a latch
    inside code destined for a CPLD or FPGA.

    >>
    >> Is inference of registers or flip-flops (by clocked if/then statements
    >> without else statement) also a problem along these same lines?

    No, because all CPLD/FPGAs have flip flops hardware built in so they won't
    cause the synthesis tool to try to build a flip flop out of logic gates as
    it can do with a latch. Once again, it is the flip flop designer for the
    chip itself that has to deal with the timing but they have the ability to
    control timing but the VHDL designer trying to USE the flip flop does not.

    By the way, as I mentioned earlier, besides the 'process' form of latch
    inferrence, you need to look for any case where the output of an equation
    shows up on the right side of the equation as well (as I demonstrated in the
    'alternative' form). Those are both the exact same latch. To take it
    further you also have to consider that the following is a form of latch
    also.

    Y <= (LE and X)
    or (not(LE) and Z);

    Z <= Y;

    Here it is not much of a stretch to see it as a latch, but the latched
    signal 'Y' does not upon first inspection appear to be a latch since it does
    not appear to depend on it's own value as input. The point here is that
    there might be any number of equations in the logic path much more than just
    "Z <= Y". Just so you don't tear your hair out trying to find all of this
    though, every synthesis tool should be able to catch this and report a
    warning. It will happen in one of two forms: either a warning about an
    inferred latch (which they implicitly are telling you is 'bad', hence the
    'warning') or if nothing else in the timing analysis it will report about a
    'combinatorial loop' (which is a timing path that exists where you have a
    combinatorial loop of logic without a flop anywhere in the path). In either
    case it's a 'warning' not an 'error' so you will get an output file that you
    can program a part with. Like most warnings though, this is actually a
    design error....so fix it. The point is that these things can be caught
    most easily by perusal of synthesis report files much easier than by code
    inspection because the synthesis report will always catch everything, the
    code inspection might overlook something.

    KJ
     
    KJ, Sep 29, 2006
    #4
  5. VHDL Guy schrieb:


    > In the code I am looking at, there are multiple situations in which
    > if/then statements without clock inputs do not have else conditions.
    >>From what I've read on this forum and in some books, I believe that

    > when synthesized this can cause a latch to be inferred to hold the
    > value of the signal when not re-assigned.


    You have to decide if you want a storage element or not. This is nothing
    that can be left to a discussion about area or something else. It is a
    very big difference if you describe something pure combinational or
    something that includes storage elements.

    I write storage elements, because I mean flipflops AND latches. A good
    hardware designer knows _every_ storage element in his design and checks
    the synthesis report if exactly these storage elements are inferred (not
    more, not less).


    > However, it seems to me that the latch inference will still allow the
    > design to function as intended. Is this correct?


    Yes. Latches are not something "evil" - they are elements like all the
    other circuit elements with special purpose and special behavior.

    Nevertheless latches require careful design. For flipflops there are
    automatic checks of setup- and hold-time violations. For latches such
    stuff does not exist. A hardware designer has to take care that the
    latch input does not change short before the latch-enable is turned off.
    This is dangerous, because a lot of people are too lazy to think about
    this risk. For the others a latch is a wonderful storage element
    (smaller and less power consumption than flipflops). But flipflops and
    latches cannot exchanged because they have different advantages and
    drawbacks.


    > Why are VHDL code writers cautioned against allowing latches to be
    > inferred?


    I have written about the lazy people. The same holds for the beginners.
    Latches provide traps and pitfalls. If you know them, you can avoid them.

    A lot of FPGAs do not have latches included. Therefore latches are build
    out of combinational loops. This may lead to problems.



    > If so, what are the technical/electrical problems that make
    > latches unreliable?


    The "problem" is the behavior of a latch itself: Latches are open for
    the data input as long as the latch-enable is active and therefore they
    are transparent. This means the output changes too! And as I have said
    it is dangerous if the data input changes short before the latch-enable
    is turned off. No one can tell you then, what value is stored in the
    latch. The similar behavior for flipflops can be detected using setup-
    and hold-time checks.


    > Is inference of registers or flip-flops (by clocked if/then statements
    > without else statement) also a problem along these same lines?


    A register is a storage element. A storage element can be a latch or a
    flipflop.

    The inference of storage elements is never a problem - except you did
    not want them and know why they are inferred.


    Most synthesis tools report warnings when they infer latches, because it
    is easy to make a mistake while describing a combinational process and
    getting an unwanted latch because of this mistake. Latches in FPGAs may
    be a problem - depending on the FPGA. And a lot of companies have design
    rules, that do not allow the usage of latches.

    I use latches whenever it is possible, but the design has to be done
    very carefully.

    Ralf
     
    Ralf Hildebrandt, Sep 29, 2006
    #5
  6. VHDL Guy

    KJ Guest

    "Ralf Hildebrandt" <> wrote in message
    news:...
    >
    >> However, it seems to me that the latch inference will still allow the
    >> design to function as intended. Is this correct?

    >
    > Yes. Latches are not something "evil" - they are elements like all the
    > other circuit elements with special purpose and special behavior.
    >
    > Nevertheless latches require careful design. For flipflops there are
    > automatic checks of setup- and hold-time violations. For latches such
    > stuff does not exist. A hardware designer has to take care that the
    > latch input does not change short before the latch-enable is turned off.
    > This is dangerous, because a lot of people are too lazy to think about
    > this risk.

    Setup and hold time relative to the latch enable is important but the much
    bigger risk with using latches inside FPGA/CPLDs where the targetted device
    does not have a hard latch and the latch must be cobbled together from logic
    blocks is the inherent race condition in the resulting logic which is the
    predominant failure mechanism that I've seen even when setup and hold time
    were easily met but the output went to 0 a Tpd after the latch signal went
    low....and all you can do then is use non-portable vendor/tool specific
    attributes to help you out.

    >
    >> Why are VHDL code writers cautioned against allowing latches to be
    >> inferred?

    >
    > I have written about the lazy people. The same holds for the beginners.
    > Latches provide traps and pitfalls. If you know them, you can avoid them.

    Hence the reason for the caution....you don't know what you don't know. For
    example, even if you ae aware of setup/hold timing analysis but did not know
    about the the race condition problem then you wouldn't know that you're
    heading for problems if you use latches.

    >
    > A lot of FPGAs do not have latches included. Therefore latches are build
    > out of combinational loops. This may lead to problems.

    Without resorting to vendor/tool specfic attributes being added to the code,
    I would say that it WILL lead to problems.

    KJ
     
    KJ, Sep 29, 2006
    #6
  7. KJ wrote:

    Thumbs up for your informative post!

    On small thing: you forgot the data input in the sensitivity list.

    > The basic process template for a latch is
    > process(LE)
    > begin
    > if (LE = '1') then
    > Y <= X;
    > end if;
    > end process;


    This should be:

    process(LE, X)
    begin
    if LE = '1' then
    Y <= X;
    end if;
    end process;

    --
    Paul.
     
    Paul Uiterlinden, Sep 29, 2006
    #7
  8. VHDL Guy

    KJ Guest

    "Paul Uiterlinden" <> wrote in message
    news:451d6aef$0$11702$4all.nl...
    > KJ wrote:
    >
    > Thumbs up for your informative post!
    >
    > On small thing: you forgot the data input in the sensitivity list.
    >> The basic process template for a latch is
    >> process(LE)
    >> begin
    >> if (LE = '1') then
    >> Y <= X;
    >> end if;
    >> end process;

    >
    > This should be:
    >
    > process(LE, X)
    > begin
    > if LE = '1' then
    > Y <= X;
    > end if;
    > end process;
    >
    > --
    > Paul.
    >


    Sometimes it can be really easy to spot the work of somebody who hardly ever
    uses a process sensitivity list that consists of anything more than 'Clock'.
    Good catch.

    KJ
     
    KJ, Sep 30, 2006
    #8
  9. VHDL Guy

    Andy Guest

    KJ wrote:
    > "Ralf Hildebrandt" <> wrote in message
    > news:...
    > >
    > >> However, it seems to me that the latch inference will still allow the
    > >> design to function as intended. Is this correct?

    > >
    > > Yes. Latches are not something "evil" - they are elements like all the
    > > other circuit elements with special purpose and special behavior.
    > >
    > > Nevertheless latches require careful design. For flipflops there are
    > > automatic checks of setup- and hold-time violations. For latches such
    > > stuff does not exist. A hardware designer has to take care that the
    > > latch input does not change short before the latch-enable is turned off.
    > > This is dangerous, because a lot of people are too lazy to think about
    > > this risk.

    > Setup and hold time relative to the latch enable is important but the much
    > bigger risk with using latches inside FPGA/CPLDs where the targetted device
    > does not have a hard latch and the latch must be cobbled together from logic
    > blocks is the inherent race condition in the resulting logic which is the
    > predominant failure mechanism that I've seen even when setup and hold time
    > were easily met but the output went to 0 a Tpd after the latch signal went
    > low....and all you can do then is use non-portable vendor/tool specific
    > attributes to help you out.
    >
    > >
    > >> Why are VHDL code writers cautioned against allowing latches to be
    > >> inferred?

    > >
    > > I have written about the lazy people. The same holds for the beginners.
    > > Latches provide traps and pitfalls. If you know them, you can avoid them.

    > Hence the reason for the caution....you don't know what you don't know. For
    > example, even if you ae aware of setup/hold timing analysis but did not know
    > about the the race condition problem then you wouldn't know that you're
    > heading for problems if you use latches.
    >
    > >
    > > A lot of FPGAs do not have latches included. Therefore latches are build
    > > out of combinational loops. This may lead to problems.

    > Without resorting to vendor/tool specfic attributes being added to the code,
    > I would say that it WILL lead to problems.
    >
    > KJ


    Not only do many FPGAs not have built-in latches, but their static
    timing analysis tools are not suited to analyzing both setup/hold to
    the latch enable signal, AND the combinatorial path delay through it
    (to whatever the next storage element might be).

    The recommendation to always include elses with ifs is only a partial
    solution, and it not sufficient in itself. A better approach when
    coding combinatorial processes is to make default assignments right at
    the top of the process, so that no matter what, when the process
    triggers, every signal will be assigned something. This is a much more
    foolproof method, and is more easily auditable in reviews.

    The best way to avoid latches, IMHO, is to avoid combinatorial
    processses altogether. Use variables in clocked processes.

    Andy
     
    Andy, Oct 2, 2006
    #9
  10. VHDL Guy

    fp Guest

    VHDL Guy wrote:
    > I am in the process of reviewing someone else's code that will be
    > synthesized in an FPGA. I am not so much concerned with the amount of
    > space the design will consume on the FPGA as I believe the FPGAs being
    > used are pretty big, although I realize that best coding styles
    > recommend that code footprint be as small as possible.
    >
    > In the code I am looking at, there are multiple situations in which
    > if/then statements without clock inputs do not have else conditions.
    > >From what I've read on this forum and in some books, I believe that

    > when synthesized this can cause a latch to be inferred to hold the
    > value of the signal when not re-assigned.
    >
    > However, it seems to me that the latch inference will still allow the
    > design to function as intended. Is this correct?
    >
    > Why are VHDL code writers cautioned against allowing latches to be
    > inferred? Do latches cause unreliable circuitry when synthesized in an
    > FPGA? If so, what are the technical/electrical problems that make
    > latches unreliable?
    >
    > Is inference of registers or flip-flops (by clocked if/then statements
    > without else statement) also a problem along these same lines?
    >
    > I've been reading this group quite a bit lately and have learned quite
    > a few things from it. Thanks for your responses and guidance in
    > advance.
    >
    > Regards,
    > Vic


    See page 16 of

    http://academic.csuohio.edu/chu_p/rtl/chu_rtL_book/silde/chap08_1.pdf

    It shows how delay can lead to oscillation and
    what can go wrong for an ill-designed latch
    (or a circuit with combinational loop).

    S. C.
     
    fp, Oct 2, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dangerlee

    logical left shifter or latch ??

    dangerlee, May 5, 2004, in forum: VHDL
    Replies:
    4
    Views:
    856
    Egbert Molenkamp
    May 7, 2004
  2. Lee
    Replies:
    3
    Views:
    3,743
  3. engrjet

    Latch problem in FSM

    engrjet, Mar 12, 2008, in forum: VHDL
    Replies:
    1
    Views:
    809
    jeppe
    Mar 13, 2008
  4. kushan_2001

    latch problem

    kushan_2001, Jul 13, 2009, in forum: VHDL
    Replies:
    2
    Views:
    495
    jeppe
    Jul 14, 2009
  5. We Ech Dee Ell
    Replies:
    8
    Views:
    2,040
Loading...

Share This Page