Warning in Synthesis: found 1-bit latch for signal

ghostridergr · Jan 29, 2012

I am getting this warning for almost every signal that I use:

Code:

Xst:737 - Found 1-bit latch for signal <line_finished>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

can anyone suggest me if its serious or not?

K-J · Jan 29, 2012

Re: Warning in Synthesis

ghostridergr said:
I am getting this warning for almost every signal that I use:

Code:

Xst:737 - Found 1-bit latch for signal <line_finished>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

can anyone suggest me if its serious or not?

Yes it is serious. If you don't fix it, the design will either
- Work for some period of time
- Not work at all
- Work under 'some' conditions, such as 'only when cold', 'only when warm'

What it means is that you have a signal that has a combinatorial path (i.e. no clocked registers) back to itself. As an example, a transparent latch

Code:

process(C, D)
begin
  if (C= '1') then
    Q <= D;
  end if;
end process;

Yours might not be that simple to spot, but since the tool is reporting it, you have it.

Kevin Jennings

permute · Jan 30, 2012

Re: Warning in Synthesis

it isn't serious as long as you can still ensure the design meets timing requirements. However, it is usually easier to just fix the problem. the problem occurs in a few ways. Typically when a clocked process has an async reset, but fails to reset all signals assigned in the process. This forces the value of the non-reset registers to be retained during the reset. This can be done, but requires a latch (with the reset as the input). Timing may become an issue in these cases.

The second case is where a process is intended to infer combinatorial logic, but a signal isn't assigned in all possible if-else (or case) branches. This is different from a combinatorial loop though, as combinatorial loops will cause a synthesis error.

The last case is where an assignment outside of a process has an index. eg, x(addr) <= Din(0); no mention is made what to do with all other addresses, so a latch is formed to retain the values.

TrickyDicky · Jan 30, 2012

Re: Warning in Synthesis

permute said:
it isn't serious as long as you can still ensure the design meets timing requirements. However, it is usually easier to just fix the problem. the problem occurs in a few ways. Typically when a clocked process has an async reset, but fails to reset all signals assigned in the process. This forces the value of the non-reset registers to be retained during the reset. This can be done, but requires a latch (with the reset as the input). Timing may become an issue in these cases.

In Altera (and Im pretty sure Xilinx too) most registers have an async reset input, which can be connected or left disconnected. It does not become a latch just because you didnt do an async reset. I do the above all the time (have some reset and non in the same process) and Ive never had a timing problem (and registers are created properly).

The second case is where a process is intended to infer combinatorial logic, but a signal isn't assigned in all possible if-else (or case) branches. This is different from a combinatorial loop though, as combinatorial loops will cause a synthesis error.

What exactly do you mean by a combinatorial loop? quartus has no problem with this :

a_temp <= b_temp or a;
b_temp <= not a_temp;

b <= b_temp;

K-J · Jan 30, 2012

Re: Warning in Synthesis

What exactly do you mean by a combinatorial loop? quartus has no problem with this :

a_temp <= b_temp or a;
b_temp <= not a_temp;

b <= b_temp;

If by 'no problem' you mean that Quartus generates warnings that you ignored, then yes, there is 'no problem'. Here is what Quartus has to say...

Warning: Found combinational loop of 2 nodes
Warning: Node "a_temp|datad"
Warning: Node "a_temp|combout"

You should take your example, run it through Quartus and take a look at the post-route design in the netlist viewer. What you will see is the combinatorial output of a LUT feeding back to the input, along with the input 'a'. This is an example of such a loop, feedback without any intervening registers. Operation in this mode will not be guaranteed, therefore it will be a roll of the dice. Will it work? Sure...for a while, then it won't.

Kevin Jennings

---------- Post added at 08:43 ---------- Previous post was at 08:32 ----------

permute said:
it isn't serious as long as you can still ensure the design meets timing requirements.

But therein lies the rub. It will not be generally possible to meet the timing requirements if the implementation is in LUTs because, depending on the placement and routing, you could very well get a very fast timing path on the feedback loop and some slightly slower other path that will cause the timing to fail, but this won't be detectable by the timing analysis tool because it can't analyze this loop to begin with. The real fix would be to include logically redundant 'cover' terms that handle the situation when the fed back output gets back to the input 'too quickly', but synthesis tools will remove such redundant terms. Here is an example of how one could code a latch that would always work...but you have to disable the synthesis tool's inherent ability to remove the redundant term in order to get it to work

Code:

Q <= (D and C) or (Q and not(C)) or (D and Q);  -- Last term is redundant, handles the case when 'C' switches from 1 to 0

The only real way to use a latch in a design and be able to guarantee correct operation over the operating range is if the device has hard latches built in and those latches get used to implement your latch.

However, it is usually easier to just fix the problem.

Agreed.
Kevin Jennings

ghostridergr · Feb 1, 2012

Re: Warning in Synthesis

Ok some newbie questions about the above.

K-J said:
Yes it is serious. If you don't fix it, the design will either
- Work for some period of time
- Not work at all
- Work under 'some' conditions, such as 'only when cold', 'only when warm'

What it means is that you have a signal that has a combinatorial path (i.e. no clocked registers) back to itself. As an example, a transparent latch

Code:

process(C, D) begin if (C= '1') then Q <= D; end if; end process;

Ok to begin with, lets consider the code above. Why it will work only for some period of time? Sorry for the foolish question maybe, but i have just started to work on such a project.

permute said:
it isn't serious as long as you can still ensure the design meets timing requirements. However, it is usually easier to just fix the problem. the problem occurs in a few ways. Typically when a clocked process has an async reset, but fails to reset all signals assigned in the process. This forces the value of the non-reset registers to be retained during the reset. This can be done, but requires a latch (with the reset as the input). Timing may become an issue in these cases.

