Действительно ли нам нужен VHDL

       

Испытание Проекта при помощи Испытательного стенда


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 9

Испытание Проекта при помощи Испытательного стенда

Содержание Главы 9

9.1. Краткий обзор Главы

9.2. Введение к Испытательным стендам

9.2.1. Что такое - Испытательный стенд?

9.2.2. VHDL Испытательные стенды

9.2.3. Компоненты VHDL Испытательного стенда

9.2.4. Использование Испытательных стендов

9.3. Структура Испытательного стенда

9.3.1. Объект Испытательного стенда

9.3.2. Тестируемый Блок

9.3.3. Стимулы Сигналов



9.3.4. Операторы Утверждения

9.3.5. Сообщение с Утверждениями

Резюме

9.1. Краткий обзор Главы

Это - последняя глава нашего руководства по VHDL, и она посвящена испытательным стендам - методу испытания VHDL проектов в окружающей среде VHDL.

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

Секция 3 рассматривает глубже внутреннюю структуру испытательного стенда. При этом отображаются три характерных элемента испытательных стендов: Объект без портов, инстоляция блока при помощи теста (UUT) и стимулами формы сигнала.

9.2.1. Что такое - Испытательный стенд?

Ключевые вопросы:

Процесс проекта неполон без проверки проекта. Имеются отдельные способы проверить проект VHDL. Однако, наиболее популярное решение использовать испытательные стенды.

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


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

Испытательный стенд всегда состоит из следующих элементов:

Сокет для тестируемого блока (UUT); Генератор стимулов (подсистема, которая выдает стимулы на UUT, а так же производит их внутренние чтение или чтение из внешнего источника); Инструментальные средства для контроля реакций UUT на стимулы.

Рисунок:

9.2.2. VHDL Испытательные стенды

Ключевые вопросы:

Идея относительно испытательных стендов адаптировалась к проектам VHDL. Однако, VHDL испытательный стенд - не автономная система, а VHDL спецификация, которая моделируется VHDL моделирующим устройством. Она составлена из реализации тестируемых блоков и процессов, которые поддерживают стимулы которые подаются на UUT. Этим способом, гибридная спецификация создана так, что она смешивает структурные и поведенческие типы операторов. Такой подход приемлем в VHDL, потому что и составляющая реализация и процессы –параллельные утверждения.

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

Примеры:

Рисунок:

9.2.3. Компоненты VHDL Испытательного стенда

Ключевые вопросы:

Как Вы видели на предыдущей странице, VHDL испытательный стенд - только другая спецификация с собственым Объектом и архитектурой. Однако, она имеет, , специальную структуру с некоторыми элементами, которые являются характерными по отношению этому типу спецификации:



Объект испытательного стенда не имеет никаких портов; Моментальная компонента UUT – это связь между испытательным стендом и UUT определенная через составляющую реализации и спецификацию с структурным типом; Стимулы - это - набор сигналов, которые объявлены внутри в архитектуре испытательного стенда, а также сигналы назначенные портам UUT. Стимулы определены как формы сигнала в одном или более поведенческом процессе.

Примеры:

entity test_bench is

end test_bench;

architecture test_bench_arch of test_bench is

component and_gate is

port(

a : in bit;

b : in bit;

y : out bit

);

end component;

signal a, b, c : bit;

begin

UUT: and_gate port map (a,b,c);

a<='0', '1' after 20 ns, '0' after 40 ns;

b<='1', '0' after 40 ns, '1' after 80 ns;

end test_bench_arch;

Рисунок:

9.2.4. Использование Испытательных стендов

Ключевые вопросы:

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

Некоторые эксперты даже предлагают писать полные файлы стимулов в то же самое время.

Когда тест блока и испытательный стенд готовы, проверка может быть начата. Заметьте, что это - испытательный стенд, который моделируется, а тестируемый блок. UUT один из компонентов содержащийся в испытательном стенде. Не имеется никакого ограничения на размере испытательного стенда. Единственное ограничение - моделирующая способность VHDL и возможности ее реализовать.

Примеры:

Как описывать стимул ДАТЧИКА МЕТОК ВРЕМЕНИ:

...

constant CLK_C: time := 20 ns;



signal CLK : std_logic;

...

CLOCK_GEN: process(CLK)

begin

if CLK = 'U' then

CLK <= '0';

else

CLK <= not CLK after CLK_C;

end if;

end process;

Рисунок:

9.3.1. Объект Испытательного стенда

Ключевые вопросы:

Испытательный стенд выглядит точно так же как и любая другая VHDL спецификация, состоящая из сущности и архитектуры. Имеется, однако, одно важное различие, а именно - это отсутствие портов или generics.

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

Почему мы трактуем испытательный стенд как Объект, когда это – фактически только архитектура? Потому, что как показано во второй главе, архитектура не может быть определена без сущности, и это правило также применяется к испытательным стендам.

Примеры:

entity tb_D is

end tb_D;

architecture TB_A of tb_D is

--Declaration of tested component

component D_ent port (...);

end component;

shared variable END_SIM: boolean := false;

signal CLK : bit;

-- Time period of CLK signal

-- generator

constant CLK_PERIOD: time := 20 ns;

begin

-- Unit Under Test instantiation

UUT: D_ent port map (...);

CLK_GEN: process

begin

if not END_SIM then

CLK <= '0';

wait for CLK_PERIOD/2;

CLK <= '1';

wait for CLK_PERIOD/2;

else wait;

end if;

end process; STIMULUS: process

begin

D <= '1';

wait for 200 ns;

D <= '0';

wait for 200 ns;

END_SIM := TRUE;

wait;

end process;

end TB_A;



9.3.2. Тестируемый Блок

Ключевые вопросы:

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


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

Тестируемый блок должен быть внутренним в архитектуре испытательного стенда. Это может быть выполнено таким же образом как и в любой структурной спецификации - или через прямую реализацию или комплексную инстоляцию составляющих декларации и конфигурации. Инстолируемым портам UUT будут назначенные сигналы стимулов.

Так как процесс и составляющая реализация – параллельные операторы, то не имеет значение, будет ли UUT инстолировано сначала, а затем будут определены стимулы или наоборот.

Примеры:

entity dmux_e is

port(

X:in bit;

S:in bit_vector(1 downto 0);

Y:out bit_vector (3 downto 0));

end dmux_e;

architecture dmux_a of dmux_e is

begin

Y<=('0','0','0',X) when S="00" else

('0','0',X,'0') when S="01" else

('0',X,'0','0') when S="10" else

(X,'0','0','0') when S="11";

end dmux_a;

entity tb is

end tb;

architecture TB_ARCH of tb is

component dmux_e

port(

X:in bit;

S:in bit_vector (1 downto 0);

Y:out bit_vector (3 downto 0));

end component dmux_e; signal X:bit;

signal S: bit_vector(1 downto 0);

signal Y: bit_vector(3 downto 0);

begin

UUT : dmux_e

port map(X=>X,S=>S,Y=>Y);

STIM: process

begin

X<='1'; S<="00";

wait for 40 ns;

S<="01";

wait for 40 ns;

S<="10";

wait for 40 ns;

S<="11";

wait for 40 ns;

wait;

end process;

end TB_ARCH;

Рисунок:

9.3.3. Стимулы Сигналов

Ключевые вопросы:

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



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

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

Примеры:

entity tb is

end tb;

architecture tb_arch of tb is

component COUNTER8

port (...);

end component;

signal CLK,RESET,CE,LOAD,DIR: std_logic;

signal DIN:integer range 0 to 255;

signal COUNT:integer range 0 to 255;

begin

U1: COUNTER8 port map(...);

process(CLK)

begin

if CLK='U' then CLK<='0';

else CLK<=not CLK after 15 ns;

end if;

end process;

RESET<='1', '0' after 15 ns;

CE<='1';

DIR<='1';

DIN<=250; STIM1:process

begin

LOAD<='0'; wait for 3 us;

LOAD<='1'; wait for 100 ns;

LOAD<='0'; wait;

end process;

STIM2:process

begin

DIR<='1'; wait for 2 us;

DIR<='0'; wait for 1 us;

DIR<='1'; wait for 1 us;

DIR<='0'; wait;

end process;

end tb_arch;

Рисунок:

9.3.4. Операторы Утверждения

Ключевые вопросы:

Последний элемент успешной проверки элемента выделяет и сообщает о результатах моделирования. Это может быть выполнено рядом способов: выводом списка временных значений сигнала на дисплей в виде временной диаграммы, записью результатов моделирования в log файл или при помощи предложения VHDL report.

Последний выбор легко применить, и это обычно используется, для того чтобы показать сообщение, когда что нибудь идет неправильно. Если этот выбор используется, и никакие доклады не показаны в течение моделирования, то это означает, что UUT работало как ожидалося.



Предложение report состоит из трех элементов: оператор assert (утверждения) (контролирующий Булево условие), оператор report (определяющий сообщение, которое будет показано, когда условие ложно) и оператор severity (устройство моделирования информируется насколько серьезная ошибка произошла, причем сообщается и о неисправности системы). См. Детальное руководство по применению.

Примеры:

Рисунок:

9.3.5. Сообщение с Утверждениями

Ключевые вопросы:

Оператор assertion по природе последовательный, и поэтому он используется внутри процессов. Его применение не ограничено испытательными стендами, но здесь то место, где они наиболее часто используется.

Утверждения используются для сообщения о неправильных реакциях UUT на стимулы. Они используются следующим образом:

Применяйте пару assert-report каждый раз когда ожидается новое значение выхода UUT; Определите предполагаемую величину как условие в утверждении; Всегда обеспечьте очень определенное и детальное сообщение об ошибках: простая "Ошибка" не сообщит Вам ничто относительно моделирования. Пишите то, что неправильно и когда это случилось (то есть при каких условия входа). Помните, однако, что новые значения присвоены только тогда, когда процесс приостановлен. Так что не ожидайте изменений сразу на выходах после назначения новых значений на входах!

Примеры:

STIMUL:process

begin

NEW_CARD <= '1';

GEN_RES <= '1';

START <= '1';

wait for 50 ns; -- 50 ns

GEN_RES <= '0';

wait for 1200 ns; -- 1250 ns

START <= '0';

report "The new game starts";

...

wait for 150 ns; -- 6050 ns

NEW_CARD <= '0';

...

wait for 1850 ns; -- 10400 ns

START <= '0';

report "The new game starts";

wait for 500 ns; -- 10900 ns

START <= '1';

wait for 650 ns; -- 11550 ns

NEW_CARD <= '0';

... wait for 100 ns; --14910 ns

NEW_CARD <= '1';

wait for 500 ns; --15410 ns

END_SIM := TRUE ;

report "BJACK testing completed";

wait;

end process;

CHECK_HOLD:assert not(HOLD='1')



report "enough cards!"

severity NOTE;

CHECK_BUST:assert not(BUST='1')

report "Sorry, the game is lost"

severity NOTE;

Рисунок:

Резюме

Никакой проект не закончен без проверки его операторов. Имеются ряд способов для этого и одино из наиболее популярных решений это использование испытательных стендов. Испытательный стенд - окружающая среда, где проект (названный, тестируемый блок) проверяется при помощи стимулов. Реакции проекта – наблюдаются через вывод на дисплей временных диаграмм. Испытательный стенд состоит из следующих элементов: Сокет для тестируемого блока; Генератор стимулов (подсистема, которая применяет стимулы чаще всего генерируемые изнутри для UUT, или считывает их из внешнего источника); Инструментальные средства для контроля реакций UUT к стимулам. VHDL испытательный стенд - спецификация с собственным Объектом и архитектурой. Он имеет специальную структуру, которая является характерной для этого типа спецификации: Объект испытательного стенда не имеет никаких портов; Инстоляция компонент UUT устанавливает связь между испытательным стендом и UUT через инициализацию компонент и структурный тип спецификации; Стимулы - набор сигналов, которые объявлены внутри архитектуры испытательного стенда и присвоены портам UUTпри их инстоляции; также стимулы можно определить способом поведения как форму сигнала при одном или большем количестве процессов. Последний элемент успешной проверки элемента рапорт о результатах моделирования. Это может быть выполнено рядом способов: используя вмонтированный в моделирующее устройство показ, запись результатов моделирования в log файл, или используя предложение report языка VHDL. Предложение report (доклад) состоит из трех элементов: оператора assert (контролирующего Булево условие), оператора report (который определяет сообщение, которое будет показано, когда условие ложно) и оператор severity (который информирует моделирующее устройство о неисправности системы и местоположении ошибки). Оператор утверждения последователен, поэтому он используется внутри процессов. Используйте пару assert-report каждый раз когда ожидается новое значение выхода UUT и детально описывайте ошибки, так как простая запись "Ошибка" не сообщит Вам ничто относительно моделирования; описывайте в чем ошибка и при каких сигналах она возникла.

Конструкции VHDL для Описания Поведения Системы


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 5

Конструкции VHDL для Описания Поведения Системы

Содержание Главы 5

5.1. Краткий обзор Главы

Не-логические Типы данных

5.2.1. Введение к Типам данных

5.2.2. Скалярные Типы

5.2.3. Определяемые пользователем Типы Перечисления

5.2.4. Физические Типы

5.2.5. Предопределенные Массивы

5.2.6. Массивы определяемые пользователем

5.2.7. Записи

Выражения и Операторы

5.3.1. Введение

5.3.2. Логические операторы

5.3.3. Числовые Операторы

5.3.4. Операторы отношений

5.3.5. Операторы сдвига

5.3.6. Оператор Конкатенаци

Простое Назначение Сигнала

5.4.1. Присваивание Выражений Сигналам

5.4.2. Присвоение Может Быть Задержано

5.4.3. Инерционная Задержка

5.4.4. Транспортная Задержка

5.4.5. Инерционная Задержка против Транспортной

Константы

5.5.1. Объявление Констант

5.5.2. Использование Констант

5.5.3. Константы против. Generics

Резюме

5.1. Краткий обзор Главы

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

В Секции 2 рассмотрены основные типы VHDL. Два логических типа (bit и bit_vector) были уже представлены, но некоторые проектировщики помимо этих используют и другие типы. Эти типы могут группироваться как scalar (скалярные) типы, enumeration (перечисляемые) типы, physical (физические) типы (которые являются частными случаями скалярных типов) и complex (комплексные) типы (arrays (массивы) и records (записи)). Кроме них, VHDL допускает использование еще двух типов: files (файлы) и acctss (доступ). Так как эти типы используются менее часто, они будут опущены здесь. См. Руководство по применению для подробной информации относительно них.


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

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

В заключение, Секция 5 вводит constant (константы). Эти объекты играют роль подобную generics, но объявляются и используются немного разными способами.

5.2.1. Введение к Типам данных

Ключевые вопросы:

Каждая единица информации внутри компьютера или другой цифровой системы записывается в форме битов (bit) и разрядных векторов (bit_vector). Однако, часто неудобно использовать эту форму. Так как одна буква представлена 8 битами, и каждое обращение к памяти PC требует, по крайней мере, 20 битов для определения адреса, то более проще использовать некоторые цифры или шестнадцатеричные числа вместо битов.

Точно так же много комплексных но регулярных структур данных могут быть представлены массивами и физическими параметрами. Так образом это - типичные приложения. Поэтому VHDL поддерживает все эти структуры и параметры, и объекты VHDL могут быть объявлены так что они будут являться одним из этих типов.

Примеры:



Рисунок:

5.2.2. Скалярные Типы

Ключевые вопросы:

Scalar (скалярный) тип - обобщенное имя, которое присваивается всем типам, чьи объекты имеют единственное значение в любой момент времени. Скалярные типы не имеют никаких элементов или внутренней структуры. Все значения скалярного типа упорядоченные и значения определены или как попадающие внутрь диапазона или явно перечисленные (внесенный в список).

VHDL определяет отдельные скалярные типы. Однако, Вы можете определять ваши специфичные собственные типы, чаще на основании диапазона или как перечисляемые.


Обычно, такой определяемый пользователем скалярный тип объявлен как подтип типа, определенного ранее, или как стандартная модель или другой определяемый пользователем тип.

Рисунок:

constant N : positive := 4;

type Byte is range 255 downto 0;

type Voltage_Level is range 0 to 5;

type Int_64K is range -65536 to 65535;

type Word_Index is range 31 downto 0;

type MUX_ADDRESS is range (2**(N+1))-1 downto 0;

Рисунок:

5.2.3. Определяемые пользователем Типы Перечисления

Ключевые вопросы:

Проектировщики часто должны кодировать некоторую информацию системы очень эффективно или с учетом ее удобочитаемости. Классический пример - конечный автомат (FSM) представляющий последовательное проектирование. Для целей синтеза, каждое состояние FSM кодируется при помощи переменной состояния (триггером), которая хранят информацию относительно фактического состояния. Однако, на уровне спецификаций намного более удобно приписать уникальное имя к каждому состоянию, а затем обращаться к этому состоянию через имя. Для этого в декларации нового типа enumeration все имена состояний переписаны (перечисленны).

Примечание: Значения в декларации типа (имена состояний) определены " поскольку они - ", без любых апострофов или двойных кавычек.

Примеры:

Чтобы лучше пояснить декларацию типа enumeration, рассмотрим их синтаксис на примере:

-- Syntax:

-- type type_name is (type_element, type_element, …);

-- Примеры:

type NotGood is (X,'0','1',X); -- illegal

type MyBit is (L,H);

type Test is (’0’,’1’,L,H);

type FSM_States is (Init,Read,Decode,Execute,Write);

Рисунок:

5.2.4. Физические Типы

Ключевые вопросы:

Physical (физические) типы уникальны в VHDL, потому что они определяют не только значения объекта но также и единицы, в которых значения выражены. Это допускает такие физические величины как время, расстояние, поток, температура, и т.д., определять с нужной точностью. Стандарт VHDL определяет только один физический тип - время, однако другие типы могут быть определены по желанию.


Один из примеров как это сделать показан справа

Имеются два вида единиц в физических декларациях типа: первичные единицы и вторичные единицы, которые определяется в терминах первичных единиц. Заметьте, что диапазон, указанный в заголовке декларации типа ссылается только на первичные единицы.

Несмотря на их наглядность и привлекательность, (physical) физические типы - не синтезируются хорошо (not synthesizeable).

Примеры:

type Capacity is range 0 to 1E9

units

pF; -- picofarad

nF = 1000 pF; -- nanofarad

uF = 1000 nF; -- microfarad

mF = 1000 uF; -- milifarad

F = 1000 mF; -- farad

end units Capacity;

type Distance is range 0 to 1E9

units

um; -- micrometer

mm = 1000 um; -- millimeter

inch = 25400 um; -- inch

end units Distance;

Рисунок:

5.2.5. Предопределенные Массивы

Ключевые вопросы:

Массивы - составной тип с регулярной структурой, состоящий из элементов того же самого типа. Число элементов в массиве определяется диапазоном массива. Диапазон может быть неограничен или ограничен, “поддерживая” левую связанную или правую границу и направление следования индексов между ними (способ, которым это обеспечивается рассмотрен в Главе 3 для разрядных векторов). Неограниченный диапазон определен как:

range <>

Имеется два (2) предопределенных VHDL массива - bit_vector (с элементами типа bit) и string (строка) (имеющий элементы типа character"символ"). Оба они объявлены с неограниченным диапазоном. Конечно, они отличаются способ, которым они определяют нижнюю границу: первый элемент bit_vector индексирован как 0, а string начинается с 1.

Заметьте: простой элемент этих массивов определен в одинарных кавычках , но два или больше элемента, называемых кристаллом (slice), беруться в двойные кавычки.

Примеры:

type bit_vector is array (natural range <>) of bit;

type string is array (positive range <>) of character;

-- Примеры:

signal DataBus : bit_vector(7 downto 0) := "01010101";

signal AddressBus : bit_vector (0 to 15);

signal ChipSelect : bit := '1';



constant Message1 : string(1 to 20) := "hold time violation";

signal Letter1 : character;

signal Message2 : string(1 to 10);

Рисунок:

5.2.6. Массивы определяемые пользователем

Ключевые вопросы:

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

Типичный пример двухмерного массива - запоминающее устройство, которое может рассматриваться как двухмерный массив битов. В настоящей памяти биты обычно группируются в слова. Это практически делает их “вектором векторов” – каждый элемент вектора в свою очередь является вектором. Отдельные примеры типов памяти определены на рисунке справа

Примеры:

type Real_Matrix1 is array (1 to 10) of real;

type X is (LOW, HIGH);

type Byte is range 0 to 7;

type DATA_BUS is array (Byte, X) of bit;

-- unconstrained array of element of real type

type Real_Matrix2 is array (positive range <>) of real;

signal Real_Matrix_Object : Real_Matrix2 (1 to 8);

Рисунок:

5.2.7. Записи

Ключевые вопросы:

Записи, как одноименные массивы, принадлежат к составным типам. Однако они имеют два различия: элементы записи могут иметь различные типы, и они обозначаются именами вместо индексов. Ссылка на элемент записи имеет следующий вид

:

record_name.element_name

Эти имена всегда написаны без круглых скобок.

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

Не каждая запись может быть синтезирована, но большинство синтезаторов способно справиться с записями состоящими из типов bit, bit_vector, boolean и integer.

