alex1985 0 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба Доброго всем времени суток! Недавно начал изучение 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 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба Приходилось писать автоматы с 50-ю состояниями,таких фич не делал и проблем не замечал.А вот обработку when others делаю всегда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Poluektovich 0 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба Автомат реализован в implicit-стиле (только синхронная логика), поэтому такая проверка необязательна, как и when others. Если был explicit-стиль (комбинационная логика+регистр состояния), то нужно when others использовать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба Автомат реализован в implicit-стиле (только синхронная логика), поэтому такая проверка необязательна, как и when others. Если был explicit-стиль (комбинационная логика+регистр состояния), то нужно when others использовать. Ага,а Вы попробуйте ActiveHDL скормить case без when others.Даже при всех задействованных состояниях :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bad0512 2 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба Доброго всем времени суток! Недавно начал изучение 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 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба Автомат реализован в implicit-стиле (только синхронная логика), поэтому такая проверка необязательна, как и when others. Если был explicit-стиль (комбинационная логика+регистр состояния), то нужно when others использовать. А можно по подробнее про implicit-и -explicit стиль? И еще вопрос: сигнал input в данном примере должен быть синхронный? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alex1985 0 31 марта, 2012 Опубликовано 31 марта, 2012 · Жалоба В данном случае else писать необязательно, однако тут это приведено как пример "хорошего" кода, в том плане, что необходимо всегда описывать все возможные состояния, то есть написав if всегда не забываем про else, написав when ... не забываем про others. Это важно в плане борьбы с внезапно возникающими latches. Т.е. это как в том анекдоте про программиста, который на ночь ставит полный стакан на случай если захочет пить, и пустой - если не захочет :rolleyes: Спасибо, коллега! (я тоже из Томска). Теперь разобрался вроде ;) Кстати, при определенных комбинациях заметил на выходах иногда образуются иголки, которые, впрочем, замечательно устраняются синхронизаторами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bad0512 2 1 апреля, 2012 Опубликовано 1 апреля, 2012 · Жалоба Т.е. это как в том анекдоте про программиста, который на ночь ставит полный стакан на случай если захочет пить, и пустой - если не захочет :rolleyes: Спасибо, коллега! (я тоже из Томска). Теперь разобрался вроде ;) Кстати, при определенных комбинациях заметил на выходах иногда образуются иголки, которые, впрочем, замечательно устраняются синхронизаторами. Думаю тут эта аналогия не совсем уместна. Просто рассматривать все возможные варианты входных воздействий - это хороший, правильный стиль кодирования. А то обстоятельство, что в данном конкретном примере менять значение сигнала не нужно - это просто совпадение. Бывают и другие, более сложные варианты. З Ы иголки на выходе - следствие выхода комбинаторной схемы (последний case). Обычно выходы FSM пропускают через триггер дабы исключить иголки.То, что вы называете "синхронизатором". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 2 апреля, 2012 Опубликовано 2 апреля, 2012 · Жалоба Я бы сказал что дело вовсе не в стиле, просто надо понимать что за схема описывается в коде. В данном примере, каждое состояние автомата это физически - триггер с кучей комбинаторики по входу. И в частности, в этой комбинаторной схеме участвует и обратная связь, которая собственно и описана. Так что никакой избыточности кода, все написано наиболее близко к железу, а значит будет правильно синтезировано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dsmv 0 3 апреля, 2012 Опубликовано 3 апреля, 2012 · Жалоба Когда то я тоже начинал тему про описание конечных автоматов. Если интересно, то она здесь На мой взгляд: 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 8 3 апреля, 2012 Опубликовано 3 апреля, 2012 · Жалоба 3. Добавить after 1 ns после назначения сигнала 3 года уж прошло. А воз.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 3 апреля, 2012 Опубликовано 3 апреля, 2012 · Жалоба И еще вопрос: сигнал input в данном примере должен быть синхронный? Да. Все входные сигналы должны быть синхронны clk. Что касается "else state <= s0;" - пишите - это хороший стиль, особенно для начинающих. Кроме того, некоторые строгие синтакс чекеры ругаються на его отсутствие. ...Обычно выходы FSM пропускают через триггер дабы исключить иголки.То, что вы называете "синхронизатором". 1) А чем Вам иголки помешали? Зачем их убирать, если схема синхронна? 2) Убирать иголки можно и правильной кодировкой состояний автомата Мура (напр: 000 -> 001 -> 011 -> 010 ....) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dworfik 0 6 апреля, 2012 Опубликовано 6 апреля, 2012 · Жалоба Вопрос к ..Убирать иголки можно и правильной кодировкой состояний автомата Мура (напр: 000 -> 001 -> 011 -> 010 ....) А простенький код на этот случай покажите? А то использовать type state_type is (s0, s1, s2, s3); как-то стрёмно, мало ли как синтезатор это "скушает", сам подставив нужные состояния по коду Грея. Хорошо, а если ручками делать? Интересует просчитывание переходов в различные места. Поясню: ведь не всегда переход осуществляется из первого состояние во второе (001 -> 011) иногда надо к третьему (001 -> 010). А это уже "иголка". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mad_kvmg 0 6 апреля, 2012 Опубликовано 6 апреля, 2012 · Жалоба А простенький код на этот случай покажите? Вот грамотный дядька пишет. http://www.eeweb.com/blog/ray_salemi/state...s-coding-styles Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 6 апреля, 2012 Опубликовано 6 апреля, 2012 · Жалоба Вот грамотный дядька пишет. 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. возникают сомнения, в каком году он остановился в развитии %) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться