Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

[SOLVED] Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incomplet

Status
Not open for further replies.
rafimiet

rafimiet

Member level 5
Joined
May 21, 2015
Messages
94
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
2,364
Xst:737 - Found 1-bit latch for signal <SIG_bit>.

The following section of code shows the warning:

Xst:737 - Found 1-bit latch for signal <SIG_bit>. 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.
Click to expand...

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Architecture
SIGNAL SIG_bit : STD_LOGIC := '0';
 
TYPE state IS (init, load_nx_block, load_pixel, generate_bs, no_block_check);
BEGIN
CASE pr_state IS
WHEN generate_bs =>
    SIG_bit <= SIG(SIG_addr);
    IF p_count = 0 THEN
        IF (dout >= threshold) AND (SIG_bit = '0') THEN
            stream <= "10";
        ELSIF (dout >= threshold) AND (SIG_bit = '1') THEN
            stream <= "01"; 
        ELSE
            stream <= "00";
        END IF;
        nx_state <= no_block_check;
    ELSE
        IF (dout >= threshold) AND (SIG_bit = '0') THEN
            stream <= "10";
        ELSIF (dout >= threshold) AND (SIG_bit = '1') THEN
            stream <= "01";
        ELSE
            stream <= "00";
        END IF;
            nx_state <= load_pixel;
    END IF;


Can you please tell me where to make necessary changes, so that the warning is removed?
 
Last edited by a moderator:

Re: Xst:737 - Found 1-bit latch for signal <SIG_bit>.

A switch-case statement instead of if-elsif could provide you an easiest way to find uncovered conditions.
 

Re: Xst:737 - Found 1-bit latch for signal <SIG_bit>.

Can you please tell me where to make necessary changes, so that the warning is removed?
Click to expand...

The answer is given in the warning message.
If you anyone else to debug your code, you have to post the entire code. You code shows only 1 state 'generate_bs'.
 

Re: Xst:737 - Found 1-bit latch for signal <SIG_bit>.

You need to post the entire code, not just the snippet, as this doesnt show the problem - which will be that SIG_bit is not assigned in every state.
 

Re: Xst:737 - Found 1-bit latch for signal <SIG_bit>.

dpaul said:
The answer is given in the warning message.
If you anyone else to debug your code, you have to post the entire code. You code shows only 1 state 'generate_bs'.
Click to expand...

TrickyDicky said:
You need to post the entire code, not just the snippet, as this doesnt show the problem - which will be that SIG_bit is not assigned in every state.
Click to expand...

I suspect the only place that SIG_bit is assigned is in the generate_bs state, which is why the OP only posted that snippet of code.

Add a default setting for SIG_bit before the case.
1. If you don't care about the SIG_bit value outside the generate_bs state then assign it with either '1' or '0'
2. If you need it to hold the last value that was assigned in generate_bs, then assign SIG_bit <= SIG_bit;
 
Re: Xst:737 - Found 1-bit latch for signal <SIG_bit>.

ads-ee said:
I suspect the only place that SIG_bit is assigned is in the generate_bs state, which is why the OP only posted that snippet of code.
Click to expand...
I got the reason for the warning, ads-ee is right, i had assigned SIG_bit only in this state. So I have to assign it in all states with some value.
 

Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incomplet

I am getting lot of warnings Xst:737, I know the reason also, but I don't know how to do away with them. Can anybody suggest me specific changes...
The code is here:
Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
 
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
 
entity ram_FSM is
     generic (
        ADDR_WIDTH       : integer := 8;        
        DATA_WIDTH       : integer := 8;
                N : INTEGER := 16); -- N x N image size
    Port ( clk : in  STD_LOGIC;
                we : out STD_LOGIC;
                din : in unsigned(DATA_WIDTH-1 downto 0);
                dout : out unsigned(DATA_WIDTH-1 downto 0);
                address : out STD_LOGIC_VECTOR(ADDR_WIDTH-1 downto 0);
                stream: out STD_LOGIC_VECTOR(1 downto 0));-- 00 means 0, 01 => 1, 10 => 10, 11 => no output 
    -- output 0 => pixel insig, 1 => pixel significant, 10 => pixel significant and positive                
end ram_FSM;
 