Примеры:

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

-- Syntax:

-- type record_type_name is record



-- element_name : element type;

-- element_name : element type;

. . .

-- end record record_type_name;

type RegisterName is (AX, BX, CX, DX);

type Operation is record

Mnemonic : string;

OpCode : bit_vector(3 downto 0);

Op1, Op2, Res : RegisterName;

end record;

signal Instr1, Instr2, Instr3 : Operation;

. . .

Instr1 <= ("ADD AX, BX", "0001", AX, BX, AX);

Instr2 <= ("ADD BX, BX", "0010", others => BX);

Instr3.Mnemonic <= "MUL AX, BX";

Instr3.Op1 <= AX;

Рисунок:

5.3.1. Введение

Ключевые вопросы:

Кроме очень тривиальных систем, входные сигналы должны всегда преобразовываться для того чтобы некоторым способам генерировать желательные выходные сигналы. Этот процесс можно наглядно себе представить как

outputs <- transformations(inputs)

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

Основной элемент каждого выражения - оператор. Каждому оператору назначен некоторый определенный тип (или типы) и для него требуется один или два операнда, которые являются объектами над которыми производятся действия. Запрещено использовать оператор или операнд тип которых не поддерживается, но пользователь может определять новое значение для существующего оператора для других типов. Это выполнено через так называемую перегрузку оператора - см., руководство по применению для детального знакомства с этим.

Примеры:

Выражения определяют способ, которым новое значение вычисляются. Они состоят из операндов и операторов. Например, выражение " 1 + 2 " прибавляет два целых числа. Числа - операнды, и знак "плюс" - предопределенный оператор добавления.


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

Смешанные операторы ** | abs | not

Мультипликативные операторы * | / | mod | rem

Операторы знака + | -

Операторы сложения + | - | &

Операторы сдвига sll | srl | sla | sra | rol | ror

Реляционные операторы = | \= | < | <= | > | >=

Логические операторы and | or | nand | nor | xor | xnor

Рисунок:

5.3.2. Логические операторы

Ключевые вопросы:

Так как цифровые сигналы системы - обычно логические сигналы,, наиболее часто используемый класс операторов VHDL - логические операторы. Логические операторы делают такие действия с двумя операндами как and, or, nand, nor, xor и xnor. Оператор not - действие с одним операндом. Логические действия определены для типов: bit, boolean, and bit_vector, Это означает, что оба операнда должны состоять из тех типов. Результат имеет всегда тот же самый тип что и операнды.

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

Примеры:

Пусть выражение построено так , что используются and, or, xor или xnor Более того эти логические операторы могут содержать любую последовательность действий. Тогда, если nand или nor действия использующиеся в выражениях, то они могут содержать только одно действие этого типа. Если необходимо большее количество таких действий, то круглые скобки должны использоваться.

signal A, B, C, D : bit;

-- И-НЕТ оператор появляется только если :

C <= A nand B;

--Многоуровневая операция моделированная И-НЕТ, с

круглыми скобками:



A <= ( D nand B) nand C;

-- Операторы И, Или могут использоваться больше чем один раз в одном выражении:

A <= '1' and B and C or D;

A <= '1' and (B and (C or D));

Рисунок:

5.3.3. Числовые Операторы

Ключевые вопросы:

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

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

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

Примеры:

Ниже приведенные примеры переводят объект типа bit_vector в целое число и наоборот. Обратите внимание на то, как арифметические операторы используются здесь.

. . .

signal Input : bit_vector (0 to size-1);

signal Output : integer :=0;

signal Power : integer :=1;

. . .

if Input'length = 0 then Output := 0;

end if;

for I in Input'reverse_range loop

if Input(I) = '1' then Output <= Output + Power;

end if;

Power <= Power * 2;

end loop;

. . .

signal vector : bit_vector (0 to size-1);

signal tmp_int : integer := value;

. . .

for I in size-1 downto 0 loop

if tmp_int mod 2 = 1

then vector(I) <= '1';

else vector(I) <= '0';

end if;

tmp_int <= tmp_int / 2;

end loop;

Рисунок:



5.3.4. Операторы отношений

Ключевые вопросы:

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

Можно отметить, что, когда два разрядных вектора сравниваются, они могут быть разной длины. Вместо того, чтобы прибавлять конечные нули к более короткому операнду, оба операнда должны быть выравнены. В случае VHDL реализации это ведет к тому что 1011 будет меньшим чем 110. Совершенно неожиданный факт, не так ли?

Примеры:

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

signal S1: REAL := 100.0;

signal S2 : bit_vector (0 to 7) := ('0','0','0','0','0','0','0','0');

signal S3, S4 : bit_vector (1 downto 0);

S1 /= 342.54 -- True

S1 = 100.0 -- True

S2 /= ('1','0','0','0','0','0','0','0') – True

S3 = S4 -- True

S1 > 42.54 -- True

S1 >= 100.0 -- True

S2 < ('1','0','0','0','0','0','0','0') -- True

S3 <= S2 -- True

Рисунок:

5.3.5. Операторы сдвига

Ключевые вопросы:

Как видно из имени оператора сам оператор предполагает, сдвиг элементов одномерных массивов. Этот класс операций ограничен массивам, у которых элементы типа бит или булевы.

Операторы сдвига требуют двух операндов. Левый представляет массив, а правый является целым числом, которое определит число место положения в массиве, на которое будет смещен его элемент. При этом стоит отметит, что, если значение второго операнда отрицательная величина, то направление смещения реверсивно, т.е. sll -n эквивалентен к srl n (левый сдвиг -n – такое же как право смещения на n разрядов), аналогично, ror -n делает то же самое действие что и rol n, и т.д.



В случае операций логического сдвига значение элемента вставляется в крайний левый (в случае srl) или младший разряда (для sll) вектора, т.е. положение формально определено как первый разряд типа элемента. По этой причине, первое значение для типа bit будет '0', а для типа boolean - 'ложь'.

Примеры:

Комментарии в каждой строке содержат результаты каждого действия сдвига, сделанного на сигнале S5. Отметим эквивалентность некоторых операторов, если используются реверсивные операнды.

signal S5 : bit_vector (0 to 3) := ('1','0','1','1');

S5 sll 1 -- ('0','1','1','0')

S5 sll 3 -- ('1','0','0','0')

S5 sll -3 -- S5 srl 3

S5 srl 1 -- ('0','1','0','1')

S5 srl 3 -- ('0','0','0','1')

S5 srl -3 -- S5 sll 3

S5 sla 1 -- ('0','1','1','1')

S5 sla 3 -- ('1','1','1','1')

S5 sla -3 -- S5 sra 3

S5 sra 1 -- ('1','1','0','1')

S5 sra 3 -- ('1','1','1','1')

S5 sra -3 -- S5 sla 3

S5 rol 1 -- ('0','1','1','1')

S5 rol 3 -- ('1','1','0','1')

S5 rol -3 -- S5 ror 3

S5 ror 1 -- ('1','1','0','1')

S5 ror 3 -- ('0','1','1','1')

S5 ror -3 -- S5 rol 3

Рисунок:

5.3.6. Оператор Конкатенаци

Ключевые вопросы:

Сцепление - удобный способ создания новых значений массивов любого типа. Это действие предопределено для одномерных массивов.

Действие конкатенаця соединяет два операнда, которые вместе используют оператор конкатенаци. Это приводит к массиву, в котором длина является суммой длин обоих операндов. Последовательность элементов массива сохранена, то есть результирующий массив имеет значения левых элементов операнда с лева и значение правых - с права.

Сцепление не ограничено только операндами массива – вполне законно конкатенировать два массива или отдельные значения (отдельные биты) если тип отдельных значений и типа элементов массива (2-ой операнд) сопоставими.

Примеры:

В действии конкатенация могут быть следующие ситуации:

Когда оба операнда - одномерные массивы того же самого типа, конкатенация соединяет два массива в один. Направление расположения элементов нового массива – такое же как направление в массиве левого операнда: constant B1: bit_vector := "0000"; -- four element array



constant B2: bit_vector := "1111"; -- four element array

constant B3: bit_vector := B1 & B2;-- eight element array,

-- ascending direction, value "00001111"

subtype BIT_VECTOR_TAB is bit_vector (1 downto 0);

constant B4: BIT_VECTOR_TAB := "01";

constant B5: bit_vector:= B4 & B2; -- six element array,

-- descending direction, value "011111"

Когда один из операндов - одномерный массив, а второй операнд - скаляр того же самого типа как и элементы исходного массива, то результат конкатенации – такой же как в первом пункте: constant B6 : bit := '0' ;

constant B7 : bit_vector := B2 & B6;-- five element array,

-- ascending direction, value "11110"

В случае, если оба операнда имеют тот же самый скалярный тип, то результат конкатенации - одномерный массив с элементами того же самого типа как операнд: constant B8: bit := '1';

constant B9: bit_vector := B6 & B8; -- two element array,

-- ascending direction value "01"

Рисунок:

5.4.1. Присваивание Выражений Сигналам

Ключевые вопросы:

Окончательная цель каждой электронной системы состоит в том, чтобы сгенерировать желательную реакцию (выходные сигналы) по входным сигналам. Обычно, это требует некоторых действий с их значениями. Как такие действия могут быть определены в VHDL, показано в предыдущей секции.

В конечном счете, результаты действий должны быть присвоен выходным сигналам. Механизм присвоения прост: целевой сигнал указывается слева. Это сопровождается символом присвоения сигнала (< = ) и в заключение определяется. выражение присвоения Результат выражения будет передаваться целевому сигналу, внесенному в список слева. Чтобы лучше запоминать символ присвоения, его обозначили похожим на стрелку, которая обозначает поток информации.

Заметьте: символ присвоения сигнала всегда направлен справа налево (< = ) Противоположный символ (= > ) также используется в VHDL, но он имеет другое значение. Оба символа < = и = > могут использоваться как операторы отношений.


Их интерпретация зависит от контекста.

Примеры:

Даже без того, чтобы много знать относительно VHDL, совершенно просто определить поведение простого комбинаторного счетчика. Заметьте присвоение сделано выходнму сигналу.



entity MyFirstCircuit is

port (A, B, C, D : in bit;

Y : out bit);

end entity MyFirstCircuit;

architecture MyFirstCircuit_Arch of MyFirstCircuit is

begin

Y <= (A and B) or (C and D); -- Classical assignment

-- of a logical operation

end architecture MyFirstCircuit_Arch;

Рисунок:

5.4.2. Присвоение Может Быть Задержано

Ключевые вопросы:

Ничто не случается немедленно в реальном мире. Результаты в любой системе появляются один за другим в течении определенного времени. Такое поведение в VHDL моделируется присваиванием с after, которое может быть добавлено к любому утверждению, которое присваивает сигнал.

Присваивание с after определяет количество времени, которое должно пройти прежде, чем присвоение становиться эффективным.

Примечание: значение ‘0’ после присваивания в примере из предыдущей страницы означает ' никакакой задержки нет'.

Примеры:

Применение к примеру из предыдущей страницы after после присваивания, приведет к более реалистичному поведению счетчика.

entity MyFirstCircuit is

port (A, B, C, D : in bit;

Y1 : out bit);

end entity MyFirstCircuit;

architecture MyFirstCircuit_Arch2 of MyFirstCircuit is

begin

Y1 <= (A and B) or (C and D) after 10 ns;

end architecture MyFirstCircuit_Arch2;

Этим способом, все изменения значения Y1 будут происходить на 10 ns позже чем тактовые Y:

Рисунок:

5.4.3. Инерционная Задержка

Ключевые вопросы:

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



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

Инерционная задержка типична для большинства систем реальной жизни и из-за этого, она определяется моделью задержки в VHDL. Присвоение с after автоматически определяет инерционную задержку. Характерным элементом этой модели – является то, что два последующих изменения входа, будут игнорироваться, если время между ними более короткое чем указанная задержка.

Примеры:

Присвоение с after применилось в предыдущем примере, чтобы определить время распространения сигнала в цепи. Давайте использовать это снова, для моделирования времени реальной схемы AND. Заметьте что может произойти в случается когда вход изменяется быстрее чем задержка распространения сигнала:

architecture MyFirstGate_Arch1 of MyFirstGate is

begin

Output <= InputA nand InputB after 20 ns; -- propagation

-- time of and gate

end architecture MyFirstGate_Arch1;

Рисунок

Рисунок:

5.4.4. Транспортная Задержка

Ключевые вопросы:

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

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

Примеры:

Транспортный способ задержки, который вводиться с помощью ключевого слова transport, изменяет поведение моделируемой цепи . Ниже приведенные диаграммы времени показывают то, что случается с AND из предыдущего примера, если AND имеет транспортную задержку вместо инерционной.


Форма сигнала входа - точно таже самая:

architecture MyFirstGate_Arch2 of MyFirstGate is

begin

Output <= transport InputA nand InputB after 20 ns;

end architecture MyFirstGate_Arch2;

Рисунок:

5.4.5. Инерционная Задержка против Транспортной

Ключевые вопросы:

Инерционные и транспортные модели задержки достаточны для описания любой физической системы в VHDL. Их главные подобия и различия следующие:

Инерционная задержка - задержка по определению в VHDL и не требует никаких дополнительных деклараций. Однако, транспортная задержка требует, чтобы использовалось ключевое слово transport; Инерционная задержка не распространяет импульсы более короткие чем декларированная задержка; транспортная задержка распространяет все изменения входного сигнала, независимо от того, как быстро или как часто они могут появляться; Инерционные и транспортные задержки определяются при использовании after с указанием нормы времени; Обе модели задержки могут применяться к сигналам любого типа.

Примеры:

Позвольте нам сравнить две модели задержки. Предложенная диаграмма содержит, и инерционную модель (MyFirstGate_Arch1), и транспортную модель (MyFirstGate_Arch2). Результаты следующие:

Рисунок:

5.5.1. Объявление Констант

Ключевые вопросы:

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

Декларация констант состоит из следующих элементов:

Ключевое слово constant; Имя константы (идентификатор константы); Двоеточие; Индикация типа для константы; Значение константы указанное после символа ': = '; Точка с запятой, завершающая строку. Если две или больше констант имеют тот же самый тип и имеют то же самое значение, они могут быть определены в одной декларации.

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

Примеры:



type WeekDay is (Mon,Tue,Wed,Thu,Fri,Sat,Sun);

constant StartDay : WeekDay := Sat;

constant LogicalGND : bit := '0';

constant BusWidth, QueueLength : integer := 16;

constant CLKPeriod : Time := 15 ns;

constant MaxSimTime : Time := 200 * CLKPeriod;

type NumericCodeType is array ( 7 downto 0) of integer range 0 to 9;

constant EntryCode : NumericCodeType := (2,6,4,8,0,0,1,3);

constant DataBusReset: std_logic_vector(7 downto 0) := "00000000";

Рисунок:

5.5.2. Использование Констант

Ключевые вопросы:

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

Если жестко закодированные значения использовались, пользователь должен будет тщательно проверить полную спецификацию " строка в строку " чтобы удостовериться, что все значения исправлены.

Вообще константы используются тем же самым способ как generics. Специально, они используются для:

Определения размера комплексных объектов (одномерных массивов или шин); Управления циклом; Определения временных параметров: задержки, времени подготовки к работе, временной задержки, времени переключения, и т.д. Так как константы объявлены в архитектуре, они не могут использоваться, чтобы определить размер векторов, объявленных как порты в объектах (см. примеры на generics на странице 4.4.3). Это - главная причина, почему этот случай не рассматривается в примерах справа Однако это ограничение, , может быть преодолено, если константа объявлена в блоке, используемом сущностью.

Примеры:

Ниже приведенный пример показывает, как использовать константы.

entity Mux2to1 is

port (I0, I1, SEL : in bit;

Y : out bit);

end entity Mux2to1;

architecture Mux2to1_Arch of Mux2to1 is

constant tp : time := 10 ns;



begin

Y <= (I0 and SEL) or (I1 and not(SEL)) after tp;

end architecture Mux2to1_Arch;

entity CPU IS

port(Input_CPU : in bit_vector (31 downto 0);

Output_CPU : out bit_vector (31 downto 0));

end entity CPU;

architecture CPU_Arch of CPU is

constant Width : integer := 7;

constant Depth : integer := 15;

signal IntAddr : bit_vector (Depth downto 0);

signal IntData : bit_vector (Width downto 0);

begin

. . .

end architecture CPU_Arch;

Рисунок:

5.5.3. Константы против. Generics

Ключевые вопросы:

Многие впервые столкнувшись с VHDL задаются вопросом, почему язык содержит два такие конструкции как generics и constants. Нужны ли в действительности обе из них?

Основное различие между generics и constants состоит в том, что generics может использоваться динамически, в то время как constants совершенно статические. Это означает, что Вы можете изменять значение generics без никаких изменений в коде. Однако, константы не могут быть изменены без того, чтобы изменился код. Это важно особенно в случае, когда спецификация будет использоваться как компонент для спецификации с более высоким уровнем. Каждый раз как такой компонент используется, мы может назначать новые значения, если они определены generics.

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

Примеры:

Видимость констант зависит от места их декларации:

Константы, определенные в блоке могут использоваться отдельными устройствами проекта: Package Timing is

Constant Reset : std_logic;

end package Timing;

package body Timing is

constant Reset: std_logic := '0';

end package body Timing;

Описание константы в сущности проекта доступно всем утверждениям внутри архитектуры этой сущности: entity Mux2to1 is



port (I0, I1, SEL : in bit;

Y : out bit);

constant NumberOfIteration : positive := 5;

begin

end entity Mux2to1;

Константы, определенные в разделе описаний устройства в проекте доступны во всех блоках, внутри этого проекта, включая процесс: architecture DFF_Arch of DFF is

constant t_setup : time := 10 ns;

constant t_hold : time := 1 ns;

constant t_propagation : time := 15 ns;

begin

end architecture DFF_Arch;

Рисунок:

Резюме

Каждый объект в VHDL должен иметь некоторый тип. Этот тип определяет возможные операции и значения, которые могут принадлежать этому типу. Язык VHDL это язык со строгим контролем типов, что означает, что две лексемы с идентичными типами, но с различными именами, будет рассматриваться по разному. Если требуется переход от одного типа к другому, то преобразование типов необходимо, даже если два типа очень похожи (например, переменная со знаком и целая переменная). Скалярные значения типа не могут содержать элементы любой сложности. Все значения в скалярном типе счетны. Благодаря этому все операторы отношений для все типов предопределены. Более того , каждое значение дискретного или физического типа имеет номер положения. Все числовые типы (то есть целое число,число с плавающей запятой и физический) могут быть определены в определенном диапазоне, который состоит из набора возможных значений. Объект сложного типа – состоит из других объектов, которые назваются элементами. Элементы могут иметь любой тип scalar, composite или access. При этом не допускается использование типа file как элемента сложного типа. Разница между массивами и записями состоит в том, что все элементы массива должны иметь тот же самый тип. С другой стороны, каждый элемент записи может иметь различный тип. Каждый элемент массива задается именем массива и индексом. С другой стороны, элементы записи (называемые полями) задаются через их индивидуальные имена (вместе с полным именем записи), или через агрегатирование. VHDL имеет широкий набор операторов, которые могут быть разделены на группы того же самого уровня старшинства (приоритета): смешанные операторы, мультипликативные операторы, знаковые операторы,операторы сложения, операторы сдвига, операторы отношений, логические операторы. Блок STANDARD обеспечивает предопределенные операторы для стандартных типов. Оператор not классифицирован как смешанный оператор только с целью определения старшинства.


Иначе, его можно классифицировать как логический оператор. Если операции nand или nor используются, то выражения могут содержать только одно действие этого типа. Если необходимо многократное их применение, то должны использоваться круглые скобки. Оператор кокатенации (обозначенный как &) помещает два одномерных массива в больший массив того же самого типа (объявленное число элементов в массиве результата должено быть большой достаточным, чтобы охватить число элементов обоих добавленных операндов). Имеются два механизма задержки, доступные в VHDL: инерционная задержка и транспортная задержка. Транспортная задержка определена, при помощи использования зарезервированного слова transport, и типична для линий электропередачи. Инерционная задержка определена при помощи зарезервированного слово inertial и используется для моделирования приборов, которые являются по существу инерционными. Практически, это означает, что импульсы короче чем указанное время переключения не будут передавться. Если механизм задержки не определен, то по умолчанию это инерционная задержка. Механизмы задержек могут применяться только к сигналам. Константа это объект у которого значение никогда не может быть изменено в течение моделирования. Используйте константы настолько часто, насколько возможно, потому что они создают более читаемый и машино совместимый код
Далее>>

Многократные Процессы в Архитектуре


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 7

Многократные Процессы в Архитектуре

Содержание Главы 7

7.1. Краткий обзор Главы

7.2. Параллелизм? Это настолько Естественно …

7.2.1. Многомерность Мира

7.2.2. Параллельная Природа Систем

7.2.3. Структура Поведенческой Архитектуры

7.2.4. Как Архитектура Выполненяется

7.2.5. Прохождение Информации Между Процессами

7.3. Упрощенные Процессы: Назначение Сигнала

7.3.1. Некоторые Процессы - такие Простые …

