2.5. Контрольные вопросы

1. Представьте синтаксическое определение и порядок исполнения операторов if, case, loop, условного присваивания, присваивание по выбору.

2. Определите правила и преимущественные области использования типов данных для представления одиночных данных.

3. Как выполняется переход от табличного задания логической функции к алгебраическому?

4. Когда могут возникнуть в схеме «неожиданные» триггеры?

3. Структурное представление устройств

3.1. Структура и поведение

При проектировании аппаратуры применяют представление проекта с различной степенью детализации, иными словами различные модели. Модель, отражающая объект проектирования в форме правил преобразования входных данных в выходные, называется поведенческой. Применяя поведенческое описание, проектировщик абстрагируются от вопросов технической реализации, сосредотачивая внимание на алгоритмических аспектах работы проектируемого изделия, в том числе на отладке алгоритма функционирования. Поведенческое представления обеспечивает лучший уровень взаимопонимания в коллективе разработчиков, а в ряде случаев также и разработчиков с покупателями проекта, включая распространение результатов проектирования как объектов интеллектуальной собственности (IP-блоков). Одним из преимуществ поведенческого описания является возможность относительно легкого переноса описания в различные САПР и для реализации (синтеза) на основе различных технологий.

Большинство практических разработок строятся из блоков, либо стандартных, либо создаваемых параллельно несколькими исполнителями. Структурная модель описывает проект в виде совокупности модулей, каждый из которых реализует определенную часть задачи, и набора связей между ними. Современные САПР способны синтезировать аппаратную реализацию, как на основе поведенческого представления, так и структурного и смешанного. Однако при этом предполагается, что каждый подблок структуры уже имеет свое описание. При проектировании на VHDL это означает, что описаны и доступны ENTITY и архитектурное тело, определяющее поведение или внутреннюю структуру подблока. В конечном счете, необходимо, чтобы для всех модулей проекта в проектной библиотеке содержались поведенческие модели. В том числе, если компоненты модуля представлены структурными моделями, то компоненты таких вложенных структур в свою очередь должны иметь поведенческое описание, и так далее.

Структурная модель является естественным способом создания сложных проектов, описание которых целесообразно выполнить по иерархическому принципу. Структурная модель приближает описание к реальной конфигурации проектируемого устройства, а, как минимум, к представлению разработчика об этой конфигурации, то есть обеспечивает некоторое влияние разработчика на результат синтеза, например, для учета плохо формализуемых требований к проекту. К тому же надо иметь в виду, что компилятор при синтезе на базе «чисто поведенческого» описания может синтезировать недостаточно эффективные реализации.

Использование структурных моделей кроме того обеспечивает возможность:

- использования широкого набора типовых компонентов, содержащихся в библиотеках систем автоматизированного проектирования;

- многократного использования ранее созданных проектной группой узлов в новых проектах (так называемый процесс reusing);

- параллельной «доработки» фрагментов проекта несколькими разработчиками.

Большинство современных языков проектирования аппаратуры поддерживают возможность описания проекта, как в поведенческой форме, так и в виде совокупности заранее описанных компонентов и их связей (то есть в структурной форме), и язык VHDL не является исключением.

Всякая иерархия представлена главным проектным модулем, который называют вершиной проекта, и совокупностью подчиненных проектных модулей. Вершина проекта содержит объявления портов и внутренних связей, а также так называемые операторы вхождения компонентов (INSTANTION STATEMENT), т. е. определенные синтаксисом языка указания на включенные компоненты и способ их соединений. В VHDL такое описание называют структурным архитектурным телом (SAB – structural architectural body). Подчиненный проектный модуль может быть, в свою очередь, вершиной следующей иерархии. В общем случае, проектные модули независимы в том смысле, что каждый может использоваться самостоятельно в различных конструкциях и быть вершиной проекта. Проектные модули, относящиеся к одному проекту, могут находиться в одном файле или представляться несколькими файлами. В последнем случае проектные файлы должны компилироваться в библиотеку проекта в порядке их вхождения в иерархию снизу вверх.