architecture Behavioral of ram_FSM is
    
                                            -- SPIHT SIGNALS --
    SIGNAL BL : STD_LOGIC_VECTOR(N*N/4-1 downto 0);-- N*N/8 block locations need to be initialized
    SIGNAL SIG : STD_LOGIC_VECTOR(N*N-1 downto 0):= (OTHERS => '0');
    SIGNAL threshold : UNSIGNED(7 downto 0) := "10000000";
    SIGNAL BL_addr : INTEGER RANGE 0 TO N*N/4-1 := 0;
    SIGNAL PX_addr,p1_addr : INTEGER RANGE 0 TO N*N-1 := 0;
    SIGNAL str : STD_LOGIC_VECTOR(1 downto 0);
    
                                            -- FSM SIGNALS --
    TYPE state IS (init, load_nx_block, load_pixel, bs_generate, no_block_check);
    SIGNAL pr_state, nx_state, var_state : state;
    SIGNAL p_count: INTEGER RANGE 0 to 3 := 0;
    CONSTANT one : STD_LOGIC_VECTOR(7 downto 0) := "00000001";
begin
 
--  with pr_state select
--      p_count <=  p_count + 1 when bs_generate
--                      p_count when others;
--  with pr_state 
                                ----- FSM STARTS FROM HERE ----
    -- Lower Section of FSM --
lower:PROCESS(clk)
    BEGIN
        IF clk'EVENT AND clk = '1' THEN
            pr_state <= nx_state;
        END IF;
    END PROCESS lower;
    
    
    -- INITIALIZATION --
    l3: PROCESS(nx_state,p_count)
            BEGIN
                IF nx_state = init THEN
                    BL(N*N/64-1 downto 0) <= (OTHERS => '1');
                END IF;
            END PROCESS l3;
    
    -- PIXEL ADDRESS GENERATOR --   
l1:PROCESS(nx_state,p_count,BL_addr)
    BEGIN
        IF nx_state = load_pixel THEN
            IF p_count = 0 THEN
                p1_addr <= 4*BL_addr;
            ELSIF p_count = 1 THEN
                p1_addr <= 4*BL_addr + 1;
            ELSIF p_count = 2 THEN
                p1_addr <= 4*BL_addr + 2;
            ELSE
                p1_addr <= 4*BL_addr + 3;
            END IF;
        END IF;
    END PROCESS l1;
    
    -- BITSTREAM GENERATOR --
l2:PROCESS(nx_state,p_count,din,threshold,SIG)
    BEGIN
        IF nx_state = bs_generate THEN
            if (din >= threshold) AND (SIG(p1_addr) = '0') then
                str <= "10";
                dout <= din - threshold;
                SIG(p1_addr) <= '1';
            elsif (din >= threshold) AND (SIG(p1_addr) = '1') then
                str <= "01";
                dout <= din - threshold;
                SIG(p1_addr) <= '1';
            else
                str <= "00";
            end if;
        END IF;
    END PROCESS l2;
    
    -- Upper Section of FSM --
upper:PROCESS(pr_state, p_count,p1_addr,str,BL)
 
    --  VARIABLE out_count : INTEGER RANGE 0 TO 9 := 0;
    BEGIN
        CASE pr_state IS
            WHEN init =>
                BL_addr <= 0;
                nx_state <= load_nx_block;
            WHEN load_nx_block =>
                BL_addr <= BL_addr + 1;
                p_count <= 0;
                if BL(BL_addr) = '1' then
                    nx_state <= load_pixel;
                else
                    nx_state <= load_nx_block;
                end if;
            WHEN load_pixel =>
                address <= std_logic_vector(to_unsigned(p1_addr,ADDR_WIDTH));
                we <= '0';
                nx_state <= bs_generate;
            WHEN bs_generate =>
                if p_count = 3 then
                    p_count <= 0;
                    stream <= str;
                    nx_state <= no_block_check;
                else
                    p_count <= p_count + 1;
                    stream <= str;
                    nx_state <= load_pixel;
                end if;
                we <= '1';
            WHEN no_block_check =>
                if BL_addr >= N*N/4-1 then
                    nx_state <= init;
                else
                    nx_state <= load_nx_block;
                end if;
        END CASE;
    END PROCESS upper;      
end Behavioral;
The warnings are (a few are as below):
Xst:737 - Found 8-bit latch for signal <address>. 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.

Xst:737 - Found 8-bit latch for signal <dout>. 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.

Xst:737 - Found 1-bit latch for signal <SIG_255>. 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.
Click to expand...
Same Warning for all SIG_0 to SIG_255
 
Last edited by a moderator:

Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

I merged the new post with your previous same topic thread, because the problem has been already discussed.

You are using a FSM template with a registered and a combinational process. As you already know, assigning a signal in the combinational process conditionally creates latches.

Question is what you want to achieve? Either the latch is unwanted, this can be easily fixed by assigning default values to all signals in the combinational process. Or you want the signal to be preserved over FSM states, then it should be assigned in a registered (clock driven) process.

