Great question—let’s break down exactly what’s happening here with your Lattice iCE40 state machine, why your fix worked, and share a more robust solution for the future.

The Root Cause: Uninitialized State Registers & Enumeration Order #

In VHDL, when you declare a signal (like your r_SM_peaks state register) without explicitly setting an initial value, synthesis tools will default to the last value in your enumeration list as the power-on state for the register.

In your original code, your state type was defined as:

type t_SM_peaks is (sm_init_lattice, sm_high_start_up, sm_low_start_up, sm_peaks, sm_end);

Here, sm_end is the final enumeration value. Lattice Diamond’s synthesis tool for the iCE40 thus set r_SM_peaks to start in sm_end when the FPGA powers up. Since your original sm_end state had r_SM_peaks <= sm_end, the state machine got stuck in this loop forever—never reaching sm_init_lattice to generate your required signals.

Why Your Modification Fixed the Problem #

Your two changes worked together to break this deadlock:

1. You re-ordered the enumeration: Moving sm_end before sm_peaks made sm_peaks the final enumeration value, which might have changed the default power-on state. But more critically:
2. You changed the sm_end state transition: Instead of looping back to sm_end, you set r_SM_peaks <= sm_init_lattice. Even if the state machine still started in sm_end (or any unexpected state), the next clock cycle would kick it back to sm_init_lattice, starting your desired signal sequence.

The Robust Solution: Explicit Initialization #

While your fix works, relying on enumeration order or state transitions to "rescue" an uninitialized state machine is fragile—changes to your state list later could reintroduce the bug. The better approach is to explicitly set the initial state of your register, either directly in the signal declaration or via a reset signal.

Option 1: Direct Signal Initialization #

Add an initial value to your state register declaration:

type t_SM_peaks is (sm_init_lattice, sm_high_start_up, sm_low_start_up, sm_peaks, sm_end);
signal r_SM_peaks : t_SM_peaks := sm_init_lattice; -- Explicit initial state

The iCE40 FPGA supports power-on initialization of registers, so this will ensure r_SM_peaks starts in sm_init_lattice when the device powers up.

Option 2: Use a Reset Signal #

If you have a reset signal (asynchronous or synchronous) in your design, use it to set the initial state:

p_ARRAY_INTS_STDLOG_2D : process (i_Clk, i_Rst_n) is
begin
  if i_Rst_n = '0' then -- Asynchronous active-low reset
    r_SM_peaks <= sm_init_lattice; -- Reset to initial state
  elsif rising_edge(i_Clk) then
    case r_SM_peaks is
      when sm_init_lattice => 
        ... 
        r_SM_peaks <= sm_high_start_up;
      when sm_high_start_up => 
        ... 
        r_SM_peaks <= sm_low_start_up;
      when sm_low_start_up => 
        ... 
        r_SM_peaks <= sm_peaks;
      when sm_peaks => 
        ... 
        r_SM_peaks <= sm_end;
      when sm_end => 
        ... 
        r_SM_peaks <= sm_end; -- Restore original loop if needed
      when others => 
        r_SM_peaks <= sm_high_start_up;
    end case;
  end if;
end process p_ARRAY_INTS_STDLOG_2D;

This is even more reliable, as it lets you reset the state machine at any time, not just on power-up.

Did You Make a Mistake? #

Nope—your modification was a clever way to work around the issue, but it’s not the most maintainable long-term. Switching to explicit initialization will prevent this problem from popping up again as you modify your state machine.

内容的提问来源于stack exchange，提问作者Ron