Warning in Synthesis: found 1-bit latch for signal

Status
Not open for further replies.
G

ghostridergr

Member level 1
Joined
Nov 22, 2011
Messages
41
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,590
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?
 

Re: Warning in Synthesis


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
 
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.
 
Re: Warning in Synthesis


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).


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;
 
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;
Click to expand...

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.
Click to expand...
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.
Click to expand...
Agreed.
Kevin Jennings
 

    V

    Points: 2
    Helpful Answer Positive Rating
Re: Warning in Synthesis

Ok some newbie questions about the above.

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.


so you mean in the reset section, giving an initial value to all of my signals?
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.
Click to expand...
what if I am using and the rest addresses in the next lines? Will I get warnings again? Because I am using them.
 

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.
Click to expand...

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?
Click to expand...

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.
Click to expand...

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.
Click to expand...

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


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.
 

Re: Warning in Synthesis

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
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…