for i in 5 downto 0 loop Sum(i) := S * i;

end loop;

S count: while i <= N loop SumT := SumT+i;

i := i +1; end loop S_count;

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

case Par is

when 'Г => out := 1; when 'O' => out := 0; when 'Z' => out := 3;

end case;

Оператор wait применяется для приостановки процесса на опреде­

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

В это время будет произведено вычисление условия, расположенного после until. Условие - выражение типа boolean. Если получается истинное значение, то выполнение процесса возобновляется.

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

Оператор wait может применяться как со всеми тремя дополнитель­ ными условиями, так и с любыми их сочетаниями. При этом условия, про­ веряемые с помощью on, until и for, проверяются последовательно. Напри­ мер:

WAIT on X, Y until (Z=0) for 100ns; WAIT on X, Y until (Z=0);

WAIT on X, Y; WAIT for 100ns;

2.1.6.Пакеты

Вязыке VHDL предусмотрен механизм пакетов для часто исполь­ зуемых описаний, констант, типов, сигналов. Эти описания помещаются в объявлении пакета (package declaration). Если пользователь использует не­ стандартные процедуры или функции, их интерфейсы описываются в объ-

явлении пакета, а тела содержатся в теле пакета (package body). Ссылку на описания, содержащиеся в пакете, можно сделать, указав имя пакета, и че­ рез точку ту его часть, которая используется. Для использования всего па­ кета применяют полную ссылку с помощью расширителя .all:

package full_p is —объявление пакета subtype mem is sparse_memory; procedure pow(S: inoutmem);

end fuil_p;

package body full_p is - тело пакета —тело пакета

end full_p;

use full_p.all; --подключаются все описания, введенные в пакете full_p

2.1.7. Процессы

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

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

Предложения внутри процесса называются последовательными предложениями (sequential statements). В отличие от выражений конкрети­ зации компонентов в структурном стиле описания и параллельного назна­ чения в потоковом стиле, выполняемых одновременно, предложения в процессе выполняются одно за другим последовательно. Предложение выполняется только тогда, когда процесс выполнения достигает этого предложения. В языке VHDL существует два варианта операторапроцесса:

Вариант А - это процесс, который активизируется, когда меняет свое значение некоторый сигнал в его списке чувствительности (сигналы X , У, Z). Вариант В не имеет списка сигналов запуска и предполагает, что про­ цесс всегда активен.

После начала моделирования процесс выполняется только один раз, а затем переходит в состояние ожидания (в конце выполнения), пока не изменятся сигналы, которые его перезапустят. При использовании процес­ са варианта А нельзя использовать операторы WAIT, поскольку они всегда выполнялись бы до подразумеваемого оператора WAIT в конце процесса, т.е. был бы потерян смысл процесса варианта А. В то же время процессы варианта В могут иметь любое необходимое число операторов WAIT.

2.2. Виды представления описаний проектов в VHDL

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

При структурном описании (structural description) объекта проекта архитектура представляется в виде иерархии связанных компонентов.

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

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

При потоковом описании (data-flow description) объекта проекта его архитектура представляется в виде множества параллельных регистровых операций, каждая из которых управляется вентильными сигналами. Пото­ ковое описание соответствует стилю описания, используемому в языках регистровых передач.

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

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

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

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

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

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

2.3. Моделирование в VHDL

Одной из основных возможностей языка VHDL является наличие развитых средств моделирования ВС. Генерация тестов и возможность мо­ делирования систем с выявлением и анализом неисправностей обеспечива­ ет выполнение верификации разработок на различных этапах маршрута проектирования.

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

Рассмотрим пример временного моделирования (рис. 2.1). В правой части параллельного или последовательного назначения сигнала имеется одна или более временных диаграмм (waveforms), каждая из которых пред­ ставляется списком элементов временных диаграмм, разделенных запяты­ ми. В каждом из элементов диаграммы определяется значение сигнала и задержка, через которую планируется появление этого значения. На­ пример, сигнал step имеет текущее значение 0; предусмотрено сле­ дующее назначение сигнала:

step <= 1 after 5ns, 2 after 10ns, 1 after 15ns, 0 after 20ns;

Рис. 2.1. Сигнал step как функция времени

Задержки задаются относительно момента, в который выполняется на­ значение.

3. ПРОЕКТИРОВАНИЕ РЭУ НА БИС ПРОГРАММИРУЕМОЙ ЛОГИКИ

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

-процесс проектирования упрощен и автоматизирован, благодаря ис­ пользованию САПР;

-лучше массогабаритные характеристики;

-проще изготовление конечных устройств;

-выше надежность;

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

3.1. Основные этапы проектирования

Процесс проектирование РЭУ на БИС программируемой логики можно разбить на несколько основных этапов, которые рассмотрим в дальнейшем.

3.1.1. Выбор элементной базы и САПР