A convenient solution can be a single process FSM scheme.
 

Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

The signals need to be preserved. I want to assign the signals in other states like this(because its value should not change in other states):
SIG <= SIG;
but, it does not remove the warnings.
 

Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

As already stated, signals you want to preserve should be assigned in a clocked process. You need to reconsider the overall FSM layout.
 

Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

"SIG" is part of the extended state of the fsm. You want to have a nx_SIG and assign SIG <= nx_SIG in the clocked process. There are several other examples of this in the design, mostly related to using nx_state comparisons as the clock for p1_addr, str, dout.

Latches are often unintended and can be dangerous. For example, a comparison to state could easily result in glitches if the bits have different routing delays. This could result in the latched value being corrupted.

The specifics of what can be allowed can be difficult to enumerate -- the latches don't always cause errors. However, proving they can't cause errors is time consuming.
 

Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

To make it easier, I have modified the code and I am presenting the code as below:
Code: 
entity warningcheck is
    Port ( clk : in  STD_LOGIC);
end warningcheck;

architecture Behavioral of warningcheck is
	SIGNAL SIG : STD_LOGIC_VECTOR(31 downto 0):= (OTHERS => '0');
	SIGNAL SIG_addr : INTEGER RANGE 0 TO 31 := 0;

	TYPE state IS (init, exit1);
	SIGNAL pr_state, nx_state : state;
begin
-- PROCESS FOR GENERATING SIG_addr --
count : PROCESS (clk)
		BEGIN
				IF clk'event AND clk = '1' THEN
					IF SIG_addr >= 31 THEN
						SIG_addr <= 0;
					ELSE
						SIG_addr <= SIG_addr + 1;
					END IF;
				END IF;
		END PROCESS count;
-- Lower Section of FSM --
lower : 	PROCESS (clk)
			BEGIN
				IF clk'event AND clk = '1' THEN
						pr_state <= nx_state;
				END IF;
			END PROCESS lower;
-- Upper Section of FSM --
upper :	PROCESS(pr_state)
			BEGIN
				CASE pr_state IS
					WHEN init =>
						SIG(SIG_addr) <= '1';
						nx_state <= exit1;
					WHEN exit1 =>
						SIG(SIG_addr) <= '0';
						nx_state <= init;
				END CASE;
			END PROCESS upper;
end Behavioral;

The warning occurs because :
1. I have assigned only one bit of the signal SIG in each state and
2. I require to assign all bits in the vector signal SIG.
3. But my SIG_addr is dynamic and
4. I want to keep all other bits in signal SIG unaffected.

Can anybody tell me how to assign all bits of signal SIG and at the same time keep them unaffected?
 

Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

rafimiet said:
Can anybody tell me how to assign all bits of signal SIG and at the same time keep them unaffected?
Click to expand...

Assign SIG in a clocked process.
 
Re: Xst:737 - Found 2-bit latch for signal <SIG>. Latches may be generated from incom

OP, you don't seem to get it...VHDL is a hardware description language, it is not a programming language.

You are coming at the problem from a algorithmic and programming mindset. You need to think in terms of digital circuit design and figure out how to implement the algorithm in a digital circuit (schematic) before you describe that circuit in VHDL.

Case in point: you keep using process (some_signal_names) creating combinational logic in an FPGA that requires STORAGE. This a very programming algorithmic view of VHDL and is not good for synthesis.

There are three ways to store data in an FPGA
1. RAM
2. Flip-flops
3. Combinational Latches

Of the three #3 is the worst way to do that in an FPGA as the tools don't work well at constraining the timing of a latch. Even in ASIC designs most of the time you have to really justify the use of a latch and you better be able to prove you have the constraints to ensure it works across PVT. So don't use combinational latches.

Any kind of feedback that is required in a combinational process will likely generate latches. By not specifying all bits in an assignment you are automatically saying that the other bits must not be changed (ergo a feedback path is formed).

Get rid of your mind lock on using a two process FSM. USE ONE PROCESS with the following structure:
Code VHDL - [expand]
1
2
3
4
5
6
7
8

process (clk, rst)
begin
  if (rst = '1') then
    -- stuff to reset
  elsif (rising_edge(clk)) then
    -- all the code goes in this section, and I mean all of it: FSM, outputs, everything.
  end if;
end process;


If you code like that you won't have any latches anywhere in your design.

When you get better at understanding VHDL hardware descriptions then you can start splitting the code into multiple process statements (but only using clocked processes, rising_edge(clk)). IMO using a combination of clocked/combinational and variable types is more of an advanced usage of VHDL and you definitely need to know what hardware a VHDL description will produce.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top