7.3.2. . Активизация Параллельных Назначений

7.3.3. Условное Присваивание Сигнала

7.3.4. Выборочное Присваивание Сигнала

7.4. Драйвера и Атрибуты Сигнала

7.4.1. Концепция Драйвера

7.4.2. Каждый Сигнал Имеет Хронологию и Будущее

7.4.3. Время Зависимые Атрибуты Сигналов

7.4.4. Другие Атрибуты

7.5. Разрешение

7.5.1. Может ли Сигнал иметь Два Драйвера?

7.5.2. Многократный Драйвер Сигнала Должен Быть Разрешен

7.5.3. Двузначная Логика Не Достаточна Для Разрешений

7.5.4. Многозначная Логика

7.5.5. Разрешенния Для Многозначной логики

Резюме

7.1. Краткий обзор Главы

Каждый процесс имеет последовательную спецификацию и не может использоваться, чтобы описать комплексные системы, потому что такие системы по существу параллельны. В секции 2 мы покажем, как описать архитектуру VHDL, которая будет состоять из одновременно выполненных процессов.

Иногда, мы должны описать такие простые блоки как логические схемы. Определение их с процессами было бы излишне сложно. Для таких блоков как схемы мы должны использовать упрощенный процесс, названный одновременное присваивание сигнала. Такие конструкции, элементы и способ выполнения определены в Секции3.

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

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

7.2.1.Многомерность Мира

Ключевые вопросы:

В то время как удобно определить предметы последовательным способом, это - только упрощенный способ описания действительности. Фактически, мир не последователен вообще. Только осмотритесь вокруг Вас: Вы изучаете VHDL, кто - то читает газету, дети играют в баскетбол, ваш друг пытается вызывать Вас и вашего босса, который поехал в отпуск и находиться с другой стороны земного шара. Все эти результаты случаются в одно и то же самое время или одновременно. Если мы трактуем каждого из этих людей как отдельную систему (Глава 2 объяснила, почему мы можем делать это) то эти системы функционируют одновременно.

Примеры:

Рисунок:

7.2.2. Параллельная Природа Систем

Ключевые вопросы:

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

Так как VHDL - иерархический язык, мы способны определить систему, такой какой она в действительности является, а именно как " набор одновременно работающих подсистем ". Каждая из них может быть взаимосвязанной в рамках подсистемы и мы можем определить подсистему как отдельный процесс. Уровень детализации будет зависеть от потребностей - иногда процесс можно определит поведением составных компонент таких как процессор, а в других случаях, мы его может детализировать до уровня процесса на логическом вентиле.


Это ведет к заключению, что поведенческая спецификация системы - набор одновременных последовательных процессов.

Примеры:

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

entity reg is

port(d : in bit;

q : out bit);

end reg;

architecture reg_arch of reg is

signal s1 : bit;

signal clock : bit;

begin

clk:process -- main clock

-- generator

begin

clock <= '0';

wait for 5 ns;

clock <= '1';

wait for 5 ns;

end process; d1:process (clock)

begin

if clock='1' then

s1 <= d;

end if;

end process ;

d2:process (clock)

begin

if clock='0' then

q <= s1;

end if;

end process ;

end reg_arch;

Рисунок:

7.2.3. Структура Поведенческой Архитектуры

Ключевые вопросы:

Пришло время, чтобы определить как поведенческая архитектура должна выглядеть. До этого мы сконцентрировались на таких элементах архитектуры как декларации и отдельные процессы.

Подобно другим комплексным конструкциям VHDL, архитектура состоит из шаблона и тела. Шаблон определяет архитектуру и обеспечивает имя и границы тела. Он также включает декларации объектов, которые являются внутренними к архитектуре

Заметьте: Все процессы полностью определены внутри тела архитектуры.

Характерная особенность заголовка архитектуры - ассоциация с сущность, потому что каждая архитектура должна принадлежать сущности (должна быть чем-то сущности).

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

Примеры:

Этот пример основан на D-триггере со внутренним генератором датчика меток времени, который может быть скрыт сигналом m, который является активным когда он логический '0':

entity dff is

port(m,d : in bit;

q, nq : buffer bit);

end dff;

architecture dff_arch of dff is

signal s1, s2 : bit;



signal clock : bit;

begin

clk:process -- main clock

-- generator

begin

clock <= '0';

wait for 5 ns;

clock <= '1';

wait for 5 ns;

end process; n1:process(m)

begin

s1 <= not(m);

end process;

nand1:process(s1,clock)

begin

s2 <= s1 nand clock;

end process;

d1:process (s2)

begin

if s2='1' then

q <= d;

nq <= not(d);

end if;

end process ;

end dff_arch;

Рисунок:

7.2.4. Как Архитектура Выполненяется

Ключевые вопросы:

Является ли параллельное выполнение процессов и последовательное выполнение операторов внутри процессов небольшое перепутывание? Эта смесь последовательных и одновременных действий - одно из наиболее трудных понятий в VHDL. Теперь Мы ближе рассмотрим эту проблему , чтобы удостовериться, что она хорошо понята.

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

Идея относительно параллелизма была бы намного проще, для понимания, если бы мы смогли описать процессы рядом, а не один под другим. К сожалению, из-за изобразительных ограничений все программы, включая параллельные VHDL спецификации, внесены в список последовательно.

Примеры:

Каждая цепь этого полного сумматора, определена как отдельный процесс, который выполняется одновременно с другими:

entity fadder is

port (

a : in bit;

b : in bit;

Ci : in bit;

S : out bit;

Co : out bit

);

end fadder;

architecture fadder_arch1 of fadder is

signal s1, s2, s3, s4 : bit;

begin

p1: process(b, Ci)

begin

s1 <= b xor Ci;

end process p1;

p2: process(b, Ci)

begin

s2 <= b and Ci;

end process p2; p3: process(a, b)

begin

s3 <= a and b;



end process p3;

p4: process(a, Ci)

begin

s4 <= a and Ci;

end process p4;

p5: process(a, s1)

begin

S <= a xor s1;

end process p5;

p6: process(s2, s3, s4)

begin

Co <= s2 or s3 or s4;

end process p6;

end fadder_arch1;

Рисунок:

7.2.5. Прохождение Информации Между Процессами

Ключевые вопросы:

Так как процессы не различимы между сигналами, сгенерированными внешним образом (приходящими от устройств) и сигналами сгенерированными внутри (объявленные внутри архитектуры), то сигналы, которые активизируют процессы, могут быть сгенерированы другими процессами в той же самой архитектуре. Всякий раз, когда сигнал в списке чувствительности процесса изменяет значение, процесс активизируется. Это случается независимо от того, был ли сигнал изменен окружающей средой системы или другим процессом.

Заметьте: Только сигналы могут использоваться для пересылки информации между процессами. Потому что переменные - местные объекты по отношению к процессам, они не могут использоваться для переноса информации между процессами.

Примеры:

Здесь приведен пример обмена информацией внутри архитектуры; JK триггера, построенного на базе D триггеров, имеющим датчика меток времени внутри их архитектуры.

entity jkff is

port(j,k : in bit;

q, nq : buffer bit);

end jkff;

architecture jkff_arch of jkff is

signal s1, s2, s3, s4 : bit;

signal clock : bit;

begin

clk:process -- main clock generator

begin

clock <= '0';

wait for 5 ns;

clock <= '1';

wait for 5 ns;

end process;

nand1:process(j,nq)

begin

s1 <= j nand nq;

end process; nand2:process(s1,s4)

begin

s2 <= s1 nand s4;

end process;

nand3:process(s3,q)

begin

s4 <= s3 nand q;

end process;

not1:process(k)

begin

s3 <= not(k);

end process;

d1:process (clock)

begin

if clock='1' then

q <= s2;

nq <= not(s2);

end if;

end process ;

end jkff_arch;

Рисунок:

7.3.1. Некоторые Процессы - такие Простые

Ключевые вопросы:

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



OutAND <= InAND1 and InAND2;

Определение такого поведения с процессом требовало бы трех дополнительных операторов (заголовка процесса, предложение begin и предложение end process) которые являются самыми массовыми для цепи AND . VHDL разрешает упрощать такие процессы с одним назначением при помощи строки оператора называемого concurrent signal assignment (одновременное назначение сигнала).

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

Заметьте: параллельное присваивание сигнала эквивалентно процессу с только одним назначением сигнала. Если два или больше присваиваний появляются в процессе, они будут выполнены в предопределенной последовательности. Однако, если они были представлены параллельными присваиваниями сигнала, они будут выполнены одновременно.

Примеры:

Асинхронный S/R триггер - хороший пример параллельного выполнения присваивания сигнала в архитектуре:

entity rs is

port (

set: in bit;

reset: in bit;

q: buffer bit;

nq: buffer bit

);

end rs;

architecture rs_arch of rs is

begin

q <= not ( nq and set ) after 1 ns;

nq <= not ( q and reset) after 1 ns;

end rs_arch;

Рисунок:

7.3.2. Активизация Параллельных Назначений

Ключевые вопросы:

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

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


Это может потребовать, чтобы операторы одновременного назначения сигнала были чувствительны к изменению любого сигнала, который появляется справа после символа назначения. Фактически, это то, как VHDL моделирующие устройства действительно работают: при изменении любого из сигналов с правой стороны одновременно назначаются сигналы и активизируются выполнения присваивания. Это присваивание может быть отсрочено при помощи предложения after, или инерционной, или транспортной задержкой.

Примеры:

Предварительно описанный полный сумматор может быть упрощен при помощи операторов параллельного назначения сигнала:

entity fadder is

port (

a: in bit;

b: in bit;

Ci: in bit;

S: out bit;

Co: out bit

);

end fadder;

architecture fadder_arch2 of fadder is

signal s1, s2, s3, s4 : bit;

begin

s1 <= b xor Ci;

s2 <= b and Ci;

s3 <= a and b;

s4 <= a and Ci;

S <= a xor s1;

Co <= s2 or s3 or s4;

end fadder_arch2;

Рисунок:

7.3.3. Условное Присваивание Сигнала

Ключевые вопросы:

Иногда Вы можете нуждаться выполнить назначение сигнала для случая когда условие истинно. Начиная с условного оператора " если … затем … " последовательные операторы ограничены только процессами, поэтому Вам, вероятно, придется использовать условное назначение сигнала, которое может также использоваться внутри архитектуры. Это функциональный эквивалент условного оператора, но написан различными способами отличными от условного назначения сигнала.

Синтаксис условного назначения сигнала определяется способом, в котором дан порядок элементов: присваивание определенной величины сигналу, когда условие истинно, а если нет или иначе присваивание другого значения. Оператор else может быть вложен.

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

Примеры:

Модель цепи XOR. Первая архитектура применяет конструцию " если ...


затем ... еще ... ", в то время как вторая использует условное присваивание сигнала:

entity xor_gate is

port (

a: in bit;

b: in bit;

y: out bit

);

end xor_gate;

architecture xor_gate_arch1 of xor_gate is

begin

gate:process(a , b)

begin

if a=b then y<='0';

else y<='1';

end if;

end process gate;

end xor_gate_arch1;

architecture xor_gate_arch2 of xor_gate is

begin

Y <= '0' when a=b else

'1';

end xor_gate_arch2;

Рисунок:

7.3.4. Выборочное Присваивание Сигнала

Ключевые вопросы:

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

Заметьте: В отличие от оператора case, выборочное присваивание сигнала ограничено присваиванием только сигнала и не может содержать любые другие операторы.

Примеры:

Модель мультиплексора; Архитектура sel1_arch использовала выборочное присвоение сигнала а архитектура sel2_arch основана на операторе выбора (внутри процесса):

entity sel is

port (

i: in bit_vector (0 to 3);

s: in bit_vector (0 to 1);

o: out bit

);

end sel;

architecture sel1_arch of sel is

begin

with s select

o <= i(0) when "00",

i(1) when "01",

i(2) when "10",

i(3) when others;

end sel1_arch;

architecture sel2_arch of sel is

begin

mux :process (i, s)

begin

case s is

when "00" => o <= i(0);

when "01" => o <= i(1);

when "10" => o <= i(2);

when others => o <= i(3);

end case;

end process mux;

end sel2_arch;

Рисунок:

7.4.1. Концепция Драйвера

Ключевые вопросы:

Вы помните, что когда сигналы назначены, то их новые значения внутри процессов? Это назначение происходит только после того, как процесс приостановлен.


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

Эта функция выполняется драйвером. VHDL компилятор создает драйвера для каждого сигнала, которому присвоено значение внутри процесса. Правило очень просто: независимо от того, как присвоено значение сигналу в процессе, имеется только один драйвер сигнала на процесс. Все действия выполняются при помощи драйвера, который копируется к сигналу только тогда, когда процесс приостановлен.

Рисунок:

7.4.2. Каждый Сигнал Имеет Хронологию и Будущее

Text:

Ключевые вопросы:

Благодаря драйверу, сигнал может иметь прошлое, настоящее и будущие значение. Драйвера, содержащие текущее значение сигнала, показаны на предыдущей странице. Однако, драйвера могут также определять проектную форму сигнала для выходного сигнала. Каждому драйверу может быть назначена такая форма сигнала, состоящая из последовательности одних или большего количества транзакций. Транзакция состоит из значения сигнала и времени. Время определяет момент, когда драйверу будет назначено новое значение, указанное транзакцией.

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

Так как моделирующие устройства хранят транзакции для каждого сигнала, они создают фактически хронологию сигналов.

Примеры:

Это - модель синхронизации сигнал-генератора. Здесь не сложно описать хронологию и будущее сигнала меток времени.

entity clk_gen is

port(clock : out bit);

end clk_gen;

architecture clk_gen_arch of clk_gen is

begin

clk:process -- main clock generator

begin

clock <= '0';

wait for 5 ns;

clock <= '1';

wait for 5 ns;

end process;

end clk_gen_arch;

Рисунок:

7.4.3. Время Зависимые Атрибуты Сигналов

Ключевые вопросы:

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


Мы возвратимся этому подробние в Главе 9.

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

Примеры:

-- flip flop D type

library IEEE;

use IEEE.std_logic_1164.all;

entity ffd is

generic(setup_time : time := 2 ns;

hold_time : time := 5 ns);

port (d: in std_logic;

clk: in std_logic;

q: out std_logic);

end ffd;

architecture ffd_arch of ffd is

begin

main:process (clk)

begin

if rising_edge(clk) then