На первом этапе проектирования на основании анализа технического задания (ТЗ) выявляются специфические требования проекта, позволяю­ щие остановить свой выбор на определенной фирме, выпускающей БИС программируемой логики, и на определенном семействе ПЛИС этой фир­ мы. Отбор осуществляется как на основе анализа характеристик самой БИС - логических, конструктивных, эксплуатационных, стоимостных, так и на основе анализа свойств требуемой или допустимой САПР. Зачастую выбор предопределяется уже имеющимся практическим заделом и опытом работы проектировщика с продукцией и САПР определенной фирмы. В этом случае уточняется семейство, архитектурные и эксплуатационные ха­ рактеристики которого удовлетворяют требованиям ТЗ. Выбор семейства может существенно зависеть от специфических требований проекта, на­ пример, необходимости соответствия определенным интерфейсным стан­ дартам, требования наличия скоростной встроенной памяти значительного объема, повышенной радиационной стойкости и т.д. На выбор могут вли­ ять и такие характеристики, как условия поставок, объявления о разработ­ ке перспективных модификаций семейства и многое другое. Одним из са­ мых неприятных (и дорогостоящих по совокупности последствий) фактов является выяснение в ходе выполнения проекта невозможности его реали­ зации на прс?ДУкЦии выбранной фирмы.

Анализ интерфейсных требований к проекту позволяет конкретизи­ ровать количество внешних контактов, необходимых для реализации про­ екта, т.е. типоразмер корпуса БИС выбранного семейства ПЛИС. Слож­ ность проекта или определенные требования к проекту (например, скоро­ стные характеристики) могут приводить к целесообразности использова­ ния на начальных этапах проектирования группы САПР сторонних фирм.

3.1.2. Спецификация проекта

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

Существенной задачей, решаемой на этом этапе, является уточнение и согласование с заказчиком интерфейсных функций проекта. Уточняется реализация протоколов внешнего обмена. Именно требуемые временные характеристики и правила взаимодействия с внешними приборами опреде­ ляют допустимую организацию и структуру внутренних узлов проекта.

3.1.3. Разработка общей структуры проекта

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

3.1.4. Содержательное описание проекта и его частей

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

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

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

3.1.5. Компиляция проекта

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

При компиляции проекта целиком удается обнаружить большинство скрытых ошибок и нестыковок, которые проявляются при попытке объе­ динить отдельные фрагменты. Реально процесс компиляции состоит из ря­ да последовательно выполняемых действий: сборки базы данных продукта, контроля соединений, логической минимизации проекта, монтирования проекта в заданную или выбранную схему, формирования загрузочного (конфигурационного) файла и т.д. На любом этапе этих работ могут возни­ кать ошибки, требующие повторной компиляции после их коррекции. Только после успешной синтаксической компиляции проекта или его час­ тей можно переходить к их верификации.

3.1.6. Верификация проекта

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

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

Важность этапа верификации приводит к тому, что работы по тести­ рованию стремятся упростить, включая в состав САПР различные про­ граммы, автоматизирующие работы этого этапа. В современных САПР наибольшее распространение получила верификация, базирующаяся на моделировании работы ПЛИС при различных внешних воздействиях. Для упрощения создания желаемой последовательности входных или контро­ лируемых (выходных) сигналов в состав САПР входят редакторы времен­ ных диаграмм. Редакторы делятся на компилирующие и интерпретирую­ щие. Редакторы интерпретирующего типа позволяют упростить процедуру отладки и обнаружить их дефекты, связанные с неправильной трактовкой разработчиком структурной или поведенческой реализации системы либо особенностей реализации используемой элементной базы.

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

Наличие компиляции проекта в САПР полной модели структуры проектируемого устройства и знание временных параметров всех компо­ нентов этой структур позволяет автоматизировать процесс вычисления различных временных характеристик проекта. Например, в САПР MAX+PLUS II предусмотрено автоматическое вычисление трех основных классов временных параметров:

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

-максимально допустимой частоты тактирования элементов памяти, используемых в проекте;

-времен предустановки и удержания сигналов, гарантирующих на­ дежное срабатывание схем при фиксации сигналов в синхронных элементах памяти.

Многие САПР позволяют также выделять критические пути переда­

чи и преобразования информации для схемного или топологического пред­ ставления проекта.

3.1.7. Организация натурных экспериментов

Одним из заключительных этапов проектирования является экспе­ риментальная проверка спроектированного устройства. При всей тщатель­ ности выполнения предыдущих этапов всегда существует далеко не нуле-

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

3.2.Особенности проектирования РЭУ

сиспользованием языка VHDL

Использование VHDL как языка описания устройств при проектиро­ вании радиоэлектроники отлично от традиционных (в частности графиче­ ских) способов и имеет ряд преимуществ и особенностей.

3.2.1. Проектирование

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

Язык VHDL представляет для этих целей развитые средства пове­ денческого стиля описания. Кроме того, стандарт IEEE Standard 1076 VHDL позволяет компиляторам, реализующим VHDL, допускать встраи­ вание описаний различных подпрограмм на языках программирования вы­ сокого уровня (Си, Паскаль и др.) в качестве реализации функций и проце­ дур. В этом стиле удобно разрабатывать описания устройств высокого уровня сложности (ЭВМ, процессоры, контроллеры различных устройств, арбитры шин, сложные последовательностные схемы и т.д.).

Потоковый стиль позволяет описывать более простые устройства, такие как сумматоры, мультиплексоры и т.д.

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

Другой подход основан на непосредственной разработке архитекту­ ры ВС. Подмножество структурного стиля VHDL обеспечивает разработ­ чика средствами описания архитектурной иерархии проекта. Потоковые или поведенческие описания компонентов могут вводиться на любых ие­ рархических уровнях. Это позволяет пользоваться библиотечными набо­ рами готовых логических и архитектурных решений. Преимущества дан­ ного подхода заключаются в возможности тщательной «ручной» оптими­ зации структуры ВС.