Comments 5
> Для того, чтобы избежать <<залипания>> ЦА в неописанных состояниях необходимо явно прописывать действия в
> таких ситуациях с помощью конструкции when… others.
> WHEN OTHERS =>
> state <= init;
Тут грубая ошибка в изложении. Конструкция when others при описании автомата через собственный тип данных никак не поможет в выходе из невалидных состояний. Ибо в рамках case рассматривается только множество состояний, соответсвующее типу state'а. А все прочие двоичные состояния будут синтезатором оптимизироваться самостоятельно. Если хочется создать надежный конечный автомат, то либо явно определяете количество состояний равное степени двойки и устанавливаете тип кодирования «двоичный» (тупиковый подход), либо используете директивы-констрэйны для явного указания синтезатору создавать автомат, выходящий из невалидных стостояний. В Quartus параметр называется «Safe state machine», у Xilinx сейчас не помню.
> таких ситуациях с помощью конструкции when… others.
> WHEN OTHERS =>
> state <= init;
Тут грубая ошибка в изложении. Конструкция when others при описании автомата через собственный тип данных никак не поможет в выходе из невалидных состояний. Ибо в рамках case рассматривается только множество состояний, соответсвующее типу state'а. А все прочие двоичные состояния будут синтезатором оптимизироваться самостоятельно. Если хочется создать надежный конечный автомат, то либо явно определяете количество состояний равное степени двойки и устанавливаете тип кодирования «двоичный» (тупиковый подход), либо используете директивы-констрэйны для явного указания синтезатору создавать автомат, выходящий из невалидных стостояний. В Quartus параметр называется «Safe state machine», у Xilinx сейчас не помню.
Большое спасибо, обязательно учту. О кодировании будет еще статья — там слишком много.
Не совсем так. Многие системы разработки по умолчанию реализуют машину с 1 битом на состояние, а не набор взвешенных битов. Тогда неуказанные состояния просто не существуют и заботиться о них вообще не нужно (видимо для этого такой подход и принят). По сути, автомат представляет собой кольцевой сдвиговый регистр с цепью установки начального значения. Но надо иметь в виду, что подобный подход при проблемах с синхронизацией может приводить к катастрофическим последствиям (думал об этом пост бросить более подробно, но тема специфическая, так что ограничусь комментарием).
В Железе не бывает состояний, которых не существует. В двоичном состоянии они все равно продолжают существовать и если автомат случайно (сбой питаний, космические лучи и т.д.) залетит в такое состояние, то дальнейшая его судьба непредсказуема.
Еще нужно учесть метод кодирования состояний. В данной статье — это One Hot. Здесь используется один триггер на одно состояние. Т.е. если 5 состояний — 5 триггеров. А тогда неиспользуемых состояний 2^5 — 5 = 32 -5 = 27 штук. Они никуда не денутся. Сбои могут выбрасывать автомат в эти состояния и тогда он в них остается и выйти их них можно только выключением питания, если ничего другого не предусмотрено. В VHDL метод кодирования задается атрибутом enum_encoding.
А пост по катастрофическим последствиям с радостью почитаю.
А пост по катастрофическим последствиям с радостью почитаю.
Sign up to leave a comment.
Описание цифровых автоматов на VHDL