3.2. Описание структур на языке vhdl

По форме структурные и поведенческие архитектурные тела не различаются. Различие состоит в составе используемых операторов и деклараций.

В разделе объявлений SAB, кроме характерных для любых архитектурных тел деклараций, таких как декларации типов, сигналов, констант, включаются специфические подразделы: обязательный подраздел декларации прототипов используемых компонентов и необязательный подраздел объявления конфигураций. Раздел операторов SAB содержит операторы вхождения компонентов, которые, собственно, и определяют порядок соединения компонентов. Могут включаться и другие параллельные операторы, а если таких операторов относительно много, подобное архитектурное тело называют смешанным, или структурно-поведенческим.

Каждому модулю, используемому в качестве структурного компонента в SAB, должно сопутствовать объявление прототипа. Синтаксис декларации прототипа компонента имеет вид:

COMPONENT <имя ENTITY компонента> IS

[ <образ настройки>]

<образ порта>

END COMPONENT [ < имя ENTITY компонента >];

Здесь <образ настройки> и <образ порта> — являются прямой копией высказываний GENERIC и PORT из текста декларации ENTITY соответствующего компонента.

Если в устройстве есть несколько одинаковых модулей, то прототип декларируется только один раз. Тем не менее, каждому экземпляру, включаемому в проект, при структурном описании присваивается собственное имя. Это собственное имя предъявляется в разделе операторов архитектурного тела в виде метки оператора вхождения компонента.

В подразделе объявления сигналов обязательно объявление всех соединений между блоками. Каждый такой сигнал относят к типу, определенному в разделе PORT модуля, к которому он подключен.

Основными операторами SAB являются операторы вхождения компонентов (Component Instantiation Statement), которые определяют порядок соединения включаемых в проект модулей и, возможно, их параметры. Синтаксис оператора вхождения определяется следующим образом:

<оператор вхождения компонента> ::=

<метка вхождения> : ([ COMPONENT ] <имя компонента>

GENERIC MAP (<список соответствий параметров настройки>)

PORT MAP

(<список соответствий порта>);

<список соответствий> ::=

([ <формальный параметр>] =><фактический параметр>

«,[ <формальный параметр> ] => <фактический параметр>»

)

Для параметров настройки фактическим параметром может быть только константное выражение, а для порта – только имя сигнала либо имя порта "главного" модуля. Нельзя объявлять в качестве фактического параметра в списке соответствий порта имя входа или выхода другого компонента. Все связи осуществляются только через объекты, объявленные в текущем архитектурном теле как сигналы. (В принципе, объявление сигналов может осуществляться в общедоступном модуле PACKAGE.)

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

При записи списка соответствий возможны полная и сокращенная формы записи. В сокращенной записи (без формальных параметров) все элементы списков соответствий записываются в том же порядке, как в списках параметров и сигналов порта данного компонента. Если используется полная форма списка соответствий, то порядок записи элементов в списке произволен.

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

Рассмотрим в качестве примера структурное описание логической схемы, приведенной на рис. 3.1.

Рис. 3.1. Простое логическое устройство

Предположим, что в библиотеку используемой САПР скомпилированы образы необходимых компонентов:

Универсальный элемент И:

ENTITY uand IS

GENERIC ( n : INTEGER, -- коэффициент объединения по входу

m : INTEGER); -- коэффициент разветвления по выходу

PORT (x : IN std_logic_vector (n-1 DOWNTO 0);

y : OUT std_logic) ;

END uand;

Универсальный элемент ИЛИ:

ENTITY uor IS

GENERIC ( n : INTEGER, -- коэффициент объединения по входу

m : INTEGER); -- коэффициент разветвления по выходу

PORT (x : IN std_logic_vector (n-1 DOWNTO 0);

y : OUT std_logic) ;

END uor;

Инвертер:

ENTITY inv IS

GENERIC (n : INTEGER); -- коэффициент разветвления по выходу

PORT (x : IN std_logic;

y : OUT std_logic) ;

END inv;

Тогда структурная модель устройства может быть представлена, как в листинге 3.1.

Листинг 3.1 Структурное описание простого логического устройства

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

ENTITY ex2 IS

PORT (x0, x1, x2 : IN std_logic; z : OUT std_logic);

END ex2;

ARCHITECTURE structure OF ex2 IS

COMPONENT uand IS

GENERIC ( n : INTEGER; m : INTEGER);

PORT (x : IN std_logic_vector (n-1 DOWNTO 0); y : OUT std_logic) ;

END COMPONENT;

COMPONENT uor IS

GENERIC ( n: INTEGER, m: INTEGER);

PORT (x : IN std_logic_vector (n-1 DOWNTO 0); y : OUT std_logic)

END COMPONENT;

COMPONENT inv IS

GENERIC (m: INTEGER);

PORT (x : IN std_logic; y : OUT std_logic) ;

END COMPONENT;

SIGNAL nx1, nx2 : std_logic;-- выходы инверторов

SIGNAL y1, y2 : std_logic; -- выходы элементов И

BEGIN

U1: inv GENERIC MAP(1)

PORT MAP (x => x1, y => nx1);

U2: inv GENERIC MAP (1)

PORT MAP (x => x2, y => nx2);

U3: uand GENERIC MAP (2, 1)

PORT MAP (x(0) => x0, x(1) => x2, y => y1);

U4: uand GENERIC MAP (3, 1)

PORT MAP (x(0) => x0, x(1) => nx1,

x(2)=>nx2, y =>y2);

U5: uor GENERIC MAP (2, 5)

PORT MAP (x(0) => y1, x(1) => y2, y => z);

END ARCHITECTURE structure;

По приведенному примеру следует сделать несколько замечаний.

Во-первых, выполняемые преобразования в программе 3.1 технически могут быть реализованы в форме различных устройств в зависимости от целевой технологии исполнения и дополнительных устанавливаемых разработчиком опций (критериев). В частности обычно приходится иметь дело с противоречивым выбором между быстродействием, потребляемой энергией и занимаемой площадью. «Чистое поведение» часто не обеспечивает гибкого выбора. В приведенной программе 3.1 предполагается выбор параметров компонента на основе параметров настройки. В развитых САПР предусматривается возможность выбора исполнителей из множества различных функционально эквивалентных библиотечных модулей, причем как в автоматическом, так и полуавтоматическом режимах.

Во-вторых, надо иметь в виду, что ряд программ синтеза (например, Leonardo Spectrum) на начальных этапах синтеза автоматически преобразуют «чисто-поведенческие» фрагменты программы в структурное представление подобное листингу 3.1.

Такое описание является исходным материалом для программ размещения и трассировки, а кроме того позволяет строить графический образ схемы соединений (так называемый schematic view) и облегчить вмешательство разработчика в процесс проектирования вплоть до возможности локальной модификации схемы или топологии (правда это относится в большей мере к проектированию заказных БИС).