Help with resolving warning “inferring latch(es) for signal or variable ”..“, which holds its previous value in one or more paths through the process”

intel-fpgaquartus-iivhdl

Below is the code for my branch unit implementation. This unit calculates the jump destination address and writes it into the PC register.

There are a few different types of jumps, etc, standard story.

library IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;
USE work.defPaket.all;

entity BR_UNIT is
Port ( 
    CLK                 : in  STD_LOGIC; -- clock
    RST                 :       in  STD_LOGIC;

    N                       : in  STD_LOGIC; -- negative
    Z                       : in  STD_LOGIC; -- zero
    C                       : in  STD_LOGIC; -- carry
    V                       : in  STD_LOGIC; -- overflow

    flushfifo           : out STD_LOGIC;
    pcOUT                   : out STD_LOGIC_VECTOR (31 downto 0);
    pcWrEn              : out STD_LOGIC;

    in1                 : in STD_LOGIC_VECTOR (31 downto 0); --input1
    in2                 : in STD_LOGIC_VECTOR (31 downto 0); --input1

    validOut                : out STD_LOGIC; --output
    wr_reg              : out STD_LOGIC;
    regOut              : out STD_LOGIC_VECTOR (4 downto 0);
    dataVal             : out STD_LOGIC_VECTOR (31 downto 0)
);

end BR_UNIT;

architecture Behavioral of BR_UNIT is

signal opc              : STD_LOGIC_VECTOR (4 downto 0);
signal newpc            : STD_LOGIC_VECTOR (31 downto 0);
signal offset           : STD_LOGIC_VECTOR (31 downto 0);

signal validOut_t       : STD_LOGIC;
signal wr_reg_t     : STD_LOGIC;
signal regOut_t     : STD_LOGIC_VECTOR (4 downto 0);
signal dataVal_t        : STD_LOGIC_VECTOR (31 downto 0);
signal pcOUT_t          : STD_LOGIC_VECTOR (31 downto 0);
signal pcWrEn_t     : STD_LOGIC;
signal flushfifo_t  : STD_LOGIC;

begin

clk_part : process (CLK)

begin