assert(d'last_event>=setup_time)

-- setup_check

report "setup time violation"

severity warning;

q <= d; -- assigning value

-- to the output

end if;

end process ; hold_check:process (clk'delayed(hold_time))

begin

if rising_edge(clk'delayed(hold_time))

then

assert (d'last_event>=hold_time)

-- setup_check

report "hold time violation"

severity warning;

end if;

end process ;

end ffd_arch;

Рисунок:

7.4.4. Другие Атрибуты

Ключевые вопросы:

Атрибуты относящиеся к хронологии сигналов - не единственные доступные атрибуты. Фактически, атрибуты совершенно часто используются в VHDL, и язык определяет 36 различных атрибутов для различных классов объектов: скалярные типы, дискретные типы, массивы, сигналы и именованные объекты. См. Руководство по применению для списка всех предопределенных атрибутов.

Кроме предопределенных атрибутов Вы можете также определять ваши атрибуты, расширяя набор VHDL почти до бесконечности.



Атрибуты имеют много приложений – от краевого детектирования ( основанного на атрибуте результата) до размерно-независимых спецификаций. Некоторые из наиболее типичных примеров приложений атрибута приведены на рисунке с права

Примеры:

Функция преобразовывает bit_vector в целое число. Объявление reverse_range и атрибутов длины делает эту функцию универсальный (она может использоваться для любого размера bit_vector без каких либо изменений кода).

entity decode is

port( i : in bit_vector(7 downto 0);

q : out integer range 0 to 255);

end decode;

architecture decode_arch of decode is

function bit_vec2int (Input: bit_vector) return integer is

variable Output: integer := 0;

variable power: integer := 1;

begin

if Input'length=0 then return Output; end if;

for I in Input'reverse_range loop

if Input(I)='1' then Output:= Output + power; end if;

power:= power * 2;

end loop;

return Output;

end bit_vec2int;

begin

q <= bit_vec2int( i );

end decode_arch;

Рисунок:

7.5.1. Может ли Сигнал иметь Два Драйвера?

Ключевые вопросы:

Когда сигнал имеет только один драйвер, его значение просто определить. Однако, что случается, когда сигнал имеет множество драйверов? Какие значения сигнала такие драйвера генерируют?

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

Трудно определить заранее, если "многократно - исходный" сигнал будет всегда управляться только отдельным источником. В некоторых системах это будет всегда истинно, в то же время в других может быть необходимость в смешанных сигналах из различных источников, эмулируя, например операции " зашитый И " или " зашитый ИЛИ ".


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

Примеры:

Это – модель контроллера шины для записи и чтения на\из устройств ввода-вывода. Также к шине можно обращаться снаружи. Заметьте: многократные драйвера сигналов шины и присвоение сигналов в различных процессах.

library ieee;

use ieee.std_logic_1164.all;

entity system is

port(instr : in integer range 0 to 4; -- code of instruction

data_bus : inout std_logic_vector(7 downto 0)); -- data bus

end system;

architecture system_arch of system is

signal rw : std_logic; -- '1' read; '0' write

signal sd : std_logic; -- select device - '1' memory; '0' I/O

-- interface

begin

ctrl:process(instr) --control process

begin

case instr is

when 0 => rw<='1'; sd<='1';-- intruction of

-- reading from memory

when 1 => rw<='0'; sd<='1';-- intruction of writing

-- from memory

when 2 => rw<='1'; sd<='0';-- intruction of reading from I/O

when 3 => rw<='0'; sd<='0';-- intruction of writing from I/O

when 4 => rw<='Z'; sd<='Z';-- no operation

end case;

end process ctrl;

mem:process(sd, rw) -- memory is emulated by process mem

variable cell : std_logic_vector(7 downto 0);

begin

if sd='1' then

if rw='1' then data_bus <= cell after 7 ns; -- reading from memory

else cell := data_bus; -- writing to memory

end if;

else data_bus <= ( others => 'Z'); -- setting high impedance

end if;

end process mem;

io_proc :process(sd, rw) -- input/output interface is emulated by process io

variable io : std_logic_vector(7 downto 0);

begin

if sd='0' and sd'event then

if rw='1' then data_bus <= io after 12 ns; -- reading from I/O port

else io := data_bus; -- writing to I/O port

end if;

else data_bus <= ( others => 'Z'); -- setting high impedance

end if;

end process io_proc;

end system_arch;

Рисунок:

7.5.2. Многократный Драйвер Сигнала Должен Быть Разрешен



Ключевые вопросы:

VHDL моделирующее устройство не может заранее "знать" будет ли сигнал с многократными драйверами активизирован из двух или больше источников в одно и то же самое время. Из-за этого, моделирующее устройство должно быть подготовлено к смешиванию значений сигнала. Такое "смешивание" сигналов называется в VHDL разрешение. Правила для смешивания значения сигнала определены как таблица, которая называется функцией разрешения. Таблица вносит в список все возможные значения сигнала в колоннах и строках, и каждая ячейка содержит информацию относительно того, что за значение будет сгенерировано, если два значения смешаны.

Сигналы Смешивания от различных водителей могли сравниваться с цветами смешивания на палитре живописца: каждый цвет, являющийся эквивалентом стоимости(значения) сигнала. Чистые цвета могли приравниваться к сигналам оденарной системы шин - driver. Однако, многократные цвета, наложенные на друг друге привели бы к полностью новому цвету.

Примеры:

Пример управления при помощи двух драйверов одним выходом. S сигнал определит, будет выход соединен с a или not a.

library ieee;

use ieee.std_logic_1164.all;

entity drivers is

port (

A : in std_logic;

S : in std_logic;

Y : out std_logic);

end drivers;

architecture drivers_arch of drivers is

begin

P1 : process (A, S)

begin

if S='1' then Y<=A;

else Y<='Z';

end if;

end process;

P2 : process (A, S)

begin

if S='0' then Y<=not A;

else Y<='Z';

end if;

end process;

end drivers_arch;

Рисунок:

7.5.3. Двузначная Логика Не Достаточна Для Разрешений

Ключевые вопросы:

Как Вы наверно отметили на предыдущей странице, функция разрешений требует больше информации чем основной набор значений. Например, три основных цвета из экрана на предыдущей странице нуждались в трех дополнительных, чтобы быть решенными.

Подобное имеет место , когда мы пытаемся представлять многократно - исходные сигналы в VHDL. Когда мы смотрим на сигнал битового типа, возникает очевидный вопрос,: что случится, если мы смешиваем '0' и '1' (какое разрешенное значение '0' и '1'?).


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

Этот факт будет иметь далеко идущие последствия: если Вы используете только типы bit и bit_vector, Вы НЕ способны определить микропроцессор в VHDL. Неразрешенные типы (подобные двум вышеупомянутым) не могут использоваться для сигналов с многократными драйверами, так как для них по очереди необходимымо определить шины передачи данных (которые очевидно существуют в каждом микропроцессоре). Чтобы решать эту проблему, Вы будете должны использовать некоторый другой логический тип данных, а именно с больше чем двумя значениями и функцией разрешения, который определен для всех комбинаций значения сигнала.

Примеры:

library ieee;

use ieee.std_logic_1164.all;

entity driver is

port (a : in bit;

y : out bit;

b : in std_logic;

z : out std_logic);

end driver;

architecture driver_arch of driver is

begin

p1:process( a )

begin -- this is enough condition for rising edge detection using

-- bit type

if a='1' and a'event then y <= a after 1 ns;
end if;

end process;

p2:process( b )

begin -- this is enough condition for rising edge

-- detection using std_logic type

if b='1' and b'event and b'last_value='0' then z <= b after 3 ns;

end if;

end process;

end driver_arch;

Рисунок:

7.5.4. Многозначная Логика

Ключевые вопросы:

Одних значений '0' и '1' не достаточно для разрешения многократно - исходных сигналов. Даже некоторые простые - исходные сигналы часто требуют больше чем два значения для представления реальной жизни цифровые объектов:

Иногда не важно, какое значение имеет сигнал. Это условие представлено значением " беззаботный " (“don’t care”); Буфера с тремя состояниями разъединяют драйвера и сигнальные линии у которых состояние " высокий импеданс ", которое не является ни '0', ни '1'; Иногда, система может иметь "неинициализированные" или “неизвестные” значения, которые отличаются от " беззаботного " (“don’t care”). Эти три и некоторые другие наиболее часто используемые значения определены типом std_ulogic, и находятся в блоке Std_logic_1164.


Этот блок также содержит определение векторного типа, который основан на типе std_ulogic и элементах std_ulogic_vector. Оба типа также имеют набор основных логических действий, определенных для них.

Примечание: буква 'u' внутри названия ulogic указывает на " неразрешенные типы ". Такие значения не могут использоваться сигналами, которые имеют множественные драйвера.

Примеры:

Это - пример таблицы разрешения и функции разрешения типа std_logic. Это - самый простой способ определить функцию разрешения для логики с 9 значениями:

PACKAGE BODY std_logic_1164 IS

-- part of real code taken from IEEE standard logic package

-- below is presented resolution table and resolution function

CONSTANT resolution_table : stdlogic_table := (

-- ---------------------------------------------------------

-- | U X 0 1 Z W L H - | |

-- ---------------------------------------------------------

( 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U' ), -- | U |

( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ), -- | X |

( 'U', 'X', '0', 'X', '0', '0', '0', '0', 'X' ), -- | 0 |

( 'U', 'X', 'X', '1', '1', '1', '1', '1', 'X' ), -- | 1 |

( 'U', 'X', '0', '1', 'Z', 'W', 'L', 'H', 'X' ), -- | Z |

( 'U', 'X', '0', '1', 'W', 'W', 'W', 'W', 'X' ), -- | W |

( 'U', 'X', '0', '1', 'L', 'W', 'L', 'W', 'X' ), -- | L |

( 'U', 'X', '0', '1', 'H', 'W', 'W', 'H', 'X' ), -- | H |

( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ) -- | - |

);

function resolved ( s : std_ulogic_vector ) return std_ulogic IS

variable result : std_ulogic := 'Z'; -- weakest state default

begin

-- the test for a single driver is essential otherwise the

-- loop would return 'X' for a single driver of '-' and that

-- would conflict with the value of a single driver unresolved

-- signal

if (s'length = 1) then return s(s'low);

else

for i in s'range loop

result := resolution_table(result, s(i));

end loop;

end if;

return result;

end resolved;

Рисунок:

7.5.5. Разрешенния Для Многозначной логики

Ключевые вопросы:



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

Для многозначных сигналов неразрешение делает все эти механизмы бесполезными. Из-за этого еще один тип std_logic определен в блоке Std_logic_1164:. Это соединяет выразительную мощность девяти значений std_ulogic с разрешением, давая проектировщику на VHDL действительно универсальный логический тип. Std_logic - в настоящее время фактический промышленный стандарт.

Единственное различие между std_logic и std_ulogic - то, что вышеупомянутый тип является решенной версией последних. Благодаря этому, все действия и функции (включая rising_edge и falling_edge) определенные для std_ulogic могут использоваться в std_logic без любых дополнительных деклараций.

Имеется разрешенная версия std_ulogic_vector также. Название получается совершенно логически: std_logic_vector (функция разрешения устраняет 'u' с названия).

Примеры:

Один выход управляется двумя независимыми драйверами:

library IEEE;

use IEEE.std_logic_1164.all;

entity drv is

port (

en_a: in boolean;

en_b: in boolean;

a: in std_logic;

b: in std_logic;

y: out std_logic

);

end drv;

architecture drv_arch of drv is

signal sa, sb : std_logic;

begin

sa <= a when en_a else 'Z';

sb <= b when en_b else 'Z';

p1:process (sa)

begin

y <= sa;

end process p1;

p2:process (sb)

begin

y <= sb;

end process p2;

end drv_arch;

Рисунок:

Резюме

VHDL это иерархический язык. Теперь мы должны можем определить системы как " набор параллельно работающих подсистем ". Каждая из этих подсистем будет определена как отдельный процесс, в котором поведенческая спецификация будет даваться как набор одновременно последовательных процессов. Как и большинство комплексных конструкций VHDL, архитектура состоит из шаблона и тела. Шаблон определяет, что эта конструкция архитектура и разрешает вводить в имя архитектуры и границы тела архитектуры. Исполнительная часть архитектуры (тело архитектуры) - параллельная структура. Всякий раз, когда сигнал в списке чувствительности процесса изменяет значение, процесс активизирован, независимо от того, заменен ли сигнал окружающей средой системы или другим процессом.


Фактически, даже тот же самый процесс может изменять процесс. Сигналы - единственные средства для пересылки информации между процессами. Одновременные операторы присваивания сигнала могут появляться внутри архитектуры вместе с процессами. Как их название предполагает, они могут быть выполнены одновременно друг с другом, как одноименные процессы. Одновременные операторы присваивания сигнала должны быть чувствительны к изменению любого сигнала, который появляется справа от символа назначения: изменение любого из сигналов справа для одновременного назначения сигнала, активизирует выполнение присваивания. Подобно присваиванию сигнала в процессах, часто необходимо выполнить присваивание только тогда, когда некоторое условие истинно. Неопытные пользователи VHDL пробуют писать это, используя конструкции " если … затем … ", но к их удивлению, никакие моделирующие устройства не принимают такую спецификацию. Вместо " если … затем … ", условное присваивание сигнала может использоваться внутри архитектуры. Синтаксис условного присваивания сигнала совершенно естественна и следует за способом, который дает порядок, а именно : присваивает заданную величину сигналу, когда условие выполнено, и в противном случае, присваивает другое значение. Чтобы присвоить сигналу, одно из отдельных значений, в зависимости от значения того же самого объекта, используется выборочное назначение сигнала. Эти параллельные конструкции не могут использоваться внутри процесса (где должен использоваться оператор case ). Каждый скалярный сигнал назначен набору драйверов (или, другими словами, управляется драйверами). Каждый раз, когда VHDL сталкивается с операторами присваивания сигнала, драйвер для того сигнала сгенерирован. Вся информация относительно ожидаемых изменений значения сигнала сохранена в драйвере сигнала. Каждый драйвер представлен формой сигнала, которая состоит из одной или более последовательных транзакций. Транзакция, состоит из значения и времени (сигнал имеет хронологию). Атрибуты - различные фрагменты информации, присоединенной к каждому сигналу и они автоматически реализуются на основе хронологии сигнала.
Далее>>

Объекты VHDL:Сигнал


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 3

Объекты VHDL:Сигнал

Содержание главы 3

3.1. Краткий обзор Главы

3.2. Введение в Сигналы

3.2.1. Понятие Сигнала

3.2.2. Сигналы в Электронных Приборах

3.2.3. Значение Электрических Сигналов

3.3. Основные Типы Сигналов

3.3.1. Отдельный Сигнал против Многократных Сигналов

3.3.2. Типы Сигнала: bit и bit_vector

3.3.3. Ширина Шины и Порядок Битов

3.4. Объявление Сигналов

3.4.1. Внешний против Внутренних Сигналов

3.4.2. Объявление Сигналов Интерфейса

3.4.3. Направление Потока информации: Режим Порта

3.4.4. Декларация Внутренних Сигналов

3.4.5. Видимость Сигналов

Резюме

3.1. Краткий обзор Главы

Перед изложением главного предмета этой главы обратим ваше внимание, что мы собираемся определять, модель и способ проектирования электронных приборов. Одно из определений электронных приборов состоит в том что “ они - системы для преобразования электрических сигналов ”. По этой причине сигналы являются наиболее важными компонентами электронных систем. Без сигналов, переносящих информацию от одной цепи к другой, не выполнялось бы никакое вычисление.

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

Секция 3 вводит два важных классификационных признака сигналов:

Единичный против множественного сигнала (провода и шины); вначале оба типа сигналов представлены неформально, а затем обсуждается их VHDL представление. Такие понятия как ширина шины и порядок битов в шине рассмотрены и объяснены; Внешний против внутренних сигналов; внешние сигналы соединяют систему с окружающей средой, и они составляют интерфейс системы.
Внутренние сигналы постоянно функционируют внутри системы и не видимы их снаружи. Обе группы иллюстрируются и показана их связь с VHDL представлением. Прежде, чем любой сигнал может быть использован в VHDL проекте, в его спецификации, он должен быть объявлен. Четвертая Секция посвящена этому вопросу. Эта глава будет готовить Вас для написания ваших первых VHDL спецификаций просто и доходчиво.

3.2.1. Концепция Сигнала

Ключевые вопросы:

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

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

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

Рисунок справа показывает отдельные примеры сигналов в реальной жизни.

Примеры:



Рисунок:

3.2.2. Сигналы в Электронных Приборах

Ключевые вопросы:

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

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


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

Имеются много способов классифицировать сигналы. Например, они могут быть классифицированы как сигналы, несущие информацию или внутри прибора или между электронными элементами. Это базовая классификация сигнала, принятая в VHDL.

Примеры:

Рисунок:

3.2.3. Значение Электрических Сигналов

Ключевые вопросы:

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

Сигналы допускают анализ временных зависимостей внутри VHDL системы. Кроме того, в отличие от переменных в классических языках программирования типа Паскаль или C, VHDL сигналы содержат информацию как о прошлых, так и настоящих их значениях. Эта информация называется историей сигнала.

Все эти свойства помещают сигналы среди наиболее важных понятий в VHDL. Это - то, почему мы начинаем наше введение в язык VHDL с описания сигналов.

Физически, электрический сигнал - поток электронов, которые являются подверженными воздействию общим законами физики. Однако, при программировании на VHDL Вы не должны волноваться относительно этих законов, потому что логический синтез и другие инструментальные средства поддержки будут автоматически заботиться о физическом рисунке схемы. Все, что Вы должны делать, это определить функциональные возможности и требуемые характеристики цепи.

Примеры:

Рисунок:

3.3.1. Единичный сигнал против множественного сигнала

Ключевые вопросы:

Электронные проекты основаны на компонентах и сигнальных линиях, соединяющих эти компоненты.


Сигнальные линии могут быть выполнены или как отдельные или как многопроводные линии связи.

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

Некоторые проекты включают множественные сигналы, названные шинами или векторами, которые передают информацию как комбинацию некоторых двоичных значений. Когда Вы слышите относительно процессора в 32-разряда то, это означает, что шина передачи данных несет 32 бита двоичных данных в любой момент.

Примеры:

Рисунок:

3.3.2. Типы Сигнала: bit и bit_vector

Ключевые вопросы:

" Единичный сигнал " и "вектор" – описательные имена. Так как формальная спецификация сигналов требуется, для того чтобы позволить нам рассматривать два основных типа сигналов, которые могут использоваться, чтобы определить любой сигнал.

Два типа сигнала, которые допускаются спецификацией VHDL, названы bit (битом) (для единичных сигналов) и bit_vector (бит_вектор)(для шин). В обоих случаях каждая сигнальная линия может быть или '0' или '1'. В случае bit_vector, также необходимо определять ширину.

Примеры:

Рисунок:



3.3.3. Ширина Шины и Порядок Битов

Ключевые вопросы:

В случае единичного провода все просто; Вы можете только говорить " этот сигнал, имеет р тип bit". Префикс bit сообщает что это все. Однако, описание шин – более комплексно. Во-первых, мы должны указать, что это – множественный сигнал, прибавляя слово: _vector, при этом формируется утверждение bit_vector.

Во-вторых, ширина шины и порядок линий или битов должен быть явно задан в списке. Например, это составляет главное различие , является ли разряд номер 7 старшим значащим битом (MSB), а номер 0 - самый младшим битом (LSB) в шине, или наоборот. Эта информация обеспечивается через диапазон вектора, которая всегда указывается в круглой скобках, например (7 downto 0). Диапазон вектора определяется в VHDL путем использования двух ключевых слов: или TO или DOWNTO.


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

Примеры:

Диапазон шины может быть определен четырьмя различными способами. Однако, только два из них правильны (и имеют смысл). Четырех-разрядная шина может быть правильно определена как:

bit_vector(0 to 3) ascending order of bits bit_vector(3 downto 0) descending order of bits Два неправильных технических данных диапазона шины могли быть написаны как:

bit_vector(0 downto 3) incorrect order of bits bit_vector(3 to 0) incorrect order of bits

Рисунок:



3.4.1. Внешний против Внутренних Сигналов

Ключевые вопросы:

Сигналы могут быть классифицированы как внутренние или как внешние:

Внешние сигналы - сигналы, которые соединяют систему со внешним миром. Другими словами, они формируют интерфейс системы; Внутренние сигналы, которые не видимы из наружной части, являются полностью вложенным внутри системы и являются частью внутренней архитектуры, обеспечивающей связь между внутренними линиями. Поскольку Вы можете помнить из предыдущей главы, подобное различие которое существует между сущностью и единицами архитектуры проекта. Фактически, внешние сигналы объявлены только в сущности, а внутренние сигналы определены исключительно в архитектуре.

Примеры:

При использовании упрощенной функциональной блок-схемы центрального процессора Вы можете классифицировать сигналы как внутренние или как внешние.



3.4.2. Объявление Сигналов Интерфейса

Ключевые вопросы:

Сигналы, соединяющие систему с окружающей средой названы портами и определены в секции сущности портов, которая определяет интерфейс системы. Каждый сигнал, который соединяет систему с внешним миром, определен как порт внутри сущности.

Каждый сигнал должен иметь уникальное название (например. Clock1 или DataBUS [0 to7]) и тип (например bit или bit_vector). Однако, порт должен иметь кроме того направление потока информации которое называется mode.


Этому объясняется на следующей странице.

Заметьте: Вы можете объявлять начальную значение для каждого сигнала порта.

Примеры:

Позвольте нам объявлять порты ЦЕНТРАЛЬНОГО ПРОЦЕССОРА. Этот пример показывает только общую идею и не должны трактоваться как реальная спецификация VHDL.

entity Central_Processing_Unit is

port( Input_CPU : mode bit_vector (31 downto 0);

Output_CPU : mode bit_vector (31 downto 0));

end Central_Processing_Unit;

И более детальный пример памяти ROM:



entity ROM_Memory is

port (A_ROM : mode bit_vector (3 downto 0); -- Address

CS_ROM : mode bit := ' 0' ; -- Chip Select

D_ROM : mode bit_vector (7 downto 0));-- Data

end ROM_Memory;

Рисунок:

3.4.3. Направление Потока информации: MODE Порта

Ключевые вопросы:

В циркулирующем направлении потока информации Мы должны определить, является ли частный сигнал входом, выходом или двунаправленным. Направление сигнала должно быть явно задано. Если это не определено, то по умолчанию объявляется как вход. Для установления направление сигнала в VHDL осуществляется приписывание соответствующей mode к каждому сигналу интерфейса. Следовательно, декларация порта имеет следующий синтаксис:

port_name : mode port_type

Несмотря на то, что VHDL поддерживает пять mode сигнала: IN, OUT, INOUT, BUFFER, и LINKAGE, рекомендуется, чтобы Вы использовали только первые три, т.к. последние два не поддержаны инструментальными средствами синтеза.

Типичные mode сигнала:

'in' – Данные могут читаться внутри архитектуры, но не могут быть выданы архитектурой; 'out' – Данные могут быть сгенерированы внутри архитектуры, но не могут читаться; 'inout' – Данные могут быть как записаны так и считаны в внутри архитектуры.

Примеры:

Теперь мы способны закончить сущность из предыдущей страницы с присущими mode:

Entity Central_Processing_Unit is

port( Input_CPU : in bit_vector (31 downto 0);

Output_CPU : out bit_vector (31 downto 0));

end Central_Processing_Unit;

entity ROM_Memory is

port (A_ROM : in bit_vector (3 downto 0); -- Address



CS_ROM : in bit; -- Chip Select

D_ROM : out bit_vector (7 downto 0));-- Data

end ROM_Memory;

Данные могут быть или написаны в память RAM или читать из нее. Это обозначено способом inout:

entity RAM_Memory is

port (A_RAM : in bit_vector (3 downto 0); -- Address

CS_RAM : in bit; -- Chip Select

D_RAM : inout bit_vector (7 downto 0));-- Data

end RAM_Memory;

Рисунок:

3.4.4. Декларация Внутренних Сигналов

Ключевые вопросы:

Сущность определяет интерфейс системы с внешним миром, а архитектура описывает все то, что постоянно находится внутри системы. Внутренние сигналы не исключение, и чтобы отличить их от других объектов в VHDL коде, ключевое слово signal должно использоваться в каждой декларации.

Заметьте: ключевое слово signal не нужно около порта, потому что каждый порт - по определению сигнал.

Заметьте: Внутренние сигналы не требуют декларации mode (in, out или inout).

Заметьте: возможно определить начальное значение для внутреннего сигнала.

Примеры:

Для того, чтобы облегчать связь между подсистемами центрального процессора (ROM памятью, RAM памятью, I/O блоками) мы должны определить внутренние сигналы для адреса, данных, и шин управления. Так как они - внутренние сигналы, их декларация расположена внутри архитектуры:

architecture Behavior_CPU OF Central_Processing_Unit is

-- Architecture declarative part

signal Address : bit_vector (31 downto 0);

signal Data : bit_vector (15 downto 0);

signal Control : bit_vector (10 downto 0) := " 00011101101" ;

begin

-- Architecture statements part

end Behavior_CPU;

Рисунок:

3.4.5. Видимость Сигналов

Ключевые вопросы:

"Видимость" каждого сигнала определена местом, в котором он объявлен:

Сигнал, объявленный в блоке видим во всех устройствах проекта, которые используют этот блок; Сигнал, объявленный как порт в сущности видим во всех архитектурах, которые приписаны этой сущности; Сигнал, объявленный в декларативной части архитектуры видим только внутри этой архитектуры; Сигнал, объявленный в блоке, расположенном внутри архитектуры видим только внутри этого блока. Эти правила следуют непосредственно из иерархических принципов проекта: если что – ни будь объявлено на одном иерархическом уровне, то это будет видимо только в этой части проекта и во всех его более низких уровнях.

Примеры:



Рисунок:

Резюме

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

Электронные проекты основаны на компонентах и сигнальных линиях, соединяющих эти компоненты. Сигнальные линии могут быть выполнены как: Однопроводные линии, которые имеют единичное двоичное значение в любой момент (представленной в VHDL типом bit); Многопроводные линии связи, которые называются шины или векторы, и передают информацию, являющуюся комбинацией некоторых двоичных значений (тип bit_vector, который поддерживается вектором с заданной шириной). Сигналы могут также быть классифицированы как: Внешние сигналы, которые формируют интерфейс системы; Внутренние сигналы, которые являются полностью вложенным внутри системы и обеспечивают связь между внутренними линиями. Каждый сигнал в спецификации проекта VHDL должен быть объявлен. Сигналы могут быть явно объявлены в декларативной части: пакета - Сигналы видимы во всех частях проекта, использующих пакет; архитектуры (внутренний сигнал) - Сигналы - видимы только внутри архитектуры; блока – Сигналы – видимы непосредственно внутри блока. Кроме того, декларация порта (внешняя декларация сигнала) по существу - неявная декларация сигнала. Сигнал объявленный таким способом видим во всех архитектурах, приписыванных к этой сущности. Сигналу может быть назначено начальное значение в декларации. Если не имеется никакого выражения в декларации сигнала, то значение по умолчанию сигнала - левая граница указанного типа. Запрещено объявлять сигналы в процессе или подпрограмме, за исключением тех случаев, когда они вводятся как формальные параметры.
Далее>>

Описание Поведения при помощи Процессов


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 6

Описание Поведения при помощи Процессов

Содержание Главы 6

6.1. Краткий обзор Главы

6.2. Введение в Процессы

6.2.1. Спецификация Поведения

6.2.2. .Что такое - Процесс?

6.2.3. Структура Процесса

6.2.4. Выполнение Процесса

6.3. Выполнение Процесса управления

6.3.1. Потребность в Приостановке и Возобновлении Процессов

6.3.2. Оператор Wait

6.3.3. Различные Типы Операторов Wait

6.3.4. Различное Местоположение Оператора Wait

6.3.5. Список Чувствительности Процесса

6.3.6. Как Работает Список Чувствительности

6.4. Процесс -Specific Объект: Переменная

6.4.1. Сигналы в Процессах

6.4.2. . Иногда Не Достаточно Сигналов

6.4.3. Декларация и Присваивание Переменным

6.4.4. Сигналы против Переменных

6.5. Управление Последовательностью положений

6.5.1. Введение

6.5.2. Оператор Условный

6.5.3. Альтернативные Условные Операторы

6.5.4. Множественный Выбор

6.5.5. Условные Циклы

6.5.6. Цикл со Счетчиком

6.5.7. Неполные Циклы Резюме

Резюме

6.1. Краткий обзор Главы

Точно так же, как сигналы описывают, как сделана электронная система, процессы определяют поведение системы. Эта глава объясняет что такое процесс и как он определяется и выполняется.

Секция 2, " Введение в Процессы ", вводит концепцию процесса и объясняет, как описать его поведение Описание выполнения процесса заканчивает эту секцию.

Выполнение Процесса подобно выполнению программы. Имеется, однако, одно важное различие: процесс вообще повторяется неопределенно, если специальные операторы не останавливают его. Секция 3, " Влияние На выполнение Процесса ", показывает, как такие операторы могут применяться к процессу и как они влияют на его выполнение.


Секция 4 представляет второй ключевой объект в VHDL - переменную. Переменные имеют много общего с сигналами, но имеются также некоторые значительные различия. Для уяснения деталей См. Секцию 4.
Все операторы внутри процесса выполняются последовательно. Однако, Вы можете влиять на последовательность их выполнения, используя условия их выполнения, определяя ветви и повторяя избранные участки в циклах. Все эти методы представлены в секции 5.

6.2.1. Спецификация Поведения

Ключевые вопросы:

Что означает " поведение системы " ? Главная цель любой электронной системы или элемента состоит в том, чтобы преобразовать входные данные в результаты в выходные результаты. Этот вид деятельности назван "поведеним" или "функционированием " системы, а спецификация системы описывает, как входные данные преобразовываются в выходные результаты.
Поведенческая спецификация - список действий, которые должны выполниться, чтобы получить ожидаемые результаты.

Примеры:

Предложенный пример показывает систему, сначала определенную в виде блок-схемы а затем представленнуюв виде последовательности условных действий (описанных на псевдоязыке):

Рисунок:

6.2.2. Что такое - Процесс?

Ключевые вопросы:

Действие дозатора напитка из рисунка на предыдущей странице зависело от последовательности действий. Фактически, это совершенно типично для большинства спецификаций проекта. Когда кто - то делает процедуру для выполнения чего - нибудь, он, или она представляет список действий, которые будут предприняты шаг за шагом или последовательной форме.
Процесс - формальный способ создания такого списка последовательных действий. Он имеет очень структурный формат, даже если он представляет поведение только небольшой секции проекта.
Примечание: рисунок с права (без действий) и приведен здесь только, потому чтобы напомнить процесс из предыдущей страницы.

Примеры:

Псевдокод, созданный на предыдущей странице может быть перезаписан в VHDL:

Рисунок:

6.2.3. Структура Процесса


Ключевые вопросы:

Написание VHDL спецификации требует знания языка. К счастью, имеются только несколько правил для написания процессов, которые описывают поведение системы.
Сначала, Вы должны определить, что часть кода, который Вы собираетесь написать в процесс. Это объявляется ключевым словом process. Вы можете присвоить имя процессу, если Вы желаете улучшить удобочитаемость проекта. Такое имя должно появиться перед ключевым словом process и должно сопровождаться двоеточием. Это имя может быть повторено в конце, с права после оператора end process, но без двоеточия.
Как Вы уже знаете, процесс это последовательность операций (операторов). Список операторов процесса стартует начиная с ключевого слова begin, и заканчивается ключевым словом end process, и далее следует имя процесса, если это необходимо.
Чтобы ясно отделить последовательнность операторов из деклараций таких как Variable или Сonstant, который могут появляться ниже операторов процесса, ключевое слово, begin размещают ниже декларации и сопровождают ‘ списком последовательных операций.

Примеры:

Ниже приведенный пример показывает D-триггер. Триггер имеет информационный вход D, счетный вход CLK и два асинхронных входа (CL-сброс и PR-предварительная устанавка).

Рисунок:

6.2.4. Выполнение Процесса

Ключевые вопросы:

С тех пор конструкции VHDL, представляют реальные системы, концепция завершения процесса заслуживает некоторого дополнительного толкования. Рассмотрим, например, действие типичной системы. Она выполняет последовательность действий, а затем останавливается навсегда? Или она повторяет эти действия в бесконечном цикле?
Второе утверждение - много ближе к действительности, не так ли? По этой причине, процесс гарантирует, что после выполнения последнего оператора система немедленно начинает выполнение первого оператора. В результате " процесс НИКОГДА не прерывается ".
В следующей Секции Вы увидите, что процесс может быть приостановлен, а затем возобновлен, этим приближаясь к реальному поведению систем.

Примеры:


Рисунок:

6.3.1. Потребность в Приостановке и Возобновлении Процессов

Ключевые вопросы:

Электронные приборы обычно функционируют в бесконечном цикле; после их активации они выполняют внесенные в список задачи а затем возвращаются и ожидают условия, при котором будет встречено нужное состояние. Другими словами, элемент приостанавливает действие, когда он заканчивает текущую задачу и возобновляет действие, когда указанные условия появляются снова.
Такие операции элементов в VHDL описываются оператором wait. Он приостанавливает процесс, когда указанная задача закончена, а затем возобновляет ее снова, когда указанное условие выполнено. Возобновление процесса может быть выполнено только одним оператором в форме, ожидания условие , которое будет выполнено.

Примеры:

Ниже на рисунке показано действие оператора wait.

Рисунок:

6.3.2. Оператор Wait

Ключевые вопросы:

Прежде, чем приостановленный процесс может возобновиться, он должен дождаться условия, которое будет выполнено. Оператор wait используется для этой цели:
Он безоговорочно останавливается (приостанавливает) выполнение процесса. Он вносит в список условие, которое возобновит процесс. Если процесс содержит оператор wait , то он выполняет последовательно все операторы, пока не сталкивается с wait. Затем процесс приостанавливается и ждет условие, которое внесено в список оператора wait, и которое будет выполнено. Когда это случиться, процесс возобновляется и выполняет все операторы, пока снова не встретится с оператором wait

Примеры:

Если два или больше wait операторов находятся в процессе, процесс будет приостановлен и возобновлен на каждом из операторе wait:

Рисунок:

6.3.3. Различные Типы Операторов Wait

Ключевые вопросы:

Так как в реальных приложениях различные условия могут возобновлять процесс, то вVHDL предлагается три типа операторов wait: заданное время ожидание возобновления процесса, ожидание пока не будет выполнено некоторое Булево условие, и ожидание изменения значения сигнала. Эти три типа конструкций имеют следующую форму:


wait for type_expression; wait until condition; wait on sensitivity_list. Совместное применение некоторых или всех этих конструкций определяет, конструкцию названную комплексное условие.
Все четыре случая иллюстрируются в примерах справа.

Примеры:

signal Sig_1, Sig_2 : bit;
. . .
My_process : process
begin
. . .
wait on Sig_1, Sig_2;
end process My_process;
После выполнения всех операторов, процесс будет приостановлен на операторе wait и будет возобновлен, когда один из сигналов Sig_1 или Sig_2 изменит свое значение.
wait until EN = '1';
В этом примере, оператор wait возобновит процесс в том случае когда сигнал изменит значение на '1'.
wait for 50 ns;
Процесс, содержащий этот оператор будет приостановлен на 50 ns.
My_process : process
begin
wait on In_A, In_B until Clock = '1';
. . .
end process My_process;
Процесс My_process возобновится после изменения сигналов In_A или In_B только в том случае, когда значение сигнала датчика меток времени станет равным '1'.

Рисунок:

6.3.4. Различное Местоположение Оператора Wait

Ключевые вопросы:

Все операторы процесса выполняются в бесконечном цикле, то есть когда последний оператор, размещенный справа перед end process заканчивается, то первый который находится после begin начинается. Вначале мы предполагали, что не имеет значения размещен ли оператор wait в начале или в конце процесса.
Однако, в общем случае это не верно. Например, если моделирующее устройство сталкивается с оператором wait с права в начале процесса, то процесс будет приостановлен немедленно без выполнения любых операторов. С другой стороны, если wait размещен в конце процесса, то часть операторов будет выполнена до того как процесс будет остановлен.
Оператор wait может появляться где-нибудь в процессе. Обычно, он размещается или в начале или в конце процесса. В процессе допускается кратный оператор wait. Это наиболее часто используются в испытательных стендах (testbenches), которые будут обсуждаться в Главе 9.

Примеры:

Цифровая схема приведенная ниже может быть определена разными способами.


Внесенные в список процессы только отличаются по локализации оператора wait. Однако, все это производит к различным результатам.

VHDL определяет процессы следующим образом:
First_process : process Second_process : process
begin begin
wait on A, B, C; Y1 <= A and B;
Y1 <= A and B; Y2 <= B and C;
Y2 <= B and C; wait on A, B, C;
end process First_process; end process Second_process;

Рисунок:

6.3.5. Список Чувствительности Процесса

Ключевые вопросы:

Ожидание в списке чувствительности, то есть ожидание изменения значения сигнала, возможно является наиболее часто используемым условием для возобновления процессов; причем VHDL поддерживает конструкцию называемую - список чувствительности процесса. Список определен после ключевого слова process и приводит к тому же, что и wait sensitivity_list в конце процесса.
Примечание: В соответствии с правилами выполнения (приведенными на предыдущей странице), wait в начале процесса - НЕ, эквивалент к наличию wait sensitivity_list.
Также важно заметить, что процесс со списком чувствительности не может содержать любой явный оператор wait. ПРИМЕРЫ:
Второй процесс из предыдущего примера может быть преобразован в эквивалентный процесс со списком чувствительности:

Рисунок:

6.3.6. Как Работает Список Чувствительности

Ключевые вопросы:

Так как процессы со списками чувствительности доминируют в спецификациях VHDL ,то небольшая трата времени оправдана, чтобы уяснить, как выполняются такие процессы.
Когда начинается моделирование, процесс выполнится, один раз, потому что список чувствительности эквивалентен оператору wait в конце процесса и оператор wait останавливает выполнение процесса.
Процесс приостановлен, пока любой из сигналов в списке чувствительности не изменит значение. Такая замена возобновляет процесс и все операторы в процессе, от начала до конца, выполняются последовательно. Заметьте, что слово all относится к всем операторам в процессе, а не только к тем, которые касались сигналов, позволяющих возобновить процесс.


Когда выполнение последнего оператора закончено, процесс приостановлен снова.

Примеры:

Ниже процесс чувствителен к сигналам RST и CLK, то есть результат на любом из этих сигналов заставит процессу возобновиться. Этот процесс эквивалентен тому, который описанный в секции комментария.
DFF : process (CLK,RST)
begin
if RST = '1'
then Q <= '0';
elsif (CLK'event) and (CLK = '1')
then Q <= D;
end if;
end process DFF;
-- DFF : process
-- begin
-- if RST = '1'
-- then Q <= '0';
-- elsif (CLK'event) and (CLK = '1')
-- then Q <= D;
-- end if;
-- wait on RST, CLK;
-- end process DFF;

Рисунок:

6.4.1. Сигналы в Процессах

Ключевые вопросы:

Основная цель поведенческой спецификации VHDL состоит в том, чтобы описать реакцию выходов на входы. И входы и выходы - сигналы, так что реакции выходных сигналов даются как назначения сигнала. Сигналы и присвоенные сигналы появляются внутри процессов. Однако, использование сигналов в процессах регулируется в соответствии с тремя важными ограничениями:
Сигналы не могут быть объявлены внутри процессов. Любое присвоение сигналу воздействует только, когда процесс приостанавливает. Пока это не случается, все сигналы хранят их предыдущие значения. Только последнее присвоение сигналу, внесенное в список внутри процесса эффективно. Таким образом, в данном процессе не имеет смысла присваивать больше чем одно значение сигналу.

Примеры:

Если значение присвоено сигналу в процессе и сигнале находится в списке чувствительности этого процесса, то изменение значения этого сигнала может привести к восстановлению процесса:
signal A, B, C, X, Y, Z : integer;
process (A, B, C)
begin
X <= A + 1;
Y <= A * B;
Z <= C – X;
B <= Z * C;
end process;
Когда процесс активизирован результатом на сигнале C, то это приведет к замене сигнала B внутри процесса. В свою очередь это восстановит процесс, так как B находится в списке чувствительности.

Рисунок:

6.4.2. Иногда Не Достаточно Сигналов

Ключевые вопросы:

Ограничения на использование сигналов имеют серьезное значение в ряде практических приложений.


Неспособность объявлять сигналы внутри процессов - не главная проблема, но правила присваивания имеют серьезные последствия.
Так как сигналы могут хранить только последнее присвоенное значение, то они не могут использоваться для хранения промежуточных или временных данных внутри процессов.
Другое главное неудобство – это то, что новые значения присвоенные сигналам не в течение выполнения, а после приостановки процесса. Это делает анализ проекта, совершенно громоздким. Эксперименты с примером для лучшего понимания, как ведут себя сигналы в процессах затруднительны.
Так как сигналы не могут быть объявлены внутри процессов, и присваивание значений происходит после того, как процесс приостановлен, то имеется потребность в объекте, который мог бы быть объявлен внутри процесса и который обеспечил бы мгновенное хранение временных данных. Такой объект в VHDL существует и назван переменной.

Примеры:

Рассмотрите ниже приведенный процесс, в котором присвоение сигналам новых значений потребует времени. Однако, результаты этих присвоений - не видимая наружная часть процесса, как показано на временной диаграмме:

Эта проблема может быть решена через применение переменных в процессе:

Рисунок:

6.4.3. Декларация и Присваивание Переменным

Ключевые вопросы:

Переменные подобны сигналам. Однако, из-за их характерных особенностей они могут использоваться в некоторых приложениях, для которых сигналы подходят плохо. Например, они могут использоваться для описания алгоритмов внутри процессов.
Поэтому переменные ограничены процессами, они объявляются в процессах и не могут быть используемы вне их. Декларация переменных выглядит подобной декларации сигнала. Единственное различие состоит в том, что переменная объявляется с ключевым словом variable вместо ключевого слова signal, которое зарезервировано только для сигналов.
Присваивание значения переменной осуществляется символом ': = '. Такое присваивание мгновенно, и каждой переменной могут быть назначены новые значения столько раз сколько это необходимо.

Примеры:


Переменная может быть объявлена так, чтобы быть любого типа или доступного подтипа:
type Mem is array (natural range <>, natural range <>) of std_logic;
variable Delay1, Delay2 : time;
variable RAM1: Mem (0 to 1023, 0 to 8);
Начальное значение переменной может быть назначено глобально статическим выражением. Выражение непосредственно должно сослаться на значение того же самого типа как и переменная:
Variable TempCond : boolean := true;
Разные операторы присваивания изменяют значения пременной:
Variable X, Y : real;
variable A, B : bit_vector (0 to 7);
X := 1000.0;
A := B;
A := "11111111";
A (3 to 6) := ('1','1','1','1');
A (0 to 5) := B (2 to 7);
A (7) := '0';
B (0) := A (6);

Рисунок:

6.4.4. Сигналы против Переменных

Ключевые вопросы:

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

Примеры:

Если значение последовательного сигнала появляется внутри процесса, то это воздействует, на процесс приостановки. Если имеется больше чем одно присваивание для одного и того же сигнала в процессе, то для приостановки имеет значение только последний :
signal A, B, C, X, Y, Z : integer;
process (A, B, C)
begin
X <= A + 1;
Y <= A * B;
Z <= C – X;
Y <= B;
end process;
Когда этот процесс выполнен, операторы присваивания сигнала выполняются последовательно, но второе назначение (Y < = * B) никогда не будет выполнено, потому что только последнее присваивание для Y будет активизировано.


end if;
if Code_of_Operation(1) = '1'
then F := Operand_1 - Operand_2;
end if;
if Code_of_Operation(0) = '1'
then F := "00000000";
end if;

Рисунок:

6.5.3. Альтернативные Условные Операторы

Ключевые вопросы:

Выше описанные условные операторы совершенно просты и требуют некоторых расширений для большей гибкости. Например, нам нужно реализовать случай типа, ", если условие выполнено, некоторые действия предприняты, но если нет, другой набор действий выполняется ". Это конструирует, представления типа " если … затем … еще … " операторы.
Эти операторы ветвления могут быть далее расширены. Когда 'еще' предложение активно, то оно может содержать другое условные операторы, формируя иерархические условия. Такая ситуация может быть обработана в VHDL конструкцией " если … затем … elsif … ".

Примеры:

Ниже приведена поведенческая модель схем ExOr и Or.В модели применяют операторы если … затем … еще … и если … затем … elsif …, соответственно. Все сигналы (In1, In2 и Y) имеют бит тип.
architecture ExOr_Gate_Arch1 of ExOr_Gate is
begin
process (InA, InB)
begin
if InA=InB then Y <= '0';
else Y <= '1';
end if;
end process;
end architecture ExOr_Gate_Arch1;
architecture Or_Gate_Arch1 of Or_Gate is
begin
process (InA, InB)
begin
if InA='1' then Y <= '1';
elsif InB='1'
then Y <= '1';
else Y <= '0';
end if;
end process;
end architecture ExOr_Gate_Arch1;

Рисунок:

6.5.4. Множественный Выбор

Ключевые вопросы:

Конструкции " Если … затем … elsif … " – это операторы множественного выбора, которые позволяют выбирать отдельные ветви в зависимости от проанализированных условий. Однако, такие конструкции трудночитаемы, если число ветвей больше трех. В этих случаях применение операторов множественного выбора - намного лучший выбор.
Вместо Булева условия, операторы проверяют выражение дискретного типа (любое перечисление или тип целого числа) или типа массив литер. Практически, это выражение – обычно имя объекта.


Каждая альтернативная группа действий определяется выражением " когда выбор = > " предложение "выбора", которое определяет значения выражения. Одни значения могут быть единственные, другие находиться в диапазоне значений, однако они не могут использоваться совместно друг с другом.

Примеры:

Конструкции из предыдущей страницы, если … затем … еще …, могут быть заменены оператором case:
architecture ExOr_Gate_Arch2 of ExOr_Gate is
begin
process (InA, InB)
variable temp : bit_vector (1 downto 0);
begin
temp := InA & InB;
case temp is
when "00" => Y <= '0';
when "01" => Y <= '1';
when "10" => Y <= '1''
when "11" => Y <= '0';
end case;
end process;
end architecture ExOr_Gate_Arch2;

Рисунок:

6.5.5. Условные Циклы

Ключевые вопросы:

Операторы условных циклов начинаются с логических условий и функционируют аналогично условному оператору " если … затем … ", но выполняют переход к началу цикла после самого последнего оператора.
Цикл повторяется до тех пор пока условие в начале цикла истинно. Сначала, условие проверяется и если оно истинно, то операторы внутри цикла выполняются. Если условие ложно, цикл заканчивается, и управление передается к самому первому оператору, который следует после цикла.
Обычно, такие циклы используются, для того чтобы многократно выполнять набор действий, до тех пор пока сигнал или переменная принимает выбранное значение.
Пример приведенный справа счетчик, который считает накопление CLK до тех пор, пока сигнал Level '1'. Заметьте, что устойчивость сигнала Level не анализируется. Все что только проверяется в начале цикла - это то является ли Level = '1', тогда ребро накопления CLK обнаружено. При этом не имеет значение, если Level изменил значение по сравнению с предыдущей проверкой.

Примеры:

Shift_1: process (Input_X)
variable i : positive := 1;
begin
L1: while i <= 8 loop
Output_X(i) <= Input_X(i+8) after 5 ns;
i := i + 1;


end loop L1;
end process Shift_1;

Рисунок:

6.5.6. Цикл со Счетчиком

Ключевые вопросы:

Цикл с условием продолжения повторяет тело неограниченное число раз, пока условие, указанное в заголовке цикла истинно. Однако, иногда необходимо повторить действия заданное число раз. Чтобы выполнить это, более удобно использовать цикл со счетчиком вместо цикла с условием продолжения. Фактически такой цикл используются на практике намного чаще чем циклы с условием продолжения.
Цикл со счетчиком не содержит Булево условие. Вместо него, дискретный диапазон начала и конца цикла задается. После того, как закончен один проход цикла , переменной цикла присваивается следующее значение из указанного диапазона. Счетчик, который не объявляется (по спецификации в заголовке цикла он равен декларации), трактуется как постоянный внутренний цикл и не может использоваться в операциях присваивания, индексации или выражениях, где он может быть изменен. Кроме того, счетчик существует только внутри цикла, в котором он объявлен.
Счетный диапазон не должен быть определен в классической форме как от … до …. Он может быть внесен в список как перечисляемый тип или подтип. В таком случае только подтип определен как диапазон счетчика.

Примеры:

Shift_2: process (Input_X)
begin
L2: for count_value in 1 to 8 loop
Output_X(count_value) <= Input_X(count_value + 8) after 5 ns;
end loop L2;
end process Shift_2;
Shift_3: process (Input_X)
subtype Range_Type is positive range 1 to 8;
begin
L3: for count_value in Range_Type loop
Output_X(count_value) <= Input_X(count_value +8) after 5 ns;
end loop L3;
end process Shift_3;

Рисунок:

6.5.7. Неполные Циклы

Ключевые вопросы:

Итерации условных и безусловных циклов повторяются и выполняют все свои операторыдо тех пор, пока условие цикла истино. Однако иногда, , желательно игнорировать некоторые из операторов цикла на текущей итерации и идти непосредственно на следующую итерацию того же самого цикла. Такая ситуация встречается например при подсчете битов со значением '1' в бит векторе (рисунок справа): когда бит – 1 то происходит приращение счетчика, а если бит нулевой, цикл должна игнорировать эту итерацию.


Оператор next выполняет этот вид действий.
Помимо оператора next, который выполняет переход на следующую итерацию, имеются ситуации, которые требуют завершения итераций, даже если условие истинно. Оператор exit может выполнять это.
Переход на следующую итерацию и выход из цикла может быть назначен при помощи условия их выполнения. Так как это действие используется довольно часто, VHDL имеет упрощенный метод поддержки для next и exit операторов: это условие определено в предложении when, которое следует за оператором.

Примеры:

L4: loop
A:= A+1;
exit L4 when A > 10;
end loop L4;
L5: for count_value in 1 to 10 loop
exit L5 when reset = '1';
A_1: A(count_value) := '0';
end loop L5;
A_2: B <= A after 10 ns;

Рисунок:

Резюме

Поведение системы - способ, которым система преобразовывает входные данные в выходные. Спецификация Поведения - последовательность действий, которые должны выполниться, чтобы получить ожидаемые результаты. Процесс представляет поведение некоторого блока проекта. Он состоит из последовательности операторов, порядок выполнения которых определяется пользователем. Выполнение операторов однако не заканчивается при выполнении последнего оператора в процессе, они повторяются в бесконечном цикле. Цикл может быть приостановлен и возобновлен оператором wait. Когда с оператором wait сталкивается в процесс,то он становится приостановленным, то есть при этом останавливается его выполнение, пока условие, поддержанное оператором wait не выполнено. В зависимости от типа оператора wait, могут иметься отдельные условия для продолжения выполнения приостановленного процесса: блокировка по указанному времени истекла (оператор wait), логическое условие выполнено (оператор wait for), пришел нужный сигнал (оператор wait on) Возобновленный процесс выполняет операторы последовательно в цикле, пока не сталкиваются с оператором wait. Когда это происходит, процесс становится приостановленным снова. Оператор wait может появляться в любом месте процесса. Обычно, он используется, или в начале (процесс будет приостановлен немедленно без любых выполняемых операторов) или в конце процесса (некоторые операторы будут выполнены до приостановки процесса). VHDL обеспечивает конструкции, которые назваются список чувствительности процесса, и используются для возобновления процесса.


Список чувствительности - способ определения набора сигналов или результатов, которые могут возобновлять процесс. Список чувствительности - указывается справа после ключевого слова process. Список чувствительности эквивалентен оператору wait, который является последним оператором в секции операторов (оператор wait on в начале процесса - НЕ эквивалент к списку чувствительности процесса). Также очень важно заметить, что процесс со списком чувствительности не может содержать любой оператор wait. Присваивание значения сигналу имеет эффект только, когда процесс приостанавливает и только последнее назначение на любой частный сигнал внутри процесса эффективно в данном выполнении процесса. Сигналы не могут быть объявлены внутри процессов. Переменные - объекты, совместимые с сигналами. Они способны обслужить цели, для которых сигналы не подходят - описание алгоритмов внутри процессов. Переменные объявляются внутри процессов и не могут быть использованы в их наружной части. Сигнал имеет три реквизита, присущие ему: type, value, и time. Имеется особенно близкая связь между значением и временем: сигнал имеет временную диаграмму, которая называется хронологией сигнала. Этим способом, возможно проверить то, какое значение сигнал имел ранее или когда последнее изменение значения происходило. Переменная имеет два реквизита: тип и значение. Не имеется никакого выбора времени, присущего переменной, и единственное значение - текущая значение. Процессы, которые выполняют операторы последовательно, являются совершенно редкими. Практические, процессы представляют реальные действия
Далее>>

Определение Структуры Системы


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

ГЛАВА 8

Определение Структуры Системы

Содержание Главы 8

8.1. Краткий обзор Главы

8.2. Структурные Описания

8.2.1. Введение

8.2.2. Элементы Структурных Описаний

8.2.3. Компоненты и Составляющие Требований

8.2.4. Отображение Порта

8.3. Реализация Прямого Объекта

8.3.1. Прямая Реализация

8.3.2. Позиционная Ассоциация Порта

8.3.3. Именованная Ассоциация Порта

8.3.4. Сложные Порты и Сигналы

8.3.5. Порты без Связей

8.4. Компоненты и Конфигурации

8.4.1. Введение в Компоненты

8.4.2. Компоненты Деклараций

8.4.3. Компонент Реализаций

8.4.4. Конфигурации

Резюме

8.1. Краткий обзор главы

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

В структурных описаниях VHDL могут использоваться два типа компонент: компоненты, которые являются копиями или примерами системы, скомпилированными ранее (пары архитектуры объекта) и компоненты непосредственно указанные внутри текущей структурной архитектуры. Первый тип, называемый прямой реализацией и описан подробно в Секции 3. В дополнение к объяснению, как использовать существующий проект VHDL внутри новых описаний, мы также обсудим присваивание сигналов портам.

Секция 4 объясняет инстоляцию компонент. Она показывает то, что должно быть сделано для того, чтобы использовать эти компоненты более гибко, что является более трудным путем определения структур VHDL. Также будут представлены концепции конфигурации и связывания.

8.2.1. Введение

Ключевые вопросы:

Функциональное описание VHDL определяет системы в терминах их операций.
Структурное описание определяет то, из чего сделана система; из чего состоят подсистемы или компоненты и как они связаны.

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

Примеры:

-- behavioral specification

-- of AND gate

entity and_b is

port (a,b : in bit;

y : out bit);

end and_b;

architecture b_arch of and_b is

begin

Y <= a and b;

end b_arch;

-- structural specification

-- of two-gate circuit

entity gates_s is

port (X1,X2,X3: in bit;

Y: out bit);

end gates_s;

architecture s_arch of gates_s is

component and_b

port (a,b : in bit;

y : out bit);

end component and_b;

signal y_temp : bit;

begin

U1: and_b port map (X1,X2,y_temp);

U2: and_b port map (y_temp,X3,Y);

end s_arch;

Рисунок:

8.2.2. Елементы Структурных Описаний

Ключевые вопросы:

Структурная спецификация состоит из связанных компонентов. Эти компоненты связаны друг с другом и их внешней средой через сигналы. Структурная спецификация требует двух групп элементов:

Компонент может быть индивидуальной системой, определенный как отдельный объект и архитектура; Компонент может быть определен внутри архитектуры с декларацией компонента. В обоих случаях декларация компонента обработана как общая спецификация –что-то вроде элемента каталога. Чтобы использовать такие элементы, нужно чтобы они были реализованы в структурной спецификации. Таким образом, компонент реализации –это основная инструкция в структурной архитектуре. Подобно другим инструкциям архитектуры, компоненты реализаций параллельны друг другу.

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


Сигналы, используемые в отображении порта могут быть определены как порты или как внутренности системы. Внутренности системы должны быть объявлены в декларативном разделе архитектуры. Пример:

Entity Example is

Port (X1,X2 : in bit;

Y : out bit);

end entity Example;

architecture Example_arch of Example is

-- component declaration

component and_b

port (a,b : in bit;

y : out bit);

end component and_b;

begin

-- gate1: and_b port map (X1,X2,Y);

-- good example - component gate1 instantiation

-- gate2: and_b port map (Y,X1,X2);

-- bad example

-- gate3: and_b port map (a=>X1,b=>X2,y=>Y);

-- good example - port mapping

gate4 and_b port map (b=>X2,y=>Y,a=>X1);

-- good example

. . .

end architecture Example_arch;

Рисунок:

8.2.3. Компоненты и Составляющие Требований

Ключевые вопросы:

Эффективное использование компонентов – главное преимущество структурных описаний VHDL. Весь следующий раздел будет посвящен этой теме.

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

Каждая реализация компонента состоит из следующих частей:

Instance_name: entity work.entity_name(architecture_name)

Где 'work' – имя библиотеки, где сохранены все определяемые пользователем элементы. См. следующий раздел для уточнения деталей.

Примеры:

Рисунок:

Перечень Ключевых Слов :

Реализация компонент,Декларация компонент Заметки пользователя:

8.2.4. Отображение Порта

Ключевые вопросы:

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

Отображение, которое используется в предложенном примере, называется named association (именованная ассоциация),так как каждый порт связывается с сигналом, используя явное имя порта.


Более простая форма - позиционная ассоциация, где сигналы в отображении порта перечислены в том же самом порядке как и порты в декларации объекта компонента.

Примеры:

entity Example_beh is

port(

A : in integer;

B : in bit_vector(7 downto 0);

C : out bit_vector (3 downto 0));

end entity Example_beh;

architecture Example_beh_arch of Example_beh is

...

end Example_arch;

entity Examle_struct is

...

end entity Example_struct;

architecture Example_struct_arch of Example_struct is

signal Vec : bit_vector(7 downto 0);

...

begin

U1: entity work.Example_beh(Example_beh_arch)

port map(

A => 20, -- error for VHDL’87 only, in VHDL’93 20 is an expression

B => Vec, -- good example B is the same type as Vec

C => Vec(3 downto 0)); -– good example the same length

...

end architecture Example_struct_arch;

Рисунок:

8.3.1. Прямая Реализация

Ключевые вопросы:

Прямая реализация объекта - самый простой способ определить структурную систему. Единственные вещи, которые необходимы - откомпилированная спецификация компонента, которая будет реализована и инструкция реализации.

Прямая инструкция реализации состоит из:

Обязательной метки для компонентов, которая является необходимой потому что один компонент может быть реализован более одного раза в каждой архитектуре; Ключевое слово entity, сопровождаемое именем библиотеки и объектом, содержащим спецификацию компонента; Имени архитектуры, приложенного в скобках и пункта отображения порта (не обязательно) . После того, как все определяемые пользователем спецификации откомпилированы в библиотеку work - библиотеку с компонентами реализации операторов будем называть так же work.

Имя архитектуре необходимо только тогда, когда имеется несколько архитектур в одиночном объекте. Если спецификация системы, которая использовалась как компонент, включает только одну архитектуру, то имя архитектуры может быть опущено.

Примеры:

Ниже представленный пример показывает прямую реализацию:

Рисунок:

8.3.2. Позиционное Ассоциирование Порта

Ключевые вопросы:



Каждая спецификация отображения порта определяет связи между портами объекта (компонент) и сигналами в архитектуре, где компонент реализован.

Есть два пути отображения порта: позиционное ассоциирование порта и именованная ассоциирование порта.

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

Примеры:

entity D_FF is

port (D,CLK_S : in bit;

Q : out bit := '0';

NQ : out bit := '1' );

end entity D_FF;

architecture A_RS_FF of D_FF is

begin

BIN_P_RS_FF: process(CLK_S)

Begin

if CLK_S = '1' and CLK_S'event

then

Q <= D;

NQ <= not D;

end if;

end process;

end architecture A_RS_FF;

-- a specification of a D

-- flip-flop is given which will be

-- used by the component

-- declaration

entity COUNTER_BIN_N is

generic (N : integer := 4);

port(Q:out bit_vector(0 to N-1);

IN_1 : in bit );

end entity COUNTER_BIN_N;

architecture BEH of COUNTER_BIN_N is

component D_FF

port(D,CLK_S :in bit;

Q,NQ : out bit);

end component D_FF;

signal S : bit_vector(0 to N);

begin

S(0) <= IN_1;

G_1:for I in 0 to N-1

generate

D_Flip_Flop:D_FF port map

(S(I+1),

S(I),

Q(I),

S(I+1));

end generate;

end architecture BEH;

-- the generate statement is used

-- to define a counter of arbitrary

-- length, determined only by its

-- generic parameter

Рисунок:

8.3.3. Именованное Ассоциирование Порта

Ключевые вопросы:

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

Удобное решение этой проблемы – именованное ассоциирование . В этом типе ассоциации, сигналам поставлены в соответствие имена соответствующих портов.


Таким образом, порядок портов безразличен, и вы можете наблюдать прямые отношения между формальными портами, и фактическими сигналами.

Аассоциирование между портами и сигналами представляется символом ' = > '. Обратите внимание, что этот символ не имеет никакого отношения к символу направления информационного потока через порт.

Примеры:

entity ALU is

port(

...

OUT_SIG : out bit;

...);

end entity ALU;

architecture Structural of ALU is

signal X,Y,S,C : bit;

signal Vec : bit_vector(0 to 1)

component HalfAdder is

port (In1, In2 : in bit;

Sum, Carry : out bit);

end component HalfAdder;

begin

HA : HalfAdder port map(Sum=>S,Carry=>C,In1=>X,In2=>Y);

-- good example

HA1 : HalfAdder port map(Carry =>C,In1=>X,Sum=>S,In2=>Y);

-- good example, named port associations can be replaced

HA2 : HalfAdder port map(Sum=>S,Carry=>C,In1=>Vec(0),In2=>Vec(1));

-- good example

HA : HalfAdder port map(Sum=>S,Carry=>C,In1=>Out_SIG,In2=>Y);

-- bad example - Port types or modes do not match in component

-- instantiation

. . .

end architecture Structural;

Рисунок:

8.3.4. Сложные Порты и Сигналы

Ключевые вопросы:

До настоящего времени мы обсудили только одноразрядные сигналы. Однако, сложные сигналы и порты могут также использоваться и для составной инстоляции.

VHDL предоставляет большую гибкость в связывании фактических сигналов с формальными портами сложных типов (массивы или записи). Таким сигналам / портам может быть поставлен в соответствие элемент за элементом или нужный диапазон. Любая комбинация сигналов и портов может происходить так долго пока типы связанных портов, и сигналов совместимы.

Обратите внимание: Все элементы составного порта должны быть связаны с фактическим сигналом.

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

Примеры:

entity DL_e is

port (D,C : in bit

Q : out bit);

end entity DL_e;

architecture DL_a of DL_e is



begin

U1: process (C)

begin

if C='1' then Q<=D;

end if;

end process;

end DL_a;

entity INV_e is

port(X : in bit;

Y : out bit );

end INV_e;

architecture INV_a of INV_e is

begin

Y <= not X;

end INV_a; -- D flip-flop based

-- on two D latch

entity D_FF is

port(D_in : in bit;

CLK : in bit;

Q_out : out bit);

end entity D_FF;

architecture D_FF_a of D_FF is

component DL_e

port (D,C : in bit;

Q : out bit);

end component;

component INV_e

port(X : in bit;

Y : out bit );

end component;

signal q_t, inv_t, inv_t1 : bit;

begin

U1: INV_e port map(CLK,inv_t);

U2: INV_e port map(inv_t,inv_t1);

U3: DL_e port map

(D=>D_in,C=>inv_t,Q=>q_t);

U4: DL_e port map

(D=>q_t,C=>inv_t,Q=>Q_out);

end D_FF_a;

Рисунок:

8.3.5. Порты без Связей

Ключевые вопросы:

Как насчет ситуации, когда некоторые из портов не связаны? Она может быть решена, определением таких портов при отображении порта как open (открытый).

Кроме того, неиспользованный порт может быть опущен в пункте отображение порта. Это совершенно законно в VHDL, но не рекомендуется, потому что нет никакой гарантии, что отсутствующий порт опущен нарочно. Это может случаться даже с опытным VHDL проектировщиком , т.к. один из многих портов может быть просто забыт. Такую ошибку в коде очень сложно найти, поэтому рекомендуется связать состояние (open) со всеми портами в компоненте отображения порта, которые не используются в данном случае.

Примеры:

...

component Open_ent

port(

In1 : in integer;

In2 : in integer :=0;

In3 : in bit_vector; -- unconstrained array

In4 : in bit_vector(3 downto 0):="0000";

In5 : in bit_vector(3 downto 0):="0000"));

end component;

...

U1: Open_ent port map(

In1 => open, -- error, uninitialized IN port

In2 => open, -- OK.

In3 => open, -- error unconstrained array

In4 => open, -- OK.

In5(3) => open, -- error

...

Рисунок:

8.4.1. Введение в Компоненты

Ключевые вопросы:

Если именованный объект может использоваться как компонент тогда, почему мы должны рассматривать другие конструкции для той же самой цели? Достаточно ли реализаций объекта?



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

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

В такой ситуации для структурной спецификации достаточно, иметь декларацию интерфейса компонент (как требует система). Декларация интерфейса компонент называется component declaration(декларация компонент) и она расположена в декларативной части тела архитектуры (или пакета интерфейс).

Примеры:

Этот пример показывает компонент декларации:

-- Component declaration

-- could have been done in architecture body

component My_First is

generic

(const_val : integer := 4;

delay_val : time := 5 ns);-- default value, if not modified

-- generics are optional

port (

In1 : in bit;

In2 : in bit; -- port_name : direction type

Out1 : out integer -- ports are optional

);

end component My_First;

Рисунок:

8.4.2. Компонент Декларация

Ключевые вопросы:

Синтаксис компонент декларации и объекта подобны. Это не совпадение, т.к. компонент и объект играют подобную роль в определении внешних интерфейсов модулей.

Имеется, однако, важное различие между двумя разными конструкциями VHDL:

декларация объекта определяет интерфейс "реального" модуля, то есть системы или схемы, которая физически существует; система - отдельный модуль проекта и может индивидуально моделироваться, анализироваться или синтезироваться; с другой стороны, компонент декларации определяет интерфейс "несуществующего" или "виртуального" модуля; он определен в пределах архитектуры и это скорее ожидание того, что компонент интерфейса должен быть создан раньше, чем описание существующей схемы.

Примеры:

Рисунок:

Перечень Ключевых Слов :

Реализация компонент, Декларация компонент Заметки пользователя:

8.4.3. Компонент Реализация



Ключевые вопросы:

Компонент реализации очень похож на объект реализации. Это подобие имеет следующие главные элементы:

Двоеточие после метки реализации; эта метка обязательна, чтобы идентифицировать внутренность; Необязательная составляющая, ключевое слово, которое указывает на то, что это компонент реализации; должен использоваться для большей ясности кода; Component name (имя компоненты), как определено в компоненте декларации; Предложение Generic map (общая карта), которое обеспечивает фактические значения для общих компонент. Generics может быть определен без значений, которые могут быть обеспечены в пункте общей карты. Если компонент определен без generics, это предложение может быть опущено; Предложение Port map ( карта порта), который определен таким же образом как в случае прямой реализации. Обратите внимание: точки с запятой нет после имени компоненты и пункта общей карты. Все выше названные элементы формируют сигнал реализации инструкции, и точка с запятой появляется после инструкции.

Примеры:

Рисунок:

8.4.4. Конфигурации

Ключевые вопросы:

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

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



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

Примеры:

entity AND_e is

port(X1,X2 : in bit;

Y : out bit );

end AND_e;

architecture AND_a of AND_e is

begin

Y <= X1 and X2;

end AND_a;

entity NAND_e is

port (X1,X2 : in bit;

Y : out bit);

end entity NAND_e;

architecture NAND_a of NAND_e is

begin

Y <= X1 nand X2;

end NAND_a; entity Gates is

port (A,B : in bit;

Y : out bit);

end gates;

architecture GATES_A of Gates is

-- components declarations

signal Y_s1,Y_s2 : bit;

begin

U1: and_e port map(A,B,Y_s1);

U2: nand_e port map(A,B,Y_s2);

U3: and_e port map(Y_s1,Y_s2,Y);

end GATES_A;

configuration gates_c of gates is

for GATES_A

for U1 : and_e

use entity work.AND_e(AND_a);

end for;

for U2 : nand_e

use entity work.NAND_e(NAND_a);

end for;

for U3 : and_e

use entity work.AND_e(AND_a);

end for;

end for;

end configuration gates_c;

Рисунок:

Резюме

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

Компонент может быть как индивидуальной системой, определенной как отдельный объект и архитектура, так и определенной внутренней архитектурой с компонентом декларации. Чтобы использовать компоненты, они должны быть реализованы в структурной спецификации.

Компонент реализации –это основная инструкция в структурной архитектуре и подобно другим инструкциям архитектуры, ее компоненты реализованы параллельно друг другу.

Компонент реализации не полон без карты порта – ссылка фактического названия порта и формального порта.



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

Прямая реализация объекта - самый простой способ определить систему структурным путем. Единственное, что вам необходимо - откомпилированная спецификация компоненты, в которой будут инстолированы операторы реализации.

Карта порта, которая является важной частью реализации компонента, определяет связи между портами объекта (компонент) и сигналами ,заключенными в теле архитектуры (то есть где компонент реализован). Есть две формы отображения порта:

Позиционное ассоцирование порта, при котором сигналы перечислены в том же самом порядке, что и порты которые объявляются в декларации объекта компонента; Именованное ассоциирование порта, при котором сигналы связаны с портами, используя имена порта вместо его расположения в пункте порта; ассоциация представлена символом ' = > '. Обратите внимание на то, что этот символ не имеет никакого отношения к направлению информационного потока через порт. Компонент декларации определяет интерфейс "несуществующего" или "виртуального" модуля; он определен в пределах архитектуры и это скорее ожидание того, что компонент интерфейса должен быть создан быстрее, чем описание существующей схемы. Компонент реализации очень похож на объект реализации. Его главные элементы: метка реализации, необязательный компонент ключевого слова - имя компонента, пункт общей карты (Generic map), который обеспечивает фактические значения для общих компонент, пункт карты порта, который определен так же как и в случае прямой реализации. Декларация компоненты и ее реализации не достаточна для того, чтобы иметь окончательную спецификацию структурной архитектуры, потому что описание реализации компонентов все еще отсутствует. Информация, которая связывает компонент с реальными объектами и архитектурами, определена в конфигурации, которая является отдельным модулем проекта, и она может моделироваться, анализироваться отдельно от других модулей.
Далее>>

Представление Системы в VHDL: Единицы Проекта


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 2

Представление Системы в VHDL: Единицы Проекта

Содержание Главы 2

2.1. Краткий обзор Главы

2.2. Знакомство со Структурой Системы

2.2.1. Как Система Связывается с Окружающей ее средой

2.2.2. Тело Системы

2.2.3. Внешняя Поддержка

2.3. Объект Интерфейса

2.3.1. Главная Единица Проекта: Объект

2.3.2. Из чего состоит Интерфейс ?

2.3.3. Элементы Объекта

2.4. Архитектура Описывает Тело

2.4.1. Без Интерфейса нет Архитектуры

2.4.2. Типы Описания Архитектуры

2.4.3. Функциональное Описание

2.4.4. Структурное Описание

2.4.5. Однн Объект - Сколько Архитекту?

2.5. Пакет Поддерживает Другие Проекты

2.5.1. Концепция Пакета

2.5.2. Использование Пакетов в VHDL

2.5.3. Предопределенные Пакеты

Резюме

2.1. Краткий обзор Главы

VHDL может быть использована как универсальный язык разработок, но его возможности более приспособлены для цифровых систем. Эта глава рассказывает о принципах описания цифровых систем в VHDL.

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

Иногда эти две части могут быть поддержаны дополнительными внешними проектами называемыми пакетами. Для лучшей ясности, эти три основных концепции VHDL объясняются в отдельных секциях:

Объекты (Секция 3) - представляют сущность как основную единицаупроекта , описывают структуру объекта и то, как это облегчает интерфейс между системой и окружающей ее средой; Архитектуры (Секция 4) - представляет архитектуру как вторую ,наиболее важную единицу проекта, которая не может существовать без объекта; объясняются различные стили описания архитектуры (режимный и структурный); Пакеты, которые поддерживают другие единицы проекта, объясняются в Секции 5, который описывает предопределенные пакеты типа Standard, TextIO , Std_logic_1164 и описывает, как использовать их в других единицах проекта.

2.2.1 Как Система Связывается с Окружающей ее средой


Хороший пример такого элементы поддержки - вставная карта,которая ускоряет графические операции в ПК.

В то время как такая добавляющаяся карта может рассматриваться, как часть системы, ради ясности давайте рассматривать это как третий элемент проекта системы и называть это пакетом.

Все три элемента проекта системы (интерфейс, тело и добавляющиеся части) обращаются в VHDL как отдельные проектные единицы и будут рассмотрены в следующих трех секциях.

Примеры:

Позвольте нам оборудовать человека в приложенной иллюстрации компьютером. Разве теперь не будет легче человеку исполнить сложные математические действия? Очевидно да. Это ведет к заключению, что система (человек) может быть оснащена внешней поддержкой (компьютер). Подобную роль в VHDL играют пакеты

Рисунок:

2.3.1. Главная Единица Проекта:Объект

Ключевые вопросы:

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

Без декларации объекта нет никакой спецификации VHDL любой системы. Кроме того, все,что то определено в объекте, автоматически видимо всем другим единицам проекта, связанным с этим объектом.Более того, имя системы - всегда такое же как и имя ее объекта.

Обратите внимание: Всегда начинайте любой проект системы в VHDL с декларации объекта.

.

Примеры:

Каждая система должна иметь одноименный объект проекта, который описывает ее интерфейс со внешним миром. Позвольте нам теперь определять объект проекта для системы по имени Человек:

Рисунок:

2.3.2. Из чего состоит Интерфейс?

Ключевые вопросы:

Часть объекта обеспечивает спецификацию интерфейса системы и обычно включает в себя два элемента:

параметры системы ,как видно со стороны, примерно равны ширине шины процессора или максимальной частоте тактового генератора; связи, которые передают информацию к системе и от нее (системные вводы и выводы).

Примеры:

: Каждый объект включает параметры системы и информационных каналов или связей, которые облегчают контакт со внешним миром.


Позвольте нам определять те два элемента объект а по имени Человек:

Рисунок:

2.3.3. Элементы Объекта

Ключевые вопросы:

Два ключевых элемента любого интерфейса (параметры и связи) имеют их собственные, отдельные декларации в пределах каждого объекта

Все параметры объявлыны как общие и проходят к телу системы; Связи, которые несут данные к системе и от нее, называются портами. Они формируют вторую часть объекта.

Примеры:

Параметры и информационные каналы или связи могут быть определены более формально, используя пункты общие (параметры) и порты (связей)

Рисунок:

2.4.1. Без Интерфейса нет Архитектуры

Ключевые вопросы:

Даже наиболее продвинутоеый электронные устройства, будут бесполезны, если бы мы не могли управлять ими или связываются с ними. Именно поэтому с интерфейсом обращаются как наиболее важной единицей проекта в VHDL.

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

Примеры:

Поведение человеческого тела невозможно определить (архитектура системы Человек) в конкретной ситуации без первого определения ее типичные ответы (объект ) к стимулам Окружающей среды. По этой очень важной причине необходимо определить объект для каждойархитектуры.

Рисунок:

2.4.2. Типы Описания Архитектуры

Ключевые вопросы:

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

Архитектура объекта проекта может быть определена одним из двух способовб, или как описание ее структуры или как описания ее поведения.

По характеру описание структуры системы иерархическое. Это осуществлено, определением объектов проекта (служащие компонентами) и их взаимосвязей

Поведенческое описание, с другой стороны, не содержит никакой информации относительно внутренней структуры системы. Оно описывает только ожидаемое поведение системы.



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

Примеры:

Давайте посмотрим на триггеры D-типа. Его - поведение очень простое: после того, как преобразован вход CLK ,данные от D информационного входа передаются к Q выходу (и к инвертированым не_Q выходам)..

Рисунок:

2.4.3.Функциональное Описание

Ключевые вопросы:

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

И вообще, поведенческая спецификация – это описание выходов ’реакция на входные данные’

Обратите внимание: Этот тип описания не дает никакого ключа к разгадке относительно того, как эти функциональные возможности должны быть выполнены. По этой причине, синтез из поведенческого описания все еще более исследовательская проблема ,чем индустриальная практика.

Примеры:

Мы можем определить электронное устройство, описывая его поведение, то есть внося в список функции, которые устройство, как предполагается, исполняет. Посмотрите ниже на D-триггер (мы пропускаем некоторые детали, но вернемся к ним позже):

Рисунок:

2.4.4.Структурное Описание

Ключевые вопросы:

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

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



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

Примеры:

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

Рисунок:

2.4.5. Один Объект - Сколько Архитектур?

Ключевые вопросы:

Так как различные типы архитектуры могут выполнять одинаковые функции, система (объект) может быть определена различным архитектурами. Например, множество 80xx51процессоров произведенных различными продавцами , пока они имеют тот же интерфейс , можгут использоваться друг в место друга. Это означает, что одному объекту может быть сопоставлено многократное число архитектур..

Обратите внимание: перемена не истинна. Например 8051 не может непосредственно заменять устройство 68HC05 из-за различного интерфейса. Так как архитектура не может иметь различные интерфейсы, она не может быть сопоставлена различным объектам.

Примеры:

Вообще, каждая единица проекта имеет только один интерфейс. Однако,она может иметь несколько альтернативных спецификаций архитектуры. Например, мы можем определять более чем десять различных архитектур для древнего 7400 (с четырьмя двойными входами NAND ворот), указывая различные доступные технологии. В цифровых выходах всея работа такая же, но их внутренняя транзисторная структура различна,онакончается различными архитектурами на

кремниевом уровне::

Рисунок:

2.5.1. Концепция Пакета

Ключевые вопросы:

Что вы делаете, когда стоите перед неизвестной концепцией или словом подобно " subclavian "? Наиболее вероятное- вы обратились бы за помощью, или к другому человеку, или посмотрели бы словарь.

Если Вы собираетесь использовать словарь, вы могли бы сказать , что вы собираетесь использовать единицу библиотеки (то есть книгу). Кроме того, если вы живете далеко от любой библиотеки, книга может быть поставлена Вам почтой как пакет.


Используйте эти пакеты (внешние источники описания) когда что-нибудь неопределено в стандартном языке.

Примеры:

Обратите внимание, что пакет обеспечивает типичные или нетипичные способности, позволяя решать более сложные задачи. Аналогом является случай, когда кто-то болен или хочет улучшить свои физические способности, он / она может брать больничный или витамины. Те дополнительные "пакеты" служат для того, чтобы восстановить здоровье или улучшать его или ее состсяние:

Рисунок:

2.5.2 Использование Пакетов в VHDL

Ключевые вопросы:

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

Пакеты определены в двух частях:

декларация пакета, которая определяет интерфейс пакета; тело пакета, которое определяет тела подпрограмм и веса косвенных констант которые были объявлены в интерфейсе пакета. Обратите внимание: Не все пакеты будут иметь тело пакета. В частности тело пакета не ненужно если нет подпрограмм или косвенных констант , определеных в декларации пакета.

Обратите внимание: Пункты, объявленные в теле пакета не могут быть видимыми вне этого тела. Единственное ограничение в использовании пакетов –это то, что они должны быть объявлены заранее, обычно в начале объекта. Имеются два пункта, которые выполняют эту цель: библиотека и использование. Их использование объясняется в примере справа..

Примеры:

Предоженный пример представляет общую структуру пакета и иллюстрирует его е(применение) в других единицах проекта (примим, что пакет сохранен в рабочей библиотеки работе, которая является истинной для типичных компиляций)::

Рисунок:

2.5.3. Предопределенные Пакеты

Ключевые вопросы:

VHDL - здравая окружающая среда проекта, которая имеет несколько хорошо определенных пакетов. Наиболее популярные пакеты, определенные IEEE:

STANDARD - содержит все основные декларации, и определения конструкций языка и включена во все VHDL спецификации; TEXTIO - содержит декларации основных операций над текстом; STD_LOGIC_1164 - этот пакет - не часть VHDL стандарта, а - его собственный стандарт; он содержит наиболее часто используемые расширения языка. Кроме вышеупомянутых внесенных в список IEEE пакетов, каждый продавец VHDL-ИНСТРУМЕНТА добавляет (и поощряет использовать) его собственных пакетов.


В таких случаях, библиотека обычно носит имя продавца.

Примеры:

Std_logic_1164 Пакет содержит определения типов, подтипов и функций, которые расширяют VHDL стандарт во много-значную логику. Пакет содержит следующие декларации: тип std_ulogic: нерешенный логический тип 9 значный:

тип std_ulogic: нерешенный логический тип 9 значный тип std_ulogic_vector: вектор std_ulogic; функция resolved решение std_ulogic_vector в std_ulogic; подтип std_logic как решенная версии std_ulogic; тип std_logic_vector: вектор std_logic; подтипы X01, X01Z, UX01, UX01Z: подтипы решенного std_ulogic, содержащего значения, внесенные в спискахимен подтипов (то есть. UX01 содержит значения 'U', 'X', '0', и '1', и т.д.); логические функции для std_logic, std_ulogic, std_logic_vector и std_ulogic_vector; конверсионные функции между std_ulogic и частицей, std_ulogic и bit_vector, std_logic_vector и bit_vector и наоборот;

функции rising_edge и falling_edge для обнаружения конца сигналов. .

Рисунок:

Резюме

1. Каждая система должна связаться с ее окружающей средой (она должна получить некоторые данные входа от ее окружающей среды и выводить некоторые данные выхода)

2. Часть коммуникаций спецификации системы называется интерфейсом. Интерфейс между системой и ее окружающей средой описан в VHDL объектом, который является основной единицей проекта для любой системы.

3. Невозможно описать систему в VHDL без объекта.

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

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



6. Архитектура - описание внутреннего действия системы, и это должна быть поставлена в соответствие объекту.

7. Архитектура может быть связана только с одним объектом, но объект может быть связан со множеством архитектур.

8. Имеются два типа описания архитектуры:

Функциональное описание, которое определяет то, что система, как предпологается, будет делать. Вообще, поведенческая спецификация - описание выходных ’ ответов на входные’ изменения; Структурное описание, которое определяет то, какие компоненты должны быть использованы и как они должны быть связаны, чтобы достичь ожидаемых результатов. Другими словами, оно описывает внутреннюю структуру системы. 9. Если Вы нуждаетесь в чем-то, что не определено в стандарте библиотеки VHDL, используйте пакеты, которые поддерживаются VHDL элементами (внешние источники описания). Пакет - единица, которая группирует различные декларации, которые могут быть разделены между несколькими проектами. Пакеты сохранены в библиотеках для большего удобства.

10. Пакеты определены в двух частях: декларация пакета, которая определяет интерфейс к пакету и телу пакета которое определяет тело подпрограмм и значцений косвенных констант, объявленных в интерфейсе пакета.

11. Не все пакеты будут иметь тело пакета. В частности тело пакета не нужно если нет подпрограммы или косвенных констант , определеных в декларации пакета.

12. Пункты, объявленные в декларации пакета ,видимы в других единицах проекта только если используется пункт применения.

13. Пункты, объявленные в теле пакета не могут быть видимыми внешней части тела пакета

Далее>>

Проектирование с использованием Булевых уравнений


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 1

Действительно ли нам нужен VHDL?

Содержание 1 главы

1.1. Краткий обзор 1 главы

1.2. Мир перед появлением VHDL

1.2.1. Проектирование с использованием Булевых уравнений

1.2.2. Схемное проектирование

1.2.3. Недостатки традиционных методов

1.2.4. Языки описания оборудования

1.2.5. Работаем с различными уровнями описаний

1.3. Наиболее универсальное решение: VHDL

1.3.1. Что действительно нужно проектировщику?

1.3.2. Что это такое "VHDL"?

1.3.3. Попытки стандартизации

1.3.4. Что Вы получите за Ваши деньги?

Итоги

1.1. Краткий обзор главы

Добро пожаловать в EVITA

Спасибо Вам за выбор EVITA как инструмента по изучению VHDL . Мы, а именно команда разработчиков EVITA , сделали все возможное, чтобы обеспечить Вас хорошим VHDL-руководством. Оно технически точено и интересено.VHDL не так труден для изучения, как это может казаться. При работе с EVITA, Вы обнаружите, что изучение VHDL может быть даже забавным.

Прежде всего Вы должены ответить на один важный вопрос: Почему мы должны изучить VHDL? Эта глава поможет Вам найти ответ самостоятельно.

Секция 2 рассматривает два традиционных метода проектирования: документированное логическое проектирование с Булевыми уравнениями и более продвинутое, схемно-основанное автоматизированное проектирование. Оба метода используются и сегодня, но они имеют некоторые основные недостатки. Некоторые из этих недостатков решены Языками Описания Оборудования (HDLS).

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

Секция 3 посвящена VHDL как на ведущуму Языку Описания Оборудования 90-ых годов.
Она начинается с короткой истории развития. VHDL имеет много преимуществ, которые будут высвечены через Обучающую программу(Tutorial). VHDL также не лишен некоторых недостатков. Они будут внесены в список здесь, чтобы дать Вам точное представление о силах и слабостях этой новой методологии проектирования.

1.2.1. Проектирование с использованием Булевых уравнений

Ключевые вопросы:

Было бы трудно проектировать любую цифровую систему без понимания таких базовых конструктивных блоков как схемы и триггеры. Большинство логическх цепей, основанных на схемах и триггерах были традиционно разработаны с Булевыми уравнениями. Много методов было развито, чтобы оптимизировать эту методику, включая минимизацию уравнений для более эффективного использования схем и триггеров.

Булев метод проектирования требует написания одного уравнения для каждого входа триггера и блоков схемы. Это делает Булевы уравнения непрактичными для больших проектов, содержащих сотни триггеров, так как это может привести к даже большему числу логических уравнений.

Теоретически, любая система может быть представлена Булевыми уравнениями. Однако, было бы непрактично иметь дело с тысячами логических уравнений, которые могут требовать сегодняшние проекты.

Примеры:

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

Для Булевого уравнения, описывающего Y-выход:

Y = (А и не (B) и не (C)) или (не (A) и B и C) или (А и B и C),

Схемное решение может выглядеть следующим образом:

Рисунок:

1.2.2. Схемное проектирование

Ключевые вопросы:

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



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

На протяжении многих лет, схемные решения считались оптимальным выбором для представления проекта. Теперь новые устройства сделали их слишком ограниченными и длительными в их традиционной форме для представления проекта.

Примеры:

Элементы каталога используются в схемном проектировании. Такие элементы описаны в библиотеках. Вот пример схемного решения с отдельными дискретными компонентами:

Рисунок:

1.2.3. Недостатки традиционных методов

Ключевые вопросы:

Традиционное Булево уравнение и схемные решение проекта, несмотря на их легкость в использовании, имеют некоторые недостатки. Наиболее важный из них это то, что система всегда определяется как сеть связанных элементов. И это не как спецификация системы созданная и используемая Вами.

Спецификация системы всегда подается в форме ожидаемого поведения системы, (то есть что должна система делать в том или ином случае).

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

Примеры:

Рисунок ниже показывает шаги проектирования логической цепи, которая должна считать число входов с логической '1':

Рисунок:

1.2.4.Языки описания оборудования

Ключевые вопросы:

Главный недостаток традиционных методов проектирования - ручной перенос описания проекта в набор логических уравнений. Этот шаг может быть полностью устранен языками описания оборудования (HDLS). Например, большинство HDL инструментальных средств допускают использование конечных автоматов для последовательных систем и таблиц истинности для комбинаторных блоков.


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

Языки описания оборудования находят свое основное применение в программируемых логических матрицах (PLDS) различной сложности, из простого PLDS до сложных CPLDS и FPGAS .Отдельные HDL языки используются сейчас . Наиболее популярные из них - VHDL, Verilog и Abel.

Примеры:

Комбинаторная цепь из предыдущей страницы может быть также определена в HDL. Ниже показаны два описания: Palasm и Cupl. Эти языки подобны, и они используються в основном для проектов основанных на PLD.

; Specification in PALASM

CHIP Example1 PAL16P8

;Pins 1 2 3 4 5 6 7 8 9 10

X0 X1 X2 NC NC NC NC NC NC GND

;Pins 11 12 13 14 15 16 17 18 19 20

NC Y0 Y1 NC NC NC NC NC NC VCC

EQUATIONS

Y0 = X0 :+: X1 :+: X2

Y1 = X2*X1 + X2*X0 + X1*X0

/* Specification in CUPL, Target Device: P16P8 */

/* Inputs: */

Pin 1 = X0;

Pin 2 = X1;

Pin 3 = X2;

/* Outputs: */

Pin 12 = Y0;

Pin 13 = Y1;

/* Logic Equations: */

Y0 = X0 $ X1 $ X2;

Y1 = X2&X1 # X2&X0 # X1&X0;

Рисунок:

1.2.5. Работаем с различными уровнями описаний

Ключевые вопросы:

Так как цепи становятся все более сложными, то имеет смысл проводить два одновременных процесса :

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

.

Примеры:

Эта иллюстрация представляет различные уровни описания (абстракции):

Рисунок:

1.3.1 Что действительно нужно проектировщику?



Ключевые вопросы:

Методы проектирования, рассмотренные на предыдущей странице оказались совершенно неполными. Большинство из них играет незначительную роль во всем процессе проектирования. Чтобы завершить проект, Вам нужно будет перейти от одного описания проекта к другому или от одного средства к другому, поднимая проблему совместимости средств проектирования и изучая новые среды проектирования.

Эти проблемы могут быть решены универсальным методом описания, покрывающим все уровни проектирования и типы. VHDL - это такой метод проектирования, который может обрабатывать различные уровни разработки. Он может также стандартизировать передачу данных между всеми фазами проекта и упрощать документацию.

Имеются несколько инструментальных средств для начала проекта VHDL и его проверки. Active - VHDL из ALDEC - интегрированная среда проектирования на VHDL, которая требует немного времени, чтобы научиться ею пользоваться.

Примеры:

Рисунок:

1.3.2. Что это такое "VHDL"?

Ключевые вопросы:

Термин "VHDL" уже использовался несколько раз, так что пришло время объяснить его происхождение.

VHDL - акроним: 'V' обозначает Очень Высокоскоростную Интегральную схему, и "HDL" означает Аппаратный Язык Описаний. Это сложное имя было создано U.S.Department of Defence , который был первым учреждением, понимавшим выгоды языка проектирования базирующегося на документации, моделировании и разработке электронных устройств. При их субсидировании VHDL был разработан и представлен для проектирования.

VHDL приложения появлялись в начале 90-ых годов. Поскольку они стали доступными на PC в 1994, PLD, и FPGA проектировщики начали использовать их на больших проектах.

Обратите внимание: слово "синтез" не было упомянуто как одна из причин для создания VHDL языка. Действительно, VHDL был прежде всего предназначен для целей разработки,моделирования и документации. Синтез был добавлен некоторыми из изобретателей, которые видели его как способ автоматизировать процесс проектирования.



Примеры:

Рисунок:

1.3.3. Попытки стандартизации

Ключевые вопросы:

Несмотря на тот факт, что VHDL был первоначально тесно связан с американским департаментом по обороне, он скоро нашел дорогу к не-военным проектам. Фактически, это было великое достижение разработчиков, чтобы сделать VHDL широко доступным, стандартизируя его распространением через IEEE - Институтом Электрической и Электронной Отраслей, наиболее влиятельной и профессиональной организацией в этой отрасли. Первый VHDL Стандарт появился в 1987 как СТД 1076 и с тех пор, следуя законам IEEE, он был изменен в 1993. Следующее изменение стандарта языка запланировано в 1998 (все стандарты IEEE должны пересмотриваться каждые пять лет).

Отвечая на потребности проектировщиков, различные экспертные группы приложили много усилий к созданию более универсального языка. Их работы привели к нескольким стандартам, которые поддерживают основной 1076 IEEE VHDL стандарт. Список на права отображает законченные и продолжающиеся VHDL попытки стандартизации.

Примеры:

Рисунок:



1.3.4. Что Вы получите за Ваши деньги?

Ключевые вопросы:

Имеется некоторые факторы, которые делают VHDL привлекательным для рассмотрения большинством проектировщиков:

Это - наиболее популярный HDL язык во всем мире; Системы могут быть определены структурными и/или поведенческими способами на различных уровнях; Хорошие VHDL-основанные инструментальные средства моделирования, доступные за приемлемые цены; Синтез на VHDL предлагается многими EDA продавцами инструментальных средств; VHDL не ограничен электроникой.

Примеры:

Рисунок:

Резюме

1. Традиционно, цифровые цепи, основанные на схемах и триггерах были разработаны с Булевыми уравнениями. Эта методика требует записи одного уравнения для каждого информационного входа каждого триггера, и в некоторых случаях, одно уравнение может представлять много схем. Это делает Булевы уравнения непрактичными для больших проектов, содержащих множество или большое количество триггеров.

2. Некоторые схематически - основанные проекты составлены не только из схем и триггеров но также и из некоторых схем и дискретных устройств.


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

3. Кто - то мог бы заключить,что,использование машинных схематических инструментальных средств проектирования - все, что необходимо для выполнения эффективных проектов. Однако, проектировщики отметили, что схематические проекты с более чем шестью тысячами схем становятся непостижимыми.

4. Главные недостатки традиционных методов проектирования -ручная трансляция описания проекта к логическим уравнениям, что значительно упрощается аппаратными языками описаний (HDLS). С HDL Вы можете начинать спецификацию проекта без того, чтобы иметь любые Булевы уравнения.

5. Имеются несколько уровней спецификаций системы, от кремниевых до полных, сложных систем. Каждый из этих уровней может быть проанализирован в терминах структуры и поведения. Наиболее новые инструментальные средства автоматизации проектирования, представленные ранее были прежде всего приспособлены к наиболее детализированному уровню (кремнивые), и они не охватывают весь спектр уровней проекта, которые требуются.

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

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

8. VHDL - это большой скачек вперед к такому языку описаний. Имеются несколько инструментальных средств, доступные для синтеза из VHDL спецификаций системы, и Active-CAD - одни из них.

9. VHDL - акроним: 'V' замещает Очень Высокоскоростную Интегральную схему, и "HDL" - Аппаратный Язык Описаний.

10. VHDL был стандартизирован. Первый VHDL Стандарт появился в 1987 как Std 1076, и он был пересмотрен в 1993. Следующее изменение стандарта языка было запланировано в течение 1998 (весь стандарт IEEE должен пересматриваться каждые пять лет).

11. Имеются и другие факторы, которые делают VHDL привлекательным:

Это - наиболее популярный международный HDL; Системы могут быть определены структурным или поведенческим способом и в различных уровнях детализации; Хорошие VHDL-основанные инструментальные средства моделирования доступны за приемлемые цены; Синтез на VHDL предлагается многими EDA продавцами инструментальных средств; Это не ограничено электроникой.
Далее>>

Спецификация Интерфейса Системы


Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

Глава 4

Спецификация Интерфейса Системы

Содержание Главы 4

4.1. Краткий обзор Главы

4.2. Заголовок Объекта

4.2.1. Имя Объекта

4.2.2. Комментарии в VHDL

4.2.3. Описание Системы

4.2.4. . Завершение Объекта

4.3. Предложение порта

4.3.1. Значение Порта

4.3.2. Режим Порта

4.3.3. Документирование Порта

4.4. Предложение Generic

4.4.1. Что такое Generic?

4.4.2. Спецификация Generics

4.4.3. Применение Generics

Резюме

4.1. Краткий обзор Главы

Объекты уже были упомянуты ранее. Эта глава опишет их более подробно.

Вначале, в секции 2, так называемый заголовок Объекта будет представлен. Этот заголовок Объекта не только определяет сущность, но также используется для описания действия системы. Такой комментарий не обязателен, но помогает понять цель проекта. Секция обеспечит некоторые подсказки для написания хорошего описания системы.

Секция 3 описывает декларацию порта системы. Mode Сигнала будут описаны более детально, и некоторые примеры будут рассмотрены.

В заключение, в Секции 4 будет представлена подробная информация относительно generics:, какие они, какой целе они служат и как они должны быть определены.

4.2.1. Имя Объекта

Ключевые вопросы:

Имя Объекта, формально названное идентификатором, служит прежде всего для целей документации. Из-за этого, рекомендуется составить название слов Объекта, которые лучше всего описывают то, что делает система. Так как язык VHDL регистро нечувствительный , идентификатор предпочтительно должен быть написан, используя смешанные литеры, например. FastBinary_Cntr.

Каждый идентификатор VHDL, включая имя Объекта, должен быть написан по этим правилам:

Он должен вмещаться в одну строку; Он должен начаться с буквы; Он может быть составлен только из букв, чисел и знаков подчеркивания;

Он не может иметь знаков подчеркивания в начале, или конец или два подчеркивает рядом;


Никакие пробелы не допускаются внутри идентификатора; Литеры верхнего и нижнего регистра не различаются; Зарезервированные слова не могут использоваться как идентификаторы. Так называемые расширенные идентификаторы (которые могут содержать зарезервированные слова и специальные знаки) допускаются, но не рекомендуются. См. Детальное Руководство по применению .

Примеры:

Два различных имени для Объекта простого комбинаторного устройства (мультиплексор 2 на 1) предложены. Оба из них правильны.



Entity Mux_2_to_1 is Entity Mux2to1 is

... ...

End Entity Mux_2_to_1; End Entity Mux2to1;

Entity identifier is

End Entity Entity_simple_name;

Рисунок:

4.2.2. Комментарии в VHDL

Ключевые вопросы:

Не существует хорошего проекта без сопутствующей документации. Хорошая документация это не только большое количество страниц описания, но также и комментарии внутри спецификации. Это верно для всех языков программирования и языков аппаратного описания (включая VHDL).

Комментарии в VHDL начинаются с двух дефисов (--) и заканчиваются в конце строки. Они фактически могут быть расположены где-нибудь, но не могут начинаться в середине идентификатора или зарезервированного слова (если не было бы в этом случае какого либо смысла).

Примеры:

Имеется один хороший и один плохой пример размещения комментариев в Объекта из предыдущей страницы:

-- 2-line to 1-line data multiplexer - good comment example

entity Mux_2_to_1 is

port (I0, I1, Sel : in bit;

Y : out bit);

end entity Mux_2_to_1;

entity –- bad comment example Mux_2_to_1 is

port (I0, I1, Sel : in bit;

Y : out bit);

end entity Mux_2_to_1;

Рисунок:

4.2.3. Описание Системы

Ключевые вопросы:

Документирование Проекта была одна из главных причин для развития VHDL. Это отражено в богатстве языковых конструкций и в общепринятой системе описаний в начале каждого файла VHDL.

Язык непосредственно не требует такого описания, написанного в форме комментария. Однако, это широко принятая практика, что хорошая спецификация VHDL должна быть задокументирована.



Не имеется никакого "стандартного" способа написания описания системы, но отдельные элементы необходимы и могут быть найдены в большинстве проектов. Для написания профессиональной и полной документации документируйте каждый файл VHDL подобно примеру справа.

Примеры:

С практической точки зрения описание функциональных возможностей системы (данные как комментарий) очень полезены. В нашем случае (мультиплексор), эти функции можно давать как таблица истинности:

-------------------------------------------------------

-- Truth Table of 2-line to 1-line data multiplexer --

-------------------------------------------------------

--| SEL | I0 | I1 || Y |

--|------------------------------|

--| 0 | 0 | 0 || 0 |

--| 0 | 0 | 1 || 0 |

--| 0 | 1 | 0 || 1 |

--| 0 | 1 | 1 || 1 |

--| 1 | 0 | 0 || 0 |

--| 1 | 0 | 1 || 1 |

--| 1 | 1 | 0 || 0 |

--| 1 | 1 | 1 || 1 |

--|------------------------------|

--

entity Mux_2_to_1 is

port (I0, I1, Sel : in bit;

Y : out bit);

end entity Mux_2_to_1;

Рисунок:

4.2.4. Завершение Объекта

Ключевые вопросы:

Последний элемент шаблона Объекта – его завершение.

Сущность заканчивается оператором end. Это то, как большинство VHDL конструкций заканчиваются. Чтобы улучшить удобочитаемость, рекомендуем использовать любой (или оба) необязательных поля, которые могут следовать после end : ключевое слово entity и/или имя Объекта.

Примеры:

-- Сначала хороший пример декларации Объекта

Entity Mux_2_to_1 is

End Entity Mux_2_to_1;

-- Второй хороший пример декларации Объекта

Entity Mux_2_to_1 is

End Mux_2_to_1;

-- Сначала плохой пример декларации Объекта

Entity Mux_2_to_1 is

End Entity Mux2to1;

-- Второй плохой пример декларации Объекта

Entity Mux_2_to_1 is

EndMux2_to_1;

Рисунок:

4.3.1. Значение Порта

Ключевые вопросы:

Концепция порта уже была упомянута ранее и пришло время обсудить ее более подробно.

Стандартное описание Языка VHDL определяет порты как " каналы для динамической связи между блоком [то есть сущностью] и окружающей средой ".


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

Каждый порт определяется своим предложением порта(port clause), которое состоит из следующих элементов:

Необязательное ключевое слово signal; Имя порта записанное в колонку; Mode порта; Тип порта; Факультативно; начальное значение, которому предшествует: = символ; Факультативно; комментарий, описывающий порт (строго рекомендуемый).

Примеры:

-- Сначала хороший пример декларации порта для 2- двоичных разряднов

--- Полный адрес:

entity Full_Adder is

port (A0, A1, B0, B1, Cin : in bit;

S0, S1, Cout : out bit);

end entity Full_Adder;

-- Второй хороший пример декларации порта для 2- двоичных разряднов

-- Полный адрес:

entity Full_Adder is

port (A, B : in bit_vector (1 downto 0);

Cin : in bit;

S : out bit_vector (1 downto 0);

Cout : out bit);

end entity Full_Adder;

-- Плохой пример декларации порта для 2- двоичных разряднов

-- Полный адрес:

entity Full_Adder is

port (A, B : in bit_vector (1 downto 0);

Cin : in bit := 'Z'; -- Bad static_expression

-- Assignment target incompatible

-- with right side

S : out bit_vector (1 downto 0);

Cout : out bit);

end entity Full_Adder;

Рисунок:

4.3.2. Режим Порта

Ключевые вопросы:

Порты могут играть разное назначения: некоторые могут получать входные данные, некоторые могут посылать выходные результаты, а другие могут делать обе функции. Направление потока данных через порт определено mode порта.

Имеются пять доступные способов:

in: Порт только получает данные; при этом он может читать такой сигнал, но записывать ему запрещено; out: Порт только посылает данные; при этом он может записать такой сигнал, но читать ему запрещено; inout: Порт реверсивен; он допускает как чтение так и запись сигнала; buffer: Подобный inout, но он ограничен, так как записать можно только в него; linkage: Также реверсивный порт, но с очень ограниченными правилами чтения и записи; фактически почти никогда не используется в проектах. Только первые три mode могут использоваться для синтеза.

Примеры:



При объявлении порта Вы должны определить mode. Декларация порта для полного сумматора может выглядеть следующим образом:



entity Full_Adder is

port (A, B : in bit;

Cin : bit;

S : out bit;

Cout : out bit);

end entity Full_Adder;

Рисунок:

4.3.3. Документирование Порта

Ключевые вопросы:

Документировать должным образом порт столь же важно, как и хорошее описание Объекта, которое было обсуждено ранее. Хорошо - описанный порт должен иметь очевидное имя, которое обеспечивает указание на его функции. Кроме того, комментарий в конце строки должен обеспечить некоторую дополнительную информацию относительно этого сигнала.

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

Примеры:

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



entity Full_Adder is

port (A, B : in bit_vector (1 downto 0); -- Первый и второй операнд

Cin : in bit; -- Вход переноса

S : out bit_vector (1 downto 0);-- Результат действия

Cout : out bit); -- Выход переноса

end entity Full_Adder;

entity Mux_2_to_1 is

port (I0 : in bit; -- input data

I1 : in bit; -- input data

Sel : in bit; -- address select

Y : out bit);-- output data

end entity Mux_2_to_1;

Рисунок:

4.4.1. Что такое Generic?

Ключевые вопросы:

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

Это определение означает, что декларация generics должна разместиться внутри Объекта системы, которая поддерживает связь между системой и окружающей средой.


Generics используется, чтобы описать постоянные значение. Например, они могут управлять размером модели, в частности шириной шин и размером таких параметеризированных (parameterized) блоков как n-битные адресные схемы или n-битные компараторы. Они могут также использоваться для выбора временных параметров, служа для зацикливания счетчика, и т.д.

Примеры:

Ниже приведенные примеры, показывают как использовать класс generic. Главная цель состоит в том, чтобы определить характерные (формальные) параметры данной единицы проекта:

entity Mux2to1 is

-- The generic constant tp is used to specify the timing

-- parameters of the entity

generic ( tp : time := 10 ns);

port (I0, I1, SEL : in bit;

Y : out bit);

end entity Mux2to1;

entity ROM is

-- The generic constants Width and Depth are used

-- to specify the number of data bits and address bits

-- for the read only memory

generic (Width : integer := 8;

Depth : integer := 15);

port (Addr_ROM : in bit_vector (Depth -1 downto 0);

CS_ROM : in bit;

Data_ROM : out bit_vector (Width -1 downto 0));

end entity ROM;

Рисунок:

4.4.2. Спецификация Generics

Ключевые вопросы:

Generics определяются в Объектах (entitis) внутри класса generic, который располагается перед портами. Класс generic состоит из ключевого слова generic и списка generic, помещенного в круглые скобки. Подобно портам, объекты generic в списке generic отделяются точками с запятой.

Каждая декларация generic состоит из следующих элементов:

Имя generic записанное в колонку; Тип generic; Необязательные параметры: значение generic, которому предшествует символ :=. Если значение не определено, и система используется как компонент на более высших уровня спецификации данных, значение должна быть поддержана через составляющие реализации (component instantiation); подробнее см. Главу 8; Необязательный параметр комментарий, описывает generic.

Примеры:

-- Сначала хороший пример декларации generic:

entity D_FF is

generic (tp : time := 15 ns; -- propagation time



ts : time := 10 ns; -- setup time

th : time := 5 ns); -- hold time

port (D, Clk : in bit;

Q : out bit);

end entity D_FF;

- Второй хороший пример декларации generic:

entity Full_Adder is

generic (InDataWidth : positive := 8);

port (A, B : in bit_vector (InDataWidth-1 downto 0);

Cin : in bit;

S : out bit_vector (InDataWidth-1 downto 0);

Cout : out bit);

end entity Full_Adder;

Рисунок:

4.4.3. Применение Generics

Ключевые вопросы:

Generics может использоваться где-нибудь в коде, где необходимы статические (то есть не изменяющий вовремени) значения. Фактически, строго рекомендуется использовать generics и константы вместо кодов написанных в самом тексте, потому это облегчает простые изменения в проекте. Параметры, которые обычно определены как generics следующие:

Размер комплексных объектов типа массивов или шин; так если generic используется для определения ширины шины, Вы можете изменять размер шины, изменяя generics предложение в начале спецификации. Используйте generics, для зацикливания счетчика и в подобных приложениях; Выбор временных параметров: задержки, установки времени, времени переключения и любого параметра выбора времени, который используется в описании электронных элементов. Например, чтобы заменить медленный элемент на более быстрый (без того, чтобы изменять функциональные возможности) требуется только измененить значения generics, которые описывают временные параметры элемента. Если параметры выбора времени были бы жестко закодированы, каждая строка кода была бы должна быть проверена и изменена так, чтобы она содержала требуемую величину для выбранного времени.

Примеры:

Следующие два примера поясняют применение generics, для параметрического (parametrizable) декларирования устройства:

entity Full_Adder_with_varying_structure is

generic (InDataWidth : positive);

port (A, B : in bit_vector (InDataWidth-1 downto 0);

Cin : in bit;

S : out bit_vector (InDataWidth-1 downto 0);

Cout : out bit);

end entity Full_Adder_with_varying_structure;



entity RAM_with_varying_structure is

generic (Width : positive;

Depth : positive);

port (Addr_RAM : in bit_vector (Depth -1 downto 0);

CS_RAM : in bit;

Data_RAM : out bit_vector (Width -1 downto 0));

end entity RAM_with_varying_structure;

Рисунок:

Резюме

Имя Объекта, формально названное идентификатором, служит больше всего для целей документирования. В VHDL каждый идентификатор, включая имя Объекта, должен создаваться за следующими правилами: он должен состоять из одной строки, он должен начинаться с буквы, он может включать в себя буквы, числа и знаки подчеркивания за исключением подчеркивания в начале, конце или два подчеркивания подряд. Никакие пробелы внутри идентификатора не допускаются; буквы верхнего и нижнего регистра не различаются, никакие зарезервированные слова не могут использоваться как идентификаторы. Комментарии в VHDL начинаются с двух дефисов (--) и заканчиваются в конце строки. Они могут быть расположены фактически где-нибудь, но не могут начинаться в середине идентификатора или зарезервированного слова. Одна из главных причин для развития VHDL была необходимость в документировании проектов. Это отражено в богатстве конструкций языка, и в общепринятой системе описаний используемой в начале каждого файла VHDL . Наличие документация - второй наиболее важный элемент хорошего проекта. Сущность может быть закончена простым оператором end. Много VHDL конструкций, заканчиваются этотим способ. Чтобы улучшить удобочитаемость, рекомендуется использовать одно (или оба) необязательных поля, которые могут следовать за end : ключевое слово entity или имя Объекта. Каждый порт определяется внутри класса порт и состоит из следующих элементов: необязательного ключевого слово signal, имени порта расположенного в колонку, mode порта, тип порта и необязательного параметра начальное значение, которому предшествует символ: =, а также рекомендуется комментарий, описывающий порт. Направление потока данных через порт определяется mode порта. Имеются три mode, которые могут использоваться для синтеза: in - порт получает данные, только извне и поэтому можно только читать сигналы, но записывать запрещено.


Порт out - только посылает данные, и поэтому допускает только записывать сигналы, но чтение запрещено. Порт inout реверсивен; он допускает как считывание так и запись сигналов. Документирование портов комментариями в конце строки наиболее важно для технических систем, потому что имена должны соответствовать внешним запросам, т.е. существующим элементам,которые описанный в VHDL. Generics обеспечивают постоянные значения для параметров системы, которые находятся в наружной части. Они могут служить тем же самым целям что и постоянные значения: они управляют размером модели, учитывают временные параметры и т.д. Generics определеные в Объектах, находятся внутри класса generic, они расположены справа перед портами, и состоят из ключевого слова generic и списка generics в закрытых круглых скобках. Каждая декларация generic состоит из следующих элементов: имени generic расположенного в колонку; тип generic ; значение generic, которому предшествует символом :=; и необязательного комментария, который описывает generic . Generics может использоваться где-нибудь внутри кода, где используются статические (то есть не изменяющий) вовремени) значения.
Далее>>