so you mean in the reset section, giving an initial value to all of my signals?

permute said:
The second case is where a process is intended to infer combinatorial logic, but a signal isn't assigned in all possible if-else (or case) branches. This is different from a combinatorial loop though, as combinatorial loops will cause a synthesis error.

is this wrong? I mean it seems logic to me, that a signal will get its value only on certain branches.

permute said:
The last case is where an assignment outside of a process has an index. eg, x(addr) <= Din(0); no mention is made what to do with all other addresses, so a latch is formed to retain the values.

what if I am using and the rest addresses in the next lines? Will I get warnings again? Because I am using them.

TrickyDicky · Feb 1, 2012

Re: Warning in Synthesis

ghostridergr said:
Ok to begin with, lets consider the code above. Why it will work only for some period of time? Sorry for the foolish question maybe, but i have just started to work on such a project.

If there is lots of code like this, you're liable to run into race conditions. If, because of temperature it works for a bit because signal a beats signal b, but now the temperature change means b beats a (a and b do not relate to the specified code, just two signals that race). So now it doesnt work.

so you mean in the reset section, giving an initial value to all of my signals?

You dont have to give initial values to everything. They may be irrelavent, and may not need to be reset. Like I said in my post, I think permute is wrong (you can get away with resetting some signals and not others, because reset can be connected or just left disconnected).

is this wrong? I mean it seems logic to me, that a signal will get its value only on certain branches.

In an asynchronous process, if you do assign a value in all branches, it means that the signal needs memory, and hence requires a latch. As we have discussed, latches are bad because you cannot put them through timing analysis and you get into race conditions. So all signals should be assigned in ALL branches of an asynchronous process. In a synchronous process, you dont have to, because effectively what you are doing is generating the clock enable input of a standard D-type register (which you can run timing analysis on).

what if I am using and the rest addresses in the next lines? Will I get warnings again? Because I am using them.

like above, if you are doing this asynchronously, you must assign ALL signals in ALL cases to prevent latch generation.

xtcx · Feb 2, 2012

Re: Warning in Synthesis

K-J said:
But therein lies the rub. It will not be generally possible to meet the timing requirements if the implementation is in LUTs because, depending on the placement and routing, you could very well get a very fast timing path on the feedback loop and some slightly slower other path that will cause the timing to fail, but this won't be detectable by the timing analysis tool because it can't analyze this loop to begin with. The real fix would be to include logically redundant 'cover' terms that handle the situation when the fed back output gets back to the input 'too quickly', but synthesis tools will remove such redundant terms. Here is an example of how one could code a latch that would always work...but you have to disable the synthesis tool's inherent ability to remove the redundant term in order to get it to work

Code:

Q <= (D and C) or (Q and not(C)) or (D and Q); -- Last term is redundant, handles the case when 'C' switches from 1 to 0

Kevin Jennings

I wonder what does the timing tool have to do with feedback path. This is the known issue with the combo feedback without a FF. Timing of a combo logic cannot be met whenever there is a feedback within combo process without a FF.

And I wonder the redundant logic you added might work. Consider the tool does not remove the redundant logic, how does that help here?. Without the the currently placed LUT feedback loop length, you still cannot add any compensation to balance the timing which will end up in failure if the feedback path is even faster.

K-J · Feb 2, 2012

Re: Warning in Synthesis

And I wonder the redundant logic you added might work. Consider the tool does not remove the redundant logic, how does that help here?. Without the the currently placed LUT feedback loop length, you still cannot add any compensation to balance the timing which will end up in failure if the feedback path is even faster.

Whether it works is also a function of how it is actually implemented. I don't know if FPGAs with their lookup tables that implement logic would work. I *think* that the various FPGA suppliers guaranteee no glitches on the LUT outputs when only one input changes, but as far as I know, they don't say anything if more than one input switches. Without that knowledge, it wouldn't be possible to guarantee anything about a latch inside a LUT based logic implementation device such as an FPGA.

For a PLD where you have and/or array you can guarantee proper operation by adding the redundant cover term. If you think of PLD implementation, each line below will result in a product term. Each of the three product terms get 'or-ed' together by the or matrix. The race condition manifests itself in a PLD if line 2 is 'faster' than line 1 in which case the output will not hold at a '1' when 'c' switches from '1' to '0'. However, that is exactly the situation that line 3 handles, line 3 is independent of 'c' so it will not be affected when 'c' switches.

If you draw out the Karnaugh map for lines 1 and 2, you'll see how line 3 provides redundancy strictly from a logic perspective. If a race conditions can be fixed with logic it is through the application of adding the appropriate redundant logic terms...which line 3 does provide for this example.

By the way, to reiterate what I said in an earlier post: In any programmable logic device, it is best not to design in any latch or any combinatorial loop in the first place. It is fair game to use hard latches that are designed right into the silicon (if there are any, many devices have none). This sidebar is simply about the techniques one could apply if absolutely needed.

Code:

q <= (c and d)        -- Line 1
             or (not(c) and q) -- Line 2
             or (q and d);       -- Line 3

Kevin Jennings

Welcome to EDAboard.com

Warning in Synthesis: found 1-bit latch for signal

ghostridergr

Member level 1

K-J

Advanced Member level 2

tariq786

Serwan Bamerni

permute

Advanced Member level 3

ghostridergr

Serwan Bamerni

TrickyDicky

Advanced Member level 7

Serwan Bamerni

K-J

Advanced Member level 2

ghostridergr

Member level 1

TrickyDicky

Advanced Member level 7

ghostridergr

xtcx

Advanced Member level 1

K-J

Advanced Member level 2

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Connect with us

Online statistics

Forum statistics