Разница в инициализации конечного автомата между симулятором и синтезатором

Question

Мой вопрос касается первого состояния, используемого в синтезированном автомате.

Я работаю с Lattice iCE40 FPGA, EDA Playground для моделирования и Lattice Diamond Programmer для синтеза.

В следующем примере я генерирую серию сигналов (в примере показаны только строки, относящиеся к конечному автомату). Это прекрасно работает в симуляции; то есть первый случай доступа sm_init_lattice и необходимые сигналы производятся). Тем не менее, синтезированная версия идет прямо к sm_end и остается там. В результате выходной сигнал остается низким.

-- state machine
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;

p_ARRAY_INTS_STDLOG_2D : process (i_Clk) is
begin
  if 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;                        -- peaks completed
      when sm_end =>
        ...
        r_SM_peaks <= sm_end;
      when others =>
        r_SM_peaks <= sm_high_start_up;
    end case;
  end if;

end process p_ARRAY_INTS_STDLOG_2D;

Однако, если я сделаю одно изменение следующим образом (обозначено как "ИЗМЕНЕНИЕ"), я получу набор сигналов, которые мне требуются.

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

signal r_SM_peaks : t_SM_peaks;

p_ARRAY_INTS_STDLOG_2D : process (i_Clk) is
begin
  if 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;                        -- peaks completed
      when sm_end =>
        ...
        -- CHANGE - swapped 'sm_end' for 'sm_init_lattice'
        --r_SM_peaks <= sm_end;
        r_SM_peaks <= sm_init_lattice;             
      when others =>
        r_SM_peaks <= sm_high_start_up;             
    end case;
  end if;

end process p_ARRAY_INTS_STDLOG_2D;

Кто-нибудь может объяснить, что происходит, пожалуйста? Я делаю что-то неправильно? Буду благодарен за любые предложения.

Answer 1

В симуляции, все в VHDL по умолчанию принимает левое значение. В вашем коде это было бы sm_init_lattice, который объясняет, почему ваша симуляция проходит.

Тем не менее, я не вижу сигнала сброса. Таким образом, в вашем оборудовании триггеры, которые хранят состояние вашего FSM, будут сброшены до некоторых состояний, но это, вероятно, не та комбинация, которая представляет sm_init_lattice государство.

Без вашего изменения в аппаратном обеспечении, FSM, возможно, инициализируется к некоторому состоянию рядом sm_end и когда он попадет в это состояние, он останется там. Внося свои изменения, вы позволяете FSM совершать больше кругов по трассе, поэтому он будет проходить через все состояния, независимо от того, в каком состоянии он изначально находится.

Решение состоит в том, чтобы реализовать правильный сброс (либо асинхронный, либо синхронный - люди, работающие с FPGA, похоже, предпочитают синхронный).

Использование перечислимых типов для кодирования конечных автоматов приятно, потому что код легко читается и поддерживается, вам не нужно фиксировать какие-либо кодировки состояний, и вы можете видеть, в каком состоянии вы находитесь, на дисплее формы сигнала. Однако использование перечислимых типов для кодирования конечных автоматов не позволяет моделировать унифицированное состояние, что, вероятно, является причиной вашей проблемы. System-Verilog превосходит VHDL в этом отношении, потому что можно объявить перечислимый тип, который также может быть неизвестен.