We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 39136

Design Assistant for XST – Reasons why a latch is inferred


This answer record will describe why a latch can be inferred.

Note: This Answer Record is a part of the Xilinx Solution Center for XST (Xilinx Answer 38927).

The Xilinx Solution Center for XST is available to address all questions related to XST.

Whether you are starting a new design or troubleshooting a problem, use the Solution Center for XST to guide you to the right information.


Xilinx generally does not recommend inferring latches in a design. 

This is especially true if the logic is intended to be combinatorial logic. 

A latch will break the synchronous path and make it difficult for the Xilinx Timing Engine to analyze the path appropriately. 

It is always recommend to look through the HDL Synthesis section of the XST report to see if there are latches inferred. 

You can check this by looking at the "Primitive and Black Box Usage" section in the XST Synthesis report.

Primitive and Black Box Usage:
# BELS                             : 2
#      GND                         : 1
#      LUT3                         : 1
# FlipFlops/Latches          : 3
#      FD                             : 1
#      FDC                          : 1
#      LD                             : 1
# Clock Buffers                : 2
#      BUFG                       : 1
#      BUFGP                    : 1
# IO Buffers                     : 3
#      IBUF                        : 2
#      OBUF                      : 1

Most of the time, this Warning will be given if there are latches inferred:

WARNING:Xst:737 - Found 1-bit latch for signal <signal name>

If this warning is found,  analyze the logic that created the latch and make sure that this is what was intended. 

If this was not intended, there are several things to check:
  • Ensure if-else statements assign the net to a value under all conditions.
  • Ensure case statements assign a value all signals in all conditions.
  • If you are intending to infer a register, make sure to include a clock in the process or always block.

In some cases, latches have been inferred on control signals (for example, the reset signal) but "WARNING:Xst:737" was not issued. 

If you see that latches are inferred in the Synthesis report but there are no warnings to show what signals they are inferred for, you can open the Technology Schematic or Schematic in PlanAhead and check connections of the latches to see where the latches are inferred from the code.

The following are two examples where latches are inferred on reset signals:

  • The register reset value does not match with the initial value specified in port/signal declaration.
    The solution is to have the reset value the same as the initial value.
  • The state signal of the state-machine is using integer type.
    The solution is to switch to enumerated values or standard logic (std_logic/std_logic_vector).
For more information on why a latch might be inferred, please see (Xilinx Answer 38931) for the XST Documentation.

Linked Answer Records

Master Answer Records

Answer Number Answer Title Version Found Version Resolved
38927 Xilinx Solution Center for XST N/A N/A

Associated Answer Records

Answer Number Answer Title Version Found Version Resolved
39079 Design Assistant for XST - Help with inference issues N/A N/A
AR# 39136
Date Created 03/15/2011
Last Updated 01/07/2015
Status Active
Type General Article
  • ISE
  • ISE Design Suite