Изучаем Active-HDL 7.1. Урок 14. Стили HDL-кодирования цифрового автомата
Все статьи цикла:
- Урок 1. Знакомство с пакетом
- Урок 2. Как задавать внешние воздействия с помощью стимуляторов
- Урок 3. Альтернативные способы задания внешних воздействий
- Урок 4. Как работать с редактором временных диаграмм
- Урок 5. Создание проекта в текстовом формате
- Урок 6. Инструменты, повышающие эффективность создания HDL-моделей.
- Урок 7. Проектирование схем: размещение электронных компонентов
- Урок 8. Проектирование схем: выполнение соединений
- Урок 9. Инструменты, повышающие эффективность работы с BDE-проектами
- Урок 10. Как проектировать символы
- Урок 11. Как проектировать иерархические блоки
- Урок 12. Проектирование цифровых автоматов
- Урок 13. Методы построения эффективных sde-проектов
- Урок 14. Стили HDL-кодирования цифрового автомата
- Урок 15. Менеджер библиотек
Цифровой автомат — это концептуальное представление последовательностного устройства. Фактически любая цифровая схема с памятью может рассматриваться как конечный автомат или их объединение.
Зависимость реакции выхода от текущего состояния автомата отличает его от комбинационных устройств. Каноническое представление цифрового автомата (ЦА) показано на рис. 1.
Рис. 1. Графическое представление синхронного цифрового автомата с комбинационным выходом
Базовым элементом автомата является регистр состояния SR (от State Register). Он удерживает текущее состояние (Current State) до прихода очередного тактирующего импульса CLK (активного фронта или среза).
В паузе между тактирующими импульсами на входе SR формируется вектор следующего состояния (Next State). Выполняется данная работа комбинационным блоком F-логикой переходов. Выход F зависит от текущего состояния регистра SR и входных воздействий X.
Выходная логика G — тоже комбинационная схема. Она формирует выходные сигналы Y в зависимости от текущего состояния автомата — содержимого регистра SR (автомат Мура). Для автомата Мили выходы зависят еще и от текущих значений входных воздействий X, а потому допускают асинхронное поведение.
Этот небольшой экскурс в теорию автоматов нам понадобился для того, чтобы сделать более понятным разговор о возможных стилях HDL-кодирования ЦА. Графический редактор State Diagram Editor поддерживает разные стили кодирования, и пользователь может комбинировать их по своему желанию (рис. 2).
Рис. 2. Выбор стиля HDL-кодирования ЦА
Впрочем, вариантов не так уж и много. HDL-модель ЦА удобно представлять в виде одного (One Process), двух (Two Processes) или трех (Three Processes) процессов. Внутри каждого процесса по умолчанию предлагается использовать оператор выбора Case, но вы можете отдать предпочтение условному оператору IF.
Модель ЦА в виде трех процессов
Наиболее очевидной представляется VHDL-модель цифрового автомата в виде трех процессов — по числу входящих в него блоков (рис. 1). Посмотрим, каким получается автоматически сгенерированный VHDL-код (рис. 4а) для двоичного суммирующего счетчика с входом разрешения E (рис. 3).
Рис. 3. Диаграмма состояний ЦА с функцией счетчика с входом разрешения E
Рис. 4. а) VHDL-модель ЦА, реализующего двоичный счетчик с входом разрешения E (стиль кодирования — Three Processes); б) имена процессов в окне просмотра проекта Design Browser
Обратите внимание, в самом начале кода декларируются два внутренних сигнала для хранения текущего Sreg0 и следующего NextState_Sreg0 значений регистра состояния. По умолчанию он имеет имя Sreg0.
Поведение автомата имитируется процессом с меткой Sreg0_CurrentState, который запускается любым из сигналов — C или R. На рис. 1 этому процессу соответствует регистр состояния SR, а его выход — сигналу Sreg0.
Логика переходов F (рис. 1) имитируется процессом с меткой Sreg0_NextState. Напомним, что блок F представляет собой комбинационную схему, которая вычисляет следующее состояние автомата. Оно зависит от текущего состояния Sreg0 и вектора входных воздействий (в нашем примере — от единственного входа разрешения E). По этой причине в списке инициализаторов данного процесса мы видим только эти имена (рис. 4).
Блок выходной логики G (тоже комбинационная схема) реализуется процессом Sreg0_OutputBlock. В нашем примере он не содержит входных воздействий X (автомат Мура), поэтому реакция на выходах определяется только текущим содержимым регистра состояний Sreg0. Это имя мы и наблюдаем в списке чувствительности данного процесса.
Рассмотренный стиль кодирования автомата Three Processes задается на диалоговой панели Code Generation Settings (рис. 5), вызываемой из меню FSM. Нам уже приходилось встречаться с этой панелью.
Рис. 5. Диалоговая панель настроек генератора кода редактора SDE
А теперь познакомимся с содержимым каждого процесса, сохраняя прежний порядок рассмотрения. Автоматный процесс Sreg0_CurrentState (рис. 6) описывает поведение ЦА.
Рис. 6. Основной автоматный процесс Sreg0_CurrentState
С приходом сигнала сброса (R=’1′) автомат устанавливается в исходное состояние S1 (SregO <= S1;). С появлением фронта тактирующего сигнала C (C’event and C = ‘1’) автомат переходит в следующее состояние (SregO <= NextState_Sreg0;).
Заметим, что следующее состояние — это не обязательно другое, отличное от текущего состояние. Сейчас мы убедимся в сказанном. Посмотрим, как вычисляется следующее состояние в процессе Sreg0_NextState (рис. 7).
Рис. 7. Содержимое процесса Sreg0_NextState (фрагмент), вычисляющего следующее состояние автомата
Процесс Sreg0_NextState запускается, если изменяется вход E или текущее состояние Sreg0 регистра состояния. Последнее событие может произойти при выполнении предыдущего процесса Sreg0_CurrentState.
Обратите внимание, следующее состояние будет оставаться неизменным, если отсутствует сигнал разрешения счета, то есть E=’0′. Например, для текущего состояния S1 при E=’0′ выполняется оператор NextState_Sreg0 <= S1;, то есть на следующем такте работы автомата сохраняется старое состояние S1.
Выходные сигналы вычисляются в процессе Sreg0_OutputBlock (рис. 8), который запускается только при изменении текущего состояния Sreg0. Например, если автомат переходит в исходное состояние S1, то выполняется оператор Q<=»00″;, и счетчик сбрасывается в ноль.
Рис. 8. Содержимое процесса Sreg0_OutputBlock, вычисляющего значения выходных сигналов
Для пользователей, знакомых с языком VHDL, написать рассмотренные на рис. 6-8 коды не представляет особого труда. Следовательно, для них появляется возможность сразу получить текстовое описание автомата, минуя его промежуточное графическое представление в форме диаграммы состояний.
Более того, в пакете Active-HDL имеется специальный инструмент, позволяющий преобразовать (конвертировать) исходное текстовое описание автомата в графическое.
Конвертор текстового описания проекта в графическое
Он носит имя Code2Graphics и вызывается соответствующей командой из меню Tools («Инструменты»).
Конвертор кода в графику достаточно прост в применении, и мы не станем подробно описывать его работу. Отметим лишь, что он позволяет преобразовывать текстовые проекты не только в диаграммы состояний ЦА, но и в блок-диаграммы (схемы). При этом конвертор, анализируя код, сам разбирается, что делать — схему или диаграмму состояний.
Преобразование текстового описания в графическое удобно выполнять с помощью соответствующего «мастера», вызываемого из меню Tools командой Code2Graphics Conversion Wizard.
Заметим, чтo данная κoмaндa дублируется иконкой ЙЙ, но в стандартной настройке пакета она не видна. При желании вы можете извлечь данную пиктограмму из «запасников», активизировав диалоговую панель Customize.
Диаграмма состояний, сгенерированная по тексту последнего примера (рис. 6-8), выглядит так, как показано на рис. 9.
Рис. 9. Результат работы преобразователя кода в графику Code2Graphics
Сравните ее с оригиналом (рис. 3) и вы увидите, что качество автоматически созданного графического описания вполне приемлемо. Откомпилируйте диаграмму состояний и выполните ее моделирование, чтобы убедиться в том, что ошибок в ней нет.
Главное отличие автоматически полученной диаграммы состояний — на всех альтернативных переходах программа проставляет уровни приоритетов (цифры 1 и 2 в кружках). Приоритеты назначаются чисто формальным путем — в порядке записи условий в операторе IF. В данном случае взаимно исключающие условия переходов не нуждались в задании приоритетов, но программа не обратила внимания на такую «мелочь».
На диалоговой панели Code Generation Settings (рис. 5) в разделе HDL Style можно выбрать еще два варианта — Two Processes и One Process. Любопытно посмотреть, каким будет в этих режимах сгенерированный VHDL-код. Заметим, что по умолчанию задается режим One Process — один процесс.
Модель ЦА в виде двух процессов
Сначала исследуем режим Two Processes, который порождает VHDL-код, показанный на рис. 10. В нем отсутствует процесс Sreg0_ OutputBlock, где ранее вычислялись выходные сигналы.
Рис. 10. а) VHDL-модель ЦА, реализующего двоичный счетчик с входом разрешения E (стиль кодирования Two Processes); б) имена процессов в окне просмотра проекта Design Browser
Система объединила два процесса Sreg0_ OutputBlock и Sreg0_NextState, имитирующих работу комбинационных блоков автомата, в один процесс Sreg0_NextState.
Раскрыв его содержимое (рис. 11), легко заметить, что для каждого состояния в сгенерированный текст добавилось по оператору назначения выходного сигнала. Например, для состояния S1 — это оператор Q<=»00″;.
Рис. 11. Содержимое процесса Sreg0_NextState (фрагмент), вычисляющего следующее состояние автомата
Модель ЦА в виде одного процесса
В режиме One Process картина выглядит еще более любопытной (рис. 12). Единственный процесс Sreg0_machine реализует поведение автомата, а комбинационный выходной сигнал Q вычисляется параллельным оператором условного назначения с меткой Q_assignment.
Рис. 12. VHDL-модель ЦА, реализующего двоичный счетчик с входом разрешения E (стиль кодирования One Process)
Здесь следует сделать оговорку. Формально VHDL-модель автомата, представленная на рис. 12, содержит один процесс. Во всяком случае, ключевое слово «process» встречается там только один раз.
В действительности же оператор условного назначения есть не что иное, как краткая (неявная) форма записи процесса с одним выходным сигналом. Поэтому можно констатировать, что процессов все-таки два.
Сказанное подтверждается содержимым окна просмотра проекта Design Browser (рис. 13). Именно кружком со стрелками, принято обозначать процесс в пакете Active-HDL 7.1. А на рисунке таких кружков все-таки два.
Рис. 13. Окно просмотра проекта Design Browser
Кроме рассмотренных выше стилей HDL-кодирования, вы можете изменить заданные по умолчанию установки и в некоторых других разделах. В частности, в разделе Clock generation (рис. 14) имеется возможность выбрать способ генерации тактирующего сигнала: вместо заданной по умолчанию строки C’event and C = ‘1’ будет сгенерирована строка rising_edge (C). На первый взгляд никакой разницы нет — в обоих случаях выявляется фронт (rising) сигнала C.
Рис. 14. Раздел Clock generation
На самом деле запись C’event and C = ‘1’ менее точна, так как она проверяет только факт переключения сигнала C (C’event) и его новое значение (C = ‘1’). При этом остается неясным, с какого уровня произошло переключение тактирующего сигнала C на ‘1’.
Стандартная функция rising_edge (C) ко всему прочему проверяет, было ли предшествующее значение на входе C нулем (C’last_value = ‘0’). В противном случае функция не возвратит истинное значение, и система забракует такое подозрительное «переключение».
В принципе для обнаружения фронта (или среза) тактирующего сигнала можно использовать оператор ожидания Wait (рис. 15). В этом режиме в текст автоматически генерируемого VHDL-кода будет включаться строка: wait until C’event and C = ‘1’;.
Рис. 15. Использование оператора ожидания Wait
Однако данная опция имеет ограничения и будет работать только при тактируемом сбросе .т- автомата. Для асинхронного сброса έί она игнорируется, о чем говорит соответствующее предупреждение в окне Console:
Ну и, конечно же, следует помнить, что оператор ожидания Wait при синтезе проекта может преподнести неприятные сюрпризы.
Чтобы пользователь ощущал себя комфортно в процессе проектирования диаграмм состояний, разработчики редактора State Diagram Editor снабдили его дополнительными инструментами. Наибольшего внимания заслуживает программа View/Sort Object. Мы с ней встречались в начале 12-го урока. Чтобы активизировать данный инструмент, следует выбрать одноименную команду в меню FSM или щелкнуть по кнопке, расположенной на инструментальной панели FSM Hierarchy Toolbar.
На открывшейся диалоговой панели (рис. 16) приводится информация об основных объектах проектируемой диаграммы состояний.
Рис. 16. Диалоговая панель вспомогательного инструмента View/Sort Object
Каждый класс объектов диаграммы (автоматы, порты, сигналы, константы, состояния и переменные) представлен на отдельной закладке.
Мы уже знаем, что, используя процедуру drag and drop, объекты можно сортировать, определяя тем самым желаемый порядок в процессе автоматической генерации HDL-кода. Но это еще не все.
Выделив объект, можно отредактировать его свойства и тут же найти его на диаграмме состояний. Достаточно лишь щелкнуть на объекте правой кнопкой мыши и выполнить нужную команду (рис. 17).
Рис. 17. Выполнение нужной команды
Выбрав команду Find Object, вы увидите искомый элемент на диаграмме состояний, об-рамленный мигающей рамкой зеленого цвета.
Обычно диаграмма состояний содержит описание одного автомата, однако она позволяет поместить на чертеж и несколько взаимосвязанных автоматов. С такой ситуацией мы встречались на 12-м уроке (рис. 17). В этом случае на закладках States, Variables и Declarations пoявляeτcя дополнительное поле, в котором можно выбрать конкретный автомат и тем самым сузить область поиска.
Еще одним вспомогательным инструментом является так называемый ASF-отчет
(ASF-report). Он создается в HTML-формате и содержит полную информацию о проекте (используемый язык, имя модуля, подключенные к проекту библиотеки и пакеты, описание портов, сигналов, переменных и констант, тип автомата, имя синхросигнала, активный фронт, способ кодирования состояний, дерево иерархии).
Чтобы сгенерировать отчет, выполните команду ASF Report из меню ASF. В случае успешного завершения операции вы получите следующее сообщение (рис. 18), а в окне Console увидите такой текст (рис. 19).
Рис. 18. Сообщение об успешном завершении операции
Рис. 19. Окно Console
В нем констатируется, что результаты записаны в файл сообщений (log file), и предлагается дважды щелкнуть по последней строке, чтобы увидеть его содержимое.
Если данное окно в настоящий момент закрыто, посмотреть файл сообщений можно из окна проекта Design Browser. Для этого придется активизировать правую закладку Resources, раскрыть папку log и выбрать желаемый файл с расширением *.htm.
Еще одно замечание касается редактирования текстов, размещенных на диаграмме состояний. У вас есть несколько возможностей. Двойным щелчком на редактируемом тексте можно открыть небольшое окно прямо на диаграмме и внести требуемые изменения. Этим способом редактируются имена и параметры портов, сигналов, переменных и констант, условия на переходах, текст комментариев, имена состояний.
Более универсальным способом является выбор команды Properties из всплывающего меню. Он работает для всех объектов.
Но не стоит игнорировать и команду контекстного меню Edit Using HDL, которая вызывает диалоговое окно текстового редактора HDL Editor со многими его дополнительными возможностями. Правда, эта команда доступна не для всех текстов, а только для тех, что записаны в формате целевого языка описания аппаратуры. Например, так можно редактировать условия на переходах, действия для состояний и некоторые другие HDL-описания.
Окончание Урок 15. Менеджер библиотек