[alex1985 0]

Доброго всем времени суток!

Недавно начал изучение VHDL, пытаюсь реализовать автомат Мура, за основу беру шаблон Four-State Moore State Machine из Quartus Templates:

-- Quartus II VHDL Template
-- Four-State Moore State Machine

-- A Moore machine's outputs are dependent only on the current state.
-- The output is written only when the state changes.  (State
-- transitions are synchronous.)

library ieee;
use ieee.std_logic_1164.all;

entity four_state_moore_state_machine is

    port(
        clk         : in    std_logic;
        input     : in    std_logic;
        reset     : in    std_logic;
        output     : out    std_logic_vector(1 downto 0)
    );

end entity;

architecture rtl of four_state_moore_state_machine is

    -- Build an enumerated type for the state machine
    type state_type is (s0, s1, s2, s3);

    -- Register to hold the current state
    signal state   : state_type;

begin

    -- Logic to advance to the next state
    process (clk, reset)
    begin
        if reset = '1' then
            state <= s0;
        elsif (rising_edge(clk)) then
            case state is
                when s0=>
                    if input = '1' then
                        state <= s1;
                    else
                        state <= s0;
                    end if;
                when s1=>
                    if input = '1' then
                        state <= s2;
                    else
                        state <= s1;
                    end if;
                when s2=>
                    if input = '1' then
                        state <= s3;
                    else
                        state <= s2;
                    end if;
                when s3 =>
                    if input = '1' then
                        state <= s0;
                    else
                        state <= s3;
                    end if;
            end case;
        end if;
    end process;

    -- Output depends solely on the current state
    process (state)
    begin
        case state is
            when s0 =>
                output <= "00";
            when s1 =>
                output <= "01";
            when s2 =>
                output <= "10";
            when s3 =>
                output <= "11";
        end case;
    end process;

end rtl;

Вопрос следующий: в ветке выборе состояний написан примерно один и тот же код:

when s0=>
                    if input = '1' then
                        state <= s1;
                    else
                        state <= s0;
                    end if;

Зачем здесь ветка "else state <= s0;"? На это стоит обращать внимание или это просто дано как пример? Другими словами нужно ли выставлять тоже самое состояние, если условие предшествующее его смене не было соблюдено?

Заранее спасибо!

[_sda 0]

Приходилось писать автоматы с 50-ю состояниями,таких фич не делал и проблем не замечал.А вот обработку when others делаю всегда.

[Poluektovich 0]

Автомат реализован в implicit-стиле (только синхронная логика), поэтому такая проверка необязательна, как и when others. Если был explicit-стиль (комбинационная логика+регистр состояния), то нужно when others использовать.

[_sda 0]

Автомат реализован в implicit-стиле (только синхронная логика), поэтому такая проверка необязательна, как и when others. Если был explicit-стиль (комбинационная логика+регистр состояния), то нужно when others использовать.

Ага,а Вы попробуйте ActiveHDL скормить case без when others.Даже при всех задействованных состояниях :rolleyes:

[Bad0512 2]

Доброго всем времени суток!

Недавно начал изучение VHDL, пытаюсь реализовать автомат Мура, за основу беру шаблон Four-State Moore State Machine из Quartus Templates:

-- Quartus II VHDL Template
-- Four-State Moore State Machine

-- A Moore machine's outputs are dependent only on the current state.
-- The output is written only when the state changes.  (State
-- transitions are synchronous.)

library ieee;
use ieee.std_logic_1164.all;

entity four_state_moore_state_machine is

    port(
        clk         : in    std_logic;
        input     : in    std_logic;
        reset     : in    std_logic;
        output     : out    std_logic_vector(1 downto 0)
    );

end entity;

architecture rtl of four_state_moore_state_machine is

    -- Build an enumerated type for the state machine
    type state_type is (s0, s1, s2, s3);

    -- Register to hold the current state
    signal state   : state_type;

begin

    -- Logic to advance to the next state
    process (clk, reset)
    begin
        if reset = '1' then
            state <= s0;
        elsif (rising_edge(clk)) then
            case state is
                when s0=>
                    if input = '1' then
                        state <= s1;
                    else
                        state <= s0;
                    end if;
                when s1=>
                    if input = '1' then
                        state <= s2;
                    else
                        state <= s1;
                    end if;
                when s2=>
                    if input = '1' then
                        state <= s3;
                    else
                        state <= s2;
                    end if;
                when s3 =>
                    if input = '1' then
                        state <= s0;
                    else
                        state <= s3;
                    end if;
            end case;
        end if;
    end process;

    -- Output depends solely on the current state
    process (state)
    begin
        case state is
            when s0 =>
                output <= "00";
            when s1 =>
                output <= "01";
            when s2 =>
                output <= "10";
            when s3 =>
                output <= "11";
        end case;
    end process;

end rtl;

Вопрос следующий: в ветке выборе состояний написан примерно один и тот же код:

when s0=>
                    if input = '1' then
                        state <= s1;
                    else
                        state <= s0;
                    end if;

Зачем здесь ветка "else state <= s0;"? На это стоит обращать внимание или это просто дано как пример? Другими словами нужно ли выставлять тоже самое состояние, если условие предшествующее его смене не было соблюдено?

Заранее спасибо!

В данном случае else писать необязательно, однако тут это приведено как пример "хорошего" кода, в том плане, что необходимо всегда описывать все возможные состояния, то есть написав if всегда не забываем про else, написав when ... не забываем про others. Это важно в плане борьбы с внезапно возникающими latches.

 