if (CLK'event and CLK = '1') then
    validOut <= validOut_t;
    wr_reg <= wr_reg_t;
    regOut <= regOut_t;
    dataVal <= dataVal_t;
    pcOUT <= pcOUT_t;
    pcWrEn <= pcWrEn_t;
    flushfifo <= flushfifo_t;
end if;

end process;

comb_part : process (in1, in2, N, Z, C, V)
    variable temp : signed(31 downto 0);

    begin

    if(
        (in1(31 downto 27) = OPC_BEQ) or
        (in1(31 downto 27) = OPC_BGT) or
        (in1(31 downto 27) = OPC_BHI) or
        (in1(31 downto 27) = OPC_BAL) or
        (in1(31 downto 27) = OPC_BLAL)
    ) then

        opc <= in1(31 downto 27);

    elsif(
        (in2(31 downto 27) = OPC_BEQ) or
        (in2(31 downto 27) = OPC_BGT) or
        (in2(31 downto 27) = OPC_BHI) or
        (in2(31 downto 27) = OPC_BAL) or
        (in2(31 downto 27) = OPC_BLAL)
    ) then

        opc <= in2(31 downto 27);

    end if;

    offset <= std_logic_vector(resize(signed(in1(26 downto 0)), 32));
    temp := signed(offset) + signed(in1(8 downto 1)) + 1;
    newpc <= std_logic_vector(signed(temp));

    regOut_t <= "00000";
    validOut_t <= '1';

        case opc is

            when OPC_BEQ =>
                if (Z = '1') then
                    flushfifo_t <= '1';
                    pcOUT_t <= newPC;
                    pcWrEn_t <= '1';
                end if;

            when OPC_BGT =>
                if (((N xor V) or Z) = '0') then
                    flushfifo_t <= '1';
                    pcOUT_t <= newPC;
                    pcWrEn_t <= '1';
                end if;

            when OPC_BHI =>
                if ((C or Z) = '0') then
                    flushfifo_t <= '1';
                    pcOUT_t <= newPC;
                    pcWrEn_t <= '1';
                end if;

            when OPC_BAL =>
                    flushfifo_t <= '1';
                    pcOUT_t <= newPC;
                    pcWrEn_t <= '1';

            when OPC_BLAL =>
                    flushfifo_t <= '1';
                    pcOUT_t <= newPC;
                    pcWrEn_t <= '1';

                    regOut_t <= "00000";
                    dataVal_t <= newpc; 
                    wr_reg_t <= '1';

            when OTHERS =>
        end case;

end process;

end Behavioral;

Quartus altera throws the following warnings:

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(94): signal "offset" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(100): signal "opc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(105): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(112): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(119): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(125): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(130): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(134): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "opc", which holds its previous value in one or more paths through the process

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "flushfifo_t", which holds its previous value in one or more paths through the process

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "pcOUT_t", which holds its previous value in one or more paths through the process

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "pcWrEn_t", which holds its previous value in one or more paths through the process

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "dataVal_t", which holds its previous value in one or more paths through the process

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "wr_reg_t", which holds its previous value in one or more paths through the process

Regarding these warnings about signals not being in the sensitivity list, how do I resolve that? Should I skip using them whenever possible or use variables where not possible?

The big and the main question is: what do these errors mean:

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "opc", which holds its previous value in one or more paths through the process

What do they mean and what are your suggestions on how to resolve them?

Best Answer

I'm guessing that like me, you probably come from a software development background and are now learning HDL.

The when others case is empty; that's where you are implicity making all the latches. You clear this warning by explicitly setting the output's next value to its previous value, like x <= x;. Remember this is a Hardware Description Language, not a procedural computer programming language. So you have to think in terms of what actual hardware you expect each module to implement.

As a general rule, when you have a case statement, each clause (i.e. each "execution path" though that's the wrong terminology) -- should define the value of each of the statement's output ports, even if there is no change intended. There are certain code patterns that HDL synthesis tools recognize, and for best results you should try to stick with those forms whenever possible.

Response to the comment:

There's two kinds of warning mesasges here.

Warning # 10492 seems to indicate that an input signal is missing from the sensitivity list.

Warning (10492): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(105): signal "newpc" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

In the delcaration

comb_part : process (in1, in2, N, Z, C, V)

the sensitivity list only declares in1, in2, N, Z, C, V as the available input signals. In terms of hardware, this is like declaring that comb_part is implemented with some hardware block that has these six inputs -- and then oh by the way, surprise, here's this other signal called offset, which looks like it was meant to be another input.

offset <= std_logic_vector(resize(signed(in1(26 downto 0)), 32));

So because this is a non-blocking assignment statement, offset must be some kind of signal, but is it an internal register or an output? The HDL compiler can't tell of that's what was intended, thus the error message.

Recommended fix is that you need to review your design and determine whether you need to add those inputs to the sensitivity list.

Warning # 10631 seems to indicate that an output signal has an inferred latch.

Warning (10631): VHDL Process Statement warning at IDEXWBBranchUnit.vhd(66): inferring latch(es) for signal or variable "flushfifo_t", which holds its previous value in one or more paths through the process

In software it's assumed that variables hold their value until explicitly changed, but in HDL synthesis that requires a latch or a flip-flop. When you have an HDL module that describes code in terms of "behavioral" statements like if/else, or swtich/case, and there is at least one non-blocking assignment to a signal, then every "execution path" should explicity make a non-blocking assignment to that signal.

    case opc is

        when OPC_BEQ =>
            if (Z = '1') then
                flushfifo_t <= '1';
                pcOUT_t <= newPC;
                pcWrEn_t <= '1';
            end if;
        -- etc...
        when OPC_BLAL =>
                flushfifo_t <= '1';
                pcOUT_t <= newPC;
                pcWrEn_t <= '1';
                regOut_t <= "00000";
                dataVal_t <= newpc; 
                wr_reg_t <= '1';
        when OTHERS =>
                -- [MarkU] here's the problem, missing non-blocking assignments should go here
                flushfifo_t <= flushfifo_t;
                pcOUT_t <= pcOUT;
                pcWrEn_t <=pcWrEn_t;
                -- [MarkU] and so on for all the non-blocking assignments that are unchanged in this case
    end case;

Related Solutions

LED PWM controller

You are performing a division and a multiplication operation on a signal. At least the multiplication is mapped to a hardware multiplication circuit on your FPGA.

Your module provides the generic parameter N, which could also be called PWM_RESOLUTION. Beside this, I miss two additional parameters or constants in your module:

The clock frequency of the system clock
The pwm output frequency [Notice: don't forget that pwm signals have a fixed frequency but variable duty cycle.]

One easy way to build a pwm generator is to use two counters:

Counter 1 is a frequency divider, which divides the system clock into \$2^N \cdot f_{pwm}\$ Hz
Counter 2 counts \$2^N\$ cycles on every tick from counter 1

Here some calculations for the frequency counter:

constant PWM_FREQ          : freq     := 25 kHz;
constant SYSTEM_CLOCK_FREQ : freq     := 100 MHz;

constant STEPS             : positive := 2**N;
constant STEP_FREQ         : freq     := PWM_FREQ * STEPS;
constant FREQ_COUNTER_MAX  : positive := TimingToCycles(to_period(STEP_FREQ), SYSTEM_CLOCK_FREQ);
constant FREQ_COUNTER_BITS : positive := log2ceilnz(FREQ_COUNTER_MAX);

signal Freq_Counter  : unsigned(FREQ_COUNTER_BITS - 1 downto 0) := (others => '0');
signal Pulse_Counter : unsigned(N - 1 downto 0)                 := (others => '0');

Some hints on the compact code above:

freq is a new physical type representing a frequency - you can also use the real type
to_period converty a frequency into a period (a time)
TimingToCyles is a function which calculates how many cycles must pass until a given timing (period) has elapsed at a given circuit frequency.
log2ceilnz (logarithm dualis, round up, not zero) calculates \$max(1, \lceil log_2(x)\rceil)\$

Example 1:
If N=4 the pwm signal can have 16 duty cycle steps. Counter 1 is running at 400 kHz. This equals a period of 2.5 us, which need 250 cycles at 100 MHz to achieve this timing. A 8 bit signal is needed for counter 1.

The output is then a simple comparison:

PWMOut <= to_sl(PulseCounters < unsigned(PWMIn));

This code does not prohibit the input of PWMIn=0 to produce a flat-line output, which would not be a correct pwm signal (100% low, 0% high, no edges -> no frequency)

Example 2:
If PWMIn is 3 ("0011") then PWMOut is '1' for counter values 0,1,2 else '0'.

Using a Counter to Determine next MSB position in polynomial division

I assume that ctr_reg is of type (un)signed because it's a counter.

VHDL expect normal indices to be of type integer (natural, positive are subtypes of integer). See the definition for std_logic_vector:

type STD_LOGIC_VECTOR is array (NATURAL range <>) of STD_LOGIC;

So you must convert your counter from (un)signed to integer:

if (numerator(to_integer(ctr_reg)) = '1') then

If ctr_reg is of type std_logic_vector (slv), then you must also convert slv to unsigned:

if (numerator(to_integer(unsigned(ctr_reg))) = '1') then

If this construct is to long, write a function (let's say to_index(..)) which hides these conversions :)

if (numerator(to_index(ctr_reg)) = '1') then

A definition for to_index(..) can be found here.

Edit 1:

List of commonly used packages in VHDL:

library IEEE;
use     IEEE.STD_LOGIC_1164.ALL;  -- common std_logic(_vector) operations
use     IEEE.NUMERIC_STD.ALL;     -- defines signed and unsigned and their operations

Best Answer

Related Solutions

LED PWM controller

Using a Counter to Determine next MSB position in polynomial division

Related Topic