[alex1985 0]

Автомат реализован в implicit-стиле (только синхронная логика), поэтому такая проверка необязательна, как и when others. Если был explicit-стиль (комбинационная логика+регистр состояния), то нужно when others использовать.

 

А можно по подробнее про implicit-и -explicit стиль? И еще вопрос: сигнал input в данном примере должен быть синхронный?

[alex1985 0]

В данном случае else писать необязательно, однако тут это приведено как пример "хорошего" кода, в том плане, что необходимо всегда описывать все возможные состояния, то есть написав if всегда не забываем про else, написав when ... не забываем про others. Это важно в плане борьбы с внезапно возникающими latches.

 

Т.е. это как в том анекдоте про программиста, который на ночь ставит полный стакан на случай если захочет пить, и пустой - если не захочет :rolleyes:

Спасибо, коллега! (я тоже из Томска). Теперь разобрался вроде ;) Кстати, при определенных комбинациях заметил на выходах иногда образуются иголки, которые, впрочем, замечательно устраняются синхронизаторами.

[Bad0512 2]

Т.е. это как в том анекдоте про программиста, который на ночь ставит полный стакан на случай если захочет пить, и пустой - если не захочет :rolleyes:

Спасибо, коллега! (я тоже из Томска). Теперь разобрался вроде ;) Кстати, при определенных комбинациях заметил на выходах иногда образуются иголки, которые, впрочем, замечательно устраняются синхронизаторами.

Думаю тут эта аналогия не совсем уместна. Просто рассматривать все возможные варианты входных воздействий - это хороший, правильный стиль кодирования. А то обстоятельство, что в данном конкретном примере менять значение сигнала не нужно - это просто совпадение. Бывают и другие, более сложные варианты.

З Ы иголки на выходе - следствие выхода комбинаторной схемы (последний case). Обычно выходы FSM пропускают через триггер дабы исключить иголки.То, что вы называете "синхронизатором".

 

[Shivers 0]

Я бы сказал что дело вовсе не в стиле, просто надо понимать что за схема описывается в коде. В данном примере, каждое состояние автомата это физически - триггер с кучей комбинаторики по входу. И в частности, в этой комбинаторной схеме участвует и обратная связь, которая собственно и описана. Так что никакой избыточности кода, все написано наиболее близко к железу, а значит будет правильно синтезировано.

[dsmv 0]

Когда то я тоже начинал тему про описание конечных автоматов.

 

Если интересно, то она здесь

 

На мой взгляд:

 

1. Конструкция else state <= s0 - излишняя

 

2. Всё надо делать в одном процессе

 

3. Добавить after 1 ns после назначения сигнала

 

4. сброс вынести в отдельный if:

 

 </p><p>process( clk ) begin</p><p>if( rising_edge( clk ) ) then</p><p>case( state ) is     </p><p>when s0 =>        </p><p>if( input='1' ) then         state <= s1 after 1 ns;       </p><p>end if;      </p><p>output <= "00" after 1 ns; </p><p>when s1 =>   ...end case;
      </p><p>if( reset='1' ) then    </p><p>
   state <= s0 after 1 ns;</p><p>end if;</p><p>end process;

 

 

[sazh 5]

3. Добавить after 1 ns после назначения сигнала

3 года уж прошло. А воз....

[topor_topor 0]

И еще вопрос: сигнал input в данном примере должен быть синхронный?

 

Да. Все входные сигналы должны быть синхронны clk.

 

Что касается "else state <= s0;" - пишите - это хороший стиль, особенно для начинающих.

Кроме того, некоторые строгие синтакс чекеры ругаються на его отсутствие.

 

 

 

 

 

...Обычно выходы FSM пропускают через триггер дабы исключить иголки.То, что вы называете "синхронизатором".

 

1) А чем Вам иголки помешали? Зачем их убирать, если схема синхронна?

2) Убирать иголки можно и правильной кодировкой состояний автомата Мура (напр: 000 -> 001 -> 011 -> 010 ....)

 

[dworfik 0]

Вопрос к

..Убирать иголки можно и правильной кодировкой состояний автомата Мура (напр: 000 -> 001 -> 011 -> 010 ....)

А простенький код на этот случай покажите?

А то использовать

type state_type is (s0, s1, s2, s3);

как-то стрёмно, мало ли как синтезатор это "скушает", сам подставив нужные состояния по коду Грея.

Хорошо, а если ручками делать? Интересует просчитывание переходов в различные места. Поясню: ведь не всегда переход осуществляется из первого состояние во второе (001 -> 011) иногда надо к третьему (001 -> 010). А это уже "иголка".

[Mad_kvmg 0]

А простенький код на этот случай покажите?

Вот грамотный дядька пишет.

http://www.eeweb.com/blog/ray_salemi/state...s-coding-styles

[des00 25]

Вот грамотный дядька пишет.

http://www.eeweb.com/blog/ray_salemi/state...s-coding-styles

может и грамотный, но после таких фраз

Synthesis tools cannot do timing analysis across module boundaries. This means that if you have 10 ns between clocks, then you can run into trouble if generating the combinatorial outputs from one block that takes 6 ns while processing the combinatorial inputs of another block takes 5 ns. Both blocks think they are meeting timing, but together they are not.

You can get glitches on the output signals if they are settling after you’ve changed your state.

Your synthesis tool will miss optimizing opportunities because it cannot see a complete combinatorial circuit that crosses module boundaries.

возникают сомнения, в каком году он остановился в развитии %)