Проектирование Систем На Микросхемах Программируемой Логики

Ростислав Грушвицкий
Александр Мурсаев
Евгений Угрюмов
ПРОЕКТИРОВАНИЕ СИСТЕМ
НА МИКРОСХЕМАХ
ПРОГРАММИРУЕМОЙ ЛОГИКИ
Санкт -Петербург
«БХВ -Петербург»
2002
УДК 681.3(075.8)
ББК 32.973 -02я73
Г91
Грушвицкнй Р. И., Мурсаев А. X., Угрюмое Е. П.

Г91 Проектирование систем на микросхемах программируемой логики. —
СПб.: БХВ -Петербург, 2002. — 608 с.: ил.
ISBN 5 -94157 -002 -3
В книге систематически изложены основные архитектурные и схемо-
технические особенности современных больших интегральных схем с про-
граммируемой структурой (ИСПС) всех ведущих производителей, в том
числе особенности реконфигурируемых систем на кристалле. Рассмотрены
методология, маршруты проектирования и специфика основных этапов соз-
дания проектов на ИСПС с ориентацией на использование систем автома-
тизированного проектирования. Представлены наиболее распространенные
языки описания цифровых устройств и их место в процессе проектирования.
Для студентов, аспирантов, преподавателей профильных специальностей,
а также инженеров -разработчиков вычислительных, управляющих,
радиотехнических и телекоммуникационных систем
УДК 681.3(075.8)
ББК 32.973 -02я73
Группа подготовки издания:

Главный редактор Екатерина Кондукова
Зав. редакцией Анна Кузьмина
Редактор Григорий Добин
Компьютерная верстка Ольги Сергиенко
Корректор Зинаида Дмитриева
Дизайн обложки Игоря Цырульникова
Зав. производством Николай Тверских
Лицензия ИД № 02429 от 24.07.00. Подписано печать 10.08.02.

Формат 70x100 1/10. Печать офсетная. Усл. печ. л. 48.
Тираж 3000 экз. Заказ NB 2 7 3
"БХВ -Петербург -, 198005, Санкт -Петербург, Измайловский пр.. 29.
Гигиеническое заключение на продукцию, товар № 77.99.02.953.Д.001537.03.02
от 13.03.2002 г. выдано Департаментом ГСЭН Минздрава России.
Отпечатано с готовых диапозитивов
в Академической типографии "Наука" РАН
199034, Санкт -Петербург, 9 линия, 12.
I S B N 5 94157 -002 -3 ° Грушвицкий Р. И., Мурсаев А. X., Угрюмое Е. П., 2002

о оформление, издательство "БХВ -Петербур!', 2002
Содержание
Предисловие 9
Введение 13
Глава 1. Элементная база электронных устройств и систем.

Архитектура и схемотехника интегральных схем
с программируемой структурой 23
1.1. Общие сведения. Предшественники. Классификация 23
1.1.1. Вводные замечания. Историческая справка 23
1.1.2. Базовые матричные кристаллы (вентильные матрицы) 28
1.1.3. Классификация логических микросхем программируемой логики 31
1.1.4. Общие (системные) свойства микросхем программируемой логики 41
1.2. CPLD — сложные программируемые логические устройства 42
.2.1. Структура CPLD 42
.2.2. Программируемая матрица соединений 44
.2.3. Функциональные блоки CPLD 46
.2.4. Блоки ввода/вывода CPLD 50
1.3. FPGA — программируемые пользователем,вентильные матрицы 52
.3.1. Основные сведения 52
.3.2..Функциональные блоки FPGA . 54
.3.3. Блоки ввода/вывода FPGA 56
1.3.4. Системы межсоединений 58
1.4. ПЛИС с комбинированной архитектурой 61
1.4.1. Структура микросхем семейства FLEX 61
1.4.2. Логические элементы 63
1.4.3. Встроенные блоки памяти 65
1.5. Основные сведения о СБИС типа "система на кристалле" 67
1.6. СБИС типа "система на кристалле" с однородной структурой
(с полностью синтезируемыми блоками) 70
1.6.1. Микросхемы семейств АРЕХ20К/КЕ, APEXII 70
1.6.2. Микросхемы семейств Virtex, Virtex E, Virtex II 74
4_ Содержание
1.7. СБИС типа "система на кристалле" с блочными структурами

(с аппаратными ядрами) 79
1.7.1. Вводные замечания 79
1.7.2. SOPC с блочной структурой, не содержащие ядер процессоров 80
1.7.3. SOPC семейства FPSLIC фирмы Atmel 82
1.7.4. SOPC блочного типа фирмы Triscend 88
1.7.5. SOPC блочного типа фирмы Altera 91
1.8. Микросхемы с программируемыми аналоговыми
и аналого -цифровыми структурами 92
1.8.1. Общие сведения 92
1.8.2. Практические разработки , 95
1.9. О некоторых проблемах разработки и использования БИС/СБИС
с программируемой структурой 100
1.9.1. Конвертация проектов 100
1.9.2. Конфигурирование БИС/СБИС с программируемой структурой 103
1.9.3. Засекречивание проектов 106
1.10. Способы оценки параметров ПЛИС. Обзор новой продукции
ведущих фирм -производителей ПЛИС 109
1.10.1. Об оценке логической сложности (уровня интеграции) ПЛИС 111
1.10.2. Об оценке быстродействия ПЛИС 117
1.10.3. Сведения о современной продукции крупнейших
фирм -производителей микросхем с программируемой структурой 119
Сведения, не включающие описаний блочных "систем на кристалле"
с процессорными ядрами 120
Сведения о блочных "системах на кристалле", содержащих
процессорные ядра 134
Глава 2. Основы технологии проектирования ИСПС

и структуры систем автоматизированного проектирования 139
2.1. Общие сведения о процессе проектирования 141
2.1.1. Факторы, влияющие на методику проектирования
электронных устройств 144
2.1.2. Области применения СпИС различных типов 144
2.1.3. Место БИС с программируемой структурой в процессе создания
современной аппаратуры 146
2.2. Основы организации проектной процедуры для ИСПС 148
2.2.1. Проектирование цифровых фрагментов на заказных ИС
и стандартных дискретных компонентах 157
Реализация в базисе дискретных элементов типа МИС и СИС 159
Реализация цифровых фрагментов на ПЛИС 161
Реализация цифровых фрагментов в форме однокристального
микроконтроллера 162
Реализация цифровых фрагментов в форме полузаказных кристаллов 162
2.2.2. Проектирование микропроцессорных фрагментов систем 173
Этап выбора типа МП 177
Этап выбора периферии 179
Этап разработки программного обеспечения 180
Средства поддержки создания программного обеспечения 182
Управление в реальном времени 183
Содержание 5
Этапы кодирования и отладки программного обеспечения 186

Отладка аппаратуры 187
Методы комплексной аппаратно -программной отладки 188
2.2.3. Проектирование систем, связанных с обработкой аналоговых сигналов 195
Проектирование аналоговых фрагментов 196
Проектирование фрагментов со смешанным представлением сигналов... 200
Проектирование аналоговых и аналого -цифровых SOPC 204
2.3. Структура и организация САПР 206
2.3.1. Связь процедуры проектирования и САПР БИС
программируемой логики 206
2.3.2. Связь проектной проблемы с выбором САПР 207
2.4. Основные этапы проектирования БИС программируемой логики 213
2.4.1. Этап 1. Выбор элементной базы и САПР 213
2.4.2. Этап 2. Спецификация проекта 214
2.4.3. Этап 3. Разработка общей структуры проекта 215
2.4.4. Этап 4. Содержательное описание проекта и его частей 216
Иерархия языков проектирования дискретных устройств 217
Описание структуры операционного блока 221
Описание поведения элементов операционного блока 222
Описание работы устройства управления (УУ) 223
2.4.5. Этап 5. Компиляция проекта 224
2.4.6. Этап 6. Верификация проекта 226
2.4.7. Этап 7. Определение временных характеристик
разработанного устройства 227
2.4.8. Этап 8. Организация натурных экспериментов 227
2.4.9. Этап 9. Подготовка к производственному выпуску 228
2.5. Проблемы и методы проектирования SOPC 229
2.5.1. Специфические технико -технологические особенности реализации
систем типа SOPC 231
2.5.2. Идеи и методы сопряженного проектирования 232
Методология проектирования 237
Систематическое повторное использование 238
Современные проектные средства 239
Эффективность стандартов 240
2.5.3. Стиль сопряженного проектирования и язык описания проекта 240
Методы, устраняющие связь сложности систем
и скорости моделирования 243
2.5.4. Пакеты и САПР, поддерживающие проектирование SOPC 246
Фирма Mentor Graphics 249
Фирма Cadence 250
Проектный поток в SystemC 252
2.5.5. Понятие платформенно -базированных проектов SOPC 258
2.6. Некоторые аспекты технологии производства систем с ПЛИС 261
2.6.1. JTAG -интерфейс 264
Предпосылки возникновения 264
JTAG -интерфейс и метод граничного сканирования 266
Транспортный механизм JTAG -интерфейса 269
Команды граничного сканирования 273
Содержание 7_
Простые арифметические узлы 379

Описание цифровых автоматов 385
3.2.9. Подпрограммы 394
3.2.10. Разрешаемые сигналы и шины 399
3.2.11. Структурное представление проекта 404
3.2.12. Настройка и конфигурирование компонентов 409
3.2.13. Пакеты в VHDL. Концепция видимости описаний 414
Концепция видимости объектов в VHDL 417
3.3. Элементы языка Verilog HDL 419
3.3.1. Предварительные замечания 419
3.3.2. Типы данных 423
Цепи и регистры 423
Правила записи векторных констант 426
Память 427
Целые и действительные типы данных. Время 428
Строки 429
Параметры 430
3.3.3. Операции и выражения 430
Арифметические операции 432
Операции отношения и сравнения 432
Операции сдвига 433
Логические и поразрядные операции 433
Операции свертки 433
Условная операция 434
3.3.4. Операторы initial и always 434
3.3.5. Операция присваивания, операторы присваивания 436
Непрерывное присваивание 437
Последовательные присваивания 442
3.3.6. Операторы принятия решений 444
3.3.7. Операторы повторения 447
3.3.8. Инициализация процедурных операторов 449
3.3.9. Блоки 453
3.3.11. Структурное описание проекта 458
3.3.12. Примитивы 462
Предопределенные примитивы 462
Примитивы, определяемые пользователем 463
3.4. Язык AHDL 467
3.4.1. Общая характеристика языка и структура программы 467
3.4.2. Типы данных и выражения. Оператор присваивания 470
3.4.3. Оператор выбора и оператор условия 477
3.4.4. Таблицы в AHDL 479
3.4.5. Оператор повторения . 480
3.4.6. Описание регистровых схем 481
3.4.7. Монтажная логика и буферные примитивы 485
3.4.8. Цифровые автоматы 490
3.4.9. Иерархическое проектирование в AHDL 495
3.5. Что дальше? 506
6 Содержание
Устройство управления JTAG -интерфейса 275

Стандарты, связанные с JTAG -интерфейсом 277
2.6.2. Проблемы и методология создания пригодной для тестирования
аппаратуры 278
Работы, выполняемые проектировщиком при создании проекта 280
Работы, выполняемые при тестировании готовой продукции 281
2.6.3. Обзор средств поддержки JTAG -интерфейса ведущими фирмами 285
Аппаратная поддержка JTAG -интерфейса 286
Программная поддержка тестирования 288
Комплексная организация поддержки тестирования 289
Другие подходы 291
2.6.4. Системные функции на основе JTAG -интерфейса 292
Конфигурирование БИС ПЛИС 292
Развитие средств конфигурирования схем ИСПС 293
Встраивание отладочных приборов и инструментов в ПЛИС 293
Глава 3. Языки описания дискретных устройств 297
3.1. Общие положения 297
3.1.1. HDL -программа как модель проектируемого устройства 297
Типы данных 298
Структура и поведение 299
Стили описания проектов 303
3.1.2. Принципы интерпретации поведения дискретных устройств
средствами моделирования 306
Моделирование и реальное время 306
Алфавит моделирования 310
3.1.3. Соглашение о правилах записи программ 312
3.2. Основы языка VHDL 314
3.2.1. Язык VHDL как программная система 314
3.2.2. Структура проекта. ENTITY и архитектурные тела 318
Предопределенные типы данных 326
Скалярные типы, вводимые пользователем 328
Физические типы 330
Массивы и записи 330
Подтипы 333
3.2.4. Сигналы и переменные. Оператор PROCESS 334
3.2.5. Атрибуты в языке VHDL 339
3.2.6. Последовательные операторы 343
Операторы присваивания 344
Оператор условия и оператор выбора 347
Оператор ожидания 352
Операторы повторения 353
Оператор проверки '. 358
3.2.7. Параллельные операторы 359
Оператор блока 362
3.2.8. Описание в VHDL типовых дискретных устройств 364
Комбинационные логические схемы 364
Описание триггеров и регистровых схем 372
Содержание 7_
Простые арифметические узлы 379

Описание цифровых автоматов 385
3.2.10. Разрешаемые сигналы и шины 399
3.2.11. Структурное представление проекта 404
3.2.12. Настройка и конфигурирование компонентов 409
3.2.13. Пакеты в VHDL. Концепция видимости описаний 414
Концепция видимости объектов в VHDL 417
3.3. Элементы языка Verilog HDL 419
3.3.1. Предварительные замечания 419
Цепи и регистры 423
Правила записи векторных констант 426
Память 427
Целые и действительные типы данных. Время 428
Строки 429
Параметры 430
3.3.3. Операции и выражения 430
Арифметические операции 432
Операции отношения и сравнения 432
Операции сдвига 433
Логические и поразрядные операции 433
Операции свертки , 433
Условная операция 434
3.3.4. Операторы initial и always 434
3.3.5. Операция присваивания, операторы присваивания 436
Непрерывное присваивание 437
Последовательные присваивания 442
3.3.6. Операторы принятия решений 444
3.3.7. Операторы повторения 447
3.3.8. Инициализация процедурных операторов 449
3.3.9. Блоки 453
3.3.11. Структурное описание проекта 458
3.3.12. Примитивы 462
Предопределенные примитивы 462
Примитивы, определяемые пользователем 463
3.4. Язык AHDL 467
3.4.1. Общая характеристика языка и структура программы 467
3.4.2. Типы данных и выражения. Оператор присваивания 470
3.4.3. Оператор выбора и оператор условия 477
3.4.4. Таблицы в AHDL 479
3.4.5. Оператор повторения 480
3.4.6. Описание регистровых схем 481
3.4.7. Монтажная логика и буферные примитивы 485
3.4.8. Цифровые автоматы 490
3.4.9. Иерархическое проектирование в AHDL 495
3.5. Что дальше? 506
9 Содержание
Глава 4. Примеры проектирования устройств с применением ПЛИС 513

4.1. Проектирование операционных устройств 513
4.1.1. Операционные устройства с микропрограммным управлением 513
Составление содержательной граф -схемы алгоритма
и разработка структуры операционного блока 514
Разработка модели поведения цифрового автомата 520
Разработка текстового описания устройства 521
4.1.2. Операционные устройства конвейерного типа 524
4.2. Реализация модулей памяти в ПЛИС 529
4.2.1. Память с адресным доступом 530
4.2.2. Память с последовательным доступом 537
4.2.3. Память с ассоциативным доступом 541
4.3. Цифровые фильтры 546
4.4. Пример автоматизированного проектирования
аппаратно -программной системы 560
4.4.1. Рассмотрение технического задания на разрабатываемое устройство
и выбор элементной базы 563
Процедура декомпозиции проекта 569
Выбор САПР 569
4.4.2. Разработка аппаратной части БИС SOPC 572
Этап 1. ТЗ на проектирование аппаратной части БИС 572
Этап 2. Разработка общей структуры аппаратной части проекта 573
Этап 3. Проектирование основных компонентов блока Cnt_ADC —
блока управления записью данных от АЦП 575
Этап 4. Проектирование блока Cnt_Cmp 586
Этап 5. Проектирование общей схемы — сборка проекта
из отдельных фрагментов 586
4.4.3. Настройка предопределенных ресурсов кристалла 589
Создание заголовочного файла 590
4.4.4. Разработка программного обеспечения 590
Компиляция и создание объектного кода 591
Кодовая симуляция и отладка 591
4.4.5. Монтирование ресурсов SOPC в кристалл и комплексная отладка
проекта 592
Загрузка проекта 592
Натурная отладка проекта 592
4.4.6. Разработка конструкции устройства 594
Список литературы 597
Предметный указатель 601

Предисловие
Интересы России требуют преодоления сложившегося в последнее десяти-

летие однобокого развития экономики с акцентом на сырьевые отрасли
производства. Неотъемлемой чертой развитых государств является способ-
ность к разработке и производству изделий высокой технологии, среди ко-
торых одно из ведущих мест занимает электронная аппаратура. Успех элек-
троники в значительной мере определяет технологический прогресс многих
отраслей промышленности. В последнее время, после длительного застоя в
России наметилось некоторое оживление как исследований, так и практиче-
ских разработок в области систем обработки информации самого разного
назначения, в том числе цифровых устройств.
В связи с ростом интереса к проблемам разработки электронной аппаратуры
растет и потребность в соответствующей учебной и производственно -
справочной литературе. Предлагаемая книга посвящена проблемам проекти-
рования аппаратуры на современной элементной базе, в первую очередь, на
микросхемах с программируемыми структурами. Наиболее развитыми и ши-
роко применяемыми в этой области являются цифровые программируемые
микросхемы (ПЛИС) и, естественно, основное внимание в книге уделено
именно этим компонентам. Но и состояние разработок, и методологию про-
ектирования аналоговых (ПАИС) и цифроаналоговых программируемых
микросхем авторы в некоторой мере попытались представить.
В настоящее время опубликованных работ на русском языке по предлагае-
мой тематике явно недостаточно. Среди книг, вышедших в последние годы,
можно указать работы [3, 8, 24, 30, 56, 57].
Книга А. П. Антонова [3] — это удачное пособие для освоения основных
проектных процедур при использовании САПР MAX+PLUS II фирмы
Altera. В книге В. Б. Стешенко [24] подробно рассмотрены вопросы, связан-
ные с реализацией задач цифровой обработки сигналов на компонентах
программируемой логики, но также с преимущественной ориентацией на
продукцию фирмы Altera. Имеется краткая информация о процедуре проек-
тирования и языках проектирования дискретных устройств.
10 Проектирование систем на микросхемах программируемой логики
Ряд работ посвящены описанию языков проектирования аппаратуры

(П. Н. Бибило [8], С. Емец [13], переводные книги [6, 56 и 57]). Не умаляя
достоинств этих работ, хочется заметить, что они, в основном, ограничива-
ются изложением языка как такового, без достаточной связи с возможно-
стями САПР и анализа влияния формы описания на результаты проектиро-
вания.
Книги В. В. Соловьева и А. А. Шалыто посвящены теоретическим вопросам
синтеза устройств в элементном базисе, характерном для ПЛИС, но, как
нам кажется, рассчитаны в большей мере на разработчиков систем проекти-
рования, нежели на проектировщиков цифровых устройств. Вопросы проек-
тирования устройств и систем с использованием распространенных САПР
в них практически не отражены.
Авторы предлагаемой книги старались показать проблемы проектирования
в широком плане, не сосредотачиваясь на результатах работы какой -либо
отдельной фирмы, но и не жертвуя конкретным характером материалов. Ав-
торы стремились нарисовать интегральную картину создания проекта с ис-
пользованием ПЛИС, начиная от выбора способа реализации отдельных
частей проекта (для этого, в частности, служит обзорный материал по со-
временным программируемым микросхемам) и определения стратегии про-
ектирования до завершающего представления проекта в форме, понятной
системе автоматизированного проектирования, его верификацией и подго-
товкой к реализации.
Авторы являются сотрудниками кафедры вычислительной техники Санкт -
Петербургского электротехнического университета (ЛЭТИ). Предлагаемый
материал широко использовался в учебном процессе в курсах лекций по
дисциплинам "Элементы и устройства ЭВМ", "Языки автоматизации проек-
тирования средств вычислительной техники", "Автоматизация проектирова-
ния ЭВМ" для студентов, обучающихся по специальности 220100 "Электрон-
ные вычислительные машины, комплексы, системы и сети", а также при
проведении курсов повышения квалификации работников научных и про-
мышленных предприятий. Университет располагает методическими мате-
риалами и комплексом средств для выполнения лабораторных занятий и
практических разработок.
При участии авторов реализован ряд конкретных проектов с использовани-
ем ПЛИС из областей цифровой обработки сигналов, интерфейсных моду-
лей компьютеров, кодирования информации.
Материалы книги распределены между авторами следующим образом: вве-
дение написано авторами совместно. Глава 1 написана Е. П. Угрюмовым,
глава 2 — Р. И. Грушвицким, глава 3 — А X. Мурсаевым, глава 4 — А X. Мур -
саевым и Р. И. Грушвицким. Такое разделение содержания между авторами
лишь приблизительно отражает вклад каждого из них в создание книги, т. к.
Предисловие 11
при этом имели место взаимный обмен материалами и коллективное обсуж-

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

явились? Как с ними обращаться и где применять? Это можно понять пол-
нее, рассматривая возникновение микросхем с программируемой структурой
на фоне предшествующих этапов развития вычислительной техники. Вы-
числительные машины второй половины XX века ведут свой отсчет от уни-
версального компьютера фон Неймана, в котором процесс решения задачи
организован как последовательное во времени выполнение простых опера-
ций. Каждая операция выполняется по своей команде, совокупность команд
образует программу, разработанную для решения данной задачи. Состав ап-
паратных средств фиксирован (процессор, память, устройства ввода/вывода
данных), и изменение решаемой задачи отражается лишь на числе и составе
команд программы. Такой процесс решения соответствует программной ин-
терпретации алгоритмов. Хотя в современных вычислительных архитектурах
реализованы принципы одновременной (параллельной) реализации не-
скольких команд, в том числе конвейерные и суперскалярные принципы
обработки, параллельная реализация нескольких программ в многопроцес-
сорных системах и т. п., в целом в подобных системах сохраняется принцип
последовательного во времени исполнения алгоритма.
Программный метод интерпретации алгоритмов не является единственным
способом решения задач. Можно применять структурную или, как еще го-
ворят, аппаратную интерпретацию алгоритма. В этом случае также выпол-
няется множество отдельных простых операций. Но для выполнения от-
дельных действий применяются свои функциональные блоки, соединяемые
в цепь определенной структуры. Функциональные характеристики блоков и
характер соединений между ними соответствуют алгоритму решения задачи.
Иными словами, для получения решения создается структура, отображаю-
щая интерпретируемый алгоритм. Алгоритм реализуется за счет продвиже-
ния данных и их преобразования по путям обработки (асинхронно или при
тактировании) от входов к выходам схемы, с которых снимается результат.
Команды для выполнения отдельных операций отсутствуют. Это обеспечи -
вает распределение решения задачи не только во времени, аив пространст-

ве. Естественным образом достигается высокая степень параллелизма. В этом
случае, состав аппаратных средств тесно связан с решаемой задачей. Услож-
нение задачи ведет к увеличению количества используемого оборудования.
Изменение задачи требует изменения состава компонентов и способов их со-
единения.
Роль и значение компьютеров в современной жизни общеизвестны. Аппа-
ратные методы решения задач также важны и в ряде случаев незаменимы.
Многие приложения, такие как моделирование динамических объектов,
управление движением (особенно управление движением совокупности объ-
ектов), обработка сигналов и изображений в реальном времени, реалистич-
ная компьютерная графика и подобные, связаны с многократным выполне-
нием сравнительно простых операций, причем требуют выполнения до не-
скольких миллиардов операций в секунду.
Последовательное выполнение большого числа элементарных шагов при
компьютерном решении задачи занимает относительно большое время.
Кроме того, независимость аппаратных средств от сложности решаемой за-
дачи имеет и оборотную сторону — даже для простейших задач нужны бло-
ки, образующие компьютер в целом. Таким образом, простые задачи и зада-
чи, которые должны решаться в реальном масштабе времени, могут привес-
ти к необходимости применения аппаратных вариантов решения. Понятие
"реального времени" означает, что результат должен быть получен за ограни-
ченный интервал времени, иначе он становится бесполезным.
Остановимся подробнее на некоторых путях реализации задач аппаратными
средствами. Для создания аппаратных средств решения задач нужен набор
различных элементов, узлов и устройств. Такой набор можно реализовать на
микросхемах разного уровня интеграции: малого (МИС), среднего (СИС),
большого (БИС) и сверхбольшого (СБИС). Применение БИС/СБИС и исклю-
чение из схемы МИС и СИС существенно улучшает параметры аппаратуры
(стоимость, быстродействие, надежность, экономичность по потребляемой
мощности и др.). В то же время на пути реализации схем в виде БИС/СБИС
могут возникнуть большие экономические трудности, поскольку разработка
БИС/СБИС чрезвычайно дорога и требует больших затрат времени (стои-
мость проектирования достигает сотен миллионов долларов, а время разра-
ботки — многих месяцев). Такие затраты могут оправдаться только при
больших тиражах выпуска микросхем. Тогда высокая стоимость их проекти-
рования раскладывается на большое число изготовленных и проданных эк-
земпляров (порядка сотен тысяч или более), чего' при проектировании спе-
циализированных вычислительных средств обычно не бывает.
Противоречие между желательностью и возможностями применения
БИС/СБИС в специализированных устройствах и системах вызвало к жизни
концепцию программирования структур.
Введение 15_
Благодаря программированию структур для электронной промышленности

осуществилась универсализация БИС/СБИС, сделавшая их пригодными для
широкого круга потребителей. Это было достигнуто изготовлением про-
мышленным способом некоторых заготовок, которые далее преобразуются
потребителем в нужные ему устройства. Заготовки можно производить мас-
совым тиражом, что позволяет выполнять их в виде БИС/СБИС. Естествен-
но, необходима простота доведения заготовок до законченных микросхем,
т. е. простота программирования структур БИС/СБИС по спецификациям
заказчика. В этом случае применение БИС/СБИС даже для малотиражных
изделий становится возможным и эффективным.
Таким образом, программируемое^ БИС/СБИС, иными словами, создание
программируемых логических интегральных схем, называемых ПЛИС, по-
зволила использовать их там, где ранее приходилось применять МИС/СИС.
Более позднее достижение — репрограммируемость микросхем, обеспечив-
шая возможность многократной смены их настройки. Это позволяет изме-
нять функционирование кристалла, т. е. на одном и том же кристалле полу-
чать устройства различного назначения, стирая старую конфигурацию его
структуры и записывая новую. Для некоторых разновидностей СБИС про-
граммируемой логики возможна реконфигурация в оперативном режиме,
т. е. без извлечения микросхемы из работающей системы и с высокой ско-
ростью. Оперативное программирование микросхем — путь для новых принци-
пов построения аппаратуры.
Из изложенного видно, что программирование — концепция, сыгравшая
большую роль в развитии вычислительной техники. В этой концепции мож-
но выделить два аспекта: программирование задач для процессоров с после-
довательной интерпретацией алгоритма и программирование структур для
процессоров (используем здесь тот же термин) с параллельной интерпрета-
цией алгоритма.
Между двумя аспектами концепции программирования отнюдь не проходит
какая -то разделяющая их граница. Они могут сочетаться, открывая при этом
новые горизонты в области создания высокоэффективных средств обработ-
ки данных. Более того, уже в начале XXI века можно ожидать появления
гибридных вариантов таких средств (так называемых реконфигурируемых
компьютеров и динамически реконфигурируемых вентильных матриц). В этих
архитектурах оба аспекта программирования в какой -то мере сочетаются.
Уже в первых классических ЭВМ с последовательной интерпретацией алго-
ритмов встречается, хотя и в малой степени, и программирование структур,
т. к. выполнение различных операций в разных машинных тактах означает и
некоторую перекоммутацию цепей внутри ЭВМ. В прогнозируемых архи-
тектурах реконфигурируемых компьютеров вместо несложных устройств, реа-
лизующих элементарные операции, соответствующие простым командам,
предполагается использовать так называемые обрабатывающие поля заданной
размерности, конфигурируемые для выполнения фрагментов алгоритма оп-

тимальным образом с сокращением времени решения и необходимых для
него аппаратных ресурсов. Фрагменты алгоритма выполняются последова-
тельно во времени, соответственно им "перестраиваются" и обрабатывающие
поля. Теоретический анализ показывает, что в подобных архитектурах быст-
родействие ЭВМ может быть увеличено на порядки.
Со стороны разработчиков ПЛИС ставится вопрос построения FPGA -
процессоров (FPGA, Field Programmable Gate Array, т. е. вентильная матри-
ца, программируемая пользователем). В таких процессорах применяется ди-
намически репрограммируемая FPGA с быстрой сменой настроек. Алгоритм
работы процессора загружается в FPGA аналогично загрузке в память ЭВМ
выполняемой программы. После решения части задачи полученные проме-
жуточные данные сохраняются в специально вводимых в схему элементах
памяти (триггерах), для решения следующей части (фрагмента алгоритма)
эти данные используются в качестве исходных. Таким образом, с помощью
нескольких последовательных смен настроек реализуются функции устрой-
ства в целом на аппаратных средствах, сложность которых соответствует
лишь части устройства (одному контексту, т. е. схеме, для выполнения
функций лишь одного яруса разбиения устройства).
Наиболее широкое применение ПЛИС находят при построении периферий-
ных модулей компьютеров, в том числе:
- интерфейсных средств;
- средств сопряжения с аппаратурой управляющих комплексов и систем;
- средств защиты информации;
- аппаратуры поддержки телекоммуникаций;
- аппаратных ускорителей (например, для реалистичной графики, обработ-
ки изображений, обработки сигналов).
Кроме того, ПЛИС используют для создания высокопроизводительной ап-
паратуры специализированного назначения, включая:
- обработку сигналов в реальном времени;
- средства управления производственными процессами;
- автономные интеллектуальные датчики;
- средства кодирования и декодирования информации в системах связи.
Прокомментируем некоторые из отмеченных направлений.
Ядро вычислительной системы составляют процессоры и память, которые
с точки зрения производителей ИС являются стандартной продукцией. Кроме
стандартных частей вычислительная система содержит и некоторые индиви-
дуальные схемотехнические части для сопряжения модулей и управления
Введение 17
ими. Такие индивидуальные части системы ранее приходилось строить с

помощью ИС малого и среднего уровней интеграции, применение которых
ведет к резкому увеличению числа корпусов и внешнего монтажа. Приме-
нение ПЛИС — кардинальный путь реализации систем в целом на инте-
гральных схемах высокого уровня интеграции. Одно из последних достиже-
ний в этой области — системы на кристалле SOC (System -On -a -Chip), ин-
тегрирующие процессорный модуль, программируемый "традиционным"
способом, т. е. путем занесения программы в постоянную или оперативную
память, и реконфигурируемую вентильную матрицу для реализации требуе-
мых в конкретном проекте специфических прикладных аппаратных средств.
Говоря о системах управления, следует отметить, что они, как правило, со-
держат большое количество разнообразных датчиков и исполнительных уст-
ройств, отличающихся способами представления информации, форматами
данных, временными характеристиками потоков данных. Узлы системы час-
то работают не синхронно с вычислительным ядром. Решение задач сопря-
жения принципиально требует использования специальных аппаратных
средств для буферизации, упаковки и распаковки данных, взаимного опо-
вещения узлов системы о тех или иных событиях. Устройства преобразова-
ния формы представления информации (аналого -цифровые и цифроанало -
говые преобразователи) также реализуются с использованием структурных
подходов и часто включают как цифровые специализированные узлы, так и
аналоговые подсхемы. Необходимость включения в системы аналоговых
компонентов, перестраиваемых в соответствии с требованиями потребите-
лей, вызвала в последние годы разработку и производство программируемых
аналоговых и цифроаналоговых интегральных схем (ПАИС и ПЛАИС).
Разнообразны возможности применения специализированных (но зачастую
перестраиваемых) аппаратных средств для защиты информации. Это могут
быть простейшие средства контроля доступа к информации на жестких маг-
нитных и лазерных дисках — так называемые индивидуальные электронные
ключи доступа, которые персонально программируются для допущенных
пользователей и уносятся ими после сеанса работы. В более ответственных
случаях применяется шифрация информации перед записью на диск или
передачей в сеть. Преимущество аппаратных средств защиты по сравнению
с программными наряду с повышением скорости работы состоит в трудно-
сти и даже невозможности скопировать алгоритм шифрации.
Реализация коммуникационных протоколов нижних уровней (физического
и канального) традиционно решалась с использованием аппаратных средств
для формирования битовых потоков и их первичного декодирования, уста-
новления соединений абонентов. Применение программируемой логики де-
лает возможным и экономически эффективным выполнение в аппаратной
среде интеллектуальной обработки, включая сжаццр, 'буферноащио) панети
рование данных и т. д.
Аппаратные ускорители вычислений также не являются чем -то существенно

новым. Видеокарты, блоки для реализации задач компьютерной графики и
обработки изображений занимают заметное место на компьютерном рынке.
Программируемая логика и, особенно, репрограммируемые схемы обеспечи-
вают новые возможности. Во -первых, покупая плату, содержащую одну или
несколько ПЛИС (а такие платы производят многие фирмы), и подключая
ее к компьютеру стандартным образом, пользователь получает в свое распо-
ряжение как бы несколько различных устройств. Достаточно загрузить в
микросхему одну из возможных конфигураций из числа сохраняемых на
жестком диске компьютера, чтобы вызвать к исполнению тот или иной
алгоритм функционирования периферийного блока, подобно тому, как в
"обычной" ЭВМ запускаются различные программы. Во -вторых, пользова-
тель может самостоятельно модифицировать работу такого блока, обеспечи-
вая реализацию специфических функций, не предусмотренных изготовите-
лями специализированных устройств.
В связи с этим нельзя не отметить использование ПЛИС при разработке
полностью заказных БИС. На первой стадии разработки проект воспроизво-
дят с использованием репрограммируемых компонентов, в которые легко
вносить изменения. Затем отлаженная конфигурация импортируется в сис-
тему проектирования заказных БИС. Такая методика называется быстрой
прототипизацией систем (Rapid System Prototyping), а платы с набором мик-
росхем ПЛИС и средствами подключения к отладочному компьютеру —
платами для прототипшации (prototyping boards, development boards).
Приведенные примеры далеко не исчерпывают всех возможностей. Более
того, в связи с постоянным уровнем роста степени интеграции программи-
руемых БИС снижением их стоимости, развитием средств проектирования
область их применения постоянно расширяется.
Разработка систем с использованием программируемых БИС невозможна
без применения средств и систем автоматизированного проектирования
(САПР). Трудно даже представить разработку "ручными" способами уст-
ройств с уровнем сложности, эквивалентным сотням тысяч вентилей. Рост
уровня сложности требует не только использования современных средств
проектирования, но и переосмысления всей технологии проведения проект-
ных работ, включая декомпозицию проекта, планирование и управление
работами, параллельную и взаимосвязанную разработку его фрагментов и
грамотное объединение фрагментов в целостное устройство. Особо значи-
мыми становятся процедуры отладки и верификации проектных решений.
Рынок САПР больших интегральных схем, и в частности программируемых
ИС, переживает период бурного развития. В конкурентной борьбе участвуют
как фирмы -производители БИС, так и ряд фирм, специализирующихся на
разработке систем автоматизированного проектирования.
Современной тенденцией развития САПР является интегрирование в одной
системе средств для выполнения большинства этапов проектирования, на -
Введение 19
чиная от описания проекта, его моделирования и отладки, вплоть до разра-

ботки проектной документации и управления процессом физической реали-
зации. Много внимания уделяется средствам повторного использования
проектных решений (Reusing), организации корпоративной проектной дея-
тельности (библиотеки, встроенные системы управления базами данных).
Тем не менее, нередки ситуации, когда по тем или иным причинам части
проекта подготавливаются в разных проектных средах. Это может быть свя-
зано с привычкой отдельных членов коллектива проектировщиков к раз-
личным формам представления проектной информации, желанием приобре-
сти от третьих фирм готовые решения, которые исходно создавались на
других платформах, не говоря о том, что к частям проекта могут предъяв-
ляться специфические требования, требующие привлечения специальных
средств синтеза и отладки. Нельзя не признать также оправданной исполь-
зование различных средств описания на разных уровнях представления про-
екта. Так, для общей спецификации можно рекомендовать представления на
языках системного уровня. Высшие уровни структурной декомпозиции
удачно и наглядно представляются в графической форме. Для детального
представления фрагментов могут использоваться языки описания аппарату-
ры или схемное представление (Net List). Разработчики САПР должны учи-
тывать подобные потребности.
Поэтому другая тенденция разработок — это обеспечение совместимости
различных форм представления в одном проекте, включая возможность им-
портирования в рабочий проект фрагментов, созданных на разных плат-
формах разными средствами. Несмотря на имеющуюся достаточно острую
конкуренцию, фирмы часто заключают соглашения на право взаимного ис-
пользования программной продукции, а также передачи информации о струк-
туре конфигурационных файлов для программирования микросхем.
Важнейшее влияние на весь процесс проектирования оказывает выбор ис-
ходного описания проекта. Традиционным способом представления цифро-
вых устройств является графическое. Определяется набор компонентов, изо-
бражения которых размещаются на поле чертежа (в рабочем окне дисплея),
и прорисовываются их соединения. Близко к графическому примыкает таб-
личное представление, предусматривающее явное задание списка компонен-
тов и списка соединений. Главным недостатком графического и табличного
представления проекта следует считать трудоемкость процедуры ввода,
трудность поиска ошибок. Представление проекта и ввод информации в
форме текста на языке проектирования аппаратуры (HDL, Hardware Design
Language) в значительной мере свободно от этих недостатков. Текстовое
описание объединяет в себе возможность компактного представления очень
сложных логических проектов с легкостью его понимания и большой ско-
ростью его создания, включая относительную простоту поиска ошибок и
внесения модификаций в проект. Достоинством описания проекта в тексто -
вом виде (на языках Verilog, VHDL и др.) является также возможность легкого
переноса проекта в различные приборные среды, простота настройки или
перенастройки параметров разрабатываемых устройств или их фрагментов,
например, разрядности или подмножества реализуемых функций. У разра-
ботчика появляются предпосылки расширять возможности языка за счет
введения собственных макроопределений, ориентированных на класс реали-
зуемых проектов.
Кроме того, языковое описание является эффективным способом перевода
программ пользователя, построенных на базе стандартных универсальных
языков (например, С), в языки описания аппаратуры и обратно. Уже сего-
дня имеются возможности автоматического генерирования HDL -программ
на базе других формальных представлений. Развитие языковых средств про-
ектирования сближает методы проектирования аппаратуры и программных
средств, расширяя возможности разработчиков, и улучшает взаимопонима-
ние между проектировщиками различных подсистем вычислительных ком-
плексов.
Нельзя не отметить значительное отставание российских проектных органи-
заций от их западных конкурентов не только и не столько в количестве
привлекаемых систем проектирования, сколько в готовности персонала ис-
пользовать современные технологии проектирования. В частности, до сих
пор, в отличие от мировой ситуации, в России подавляющее большинство
проектов в области цифровой техники реализуется с использованием схем-
ного (графического) ввода проекта. Авторы надеются, что издание этой
книги будет способствовать подготовке специалистов, владеющих современ-
ными средствами проектирования, и улучшению ситуации.
Структура предлагаемой книги соответствует перечисленным особенностям
создания проекта.
Глава 1 представляет обзор рынка программируемых БИС. Авторы не стре-
мились детализировать архитектурные и схемотехнические особенности
(такие сведения можно найти в работах [4, 17, 24, 27, 31, 35, 45, 53] и др.),
хотя в отношении новейших семейств программируемых ИС соответствую-
щие данные приводятся. Больше внимания уделено сравнительной оценке.
Содержание главы должно стать руководством для принятия решений о вы-
боре технических средств на ранних этапах выполнения проекта.
Материал главы 2 на сегодня не имеет аналогов в общедоступной литерату-
ре. Здесь предпринята попытка систематизированного представления не
только отдельных проектных процедур применительно к проектированию
систем на программируемых микросхемах, но, прежде всего, выявления их
взаимосвязи и взаимной обусловленности. Отмечаются отличия современ-
ных технологий проектирования от концепций, принимавшихся ранее. Под-
черкивается возможность и целесообразность при использовании современ -
Введение 21_
ных САПР встраивать в проект разнородные компоненты и использовать

разнообразные формы представления.
Глава 3 посвящена изложению наиболее употребительных языков проекти-
рования дискретных устройств. Объединение в одном издании изложения
нескольких языков (что не соответствует распространенной практике подго-
товки индивидуальных изданий для различных языков) позволило рассмот-
реть их с единых позиций, выделить их общие свойства, но и оттенить раз-
личия. Это упростит при необходимости переход проектировщиков на но-
вые языки (в том числе и еще только разрабатываемые) и улучшит
взаимопонимание проектных групп, ориентирующихся на разные способы
представления.
В главе 4 представлено несколько конкретных разработок модулей на
ПЛИС. На этих примерах иллюстрируется методология проектирования и
особенности выбора реализации в зависимости от системных требований.
Кроме того, авторы старались показать читателю, что "проектирование на
ПЛИС — это очень просто".
ГЛАВА 1
Элементная база
электронных устройств и систем,
Архитектура и схемотехника
интегральных схем
с программируемой структурой
1.1. Общие сведения. Предшественники.

Классификация
1.1.1. Вводные замечания. Историческая справка
Элементную базу электронной аппаратуры обработки информации и ее хра-
нения составляют интегральные схемы (ИС). В зависимости от характера
сигналов, отображающих информацию, средства ее обработки разделяют на
цифровые, аналоговые и цифроаналоговые. Классификация цифровых ИС
приведена на рис. 1.1.
Прежде всего, по признаку ориентации на массовое потребление или на
конкретный заказ цифровые интегральные схемы можно разделить на стан-
дартные и специализированные. Стандартные ИС приобретаются потребите-
лем как готовые изделия (off -the -shelf) и производятся массовыми тиражами,
что позволяет затрачивать большие средства на их проектирование, по-
скольку его стоимость раскладывается на большое число изделий. Стан-
дартные ИС традиционных видов имеют практически жесткую внутреннюю
структуру, и потребитель не может влиять на характер их функционирова-
ния. Специализированные ИС (СпИС), имеющие индивидуальный характер
функционирования, приходится в той или иной мере разрабатывать (проек-
тировать) по конкретному заказу. Проектирование ИС — процесс сложный
и дорогостоящий, поэтому понятно стремление в максимально возможной
степени строить аппаратуру на основе стандартных ИС.
Стандартные Специализированные
Standard ASIC
Рис. 1.1. Классификация цифровых интегральных схем
К стандартным относятся следующие виды цифровых ИС.

- Микросхемы малого и среднего уровней интеграции МИС и СИС, в анг-
лийской терминологии SSI (Small Scale Integration) и MSI (Medium Scale
Integration). Этот класс микросхем представлен многочисленными и хо-
рошо известными с давних пор стандартными сериями элементов. Необ-
ходимость использования таких микросхем в отдельных ситуациях сохра-
няется и сейчас, но построение на них сложных устройств ведет к суще-
ственному ухудшению технико -экономических параметров аппаратуры в
сравнении с теми, которые могли бы быть получены при применении
микросхем высокого уровня интеграции.
- БИС/СБИС микропроцессоров и микроконтроллеров, МП и МК (Micro-
processors, МР и Microcontrollers, MC). Многочисленные микросхемы МП
и МК широко и успешно применяются при решении задач программной
реализации алгоритмов.
Глава 1. Элементная база электронных устройств и систем 25_
- БИС/СБИС запоминающих устройств (Memory IC), относящиеся к наи-

более массовым ИС с широкой номенклатурой, применяемым в устрой-
ствах и системах разного назначения для хранения данных и обмена ими
с другими блоками систем.
- Интегральные схемы с программируемой пользователем структурой
(ИСПС). Эти схемы ознаменовали появление нового перспективного на-
правления в развитии элементной базы электронного приборостроения.
Именно эти БИС/СБИС открывают возможности использования микро-
схем высокого уровня интеграции не только в массовых изделиях, выпус-
каемых тиражами в сотни тысяч экземпляров, но и в проектах практиче-
ски любой тиражности. В ИСПС задание схеме определенной внутрен-
ней структуры (конфигурирование схемы) выполняется потребителем,
изготовитель в этом процессе не участвует и поставляет на рынок про-
дукцию, пригодную для многих покупателей, создающих аппаратуру раз-
ного назначения. Рассмотрению ИСПС посвящены основные материалы
этой главы. Отметим, что ИСПС имеют в известной мере двойственный
характер: для потребителя они являются специализируемыми, а для про-
мышленности — стандартными (со всеми вытекающими из этого выго-
дами). Это обстоятельство отражено на рис. 1.1 штриховой линией.
Кроме указанных в классификации, к стандартным микросхемам принадле-
жат также аналого -цифровые и цифроаналоговые преобразователи.
Специализированные ИС, как уже отмечалось, в той или иной мере проек-
тируются для конкретного заказчика. При этом от заказчика, как правило,
требуются затраты значительных средств при длительных сроках разработки
СпИС. Для преодоления трудностей создания специализированных ИС был
предложен ряд методик их проектирования, соответственно которым суще-
ствует и несколько разновидностей СпИС (в английской терминологии
СпИС обозначаются термином ASIC, Application Specific Integrated Circuit).
( Замечание )
Особо следует остановиться на термине ASSP (Application Specific Standard
Products), который получает все более широкое распространение. Этому тер-
мину не всегда придается одинаковый смысл. В данной книге термин ASSP по-
нимается как синоним термина ИСПС и определяет способ конфигурирования
схемы под определенную задачу. Для программирования ASIC нужна разра-
ботка специальных фотошаблонов с рисунками межсоединений, требующая
больших затрат средств и времени. Применяя для целей конфигурирования
программируемые логические интегральные схемы (ПЛИС), можно исклю-
чить разработку шаблонов и сравнительно простыми способами получить
эффективные средства построения цифровых систем, содержащие набор
схем с необходимым функционированием. Такие архитектуры и относятся к
классу ASSP, причем первая часть аббревиатуры сохраняет преемственность
с термином ASIC, а вторая подчеркивает принадлежность микросхем к стан-
дартной для электронной промышленности продукции.
Можно без преувеличения сказать, что вопросы реализации проектов на

элементной базе высокого уровня интеграции сейчас привлекают к себе ос-
новное внимание разработчиков систем и специалистов электронной про-
мышленности. В этом направлении важнейшим достижением явилось появ-
ление ИС с программируемой структурой. До их создания специализиро-
ванные проекты в зависимости от конкретных условий (сложности проекта,
его тиражности, требований к техническим и экономическим характеристи-
кам, отведенного для реализации времени и т. д.) традиционно выполнялись
в следующих вариантах:
- на микросхемах малого и среднего уровня интеграции;
- на полузаказных микросхемах (базовых матричных кристаллах);
- на заказных микросхемах, спроектированных по методу стандартных ячеек;
- на полностью заказных микросхемах.
Среди СпИС (ASIC) различают классы полузаказных и заказных ИС. Разно-
видностями заказных микросхем являются полностью заказные ИС (Fully
Custom IC) и ИС, спроектированные методом "на стандартных ячейках"
(Standard Cell Logic). Полностью заказные схемы целиком проектируются по
требованиям конкретного заказчика. Проектировщик имеет полную свободу
действий, определяя схему по своему усмотрению вплоть до уровня схемных
компонентов (отдельных транзисторов и т. п.). Для изготовления схемы тре-
буется разработка всего комплекта фотошаблонов, верификация и отладка
всех схемных фрагментов. Такие схемы очень дороги и имеют длительные
циклы проектирования.
Схемы на стандартных ячейках отличаются от полностью заказных тем, что
их фрагменты берутся из заранее разработанной библиотеки схемных реше-
ний. Такие фрагменты уже хорошо отработаны, поэтому стоимость и дли-
тельность проектирования при их использовании снижаются. Для производ-
ства схем тоже требуется изготовление полного комплекта фотошаблонов,
но разработка шаблонов облегчена. Потери сравнительно с полностью за-
казными ИС состоят в том, что проектировщик имеет меньше свободы в
построении схемы, т. е. результаты ее оптимизации по критериям площади
кристалла, быстродействию и т. д. менее эффективны. Наивысших техниче-
ских параметров добиваются от полностью заказных схем, однако метод
стандартных ячеек популярен, т. к. при небольших потерях в технических
характеристиках с его помощью можно заметно упростить проектирование
схемы. Полностью заказные схемы разрабатываются за время, превышаю-
щее время разработки схем методом стандартных ячеек приблизительно
в два раза.
К полузаказным схемам относятся базовые матричные кристаллы БМК
(в английской терминологии MPGA, Mask Programmable Gate Arrays, или
LPGA, Laser Programmable (или Laser Personalised) Gate Arrays). В этом слу-
чае имеется стандартный полуфабрикат, который доводится до готового из -
Глава 1. Элементная база электронных устройств и систем 27
делия с помощью индивидуальных межсоединений. Реализация требует из-

готовления лишь малого числа фотошаблонов (для MPGA) или цикла опе-
раций разрушения некоторых межсоединений лазерным лучом (для LPGA).
Хотя стоимость и длительность проектирования в сравнении с полностью
заказными схемами сокращаются в 3—4 раза, результат еще дальше от оп-
тимального. Причина неоптимальности заключается в том, что в матричных
БИС (МАБИС) менее рационально используется площадь кристалла (на
кристалле остаются неиспользованные элементы и т. п.), длины связей не
минимальны, и быстродействие не максимально.
Сходство методов проектирования на БМК и стандартных ячейках состоит
в использовании библиотек функциональных элементов. Различие — в том,
что для схем, проектируемых по методу стандартных ячеек, библиотечный
набор элементов имеет более выраженную топологическую свободу. Напри-
мер, в отличие от БМК, стандартизируются не оба размера ячеек (ширина и
высота), а только высота ячеек, длины которых могут быть различными.
При проектировании вначале из набора библиотечных элементов подбира-
ются необходимые функциональные блоки, а затем решаются задачи их
размещения и трассировки. Существует, естественно, и большое различие
в числе шаблонов, которое требуется изготавливать для производства БМК
и заказных ИС по методу стандартных ячеек.
Методика, а соответственно, и САПР для проектирования по методу стан-
дартных ячеек более сложны, чем для проектирования на основе БМК, ко-
торому свойственны более жесткие топологические ограничения. Ограниче-
ния вводятся и для метода стандартных ячеек (постоянство высоты ячеек,
предопределенность геометрических размеров и положения шин питания,
тактирования и др.), но по мере применения более мощных САПР ограни-
чения ослабляются. Длительность изготовления БИС/СБИС методом стан-
дартных ячеек превышает этот же показатель для МАБИС на основе БМК
в 1,3—1,8 раза.
Таким образом, как показано выше, заказные БИС/СБИС от начала до кон-
ца разрабатываются для конкретного проекта. В них нет лишних элементов,
оптимально размещены подсхемы и их межсоединения. Свойственная за-
казным схемам оптимизация БИС/СБИС по конкретному техническому
заданию минимизирует площадь кристалла, т. е. удешевляет его, позволя-
ет добиться максимального быстродействия разрабатываемого устройства
и т. д. Но, как уже отмечалось, разработка оригинальной БИС/СБИС (ее
проектирование) чрезвычайно дорога и требует спроектировать и изготовить
полный комплект фотошаблонов (15—20 штук). Стоимость проектирования
и изготовления каждого шаблона составляет десятки тысяч долларов. Со-
временный уровень затрат на создание комплекта фотошаблонов для произ-
водства БИС/СБИС можно охарактеризовать следующими цифрами: для
технологии с минимальным размером 0,18 мкм это 300—350 тыс. долларов,
для технологии с минимальным размером 0,13 мкм — около 500 тыс. долла -
ров, а для минимального размера 0,1 мкм ожидается 750 тыс. долларов или
более.
Проекты, реализованные на ИС с программируемой пользователем структу-
рой, стали успешно конкурировать прежде всего с двумя первыми из пере-
численных выше методов реализации специализированных устройств. В на-
стоящее время проектирование систем и логических устройств все больше
перемещается в сторону широкого использования программируемых схем
для всех вариантов разработки электронных аппаратных средств.
Интегральные схемы с программируемой пользователем структурой (ИСПС)
существуют уже около 25 лет и к настоящему времени представлены множе-
ством разнообразных семейств. Программирование структур вначале было
применено в программируемых логических матрицах (ПЛМ), программи-
руемой матричной логике (ПМЛ) и базовых матричных кристаллах (БМК).
Вслед за ними возникли новые классы более сложных ИСПС, продолжаю-
щих линии развития матричной логики и базовых матричных кристаллов:
CPLD и FPGA, соответственно. Затем были реализованы ИСПС комбини-
рованной (смешанной) архитектуры, сочетавшие признаки CPLD и FPGA.
Позднее удалось разработать ИСПС с аналоговыми и аналого -цифровыми
элементами, которые можно обозначить как ПАИС (программируемые ана-
логовые интегральные схемы).
1.1.2. Базовые матричные кристаллы

(вентильные матрицы)
В этой книге понятие "программируемые" относится к операциям, выполняе-
мым пользователем, поэтому рассмотрение БМК, строго говоря, не соответ-
ствует теме. Действительно, класс БМК выпадает из общего ряда перечис-
ленных ИСПС, поскольку для него программирование микросхем произво-
дится не пользователем, а изготовителем, т. е. на предприятии электронной
промышленности с помощью сложных технологических процессов. Тем не
менее, ознакомление с БМК необходимо, т. к. они являются предшествен-
никами FPGA — важного класса ИСПС — имеют с ними ряд родственных
черт и тесно связаны с использованием FPGA в процессе так называемой
конвертации проектов. Кроме того, задача проектирования устройств и сис-
тем на основе БМК близка к задаче проектирования на ИСПС, поскольку,
как правило, в значительной мере ложится на плечи пользователя.
Базовые матричные кристаллы называют также вентильными матрицами
(ВМ), что соответствует принятому для БМК английскому термину GA
(Gate Array). Термин БМК преобладает в отечественной литературе и по-
этому используется в этой книге, хотя термин "вентильная матрица" был бы
предпочтителен как не противоречащий международной терминологии.
Базовые матричные кристаллы известны с 1975 года, когда американская
фирма Amdahl Corp применила их в составе высокопроизводительной ЭВМ
с целью исключения из нее микросхем малого и среднего уровней интегра-

ции. Результаты оказались удачными, и в последующие годы БМК получили
широкое распространение.
БМК — кристалл, на прямоугольной поверхности которого размещены
внутренняя и периферийная области (ВО и ПО). Во внутренней области по
строкам и столбцам (в виде матрицы) расположены базовые ячейки — груп-
пы нескоммутированных схемных элементов (транзисторов, резисторов).
Элементный состав базовой ячейки при разных вариантах межсоединений
элементов допускает реализацию некоторого множества схем определенного
класса, каждая из которых соответствует определенной функциональной ячей-
ке (ФЯ). Для выпускаемого в продажу БМК создается библиотека функцио-
нальных ячеек, т. е., в сущности, рисунков межсоединений, дающих ту или
иную схему. Библиотеки функциональных ячеек БМК насчитывают обычно
десятки или сотни типовых узлов, реализованных на одной или нескольких
базовых ячейках.
В БМК канальной структуры между строками и столбцами базовых ячеек
или их компактных групп оставляются горизонтальные и вертикальные сво-
бодные зоны (каналы) для межсоединений.
В периферийной области кристалла размещаются периферийные ячейки, вы-
полняющие операции ввода/вывода сигналов через контактные площадки,
расположенные по краям кристалла.
Переход от биполярной схемотехники к МОП -транзисторным схемам сде-
лал возможным более плотное размещение схемных элементов на кристал-
ле. При росте сложности логической части схемы, т. е. числа логических
элементов на кристалле, еще быстрее растет сложность межсоединений. Для
снижения потерь площади кристалла, затрачиваемой на трассировочные ка-
налы, была разработана бесканальная структура БМК типа "море вентилей"
или "море транзисторов", в которой конструкторы отказались от свободных
зон кристалла, заранее отведенных для межсоединений. В таких БМК вся
внутренняя область плотно заполняется базовыми ячейками, а межсоедине-
ния проводятся только там, где это необходимо, причем находящиеся под
ними базовые ячейки оказываются в данной конкретной схеме неисполь-
зуемыми.
Еще одной разновидностью БМК являются блочные, в которых на кристалле
выделяются специализированные области -подматрицы для выполнения за-
ранее определенных функций (логической обработки данных, памяти и др.).
Между подматрицами размещаются специальные трассировочные каналы,
на периферии подматриц изготовляются внутренние периферийные ячейки
для передачи сигналов по межблочным связям.
Изобретение базовых матричных кристаллов означало появление нового
класса специализируемых БИС/СБИС — полузаказных.
Для реализации конкретной полузаказной схемы на основе БМК (такие
схемы называют МАБИС, т. е. матричные БИС, или БИСМ, т. е. БИС мат -
ричные) нужны только шаблоны рисунков межсоединений. Например, при

внедрении первых БМК в фирме Amdahl Corp для заказных схем требова-
лась разработка 13 шаблонов, а для полузаказных МАБИС только трех.
Заказные БИС/СБИС существенно дороже полузаказных в проектировании,
но затраты на изготовление каждого экземпляра уже спроектированной схе-
мы у них меньше. Затраты на проектирование (подготовку производства)
однократны, затраты на изготовление присущи каждому экземпляру микро-
схемы. Отсюда видны экономически обоснованные области применения
заказных и полузаказных БИС/СБИС. Для массового производства, когда
стоимость подготовки производства (проектирования) раскладывается на
большое число микросхем, в общей стоимости экземпляра микросхемы бу-
дет преобладать стоимость его изготовления и целесообразно заказное про-
ектирование. Так проектируются микропроцессоры, микроконтроллеры,
микросхемы памяти. Для специализированных средств с меньшими тиража-
ми заказное проектирование чаше всего неприемлемо. В эпоху появления
БМК альтернативным вариантом проектирования БИС/СБИС с тираж -
ностью в десятки тысяч экземпляров стало полузаказное. Позднее возмож-
ности упрощения и удешевления процесса разработки БИС/СБИС много-
кратно возросли в связи с появлением новых и эффективных вариантов ИС
с программируемыми структурами.
БМК выпускаются рядом зарубежных фирм, а также отечественной фирмой
"Ангстрем" (семейства 1806ХМ1, 1515ХМ1, 1593ХМ1, 1537ХМ1, 1592ХМ1) и
белорусским объединением "Интеграл" (семейства 1532ХМ, 1540ХМ, 1547ХМ,
1574ХМ, 1575ХМ). Для ориентировки укажем некоторые параметры отдель-
ных БМК. Предварительно заметим, что оценкой сложности БМК служит
число эквивалентных вентилей (обычно, вентилей 2И -НЕ) в его составе.
БМК 1592ХМ1 содержит 100 тыс. эквивалентных вентилей, имеет библиоте-
ку из 230 функциональных ячеек и рабочую частоту 50 МГц. Корпус БМК
имеет 132 внешних вывода, из которых пользовательских (функциональных)
100. Диапазон рабочих температур от -60 до +85 "С.
БМК G10, G1l, G12 американской фирмы LSI Logic имеют беспрецедентно
высокую сложность и содержат до 33 млн. эквивалентных вентилей, а бипо-
лярный БМК SH100K фирмы Infinion (ранее Siemens Semiconductor),
имеющий до 10 тыс. эквивалентных вентилей и матрицу аналоговых эле-
ментов на одном и том же кристалле, работает на тактовой частоте 5 ГГц.
В заключение отметим, что для более четкого отражения места БМК
в иерархии микросхем полезно дополнить английскую аббревиатуру GA до
аббревиатуры MPGA, Mask Programmable Gate Array.
Заметим также, что наряду с описанным выше вариантом БМК существуют
и БМК с лазерным программированием межсоединений (LPGA, Laser
Programmable Gate Arrays). В этих БМК первоначально изготовляются ме-
таллизированными дорожками все возможные межсоединения элементов, а
при программировании часть соединений под воздействием точно сфокуси-

рованных управляемых лазерных лучей разрывается. Такие БМК подобны
обычным в том, что для конфигурирования МАБИС потребитель должен
обращаться к изготовителю, т. е. на предприятие электронной промышлен-
ности, однако сроки и стоимость выполнения заказа в сравнении с обыч-
ными БМК оказываются иными. Сроки выполнения заказа сокращаются,
что благоприятно с точки зрения ускорения выхода продукции на рынок,
однако в настоящее время БМК с лазерным программированием распро-
странены меньше, чем обычные, хотя имеются фирмы, развивающие их
производство, в частности фирма Chip Express.
1.1.3. Классификация логических микросхем

программируемой логики
В приводимой ниже классификации термин "логических" обусловлен отсут-
ствием в ней сведений об аналоговых и аналого -цифровых программируе-
мых микросхемах, для которых классификационные признаки еще не впол-
не сложились. Под программируемостью здесь и ниже следует понимать
только возможность программирования микросхемы пользователем. Аббре-
виатурой для общего обозначения всех классифицируемых микросхем может
быть ПЛИС либо ЦИСПС, т. е. "программируемые логические интегральные
схемы" либо "цифровые интегральные схемы с программируемой структурой".
Первый вариант действительно известен и поэтому будет использован, хотя
он и не совсем точен (например, применительно к широко распространен-
ным схемам, в которые, кроме программируемой логики, входят также
встроенные блоки памяти).
В классификации для пояснения содержательных положений, естественно,
использован русский язык. В то же время для многих аббревиатур сохране-
ны английские варианты, поскольку они уже прочно закрепились в практи-
ке и не имеют широко признанных русских аналогов.
Микросхемы, программируемые пользователями, открыли новую страницу
в истории современной микроэлектроники и вычислительной техники. Они
сделали БИС/СБИС, предназначенные для решения специализированных задач,
стандартной продукцией электронной промышленности со всеми вытекающими
из этого положительными следствиями: массовое производство, снижение
стоимости микросхем, сроков разработки и выхода на рынок продукции на их
основе. ПЛИС можно классифицировать по многим признакам, в первую
очередь:
- уровню интеграции и связанной с ним логической сложности;
- архитектуре (типу функциональных блоков, характеру системы межсо-
единений);
- числу допустимых циклов программирования;
- типу памяти конфигурации ("теневой" памяти);

- степени зависимости задержек сигналов от путей их распространения;
- системным свойствам;
- схемотехнологии (КМОП, ТТЛШ и др.);
- однородности или гибридности (по признаку наличия или отсутствия
в микросхеме областей с различными по методам проектирования схема-
ми, такими как ПЛИС, БМК, схемы на стандартных ячейках).
Все перечисленные признаки имеют значение и отображают ту или иную
сторону возможных классификаций. Выделяя основные признаки и укруп-
няя их, рассмотрим классификацию по трем, в том числе двум комплекс-
ным, признакам:
- архитектуре;
- уровню интеграции и однородности/гибридности;
- числу допустимых циклов программирования и связанному с этим типу
памяти конфигурации.
В классификации по первому признаку (рис. 1.2, а) ПЛИС разделены на
4 класса.
Первый из классов — SPLD, Simple Programmable Logic Devices, т. е. про-
стые программируемые логические устройства. По архитектуре эти ПЛИС
делятся на подклассы программируемых логических матриц ПЛМ (PLA,
Programmable Logic Arrays) и программируемой матричной логики ПМЛ
(PAL, Programmable Arrays Logic, или GAL, Generic Array Logic).
Оба эти подкласса микросхем реализуют дизъюнктивные нормальные фор-
мы (ДНФ) переключательных функций, а их основными блоками являются
две матрицы: матрица элементов И и матрица элементов ИЛИ, включенные
последовательно. Такова структурная модель ПЛМ и ПМЛ. Технически они
могут быть выполнены и как последовательность двух матриц элементов
ИЛИ -НЕ, но варианты с последовательностью матриц И -ИЛИ и с последо-
вательностью матриц ИЛИ -НЕ — ИЛИ -НЕ функционально эквивалентны,
т. к. второй вариант согласно правилу де Моргана тоже реализует ДНФ, но
для инверсных значений переменных.
Заметим, что термин "матрица" обозначает в данном случае не более чем
"набор", "множество" и обусловлен тем, что схемные элементы ПЛМ и ПМЛ
удобнее всего располагать по строкам и столбцам, обеспечивая тем самым
регулярность структуры БИС.
На входы первой матрицы поступают т входных переменных в виде как
прямых, так и инверсных значений, так что матрица имеет 2т входных ли-
ний. На ее выходах формируются конъюнктивные термы, ранг которых не
выше т. В дальнейшем для краткости конъюнктивные термы называются
просто термами. Число термов не имеет прямой связи с величиной т и оп -
ределяется конструктивными параметрами матрицы — числом конъюнкто -

ров, которое обозначим через q. Первая матрица идентична для обоих под-
классов SPLD, т. е. для ПЛМ и ПМЛ.
Выработанные термы поступают на вход матрицы ИЛИ. Эти матрицы для
ПЛМ и ПМЛ различны. В ПЛМ матрица ИЛИ программируется, а в ПМЛ
она фиксирована.
б
Рис. 1.2. Классификация ПЛИС по архитектурным признакам (а)
и уровню интеграции (б)
Программируемая матрица ИЛИ микросхем ПЛМ составлена из дизъюнк -

торов, имеющих по q входов. На входы каждого дизъюнктора при програм-
мировании можно подать любую комбинацию имеющихся термов, причем
термы можно использовать многократно (т. е. один и тот же терм может
быть использован для подачи на входы нескольких дизъюнкторов).
Число дизъюнкторов в матрице ИЛИ определяет число выходов ПЛМ, ко-
торое обозначим через л.
Из изложенного видно, что ПЛМ позволяет реализовать систему из п пере-
ключательных функций, зависящих не более чем от m переменных и содер-
жащих не более чем q термов. Поэтому функциональные возможности ПЛМ
характеризуются тремя цифрами: m, q, n.
В ПМЛ выработанные матрицей И термы поступают на фиксированную (не-
программируемую) матрицу элементов ИЛИ. Это означает жесткое заранее
заданное распределение имеющихся термов между отдельными дизъюнкто -
рами. Каждому дизъюнктору придаются свои собственные термы, и если
для разных дизъюнкторов окажутся нужными одинаковые термы, придется
вырабатывать их в матрице И несколько раз. Однако при этом программи -
руемость матрицы ИЛИ исключается, что для многих задач в итоге сущест-
венно упрощает схему ПМЛ в сравнении со схемой ПЛМ.
ПЛМ обладают большей функциональной гибкостью, все воспроизводимые
ими функции могут быть комбинациями любого числа термов, формируе-
мых матрицей И. Это полезно при реализации систем переключательных
функций, имеющих большие взаимные пересечения по термам. Такие сис-
темы свойственны, например, задачам формирования сигналов управления
машинными циклами процессоров. Для широко распространенных в прак-
тике задач построения "произвольной логики" большое пересечение функций
по термам не типично. Для них программируемость матрицы ИЛИ исполь-
зуется мало и становится излишней роскошью, неоправданно усложняющей
микросхему. Поэтому ПМЛ распространены больше, чем ПЛМ, и к их чис-
лу относится большинство SPLD.
Структуры ПМЛ полнее освещены ниже при описании CPLD, составными
частями которых они служат. Более подробные сведения о ПЛМ и ПМЛ
имеются в ряде источников, в частности в [27].
В сложных программируемых логических схемах CPLD (Complex Program-
mable Logic Devices) несколько блоков, подобных ПМЛ, объединяются сред-
ствами программируемой коммутационной матрицы. В CPLD могут входить
сотни блоков и десятки тысяч эквивалентных вентилей. Архитектуры CPLD
разрабатываются фирмами Altera, Atmel, Lattice Semiconductor, Cypress
Semiconductor, Xilinx и др. Воздействуя на программируемые соединения
коммутационной матрицы и ПМЛ, входящих в состав CPLD, можно реали-
зовать требуемую схему.
Микросхемы программируемых пользователями вентильных матриц FPGA

(Field Programmable Gate Arrays) в своей основе состоят из большого числа
конфигурируемых логических блоков ЛБ, расположенных по строкам и
столбцам в виде матрицы, и трассировочных ресурсов, обеспечивающих их
межсоединения. В архитектуре FPGA явно прослеживается большое сходст-
во с архитектурой MPGA. Разница в том, что FPGA, поступающая в распо-
ряжение потребителя, имеет уже готовые, стандартные, хотя и не запро-
граммированные, трассировочные ресурсы, не зависящие от конкретного
потребителя. Получение конкретного проекта на базе FPGA, как и на осно-
ве других ПЛИС, реализуется воздействием на программируемые межсо-
единения, в ходе которого обеспечивается замкнутое состояние одних уча-
стков и разомкнутое — других. Обращаться к изготовителю FPGA при этом
не требуется.
Архитектуры FPGA разрабатываются фирмами Xilinx, Actel, Altera, Atmel,
Agere Systems (ранее Lucent Technologies), QuickLogic и др.
В течение первых лет развития ПЛИС они были представлены архитектура-
ми CPLD и FPGA в "чистом" виде. Каждая из этих архитектур имеет свои
достоинства и недостатки. Стремление к сочетанию достоинств CPLD и
FPGA и рост уровня интеграции БИС/СБИС привели к появлению ПЛИС с
комбинированной архитектурой. Класс ПЛИС с комбинированной архитек-
турой не имеет таких четких границ, как классы CPLD и FPGA, отличается
большим разнообразием вариантов и различной степенью близости к тому
или иному классическому типу ПЛИС. Не имеет он и общепринятого на-
звания. Тем не менее, представляется целесообразным рассматривать ПЛИС
с комбинированной архитектурой как отдельный класс, поскольку принад-
лежащие к нему схемы трудно квалифицировать как FPGA или CPLD, что
подтверждается и разнобоем в названиях, используемых для таких схем раз-
личными фирмами. Примером первых ПЛИС с комбинированной архитек-
турой могут служить микросхемы семейств FLEX8000 и FLEX10K фирмы
Altera (FLEX, Flexible Logic Element matriX).
Фактическое существование ПЛИС с комбинированной архитектурой и от-
сутствие для них общепринятого обобщающего названия вносят ощутимые
неудобства в процесс составления классификации ПЛИС. Зачастую ПЛИС
с комбинированной архитектурой представляются производителем под каким -
либо конкретным именем, в котором не упоминаются ни CPLD, ни FPGA.
Таких имен много, и на их основе не провести какую -либо классификацию.
Мы не считаем целесообразным вводить свои термины для обозначения
классов ПЛИС, т. к. сознаем, что общепризнанной окажется та терминоло-
гия, которая исходит от крупнейших фирм -производителей микросхем этого
типа. В то же время отнесение той или иной микросхемы в соответствую-
щий раздел описания или справочной таблицы требует определенности в
трактовке ее типа. Поэтому ниже наряду с узким применяется и широкое
толкование термина FPGA. При этом выделяются "классические" FPGA с их
канонической архитектурой, а ПЛИС комбинированной архитектуры при

необходимости (главным образом, при описании справочных данных) отно-
сятся к FPGA в широком смысле этого понятия. Обоснованием такого под-
хода служит то, что в комбинированных архитектурах черты FPGA обычно
проявляются более выраженно, чем черты CPLD. Правда, такой подход за-
ставляет применять к некоторым схемам термины, которые самими произ-
водителями не используются (это относится, в частности, к фирме Altera,
которая никогда не пользуется термином FPGA), но, по нашему мнению,
возникающие разночтения являются следствием только рекламно -маркетин -
говых соображений. Следует заметить, что авторы, не связанные с фирмой
Altera, этого правила придерживаются не всегда и называют некоторые мик-
росхемы данной фирмы термином FPGA [44]. Сказанное выше отображает-
ся на рис. 1.2, а объединением классических FPGA и ПЛИС с комбиниро-
ванными архитектурами общим прямоугольником из штриховых линий.
Термин SOPC (System On Programmable Chip), т. е. "система на программи-
руемом кристалле" относится к ПЛИС наибольшего уровня интеграции, со-
держащим сотни тысяч или даже миллионы эквивалентных вентилей. Такой
высокий уровень интеграции достигается только с помощью самых совре-
менных технологических процессов (малые топологические нормы проекти-
рования, многослойность систем металлизации и т. д.). На основе прогрес-
сивных технологических процессов обеспечивается одновременно высокий
уровень интеграции и высокое быстродействие БИС/СБИС. В результате
становится возможной интеграция на одном кристалле целой высокопроизво-
дительной системы.
Классификация по уровню интеграции (рис. 1.2, б) дана кратко и отражает,
главным образом, ситуацию последних годов — бурный рост уровня инте-
грации ПЛИС и выделение из них класса "системы на кристалле". В силу
связи между уровнем интеграции и архитектурой, классификация не являет-
ся строгой, и в ней имеется некоторое смешение двух признаков, однако
она принята в показанном виде ради соответствия практически сложившим-
ся понятиям.
ПЛИС с широким диапазоном изменения уровня интеграции (от простых
до содержащих сотни тысяч вентилей) отнесены к "досистемным" в том
смысле, что для них не рассматривались вопросы создания целых систем на
одном кристалле.
ПЛИС мегавентильного уровня интеграции отнесены к "системам на кри-
сталле", обозначаемым далее как SOPC (Systems On Programmable Chip). За-
метим, что для программируемых систем на кристалле разные фирмы, как
правило, используют свои обозначения (PSOC, CSOC, FIPSOC и т. д.), ре-
гистрируемые как товарные знаки. В разд. 1.10 данной главы, посвященном
справочным данным об ИС с программируемыми структурами, индивиду-
альные обозначения фирм сохранены. Для обобщающего термина принято
обозначение SOPC, введенное в обиход фирмой Altera.
Класс SOPC делится на подклассы однородных и блочных систем на кристалле.

В однородных SOPC различные блоки системы реализуются одними и теми
же аппаратными средствами, благодаря программируемоети этих средств.
При разработке систем используются так называемые "единицы интеллекту-
альной собственности" IP (Intellectual Properties), т. е. заранее реализованные
параметризируемые мегафункции для создания тех или иных частей систе-
мы. Все блоки системы при этом являются полностью синтезируемыми, пе-
ремещаемыми и могут располагаться в разных областях кристалла. Создание
IP стало важной сферой деятельности многих фирм, предлагающих на рын-
ке широкий спектр разнообразных решений. Заметим, что приобретение IP
обычно требует немалых затрат. Используя IP, проектировщик размещает на
кристалле нужные ему блоки, которые будем называть soft -ядрами (Softcores).
Блочные SOPC имеют аппаратные ядра, т. е. специализированные области
кристалла, выделенные для определенных функций. В этих областях созда-
ются блоки неизменной структуры, спроектированные по методологии ASIC
(как области типа БМК или схем со стандартными ячейками), оптимизиро-
ванные для заданной функции и не имеющие средств ее программирования.
Такие блоки будем называть hard -ядрами (Hardcores). Реализация функций
специализированными аппаратными ядрами требует значительно меньшей
площади кристалла в сравнении с реализациями на единых однородных про-
граммируемых средствах и улучшает другие характеристики схемы, в первую
очередь, быстродействие блоков, но уменьшает универсальность ПЛИС.
Снижение универсальности сужает круг потребителей ПЛИС, т. е. тираж -
ность их производства, что, в противовес факторам, удешевляющим схему,
ведет к их удорожанию. Преобладание того или иного из указанных факто-
ров зависит от конкретной ситуации.
Кристаллы, содержащие как области ПЛИС, так и области ASIC, в различ-
ных источниках именуются по -разному. В сетевом журнале Electronic Design
News встречается термин "гибридные", по смыслу близкий к принятому нами
термину "блочные" (мы воздержались от термина "гибридные" в силу тради-
ции, по которой этот термин применялся для схем со смешанными цифро-
выми и аналоговыми сигналами).
Сейчас на рынке появилось большое число различных SOPC, и среди них
наметились свои подклассы и проблемные ориентации. Не пытаясь деталь-
но классифицировать все варианты, целесообразно разделить блочные SOPC
хотя бы на две группы: имеющие аппаратные ядра процессоров и не имеющие
их. Первые представляют БИС/СБИС по -настоящему универсальные, т. к.
содержат полный комплект блоков, характерных для микропроцессорной
системы (имеется в виду цифровая часть системы, но следует отметить, что
у некоторых SOPC есть и аналоговые блоки для ввода, предварительной об-
работки и последующей оцифровки аналоговых сигналов). Вторые специа-
лизированы и ориентированы на те или иные конкретные приложения. Но
и здесь нужно отметить наличие у некоторых SOPC второго типа интер-

фейсных средств для сопряжения с процессором и ОЗУ различных типов,
что облегчает построение целостных систем с применением таких SOPC.
Классификация по признаку кратности программирования, определяемой
типом памяти конфигурации (называемой также теневой памятью), приве-
дена на рис. 1.3.
Р и с . 1.3. Классификация ПЛИС по признакам кратности программирования

(по типу теневой памяти)
В однократно программируемых ПЛИС используются элементы с необра-

тимыми изменениями состояний — специальные перемычки или ЛИЗМОП -
транзисторы. ЛИЗМОП -транзисторы имеют заряжаемые "плавающие" затво-
ры, которые, в общем случае, могут как заряжаться, так и разряжаться. Для
однократно программируемых ПЛИС возможности ЛИЗМОП -транзисторов
используются лишь частично: для них применяются такие конструкции,

в которых отсутствуют возможности стирания записанной информации.
В простых ПЛИС первых поколений применялись плавкие перемычки типа
fuse. В таких ПЛИС в исходном состоянии имеются все возможные соеди-
нения, а для получения требуемой конфигурации схемы часть перемычек
разрушается (пережигается). При программировании плавких перемычек
возникает определенный процент брака, кроме того, со временем проводи-
мость разрушенной перемычки может восстановиться из -за явления элек-
тромиграции в материалах. В течение многих лет велась большая работа по
подбору материалов перемычек и усовершенствованию технологических
процессов программирования, тем не менее для ПЛИС высокого уровня
интеграции схемы с плавкими перемычками не подошли.
В однократно программируемых FPGA нашли применение пробиваемые пе-
ремычки типа antifuse. В исходном состоянии сопротивления перемычек
чрезвычайно велики, а в пробитом достаточно малы. Перемычки очень
компактны — их площадь близка к площади пересечения двух дорожек
межсоединений. Паразитные емкости перемычек также очень малы. Боль-
ших успехов в разработке техники пробиваемых перемычек добились фирмы
Actel (перемычки типа ONO), QuickLogic (перемычки ViaLink), Crosspoint
Solution (кремниево -аморфные перемычки) и Xilinx (перемычки MicroVia).
В третьем варианте (с плавающими затворами) роль программируемых эле-
ментов играют однозапгворные ЛИЗМОП -транзисторы, а кристаллы микро-
схем размещаются в дешевых корпусах, не имеющих специальных окошек
для стирания информации (зарядов в плавающих затворах). Для транзисто-
ров с одним (плавающим) затвором и каналом р -типа до программирования
затвор не имеет заряда, и транзистор заперт. Введение в затвор заряда элек-
тронов приводит к возникновению в транзисторе проводящего канала. Заряд
в плавающем затворе сохраняется в течение десятков лет. Память конфигу-
рации с элементами описанного типа называют EPROM -OTP (Electrically
Programmable Read -Only Memory — One Time Programmable). Однозатворные
ЛИЗМОП -транзисторы компактны и дешевы.
Микросхемы с возможностями многократного программирования со стирани-
ем и записью конфигурации в специальных режимах также используют про-
граммируемые элементы в виде ЛИЗМОП -транзисторов. От предыдущего
варианта эти микросхемы отличаются наличием средств стирания записан-
ной в память информации.
Информация в элементах памяти типа EPROM стирается с помощью облу-
чения кристалла ультрафиолетовыми лучами, что отражается в русском тер-
мине для этой памяти — РПЗУ -УФ (репрограммируемые запоминающие
устройства с ультрафиолетовым стиранием). Кристалл со стертой конфигу-
рацией можно запрограммировать вновь. Стирание конфигурации занимает
десятки минут, а число циклов репрограммирования ограничено величина -
4£ Проектирование систем на микросхемах программируемой логики
ми порядка десятков-сотен, т. к. ультрафиолетовое облучение постепенно

изменяет свойства кристалла.
В репрограммируемых ПЛИС с памятью конфигурации типа EEPROM
(Electrically Erasable Programmable Read -Only Memory) стирание старых дан-
ных осуществляется электрическими сигналами. Используются двухзатвор -
ные ЛИЗМОП -транзисторы. Управление процессами в транзисторе произ-
водится с помощью двух затворов — обычного и плавающего. При опреде-
ленных сочетаниях программирующих напряжений на внешних выводах
транзистора (плавающий затвор внешнего вывода не имеет) создаются ре-
жимы как заряда плавающих затворов, так и их разряда. В русской терми-
нологии память типа EEPROM называют РПЗУ -ЭС (репрограммируемые
запоминающие устройства с электрическим стиранием). Электрическое сти-
рание содержимого памяти не требует извлечения микросхем из устройства,
в котором они используются. Число допустимых циклов репрограммирова -
ния хотя и ограничено, но на порядки превышает соответствующие числа
для памяти с ультрафиолетовым стиранием информации и составляет
105 -10 6 . Элементы памяти с электрическим стиранием вначале заметно про-
игрывали элементам с ультрафиолетовым стиранием по площади, занимаемой
на кристалле, но быстро совершенствуются и становятся преобладающими
для класса ПЛИС со стиранием конфигурации в специальных режимах.
К памяти типа EEPROM близка память конфигурации типа Flash. Запоми-
нающие элементы по своему принципу действия у обоих видов памяти
идентичны — это ЛИЗМОП с двумя затворами и электрическим стиранием
информации. Различия имеются в организации процессов записи и стира-
ния данных и, кроме того, при разработке Flash -памяти достигнут особенно
высокий уровень параметров (быстродействия, уровня интеграции, надеж-
ности и др.). Разработку Flash -памяти считают кульминационным пунктом
десятилетнего развития памяти типа EEPROM. В современных ПЛИС нахо-
дят применение обе разновидности памяти конфигурации с электрическим
стиранием данных.
Последний класс ПЛИС по второму признаку принятой классификации —
оперативно репрограммируемые. В таких ПЛИС конфигурация задается с по-
мощью загрузки файла в "теневую" триггерную память, т. е. операций, не
имеющих какого -либо специального характера. В противоположность пре-
дыдущим вариантам для программирования не нужны ни специальные
программаторы, ни специальные режимы с повышенными напряжениями и
длительностями воздействий на элементы памяти. Память конфигурации —
обычная статическая (триггерная), т. е. типа SRAM, Static Random Access
Memory. Загрузка памяти производится с высокой скоростью, свойственной
статической триггерной памяти, последовательным потоком битов или бай-
тов. Элементом с программируемой проводимостью (режимом "замкнуто -
разомкнуто") служит обычный МОП -транзистор, управляемый триггером
памяти конфигурации (теневой памяти). Состояние триггера задает режим
ключевому транзистору. Программирование соединения сводится к установке
триггера в состояние 0 или 1. В рабочем режиме триггер сохраняет неизмен-

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

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

процентом выхода годных микросхем при их производстве вследствие
достаточно регулярной структуры.
- Высокое быстродействие и надежность как следствие реализации на базе
передовых технологий и интеграции сложных устройств на одном кри-
сталле.
- Разнообразие конструктивного исполнения, поскольку обычно одни и те
же кристаллы поставляются в разных корпусах.
- Разнообразие в выборе напряжений питания и параметров сигналов вво-
да/вывода, а также режимов снижения мощности, что особенно важно
для портативной аппаратуры с автономным питанием.
- Наличие разнообразных, хорошо развитых и эффективных программных
средств автоматизированного проектирования, малое время проектирова-
ния и отладки проектов, а также выхода продукции на рынок.
- Простота модификации проектов на любых стадиях их разработки.
Для новейших вариантов ПЛИС с динамическим репрограммированием
структур кроме важных с общих позиций свойств следует назвать и допол-
нительную специфическую черту: возможность построения на базе динами-
чески репрограммируемых микросхем новых классов аппаратуры с многофунк-
циональным использованием блоков.
1.2. CPLD — сложные программируемые

логические устройства
1.2.1. Структура CPLD
CPLD — микросхемы высокого уровня интеграции, основными частями ко-
торых являются:
- PAL (GAL) — подобные функциональные блоки;
- система коммутации, позволяющая объединять функциональные блоки
в единое устройство, выполненная в виде матрицы соединений.
- блоки ввода/вывода.
Все составные части CPLD программируются. Обобщенная структура CPLD
показана на рис. 1.4.
В структурной схеме приняты следующие обозначения. Через ФБ (FB) обо-
значены функциональные блоки, число которых N зависит от уровня инте-
грации микросхемы и изменяется в довольно широких пределах. В каждом
ФБ имеется п макроячеек МЯ (МС, Macrocells). Функциональные блоки по-
лучают входные сигналы от программируемой матрицы соединений ПМС
(PIA, Programmable Inerconnect Array). Число таких сигналов т. Выходные

сигналы ФБ поступают как в ПМС, так и в блоки ввода/вывода CPLD (IOBs,
Input/Output Blocks, БВВ). ПМС обеспечивает полную коммутируемость
функциональных блоков, т. е. возможность подавать сигналы с любого их
выхода на любой вход.
Рис. 1.4. Обобщенная структура CPLD
Блоки ввода/вывода связаны с внешними двунаправленными выводами I/O,

которые, в зависимости от программирования, могут быть использованы как
входы или как выходы. Три нижних вывода либо специализируются для по-
дачи на матрицу функциональных блоков сигналов GCK (Global Clocks)
глобального тактирования, сигналов GSR (Global Set/Reset) глобальной уста-
новки/сброса и сигналов GTS (Global 3 -state Control) глобального управле-
ния третьим состоянием выходных буферов, либо эти же выводы могут быть
использованы для операций ввода/вывода. Здесь и далее термин "глобаль-
ный" применяется для сигналов, общих для всей микросхемы.
Число контактов ввода/вывода может совпадать с числом выходов всех ФБ,
но может быть и меньшим. В последнем случае часть макроячеек может
быть использована только для выработки внутренних сигналов устройства
(в частности, сигналов обратной связи). Необходимость в таких сигналах

типична для структур большинства цифровых устройств.
Структура на рис. 1.4 несколько упрощена. Кроме показанных блоков в
CPLD могут присутствовать контроллеры для управления операциями про-
граммирования непосредственно в системе (In System Programmability, ISP),
контроллеры для работы с интерфейсом JTAG и др. Вопросы, связанные
с использованием интерфейса JTAG и программированием в системе ISP,
рассмотрены в разд. 2.6.
1.2.2. Программируемая матрица соединений

В программируемой матрице соединений ПМС (рис. 1.5, а) выходы функ-
циональных блоков ФБ подключаются к вертикальным непрерывным (не
сегментированным) линиям, причем каждому выходу соответствует своя ли-
ния. Входы ФБ связаны с горизонтальными линиями, пересекающими все
вертикальные линии. На пересечениях горизонтальных и вертикальных ли-
ний имеются программируемые точки связи, так что любой вход ФБ может
быть подключен к любому выходу, чем обеспечивается так называемая пол-
ная коммутируемость блоков.
Достоинством ПМС рассмотренного типа является малая и предсказуемая
задержка коммутируемых сигналов, т. к. для каждого соединения образуется
идентичный всем другим канал связи с малым числом программируемых
ключей или даже их отсутствием, если передача сигналов из ПМС в ФБ
организована так, как показано на рис. 1.5, б. В этом случае программируе-
мых ключей в цепи передачи сигнала нет, программируются только напря-
жения на нижних входах конъюнкторов, и ФБ получит сигнал от i-й верти-
кальной линии ПМС (i= 1, 2, ..., m), если транзистор Т, будет заперт, и на
нижнем входе i -го конъюнктора будет действовать высокий потенциал логи-
ческой единицы. Открытый транзистор Т, подключает нижний вход конъ-
юнктора к нулевому потенциалу, создавая на нем и на выходе конъюнктора
сигнал логического нуля. Таким образом, задавая триггеру Т, состояние ло-
гического нуля, а остальным триггерам состояние логической единицы,
можно обеспечить закрытое состояние транзистора Т, и открытое состояние
всех других транзисторов, что означает подключение выхода ФБ к i-й вер-
тикальной линии ПМС с образованием так называемого непрерывного со-
единения.
Замкнутые транзисторные ключи имеют, в первом приближении, схему за-
мещения в виде инерционной RC -цепи и вносят основные задержки в про-
цесс распространения сигнала.
Программируемые матрицы соединений типа показанной на рис. 1.5, а эф-
фективны в схемах с относительно небольшим числом коммутируемых бло-
ков. При большом их числе, характерном, например, для FPGA, подобные
от ПМС
кФБ
б
Рис. 1.5. Схема программируемой матрицы соединений CPLD (а)
и схема передачи сигналов из этой матрицы в функциональный блок (б)
ПМС были бы чрезмерно сложны, поскольку любое соединение образуется

с помощью линий связи, проходящих по всей длине и ширине схемы, тогда
как очень многие связи локальны и соединяют близлежащие блоки. Поэто-
му в FPGA системы коммутации строятся иначе — с помощью сегментиро-
ванных линий связи.
1.2.3. Функциональные блоки CPLD

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

руемая матрица элементов И (М н ), матрица распределения термов МРТ и
группа из нескольких (N) макроячеек. По существу, каждый ФБ представ-
ляет собою PAL -подобную структуру с некоторыми отличиями от вариан-
тов, используемых в простых PLD (ПМЛ). Как и в классических PLD,
в блоке имеется многовходовая (Wide) матрица М и , вырабатывающая конъ-
юнктивные термы для их использования в последующих частях блока.
В классических PLD типа ПМЛ термы жестко распределяются между дизъ -
юнкторами, формирующими выходные функции в форме ДНФ. Совокуп-
ность дизъюнкторов образует фиксированную (не программируемую) мат-
рицу элементов ИЛИ. На рис. 1.7, а показан один из дизъюнкторов (для
канала с номером i ) , вырабатывающий функцию, в которую может входить
не более 5 термов.
Разделяемый
ЛР
б
Рис. 1.7. Схема выработки ДНФ логической функции в простейшем варианте CPLD (а)
и логические расширители параллельного и последовательного типов (б)
48 _ Проектирование систем на микросхемах программируемой логики
В CPLD матрица элементов ИЛИ чаще всего не является полностью фикси-

рованной, и благодаря введению в схему матрицы распределения термов
МРТ, возможно варьирование числа термов в вырабатываемой функции Fi.
При этом термы заимствуются у других каналов выработки функций или
отдаются им. Проще всего организовать коммутацию термов между сосед-
ними каналами. Через соседние каналы путем образования цепочечных свя-
зей можно собирать в одном канале много термов (в пределах одного функ-
ционального блока). Если термы используются не только дизъюнкторами
формирования выходных функций, но и другими элементами ФБ, то и для
них МРТ играет роль "раздатчика термов".
Схемотехнически в операциях распределения термов по каналам ФБ задей-
ствованы как непосредственно цепи коммутации между входами и выходами
МРТ, так и логические расширители последовательного и параллельного
типов. Последовательные (разделяемые, общие) логические расширители соз-
даются подачей инвертированного значения терма из МРТ данного канала
обратно на один из входов матрицы Ми (рис. 1.7, б). Переданный в матрицу
Ми терм становится доступным для использования во всех каналах данного
ФБ. Если, например, этот терм запрограммирован как q = x1!x2x5!x10, т. е.
его инверсия есть !q = !(xl!x2x5!x10) = !xlvx2v!x5vx10, то в том канале, где он
будет использован вместе с входными термами канала, например, q1, q2, q3,
будет получена функция
F= qlvq2vq3v!xlvx2v!x3vx10 = q1vq2vq3v!(xl!x2x5!xl0).
Параллельный расширитель позволяет передавать термы одного канала дру-
гому. Способность принимать в свой канал термы от соседнего канала
обычно означает и возможность приема через него термов и более далеких
каналов с образованием цепочки для сбора термов от нескольких каналов
(например, в пределах целого функционального блока). Можно, естествен-
но, и отдавать собственные термы или их часть другим каналам (в част-
ности, соседним, а через них и более далеким).
Термы от МРТ поступают далее на часть ФБ, называемую макроячейкой
(МЯ). Макроячейка содержит в качестве основы программируемые мульти-
плексоры, триггер (или триггеры) и формирует группу выходных сигналов
ФБ в нескольких их вариантах.
Термин "макроячейка" трактуется в разных источниках по -разному. Наряду с
указанным определением встречаются и такие, согласно которым макроячей-
кой называют часть ФБ, содержащую все его последовательно включенные
части (группу элементов И, МРТ и все последующие элементы, относящиеся
к данному каналу выработки выходных функций).
На рис. 1.8 раскрыта схема одной из идентичных макроячеек ФБ. Прообра-

зом показанной схемы является макроячейка CPLD XC9500 фирмы Xilinx,
не имеющая разделяемого (общего) логического расширителя.
GSR GCK
Обмен термами
с вышележащей
макроячейкой
Обмен термами
с нижележащей
макроячейкой
Рис. 1.8. Пример схемы макроячейки функционального блока CPLD
Программируемость мультиплексоров в этой схеме и всех дальнейших не

отображается, т. к. она присуща всем имеющимся в схеме мультиплексорам,
если не оговорено противоположное. В зависимости от программирования
каждый мультиплексор передает на выход сигнал с того или иного входа.
Триггер может программироваться на режимы работы триггера типа D или
Т. Заметим, кстати, что при описании микросхем профаммируемой логики
триггеры в иностранной литературе чаще всего называют регистрами. Триг-
геры тактируются положительными фронтами синхросигналов и имеют вхо-
ды установки S и сброса R. Выходные сигналы ФБ передаются в ПМС и
в блоки ввода/вывода БВВ.
Аргументы х1, ..., хМ реализуемой макроячейкой функции поступают на
матрицу Ми из ПМС. Аргументами для МЯ могут быть как входные сигна -
лы, поступающие извне через БВВ, так и сигналы обратных связей, пода-
ваемые в матрицу И с выходов макроячеек. На рис. 1.8 входные сигналы
матрицы независимо от их характера обозначены через x1, ..., хМ. Входные
буферы преобразуют сигналы в парафазные, представляя каждый сигнал его
прямым и инверсным значениями, так что в матрице имеется 2т вертикаль-
ных линий и образующие ее конъюнкторы имеют по 1т входов. Пять тер-
мов из матрицы И поступают на элемент ИЛИ для образования логической
функции. Для управления триггером и буферами блока ввода/вывода выра-
батываются также термы PTSet, PTClock, PTReset, которые могут быть ис-
пользованы как сигналы установки, синхронизации и сброса триггера. Терм
РТОЕ — программируемый терм управления третьим состоянием буфера
БВВ (ОЕ, Output Enable). Всего в матрице И на рис. 1.8 программируются
9N термов.
На выходе элемента ИЛИ вырабатывается логическая функция в форме
ДНФ ранга не более т. Ее значение передается дальше через элемент сло-
жения по модулю 2, на второй вход которого, в зависимости от программи-
рования мультиплексора 1, может быть подан логический нуль, логическая
единица или терм РТ1. В первом случае функция передается без изменений
(F= F*), во втором инвертируется (F= !F*), в третьем передается в прямом
виде во всех ситуациях за исключением такой, в которой РТ1 = 1.
Мультиплексор MUX5 программируется для передачи на выход МЯ либо
непосредственно значения функции F (комбинационный выход), либо со-
стояния триггера (регистровый выход). Характер тактирования триггера оп-
ределяется программированием мультиплексора MUX4, при этом возможно
использование глобального синхросигнала (GCK, Global Clock) или сигнала,
порождаемого термом PTClock. Асинхронные установка и сброс триггера
производятся либо глобальным сигналом (GSR, Global Set/Reset), либо тер-
мами PTSet и PTReset, что определяется программированием мультиплексо-
ров MUX2 и MUX3. Сам триггер программируется на режимы триггера за-
держки (типа D) или счетного (типа Т).
Основной выходной сигнал макроячейки поступает как в ПМС, которая
может направлять его по любому требуемому маршруту, так и в блоки вво-
да/вывода.
1.2.4. Блоки ввода/вывода CPLD

Блоки ввода/вывода соединяют внешние контакты микросхемы с ее внут-
ренними цепями. Характерным примером такого блока может служить БВВ
CPLD типа ХС9500 фирмы Xilinx, показанный на рис. 1.9.
Основой БВВ служат два буфера — входной (1) и выходной (2). Чтобы обес-
печить постоянство уровней напряжения, поступающих на входной буфер, и
их независимость от амплитуды входных сигналов, в схеме вырабатывается
и
внутреннее напряжение питания VCCINT вводится цепь из двух фикси-
рующих диодов.
Рис. 1.9. Пример схемы блока ввода/вывода CPLD
Схема программируемой общей точки ПрОТ позволяет пользователю при

необходимости получать дополнительный "заземленный" вывод. Дополни-
тельные выводы для системы "заземления" повышают ее качество и тем са-
мым снижают уровень помех в микросхеме.
Схема программирования подключаемого резистора ПрР введена для ис-
ключения плавающих потенциалов на контактах ввода, когда они не ис-
пользуются в рабочем режиме. В этом случае контакту задается высокий по-
тенциал от цепи VCCINT — R. Резистор R используется и в некоторых других
режимах, а в рабочих режимах отключается.
Выходной буфер 2 получает сигналы разрешения работы ОЕ и управления
крутизной фронта выходного напряжения SRC (Slew Rate Control). Сигнал
ОЕ с помощью программируемого мультиплексора MUX3 вырабатывается

в нескольких вариантах: от терма РТОЕ, получаемого от макроячейки, от
любого из глобальных сигналов управления третьим состоянием (GOE1,
GOE2), от константы 1 и от константы 0. Глобальные сигналы управления
третьим состоянием образуются с возможностью выбора любой полярности
исходных сигналов GTS1 и GTS2.
Выходные буферы конфигурируются для работы с напряжениями питания
5 или 3,3 В при подключении внешнего источника питания с тем или иным
уровнем напряжения (эти цифры относятся к рассматриваемому блоку типа
ХС9500, сейчас у блоков ввода/вывода нередко уровни выходных сигналов
могут выбираться из многих возможностей, в том числе из таких низких на-
пряжений, как 2,5 и 1,8 В).
Согласно принятой нами классификации в класс CPLD попадают ПЛИС
с уровнем интеграции 600—20 000 эквивалентных вентилей, числом макро-
ячеек 32—512, числом функциональных блоков 2—16 и временем распро-
странения сигнала от любого входа до любого выхода 5—20 не. Эти CPLD
представлены, в частности, такими популярными семействами микро-
схем, как МАХ7000 и МАХЗОООА фирмы Altera, XC9500 фирмы Xilinx,
МАСН1...МАСН5 фирмы Lattice Semiconductor (ранее семейства МАСН вы-
пускались известной фирмой AMD, позднее подразделение этой фирмы
Vantis вместе с производством указанного семейства было приобретено
фирмой Lattice Semiconductor). В схемах CPLD используется энергонезави-
симая память конфигурации, причем доминирует память типа EEPROM или
Flash. Энергонезависимость памяти конфигурации облегчает засекречивание
проектов, т. к. не требует загрузки внешних данных конфигурации, которые
доступны для чтения. Содержимое памяти конфигурации на самом кристал-
ле обычно защищается специальным битом секретности, сбросить который
можно лишь при стирании всего содержимого памяти.
1.3. FPGA — программируемые пользователем

вентильные матрицы
1.3.1. Основные сведения
В наиболее типичном варианте FPGA представляет собою микросхему вы-
сокого уровня интеграции, содержащую во внутренней области матрицу
идентичных функциональных блоков и систему их межсоединений, разме-
щенную между строками и столбцами матрицы, а в периферийной облас-
ти — блоки ввода/вывода (рис. 1.10, а). Кроме этого варианта существуют
FPGA, в которых функциональные блоки расположены по строкам (строко-
вые FPGA), однако рассматривать эти варианты отдельно нет оснований,
поскольку существенные черты FPGA остаются одинаковыми для обоих ва-
риантов.
БВВ
LUT
RG
MUXs
Области
межсоединений
a
Рис. 1.10. Обобщенная структура FPGA (а)
и основные части их функциональных блоков (б)
Все части FPGA (функциональные блоки ФБ, система межсоединений и

блоки ввода/вывода БВВ) являются конфигурируемыми или реконфигури -
руемыми, причем (в отличие от БМК) средствами самих пользователей.
Перечисленные части — основа FPGA. Кроме них современные варианты
FPGA, как правило, оснащены дополнительными средствами для автопод-
стройки задержек в системе тактирования (PLL, Phase Locked Loop или
DLL, Delay Locked Loop), средствами поддержки интерфейса JTAG и др.
При конфигурировании FPGA функциональные блоки настраиваются на
выполнение необходимых операций преобразования данных, а система меж-
соединений — на требуемые связи между функциональными блоками. В ре-
зультате во внутренней области FPGA реализуется схема нужной конфигу-
рации. Расположенные по краям кристалла блоки ввода/вывода обеспечи-
вают интерфейс FPGA с внешней средой. Блоки ввода/вывода современных
FPGA можно программировать на выполнение требований множества стан-
дартов передачи данных (число таких стандартов может доходить до 20).
На рис. 1.10, б укрупненно показан состав типичного функционального
блока ФБ, в который входят функциональный преобразователь ФП, реа-
лизованный в виде программируемого запоминающего устройства (LUT,
Look -Up Table), триггер (регистр) и мультиплексоры, играющие роль средств
конфигурирования ФБ.
LUT — наиболее распространенная разновидность ФП в FPGA со стати-

ческой памятью конфигурации. В схемах FPGA с однократным программи-
рованием перемычек находят применение ФП в виде простых логических
вентилей (SLC, Simple Logic Cell) и логических модулей на основе мульти-
плексоров [27].
1.3.2. Функциональные блоки FPGA

Табличный ФП типа LUT представляет собою запоминающее устройство,
хранящее значения искомых функций, считываемые по адресу -аргументу.
Запоминающее устройство с организацией 2m *n имеет m адресных входов и
я выходных линий. В таком запоминающем устройстве можно хранить таб-
лицу для считывания я функций от m переменных, поскольку каждый раз-
ряд хранимого массива данных можно рассматривать как столбец значений
переключательной функции. В память можно записывать любые числа, и,
следовательно, разрядные столбцы этих чисел могут воспроизводить любые
функции m переменных. Время вычисления результата не зависит от вос-
производимой функции и равно времени считывания слова из памяти.
Второй тип ФБ — схема, основой которой служат программируемые мульти-
плексоры (фирма Actel и др.). В этих ФБ выходная величина описывается
некоторой так называемой порождающей функцией, соответствующей ис-
пользованию всех входов схемы как информационных. При программиро-
вании на некоторые входы задаются константы 0 и 1, разные сочетания ко-
торых порождают целый спектр возможностей воспроизведения логических
функций. Подробнее о таких возможностях говорится в работах [27, 30 и др.].
Третий тип ФБ — так называемые "мелкозернистые", блоки, составленные,
чаще всего, из транзисторных пар, выделяемых из цепочек транзисторов
с п - и р -каналами. Из таких пар собираются традиционные для КМОП -схем
логические элементы, методы синтеза которых традиционны.
Типичную структуру ФБ FPGA с триггерной памятью -конфигурации рас-
смотрим на примере микросхемы семейства Spartan фирмы ХШпх (рис. 1.11).
Фирма ХШпх изобрела и активно разрабатывает оперативно реконфигури -
руемые FPGA, ее продукция занимает 30—40% мирового рынка ПЛИС. По-
сле семейства Spartan фирма выпустила семейство Spartan II, но нами для
иллюстрации особенностей FPGA выбрано первое из этих семейств, т. к.
второе по схемотехнике блоков аналогично семействам Virtex и Virtex E,
рассмотренным ниже.
По своей структуре микросхемы Spartan продолжают линию развития клас-
сических FPGA, популярным представителем которой является семейство
ХС4000 той же фирмы. В функциональных блоках этих микросхем логиче-
ские преобразования выполняются тремя LUT -блоками (функциональными
преобразователями ФП) G, F и Н. Преобразователи G и F — программи -
руемые запоминающие устройства (ЗУ) с организацией 16x1, способные

воспроизводить любые функции четырех переменных, значения которых
могут быть переданы на выходы Y и X через мультиплексоры 4 и 6 при со-
ответствующем их программировании (через линии вфхних входов мульти-
плексоров).
Рис. 1.11. Пример схемы функционального блока FPGA
Заметим, что на рисунках, как и ранее, в обозначениях мультиплексоров не

отражена их программируемость, поскольку все они без исключения обла-
дают этим свойством.
Через верхний вход мультиплексора 1 и нижний вход мультиплексора 2
функции G и F могут быть поданы на ФП -Н (ЗУ с организацией 8x1) для
образования "функции от функций" с целью получения результирующей
функции, зависящей от более чем четырех аргументов. К третьему входу
ФП -Н подключен входной сигнал HI, так что Н = / ( G , F, HI). Аргумента-
ми для ФП -Н, поступающими от мультиплексоров 1 и 2, в зависимости от
их программирования может быть не только набор G, F, HI, но также набо-

ры G, HI, DIN; SR, HI, DIN; SR, HI, F. Линии DIN и SR используются
либо для передачи в триггер непосредственно входных данных и сигнала
установки/сброса (Set/Reset), либо как входы ФП -Н.
Перечисленные ресурсы логической части ФБ позволяют воспроизводить:
- любую функцию с числом аргументов до 4 включительно плюс вторую
такую же функцию плюс любую функцию с числом аргументов до трех;
- любую функцию 5 аргументов (одну);
- любую функцию 4 аргументов и одновременно некоторые функции 6 ар-
гументов, некоторые функции с числом аргументов до 9.
Сигналы HI, DIN, SR, ЕС являются для ФБ входными, они подаются на его
внутренние схемы через группу из четырех мультиплексоров MUX "4—1" (на
рисунке не показаны), к которым подключены 4 линии внешней шины
управления С1...С4. Это позволяет распределять сигналы HI, DIN, SR и ЕС
по линиям С1...С4 в любом желаемом варианте.
Мультиплексоры 3...6 направляют те или иные сигналы данных управления
на триггеры 1 и 2. Триггеры могут использоваться для фиксации и хранения
выходных сигналов функциональных преобразователей или же работать не-
зависимо от них. Входной сигнал ФБ DIN может быть прямым входом для
любого триггера. Сигнал HI тоже можно передавать любому триггеру, но
через ФП Н, что вносит в цепь его передачи некоторую задержку.
Оба триггера имеют общие входы СК тактирования от сигнала К, разреше-
ния тактирования ЕС и установки/сброса SR. Внутренние программируемые
цепи в схеме триггера (на рис. 1.11 не показаны) позволяют индивидуально
программировать полярность тактирующего сигнала СК. Сигнал ЕС син-
хронизирован с сигналом СК, сигнал SR асинхронный и для каждого триг-
гера с использованием внутренних цепей триггера программируется как
сигнал установки или сброса. Этот сигнал определяет состояние, в котором
окажется триггер после процесса конфигурации микросхемы. Конфигурация
определяет и характер воздействия на триггеры импульсов GSR (Global SR)
и SR при работе схемы.
1.3.3. Блоки ввода/вывода FPGA

Блоки ввода/вывода, показанные на примере микросхем семейства Spartan
фирмы Xilinx (рис. 1.12), обеспечивают интерфейс между выводами корпуса
FPGA и ее внутренними логическими схемами. Каждому выводу корпуса
придается блок ввода/вывода БВВ, который может быть конфигурирован
как вход, выход или двунаправленный вывод.
Рис. 1.12. Пример схемы блока ввода/вывода FPGA
Работа БВВ как выходного блока обслуживается следующими элементами:

выходным буфером 1, триггером 1, мультиплексорами 1, 2, 5 и логической
схемой ИЛИ. Выводимый сигнал О можно получать в прямой или инверс-
ной форме в зависимости от программирования мультиплексора 2. Этот
сигнал может передаваться на выходной буфер непосредственно или сни-
маться с триггера при соответствующем программировании мультиплексо -
ра 5. Сигналы Т и GTS (Global Tri -State), согласно логике ИЛИ, управляют

переводом буфера в третье состояние, причем активный уровень сигнала Т
программируется с помощью мультиплексора 1. Внутренние программируе-
мые цепи триггера (на рисунке не показаны) позволяют изменять поляр-
ность тактирующего фронта. Сам буфер имеет программируемые крутизну
фронта выходного сигнала и его уровни (КМОП/ТТЛ). Крутизна фронтов в
некритичных к скорости передачи цепях снижается для уменьшения уровня
помех на шинах питания и земли. Используется так называемый мягкий
старт (Soft Start -Up), снижающий помехи при конфигурировании схемы и
переходе ее к рабочему режиму, когда одновременно активизируются мно-
гие буферы. Первая активизация автоматически происходит с пологими
фронтами перепадов напряжения. Затем вступает в силу заданный выбор
той или иной крутизны фронтов в зависимости от принятой конфигурации
БВВ.
Тракт ввода сигналов содержит входной буфер 2, триггер 2, программируе-
мые мультиплексоры 3, 4, 6, элемент задержки ЭЗ и программируемые схе-
мы задания определенных потенциалов выводу, к которому не подключен
вводимый или выводимый сигнал (схемы Pull -Up/Pull -Down). Вводимый
сигнал в зависимости от программирования мультиплексоров 3 и 4 или по-
ступает непосредственно в систему коммутации FPGA по входным линиям
II и 12, или же фиксируется триггером и с его выхода передается в эти ли-
нии. Триггеры могут конфигурироваться как тактируемые фронтом или как
защелки (D -триггеры, управляемые уровнем). Выбор осуществляется при-
своением триггеру соответствующего библиотечного символа. В цепи пере-
дачи сигнала на триггер 2 могут быть включены элементы задержки (при
передаче сигнала через нижний вход мультиплексора 6). Включение задерж-
ки гарантирует необходимые временные соотношения между входными сиг-
налами триггера D и глобальным сигналом тактирования.
Входной буфер может конфигурироваться для восприятия входных сигналов
с пороговым значением ТТЛ (1,2 В) или КМОП (0,5 U c c ). Выходные уровни
тоже конфигурируются, две глобальные регулировки входных порогов и вы-
ходных уровней независимы.
1.3.4. Системы межсоединений

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

правило, иерархический характер, и в ней сочетаются различные типы сег-
ментов (основные связи, связи двойной длины, прямые связи для близле-
жащих функциональных блоков, длинные линии, пересекающие кристалл
по всей его длине или ширине).
Систему межсоединений FPGA образуют сегментированные линии и пере-
ключательные блоки ПБ (PSM, Programmable Switching Matrix). Функцио-
нальные блоки имеют квадратные геометрические очертания, их выводы
распределены по всем сторонам квадрата для облегчения коммутируемости.
Для межсоединений функциональных блоков во внутренней области кри-
сталла имеются три типа связей: одинарной длины, двойной длины и длин-
ные линии. Упрощенная система коммутации FPGA показана на рис. 1.13, а
на примере FPGA семейства ХС4000 фирмы Xilinx.
На пересечениях вертикальных и горизонтальных каналов расположены пе-
реключательные блоки (рис. 1.13, б). В пределах ПБ пересекаются верти-
кальные и горизонтальные линии связей, и в каждом пересечении имеется
цепь из 6 транзисторов для установления того или иного соединения. Сиг-
нал, поступающий в ПБ по какой -либо линии (например, горизонтальной),
может быть направлен вверх, вниз или прямо в зависимости от того, какой
транзистор будет открыт при конфигурировании FPGA. Возможна и одно-
временная передача сигнала по нескольким направлениям, если требуется
его разветвление.
Линии одинарной длины осуществляют, преимущественно, межсоединения
соседних или близлежащих ФБ, линии двойной длины огибают переключа-
тельные блоки, соседние по отношению к данному, и проходят к следую-
щим, чем облегчается установление более длинных связей. По три длинных
линии, пересекающих весь кристалл по длине (ширине), реализуются свер-
ху, снизу и по обоим бокам ФБ.
Выводы функциональных блоков пересекают горизонтальные и вертикаль-
ные каналы трассировки, проходящие непосредственно около них, и могут
программируемыми точками связи подключаться к линиям каналов. Даль-
нейшее направление сигналов в нужные цепи осуществляется переключа-
тельными блоками.
Линии двойной длины сгруппированы в пары, имеется по 4 вертикальных и
горизонтальных линии, обеспечивающих более быструю и эффективную
передачу сигналов на средние расстояния. Длинные линии, рассчитанные
на передачу сигналов на большие расстояния и при большой нагрузке, име-
ют в середине ключ, разделяющий линию на две части ((рис. 1.13, в).
Кроме системы коммутации для функциональных блоков FPGA (в частно-
сти, семейство Spartan) может иметь дополнительные трассировочные ре-
сурсы, расположенные в виде кольца вне пределов матрицы ФБ. Эти ресур-
сы позволяют изменять назначение вводов/выводов микросхемы и облегча -
ют тем самым модификацию проекта, реализованного на FPGA, без влия-

ния на разводку печатных плат, на которых монтируются микросхемы.
В число FPGA по принятой классификации попадают микросхемы с числом
эквивалентных вентилей около 200—85 000, системными частотами прибли-
зительно 50—80 МГц, числом пользовательских выводов 100—300. Лидером
в производстве однократно программируемых FPGA считают фирму Actel, a
в производстве FPGA с триггерной памятью конфигурации — фирму Xilinx.
б в
Рис. 1.13. Пример системы коммутации FPGA (а), схема переключательного блока (б)
и схема для установления соединений коммутируемых линий (в)
1.4. ПЛИС с комбинированной архитектурой

1.4.1. Структура микросхем семейства FLEX
По мере роста уровня интеграции ПЛИС их архитектуры усложнялись, по-
явились архитектуры в той или иной мере сочетающие достоинства CPLD
и FPGA. К числу появившихся микросхем с такой архитектурой в первую
очередь можно отнести семейство FLEX (Flexible Logic Element matriX)
фирмы Altera. Комбинированные архитектуры затем нашли применение в
многочисленных БИС/СБИС, в том числе типа "система на кристалле".
Микросхемы высшей сложности строят по все более оригинальным архи-
тектурам, не только сочетающим черты CPLD и FPGA, но и обладающим
новыми особенностями. На рис. 1.14 приведена структура микросхем семей-
ства FLEX.
Микросхемы семейства FLEX имеют функциональные блоки (LABs, Logic
Array Blocks) с логическими элементами ЛЭ (LEs, Logic Elements), содер-
жащими функциональные преобразователи ФП табличного типа (LUTs).
Функциональные блоки расположены в виде матрицы, между их строками и
столбцами проходят горизонтальные и вертикальные трассировочные кана-
лы, что характерно для FPGA. В то же время, трассы в каналах не сегменти-
рованы, а непрерывны, что типично для CPLD. Поскольку, как уже отмеча-
лось, в схемах с большим числом функциональных блоков применение еди-
ной коммутационной матрицы затруднено, система коммутации имеет два
уровня межсоединений — глобальный и локальный. Локальная программи-
руемая матрица соединений (локальная ПМС или ЛПМС) обеспечивает
межсоединения логических элементов ЛЭ, из которых составляются функ-
циональные блоки LABs. В состав LAB входят 8 логических элементов. Со-
единения между блоками LAB обеспечиваются глобальной программируе-
мой матрицей соединений ГПМС, к концам строк и столбцов которой под-
ключаются блоки ввода/вывода (IOBs, Input/Output Blocks).
Начиная с семейства FLEX10K, в составе многих микросхем ПЛИС появи-
лись встроенные блоки памяти ВВП (EABs, Embedded Array Blocks). Ранее
имелась возможность использования в качестве субмодулей памяти лишь
тех ресурсов, которые имеются в ФП типа LUT.
В схеме на рис. 1.14 показан включенный в середине строк встроенный
блок памяти (у большинства микросхем семейства FLEX10K его емкость
равна 2048 бит). Такой блок может конфигурироваться как ЗУ с организаци-
ей 256x8, или 512x4, или 1024x2, или 2048x1 и использоваться не только для
хранения данных, но и как табличный ФП для реализации сложных функ-
ций с числом аргументов 8—10 (в частности, на блоках ЕАВ строятся быст-
родействующие арифметико -логические устройства АЛУ, перемножители
4x4 и т. д.).
Рис. 1.14. Структура микросхем семейства FLEX
1.4.2. Логические элементы

Логические элементы микросхем семейства FLEX (рис. 1.15) имеют в своей
основе 4 -входовые ФП табличного типа (LUT). Особенностью схем, кото-
рые могут быть построены из этих логических элементов, является наличие
специальных трактов переноса, образуемых цепочками схем переноса СП, и
трактов каскадирования, образуемых схемами каскадирования СК с непо-
средственными и быстродействующими связями между логическими эле-
ментами по указанным трактам.
Рис. 1.15. Схема логического элемента микросхем семейства FLEX
ФП с 4 входами имеет 16 бит памяти и для воспроизведения функций 4 ар-

гументов организуется в варианте 16x1. Те же самые 16 бит можно исполь-
зовать в виде двух табличных ФП с организацией 8x1, реализующих две
функции 3 переменных, что отвечает, например, потребностям построения
разрядных схем сумматоров с последовательным переносом, разрядных схем
некоторых счетчиков и т. д. Длинные цепочки переносов формируются в
пределах нескольких LAB. В микросхемах семейства FLEX задержка цепи
переноса мала (приблизительно 1 не), что делает целесообразным примене-
ние в проектах многих простых схем с последовательными переносами даже
для быстродействующих устройств.
Цепочка каскадирования используется для получения функций с числом
аргументов более 4. Три соседних ЛЭ можно применить для воспроизведе -
ния частичных функций, а затем с помощью каскадирования сформировать

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

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

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

другой ЛЭ и т. д. В результате вычисляется "функция от функций" с числом
аргументов, превышающим 4 (рис. 1.16, б).
Синхронный триггер в схеме на рис. 1.15 получает сигналы от схемы управ-
ления с входами R (Reset), D (одна из входных линий логического элемен-
та) и ЛУС (четыре линии локальных управляющих сигналов). Один из двух
сигналов ЛУС по выбору используется для тактирования триггера, два дру-
гих вместе с сигналом R и одним из входов D управляют режимами сбро-
са/установки. С помощью программирования можно задавать несколько ре-
жимов воздействия на триггер по входам S и R. Все эти режимы (сброс, ус-
тановка, загрузка в разных вариантах) асинхронны.
Триггер может быть использован для фиксации значений выработанных ФП
функций или как отдельный элемент с входом от одной из линий D в зави-
симости от программирования мультиплексора в линии этого входа.
Выходной сигнал логического элемента через программируемые мультип-
лексоры может подаваться в глобальную и локальную матрицы межсоедине-
ний в программируемых вариантах комбинационного (с обходом триггера)
или регистрового (с триггера) выходов.
1.4.3. Встроенные блоки памяти

В состав СБИС семейства FLEX10K были впервые включены встроенные
блоки памяти ВВП общей емкостью приблизительно от 6 до 20 Кбит для
разных представителей семейства. Отдельные блоки емкостью 2 Кбит были
размещены в середине каждой строки матрицы логических блоков. 'Блоки
встроенной памяти можно использовать как по прямому назначению, т. е.
как статическое ЗУ, так и для реализации ПЗУ и логических схем
(табличных ФП повышенной размерности путем эмуляции ПЗУ с помощью
загрузки таблицы в ОЗУ). Такие ФП дают более эффективные решения в
сравнении с реализациями сложных функций средствами типовых логиче-
ских блоков. Например, один встроенный блок памяти при организации
256x8 реализует перемножитель 4x4, способный работать на частотах до
50 МГц. Построение такого же перемножителя на типовых ЛБ потребовало
бы занять 8 логических блоков, а частота работы перемножителя не превы-
сила бы 20 МГц.
Блоки встроенной памяти ориентированы также на организацию буферов
FIFO, а в микросхемах FLEX10KE и на построение двухпортовой памяти.
Несколько блоков можно объединять для создания" более емкой памяти. Так
как блоки памяти расположены на том же кристалле, что и логическая часть
схемы, работа с памятью отличается высоким быстродействием.
В структуре встроенных блоков памяти (рис. 1.17) кроме модуля памяти
RAM/ROM имеется несколько синхронных D -триггеров и программируе -
мых мультиплексоров. Локальная программируемая матрица соединений

ЛПМС получает 22—26 сигналов от строки глобальной матрицы ГПМС.
Регистры 1 и 2 программируются для передачи в модуль памяти данных и
адресов разной разрядности в зависимости от заданной конфигурации памя-
ти. В блоке с емкостью 2 Кбит разрядность данных может изменяться от 1
до 8, а разрядность адреса от 11 до 8. Запись в память в зависимости от
программирования мультиплексоров 4—6 может быть синхронной (от реги-
стров по сигналам тактирования) или асинхронной (непосредственно от
ЛПМС).
Рис. 1.17. Структура встроенных блоков памяти

в микросхемах семейства FLEX10K
Сигналы управления регистрами 1—3 поступают от глобальной шины управ-

ляющих сигналов с возможностью выбора их полярности (мультиплексоры
1—3). Выходные сигналы блока' памяти с помощью мультиплексоров 7—9
могут передаваться как на линии строки, так и на линии столбца ГПМС
в тактируемом или асинхронном вариантах.
1.5. Основные сведения о СБИС

типа "система на кристалле"
Уменьшение литографических размеров и другие усовершенствования про-
цессов производства интегральных схем ведут к непрерывному росту уровня
их интеграции, который для наиболее сложных СБИС в настоящее время
оценивается уже десятками миллионов вентилей. Быстродействие таких
СБИС характеризуется рабочими частотами в несколько сотен мегагерц. На
кристаллах с подобными параметрами можно разместить законченную сис-
тему обработки данных, обладающую к тому же высокой производитель-
ностью. В последние годы появились микросхемы, называемые "система на
кристалле", "система на программируемом кристалле", "программируемая сис-
тема на кристалле" и т. д. (обозначаются как SOC, System On Chip, или как
SOPC, System On Programmable Chip, или как PSOC, Programmable System
On Chip, или как CSOC, Configurable System On Chip и т. д.). Далее в каче-
стве обобщающего термина будет применяться обозначение SOPC.
Стратегическая значимость возможности создания законченной системы на
одном кристалле очевидна — такая система обладает высокими качествен-
ными показателями. Для подавляющего большинства разработчиков созда-
ние системы на одном кристалле осуществимо только на основе програм-
мируемых СБИС, т. к. заказное проектирование по экономическим сообра-
жениям возможно только при массовом производстве.
Задача создания высококачественных законченных систем на одном кри-
сталле решается более чем десятком крупных фирм в обстановке активной
состязательности. Состязательность выражается как в конкурентном разви-
тии двух направлений, отраженных в принятой нами классификации СБИС
программируемой логики, так и в разработке многих разновидностей СБИС
в рамках каждого из этих направлений.
Представителями первого направления являются SOPC с однородной струк-
турой (с конфигурируемостью всех областей кристалла, с полностью синте-
зируемыми блоками).
Заметим, что однородность здесь понимается только как признак конфигу-
рируемости всех областей кристалла, поскольку эти области содержат одно-
типные программируемые схемные ресурсы. Исключение составляют лишь
некоторые области кристалла (схемы встроенной памяти, которые стали по-
являться в архитектурах ПЛИС, начиная с семейства FLEX10K, схемы
управления тактовыми импульсами типа PLL или DLL и т. п.). В однород-
ных SOPC реализуемые блоки могут размещаться в разных областях и соз-
даваться соответствующим программированием. По своим архитектурным
признакам SOPC, как правило, относятся к структурам комбинированного
типа, в которых сочетаются признаки CPLD и FPGA с преобладанием при -
знаков FPGA. В иностранной литературе применительно к однородным

в указанном смысле SOPC иногда используют термин generic.
SOPC блочного типа включают в себя как программируемые, так и фикси-
рованные области, в которых жестко реализованы блоки с предопределен-
ными функциями — аппаратные ядра (Hardcores, hard -ядра). В других об-
ластях кристалла размещается программируемая пользователем часть, чаще
всего типа FPGA.
В ходе развития блочных SOPC характер и сложность аппаратных ядер из-
меняются. Вначале аппаратные ядра были относительно простыми, сейчас
основным ядром сложных блочных SOPC нередко служит микропроцессор
или микроконтроллер.
В чем состоят преимущества и недостатки СБИС двух развивающихся на-
правлений? В однородных SOPC уровень интеграции уже позволяет скон-
фигурировать на кристалле области процессора, памяти и периферийных
схем. Современные средства САПР с их приспособленностью к взаимозаме-
няемым и стандартным решениям позволяют объединять на одном кристал-
ле виртуальные компоненты (soft -ядра, IP) разных разработчиков. Правда,
при использовании IP возникает проблема их приобретения, поскольку сто-
ят они достаточно дорого. В однородных SOPC не достигаются предельные
быстродействия ядер.
Hard -ядра реализуют блоки, полученные методами проектирования заказных
схем. Такие блоки в сравнении с их soft -аналогами занимают на кристалле
значительно меньшую площадь (в несколько раз), поскольку они не содер-
жат средств конфигурирования и оптимизированы для выполнения задан-
ной конкретной функции. Если принять площадь, занимаемую цифровым
устройством, реализованным по методу "на стандартных ячейках", за едини-
цу, то при реализации того же устройства в технологии LPGA (на БМК
с лазерным программированием) площадь составит в среднем 3,3 единицы,
для технологии MPGA — 1,6 единиц, а для П Л И С — 10—20 единиц. По
этим же причинам существенно (на 20—50%) возрастает быстродействие
hard -ядер в сравнении с soft -ядрами.
В то же время предопределенность функций hard -ядер снижает универсаль-
ность микросхемы (как говорят, уменьшает ее функциональную гибкость) и
может сузить круг ее потребителей, что с точки зрения экономики является
негативным фактором. Hard -ядра фиксированы на площади кристалла, что
может затруднять решение задач размещения и трассировки для конфигури-
руемых областей микросхемы, препятствуя тем. самым реализации макси-
мальных показателей логической емкости и быстродействия для программи-
руемых ресурсов схемы.
Во избежание больших потерь универсальности СБИС с hard -ядрами, для
этих ядер отбираются только такие функциональные блоки, которые зани-
мают значительную долю рынка. Характерными примерами hard -ядер, по -
мимо микропроцессоров и микроконтроллеров, могут служить блоки для

реализации интерфейсов различных шин (в том числе шин PCI, VME), схе-
мы поддержки интерфейса JTAG, множительные устройства для систем
цифровой обработки сигналов.
Заметим, что современные ПЛИС с hard -ядрами имеют архитектурную пре-
емственность с прошлыми разработками. Например, уже несколько лет в
состав микропроцессорных систем вводят FPGA, создавая тем самым как
бы "островок программируемости среди блоков жесткой структуры. С дру-
гой стороны, в составе ПЛИС тоже несколько лет назад стали появляться
несложные аппаратные ядра, т. е. участки фиксированной структуры в ок-
ружении массива синтезируемой логики. Поэтому говорить о том, что во
что встроено, порою можно по -разному. Чем выше процент синтезируемой
части микросхемы, тем больший контроль над реализацией получает разработ-
чик проекта, но тем больше блоков при этом теряют оптимальность своих
параметров.
По поводу перспектив применения двух разновидностей SOPC высказыва-
ются разные мнения. Одни считают, что структуры однородного типа с их
высокой степенью регулярности схем легче переводятся на новый техноло-
гический уровень, поэтому освоение новых технологий для блочных струк-
тур должно всегда несколько запаздывать, а замедленный выход продукции
на рынок наносит изготовителю экономический ущерб. С другой стороны
отмечается, что аппаратные ядра не только гарантируют улучшенные пара-
метры блоков, но и упрощают деловую часть разработки проекта, устраняя
для проектировщика взаимоотношения с третьими лицами (поставщиками
IP). При этом отпадают лицензионные проблемы, платежи роялти и т. п., и
вся техническая поддержка сосредотачивается в руках одного партнера —
поставщика микросхем, а все затраты концентрируются в одном показателе
(цене микросхемы). Так или иначе, но при решении вопроса о выборе той или
иной SOPC приходится учитывать целый комплекс показателей.
СБИС программируемой логики образуют динамичный, быстро растущий
сектор рынка. Интеграция все большего числа функциональных блоков в
одном кристалле сопровождается сокращением площади плат при реализа-
ции проектов, повышением быстродействия устройств и систем и их надеж-
ности, уменьшением потребляемой мощности и стоимости. Возможность
быстрой реконфигурации схем непосредственно в работающем устройстве
открывает перспективы не только эффективной отработки прототипа проек-
та, но и создания принципиально новых структур с динамическим реконфигури -
рованием и многофункциональным использованием аппаратных средств.
При обсуждении вопросов применения SOPC возникает проблема выбора
между однородными и блочными архитектурами, т. е. между soft - и hard -
ядрами. Как отмечалось, в этой сфере имеются различные мнения. Наиболее
бесспорной областью использования блочных SOPC являются системы высшего
_70 Проектирование систем на микросхемах программируемой логики
быстродействия, поскольку, как бы соблазнительно ни выглядели реклам-

ные преувеличения, процессоры с рабочими частотами в сотни мегагерц,
осуществимые для hard -ядер, находятся за пределами возможностей soft -
ядер FPGA. В других, менее очевидных ситуациях, оценивается весь ком-
плекс характеристик SOPC.
В настоящее время развиваются обе разновидности SOPC, и успехи видны
в обоих направлениях. Например, для SOPC типа generic фирмой Altera при-
менено процессорное soft -ядро Nios, размещаемое на кристаллах семейств
АРЕХ20К/КЕ и АРЕХП. Уровень интеграции этих кристаллов настолько
велик, что процессор занимает лишь малую долю их логических ресурсов,
что считается вполне приемлемым. Фирма Xilinx разработала soft -ядро про-
цессора Microblaze для своего семейства Virtex II. Это ядро обладает наи-
высшей для soft -ядер производительностью и работает на частотах до 125 МГц.
Впечатляют успехи разработок hard -ядер процессоров. Эти ядра базируются
на RISC -архитектурах процессоров фирм ARM Limited, MIPS Technologies
и IBM Microelectronics, работают на частотах до 200 МГц и более, имеют
5—6 -ступенчатые конвейеры, выполняют скалярные операции, соверша-
ют большинство операций за один такт, занимают на кристалле площадь
2—3 мм 2 и ориентированы на малое потребление мощности. Стандартность
архитектур таких процессоров позволяет пользоваться при их применении
обширными инструментами и средствами проектирования, что снижает тру-
доемкость разработок и уменьшает время выхода продукции на рынок.
1.6. СБИС типа "система на кристалле"

с однородной структурой
(с полностью синтезируемыми блоками)
Однородные SOPC появились в составе продукции фирм Altera (семейст-
во АРЕХ20К), Xilinx (семейство Virtex), Actel (семейство proASIC), Cypress
Semiconductor (семейство Delta 39K), Lucent Technologies (семейство ORCA4)
и др. Появившиеся семейства, как правило, подвергаются периодическим
модификациям с существенным улучшением параметров по мере освоения
новых технологических процессов.
1.6.1. Микросхемы семейств АРЕХ20К/КЕ, АРЕХП

Микросхемы семейств АРЕХ20К/КЕ принадлежат к первым промышлен-
ным SOPC с конфигурируемостью всех областей кристалла. Память конфи-
гурации — статическая (триггерная). Микросхемы АРЕХ20К имеют напря-
жение питания ядра 2,5 В и уровни сигналов ввода/вывода 2,5; 3,3 и 5,0 В,
а микросхемы АРЕХ20КЕ напряжение питания ядра 1,8 В, а уровни сигна-
лов ввода/вывода 1,8; 2,5; 3,3 и 5,0 В.
Общий план микросхем показан на рис. 1.18. Архитектура микросхем на-

зывается Multicore, в ней сочетаются функциональные блоки типов LUT
и PAL. Кроме того, микросхемы имеют встроенные блоки памяти ESB
(Embedded System Blocks), содержащие также средства для реализации ДНФ
логических функций (что и объясняет термин "системные" в названии бло-
ков).
Схемы управления
тактированием
Шины быстрых
Схемы 4 -входовых I
ФПтипаШТ - - '
Схемы многофунк -
циональной встро-
енной памяти
Рис. 1.18. Общий план кристалла микросхем семейства АРЕХ20К/КЕ
LUT -блоки этого семейства заимствованы от описанных ранее микросхем

FLEX10K, блоки типа SOP (Sum -of -Products) — от семейства МАХ7000,
также описанного выше, блоки памяти близки по структуре к блокам се-
мейства FLEX 1 ОКЕ с емкостью 2 Кбит.
Дизъюнктивные нормальные формы удобны для получения функций управ-
ляющей логики, в частности, адресных декодеров и автоматов с памятью.
Табличные блоки хорошо приспособлены к реализации сложных алгорит-
мов обработки сигналов и к построению узлов и устройств, содержащих
большие количества триггеров. Совмещение обоих типов блоков в одном
кристалле обеспечивает эффективность схемных решений, характерных для
проектов разных типов. Этому же способствует наличие на кристалле встро-
енных блоков памяти высокого быстродействия, организуемых в виде RAM,
двухпортовой RAM, FIFO с широким диапазоном программируемых длины
и ширины, а также блоков ассоциативной памяти (у микросхем АРЕХ20КЕ).
Сложность кристаллов семейства APEX обусловила увеличение в них числа
иерархических структурных уровней. Наименьшей структурной единицей
логического типа является логический элемент ЛЭ (LE, Logic Element), no -
добный логическому элементу семейства FLEX10K/KE (см. рис. 1.15), до-

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

" "
Выход каскадирования
Выход переноса
Рис. 1.19. Пояснения к способам конфигурации логических элементов

семейств APEX и FLEX (a — нормальный режим, б — арифметический)
как функциональные преобразователи с четырьмя входами. В арифметиче-

ском режиме LUT -блок конфигурируется как два трехвходовых функцио-
нальных преобразователя, один из которых служит для выработки функций
переносов, а другой для функций трех аргументов, реализуемых в разрядных
схемах устройства. В счетном режиме (на рисунке не показан) к схеме, со-
ответствующей арифметическому режиму, добавляются элементы, обеспечи-
вающие функции разрешения счета, реверса, сброса и загрузки счетчика.
Десять логических элементов объединяются в логический блок ЛБ (LAB,
Logic Array Block), имеющий свой уровень межсоединений — локальную
матрицу соединений ЛМС (LI, Local Interconnect). Шестнадцать логических
блоков и блок ESB объединяются в мегаблок (MegaLAB). Мегаблоки также
имеют свой уровень межсоединений, что не только увеличивает общие ре-
сурсы трассировки кристалла, но и позволяет получать в пределах мегаблока
некоторые функционально законченные части системы. Функциональная
автономность мегаблоков, когда она возможна, упрощает модификацию
системы и закладывает возможности локальной оптимизации схемных ре-
шений. Мегаблоки коммутируются между собой по системе глобальной мат-
рицы соединений ГМС (Fast Track Interconnect), линии которой непрерыв-
ны и проходят по всей длине (ширине) кристалла. К концам линий ГМС
подключаются элементы ввода/вывода ЭВВ (IOЕ, Input/Output Elements).
К системе межсоединений относятся также цепи переноса и каскадирования.
Схемы ввода/вывода отличаются высоким быстродействием и поддерживают
более 10 стандартов входных и выходных сигналов. Контакты ввода/вывода
разделены на восемь банков, имеющих свои напряжения питания и способ-
ных, независимо от других банков, поддерживать те или иные стандарты
ввода/вывода. Элементы ввода/вывода обеспечивают совместимость с ши-
ной PCI (64 разряда, 66 МГц).
Большое внимание уделено схемам тактирования кристалла, реализована
схема передачи синхросигналов с малыми фазовыми сдвигами, блоки мик-
росхем могут использовать до 8 глобальных синхросигналов. Схемы управ-
ления параметрами синхросигналов выполняют функции минимизации их
задержек и фазовых рассогласований (ClockLock), умножения частоты в не-
которых блоках схемы, что позволяет разводить по кристаллу сигналы так-
тирования меньшей частоты (функция ClockBoost), функции ClockShift
(введения специальных программируемых фазовых сдвигов в линии переда-
чи сигналов).
Микросхемы семейства АРЕХ20К/КЕ имеют программируемое управление
по координатам скорость/мощность. Когда максимальное быстродействие
не требуется, можно снижать мощность потребления до 56% с помощью
соответствующей опции турбо -бита для блоков ESB. Неиспользуемые блоки
ставятся в режим глубокого снижения мощности.
Типичный диапазон числа эквивалентных вентилей для микросхем семейст-
ва АРЕХ20К/КЕ от 60 тыс. до 1,5 млн., емкость встроенной памяти состав-
ляет от 32 768 до 442 368 бит, число пользовательских выводов от 204 до 808,
_74 Проектирование систем на микросхемах программируемой логики
внутренняя рабочая частота достигает значений приблизительно 200 МГц.

В новом семействе АРЕХ20КС с медными проводниками и топологической
нормой 0,15 мкм быстродействие схем повышается на 25—35%.
Для микросхем семейства АРЕХ20К/КЕ разработано soft -ядро процессора
Nios — RISC -процессора с изменяемой архитектурой, конфигурируемым
файлом регистров, 16 -разрядными командами и шиной данных на 16 или
32 разряда по выбору проектировщика. Производительность процессора
может достигать 50 MIPS. Микросхемы семейства АРЕХ20КЕ имеют на-
столько высокий уровень интеграции, что процессор Nios занимает неболь-
шую долю их логической емкости. Например, для микросхемы ЕР20К200Е
ядро процессора Nios занимает 12% логических ресурсов кристалла. При
стоимости кристалла около 80 долларов (в единичных поставках) на ядро
процессора приходится приблизительно 10 долларов, а при массовых по-
ставках стоимость снижается приблизительно в два раза. Для микросхемы
ЕР20К1500Е с 1,5 млн. вентилей доля расхода ресурсов на процессор Nios
снижается до 1,5%. Изменяемая архитектура ядра Nios, как и других разра-
ботанных soft -ядер, придает SOPC высокую степень гибкости. Однако быст-
родействие soft -ядер не достигает максимальных значений и в сравнении
с быстродействием аппаратных ядер остается умеренным.
Для ядра Nios применима разработанная ранее для семейства FLEX10K до-
вольно обширная периферия: таймеры -счетчики, UART, широтно-импульс -
ные модуляторы, контроллеры дисковой памяти, динамических ОЗУ и др.
Применимы и LPM (библиотечные параметризируемые модули), использо-
вавшиеся ранее в микросхемах FLEX10К.
Появление семейства АРЕХII — новое значительное достижение в развитии
однородных SOPC. На основе технологии с топологическими нормами
0,15 мкм при напряжении питания ядра 1,5 В и многослойной системе мед-
ных межсоединений получены кристаллы с уровнем интеграции до 4 млн.
типичных эквивалентных вентилей (90К логических элементов), внутренней
встроенной памятью в диапазоне от 425 984 до 1 532 712 бит и высокоскоро-
стными каналами связей, в том числе дифференциальных. Большое число
каналов связи с пропускной способностью в 1,6 Гбит/с и 624 Мбит/с позво-
ляет получать на кристалле быстродействующую систему из множества бло-
ков, либо включать кристалл в более сложную систему в качестве быстро-
действующего блока. В настоящее время выпускаются 5 представителей се-
мейства АРЕХП с диапазоном числа типичных эквивалентных вентилей от
600 тыс. до 4 млн.
1.6.2. Микросхемы семейств

Virtex, Virtex E, Virtex II
Семейства Virtex и Virtex E с триггерной памятью конфигурации появились
в составе продукции фирмы Xilinx в конце 1998 года. Как и микросхемы
АРЕХ20К, они имеют мегавентильный уровень интеграции и встроенные
блоки памяти. Системная частота их работы достигает 200 МГц. Напряже-

ние питания ядра у схем Virtex 2,5 В, у схем Virtex E 1,8 В, для уровней
внешних сигналов возможен выбор нескольких значений. Тенденция сни-
жения питания ядра микросхемы при сохранении широкого выбора уровней
внешних сигналов имеет общий характер. По мере снижения топологиче-
ских норм, напряжения питания ядер, как правило, проходят следующую
последовательность цифр: 3,3; 2,5; 1,8; 1,5 В, и это касается всех фирм -
производителей БИС/СБИС.
Общий план кристалла семейств Virtex и Virtex E показан на рис. 1.20.
Рис. 1.20. Общий план кристалла микросхем семейств Virtex и Virtex E
Основной частью микросхем является матрица конфигурируемых логи-

ческих блоков КЛБ (CLB, Configurable Logic Block), окруженная программи-
руемыми блоками ввода/вывода БВВ (IOBs, Input/Output Blocks), и иерар-
хическая система коммутации. КЛБ коммутируются системой локальных
связей с генеральной матрицей соединений ГМС (GRM, General Routing
Matrix) и горизонтальными и вертикальными каналами трассировки. Каж-
дый КЛБ входит в так называемый VersaBlock (рис. 1.21), в котором имеют-
ся локальные ресурсы соединений для коммутации КЛБ с ГМС, встроенные
обратные связи в пределах самих КЛБ и прямые пути соединении между
горизонтально -смежными КЛБ. VersaBlock может реализовать небольшие
части проекта, объединяемые далее средствами коммутации.
Микросхемы имеют также средства коммутации, называемые VersaRing, для
создания межсоединений в периферийной области, программирование ко-
торых, в частности, облегчает размещение внешних выводов по вхо-
дам/выходам схемы, реализованной во внутренней области и, тем самым,
облегчает и адаптацию логического проекта к существующей разводке пе-
чатной платы.
Основная трассировочная нагрузка приходится на горизонтальные и верти-
кальные каналы основных связей, соответствующих строкам и столбцам
матрицы КЛБ. На эти каналы сигналы из КЛБ выходят через переключа-
тельные матрицы ГСМ, способные соединять линии горизонтальных и вер -
тикальных каналов. От ГСМ к ГСМ по всем четырем направлениям сигна-

лы могут передаваться через линии разных типов. Имеются линии одинар-
ной длины (между смежными ГСМ), линии протяженностью в 6 КЛБ с дос-
тупом к ним на концах и в середине и длинные линии, с протяженностью
по всей высоте кристалла для вертикальных линий и по всей его ширине
для горизонтальных.
Прямые связи
с соседними КЛБ
Рис. 1.21. Схема VersaBlock микросхем семейств Virtex и Virtex II
К матрицам ГСМ подключены также блоки памяти по 4 Кбит и 4 схемы

DLL для управления фазовыми и частотными параметрами синхросигналов
в разных областях кристалла.
Схемы DLL (Delay Locked Loop) или PLL (Phase Locked Loop), называемые
в последнее время также схемами типа Clock Manager, стали важными бло-
ками быстродействующих БИС/СБИС. Дело в том, что из -за задержек в це-
пях передачи синхросигналов по кристаллу они "разъезжаются" во времени,
и в разных местах кристалла уже не являются синхронными. Понятно, что
это создает проблемы взаимодействия элементов, питаемых такими несин-
хронными тактирующими сигналами. Схемы DLL и PLL представляют со-
бою следящие системы с фазочувствительным элементом на входе. Фазочув -
ствительный элемент сравнивает корректируемую синхропоследовательность
с эталонной и, при наличии сигнала рассогласования этих последовательно-
стей, изменяет фазу корректируемого синхросигнала, чтобы компенсировать
задержки в цепях его передачи. Наличие в БИС/СБИС блоков DLL или
PLL позволяет заметно повысить частоту синхросигнала по сравнению с той
частотой, которая могла бы быть реализована в схеме без DLL или PLL.
Основа КЛБ — логическая ячейка ЛЯ (LC, Logic Cell). В каждом КЛБ раз-
мещены 4 логических ячейки, организованные в две идентичные секции
(Slices). Логическая ячейка (рис. 1.22) по своей структуре подобна рассмот-
ренным ранее типовым элементам FPGA и содержит 4 -входовой LUT -блок
с возможностью организации цепи переноса и триггер.
Вход переноса
Рис. 1.22. Схема логической ячейки кристаллов Virtex и Virtex E
Выходная величина вырабатывается одновременно в двух вариантах — как

комбинационная, снимаемая непосредственно с выхода LUT -блока, или как
регистровая, снимаемая с выхода триггера. Дополнительно к 4 базовым ло-
гическим ячейкам КЛБ имеет логическую схему для выработки функций от
5 и 6 аргументов в виде комбинации выходов от логических ячеек. Ресурсы
LUT -блоков могут использоваться и в качестве обычных RAM. Каждый
LUT -блок дает 16 бит памяти с организацией 16x1. В секции может быть
образован блок памяти с организацией 16x2 или 32x1 для обычного RAM
или 16x1 для двухпортового. LUT -блок может быть сконфигурирован также
как 16 -разрядный регистр сдвига.
Триггер типа D может программироваться как защелка или как триггер,
управляемый фронтом, и принимать данные с выхода LUT -блока или непо-
средственно от входов секций, и имеет программируемые входы установки
и сброса с несколькими режимами.
Блоки встроенной памяти (BlockSelectRam+) топологически расположены
в двух столбцах вдоль вертикальных краев внутренней области кристалла,
7В Проектирование систем на микросхемах программируемой логики
высота одного блока соответствует четырем КЛБ. Каждый блок представляет

собой синхронную двухпортовую RAM емкостью 4 Кбит с независимыми
управляющими сигналами для каждого порта (рис. 1.23).
Рис. 1.23. Внешняя организация блока встроенной памяти

микросхем семейств Virtex и Virtex E
Разрядности данных, передаваемых через порты, могут программироваться

независимо, причем для примитивов, генерируемых библиотекой блоков
SelectRam+, разрядности могут быть заданы в вариантах 1, 2, 4, 8, 16, чему
соответствуют разрядности шины адреса 12, 11, 10, 9, 8. Блоки RAM имеют
также специальные средства межсоединений для связей как с КЛБ, так и
с другими блоками RAM.
Сигналы и шины портов А и В имеют следующий смысл:
- CLK — тактирующий сигнал;
- EN — сигнал разрешения, отсутствие которого сохраняет состояния вы-
ходов блока в прежнем состоянии, запись данных запрещена;
- WE — разрешение записи, при его активности сигналы с входной шины
данных записываются в память по адресу с шины адресов, а вновь запи-
санные данные появляются на выходной шине данных. Пассивный уро-
вень сигнала задает операцию чтения по адресу с шины адресов, и со-
держимое адресованной ячейки появляется на выходной шине данных;
- RST — сбрасывает выходной регистр -защелку порта, не влияя на ячейки
памяти и на операции записи в другом порту;
- ADDR #:0 — шина адреса, выбирает ячейку памяти для операций чтения
или записи. Разрядность порта задает требуемую разрядность этой шины
соответственно приведенным ранее вариантам конфигурации памяти;
- DI #:0 — входная шина данных, передает значения записываемых в па-

мять данных соответственно заданной разрядности порта;
- DO #:0 — выходная шина данных, отображает содержимое адресованной
ячейки памяти. При записи отображает новые данные. Разрядность ши-
ны соответствует заданной разрядности порта.
- -активность или L -активность сигналов CLK, EN, WE, RST могут быть
заданы независимо для каждого порта. При работе памяти действуют прави-
ла разрешения конфликтов при одновременном обращении портов к одной
и той же ячейке.
Новое семейство Virtex II должно значительно расширить возможности соз-
дания SOPC. Уровень интеграции доведен в нем до 10 млн. системных вен-
тилей, число слоев межсоединений до 8, используются медные проводники,
усовершенствованы конфигурируемые логические блоки. Активные цепи
межсоединений увеличивают скорость распространения сигналов и предска-
зуемость их задержек. Микросхемы содержат до 3,5 Мбит памяти RAM/ROM,
имеют умножители размерностью 18x18 бит, широкий набор интерфейсов
ввода/вывода и 122 980 Кбит памяти в составе LUT -блоков. Существует воз-
можность выбора внутрикристальных резисторов -терминаторов с автомати-
ческим согласованием их номиналов с внешними эталонными резисторами
(Digitally Controlled Impedance Technology). Предусмотрена возможность
удаления с кристалла областей soft -ядер и размещение на их местах соответ-
ствующих hard -ядер с сохранением всех имевшихся межсоединений и всех
функциональных возможностей блоков.
Фирма Хilinx сообщила о разработке быстрейшего в мире soft -ядра процес-
сора Microblaze, работающего на частоте до 125 МГц, имеющего 32 -разряд-
ные шины для команд и данных в Гарвардской архитектуре. Процессор
предназначен для использования в сложных системах (сетевых, телекомму-
тационных и т. п.) на основе семейства Virtex И. Для совместной работы с
процессором Microblaze созданы также soft -ядра периферийных устройств
(арбитров, UART, контроллеров прерываний, интерфейсных схем для связи
с внешними ЗУ типов Flash и SRAM и т. д.).
1.7. СБИС типа "система на кристалле"

с блочными структурами
(с аппаратными ядрами)
1.7.1. Вводные замечания
Блочные SOPC — самое новое направление в развитии "систем на кристал-
ле". Согласно оценкам специалистов, их реализация становится особенно
эффективной при топологических нормах производства, достигнутых лишь
80_ Проектирование систем на микросхемах программируемой логики
в последнее время. К первым продавцам блочных SOPC без процессорных

ядер относятся фирмы Lucent Technologies (впоследствии Agere Systems),
QuickLogic. Блочные SOPC с ядрами процессоров появились впервые в про-
дукции фирм Triscend и Atmel, затем к ним присоединились фирмы Altera,
Cypress, Xilinx и др.
Следует заметить, что между SOPC с конфигурируемостью всех областей
кристалла и SOPC с аппаратными процессорными ядрами расположена
многочисленная группа микросхем с более простыми hard -ядрами, начало кото-
рым положили кристаллы со встроенными ядрами интерфейса PCI. В этой
книге основное внимание будет уделено SOPC с процессорными hard -ядра-
ми, именно наличие встроенного аппаратного микропроцессора или микро-
контроллера будем считать признаком истинной "системы на кристалле".
В составе блочных SOPC с процессорными ядрами можно выделить четыре
основные части: процессор, FPGA, интерфейс между ними и интерфейс с
внешней средой. В первую очередь, именно интерфейсы различаются друг
от друга в SOPC разных фирм, и, главным образом, это определяет специ-
фику тех или иных микросхем. Различия, имеющиеся во внутренней орга-
низации процессоров и FPGA, вторичны и при проектировании на основе
SOPC проявляют себя в меньшей степени.
1.7.2. SOPC с блочной структурой,

не содержащие ядер процессоров
Появившиеся в последние годы блочные SOPC с процессорными ядрами
ознаменовали создание в полном смысле универсальных "систем на кри-
сталле". Этим SOPC предшествовали "усеченные" варианты с более просты-
ми аппаратными ядрами, ориентированные на специализированные прило-
жения. Такие SOPC оказались полезными для многих, в том числе и самых
новых, проектов. В силу этого существование "заполненной" зоны между
БИС/СБИС с простейшими и самыми сложными ядрами обуславливается
не только временными причинами технологического характера, но и устой-
чивыми потребностями системотехников. Кстати говоря, с точки зрения
технологических возможностей (и связанных с ними параметров БИС/СБИС)
считается, что реализация простых аппаратных ядер становится эффектив-
ной при топологической норме производства не более 0,25—0,35 мкм, а реа-
лизация сложных — при норме не более 0,18 мкм.
Блочные SOPC со специализированными ядрами выпускаются несколькими
фирмами. К числу пионеров этого направления относятся фирмы Lucent
Technologies, QuickLogic, Cirrus Logic, Cypress Semiconductor и др.
Фирмой Lucent Technologies первая микросхема OR3TP12 типа FPSC (Field -
Programmable System Chip) выпущена в 1998 году на основе известной серии
микросхем ORCA3. Схема содержит массив программируемой логики с мат -
рицей логических ячеек 18x18 емкостью до 60 тыс. эквивалентных вентилей

и аппаратное ядро PCI (64 разряда/66 МГц). В следующей микросхеме
OR3LP26B был удвоен объем программируемой логики FPGA и увеличена
пропускная способность межсоединений тракта "ядро -FPGA", а в микро-
схеме ORT4622 ядро PCI заменено полностью дуплексным 4 -канальным
синхронным интерфейсом с пропускной способностью 622 Мбит/с. После-
дующий вариант ORT8850, основанный на разработках серии ORCA4, про-
должил линию развития микросхемы ORT4622, имея 8 каналов и пропуск-
ную способность 850 Мбит/с. Продукция фирмы Lucent Technologies ориен-
тирована на рынок интерфейсных схем для систем коммуникаций.
Микросхемы этой фирмы отличаются высоким схемотехнологическим уров-
нем, в частности, тем, что имеют минимальный размер 0,13 мкм при 7 слоях
металлизации.
Фирма QuickLogic разработала семейство блочных SOPC под названием ESP
(Embedded Standard Products, в других источниках эта же аббревиатура рас-
шифровывается как Embedded Standard Platforms) с подсемействами
QuickRAM, QuickPCI, QuickPC, QuickDSP, QuickSD. По своим классифика-
ционным признакам семейство ESB принадлежит к классу ASSP. Конфигу-
рируемые части указанных микросхем построены с использованием про-
граммируемых перемычек ViaLink типа antifuse, что придает этим частям
известные свойства: однократность программирования, но при этом высо-
кую компактность межсоединений, высокое быстродействие схем, повы-
шенную стойкость к воздействиям температуры и радиации, защищенность
от рассекречивания проекта.
Кристаллы QuickRAM (1998 г.) содержат FPGA и встроенные блоки памяти
емкостью до 25 374 бит с программированием организации как RAM, ROM,
FIFO при способности работать на частотах до 160 МГц.
Микросхемы QuickPCI имеют FPGA и ядро PCI (ядро PCI фиксировано и,
тем самым, определяется как аппаратное, но, что своеобразно, также вы-
полнено с использованием перемычек antifuse). Для ядер PCI возможен вы-
бор вариантов на 32 и 64 разряда с частотами 33, 66 и 75 МГц. Для связи
ядра PCI с другими частями схемы введен набор буферов FIFO.
Схемы QuickPC имеют аппаратно реализованный канал Fibre Channel со
скоростью передачи данных до 2,5 Гбит/с и 32 -разрядным синхронным сис-
темным интерфейсом с буферами FIFO.
Кристаллы QuickDSP базируются на специальных арифметических ячейках
ECU (Embedded Computational Units), выполняющих однотактно операции
умножения 8x8 с задержкой 4,53 не, 16 -разрядное сложение с задержкой
2,54 не, умножение с накоплением с задержкой 7,07 не. На основе таких
ячеек строятся схемы реализации алгоритмов цифровой обработки сигналов.
В микросхемах QuickSD комбинируются быстродействующие FPGA и блоки
SERDES (Serializer -Deserializer), выполняющие преобразования данных из
параллельной формы в последовательную и наоборот. Три представителя

семейства имеют в своем составе 6 или 8 каналов SERDES и от 334 до 658К
системных вентилей. Каждый порт SERDES может передавать последова-
тельные данные со скоростью до 1 Гбит/с. Две программируемых схемы
синхронизации каналов SERDES могут тактировать передачи, если синхро-
сигналы не содержатся в самих данных. Имеются два программируемых
блока PLL и от 24 до 36 блоков двухпортовой SRAM, а также 12—18 блоков
QMAC умножения -накопления, которые в большой степени ускоряют вы-
числения при цифровой обработке сигналов. Результирующая скорость
передачи составляет 8 Гбит/с, чего достаточно для большого числа приме-
нений. Логика FPGA может выполнять операции кодирования и декодиро-
вания информации, балансировки дифференциальных сигналов по посто-
янному току, обрамления пакетов данных, управления памятью и др., в том
числе реализацию некоторых интерфейсов.
Каждый канал SERDES может быть запрограммирован на выработку после-
довательных кодов для I, 4, 7, 8, 10 или 20 линий параллельной шины, что
позволяет блоку принимать сигналы с многоразрядных внутренних шин и
расщеплять их для максимального использования ресурсов кристалла.
В качестве примера области применения микросхем QuickSD можно указать
интерфейс с дисплеем высокого разрешения. Поток данных для такого дис-
плея обычно передается через многоразрядный кабель. При наличии скоро-
стного последовательного канала кабель можно исключить и заменить более
дешевым последовательным интерфейсом. При этом возможности микро-
схем QuickSD способны удовлетворить требования систем с самыми совре-
менными дисплеями.
Внутренние передачи "регистр -регистр" производятся на частотах до 600 МГц,
частота передач "кристалл -кристалл" свыше 225 МГц.
Фирмой Cypress Semiconductor разработаны блочные SOPC семейства PSI
(Programmable Serial Interface), содержащие блоки SERDES -SONET, канал
Fibre Channel, гигабитный интерфейс сети Ethernet и др.
1.7.3. SOPC семейства FPSLIC фирмы Atmel

Начнем ознакомление с SOPC, имеющими ядра процессоров, с семейства
FPSLIC (Field Programmable System -Level Integration Chip) фирмы Atmel,
разработка которого была признана лучшим проектом США в области элек-
троники в 1999 году.
До выпуска семейства FPSLIC (микросхем АТ94К) фирмой Atmel уже про-
изводились как хорошо известные микроконтроллеры типа AVR, так и
FPGA семейства АТ40К, которые и были объединены в одном кристалле
FPSLIC. Кроме них, к основным блокам этого кристалла относится статиче -
Глава 1. Элементная база электронных устройств и систем S3
екая память SRAM. FPGA получает от процессора команды и исходные

данные и передает ему выработанные результаты.
В архитектуре микросхем FPSLIC (рис. 1.24) представлены следующие блоки:
О процессорное ядро AVR и его периферия;
- память программ и память данных;
- FPGA AT40K с логической емкостью от 10 до 40К эквивалентных вен-
тилей.
Используется Гарвардская архитектура процессора, обеспечивающая повы-
шение быстродействия ядра вследствие совмещения во времени процессов
выборки и исполнения команд. В блоке FPGA размещена стандартная
структура микросхем АТ40К с различной логической емкостью у разных
представителей семейства, способная работать на системных частотах
до 100 МГц и имеющая собственные блоки встроенной памяти емкостью
от 2048 до 18 432 бит.
Структура микросхем АТ40К, в основных чертах, типична для классических
FPGA, хотя и имеет некоторые оригинальные особенности. Квадратная об-
ласть, занимаемая FPGA на кристалле, от края до края плотно заполнена
идентичными логическими ячейками. Помимо этих ячеек в области FPGA
реализованы повторители (Repeaters), сегментированные программируемые
связи и блоки RAM. Повторители соединяют смежные сегменты в горизон-
тальных и вертикальных трассах передачи сигналов, размещенных через
каждые четыре ячейки по обеим координатам. На пересечениях рядов, со-
держащих повторители, находятся блоки RAM емкостью 32x4 бита каждый.
В трактах трассировки выделяются локальные линии связи и экспресс -
линии. В экспресс -линиях повторители включены реже, чем в локальных, а
длина их сегментов больше.
Особенностью ячеек FPGA является их восьмиугольная форма. У квадрат-
ных ячеек, если они в дополнение к другим ресурсам трассировки имеют
прямые связи с соседними ячейками, четыре направления передач: вверх,
вниз, влево, вправо (в американских фирменных справочниках направления
часто соответствуют странам света и обозначаются как северное: N, южное:
S, западное: W и восточное: Е). Восьмиугольные ячейки имеют, кроме ор-
тогональных, и диагональные связи (NW, NE, SW, SE). Увеличенные воз-
можности межсоединений на уровне прямых связей и увеличенные ресурсы
программируемых связей внутри самих ячеек позволяют строить некоторые
блоки (например, особо быстродействующие умножители), не прибегая
к использованию шинных ресурсов трассировки.
В каждую из ячеек входят два табличных функциональных преобразователя
(LUТ), триггер типа D и полтора десятка программируемых мультиплексо-
ров, направляющих сигналы по тем или иным путям внутри самой ячейки и
Рис. 1.24. Структурная схема микросхем семейства FPSLJC
Глава 1. Элементная база электронных устройств и систем 65^
на ее входы и выходы, а также создающих некоторые дополнительные

функциональные возможности для самой ячейки. Функциональные преоб-
разователи воспроизводят функции трех переменных (одних и тех же для
обоих LUT) и могут быть объединены для выработки функций четырех пе-
ременных. Логические ячейки имеют несколько стандартных конфигураций:
для воспроизведения функций четырех переменных (режим Synthesis), двух
функций трех переменных (режим Arithmetic), двух функций от аргументов
АВ, С и D (один из трех аргументов образован как конъюнкция двух вход-
ных переменных, режим имеет название DSP/MPL), режим с конфигураци-
ей ячейки в виде схемы разряда счетчика (режим Counter) и режим реализа-
ции мультиплексора "2 -1" с буфером (режим Tri -State/MUX).
Такой набор возможных режимов ячейки обеспечивает удобство разработки
проектов с интенсивными вычислениями, таких как системы цифровой об-
работки сигналов (ЦОС), криптографические системы и другие мультиме-
дийные проекты, для которых характерен большой объем вычислений, вы-
полняемых в реальном масштабе времени. На основе блока FPGA реализу-
ются и общеупотребительные интерфейсные функции (UARTs, PCI и др.).
В FPGA имеются 6 внешних и 2 внутренних линии тактирования, внутрен-
ние линии получают сигналы от ядра AYR. FPGA имеет собственную стати-
ческую память (FreeRAM) с временем доступа 10 не и несколькими вариан-
тами возможной организации: синхронной или асинхронной, одно - или
двухпортовых RAM, буферов FIFO и др.
Система межсоединений в ядре FPGA иерархична и включает в себя ло-
кальные шины, экспресс -шины и прямые связи ячеек с ближайшими сосе-
дями. В связях имеются программируемые вентили, с помощью которых
формируются шины с тремя состояниями.
Интерфейс между FPGA и AVR (рис. 1.25) предусматривает для FPGA
16 входных линий декодированного адреса от AVR и 16 выходных линий
запросов прерываний с различными приоритетами для AVR.
Четырехразрядный адрес из адресного пространства процессора декодирует-
ся для образования 16 линий адресации объектов в FPGA. Данные переда-
ются по 8 -разрядной шине данных процессора. Таким образом, устройст-
вам, реализованным в FPGA и имеющим адреса в адресном пространстве
ввода/вывода AVR, придается возможность иметь собственный запрос пре-
рывания. Кроме того, AVR посылает в FPGA сигналы стробов чтения и
записи, управляющие двунаправленной шиной данных, образованной ли-
ниями экспресс -шин. Видно, что ядро AVR взаимодействует с устройства-
ми, созданными в FPGA, подобно тому, как обычно процессор взаимодей-
ствует с внешними устройствами.
Для функций заказной периферии, которая может быть реализована в
FPGA, существует макробиблиотека.
16 линий декодированного
адреса
Рис. 1.25. Схема интерфейса между блоками FPGA и AVR

микросхем семейства FPSLIC
Другой аспект взаимодействия FPGA и AVR состоит в их общем доступе к

двухпортовой памяти SRAM с временем доступа 15 не (рис. 1.26).
Между FPGA и процессором имеется 36 Кбайт двухпортовой памяти. Часть
ее, имеющая емкость 20 Кбайт при организации 10Кх1б, всегда используется
со стороны процессора как память программ, другая часть емкостью
16 линий адреса 16 -разрядный

' ^ - --
Память WEAVR
WE FPGA ^ данных
от 4К x 8 -—
CLK FPGA до16Кх8 REAVR
^- AVR
8 CLK AVR
-^
8 / .
s 1 «^ ^Л ' ^
f
/
/ /
Записываемые Читаемые
/
ЗП/ЧТ данных
данные данные
Рис. 1.26. Схема доступа блоков FPGA и AVR к общей двухпортовой памяти
4 Кбайта — всегда как память данных. Остальные 12 Кбайт могут полностью

или частично присоединяться к памяти программ или памяти данных
(с дискретностью 2Кх16 или 4Кх8, соответственно). Устройства, реализо-
ванные в FPGA, имеют непосредственный доступ к памяти данных, запре-
щаемый при загрузке конфигурации. Для записи и чтения в память исполь-
зуются экспресс -шины системы коммутации FPGA, расположенные на со-
ответствующем краю матрицы. Со стороны FPGA вырабатываются только
сигналы разрешения записи WE и отсутствуют сигналы разрешения чтения,
которое всегда разрешено. Одновременно с операциями записи или чтения
со стороны FPGA могут производиться и такие же операции со стороны
процессора, поэтому при появлении одного и того же адреса от FPGA и
AVR должен быть специально предусмотрен арбитраж. В большинстве слу-
чаев он заключается в ограничении доступа в память со стороны FPGA при
возникновении конфликта.
Важная особенность микросхем FPSLIC — способность к реализации концеп-
ции кэш -логики (Cache Logic), впервые введенной фирмой Atmel. Кэш -
логика — новое достижение в области разработки адаптивных систем, она
позволяет полностью или частично конфигурировать систему "на лету" без
потери имевшихся данных и нарушения работы ее неизменяемой части.
Данные, которые были выработаны к моменту перестройки той или иной
части системы, сохраняются. Та часть аппаратуры, в которой в данный мо-
мент идет обработка информации, представлена "нормальной" схемой соот-
ветствующей конфигурации, созданной в FPGA, а пассивная часть аппара-
туры представлена данными, сохраняемыми в недорогих устройствах памя-
ти. В итоге экономно выполняются требуемые преобразования. Когда
активизируются новые операции, новая конфигурация записывается поверх
старой.
Как известно, решаемые задачи обработки информации в конечном счете
раскладываются на множество стандартных операций низшего иерархиче-
ского уровня (сдвиги, сложения, умножение, мультиплексирование и т. п.).
Ясно, что каждая из подобных функций может быть использована много-
кратно в разных обстоятельствах, причем в одно и то же время активна
только малая часть операторов, соответствующих этим функциям. Исключая
избыточность и контролируя условия появления каждой операции, можно
так организовать систему, что сложные функции будут воспроизводиться с
помощью небольшого числа простых схем и, следовательно, на недорогих
средствах программируемой логики. Так, например, в одном из известных
примеров требуемая задача решалась обычным способом с использованием
10 тыс. вентилей, а на основе программируемых схем и концепции кэш -
логики потребовались всего 2 тыс. вентилей и запоминание неизменной
в данное время информации в дешевой системной памяти.
Концептуально различают предопределенную и динамическую кэш -логику.
Первая подразумевает использование предопределенных функций и макро -
j?8 Проектирование систем на микросхемах программируемой логики
сов, хранимых во внешней энергонезависимой памяти, заранее отработан-

ных и имеющих уже сгенерированные битовые потоки конфигурирования.
Выполнением этих функций управляют средства самой кэш -логики или
процессор.
Вторая разновидность кэш -логики должна определять требуемые функции с
их размещением и трассировкой и генерировать битовые потоки настройки
в реальном масштабе времени. Такой режим ассоциируется с работой адап-
тивных систем, и пока существует только как концепция, не имеющая за-
конченной физической реализации.
Перспективы применения кэш -логики расцениваются -как достаточно ши-
рокие. Ее применение снижает сложность программируемой части аппара-
туры и, в конечном счете, повышает ее надежность (вследствие сокращения
числа физически существующих схемных компонентов), снижает потреб-
ляемую мощность и стоимость. Предполагается применение кэш -логики,
в первую очередь, в портативной аппаратуре, системах компьютерной гра-
фики и т. п.
Разработчики таких сложных СБИС, как FPSLIC, подчеркивают, что по-
добные микросхемы не следует рассматривать как просто микроконтроллеры
с программируемой пользователем периферией, поскольку для таких отно-
сительно ограниченных целей могут найтись и более простые решения. Для
микросхем типа FPSLIC и им подобных эффект достигается прежде всего
при достаточно полном использовании их новых функциональных возможностей.
1.7.4. SOPC блочного типа фирмы Triscend

Важное место на рынке SOPC занимает корпорация Triscend, концент-
рирующая свои усилия исключительно на производстве микросхем типа
"система на кристалле". Корпорация Triscend выпустила первую в мире про-
мышленную SOPC с аппаратным процессорным ядром в то время, когда семей-
ство FPSLIC только анонсировалось фирмой Atmel (апрель 1999 г.). Сей-
час архитектуры SOPC фирмы Triscend принадлежат к числу наиболее по-
пулярных.
В микросхемах семейства Е5 фирмы Triscend на одном кристалле объедине-
ны: 8 -разрядное ядро микроконтроллера "турбо 8032", совместимое со став-
шей в последнее время фактическим стандартом архитектурой 8051 фирмы
Intel, FPGA, системная шина, память типа SRAM и несколько вспомога-
тельных периферийных устройств. Для следующего семейства А7 фирмой
Triscend взято 32 -разрядное процессорное ядро ARM7TDM1. На рис. 1.27
показаны основные блоки микросхем семейства Е5 и их взаимосвязи.
В состав микросхем этого семейства входят следующие основные блоки:
П Микроконтроллерное ядро с длительностью командного цикла 4 такта и
тактовыми частотами до 40 МГц, что обеспечивает производительность
до 10 MIPS. В состав ядра входит ОЗУ (SRAM) с организацией 256x8, три

таймера -счетчика, сторожевой таймер, блок прерываний на 12 запросов,
два указателя данных и универсальный асинхронный приемопередатчик
UART.
О FPGA с числом логических ячеек типа "LUT+триггер" от 256 до 3200 для
различных микросхем семейства.
Рис. 1.27. Структура микросхем семейства Е5 фирмы Triscend

- Высокопроизводительная конфигурируемая системная шина CSI (Confi-

gurable System Interconnect) с двумя 8 -разрядными шинами данных
(одной для чтения, другой для записи), 32 -разрядной шиной адреса и ад-
ресными селекторами. Шина связывает FPGA, периферийные узлы и яд-
ро микроконтроллера при скорости передач до 40 Мбайт/с, поддерживает
возможность обращения к внешним устройствам, режим циклического
арбитража и реализацию циклов ожидания. Адресные селекторы обеспе-
чивают доступ к устройствам, реализованным в блоке FPGA, и при этом
на создание адресных дешифраторов не расходуются ресурсы программи-
руемой логики.
- Блок программируемых портов ввода/вывода ПВВ (РIO, Programmable
Input -Output port) с программированием обычных или повышенных вы-
ходных токов. Схемы слежения за состояниями входов при отсутствии
воздействия на них активного источника сигнала удерживают на входах
последнее активное состояние. Возможно индивидуальное переключение
линий ввода/вывода в энергосберегающий режим. Уровни сигналов сов-
падают со стандартом ТТЛ.
- Блок сопряжения с внешней памятью для подключения к SOPC внешних
запоминающих устройств с параллельным или последовательным интер-
фейсом и емкостью до 256Кх8. Возможно дополнительное увеличение
числа адресных линий до 32 и доступ через блок сопряжения с внешней
памятью к внешним устройствам с внутренней системной шины.
- Контроллер прямого доступа к памяти DMA (Direct Memory Access)
с двумя независимыми каналами и скоростью передач до 40 Мбайт/с.
Передачи сопровождаются подсчетом циклической контрольной суммы.
Возможен режим передач "память -память" для организации обмена меж-
ду различными областями памяти без участия процессорного ядра.
П Блок интерфейса JTAG для загрузки памяти конфигурации и исполняе-
мой программы и для внутрисхемной отладки устройств, содержащих
микросхемы семейства Е5. Через этот блок возможен доступ к внутрен-
ней системной шине и адресуемым регистрам кристалла.
О Специальный блок внутренней отладки (In -System Debugging Hardware
Breakpoint Unit), позволяющий задавать различные условия останова при
выполнении микроконтроллером программы. Одновременно можно зада-
вать две точки останова. В состоянии останова разрешен доступ к адре-
суемым регистрам кристалла через JTAG -интерфейс.
П Блок управления энергопотреблением для индивидуального задания
энергосберегающих режимов устройствам системы и линиям портов вво-
да/вывода. В режиме снижения мощности для всех устройств ток, по-
требляемый кристаллом, не превышает 50 мкА.
О Система тактирования с внешним или внутренним задающим генера-
тором. При применении внутреннего генератора его частота задается
внешним кварцевым резонатором.
^0 Проектирование систем на микросхемах программируемой логики
П Высокопроизводительная конфигурируемая системная шина CSI (Confi-

gurable System Interconnect) с двумя 8 -разрядными шинами данных
(одной для чтения, другой для записи), 32 -разрядной шиной адреса и ад-
ресными селекторами. Шина связывает FPGA, периферийные узлы и яд-
ро микроконтроллера при скорости передач до 40 Мбайт/с, поддерживает
возможность обращения к внешним устройствам, режим циклического
арбитража и реализацию циклов ожидания. Адресные селекторы обеспе-
чивают доступ к устройствам, реализованным в блоке FPGA, и при этом
на создание адресных дешифраторов не расходуются ресурсы программи-
руемой логики.
П Блок программируемых портов ввода/вывода ПВВ (РЮ, Programmable
Input -Output port) с программированием обычных или повышенных вы-
ходных токов. Схемы слежения за состояниями входов при отсутствии
воздействия на них активного источника сигнала удерживают на входах
последнее активное состояние. Возможно индивидуальное переключение
линий ввода/вывода в энергосберегающий режим. Уровни сигналов сов-
падают со стандартом ТТЛ.
П Блок сопряжения с внешней памятью для подключения к SOPC внешних
запоминающих устройств с параллельным или последовательным интер-
фейсом и емкостью до 256Кх8. Возможно дополнительное увеличение
числа адресных линий до 32 и доступ через блок сопряжения с внешней
памятью к внешним устройствам с внутренней системной шины.
О Контроллер прямого доступа к памяти DMA (Direct Memory Access)
с двумя независимыми каналами и скоростью передач до 40 Мбайт/с.
Передачи сопровождаются подсчетом циклической контрольной суммы.
Возможен режим передач "память -память" для организации обмена меж-
ду различными областями памяти без участия процессорного ядра.
П Блок интерфейса JTAG для загрузки памяти конфигурации и исполняе-
мой программы и для внутрисхемной отладки устройств, содержащих
микросхемы семейства Е5. Через этот блок возможен доступ к внутрен-
ней системной шине и адресуемым регистрам кристалла.
О Специальный блок внутренней отладки (In -System Debugging Hardware
Breakpoint Unit), позволяющий задавать различные условия останова при
выполнении микроконтроллером программы. Одновременно можно зада-
вать две точки останова. В состоянии останова разрешен доступ к адре-
суемым регистрам кристалла через JTAG -интерфейс.
О Блок управления энергопотреблением для индивидуального задания
энергосберегающих режимов устройствам системы и линиям портов вво-
да/вывода. В режиме снижения мощности для всех устройств ток, по-
требляемый кристаллом, не превышает 50 мкА.
П Система тактирования с внешним или внутренним задающим генера-
тором. При применении внутреннего генератора его частота задается
внешним кварцевым резонатором.
1.7.5. SOPC блочного типа фирмы Altera

К числу фирм, выпускающих блочные SOPC, в 2000 году подключилась и
Altera. Производство SOPC этой фирмой началось с рассмотренного ранее
в разд. 1.5 семейства АРЕХ20К типа generic (с soft -ядрами). Позднее появи-
лись блочные SOPC с hard -ядрами, которые базировались на разработках
фирм ARM Limited и MIPS Technologies. Аппаратные ядра процессоров этих
фирм вместе с soft -ядром Nios образовали семейство встроенных процессо-
ров Excalibur.
Процессорные ядра ARM и MIPS оптимизированы для эффективной инте-
грации с программируемой логикой семейства АРЕХ20К/КЕ. Реализация в
виде hard -ядер позволяет достичь производительности процессоров в сотни
миллионов операций в секунду
Общий план микросхем Excalibur (рис. 1.28) показывает основные блоки
кристалла, в котором роль процессора играют ядра ARM или MIPS. Кроме
них на кристалле находятся оперативная память RAM, кэш -память, интер-
фейсные схемы для связи с внешними устройствами и последовательный
порт UART.
Рис. 1.28. Общий план кристалла микросхем семейства Excalibur
Микросхемы семейства Excalibur с аппаратными процессорными ядрами

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

для семейства АСЕХ.
К числу фирм -производителей блочных SOPC относится и фирма Cypress
Semiconductor. Особенностью SOPC этой фирмы является наличие подсис-
темы аналоговой программируемой периферии, в связи с чем их рассмотре-
ние приводится в следующем разделе.
1.8. Микросхемы с программируемыми

аналоговыми и аналого-цифровыми
структурами
1.8.1. Общие сведения
Многие управляющие и вычислительные системы оперируют с информаци-
ей, представленной не только в цифровой, но и в аналоговой форме. Ана-
логовые сигналы вырабатываются многими датчиками физических величин,
сведения о которых должны поступать далее в цифровую часть системы. До
ввода этих величин в цифровые устройства и при их выводе из них часто
необходимы некоторые операции (нормирование, фильтрация, аналого -циф-
ровое преобразование, цифроаналоговое преобразование и др., что иногда
обозначается термином End -Front Design). Таким образом, постановка зада-
чи интеграции всей системы на одном кристалле нередко приводит одновремен-
но и к задаче реализации на этом кристалле программируемых средств обра-
ботки аналоговых сигналов.
Аналоговые и аналого -цифровые фрагменты уже давно встраиваются в
структуры микропроцессорных систем в виде отдельных микросхем малого
и среднего уровней интеграции, использующих дискретные (навесные) опе-
рационные элементы. Технология БМК также нашла применение в области
аналого -цифровой техники, но программирование самим пользователем
аналоговых и аналого -цифровых схем, размещенных на кристаллах высо-
кого уровня интеграции, до последнего времени практически не было ос-
воено. Трудности освоения аналоговых интегральных схем в значительной
мере объяснялись их пониженными точностными возможностями в сравне-
нии со схемами на дискретных компонентах. Блоки АЦП и ЦАП с относи-
тельно давних пор встраивались в БИС (фирмы Analog Devices, Intel), но
с очень нестабильными результатами. Появление "систем на кристалле" сде-
лало особенно актуальной проблему интеграции надежных программируе-
мых аналоговых и аналого -цифровых схем и цифровой части системы. На
основе микросхем с программируемыми структурами возможно быстрое
проектирование подсистем аналоговой и аналого -цифровой обработки сиг-
налов, их отладка, создание промышленных образцов и быстрый выход на
рынок.
Глава /. Элементная база электронных устройств и систем 93
Несколько крупных фирм -производителей микросхем с программируемыми

структурами (Motorola, Lattice Semiconductor, Cypress) уже отреагировали на
требования времени и уделили внимание разработкам программируемых
аналоговых и аналого -цифровых структур, выполненных как на отдельном
кристалле, так и совместно с цифровой частью системы.
Цифровые сигналы принимают лишь два значения, одно из которых соот-
ветствует логической единице, а другое — логическому нулю. Проблема
точного задания этих сигналов отсутствует — требуется лишь надежно отли-
чать один из этих сигналов от другого. Совершенно иным является положе-
ние в аналоговой технике, где сигнал должен передавать точное значение ве-
личины с погрешностью в десятые или сотые доли процента, т. е. требуется
"дозирование" сигналов с разрешающей способностью в тысячи или даже
более уровней. Традиционно (до конца 70 -х — начала 80 -х гг.) роль дози-
рующих параметров в схемах нормирующих усилителей, сумматоров и т. п.
играли отношения сопротивлений точных резисторов. Постоянные времени
RC (также масштабирующие параметры в схемах интеграторов, фильтров
и др.) задавались совместно значениями сопротивления точного резистора и
емкости операционного конденсатора. Так, например, в известной схеме
масштабирующего усилителя, т. е. устройства умножения сигнала, заданного
напряжением постоянного тока, на константу используются два точных ре-
зистора R1 и R2, от соотношения сопротивлений которых зависит функцио-
нальная характеристика схемы, в идеализированном виде имеющая вид
U2 = (—R2/Rl)Ul, где UI и U2 — входное и выходное напряжения, соответ-
ственно. Интегратор имеет идеализированную функциональную характери-
стику вида:
U2 = ( -1/RС)INТ U1 (t) dt,
в которой роль масштабирующего коэффициента играет произведение со-
противления точного резистора входной цепи на емкость конденсатора цепи
обратной связи.
В схемотехнике с дискретными (навесными) схемными элементами пробле-
ма реализации точных резисторов имеет удовлетворительное решение. Для
технологии интегральных схем эта проблема намного сложнее, но существу-
ет альтернативное схемное решение, благодаря которому резисторы имитиру-
ются цепями, содержащими коммутируемые (переключаемые) конденсаторы
(рис. 1.29).
В такие цепи входят конденсатор С и ключевые транзисторы T1 и T2,
управляемые тактирующими напряжениями Ut1 и Ut2. Транзисторы T1 и T2
под воздействием тактирующих напряжений замыкаются поочередно, и
конденсатор С попеременно заряжается через замкнутый ключевой транзи-
стор до напряжения U1 или U2. В момент замыкания ключевого транзисто-
ра заряд конденсатора изменяется на величину q — q1 = q2 = C(U1 — U2).
Изменение заряда осуществляется короткими импульсами тока, протекаю -
щими через конденсатор при замыкании соответствующего ключевого тран-

зистора.
Среднее значение тока в цепи между точками 1 и 2 составляет величину
i = q/T=(U1 -U2)C/T,
где Т— период тактирующих импульсов.
Из полученного выражения видно, что в определенном смысле (для средних
значений сигналов) цепь ведет себя как резистор с сопротивлением R = Т/С,
сопротивление которого пропорционально периоду тактирующих импуль-
сов, т. е. обратно пропорционально их частоте. Разница состоит в том, что
резистор регулирует поток передаваемого через него заряда плавно, а цепь с
переключаемыми конденсаторами — импульсно.
Рис. 1.29. Цепь с переключаемыми конденсаторами, моделирующая резистор
На основе схем с переключаемыми конденсаторами можно строить разно-

образные операционные звенья, аналогичные известным из традиционной
аналоговой схемотехники, путем замены резисторов эквивалентными им
цепями. Сопротивления эквивалентных цепочек управляются значениями
тактовой частоты f= 1/Т, которые можно изменять и дистанционно. А это
ставит аналоговые блоки в один ряд с цифровыми с точки зрения возмож-
ностей программирования в системе на расстоянии (например, через Ин-
тернет). В схемотехнике с переключаемыми конденсаторами строятся схемы
с зависимостью функциональных характеристик только от отношения емко-
стей, которое может задаваться с высокой точностью. Именно схемотехни-
ка на основе переключаемых конденсаторов дает возможность реализовать
АЦП и ЦАП с высоким уровнем параметров. Параметры емкостей мало
критичны к изменению температуры и старению. Резко (в сотни раз) сни-
жается площадь, занимаемая цепями с переключаемыми конденсаторами
в сравнении с цепями, содержащими точные резисторы. Таковы технологи-
ческие достоинства схемотехники переключаемых конденсаторов. В то же
время применение цепочек с переключаемыми конденсаторами имеет и
свои недостатки. В цепях с непрерывными сигналами (без переключаемых
конденсаторов) отсутствует проблема отделения полезной информации
(среднего значения пульсирующей величины) от сопровождающих ее пара-
зитных высокочастотных составляющих, что благоприятно влияет на дина -
Глава 1. Элементная база электронных устройств и систем g5
мические характеристики устройств. Кроме того, схемы с непрерывными

сигналами имеют лучшие шумовые характеристики.
1.8.2. Практические разработки

Впервые о создании БИС с массивом программируемых пользователем ана-
логовых элементов объявила фирма Motorola (1997 г.). Эти БИС были анон-
сированы под названием МРАА020 (Motorola Field Programmable Analog
Arrays), но не были доведены до промышленного выпуска. В 1999 году фир-
ма Lattice Semiconductor выпустила семейство внутрисхемно программируе-
мых (In -System Programmable) аналоговых схем типов ispPACIO и ispPAC20,
а затем и ispPACSO. Фирма Cypress Semiconductor выпустила микросхемы
класса SOPC с реализацией цифровой и аналоговой части программируемой
логики в пределах одного кристалла.
В микросхемах фирмы Motorola для построения операционных звеньев ис-
пользуется схемотехника с переключаемыми конденсаторами, в микро-
схемах фирмы Lattice Semiconductor — традиционные решения с примене-
нием масштабирующих резисторов и, следовательно, непрерывных сигналов,
в SOPC фирмы Cypress Semiconductor — оба вида схемотехнических реше-
ний, т. е. и схемы с точными резисторами, и схемы с переключаемыми кон-
денсаторами.
Микросхемы семейства ispPAC фирмы Lattice Semiconductor архитектурно
просты (имеют немного конфигурируемых ресурсов и контактов вво-
да/вывода). Память конфигурации реализована по технологии EEPROM и
может загружаться через специально выделенные контакты JTAG -интер -
фейса. Допустимое число циклов репрограммирования не менее 10 тыс.
Конфигурация может быть закрыта от несанкционированного доступа битом
секретности. В состав конфигурируемых ресурсов включены не только ана-
логовые, но и цифроаналоговые средства (схема ispPAC20 содержит встро-
енный восьмиразрядный цифроаналоговый преобразователь).
Макроячейки ИС ispPACIO и ispPAC20 (рис. 1.30 и 1.31), называемые
PACblocks, состоят из двух входных (инструментальных) усилителей IA и
выходного усилителя ОА. В микросхеме ispPACIO таких макроячеек четыре,
а в микросхеме ispPAC20 — две.
Назначение других блоков микросхем указано на самих рисунках. Выходы
IA подключены к потенциально заземленным (суммирующим) точкам вы-
ходных усилителей. Входные и выходные цепи усилителей выполнены по
дифференциальной схеме, защищенной от воздействий других сигналов, что
делает качество передачи сигнала независимым от -положения линии связи
на кристалле и улучшает другие характеристики макроячеек. Входные со-
противления усилителей, реализованных в схемотехнике КМОП, настолько
велики, что практически снимают вопрос нагрузки на источники сигналов,
в том числе на датчики исходных физических величин. Взаимосоединения
блоков программируются. Из нескольких макроячеек можно строить схемы
перестраиваемых активных фильтров. Восьмиразрядный цифроаналоговый

преобразователь микросхемы ispPAC20 может воспринимать параллельные
или последовательные данные. Для компараторов возможно программиро-
вание работы с гистерезисом или без него. В схемах выходных усилителей
программируется подключение или отключение резисторов обратной связи.
Емкости конденсаторов обратной связи могут программироваться на вели-
чины от 1 до 63 пФ (всего 128 возможных значений).
Рис. 1.30. Структура PACblock микросхем ispPACtO

Рис. 1.31. Структура PACblock микросхем ispPAC20
Микросхемы ispPACSO предназначены для создания активных фильтров пя-

того порядка с программируемыми характеристиками. Могут строиться
фильтры с аппроксимацией частотных характеристик по Баттерворту, Бес-
селю, Чебышеву, фильтры с аппроксимацией эллиптического типа.
Аналоговые блоки следует характеризовать совокупностью их функциональ-
ных и точностных характеристик с учетом статических и динамических по-
грешностей. Укажем основные параметры семейства ispPAC. Микросхемы
работают от источника питания 5 В и имеют источник образцового напря-
жения 2,5 В, позволяющий выводить рабочую точку усилителей в середину
питающего напряжения для восприятия и выработки знакопеременных сиг -
j№ Проектирование систем на микросхемах программируемой логики
0.5
налов. Уровень шумов равен приблизительно 40 нВ/Гц , что дает динами-
ческий диапазон около 100 дБ в диапазоне частот до 100 кГц. Типовое зна-
чение коэффициента гармоник на частоте 10 кГц составляет —88 дБ, а на
частоте 100 кГц — -67 дБ. Автоматическая калибровка смещения нуля
(длительностью 100 мс) обеспечивает максимальное смещение менее чем на
1 мВ при типовом значении 200 мкВ и любых конфигурациях схемы и
коэффициентах усиления. Коэффициенты усиления IA программируются в
пределах от —10 до +10 с шагом 1. Типовая точность задания коэффициен-
тов усиления IA характеризуется погрешностью 1,5%, максимальная по-
грешность 4%. Температурный дрейф 20 ррт/°С. Диапазон частот для соз-
даваемых фильтров 10—100 кГц, значения частот задаются с погрешностями
не более 3,5—5%. Эксплуатационный диапазон температур от —40 до +85 °С.
Время установления выходного напряжения цифроаналогового преобразова-
теля с погрешностью 0,1% не превышает 6 мкс. Дифференциальная нели-
нейность преобразователя не более единицы младшего разряда. Типовое
время переключения компаратора при амплитуде перепада 10 мВ составляет
750 не. Максимальные токи потребления микросхем приблизительно 20 мА.
Относительно скромные точностные возможности микросхем ispPAC, тем
не менее, приемлемы для построения на них ряда работоспособных функ-
циональных узлов. Программное обеспечение фирмы Lattice Semiconductor
под названием PAC -Designer ориентировано на использование в PC -
совместимых компьютерах с ОС Windows. САПР позволяет вводить инфор-
мацию о проекте, моделировать функционирование схем, компилировать
проекты и загружать результаты компиляции в память конфигурации БИС.
Фирма Cypress Semiconductor выпустила семейство CY8C25/26, сочетающее
цифровые и аналоговые программируемые блоки.
SOPC CY8C25/26xxx имеют восьмиразрядное процессорное ядро М8С с ум-
ножителем/аккумулятором. Возможен выбор частот тактирования. Емкости
памяти программ и данных в зависимости от типа микросхемы варьируются
(от 4 до 16 Кбайт Flash -памяти для программ и от 128 до 256 байт SRAM -
памяти для данных).
В микросхемах CY8C25/26 вокруг быстродействующего процессорного ядра
размещены и цифровые, и аналоговые программируемые блоки (SOC -бло -
ки), функционирование которых задается при конфигурировании системы
(рис 1.32).
Выделение в отдельную часть цифровых блоков является вариантом органи-
зации интерфейса между процессором и FPGA. SOC -блоки могут соеди-
няться друг с другом двумя основными способами: параллельным и после-
довательным. При параллельных соединениях достигается повышение точ-
ности блоков (увеличение разрядности аналого -цифровых преобразователей,
повышение разрешающей способности таймеров и т. п.). При последова-
тельных соединениях создаются тракты из нескольких операционных звень -
ев, например, последовательное соединение предварительного усилителя,

фильтра и аналого -цифрового преобразователя.
Рис. 1.32. Структура с цифровыми и аналоговыми SOC -блоками

микросхем семейства CY8C25/26
В состав SOC -блоков первого из выпущенных представителей семейства

CY8C25/26 входят 12 аналоговых и 8 цифровых блоков. Из 12 аналоговых
блоков 4 реализованы в схемотехнике с масштабирующими резисторами
(блоки с непрерывными сигналами (СТ, Continues Time building blocks))
и 8 построены на переключаемых конденсаторах (SC, Switched -Capacitor
blocks). Блоки с непрерывными сигналами оптимизированы для построения
усилителей с программируемыми коэффициентами усиления и мультиплек-
сируемыми каналами входов и выходов, дифференциальных усилителей
и быстродействующих компараторов. Блоки, использующие технику пере-
ключаемых конденсаторов, ориентированы на создание программируемых
фильтров, регистров последовательного приближения, аналого -цифровых
и цифроаналоговых преобразователей и т. п. Цифровые блоки реализуют
такие функции, как таймеры, универсальные асинхронные приемопередат-
чики, широтно -импульсные модуляторы и др.
С помощью аналоговых и цифровых средств коммутации, содержащих

мультиплексоры и ключи, SOC -блоки соединяются в так называемые модули
• пользователя (User modules), для формирования которых подготовлена спе-
циальная библиотека. Библиотека содержит несколько типов аналого -
цифровых преобразователей (последовательного приближения, следящего
типа, с дельта -сигма модуляцией), цифроаналоговые преобразователи, ком-
параторы, устройства выборки и хранения аналоговых данных, разнообраз-
ные виды фильтров (низкой частоты, высокой частоты, полосовых), генера-
торы и детекторы напряжений специальной формы, модуляторы и демоду-
ляторы (всего около 40 аналоговых модулей пользователя).
Цифровая часть библиотеки (около 30 модулей пользователя) включает в
себя таймеры, широтно -импульсные модуляторы, приемопередатчики и за-
конченные структуры UART, интерфейс SPI, CRC -генераторы, генераторы
псевдослучайных последовательностей и схемы управления двигателями.
Программируемые аналоговые микросхемы FPAD (Field Programmable Analog
Devices) появились также в серии TRAC фирмы Fast Analog Solutions, вхо-
дящей в группу ZETEX.
Появилось сообщение о выпуске фирмой Anadigm Inc. микросхем FPAA
с программированием операционных усилителей и схем их межсоединений.
В микросхему входят 20 таких блоков, выполняющих обычные функции об-
работки аналоговых сигналов в диапазоне частот от нулевой до 500 кГц. На
процесс реконфигурации схемы затрачивается 100 мкс.
1.9.0 некоторых проблемах разработки

и использования БИС/СБИС
1.9.1. Конвертация проектов
Промышленные изделия в своем жизненном цикле проходят несколько ста-
дий. Крупными стадиями являются разработка изделия, стадия активной
реализации, стадия спада производства в связи с устареванием изделия и за-
меной его более новым и совершенным. Для создания изделия электронной
промышленности, как известно, можно пользоваться разными средствами
(стандартными ИС, программируемыми ИС, полузаказными и заказными
ИС). Учет особенностей разных стадий жизненного цикла изделия в сочета-
нии с возможностями тех или иных вариантов его реализации необходим
для эффективной организации процесса производства.
На стадии разработки проекта трудно переоценить роль применения микро-
схем, репрограммируемых пользователем, как чрезвычайно полезных средств
отработки прототипа изделия, позволяющих легко и быстро вносить в про -
ект изменения, доводя его до полностью работоспособного устройства. Ос-

танется ли вариант с репрограммируемыми микросхемами конечной про-
дукцией зависит от объема его производства. Если изделие имеет высокий
спрос, то, возможно, целесообразно перевести его на реализацию в виде по-
лузаказных или даже заказных схем, т. к. это позволит устранить из устрой-
ства средства программирования его структуры, что снизит стоимость изго-
товления каждого экземпляра микросхемы и, при необходимости, позволит по-
высить ее быстродействие. Затраты на проектирование некоторого числа
фотошаблонов, необходимых для производства полузаказных или заказных
схем, и другие однократные технологические затраты (NRE, Non Recurrent
Expends) не зачеркнут указанный выигрыш, если тиражность изделия доста-
точно велика. На последней стадии жизненного цикла изделия объем его
производства снижается и становится неустойчивым. При этом может ока-
заться выгодным возврат от варианта с полузаказными и заказными микро-
схемами к БИС/СБИС с программируемыми структурами (FPGA, CPLD,
FLEX, SOPC), т. к. для них не существует проблемы заказа в виде только
больших партий, и можно избавиться от риска экономических потерь при
уценках и распродажах. Кроме того, несложно выпустить и дополнительную
партию изделий любого объема, если конъюнктура этого потребует.
Как видно из сказанного, между разными средствами реализации одних и
тех же изделий должна существовать взаимосвязь, поскольку иначе процесс
перехода от одних средств к другим (конвертация проектов) окажется за-
трудненным. Такая взаимосвязь оказывает влияние на архитектуры, элек-
трические характеристики и конструктивные параметры как БИС/СБИС
программируемой логики, так и БМК. Например, были выпущены специа-
лизированные репрограммируемые FPGA с триггерной памятью конфигура-
ции, предназначенные для макетирования схем, реализуемых на определен-
ных масочных БМК (фирма Quickturn System Inc.). Были созданы также
специализированные масочные БМК (Hard Wire), по архитектуре идентич-
ные схемам известных репрограммируемых FPGA. И в дальнейшем FPGA
подстраивались под конкретные БМК с целью их эффективного макетиро-
вания, а определенные БМК приспосабливались по логической структуре,
библиотеке схемных решений и электрическим параметрам к конкретным
FPGA.
Проиллюстрируем высказанные тезисы некоторыми примерами. Практика
фирмы Xilinx дает следующие цифры: почти все проекты с логической ем-
костью меньше 20 тыс. вентилей остаются реализованными на микросхемах
программируемой логики и в качестве конечной продукции. Для проектов
с логической емкостью в диапазоне от 20 до 50 тыс. вентилей могут прини-
маться различные решения на основе конкретной ситуации. Для проектов с
логической емкостью больше 50 тыс. вентилей конвертация, как правило,
целесообразна. Указанные цифры довольно быстро изменяются в сторону
увеличения и, соответственно этому, конвертации в направлении "ПЛИС -
ASIC" подвергается все меньший процент проектов. Большинство конверти-

руемых проектов переводится в схемы на БМК. В схемы, реализованные по
методу стандартных ячеек и, тем более, в полностью заказные схемы кон-
вертация производится реже, т. к. это обычно экономично только для очень
сложных или высокотиражных проектов.
Для конвертации своих проектов фирма Хilinх несколько лет назад создала
микросхемы Hardwire FpgASIC, обеспечивающие полную совместимость
контактов ввода/вывода при замещении ими конвертируемых FPGA. Каж-
дая микросхема Hardwire FpgASIC соответствует функционированию и осо-
бенностям конкретной FPGA. Применение этих микросхем в два раза уско-
ряло процесс конвертации в сравнении с традиционным процессом проек-
тирования на основе БМК. Конвертация основана на заранее созданной и
проверенной базе данных, тогда как обычный перевод схемы из реализации
на FPGA в реализацию на БМК нуждается в повторной верификации, что
сопряжено с большими затратами времени.
Если исходный проект выполнен на нескольких FPGA, то можно удешевить
его переводом лишь некоторых FPGA в базис HardWireFpgASIC. Замена
лишь части FPGA на HardWireFpgASIC и оставление других FPGA в обыч-
ном виде позволяет использовать их в традиционном варианте с возмож-
ностью реконфигурации. Перевод схемы в реализацию на HardWireFpgASIC
позволяет также исключить соответствующую память загрузки конфигура-
ции, что дополнительно упрощает и удешевляет схему.
В противовес сказанному следует отметить, что реальная ситуация с про-
дукцией Hardwire не совпала с прогнозом, и это направление не стало
"серьезным бизнесом", имеющим достаточное число заказчиков. Ограни-
ченное применение конвертации имеет несколько причин. Во -первых, часто
не оправдываются ожидания большой тиражности выпуска изделия, во -
вторых, нередко через полгода -год у производителя возникает желание вне-
сти в проект изменения, для чего хороши именно ИСПС, в третьих, с ус-
ложнением схем и появлением в них разнородных областей все сложнее
воспроизвести ИСПС в БМК или других ASIC с сохранением временных
соотношений сигналов и работоспособности и быстродействия фрагментов
ИСПС и схем в целом. Так или иначе, но фирма ХШпх прекратила усилия
по внедрению микросхем Hardwire и сосредоточилась на удешевлении своих
FPGA.
Почти одновременно с прекращением предложений средств конвертации
Hardwire фирмой ХШпх фирма Altera выступила с новым решением задачи
перевода проектов, реализованных на ПЛИС, в проекты типа ASIC, объявив
о выпуске микросхем HardCopy. Это решение дает удобства для тех, кто ис-
пользовал ПЛИС фирмы на стадии проектирования и затем намеревается
переключиться на реализацию по методу стандартных ячеек для тиражной
продукции. Сообщается, что перевод проекта на микросхемы HardCopy дает
70% экономии площади кристалла при снижении стоимости микросхем и
pin -совместимости исходного и конечного вариантов. Переход от проекта,

реализованного на ПЛИС, к эквивалентному проекту на ASIC производится
приблизительно за 8 недель. С учетом времени, которое будет затрачено за-
казчиком на верификацию проекта, время до выпуска продукции оценива-
ется приблизительно в 16 недель. Технология HardCopy, по мнению фирмы
Altera, дает хорошие предпосылки для повышения эффективности процесса
конвертации, причем она нацелена, в основном, на конвертацию проектов
высокой сложности.
Фирма AMI (American Microsystems Inc.) извещает об эффективной конвер-
тации в ASIC -реализацию таких сложных ПЛИС, как семейство Virtex фир-
мы Xilinx и семейство APEX фирмы Altera. Имея для такой конвертации от-
работанный набор схемных решений, фирма AMI обеспечивает быструю
конвертацию проектов, содержащих разнообразные блоки, в том числе DLL,
PLL, PCI, блоки памяти с разнообразными организациями, различные вари-
анты схем ввода/вывода. Микросхемы семейства XL -3 фирмы AMI дешевле
своих аналогов из семейств Virtex и APEX приблизительно в 4 раза.
1.9.2. Конфигурирование БИС/СБИС

Способ конфигурирования БИС/СБИС ПЛ, т. е. настройки их на опреде-
ленное функционирование, зависит от типа программируемых элементов.
Для микросхем с необратимым изменением состояний программируемых
элементов (типов fuse и antifuse) и реконфигурируемых микросхем с энерго-
независимой памятью конфигурации (EPROM, EEPROM, Rash) для про-
граммирования используются специальные воздействия электрическими
сигналами, характеристики которых существенно отличаются от характери-
стик рабочих (логических) сигналов. Конфигурирование таких микросхем
может производиться вне создаваемой системы с помощью программаторов
или же в составе системы (т. е. при сохранении монтажа микросхемы на
плате), но также с использованием специальных режимов. При этом для
процессов записи информации требуются повышенные напряжения про-
граммирования (для микросхем семейств МАХ7000 и МАХ9000 фирмы
Altera, например, это 12 В при рабочем напряжении питания 5 В). Для ста-
рых микросхем вследствие этого требовались несколько источников пита-
ния, более новые стали снабжаться внутренними преобразователями рабо-
чего напряжения в повышенное напряжение программирования.
Для БИС/СБИС ПЛ со статической памятью конфигурации ее загрузка не
требует каких -либо специальных электрических режимов, и процесс кон-
фигурирования состоит в передаче в микросхему информации по заданному
протоколу и с фиксированными форматами данных. Переданная информа-
ция обеспечивает создание требуемых соединений в логических блоках,
блоках ввода/вывода и подключение их к трассам межсоединений. Опера -
ция конфигурирования выполняется после каждого включения питания,

причем, если установлены специальные загрузочные БИС, сам факт очеред-
ного включения питания автоматически инициирует процесс конфигуриро-
вания, который может повторяться неограниченное число раз. Отсутствие
специальных электрических режимов для записи информации в память
конфигурации обеспечивает возможность ее проведения в работающей схе-
ме, причем возможна и частичная реконфигурация, относящаяся лишь к
части системы.
Конфигурирование БИС/СБИС ПЛ со статической (триггерной) памятью
конфигурации представляет собой запись во внутренние регистры (триг-
геры) данных, задающих структуру блоков системы и их межсоединений.
Каждый бит настроечных данных задает состояние соответствующему триг-
геру, управляющему программируемым ключом в настраиваемой схеме.
БИС/СБИС ПЛ обычно имеет несколько возможных режимов конфигурирова-
ния (например, у FPGA XC4000 фирмы Хilinх их 6, у СБИС семейства Virtex
той же фирмы 4, у микросхем семейства Spartan — 2). У способов конфи-
гурирования микросхем разных фирм и разных типов много общего. Рас-
смотрим, например, как конфигурируется СБИС ПЛ типа SOPC семейства
Virtex.
Для конфигурирования этой микросхемы используются как специализиро-
ванные выводы, так и выводы, которые после завершения конфигурирова-
ния могут играть роль выводов общего назначения. К специализированным
относятся выводы М2, Ml, МО, на которых задается код того или иного ре-
жима, вывод для синхросигналов процесса конфигурирования, выводы
PROGRAM, DONE и выводы периферийного сканирования TDI, TDO,
TMS, TCK (см. разд. 2.6). Вывод синхросигнала может быть выходом, когда
этот сигнал генерируется микросхемой, или входом, когда поступает извне.
Возможные способы конфигурирования:
- пассивный последовательный (Slave -serial mode);
- активный последовательный (Master -serial mode);
- байт -последовательный (SelectMAP mode);
- периферийного сканирования.
В пассивном последовательном режиме микросхема получает данные конфи-
гурирования в виде потока битов из последовательной памяти PROM или
другого источника. Синхронизация осуществляется от внешнего источника,
каждый положительный фронт синхросигнала вводит бит данных от входа
DIN. Несколько микросхем могут быть соединены в цепочку для конфигу-
рирования в едином процессе от общего потока битов. В этом случае после
завершения конфигурирования очередной микросхемы данные конфигура-
ции для следующих микросхем появляются на выводе DOUT микросхемы,
завершившей конфигурирование.
В активном последовательном режиме выходной синхросигнал микросхемы

подается на последовательное ЗУ, с которого на вход DIN микросхемы по-
ступает последовательный поток битов конфигурации. Микросхема воспри-
нимает каждый бит под управлением положительного фронта синхросигна-
ла. После загрузки очередной микросхемы, входящей в цепочку, данные для
следующей снимаются с выхода DOUT той микросхемы, которая закончила
конфигурирование. Для синхронизации процесса можно выбирать частоту
из широкого диапазона значений. По умолчанию используется наименьшая
частота 2,5 МГц. Максимальная частота — 60 МГц. Устанавливаемые часто-
ты, естественно, должны соответствовать возможностям используемых
PROM и включенных в цепочку микросхем. При включении питания уста-
навливается частота 2,5 МГц. Если не поступит команда на изменение этого
значения (опция ConfigRate в программе генерации битового потока кон-
фигурации), процесс продолжится до конца на частоте 2,5 МГц.
В байт -последовательном режиме время конфигурирования минимально.
Используется байт -последовательный поток данных, которые записываются
в микросхему с учетом флажка ее готовности BUSY. Байтовый поток задает-
ся от внешнего источника, как и сигналы тактирования, разрешения работы
CS и WRITE. В этом режиме данные могут и читаться. Если сигнал WRITE
пассивен, то данные конфигурации читаются из микросхемы (этот процесс
есть часть процесса Readback). В режиме SelectMAP также можно конфигу-
рировать одновременно несколько микросхем, но в этом случае они вклю-
чаются параллельно по входам синхронизации, данных, WRITE и BUSY.
Загружаются микросхемы поочередно путем соответствующего управления
сигналами разрешения их работы CS.
В режиме периферийного сканирования конфигурирование осуществляется
исключительно через выводы порта тестирования ТАР (Test Access Port) ин-
терфейса JTAG. Используется специальная команда CFG_IN, позволяющая
входным данным от вывода TDI преобразовываться в пакеты данных для
внутренней шины конфигурации микросхемы.
Процесс конфигурирования для микросхем Virtex состоит из трех этапов:
очистки памяти конфигурации, загрузки в нее данных и активизации логи-
ческих схем, участвующих в процессе.
Конфигурирование начинается автоматически после включения питания, но
может быть и задержано пользователем с помощью сигнала PROGRAM,
снятие которого запрещает конфигурирование. Завершение очистки памяти
выявляется с помощью сигнала INIT, а завершение всего процесса — с по-
мощью сигнала DONE.
Данные для загрузки памяти конфигурации формируются системой автома-
тизированного проектирования.
Реконфигурация в системе (ISP, In -System Programmability) — одно из важ-
нейших достоинств СБИС ПЛ, позволяющее легко изменять логику их ра -
боты. Потребности в изменениях возникают для устранения не выявленных

при первоначальном тестировании ошибок, для модернизации (Upgrade)
систем и в системах с многофункциональным использованием блоков. На-
личие ISP облегчает работу с современными СБИС ПЛ, корпуса которых
имеют большое число миниатюрных и легко повреждаемых выводов, что
делает однократность установки микросхем на плату весьма желательной.
Кроме того, реконфигурация микросхемы на расстоянии с использованием
средств телекоммуникации или сети Интернет дает и экономическую выго-
ду, поскольку обходится дешевле, чем вызов техника для проведения этой
операции у заказчика.
Возможности программирования в системе растут, если при проектирова-
нии часть функциональных возможностей СБИС ПЛ оставлять свободной,
имея также запас по скорости и ресурсам межсоединений. При реконфигу-
рации в системе должно сохраняться назначение внешних выводов, иначе
потребуется изменить монтаж печатных плат.
Среди СБИС ПЛ имеются и такие, в которых реализованы одновременно
триггерная и энергонезависимая память конфигурации. В этом случае конфи-
гурирование СБИС ПЛ можно производить без внешних источников дан-
ных путем автоматической загрузки триггерной памяти из энергонезависи-
мой. Конфигурирование СБИС ПЛ выполняется с помощью интерфейса
JTAG.
1.9.3. Засекречивание проектов

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

ванию или реконструкции проектов зависит от характера проекта и схемо -
технологии микросхемы.
В начале развития программируемых микросхем, когда они были представ-
лены простыми комбинационными ПЛМ и ПМЛ, проекты можно было ре-
конструировать, подавая на схему все возможные комбинации входных сиг-
налов и фиксируя соответствующие им выходные комбинации сигналов. Из
полученных сведений можно вывести булевы функции, воспроизводимые
схемой, и, следовательно, реконструировать ее в соответствующем логиче-
ском базисе.
Более сложные схемы программируемой логики, практически, не поддаются
такому методу реконструкции. Они имеют большое число вводов/выводов,
назначение которых заранее не известно (например, у двунаправленных вы-
водов). Уже одно это создает очень большие сложности для логического
анализа проектов, т. к. неизвестно, подавать ли на вывод входной сигнал,
снимать ли с него выходной сигнал, или же использовать его поочередно
в обоих вариантах. Сложность внутренней структуры микросхем, наличие в
них фрагментов, являющихся последовательностными схемами, и различ-
ных встроенных функций чрезвычайно затрудняют логический анализ про-
ектов.
Для клонирования проектов нужно раздобыть сведения о содержимом памя-
ти конфигурации микросхемы (битовом потоке конфигурирования). По
возможностям защиты этой информации от несанкционированного доступа
микросхемы разных схемотехнологий существенно различаются.
Однократно программируемые 5ИС/СБИС с пробиваемыми при конфигури-
ровании перемычками наиболее защищены от взлома. Для их эксплуатации
битовый поток конфигурирования не нужен, поскольку программирование
перемычек завершается на стадии изготовления микросхемы. В распоряже-
нии взломщика находится лишь сам кристалл. Для раскрытия проекта тре-
буется определить состояние всех перемычек, получив для каждой ответ на
вопрос "замкнута -разомкнута". Это чрезвычайно трудно сделать по следую-
щим причинам. Число перемычек очень велико (сотни тысяч). Наблюдени-
ем поверхности кристалла нельзя выявить не только состояние перемычек,
но и их местоположение, т. к. по виду они не отличаются от простого пере-
сечения шин. Чтобы рассмотреть перемычку и определить ее состояние
(наличие проводящей нити), нужно сделать в ней несколько поперечных
срезов, а это, вероятнее всего, разрушит остальную часть кристалла. Таким
образом, для выявления состояний всех перемычек потребуется испортить
столько кристаллов, сколько перемычек имеется на каждом из них. Задава-
ясь вопросом, есть ли проекты, ценность раскрытия которых оправдает за-
траты на их взлом, можно ответить, что возможность раскрытия проекта
в данных ситуациях есть категория скорее теоретическая, чем практическая.
Описанная ситуация касается микросхем фирмы Actel с перемычками

PLICE (ONO), фирмы QuickLogic с перемычками типа ViaLink, фирмы
Xilinx с перемычками типа MicroVia.
Репрогроммируемые БИС/СБИС с энергонезависимой памятью конфигурации
(EPROM, EEPROM, Flash) в рабочих режимах также не используют файлы
конфигурирования. Взломщик, как и в предыдущем случае, имеет в своем
распоряжении сам кристалл, в котором скрыта информация о проекте. Чте-
ние памяти конфигурации может быть запрещено битом секретности, сбро-
сить который можно только при операции стирания всего содержимого этой
памяти (заметим, что в литературе имеются сведения о случаях проникнове-
ния в запертую память конфигурации с помощью специальных электриче-
ских режимов микросхемы). Исследовать сам кристалл проще, чем кристалл
с перемычками, но также очень нелегко. Если предположить, что располо-
жение транзисторов с плавающими затворами, состояния которых програм-
мируются, известно или может быть визуально определено, то задача рас-
крытия проекта сводится к исследованию состояний каждого из многих ты-
сяч или даже миллионов транзисторов. Наличие или отсутствие заряда в
плавающем затворе можно выявить без разрушения кристалла несколькими
способами. Заряды создают электрические поля, которые можно обнаружи-
вать специальными методами, можно использовать также электронный
микроскоп или материалы, накладываемые на кристалл и изменяющие цвет
под воздействием электрических полей. Трудоемкость и стоимость исследо-
вания состояний плавающих затворов остаются все же очень высокими, и
подобные исследования имеют смысл только для высокоценных проектов.
Далее, даже если станут известны местоположение и состояния всех транзи-
сторов, то для простого клонирования проекта нужно транслировать эти
сведения в битовый поток конфигурирования БИС/СБИС, а для реконст-
рукции проекта еще и в саму схему. Решение этих задач очень сложно, по-
этому схемы с энергонезависимой памятью конфигурации можно считать хо-
рошо, хотя и не абсолютно, защищенными от взлома.
Самыми уязвимыми для взломщиков являются БИС/СБИС программируемой
логики с триггерной памятью конфигурации, которую нужно загружать при
каждом включении питания от внешнего источника хранимых данных. Для
клонирования проекта достаточно прочитать содержимое этой внешней па-
мяти и использовать его для конфигурирования клонов. Установление соот-
ветствия недокументированного битового потока конфигурирования и внут-
ренней структуры схемы (реконструкция проекта) является более сложным,
но не считается невозможным.
С целью повышения защищенности проектов, в первую очередь для
БИС/СБИС с триггерной памятью конфигурации, принимается ряд мер:
организационных, юридических, конструктивных и др.
К организационным мерам можно отнести договоренность с поставщиком
о поставке немаркированных кристаллов, что эффективно затрудняет по-
пытки взлома проектов.
К юридическим мерам можно отнести встраивание в проект некоторого не-

документированного идентификатора (например, инициалов автора проекта).
К конструктивным мерам можно отнести покрытие кристалла и его связей
с другими кристаллами непроницаемым слоем (например, эпоксидной смо-
лой). Естественно, это имеет и отрицательные последствия, не позволяя
в дальнейшем дорабатывать проект и ухудшая тепловой режим кристалла.
Сходен с этим прием размещения трассы передачи битового потока конфи-
гурирования между энергонезависимой памятью и микросхемой в скрытых
внутренних слоях печатной платы.
Можно вообще обойтись без энергонезависимой памяти конфигурирования,
если вместо нее разместить на плате автономный источник питания (ли-
тиевую батарею), который будет сохранять запрограммированную конфигу-
рацию в самой триггерной памяти микросхемы. Однако в этой ситуации
потребуются специальные схемы для изоляции источника автономного пи-
тания от всех цепей, кроме памяти конфигурации, что увеличивает площадь
кристалла и снижает его быстродействие. Кроме того, при истощении бата-
реи схема все же разрушится. Разрушение может произойти и от мгновен-
ной потери питания вследствие удара, действия помехи и т. д.
В качестве приема защиты проекта используется и разделение его между
частями с триггерной и энергонезависимой памятью конфигурации при на-
личии в обеих частях одного и того же уникального идентификатора, кото-
рый должен согласовываться.
Можно использовать в ПЛИС с энергонезависимой и с триггерной памятью
конфигурации сдвигающих регистров с линейными обратными связями,
причем первая ПЛИС имеет целью только разрешать работу второй. Слож-
ность расшифровки функционирования сдвигающего регистра связана с его
структурой и разрядностью.
Существуют и другие возможности затруднить процесс взлома проектов,
реализованных в БИС/СБИС программируемой логики [45].
1.10. Способы оценки параметров ПЛИС.

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

рынок. Для БИС/СБИС с программируемыми структурами модификация
реализуемых алгоритмов производится без изготовления наборов фотошаб-
лонов.
Области применения интегральных схем разных видов в качестве оконча-
тельной продукции, как показано на рис. 1.33, зависят от тиражности их
производства (предполагается, что тиражность растет в направлении слева
направо).
SPLD
Рис. 1.33. Связь объемов производства изделий с элементной базой,

целесообразной для их реализации
При объеме производства изделия меньше 50—70 тыс. шт. применение

FPGA и CPLD, согласно мнению ряда специалистов, становится стоимост -
но -эффективной альтернативой для базовых матричных кристаллов и более
сложных ASIC. Подробные соображения по выбору элементной базы при
разных условиях разработки проектов приводятся в гл. 2.
Область применения программируемых схем в качестве прототипов при от-
работке систем значительно шире.
Микросхемы с программируемой структурой конкурируют со стандартными
ИС, с базовыми матричными кристаллами и с заказными схемами, реализо-
ванными по методу стандартных ячеек. Активнее всего программируемые
схемы отвоевывают области применения у стандартных ИС невысокого
уровня интеграции и у базовых матричных кристаллов. В меньшей степени

они вытесняют ИС со стандартными ячейками, хотя, возможно, это поло-
жение вскоре может измениться. Нельзя не отметить, что в последнее время
ИСПС хорошо дополняют схемы со стандартными ячейками, позволяя соз-
давать системы разного назначения с помощью одного и того же набора фо-
тошаблонов за счет модификации программируемой части кристалла. Под-
робнее об областях применения различных типов микросхем также говорит-
ся в гл. 2.
Достоинства ПЛИС рождают спрос на них, спрос стимулирует предложе-
ние, в результате появилось много разновидностей ПЛИС, в которых не-
просто ориентироваться без понимания особенностей различных архитек-
тур. Знание архитектур и особенностей существующих ПЛИС нужно для
успешного выполнения ряда этапов процесса проектирования устройств и
систем на их основе, в частности этапа выбора элементной базы и оценки, а
при необходимости, и "ручной" коррекции результатов работы компилятора
САПР по синтезу схемной части проекта.
Свойства и возможности ПЛИС выражаются многими параметрами, поэто-
му разумно ранжировать их по степени важности для того или иного при-
менения и, после выбора претендентов на использование, переходить к де-
тальному ознакомлению с их характеристиками. Разнообразие и насыщен-
ность все более расширяющегося рынка ПЛИС не отменяет, а даже
обостряет для системотехников необходимость глубокого знания особенно-
стей и сравнительных характеристик существующих микросхем. Подробное
описание сложной программируемой микросхемы в фирменных справочни-
ках может занимать десятки или даже сотни страниц, и его изучение требует
немалого времени. Сравнительная оценка ПЛИС затрудняется не только
многочисленностью их параметров, но и тем, что методика определения не-
которых параметров у разных фирм не только различна, но порою приводит
к существенно расходящимся результатам.
При выборе микросхем для применения в конкретном проекте приходится
оценивать многие их параметры, и, как обычно в подобных ситуациях, воз-
никают трудности учета разнородных характеристик. Тем не менее, не при-
ходится говорить о формировании многокритериальной функции качества,
поскольку практика проектирования не подтвердила, как и следовало ожи-
дать, эффективности такого подхода.
1.10.1. Об оценке логической сложности

(уровня интеграции) ПЛИС
Сложность программируемых микросхем с давних пор оценивается, как уже
было сказано выше, с использованием понятия "число эквивалентных венти-
лей", причем под вентилем понимают обычно логический элемент 2И -НЕ.
В свое время программируемые схемы (базовые матричные кристаллы) со-

держали именно такие или близкие к ним вентили, поэтому подсчет числа
вентилей на кристалле давал достаточно точную оценку его логической ем-
кости (логической мощности, уровня интеграции). Однако для последую-
щих ПЛИС, более разнообразных по схемотехнике, стало невозможным
просто подсчитывать число вентилей на кристалле, поскольку схемы кри-
сталла отнюдь не состояли из таких вентилей. На начальном этапе развития
ПЛИС разнобой в подходе разных производителей к оценке логической
сложности схем очень затруднял их сопоставление по этому параметру.
На ранней стадии развития ПЛИС упорядочить эту ситуацию удалось кон-
сорциуму компаний PREP (Programmable Electronics Performance Corporation).
Согласно широко признанной в свое время методике подсчета по рекомен-
дациям этого консорциума, оценка сложности ИС проводится с помощью
набора эталонных схем. Для измерения сложности кристалла определяется
максимально возможное число реализаций в нем каждой схемы из этого
набора. Из практики работы с взятым для образца БМК сложность, выра-
женная в числе эквивалентных вентилей, для каждой эталонной схемы из-
вестна. Далее можно получить и сложность оцениваемого кристалла по дан-
ной эталонной схеме, определяемую как произведение ее сложности на
максимально возможное число реализаций таких схем на кристалле. В каче-
стве эталонных схем были выбраны 10 типовых функциональных узлов
(регистры, счетчики, дешифраторы и т. д.). Усредненная по всем эталонным
схемам величина характеризует итоговый (окончательный) показатель слож-
ности микросхемы в целом.
Идея эталонного (тестового) набора функциональных узлов явилась основой
и для созданных другими авторами, в частности в работе [4], методик изме-
рения сложности (а также и быстродействия) программируемых микросхем.
Далее ситуация осложнилась, стали широко применяться крупнозернистые
функциональные блоки сложной структуры, и вместе с ними появились
спорные интерпретации различных параметров. Разнобой в методиках оцен-
ки логической емкости кристалла увеличивался, и параметр "число эквива-
лентных вентилей" становился все более шатким. Этот параметр, тем не ме-
нее, чаще всего фигурирует в качестве одного из основных в таблицах, при-
водимых в справочниках фирм -изготовителей ПЛИС, хотя нередко вместо
этой единой оценки сложности кристалла производители стали указывать
отдельно размерности разных по функциональному назначению областей
кристалла или даже переходить к прямому сравнению своей продукции со
сходной продукцией других фирм, выполняемому по выбранным конкрет-
ным ситуациям.
Сложность ПЛИС первых поколений достаточно точно оценивалась числом
эквивалентных вентилей в двух вариантах — общим числом (Total) и/или
пользовательским (Usable), поскольку не все элементы схемы кристалла мо -
гут быть использованы системотехником в его проекте. К сожалению, не

всегда в документации на схему четко указывается, о каком варианте оценки
идет речь (и это относится не только к параметру "число эквивалентных
вентилей"). В последнее время, как правило, приводится число пользова-
тельских эквивалентных вентилей. В дальнейшем изложении определение
"эквивалентные" для краткости будет иногда заменяться термином "число
вентилей".
В ходе дальнейшего развития ПЛИС положение с оценкой их сложности
осложнилось еще более. В качестве функциональных блоков стали приме-
нять табличные преобразователи (LUT -блоки), которые допускают неодно-
значное использование — они способны воспроизводить логические функ-
ции или работать в качестве блоков памяти с той или иной организацией.
В зависимости от режима работы существенно меняется и оценка сложности
одного и того же фрагмента схемы, поскольку эквивалентные реализации
разных режимов работы LUT -блоков средствами БМК сильно различаются
по сложности (в несколько раз). На этом этапе возникли понятия числа ло-
гических вентилей и числа системных вентилей. При подсчете числа логиче-
ских вентилей предполагается работа функциональных блоков в режиме
воспроизведения логических функций. При подсчете числа системных вен-
тилей предполагается, что часть функциональных блоков работает в режиме
блоков памяти и, следовательно, имеет другую эквивалентную сложность.
Естественно, числа логических и системных вентилей в одной и той же
микросхеме не совпадают.
Позднее положение с оценкой сложности ПЛИС дополнительно осложни-
лось из -за появления на кристалле специализированных областей встроен-
ной памяти и других структурных неоднородностей. Встроенная память,
в частности, также может применяться как По прямому назначению, так и
для воспроизведения логических функций табличным методом.
Подсчитывая число вентилей в своих микросхемах, три крупнейших произ-
водителя ПЛИС занимают неодинаковые позиции. К методике оценки ло-
гической емкости программируемой микросхемы, принятой фирмой Xilinx,
склоняется также фирма Altera, тогда как фирма Actel пользуется другой ме-
тодикой, приводящей к иным результатам, и считает показатели фирм Хilinх
и Altera завышенными. Например, фирмы Actel и Cypress, указав для одной
из своих ПЛИС семейства pASIC сложность в 12 тыс. эквивалентных венти-
лей, сопроводили свою оценку замечанием, что по методике измерений
фирм Altera и Xilinx это соответствовало бы сложности в 36 тыс. эквива-
лентных вентилей. Из сказанного следует, что при" рассмотрении параметра
сложности ПЛИС нужно внимательно следить за тем смыслом, который
вкладывается в каждом конкретном случае в приводимый показатель.
Методика фирмы Altera основана на сравнении аппаратных затрат при реа-
лизации одних и тех же устройств в двух вариантах: на оцениваемой ПЛИС
и на известном базовом матричном кристалле LCA300K, логической осно-

вой которого являются вентили, подобные принятым в качестве эквива-
лентных.
Основная проблема оценки логической емкости ПЛИС создается наличием
в ней как логической части (FPGA, CPLD), так и модулей памяти. Для
оценки логической емкости микросхемы в этих условиях используются не-
сколько параметров [4]:
- емкость логического массива;
- логическая емкость массива памяти при реализации логических функций;
- логическая емкость массива памяти при реализации запоминающих уст-
ройств;
- диапазон изменения логической емкости;
- типичная логическая емкость.
Емкость логического массива определяется как произведение логической ем-
кости одного логического элемента q на их число М в данной ПЛИС. Для
нахождения емкости одного логического элемента рассматриваются схемы,
которые могут быть в нем реализованы. Эти схемы сопоставляются с биб-
лиотечными модулями эталонного БМК (LCA300K), что дает их оценку в
числах эквивалентных вентилей. За логическую емкость элемента q прини-
мается число эквивалентных вентилей, усредненное по всему множеству
проанализированных схем. Таким образом, емкость логического массива
L1 = qN1.
Логическая емкость массива памяти при реализации логических функций L2
определяется как произведение логической емкости модуля памяти р на
число N2 таких модулей в данной ПЛИС. Параметр р определяется опять -
таки на основе анализа библиотечных модулей БМК — это среднее число
эквивалентных вентилей, необходимых для воспроизведения функций, реа-
лизуемых модулем памяти. Таким образом, LI = pN1.
Логическая емкость массива памяти при реализации запоминающих, устройств
L3 определяется как произведение числа s вентилей БМК, необходимых для
создания схемы хранения одного бита данных, на емкость М массива памя-
ти ПЛИС. Таким образом, L3 = sM.
Диапазон изменения логической емкости. Значение логической емкости ПЛИС,
как можно видеть, зависит от способа использования модулей памяти.
Оценки сложности отдельных схемных элементов, принятые фирмами Altera
и Xilinx, таковы, что вариант с использованием памяти по прямому назна-
чению даст верхнюю границу диапазона значений логической емкости
ПЛИС, а вариант с использованием всей памяти для воспроизведения логи-
ческих функций — нижнюю. Следовательно, минимальная логическая ем-
кость ПЛИС Lmin = L1 + L2, а максимальная Lmax = L1 + L3.
Типичная логическая емкость. Для оценки типичного значения логической

емкости кристалла привлекаются статистические данные о доле массива па-
мяти, используемой для реализации логических функций, усредненные по
множеству проанализированных проектов. Как правило, эта доля лежит в
пределах 15—35%. Обозначив эту долю через d, для нахождения типичной
логической емкости кристалла Ltyp, выраженной в числе системных венти-
лей, можно записать соотношение Ltyp = L1 + dL2 + (1 — d)L3.
Приведенные формулы справедливы для оценки основной части ПЛИС,
занятой функциональными ячейками и памятью. Наличие областей с бло-
ками ввода/вывода и другими блоками в некоторой мере изменяет соотно-
шение между указанными параметрами.
В справочных данных фирм часто указывается типичный диапазон числа вен-
тилей, в котором нижняя граница соответствует числу вентилей в составе
функциональных блоков, работающих в режиме воспроизведения логиче-
ских функций, а верхняя определяется при указании доли этих блоков, реа-
лизующих функции памяти (обычно это 20—30%).
Укажем для примера цифры, полученные фирмами Altera и Xilinx для своих
популярных семейств. Фирма Altera для семейства FLEX10K приняла сле-
дующие параметры: q = 12, р = 150, s = 4. Фирма Xilinx для семейства
Virtex II считает каждую логическую ячейку в логическом режиме соответст-
вующей 12 системным вентилям, а в режиме распределенной памяти — 64 -м
(16 битх4 ЛЭ/бит). Каждая схема автоподстройки по задержкам синхросиг-
налов DLL дает 7К вентилей, каждая логическая ячейка в режиме програм-
мируемого элемента задержки — 112 вентилей, каждый бит блока памяти —
4 системных вентиля.
Цифра 4 как оценка эквивалента одного бита памяти при реализации памя-
ти с помощью логических вентилей, принятая многими фирмами, объясняет
резкий рост оценок уровня интеграции современных ПЛИС относительно
их недавних предшественников. Действительно, введение в состав ПЛИС
относительно больших массивов встроенной памяти при оценке их сложно-
сти числом эквивалентных вентилей путем умножения емкости в битах на
четыре сразу дает большую прибавку к оценке уровня интеграции. Иными
словами, скачкообразный рост расчетного уровня интеграции современных
сложных ПЛИС только отчасти объясняется совершенствованием процессов
их производства и во многом стал следствием принятой методики оценки
логической емкости микросхем.
При выборе подходящей ПЛИС для своего проекта системотехник не может
полагаться на какой -либо параметр микросхем или даже 2—3 параметра.
Проблема выбора достаточно сложна и требует проведения квалифициро-
ванного анализа совокупности параметров ПЛИС с учетом специфики под-
лежащего реализации проекта.
Почему нельзя полагаться на параметр "число вентилей"? Во -первых, из -за

различия архитектур ПЛИС. Логические блоки ПЛИС уже не являются
"мелкозернистыми" и представляют собой довольно сложные схемы. Какой
будет эффективность использования логических ресурсов кристалла при реали-
зации данного проекта? Называя цифру "число вентилей", производители
ПЛИС часто имеют в виду 100% их использования (некоторые фирмы ука-
зывают более скромные цифры). На самом деле, в составе сложных логиче-
ских блоков может оказаться значительная доля неиспользуемых ресурсов.
Кроме того, проект может исчерпать трассировочные ресурсы раньше, чем
будет использована имеющаяся на кристалле логика, и, таким образом, часть
логических ресурсов "пропадет".
Очень спорны вопросы пересчета встроенной (дискретной) и распределенной
памяти кристалла, т. е. памяти, реализованной в виде специальных блоков,
и находящейся в составе функциональных блоков типа LUT, в число экви-
валентных вентилей. В этом случае получаемое число эквивалентных венти-
лей резко зависит от того, в каком качестве будет служить память. Если она
применяется по своему назначению для создания той или иной конфигура-
ции ЗУ (очень часто в проектах интенсивно используются блоки FIFO), то
ее присутствие сильно увеличивает оценку числа эквивалентных вентилей
на кристалле. А какую роль будет играть память в реализуемом проекте —
это еще вопрос.
Далее, большую роль играет технология проектирования схем. Например,
схема может быть реализована с помощью неэффективного компилятора
САПР или же вручную доработана опытным специалистом. Ясно, что за-
траты оборудования на реализацию проекта для этих вариантов могут су-
щественно отличаться. Ясно также, что, пользуясь оценками по затратам
оборудования на построение разных функциональных узлов, фирмы -произ-
водители обеспечивали высококачественное проектирование. Сможет ли
потребитель для своего проекта обеспечить такое же качественное проекти-
рование?
Кроме того, разные производители включают в состав средств для счета вен-
тилей разные ресурсы. Могут быть включены или не включены в этот состав
буферные элементы, схемы граничного сканирования по интерфейсу JTAG,
дополнительные схемы быстродействующих декодеров и т. д. Понятно, что
это тоже вносит разночтения в приводимые оценки.
Отмеченные обстоятельства не исчерпывают проблематику сложности оцен-
ки логической емкости кристалла, достоверной для конкретного проекта, но
убедительно свидетельствуют о сугубо ориентировочном характере группы па-
раметров, связанных с понятием "число эквивалентных вентилей".
Наряду с числом эквивалентных вентилей в числе параметров ПЛИС указы-
ваются числа макроячеек (для CPLD), логических блоков или логических ячеек
(для FPGA и микросхем комбинированной архитектуры). Сведения об этих
параметрах, пожалуй, более репрезентативны, т. к. говорят о числе функ-

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

Быстродействие ПЛИС характеризуется либо задержками распространения
сигналов по указанным путям, либо максимальными частотами их работы
в указанных условиях.
Пути распространения сигналов в классических CPLD жестко предопреде-
лены их архитектурой и задержки по путям от любого входа до любого вы-
хода (Pin -to -pin, Corner -to -corner, Clock -to -pin) могут достаточно хорошо
характеризовать быстродействие CPLD.
Пути распространения сигналов в FPGA разнообразны, и для них с целью
оценки быстродействия целесообразно пользоваться максимально возмож-
ной частотой тактирования, причем эта частота может быть указана для раз-
личных схем. Часто указывают либо максимально возможную частоту ра-
боты счетчика FCNT либо частоту работы (тактирования) схемы в целом Fc,
называемую системной. Обычно системная частота приблизительно вдвое
ниже, чем частота работы счетчика.
Могут быть указаны и другие частоты, например, частота тактирования
передач типа "регистр -регистр" Frr или частота F m a x , называемая просто
"максимальной" без конкретного уточнения схемы, к которой она относится.
Именно эта частота фигурирует в описаниях многих микросхем, хотя ясно,
что без указания схемы, о тактировании которой идет речь, приводимая
цифра теряет смысл. Иногда понятно, как следует трактовать величину Fmax
(например, в случае получения результата при однократном прохождении
сигналов от входов к выходам микросхемы). Но в более сложных ситуациях
(например, при использовании в схеме обратных связей) требуется конкрет-
ная оценка максимальных частот тактирования для данного устройства, реа-
лизованного в той или иной микросхеме. Тракт прохождения сигналов в
цифровом устройстве можно представить в виде последовательности секций
"регистр -комбинационная схема -регистр". Согласно формулам расчета па-

раметров синхросигналов для устройств, содержащих подобные секции [27],
минимальный период синхроимпульсов для однофазной системы синхрони-
зации определяется как
Т= 2А + Tsu + Ттг.mах + Ткц.тах,
где А — нестабильность положения фронта синхроимпульса во времени,
Tsu — параметр предустановки информационных сигналов на входах тригге-
ров регистра -приемника, Ттг.тах — максимальная задержка от поступления
на вход триггера регистра -передатчика тактового сигнала до установления
данных на его выходах, Ткц.тах — максимальная задержка сигнала в ком-
бинационных схемах и цепях связи между регистром -передатчиком и реги-
стром -приемником.
Величина A есть "поле допуска" для временного положения фронта синхро-
сигналов, т. е. интервал появления фронта синхросигнала задается от t — А
до t + A, где t — теоретический момент появления фронта синхроимпульса.
Минимальный период тактирования схемы при данных параметрах (Tsu и
Ттг.mах) синхронизируемых триггеров (регистров) и нестабильности фрон-
тов синхросигналов зависит от Ткц.mах, т. е. от задержки выработки логи-
ческой функции комбинационной схемой и задержки в цепях связи для
соответствующей секции (яруса схемы или ступени конвейера). Секция с
максимальным значением Т ограничит возможную частоту тактирования
устройства. Максимальная частота синхронизации Fmax = 1/T.
Нередко в сведениях о ПЛИС приводятся тактирующие частоты для синхро-
низации внутреннего ядра и цепей ввода/вывода микросхемы. Встречаются раз-
личные соотношения между этими частотами. Внутренняя частота при
многоразрядных трактах передач информации, как правило, выше, чем час-
тота ввода/вывода, но в других ситуациях может наблюдаться и противопо-
ложная картина. В частности, в новых сложных ПЛИС все чаще использу-
ются линии последовательного ввода/вывода, которые в сочетании с мало-
сигнальными дифференциальными схемами передачи сигналов (например,
по стандарту LVDS) обеспечивают чрезвычайно высокие скорости обмена.
В таких случаях даже при параллелизации данных внутри приемника ско-
рости передач могут оказаться приемлемыми. Например, для линии со ско-
ростью передачи 2,5 Гбит/с переход к байт -последовательной передаче даст
частоту передачи байтов выше 300 МГц. Четыре таких скоростных линии
последовательной передачи смогут обеспечить передачу с частотой 300 МГц
32 -разрядных слов, а 8 линий смогут передавать 32 -разрядные слова с часто-
той 600 МГц. Преобразования данных из последовательной формы в парал-
лельную и наоборот связаны с применением сдвигающих регистров типа
SIPO (Serial Input — Parallel Output) или PISO (Parallel Input — Serial Output).
Естественно, при этом требуется строгая синхронность подачи последова-
тельных данных и синхросигналов, управляющих сдвигами данных в реги -
страх. При работе на высоких частотах обеспечение синхронизации стано-

вится сложной проблемой. Для ее решения в состав соответствующих
ПЛИС включают блоки CDR (Clock Data Recovery).
Оценка быстродействия ПЛИС дается также с применением понятия града-
ция быстродействия. Этот параметр входит в состав кода обозначения схемы
в виде цифры, перед которой ставится дефис ( -3, -4, -5 и т. д.). Для архитек-
тур типа CPLD с характерной для них независимостью задержек распро-
странения сигналов от их конкретных путей цифра, приводимая на позиции
"градация быстродействия", приближенно совпадает с округленным значе-
нием задержки распространения сигнала через данную ПЛИС. Для архитек-
тур типа FPGA и комбинированных архитектур цифра, определяющая гра-
дацию быстродействия, имеет лишь относительное значение. Она ранжирует
микросхемы по быстродействию, но не указывает абсолютные значения ди-
намических параметров, являясь, таким образом, как бы указателем для их
поиска в таблице. Указание градаций быстродействия целесообразно для
сравнительной оценки ПЛИС одного и того же семейства, но будет беспо-
лезно для сравнения микросхем разной архитектуры [4]. Для сравнения раз-
нотипных ПЛИС лучше оценивать тактовые частоты устойчивой работы ти-
повых функциональных узлов, реализованных в данной микросхеме.
Важной экономической характеристикой ПЛИС является их стоимость.
Стоимость ПЛИС, как и других БИС/СБИС, меняется со временем. Цена
новых сложных ПЛИС вначале высока, но довольно быстро снижается и
затем устанавливается на относительно стабильном уровне, испытывая лишь
небольшие конъюнктурные колебания. Стоимость микросхем во многом
определяется типом их корпусов — в зависимости от этого фактора цена
одного и того же кристалла может измениться более чем в 10 раз. Значи-
тельно повышаются и цены микросхем, имеющих специальную приемку
(военную и др.). Стоимость, как и для других видов продукции, зависит от
размера приобретаемой партии микросхем (лота) и ряда других факторов.
Кстати говоря, одним из преимуществ ПЛИС перед БМК и другими микро-
схемами, объявляемым многими фирмами-производителями, является от-
сутствие минимального порога при их заказе: допускается заказ любого ко-
личества микросхем.
1.10.3. Сведения о современной продукции

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

блочных "систем на кристалле" с процессорными ядрами
Ниже приводятся рисунки и комментарии к ним, отображающие основные
параметры и свойства ИСПС. На рисунках представлены только новые се-
мейства, перспективные для будущих разработок. Не показаны семейства,
которые пока не сняты с производства и могут применяться по тем или
иным соображениям, но имеют более современных преемников. Сведения
о некоторых таких семействах, не показанных на рисунках, даются в тексте.
Хотя приводимые ниже материалы освещают достаточно широкую область в
производстве ИСПС, они все же не являются полностью исчерпывающими
и не претендуют на описание всех без исключения разработок.
Микросхемы сгруппированы по признаку кратности программирования
(т. е. по типу памяти конфигурации), а внутри этих групп по фирмам -
производителям (маркировки микросхем не приводятся). При первом упо-
минании фирмы указывается и ее интернет -адрес. Каждое семейство ИСПС
изображается горизонтально расположенной прямоугольной областью с не-
сколькими поперечными вертикальными линиями, которым соответствуют
микросхемы -члены семейства. Против каждой вертикальной линии сверху
(а при нехватке места, и снизу) проставлена цифра, указывающая число эк-
вивалентных вентилей в данной микросхеме. Если в справочных данных для
микросхемы имелась конкретизация параметра "число вентилей", то это
отображается и на рисунке, где приняты следующие обозначения: NB —
число эквивалентных вентилей, Nbc — число системных эквивалентных вен-
тилей, Nbtyp — типовое число эквивалентных вентилей. Данные о числе вен-
тилей приводятся для всех членов семейства. Рядом с названием семейства
записывается напряжение питания ядра микросхемы. Левее прямоугольни-
ка, при необходимости (если на одном и том же рисунке встречаются разно-
типные архитектуры ИСПС), указывается архитектура микросхемы.
Остальные параметры приводятся только в виде диапазона их значений для
данного семейства (указываются значения для младшего и старшего членов
семейства).
Сведения о быстродействии включают в себя указание на ту или иную мак-
симально допустимую частоту. Системная частота Fc или Fmax — макси-
мальные частоты, на которых могут работать собранная в данной микросхе-
ме сложная схема, содержащая множество функциональных блоков, или
(если это отмечено) конкретное устройство, Fcnt - максимальная частота
работы счетчика (чаще всего в качестве испытательного образца берется
16 -разрядный двоичный счетчик), Frr— максимальная частота передач "ре-
гистр -регистр".
К параметрам, задаваемым диапазоном значений для всего семейства, могут
относиться следующие:
- число макроячеек Nмя (для CPLD) или логических элементов Nлэ (для
FPGA);
- суммарная емкость памяти Mlut в схемах табличных функциональных

преобразователей (блоков типа LUT);
- суммарная емкость встроенных блоков памяти Mвбп;
- число пользовательских вводов/выводов Nвв;
- стоимость микросхем, $.
Число вентилей измеряется в тысячах, емкости блоков памяти — в битах.
Диапазон значений NBB дается с учетом разных вариантов корпусов микро-
схем, иначе говоря, к различным цифрам могут относиться и разные типы
корпусов, в которых выпускаются микросхемы данного семейства.
Стоимость микросхем приводится по американским данным 2001 года для
лотов в 10 тыс. шт., для самых дешевых корпусов, схем минимального быст-
родействия и коммерческого диапазона температур.
В виде отдельных примечаний для некоторых семейств, обладающих ярко
выраженными особенностями, они указываются текстовой надписью.
На рис. 1.34 приведены сведения об однократно конфигурируемых FPGA
с программированием перемычек типа antifuse.
В этом секторе рынка доминируют фирмы Actel и QuickLogic. Полезные
свойства ПЛИС с перемычками типа antifuse — невысокая стоимость, высо-
кое быстродействие, высшая степень засекречивания проекта, повышенная
стойкость к воздействию радиации. Недостаток — однократность програм-
мирования. Естественно, конфигурация схем сохраняется при снятии пита-
ния микросхемы.
Большинство выпускаемых FPGA с перемычками типа antifuse имеют уро-
вень интеграции, оцениваемый числом вентилей от 3 до приблизительно
100 тыс. Исключение составляет семейство Eclipse фирмы QuickLogic с
уровнем интеграции до 580 тыс. эквивалентных вентилей. Отличительными
чертами FPGA семейства Eclipse, кроме высокого уровня интеграции, мож-
но считать большие возможности входных и выходных буферов. В них вве-
дены триггеры для фиксации входных и выходных сигналов, а также сигна-
лов управления третьими состояниями буферов, поддерживается множество
стандартов выходных сигналов, в том числе и для дифференциальных пере-
дач. Введены 4 схемы PLL, реализован большой объем встроенных блоков
двухпортовой памяти RAM.
В группе реконфигурируемых ПЛИС с электрическим программированием
состояний транзисторов типа ЛИЗМОП представлена продукция 5 фирм
(рис. 1.35).
Память конфигурации типов EEPROM и Flash характерна почти исключи-
тельно для CPLD, где эти типы памяти сменили применявшуюся ранее па-
мять типа EPROM. Пионер в разработке CPLD — фирма Altera, впервые
Глава /. Элементная база электронных устройств и систем 125
реализовавшая их в конце 1980 гг. Основой большинства современных

CPLD этой фирмы явилась архитектура семейства МАХ7000, вслед за кото-
рым появились модификации, развивавшиеся в двух направлениях.
В рамках первого направления возросшие технологические возможности
использовались для увеличения уровня интеграции микросхем, числа их
макроячеек и быстродействия при одновременном снижении напряжений
питания, потребляемой микросхемами мощности и стоимости в расчете на
одну макроячейку. Начиная с семейства MAX7000S, микросхемы снабжают-
ся средствами программирования в системе (ISP). Отличительной чертой
микросхем становится также большое разнообразие в выборе стандартов для
сигналов ввода/вывода, уровни которых могут быть как ниже, так и выше
рабочего напряжения ядра (Multivolt I/O Technology).
Семейство МАХ9000 также ориентировано на повышение уровня интегра-
ции. Его старший представитель имеет 12 тыс. макроячеек против 5 тыс.
у старшего представителя семейства МАХ7000. Однако при этом пришлось
перейти к иерархической системе межсоединений, что привело к утере цен-
ного свойства CPLD классической структуры — предсказуемости и постоян-
ства задержек сигналов независимо от их конкретного пути.
Второе направление, представленное семейством МАХЗОООА, связано со
стремлением к удешевлению микросхем. Семейство МАХЗОООА отличается
от базового семейства МАХ7000 снижением требований к некоторым пара-
метрам схемы, прежде всего, к потребляемой ими мощности. Микросхемы
семейства МАХЗОООА тестируются по пониженным нормам, уменьшен вы-
бор типов их корпусов, реализованы не все возможности базового семейства
МАХ7000. Следствием стало снижение цен почти вдвое.
Фирма Cypress Semiconductor в секторе продукции CPLD с памятью кон-
фигурации EEPROM представлена семейством микросхем Ultra37000. Это
семейство реализовано на основе архитектуры семейства МАХ7000 фирмы
Altera, но, как указывает фирма Cypress Semiconductor, имеет ряд усовер-
шенствований в сравнении с базовым вариантом. Изменения касаются вре-
менных параметров схем, у них отсутствует ощутимое влияние коэффициен-
та разветвления на задержку распространения сигналов, снижены задержки,
вносимые логическими расширителями, отсутствует рост задержек сигналов
с увеличением числа термов макроячеек вплоть до 16 и др.
Фирма Atmel известна как поставщик популярных PAL типов 16V8, 20V8,
22V10 (в этой главе из -за широкой известности эти PAL подробно не рас-
сматривались). В области CPLD высокого уровня интеграции фирма произ-
водит семейство ATF1500. Семейство ATF1500, как и семейство Ultra3700
фирмы Cypress Semiconductor, сходно с семейством МАХ7000 фирмы Altera
и конкурирует с ним. В микросхемах фирмы Atmel увеличено число входов
у логических блоков и ресурсы трассировки. Фирма Atmel считает, что в ее
микросхемах можно размещать более сложные проекты, чем в микросхемах
семейства МАХ7000 со сравнимым числом макроячеек. В микросхемах се-

мейства ATF1500 используется память конфигурации типа Flash.
Фирма Xilinx подключилась к производству CPLD лишь во втором поколе-
нии своих ПЛИС и в ограниченном масштабе. Ею выпущено семейство
ХС9500 с памятью конфигурации типа Flash. Схемотехника микросхем се-
мейства ХС9500 рассматривалась выше в качестве примеров решений, ха-
рактерных для CPLD.
Фирма Lattice Semiconductor стала в области ИСПС также и преемником
фирмы AMD в связи с приобретением у нее подразделения Vantis, с давних
пор занимавшегося производством PAL и CPLD. Эта фирма известна, в ча-
стности, тем, что впервые применила программирование в системе (ISP) для
ПЛИС невысокого уровня интеграции. С тех пор активность фирмы в об-
ласти ISP подчеркивается даже в названиях ее микросхем. В сфере CPLD
продукция фирмы делится на секторы: особо быстродействующей (SuperFast),
особо "широкой" (SuperWide) и особо сложной (SuperBig).
Особо быстродействующие микросхемы второго поколения семейства
ispLSI2000VE имеют время распространения сигнала от входа к выходу око-
ло 3 не и максимальную частоту 300 МГц, особо "широкие" микросхемы
семейства ispLSISOOOVE имеют по 68 входов на каждый логический блок
(однако в один логический блок этих микросхем входят 32 макроячейки, так
что отношение "число входов блока/число макроячеек в блоке" не является
столь уж большим и даже уступает этому показателю некоторых других
CPLD). В особо сложных микросхемах семейства ispLSISOOO введена двух-
уровневая система межсоединений. Средства локальной трассировки объ-
единяют по 20 макроячеек в так называемые мегаблоки, а 6 мегаблоков свя-
зываются между собой средствами глобальной трассировки. Микросхемы
имеют встроенные шины с тремя состояниями и 108 линиями. Буферы вво-
да/вывода имеют триггеры для возможности выбора комбинационного или
регистрового варианта для всех сигналов входов, выходов и управления дву -
направленностью.
Фирма Lattice Semiconductor выпускает также микросхему специальной ар-
хитектуры ispG, в которой мало логических элементов и почти все ресурсы
кристалла отданы под программируемые средства коммутации. Напомним,
что фирма Lattice Semiconductor принадлежит также к пока малому чис-
лу производителей аналоговых схем с программируемыми структурами
(ПАЙС).
Фирма Actel, наиболее известная как производитель ПЛИС с перемычками
типа antifuse, приняла участие и в выпуске реконфигурируемых микросхем,
что связано с покупкой ею фирмы Gatefield Corporation с ее производством
семейства ProASICSOOK. По своей архитектуре микросхемы ProASICSOOK
относятся к FPGA (это единственный представитель класса FPGA среди
микросхем с памятью конфигурации типа EEPROM или Flash). Произведет -
вом микросхем ProASICSOOK с Flash -памятью конфигурации фирма Actel

поддерживает концепцию тесной преемственности FPGA и БМК, заботясь
об их подобии. Микросхемы ProASICSOOK имеют крайне мелкозернистые
логические ячейки, что позволяет в значительной мере сохранить для этого
семейства методику и инструменты проектирования, освоенные ранее для
БМК.
В группу оперативно репрограммируемых ИСПС входит большое число
микросхем разной архитектуры и разных уровней интеграции (рис. 1.36).
Рис. 1.36. Основные параметры оперативно репрограммируемых ИСПС

с триггерной памятью конфигурации (см. продолжение)
Фирма Atmel
www.atmel.com
Семейство АТ6000;
3 ... 5,5 В
NB 6 9 15 30 Fc= 100МГц
FPGA
$6... 40
Млэ 1024 6400
NBB 84 240
Особенность - реализуемость
кэш -логики
Семейство АТ40К;
3 ... 5,5 В
Рс=100МГц
NB 10 20 30 50
FPGA $ 5 ... 50
_L _Е
Млэ 256 6400
NBB 84 352
Особенность - реализуемость
кэш -логики
Имеется память объемом
2048... 18432 бит
Фирма Cypress
www.cypress.com
Семейство Delta 39K;

3,3 В; 2.5 В; 1,8В
Fc = 250 МГц
NB 15 50 165 250 350 $18... 145
CPLD
NB 30 100 200
NMH 256 5376
NBB 208 676
Имеется память объемом

40960... 860160 бит
Рис. 1.36. Продолжение

130 Проектирование систем на микросхемах программируемой лотки
Фирма Agere Systems

www.agere.com
Семейство ORCA3;
5 В, 3,3 В; 2,5 В
NBC 244 340

FPGA Рсмт=176МГц
Nlut 8192 11552 $ 9,6 .. 206

Mlut 131000 185000
NBB 206 660
Семейство ORCA4;
1,5В
NBC 470 720 970 1350 1700 рс = 250МГц

FPGA
4 1 6 9 7
Nlut 4992 39960 $ -
Nu6n 73728 221184
NBB 400 1068
Особенность семейств - наличие встроенного

интерфейса для процессора
Рис. 1.36. Окончание
Среди ИСПС с триггерной памятью конфигурации преобладают архитекту-

ры FPGA и комбинированные архитектуры, а по уровню интеграции эти
схемы располагаются в диапазоне от нескольких тысяч до 10 млн. экви-
валентных вентилей. Последняя цифра относится к микросхемам типа
"системы на кристалле".
Оперативное репрограммирование появилось в разработках фирмы Хilinх —
создателя FPGA с триггерной памятью конфигурации (SRAM -based FPGA).
Перечень выпущенных фирмой Хilinх FPGA с оперативным репрограмми -
рованием насчитывает несколько семейств. К современным микросхемам
можно отнести семейства, начиная с XC4000E/XL, в состав которого входит
довольно много представителей и архитектура которого послужила базой
для последующего семейства Spartan. В дальнейшем технологический про-
гресс позволил усложнить схемы, увеличить в них число логических блоков
и ресурсы трассировки, улучшить технико -экономические показатели. На
новую ступень развития архитектуры и схемотехники продукция фирмы
Xilinx перешла при создании семейств Virtex и их модификаций, достигну-

тый уровень был затем использован при разработке семейства Spartan II.
Архитектура логических элементов у всех микросхем фирмы Xilinx традици -
онна, они содержат табличные функциональные преобразователи, триггеры
и программируемые мультиплексоры. Память в течение довольно длитель-
ного времени аккумулировалась в ресурсах LUT -блоков, но в семействе
Virtex и последующих появились и встроенные блоки памяти.
При переходе к семействам Virtex и Virtex E были изменены параметры
LUT -блоков и характер схем памяти. Распределенная память дополнилась
4 -К.битными двухпортовыми блоками памяти SRAM, для блоков верхнего
уровня памяти были применены высокоскоростные буферы ввода/вывода с
целью реализации скоростного интерфейса как между этими блоками, так и
для обмена между ними и внешними статическими и динамическими ЗУ.
Число блоков DLL было доведено до 8, был введен протокол обмена ин-
формацией с производительностью более чем 300 Мбит/с на контакт
(SelectLink). В семействе Virtex EM два верхних слоя межсоединений вы-
полнены на медных проводниках для распределения по кристаллу мощных
сигналов тактирования с большой скоростью.
Семейство Spartan II основано на технических новшествах, разработанных
при создании микросхем Virtex, но его микросхемы проще и дешевле. Се-
мейство Spartan II родственно по архитектуре семейству Virtex, но в нем со-
кращен состав функциональных блоков (нет параллельного интерфейса для
одного из режимов конфигурирования, нет средств создания декодеров ме-
тодами монтажной логики и т. д.), используются только дешевые корпуса.
Последняя разработка фирмы в рамках данного направления — семейство
Spartan IIE с цепями передачи данных типа LVDS (малосигнальными диф-
ференциальными линиями связей), ориентированное на реализацию быст-
рых алгоритмов ЦОС. Отмечается, что микросхемы семейства Spartan IIE
сочетают такие ценные свойства, как уровень интеграции, приближающийся
к возможностям ASIC, малое время выхода продукции на рынок и репро -
граммируемость при хорошем соотношении цена/вентиль. Сложность мик-
росхем семейства лежит в пределах от 50 до 300 тыс. вентилей.
Последнее на сегодня мегавентильное семейство микросхем фирмы Xilinx —
Virtex II. В его архитектуре продолжена линия усложнения логических бло-
ков, увеличены объемы памяти и ресурсы трассировки. Введена специали-
зированная схема быстрого умножителя 18x18. Появились внутрикристаль-
ные резисторы -терминаторы для линий передачи сигналов с возможностью
выбора их сопротивлений, которые автоматически устанавливаются соответ-
ственно внешним условиям.
На будущее планируется выпуск семейства Virtex IIРго с интегрированным
ядром процессора Power PC фирмы IBM.
Если фирма Xilinx имеет приоритет в применении триггерной памяти кон-
фигурации, то лидером в развитии ПЛИС комбинированной архитектуры
можно считать фирму Altera. Первым семейством микросхем с комбиниро-

ванной архитектурой были микросхемы семейства FLEX8000, затем появи-
лись семейства FLEX10K/KE и FLEX6000. По типу логических блоков эти
семейства можно отнести к FPGA, но по типу системы межсоединений, на-
против, они имеют близость к CPLD, т. к. фирма Altera избегает сегменти-
рованных линий связи, стремясь по возможности сохранить предсказуе-
мость задержек в связях.
Структура и схемотехника микросхем семейства FLEX10K/KE рассмотрена
ранее в этой главе. Семейства FLEX6000 и FLEX6000A структурно упроще-
ны в сравнении с семейством FLEX10K/KE, но одновременно с этим вы-
полнены на более новом и совершенном технологическом базисе, имеют
улучшенные показатели по плотности и быстродействию схем. Эти схемы
расцениваются как удачное решение с точки зрения сочетания параметров
"цена -производительность" для проектов, не требующих наличия памяти на
кристалле и не слишком сложных. В сравнении с семейством FLEX10K/KE
в микросхемах FLEX6000 и FLEX6000A исключены блоки PLL, сокращены
ресурсы глобальной трассировки и усилены ресурсы местных связей, огра-
ничен выбор типов корпусов.
Семейство АСЕХ1К — вариант микросхем FLEX10K/KE, реализованный
с уменьшенными топологическими нормами, но значительно более дешевый,
чем его мегавентильные "соседи" того же технологического поколения.
Микросхемы семейства АСЕХ1К имеют сравнительно небольшой уровень
интеграции, меньший выбор типов корпусов. Эти микросхемы популярны
у отечественных разработчиков вследствие невысокой стоимости при хоро-
ших технических параметрах.
Последнее семейство микросхем фирмы Altera — Mercury (Меркурий) оп-
тимизировано по критерию быстродействия и ориентировано на использо-
вание в высокопроизводительных системах ЦОС и сложных коммуникаци-
онных системах. Имеет высокоскоростную систему межсоединений с ис-
пользованием приоритетностей и конвейерный умножитель, до 18 каналов
поддержки CDR (Clock Data Recovery), и способно поддерживать протоколы
Gigabit Ethernet и другие скоростные протоколы передачи данных.
Семейства микросхем АРЕХ20К/КЕ и APEX II типа "система на кристалле"
рассмотрены выше в разд. 1.6.
Фирма Agere Systems (ранее Lucent Technology и еще ранее AT&T Micro-
electronic) в соответствии с изначальной проблемной ориентацией фирмы
AT&T концентрирует свои усилия на производстве микросхем для систем
цифровой связи. Эта фирма на современном этапе выпускает семейства
ORCA2, ORCA3, ORCA4 и несколько специализированных ПЛИС на их
основе. Указанные семейства модифицируются с течением времени и пере-
водятся на производство по новым технологическим процессам, что сразу
же отражается на уровнях питающих и сигнальных напряжений. Логические
элементы серий ORCA основаны на использовании LUT -блоков и тригге-

ров, четыре таких комбинации группируются в блок PFU (Programmable
Function Block), память функциональных блоков может быть использована
как RAM или ROM. Отличием семейств, начиная с ORCA3, является нали-
чие интерфейса для сопряжения с процессором, допускающее параллельное
программирование конфигурации микросхем и подключение процессоров
i960 или Power PC. При переходе к семейству ORCA4 акцент был сделан на
совершенствовании сигнальной трассировки, задержки сигналов в которой
все более определяют общее быстродействие микросхемы.
На основе семейств ORCA выпущены схемы FPSC (Field Programmable
System Circuits), в том числе OR3TP12, OR3LP26B, ORT4622, ORT8850,
ORT82G5, ORLI10G. В этих микросхемах матрицы типа FPGA сочетаются с
ядрами на элементах ASIC, причем вначале применялись ядра PCI, а позд-
нее эти ядра стали заменяться на схемы дуплексных синхронных интерфей-
сов с высокими скоростями передач и встроенными средствами CDR (Clock
Duty Recover). В микросхемах на основе серии ORCA4 достигнуты наи-
высшие скорости передач: в микросхеме 4622 реализованы 4 канала с про-
пускной способностью 622 Мбит/с, в микросхеме 8850 — 8 каналов и
850 Мбит/с, в микросхеме 82G5 получены скорости 1,25; 2,5 и 3,125 Гбит/с,
в микросхеме 10G — 10 Гбит/с.
Фирмой Atmel выпускаются сходные семейства FPGA: AT6000 и АТ40К,
причем семейство АТ40К новее и больше приспособлено к широкому при-
менению в универсальных проектах. Компания делает акцент на возмож-
ностях частичного динамического реконфигурирования своих FPGA (воз-
можностях так называемого reconfigurable computing). Подробнее о микро-
схемах АТ40К сказано ранее при описании SOPC типа FPSLIC. К сведениям
о микросхемах FPSLIC можно добавить, что в последнем нововведении
фирмы (архитектуре AT49S) приняты меры по повышению засекреченности
разработанных проектов.
Фирма Cypress Semiconductor использует триггерную память конфигурации
в своих микросхемах Delta39K, имеющих сходство с описанными ранее
микросхемами Ultra37000. Переход от памяти конфигурации типа EEPROM
в UltrаЗ7000 к триггерной памяти в Delta39K сопровождался значительным
увеличением емкости пользовательской памяти. Вариантом -пониженной
стоимости является семейство Quantum38K, отличающееся от семейства
Delta39K рядом упрощений. На основе микросхем Delta39K разработаны
кристаллы PSI (Programmable Serial Interface) с сочетанием областей БМК
и программируемой логики, в которых достигнуты - скорости передачи сиг-
налов от 200 Мбит/с до 2,5 Гбит/с на контакт и общая пропускная способ-
ность тракта в 12 Гбит/с. При этом поддерживаются стандарты PCI,
SONET, Gigabit, Ethernet, Fibre Channel и InfiniBand. В отличие от других
архитектур с триггерной памятью конфигурации, схемы Delta39K относятся
к CPLD.
В производстве встроенных FPGA -ядер для схем на основе ASIC участвует

пока что небольшое число фирм. Фирма Actel выпускает микросхемы
VariCore с напряжением питания 1,8 В, числом логических ячеек от 1024
до 8192 и встроенной памятью в диапазоне от 36 864 до 73 728 бит. Фирма
Adaptive Silicon производит семейство MSA2500 с напряжениями питания
1,8; 1,3 и 1,0 В и числом логических ячеек от 64 до 1024 (схемы памяти от-
сутствуют). Фирма Agere Systems поставляет микросхемы eORCA (embedded
ORCA) с напряжением питания 1,5 В, числом логических ячеек 800 и па-
мятью в составе LUT -блоков емкостью 102 400 бит. Фирма Atmel разработа-
ла микросхемы под названием Embedded FPGA с напряжением питания
от 1,8 до 3,3 В, числом логических ячеек от 256 до 6400 и встроенной па-
мятью емкостью от 2048 до 51 200 бит.
Сведения о блочных "системах на кристалле",

содержащих процессорные ядра
Принятая выше форма представления параметров более или менее удовле-
творительна применительно к микросхемам, не имеющим разнообразного
состава аппаратных ядер. Для блочных систем указание числа эквивалент-
ных вентилей, объема памяти и т. п. недостаточно характеризует микросхе-
му, т. к. первоочередной интерес для таких систем представляет состав реа-
лизованных ядер, их типы, количество и характеристики. Для блочных сис-
тем с процессорными ядрами ниже дается краткое словесное описание
основных представителей современной продукции ведущих фирм. Более
подробные сведения о некоторых блочных SOPC, были даны ранее в этой
главе.
В современной номенклатуре 32 -разрядных hard -ядер процессоров имеется
несколько вариантов, которые могут быть эффективно встроены в кристал-
лы со схемами программируемой логики вследствие своей настроенности на
процессы изготовления FPGA. Такие hard -ядра компактны и могут занимать
всего лишь 1,5—2 мм 2 (без кэшей). По архитектуре это, в сущности, стан-
дартные RISC -процессоры. Производителями FPGA применяются hard -ядра
с процессорами ARM9T, MIPS4KC, PowerPC405C. В маломощных порта-
тивных системах доминируют процессоры ARM, следом идут архитектуры
MIPS и Power PC. В этих процессорах достигаются рабочие частоты до
200 МГц и более, в них применяются 5—6 ступенчатые конвейеры, выпол-
няются скалярные операции, достигнута малая мощность потребления.
Hard -ядро ARM922T фирмы ARM имеет площадь 11,8 мм 2 (при топологиче-
ских нормах 0,18 мкм), рабочие частоты до 200 МГц и используется фирма-
ми Altera и QuickLogic. С этим ядром связано применение шинной системы
АМВА с шинами АНВ, ASB и АРВ, в обозначениях которых средние буквы
означают соответственно High -Speed, System и Peripheral. Имеются кэши
данных и команд емкостью по 16 Кбайт, 6 -ступенчатый конвейер, аппарат-
ный умножитель, рассеиваемая мощность 160 мВт.
Глава 1. Элементная база электронных устройств и систем /35
Ядро ARM740T, используемое фирмой Triscend, имеет площадь 2,5 мм 2 , ра-

бочую частоту до 60 МГц, смешанный кэш команд/данных емкостью
8 Кбайт, 4 канала прямого доступа к памяти и контроллеры/интерфейсы для
работы с внешней памятью.
Ядро MIPS (Microprocessor without Interlocked Pipeline Stages, что, в сущно-
сти, означает "микропроцессор без задержек ожидания конвейера") фирмы
MIPS Technologies сейчас лицензируется многими крупными производите-
лями электронной аппаратуры. Ядро MIPS4C занимает площадь 3 мм 2 . Ис-
пользуется фирмой QuickLogic, а вариант MIPS4KC также и фирмой Altera.
Имеет кэши команд и данных по 16 Кбайт, 5 -ступенчатый конвейер, аппа-
ратные средства для выполнения операций умножения, деления, умножения
с накоплением. Рабочая частота ядра 200 МГц, рассеиваемая мощность
400 мВт. Используется с шинной системой АМВА.
Ядро Power PC405C фирмы IBM Microelectronics имеет площадь 3 мм 2 , ис-
пользуется фирмой Xilinx с шинной системой CoreConnect фирмы IBM.
Кэши команд и данных имеют объемы по 32 Кбайта, применяется 5 -сту-
пенчатый конвейер, аппаратные схемы умножения и деления, мощность
рассеяния составляет 400 мВт.
Soft -ядра Nios фирмы Altera и Microblaze фирмы Xilinx кратко рассмотрены
выше (см. разд. 1.5 и 1.6 данной главы).
Информация об однородных системах на кристалле приведена на рисунках
в разделах ПЛИС с триггерной памятью конфигурации и в тексте главы
(семейства Virtex, APEX и др.). Блочные "системы на кристалле" перечисле-
ны ниже с указанием фирм -производителей.
О Фирма Triscend выпускает CSOC (Configurable SOC) семейств Е5 и А7,
в которых объединяются процессор (8 -разрядное ядро 80С51 для семей-
ства Е5 с производительностью 10 MIPS на 40 МГц или 32 -разрядное
ядро ARMA7 для семейства А7 с производительностью 54 MIPS на
60 МГц), скоростные шины на кристалле и FPGA с триггерной памятью
конфигурации. Работа процессора поддерживается наличием кэша ем-
костью 8 и 16 Кбайт статической памяти. На кристалле имеется 4 -ка -
нальный контроллер прямого доступа к памяти и схемы интерфейса для
работы с внешней памятью и стандартной периферией, а также обычная
для контроллеров периферия (2 таймера, 2 UART, сторожевой таймер).
FPGA дает до 40К вентилей (до 3200 логических элементов, до 51 200 бит
памяти в LUT -блоках и до 521 288 бит встроенной памяти). Имеется
блок внутрисхемной отладки. Стоимость микросхем лежит в диапазоне
5—19 долларов для семейства Е5 и составляет приблизительно 20 дол-
ларов для пока единственного представителя семейства А7 (микросхемы
А7520). Несмотря на достаточно универсальный характер блоков CSOC,
фирма отмечает ее проблемную ориентацию — для систем коммуника-
ции. Triscend ведет совместную работу с фирмой Hitachi с целью выпуска
CSOC на основе ее процессора SuperH. Предполагается и дальнейшее

расширение перечня процессорных ядер в CSOC фирмы Triscend.
О Фирма Atmel выпускает микросхемы FPSLIC с 8 -разрядным процессор-
ным ядром AVR, имеющим производительность 30 MIPS на 40 МГц.
Процессорное ядро объединено с FPGA емкостью до 40К вентилей
(до 6400 логических элементов) и собственной памятью RAM емкостью
18 Кбит, На кристалле размещены также память команд и память данных
с общей емкостью 32 Кбайт, блок регистров размерностью 32x8, аппа-
ратный умножитель размерностью 8x8 и стандартная для микроконтрол-
леров периферия (2 UART, 3 таймера, двухпроводной стандартный по-
следовательный интерфейс, сторожевой таймер). Особенностью FPSLIC
являются возможности динамической частичной реконфигурации систе-
мы, обеспечивающие реализуемость решения задач методом, называемым
reconfigurable computing. Стоимость микросхем находится в пределах
7—58 долларов.
- Фирма Altera производит SOPC семейство Excalibur, в состав которого
обычно включают как SOPC с soft -ядром процессора Nios, размещаемым
на кристалле семейств APEX, так и SOPC с hard -ядрами типов ARM или
MIPS. Имея в качестве основы ПЛИС APEX высокой сложности, SOPC
Excalibur занимают позиции в верхней части спектра SOPC. Типичное
число эквивалентных вентилей доходит у них до 1 млн., число логиче-
ских элементов до 38 400, 32 -разрядное процессорное ядро ARM922T ра-
ботает на частотах до 166 МГц, используется высокоскоростной вариант
шинной системы АМВА (шина АНВ). Имеются раздельные кэши по
8 Кбайт для команд и данных, несколько видов оперативной памяти, мо-
дуль для отладки программного обеспечения, гибкий контроллер преры-
ваний, UART, таймеры (общего назначения и сторожевой). Стоимость
микросхем находится в пределах 265—925 долларов.
- Фирма Cypress Semiconductor выпускает кристаллы PSOC, архитектурно
представляющие собою микроконтроллер, дополненный программируе-
мыми цифровыми и аналоговыми блоками, ориентированными на созда-
ние специального набора периферийных функций. Для цифровой части
это таймеры, последовательные порты, генераторы, для аналоговой —
цифроаналоговые и аналого -цифровые преобразователи и фильтры
(низких частот, высоких частот, полосовые). Имеется умножитель 8x8
с 32 -разрядным аккумулятором, до 16 Кбайт Flash -памяти и 256 Кбайт
статического ОЗУ. Микросхема работает на частотах до 24 МГц.
- Фирма Semiconductor Design Solution выпускает "системы на кристалле"
FIPSOC с процессорным ядром 8051 и цифровыми и аналоговыми под-
системами программируемых периферийных устройств. Цифровая часть
содержит функциональные блоки типа LUT + RG, аналоговая часть мо-
жет программироваться на такие заказные функции, как усиление диф -
ференциальных сигналов, сравнение и преобразование данных, т. е. ори-

ентирована на так называемое front -end design.
- Фирма Motorola намеревалась войти в сферу производства блочных
SOPC с микросхемой MPACF250, которая расценивалась многими спе-
циалистами как весьма перспективная, поскольку планировавшееся для
нее процессорное ядро имело преимущества перед существовавшими.
Однако по каким -то причинам имевшиеся планы пока не реализуются.
- Фирма LSI Logic совместно с фирмой Adaptive Silicon разработала SOPC,
в которой объединены традиционные схемы, реализованные по методу
стандартных ячеек, ядро процессора ARM и программируемая логика для
реконфигураций, адаптирующих проект к новым требованиям.
- Фирма Agere Systems объявила о выпуске SOC Ultra Mapper, содержащей
до 8 млн. вентилей, для реализации функций, характерных для систем
передачи речи и другой информации в проводных системах.
ГЛАВА 2
Основы технологии
проектирования ИСПС и структуры
систем автоматизированного
проектирования
Задача данной книги — помочь в освоении современных подходов к проек-

тированию систем, ориентированных на широкое использование в них но-
вой элементной базы — микросхем с программируемой структурой (ИСПС)
и их наиболее ярких представителей — конфигурируемых систем на кри-
сталле (SOPC).
Краеугольными составляющими любого проектирования являются:
- элементы, из которых строится проектируемый объект;
- инструментарий, при помощи которого выполняются отдельные этапы
изготовления документации и собственно результирующего объекта;
- методика применения инструментария для получения конечных резуль-
татов;
- абстракции (определения, понятия и т. д.), вводимые для упрощения
описания процесса проектирования.
Строительными "кирпичиками" интересующих нас систем являются рас-
смотренные в гл. 1 элементы с конфигурируемой структурой (по сути, пред-
ставляющие собой конфигурируемую аппаратуру, для которой в английской
терминологии обычно используется термин Hardware, HW) и программи-
руемым поведением (в основе которого лежит программное обеспечение, в
английской терминологии Software, SW). Термины HW и SW, благодаря
своей краткости (при сохранении однозначности трактовки), получили ши-
рокое распространение в отечественной литературе и будут применяться в
последующих разделах. Основными абстрактными понятиями, которыми
приходится пользоваться в процессе проектирования, являются языки опи -
сания аппаратуры, рассматриваемые в гл. 3, и средства описания програм-

мной части проектируемых систем (универсальные языки программирова-
ния), которые достаточно подробно разобраны в существующей литературе.
Инструментарий проектирования и методика его использования составляют
содержание данной главы. Основным инструментом проектирования для
рассматриваемой прикладной области (проектирование на основе ИСПС)
является программное обеспечение ЭВМ, в комплексе образующее системы
автоматического проектирования, САПР. Наиболее значимым для проекти-
рования на основе ИСПС (и отличающим его от многих других) является не
столько резкое увеличение возможностей, предоставляемых современными
САПР, сколько взаимопроникновение и взаимное влияние составляющих
процесса проектирования.
Стремительное увеличение степени интеграции современной элементной
базы и постоянное улучшение характеристик ЭВМ (не в последнюю очередь
благодаря этой элементной базе) вызывает адекватное наращивание как ко-
личественных, так и качественных возможностей САПР, т. е. инструмента-
рия проектирования. Динамика изменения возможностей САПР предопре-
деляет изменение методологии их применения и все большую интеграцию
в рамках одной САПР смешанных методик и объектов проектирования.
Темпы изменений всех составляющих процесса проектирования электрон-
ных систем заставляют периодически пересматривать и переосмысливать
различные аспекты проектирования. Материал данной главы посвящен рас-
смотрению возможностей и особенностей использования современных ме-
тодик проектирования цифровых устройств с ориентацией на существующие
САПР.
В области структурной организации схем с программируемой структурой и
средств их проектирования состояние весьма подвижно. Если базовые архи-
тектурные и структурные решения для схем ПЛИС в значительной мере уже
определились и перешли в стадию простого наращивания количественных
характеристик, то для схем ПАИС и SOPC архитектурные и структурные
решения еще только развиваются. О степени подвижности этого аспекта
проектирования говорит тот факт, что новые семейства БИС ПЛИС появ-
ляются с частотой приблизительно раз в два года, а принципиально новые
архитектурные решения появляются не чаще чем раз в пять лет.
Что касается инструментария проектирования — САПР и самой методики
проектирования, то эта составляющая в настоящий момент находится в со-
стоянии стремительного нарастания своей интеллектуализации, предостав-
ляемых средств и возможностей автоматизации. Подтверждением интенсив-
ности изменений в методике проектирования является тот факт, что новые
версии САПР поставляются фирмами с частотой раз в квартал. Вместе
с тем, в отечественной литературе вопросам создания и даже выбора совре-
менных средств проектирования (если не считать переводов или переложе-
ний фирменных руководств по использованию САПР) уделяется явно не -
Глава 2. Основы технологии проектирования ИСПС 141
достаточное внимание. Последние издания отечественной литературы по

этому направлению [1, 2] вышли более 10 лет назад. Поэтому материал дан-
ной главы, кроме изложения общих концепций, содержит и справочные
данные. Авторы надеются, что включение справочного материала (несмотря
на ожидаемое быстрое устаревание) поможет читателю лучше сориентиро-
ваться в основных направлениях и тенденциях развития современных мето-
дик проектирования.
2.1. Общие сведения

о процессе проектирования
Проектирование — комплекс работ, целью которого является получение тех-
нической документации, позволяющей реализовать или изготовить новый
или модернизируемый объект с заданными свойствами и с заданным функ-
ционированием в заданных условиях. В общем случае, объектами проекти-
рования могут быть изделия (например, мобильный телефон, ЭВМ, сти-
ральная машина) или процессы (например, технологические, вычислитель-
ные). Сущность процесса проектирования изложена в работах [12, 16].
В контексте рассматриваемой проблематики нас интересуют процессы, свя-
занные с созданием электронных систем.
Стратегия проектирования — функциональная декомпозиция. Для системы
в целом и ее блоков используется концепция "черного ящика". Для "черного
ящика" разрабатывается функциональная спецификация, включающая внеш-
нее описание блока (входы и выходы) и внутреннее описание — функцию
или алгоритм работы: F= Ф(Х, t), где X— вектор входных величин, F —
вектор выходных величин, t — время. При декомпозиции функция Ф разби-
вается на более простые функции Ф1 -.Ф к , между которыми должны быть
установлены определенные связи, соответствующие принятому алгоритму
реализации функции Ф. В результате разбиения, в конечном счете, получа-
ется структура. Переход от функции к структуре — синтез.
Синтез неоднозначен. Выбор наилучшего варианта осуществляется по ре-
зультатам анализа, когда проверяется правильность работы и некоторые по-
казатели, характеризующие устройство. Процедуры синтеза и анализа по-
стоянно чередуются.
Декомпозиция функций блоков выполняется до тех пор, пока не получатся
типовые функции, каждая из которых может быть реализована на элементах
выбранного уровня иерархии.
Процесс проектирования — многоуровневый, многошаговый и итерацион-
ный, с возвратами назад и пересмотром ранее принятых решений. Комплекс
проектных работ, как правило, включает в себя теоретические и экспери-
ментальные исследования, расчеты и конструирование.
Различие теоретической базы и понятийного аппарата, используемых на

разных стадиях проектирования, приводит к тому, что традиционным явля-
ется разбиение процесса проектирования как электронных систем, так и
БИС/СБИС, на этапы, приведенные на рис. 2.1.
Рис. 2 . 1 . Традиционные этапы проектирования
На этапе системного проектирования определяется архитектура, состав ком-

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

нических средств, как привлекаемых для создания проекта в роли инстру-
ментария, так и используемых в качестве компонентов проекта, а также и
технологических особенностей реализации конечного продукта. Хотя общая
методология процесса проектирования не зависит от варианта разбиения
процесса проектирования на отдельные уровни, содержание, а также методы
и средства проектирования для различных уровней оказываются очень спе-
цифичными и существенно зависят как от типа применяемой элементной
базы, так и от способа реализации (изготовления) конечного продукта.
Представленная последовательность действий характерна для всех уровней
проектирования. Для каждого уровня декомпозиция заканчивается при по-
лучении типовых функций, соответствующих этому уровню иерархии. Так,
например, при многоплатной реализации проекта декомпозиция заканчива-
ется на верхнем уровне иерархии при представлении проекта в виде отдель-
ных плат, на следующем уровне — в виде отдельной платы (типового эле-
мента замены), еще ниже декомпозиция осуществляется до реализации
функций при помощи той или иной микросхемы. При ориентации на про-
граммируемые (разрабатываемые) пользователем микросхемы процедура де-
композиции осуществляется уже для этой микросхемы в соответствии с со-
ставом функциональных библиотек программируемых БИС/СБИС.
На любом этапе проектирования может быть выявлена ошибочность или не
оптимальность выбранного ранее варианта реализации или принятого ре-
шения. Такая ситуация требует оценки целесообразности возврата и пере-
смотра решений. С учетом возможностей современных САПР проектирова-
ние может считаться законченным после верификации проекта в целом,
когда завершена отладка готового изделия.
Последовательная декомпозиция проекта на отдельные фрагменты (с опре-
делением функций каждого фрагмента и его интерфейса) характерна для
любого этапа проектирования и применяется при разработке широкого
спектра цифровых устройств, начиная от устройства целиком и кончая про-
ектированием отдельных БИС/СБИС. Такая методология проектирования
отображает процесс проектирования "сверху вниз": от технического задания
до электрических схем, файлов прошивки ПЗУ и конфигурации программи-
руемых приборов, а также конструкции устройства в целом.
Другая последовательность, соответствующая методологии "снизу вверх", преду-
сматривает объединение простейших модулей в более сложную структуру до
тех пор, пока, в конце концов, не будет создан конечный проект. Исходные
модули — это решения, созданные проектировщиком на более ранних эта-
пах работы или в ходе работ над другими проектами, или доступные проек-
тировщику и входящие в состав имеющихся библиотек САПР.
2.1.1. Факторы,
влияющие на методику проектирования
электронных устройств
Первым фактором, влияющим на специфику проектирования и, как следст-
вие, на возможные САПР, является тип обрабатываемой информации и свя-
занные с ним методы и способы ее обработки. Проект или его отдельные
фрагменты могут включать аналоговые, аналого -цифровые и/или цифроана -
логовые элементы, строиться на основе дискретных (цифровых) компонен-
тов или опираться на встроенные микропроцессорные средства. Отсюда
следует многообразие вариантов проектирования, которые в современных
технологиях часто называют потоком проектирования (Design Flow). Поток
проектирования при этом определяется тем, какие компоненты превалиру-
ют в проекте.
Следующим определяющим фактором является выбор технической базы для
реализации фрагментов проекта, а также технологического способа реализации
самого проекта. Как правило, одно и то же электронное изделие может быть
реализовано различными способами. Здесь должен быть дан ответ на во-
прос — будет ли проект построен на стандартных микросхемах, будут ли
использоваться те или иные специализированные ИС или комбинация раз-
личных типов ИС. Более того, в разные моменты жизненного цикла проекта
в зависимости от тиражности изделия в составе проекта могут меняться ис-
пользуемые типы ИС.
В наибольшей степени появление и широкое распространение БИС с про-
граммируемой структурой и конфигурируемых систем на кристалле повлия-
ло на два соседних иерархических уровня проектирования: проектирование
собственно ИС с программируемой структурой (ИСПС) и проектирование
печатных плат, содержащих такие БИС.
Хотя во многих чертах проектирование для этих двух уровней близко, спе-
цифика проектирования и, соответственно, применяемые САПР заставляют
рассматривать их, в зависимости от анализируемой проблемы, раздельно
или последовательно.
2.1.2. Области применения СпИС

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

технологическим процессом:
С и с = С и з г + C n р /N,
где С и з г — стоимость изготовления ИС (стоимость кристалла и других мате-
риалов, стоимость технологических операций по изготовлению ИС, кон-
трольных испытаний). Затраты на изготовление относятся к каждой ИС,
т. е. повторяются столько раз, сколько ИС будет произведено; С п р — стои-
мость проектирования ИС, т. е. однократные затраты для данного типа ИС;
N— объем производства (тиражность), т. е. число ИС, которое будет произ-
ведено.
Стоимость проектирования БИС/СБИС велика и может достигать сотен
миллионов долларов. Для дорогостоящих вариантов проектирования
БИС/СБИС производство становится рентабельным только при большом
объеме их продаж.
Затраты С п р и С и з г находятся во взаимосвязи. Рост затрат на проектирование,
как правило, ведет к снижению С и з г , поскольку чем совершеннее проект, тем
рациональнее используется площадь кристалла и другие его ресурсы. Отсюда
видно, что выигрыш по экономичности могут получать те или иные типы СпИС
в зависимости от тиражности их производства и сложности.
Применительно к микросхемам программируемой логики справедливы сле-
дующие положения. Простые устройства со сложностью в сотни эквива-
лентных вентилей целесообразно реализовывать на PLD (PAL, GAL, PLA).
При росте сложности проекта естественен переход к FPGA и CPLD, если
тиражность ИС сравнительно невелика. Рост тиражности (приблизительно
свыше десятков тысяч) ведет к преимуществам реализаций на БМК, т. к.
стоимость изготовления небольшого числа шаблонов для создания межсо-
единений разложится на большое число микросхем, а стоимость изготовле-
ния каждой ИС уменьшится благодаря исключению из схемы программи-
руемых связей и средств их программирования.
При еще большей тиражности выгодным оказывается метод стандартных
ячеек (СЯ), позволяющий дополнительно улучшить параметры схемы, плот-
нее разместить ее элементы на кристалле, т. е. уменьшить С и з г и улучшить
быстродействие. При этом, слагаемое Cnp/N в формуле стоимости ИС не
окажется слишком большим благодаря большой величине N, хотя необхо-
димость проектировать весь комплект шаблонов для технологических про-
цессов приводит к большим затратам С п р .
Полностью заказное проектирование для СпИС не характерно. Оно стоит
настолько дорого, что применяется практически только для создания стан-
дартных БИС/СБИС массового производства.
Диаграмма областей целесообразного применения разных типов СпИС
в зависимости от их сложности и тиражности приведена на рис. 2.2.
Сложность проекта,
вент / крист ' '
10 2 10"
Объем выпуска,
шт
Рис. 2.2. Рациональные объемы выпуска СпИС разных технологий проектирования

и изготовления
2.1.3. Место БИС с программируемой структурой

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

напряжение и т. д.).
Микропроцессорная система создается в результате разработки комплекса
программно -аппаратных средств. Проектирование аппаратной части сводит-
ся к компоновке системы из типовых модулей: центрального процессорного
элемента, различных видов памяти, адаптеров, контроллеров и внешних
устройств. Способы подключения модулей к шинам микропроцессорной
системы, описания основных модулей, сведения о типах и методике их выбо-
ра, о методике их программирования и применения изложены в литерату-
ре [27]. Ключевой проблемой при проектировании микропроцессорных сис-
тем была и остается проблема разработки программного обеспечения.
Помимо проектирования микропроцессорных систем различного уровня и
функционального назначения, львиной долей инженерных разработок аппа-
ратуры в условиях современной России, по -видимому, явится использование
схем с программируемой структурой как для создания автономных устройств,
так и их применения в составе микропроцессорных систем. Более того,
в соответствии с ростом возможностей построения систем на одном кри-
сталле сами микропроцессорные системы могут оказаться одним из элемен-
тов, входящих в состав БИС с программируемой структурой. В подобной
ситуации уже трудно определить — являются ли подобные СБИС програм-
мируемой логикой со встроенным микропроцессором или это МП -система
со встроенной программируемой периферией. Также трудно провести чет-
кую грань между проектированием собственно МП, проектированием его
периферии и, тем более, проектированием связи между МП -ядром и пери-
ферией. Сведения о средствах и методике отладки ПО, входящего в состав
SOPC, приведены в данной главе.
Целесообразность использования того или иного типа СпИС может опреде-
ляться различными соображениями. Наиболее распространенной ситуацией
оказывается случай, когда с целью обеспечения минимального времени вы-
хода конечного изделия на рынок (time -to -market), производимые приборы
на начальном этапе жизненного цикла изделия строятся на основе схем
с программируемой структурой, затем (по мере готовности) продукция пере-
водится на использование полузаказных БИС. На рис. 2.3 показана такая
зависимость. Выбор типа полузаказных БИС (БМК или стандартные ячей-
ки) может определяться необходимостью сокращения времени выпуска се-
рийной продукции (time -to -silicon).
На рисунке также отражена ситуация, соответствующая случаю, когда на
заключительных этапах жизненного цикла могут оказаться нецелесообраз-
ными заказы новых партий полузаказных БИС, а экономически обоснован-
ным будет возврат к использованию ИСПС. Кроме соображений быстрого
выхода на рынок, причиной ориентации первых опытных партий конечной
продукции на использование ИСПС может служить простота корректиро -
вок внутренней конфигурации БИС по результатам эксплуатации опытной

партии.
Время
Рис. 2.3. Зависимость применяемого типа СпИС от времени

в жизненном цикле устройства
Достоинством применения БИС типа ИСПС, и в том числе типа SOPC, яв-
ляется не только легкость корректировок как макетов, так и опытных пар-
тий продукции, но и определенная секретность разработок. В отличие от
традиционной реализации на стандартных дискретных элементах, при во-
площении системы на ИСПС структура ее оказывается невидимой, и этим
соответственно затрудняется несанкционированное повторение разработок,
а тем более выпуск их усовершенствованных вариантов.
Широкое внедрение БИС типа SOPC в настоящее время сдерживается не
только и не столько экономическими соображениями (БИС пока относи-
тельно дороги), сколько издержками новизны (недостаточная подготовлен-
ность кадров, малое количество у разработчиков апробированных решений,
недостаточное качество и количество методических и учебных материалов).
В силу сказанного, отечественным разработчикам следует уделять особое
внимание вопросам проектирования схем с программируемой структурой.
2.2. Основы организации

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

ектирования САПР. САПР для проектирования и комплексной отладки
программного обеспечения МП -систем обычно называют интегрированной
средой разработки или оболочкой. Для единства терминологии, кроме случа-
ев, узко ориентированных на разработку ПО МП -систем, будем использо-
вать общий термин "САПР" для любых систем автоматизированного проек-
тирования. Для схем с программируемой структурой, даже для ПЛИС не очень
высокой сложности, проектирование связано с обязательным применением тех
или иных САПР.
Для лучшего уяснения специфики современного проектирования произве-
дем параллельный сравнительный анализ традиционной и современной ме-
тодик проектирования. Чтобы охватить наибольшее число возможных сце-
нариев проектирования и, тем самым, обеспечить общность дальнейшего
рассмотрения, предположим необходимость проектирования традиционной
многоплатной системы, требующей как программной, так и аппаратной
реализации, необходимость обработки аналоговой информации и после-
дующей стыковки с цифровыми фрагментами системы. Сравнение станем
производить с учетом как уже существующей элементной базы, так и совре-
менных тенденций ее развития. Будем предполагать проектирование, опи-
рающееся на возможности современных БИС с программируемой структу-
рой (для реализации как цифровых, так и аналоговых фрагментов системы)
и возможности современных САПР. Укрупненная структура организации
процесса проектирования для подобных систем показана на рис. 2.4.
Хотя относительно традиционных методик процедура проектирования внешне
осталась той же, изменилось содержание и взаимодействие отдельных ее
этапов.
Проектирование на концептуальном уровне возлагается на проектировщика и
слабо связано с автоматизацией. Сложность автоматизации этого этапа свя-
зана со спецификой работ для различных прикладных областей и систем.
Автоматизация касается скорее современных способов получения, копиро-
вания и отображения исходной информации для проектирования и автома-
тизации вычислительных работ. Исходные данные для проектирования на
этом этапе содержат требования к основным технико -экономическим пока-
зателям (производительности, энергопотреблению, стоимости, надежности),
конструктивным и другим параметрам. Кроме того, для управляющих фраг-
ментов системы должны быть определены реализуемые алгоритмы управле-
ния, для типовых дискретных фрагментов — классы выполняемых задач, для
аналоговых — требуемые преобразования и их - свойства (точность, ско-
рость). Это уровень принятия концепций, используемых абстракций, мето-
дик решения и т. д.
Только в отдельных случаях, для тех приложений, которые характеризуются
единством методики решения и используемого математического аппарата,
возможно сквозное применение средств автоматизации. Целый ряд фирм раз -
Рис. 2.4. Структура автоматизированного проектирования
рабатывает средства и методы автоматизации системного уровня проектиро-

вания. Решения, принятые на этом самом первом этапе проектирования, на
80% предопределяют цену конечного продукта, затраты на реализацию про-
екта и скорость появления конечного продукта на рынке. Примерами при-
кладных областей, где обеспечивается достаточно легкая стыковка средств
автоматизации системного и последующих этапов проектирования, является
цифровая обработки сигналов (DSP), анализ и синтез динамических систем.
Фирма Elanix (www.elanix.com) предлагает редактор SystemView, обеспечи-
вающий взаимодействие с проектным потоком фирмы ХШпх, используемым
для разработки DSP -систем. Работа редактора ориентируется на применение
схем ПЛИС фирмы ХШпх и предлагаемых этой же фирмой стандартных ап-
паратных решений, оформленных в виде модулей интеллектуальной собст-
венности (DSP IP -core) и настраиваемых на конкретные условия примене-
ния специальной программой — генератором ядер (Core Generator). Редак-
тор SystemView обеспечивает не только решение задач системного уровня
проектирования DSP -систем, но и выполняет функции управления взаимо -
действием отдельных проектных средств. В результате SystemView позволяет

проектировать, оптимизировать и тестировать DSP -алгоритмы. На рис. 2.5
приведены традиционный и предлагаемый фирмой Elanix процессы проек-
тирования.
К производству
кристалла
Рис. 2.5. Начальные этапы проектирования DSP -систем на базе схем фирмы Xilinx
Другой проблемной областью, имеющей хорошо отработанную математиче-

скую базу, и для которой возможно использование САПР, начиная с самых
начальных этапов проектирования, является разработка вычислительных
комплексов, управляющих динамическими системами. Примером САПР,
поддерживающей проектирование подобного класса приложений, может
служить пакет Professional VisSim фирмы Visual Solutions, Inc. (www.vissim.com).
Программный пакет VisSim объединяет в своем составе интуитивно простой
блочный диаграммный интерфейс с мощными моделирующими программа-
ми. Структура взаимодействия основных компонентов пакета приведена на
рис. 2.6. В состав Professional VisSim входит блок VisSim Viewer, который по -
зволяет разработчику еще до покупки лицензии определить необходимый и

целесообразный набор средств пакета.
Рис. 2.6. Основные компоненты пакета Professional VisSim
Все версии Professional VisSim включают интегрированные с ним известные

пакеты MATLAB, SIMULINK и MathCAD. Задачей блока VisSim/Analyze
является линеаризация нелинейных систем. В основе работы блока лежит
анализ корневого годографа и частотный анализ непрерывных и дискретных
систем. Блок VisSim/OptimizePRO —вычисляет оптимальные значения ос-
новных характеристик и параметров проекта исходя из ограничений, уста-
новленных пользователем, и начиная от заданных им приближенных значе-
ний. Блок VisSim/C Code автоматически преобразует модели пакета в опти-
мизированный на языке С код, который может быть скомпилирован для
работы на большинстве вычислительных платформ. Блок VisSim/Real Time
обладает способностью объединять системные модели с реальным процес-
сом или контроллером для моделирования в реальном масштабе времени
работы проектируемого устройства управления. Ряд дополнительно подклю-
чаемых блоков, таких как VisSim/ModelWizard и VisSim/matLab Compiler, еще
больше упрощает работу проектировщика. Фирма выпускает также про-
граммные прототипные пакеты для ускорения разработок. Графический ме-
тод доступа к моделям элементов позволяет легко создавать, модифициро-
вать и комбинировать состав будущей системы. Пакет позволяет разработ-
чику быстро создать программное обеспечение или виртуальный прототип
Глава 2. Основы технологии проектирования ИСПС У S3
системы или процесса, чтобы определить основные характеристики и пара-

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

на этом этапе, может задавать стиль, методы и средства решения задач по
требуемым направлениям проектирования.
Для многих приложений БИС теперь начинают конкурировать с традици-
онными решениями и вытеснять не только многоплатные конструкции, но
даже вычислительные комплексы на базе персональных компьютеров. Те
задачи, которые ранее решались с помощью подключения разрабатываемого
устройства к ПК, теперь могут быть реализованы в одной БИС. Например,
целый ряд сервисных задач, который раньше мог быть решен только ком-
пьютером, подключенным к телефонной линии, сейчас может быть реали-
зован в одной БИС, встроенной в мобильный телефон.
Если предположить, что проектируемая система требует интеллектуально-
сти, достижимой только при использовании МП или МК, то, прежде всего,
должен быть решен основной вопрос этого этапа — вопрос о технической
реализации микропроцессорного ядра. Возможные варианты реализации
сводятся либо к ориентации на автономный МП, либо на МП, встроенный
в БИС ПЛИС. Если планируется использовать МП, встроенный в БИС
ПЛИС, то возникает очередной вопрос — каким образом будем встраивать
МП? Будет ли МП -ядро представлять собой библиотечный элемент (Soft-
core) для ПЛИС типа generic, или это будет аппаратное процессорное ядро
(Hardcore) в ПЛИС типа SOPC.
Результаты выполнения работ двух рассмотренных этапов позволяют пе-
рейти к последующим параллельным этапам проектирования. В отличие от
традиционного подхода, когда порядок работы сильно зависел от конструк-
торской реализации и достаточно жестко увязывался во времени с оконча-
тельной готовностью макетных плат отдельных проектных направлений, со-
временный подход позволяет выполнять проектирование одновременно для
нескольких направлений. Современные средства и технологии проектирования
позволили разрушить существовавшую ранее жесткую взаимосвязь отдель-
ных направлений и обеспечить возможность выполнения проектных работ в
произвольных взаимных сочетаниях. Даже этап конструкторско -технологи -
ческого проектирования, благодаря легкости перепрограммирования ИСПС,
может начинаться (а иногда даже заканчиваться) до получения окончатель-
ных результатов по всем параллельным ветвям проектирования.
Процедуры проектирования по всем параллельным ветвям в САПР для
ИСПС сходны. Как разработка программного обеспечения для МП(МК) -
ядра, так и разработка дискретной и аналоговой частей проекта могут рас-
сматриваться как последовательность трех основных этапов:
О ввод исходной информации (спецификации проекта);
О компиляция проекта;
О тестирование полученных результатов.
Конкретное содержание этапов для аппаратной и программной частей про-

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

пы всех типов работ с недостижимой ранее скоростью.
Даже для экспериментальной проверки совсем не обязательно ждать реали-
зации будущей системы целиком. Возможна практическая проверка всего
устройства или его отдельных фрагментов с помощью либо специально раз-
работанных устройств, либо предлагаемых различными фирмами достаточно
универсальных наборов отладочных средств, включающих, как правило, от-
ладочную плату, программные средства и методические материалы. Назва-
ния таких средств отражают целевую направленность отладочного средства.
Спектр отладочных средств включает следующие разновидности:
О средства, предназначенные для предварительного знакомства с БИС рас-
сматриваемого класса (обычно это комплекс HW - и SW -средств, назы-
ваемых стартовый набор, Starter Kit);
О средства для оценки применимости проектных решений (обычно вклю-
чают так называемую оценочную плату или демонстрационную плату,
Evaluation Board);
- средства для отладки прикладных проектных решений (обычно базиру-
ются на макетной плате или проектной плате, Development Board);
- средства, замещающие на начальных этапах выпуска готовой продукции
оборудование, которое еще находится в конструкторско -технологической
разработке (обычно называемые прототипными платами, Prototype Plate).
Несмотря на некоторые отличия по имеющимся ресурсам и предлагаемым
возможностям, любой тип плат позволяет выполнять широкий круг экспе-
риментов. Все платы позволяют также изменять программное обеспечение
МП для средств отладки МП -систем, либо содержимое памяти конфигура-
ции для микросхем с программируемой структурой, либо и то и другое для
БИС типа SOPC.
Естественно, что допустимый объем выполняемых экспериментов значи-
тельнее у более дорогих средств. В стартовых наборах обычно удается реали-
зовать и проверить работоспособность лишь отдельных фрагментов будущей
системы.
После успешного завершения экспериментальных работ файлы с програм-
мным обеспечением или файлы памяти конфигурации могут использоваться
либо для изготовления требуемых ИСПС, либо для записи в соответствую-
щие виды промежуточных ПЗУ. Файлы отчетов о результатах компиляции
обычно содержат информацию о конкретных данных по монтированию
проекта в реальную систему или БИС. Поэтому уже после этапа компиля-
ции проектов возможен переход к разработке технологической реализации
проекта, например, к разработке топологии печатных плат, являющихся, как
правило, конечной продукцией проектирования.
Ввиду легкости перепрограммирования как программной, так и аппаратной
части проекта, этап экспериментальных работ с ним может быть отложен до
завершения конструкторской разработки печатной платы. Даже значитель-

ные изменения схемы на основе ИСПС обычно не влекут за собой столь ката-
строфических последствий, как в случаях, использования жесткой стандартной
логики. Для упрощения реализации этого подхода фирмы -изготовители
предлагают набор схем, отличающихся логической мощностью, но имеющих
одинаковое расположение выходных контактов, что делает модификацию
проектов вопросом скорее экономическим (более мощные БИС стоят доро-
же), чем техническим. Поэтому экспериментальные работы целесообразно
проводить на различных отладочных прототипных системах исключительно
для ускорения общего процесса проектирования, поскольку для большинст-
ва ИСПС возможно совмещение во времени этапов конструкторской разра-
ботки и экспериментальных работ.
Итерационные возвраты к повторным процедурам компиляции в ходе кон -
структорско -технологического этапа проектирования возникают в том слу-
чае, когда, исходя из соображений повышения помехоустойчивости или бо-
лее эффективной разводки соединений БИС на печатной плате между со-
бой, целесообразно изменить расположение входных и/или выходных
контактов ИСПС и их подключение к выходным разъемам печатной платы.
Подобная возможность следует из способности современных ИСПС обеспе-
чивать различные варианты монтирования одного и того же проекта в одну
и ту же БИС.
Современные методы проектирования продолжают сосуществовать с тради-
ционными. И те, и другие сильно зависят от варианта реализации проекта
(ветви реализации для рис. 2.4) и в некоторых деталях отличаются друг от
друга, поэтому далее рассмотрим параллельные ветви проектирования по
отдельности.
2.2.1. Проектирование цифровых фрагментов

на заказных ИС и стандартных
дискретных компонентах
Необходимость проектирования цифровой части современных систем
(обычно отвечающей за логику функционирования) на дискретных компо-
нентах малой и средней интеграции, несмотря на рост интеграции ИС, со-
хранилась, хотя объем такой продукции существенно уменьшился и в на-
стоящий момент составляет около 10—20%. В любом проекте может воз-
никнуть ситуация, когда часть ИС не может быть включена в БИС общего
назначения и целесообразно использование элементов МИС. В методике
проектирования при ориентации только на этот тип элементной базы за по-
следнее время особых изменений не произошло. Наиболее существенные
изменения произошли в самом подходе к созданию проектов, замещающих
ранее созданные системы, которые были реализованы на дискретных ком-
понентах или включали значительные фрагменты с подобной реализацией.
При решении задачи перевода реализации таких фрагментов на современ-

ную элементную базу разработчик ставится перед выбором наиболее рацио-
нального варианта. Необходимость перевода диктуется не только и не
столько престижными соображениями, сколько экономическими. Стои-
мость ИС старого типа (из разных соображений и причин) не только не
уменьшается, а иногда даже и увеличивается (малый спрос, например, при-
водит к сокращению или даже прекращению выпуска неперспективных
СИС и МИС). Вместе с тем, во многих проектах остаются фрагменты, тре-
бующие использования специализированных ИС. Примерами фрагментов,
которые обычно не включаются в состав общецелевых БИС, являются
фрагменты, решающие следующие общесистемные проблемы: создание ИС
осцилляторов частоты со средними или высокими требованиями к точности
реализации, гальваническая развязка на основе оптронных элементов, от-
дельные мощные элементы, элементы сопряжения различных систем эле-
ментов и т. д.
Поэтому наряду с выпуском ИС с увеличенной логической мощностью и
функциональными или эксплуатационными возможностями продолжается
выпуск МИС, реализующих отдельные логические функции. Например,
фирма Fairchild Semiconductor производит семейство ИС под названием
TinyLogic, которое представляет собой реализацию в одном корпусе
(различных габаритов) одной единственной функции, например функции
2И -НЕ или аналогового ключа.
Для разработчиков цифровых фрагментов фирмы -производители электрон-
ного оборудования предлагают различные варианты технологической реали-
зации. Если исключить разработку полностью заказных схем, то у разработ-
чика остаются направления, показанные на рис. 2.7.
ASIC
(новые свойства)
Конвертация
Рис. 2.7. Технологии проектирования и реализации цифровых фрагментов

Возможно проектирование по четырем основным направлениям: традици-

онная реализация на дискретных схемах СИС/МИС, реализация на ПЛИС,
программная интерпретация цифровой схемы на МК и реализация в форме
полузаказного кристалла того или иного типа. Естественно, при физической
реализации конечной продукции может оказаться целесообразным приме-
нение любых комбинаций перечисленных вариантов. Более того, реализация
ряда комбинаций может оказаться целесообразной и в рамках единой БИС.
Так, например, уже появлялись сообщения [43] и [46] об объединении в од-
ной БИС схемы ASIC и фрагмента ПЛИС. Этот вариант иногда считают
средним путем реализации полузаказных схем. Его же ряд производителей
называет вариантом ПЛИС со встроенными стандартными блоками. По-
следнее определение представляется предпочтительным, т. к. в большей ме-
ре отражает способ создания структуры такой комбинированной БИС. Сле-
дует ожидать, что номенклатура блоков, относимых к стандартным, будет
постоянно увеличиваться, и у разработчика появится большая свобода вы-
бора реализации БИС.
В тех случаях, когда при переходе к реализации в другом типе БИС проект
не меняет своего функционирования, а сама процедура перевода выполняет-
ся в автоматическом или полуавтоматическом режимах, процесс носит на-
звание конвертация проекта. На рис. 2.7 показаны такие варианты перехо-
дов от одного способа реализации к другому.
Каждый базовый вариант проектирования характеризуется своим специфи-
ческим потоком проектирования, более того, маршруты проектирования у
разных фирм могут отличаться. Представляется целесообразным более под-
робно остановиться на потоках проектирования, характерных для основных
вариантов реализации.
Реализация в базисе дискретных элементов

типа МИС и СИС
Рассмотрим традиционную реализацию в базисе дискретных элементов типа
МИС и СИС. На рис. 2.8 показан маршрут проектирования, характерный
для такого способа реализации цифровых фрагментов.
При традиционном проектировании основные изменения коснулись пре-
доставляемой элементной базы и возможностей САПР. Эти изменения
взаимосвязаны, например, увеличение объема доступной к использованию
номенклатуры ИС потребовало включения характеристик этих элементов в
состав библиотек САПР. Целый ряд фирм — Mentor Graphics Corporation,
Synplicity, Innoveda (прежде ViewLogic, Inc.) — предлагают САПР, ориенти-
рованные на задачи проектирования систем класса ASIC. Приведенное на
рисунке распределение функций, естественно, является условным. В неко-
торых случаях фирма -изготовитель готова взять на себя большую долю про-
ектных работ, чем изображено на рисунке.
Традиционная процедура Современные добавки
Рис. 2.8. Типовая последовательность проектирования цифровых фрагментов
Для рассматриваемого направления САПР изменяют и сам подход к проек-

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

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

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

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

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

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

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

задания системы межсоединений
Laser -programmable MPGA/SC FPGA/CPLD

gate array
Время до выпуска Дни Недели Минуты или часы
первого кристалла
Тактовая частота В 1,1 раза меньше В 1,25 раз меньше В 3—5 раз
меньше
Площадь В 3,3 раза больше В 1,6 раз больше В 10—20 раз

больше
Если разработчик ориентируется на реализацию проекта в виде полузаказ-

ной БИС, то, независимо от способа ее изготовления, в процессе разработ-
ки требуется выполнение согласованных и/или совмещенных работ заказчи-
ка (или проектировщика) и фирмы -изготовителя ИС. Формы взаимодейст-
вия и используемое оборудование зависят от многих факторов, в том числе
от фирмы -изготовителя и от формы заказа. Далее рассмотрим проектные
процедуры для некоторых типичных примеров, отличающихся технологией
изготовления конечного продукта.
Фирма American Microsystems, Inc. (AMI) обеспечивает производственный
выпуск семейства БИС типа AMI3HS с проектными нормами 0,35 мкм, от-
носящихся к классу ASIC и с технологией изготовления по методу стан-
дартных ячеек (Standard Cell).
Архитектура БИС, предлагаемая фирмой AMI, строится на основе следую-

щих основных фрагментов: индивидуальных функциональных ячеек, мега -
ячеек (megacells), информационных функциональных блоков (datapath func-
tions) и блоков памяти, которые с целью уменьшения размеров и повышения
быстродействия являются оптимизированными и предварительно скомпи-
лированными. Фирма специализируется на проектировании дополнитель-
ных схем заказчика, связанных с выполнением логических и даже простых
аналоговых функций. Библиотека мегаячеек фирмы весьма обширна, чрез-
вычайно гибка и включает: процессорные ядра от 8 до 32 разрядов, набор
периферийных элементов от таймеров до дисковых контроллеров, информа-
ционные фрагменты от сдвигающих регистров и сумматоров до умножите-
лей, различные виды буферных блоков FIFO.
Рассмотрим типовую процедуру проектирования БИС этого типа. БИС по-
зволяют реализовать проекты заказчика, содержащие до 4 млн. вентилей
в кристалле плюс емкость встраиваемой памяти. Основные этапы проектной
процедуры, принятой фирмой, приведены на рис. 2.9.
Из рисунка видно, что проектирование выполняется в тесном - взаимодейст-
вии заказчика и изготовителя. Работы требуют стыковки САПР, используе-
мых заказчиком и изготовителем. Фирма AMI имеет собственную САПР под
названием ACCESS Design Tools, которая интегрирует программные средст-
ва для верификации цифровых ASIC -проектов, для конвертации FPGA - или
ASIC -проектов в ASIC -проекты или для корректировок и конвертации
ASIC -проектов в другие формы. Пакет и методология его использования
обеспечивают значительное сокращение времени проектных работ, умень-
шают величину однократных (начальных) денежных вложений заказчика в
проект (в английской терминологии NRE, Non Recurrent Expends), увеличи-
вают вероятность успешности выпуска уже первых образцов кристалла. Па-
кет поддерживает методологию компактного проектирования, хорошо согла-
сованного с производственным процессом фирмы, а сама фирма предлагает
помощь разработчикам на любых этапах проектирования.
Для ускорения и упрощения импортирования описаний из САПР различ-
ных фирм, AMI ориентируется на языки Verilog и VHDL. Стандартизация
описаний предопределяет простоту переводов проектов в различные техно-
логические реализации, включая перевод в MPGA, другие классы ASIC и т. д.
Заказчик ИС для выполнения своей части работ может использовать САПР
фирм Cadence, Mentor Graphics, Synopsys, Viewlogic, Veribest и некоторых
других. Проектирование начинается с передачи изготовителем ИС заказчику
проектного набора, содержащего библиотеку ячеек, их символьного изобра-
жения, моделей для симуляции, а также программного обеспечения для
проектной верификации, вычисления временных соотношений и генерации
списка соединений. Временное моделирование до разводки опирается на
среднестатистические фирменные данные о значениях емкостей и сопротив-
лений межсоединений. После детальной разводки, выполняемой фирмой -
Рис. 2.9. Этапы проектирования продукции класса ASIC SC,

используемые фирмой American Microsystems, Inc.
изготовителем, таблицы емкостей и сопротивлений действительных соеди-

нений передаются разработчику и используются им для определения ожи-
даемых фактических временных параметров прибора. Одновременно с ра-
ботой над собственно проектом, заказчик и изготовитель подготавливают
тестовые процедуры для проверки доводочных модификаций и готовых из-
делий. К доводочным испытаниям прибегают после вставок элементов гра-
ничного сканирования JTAG/SCAN, выполнения оптимизации размещения
In -Place Optimization (IPO), а также после выполнения процедуры баланси-
ровки времен синхронизации (ВСТ) отдельных фрагментов. Только после
получения удовлетворительных результатов моделирования, произведенных
заказчиком, фирма -изготовитель приступает к выпуску масок и подложек.
Тестовые программы разрабатываются заказчиком и изготовителем совмест-
но на базе САПР и тестируются на прототипах перед их окончательной
сдачей.
Существенными факторами, которые предопределяют ориентацию разра-
ботчика на продукцию той или иной фирмы, являются логическая мощ-
ность кристаллов, тактовая частота или задержка на вентиль, а также пре-
доставляемый фирмой -изготовителем набор библиотечных элементов, сроки
изготовления, стоимость при различных объемах партии, потребляемая
мощность, возможность управления различными режимами потребления
и т. д.
Приведенная выше процедура проектирования остается справедливой и при
реализации в форме матричных кристаллов. Фирма AMI, кроме технологии
стандартных ячеек, поддерживает выпуск кристаллов класса МРСА. Произ-
водимые фирмой БМК -кристаллы семейства AMI5HG с проектными нор-
мами 0,5 мкм (от 4,6 до 1320 тыс. вентилей в кристалле) выполняются по
бесканальной технологии типа "море вентилей", разрабатываются на той же
САПР ACCESS Design Tools и по такой же технологической схеме. Некото-
рые отличия наблюдаются только в составе библиотек.
Другой фирмой, выпускающей БИС класса ASIC с технологией изготовле-
ния по методу базовых матричных кристаллов МРСА, является фирма LSI
Logic Corporation. Фирма является ведущей в мире по числу вентилей в кри-
сталле (до 33 млн. вентилей). В качестве примера рассмотрим проектный
процесс при ориентации на кристаллы типа Gl0p с проектными нормами
0,35 мкм.
В основе проектной процедуры лежит использование фирменной техноло-
гии под названием FlexStream, которая интегрирует в своем составе как
специфические собственные проектные средства, так и встроенные лучшие
САПР других фирм, таких как Avanti, Cadence, Mentor Graphic и Synopsys.
Подобное объединение различных средств в единой оболочке позволяет ис-
пользовать эту технологию на всех уровнях проектирования (системном,
логическом и физическом).
В состав собственных средств фирмы, помимо библиотек, включаются про-

ектные средства, которые позволяют осуществлять проектный анализ, ин-
терфейс со стандартными САПР, вычисление задержек, генерацию модулей,
контроль проектных норм и т. д. Так же, как и фирма AMI, фирма LSI
Logic в процессе работ над выпуском кристалла предполагает тесное взаи-
модействие с заказчиком -проектировщиком. Основное различие состоит в
ориентации фирмы LSI Logic на описания проектов на уровне регистровых
передач. В процедуре проектирования фирма выделяет семь основных кон-
трольных точек. Содержание этапов и взаимодействие разработчика и изго-
товителя приведены на рис. 2.10.
Рассмотрим последовательно маршрут проектирования и кратко охарактери-
зуем работы, выполняемые на отдельных этапах.
- Этап 1. Начало работ над проектом. Заказчиком создается описание про-
екта на блочном уровне и спецификация на уровне регистровых передач
(RTL). В проекте могут использоваться стандартные решения фирмы LSI
Logic — CoreWare. Описание вводится в САПР, САПР контролирует про-
ект и выполняет синтез до вентильного уровня. Одновременно с синте-
зом производится проверка функционирования и соблюдения указанных
временных ограничений. Фирма LSI Logic просматривает спецификации
проекта и может осуществлять консультирование и обучение разработчи-
ков. Процесс контроля и синтеза итерационный. Результатом работ этого
этапа является предварительное разбиение проекта на части и составле-
ние списка соединений.
- Этап 2. Начальное физическое размещение. Список соединений и огра-
ничения анализируются совместно, чтобы быть уверенными в том, что
проект хорошо структурирован и не содержит фрагментов, которые смо-
гут создать проблемы (во временной области) при физической реализа-
ции. Осуществляется статический временной анализ и функциональная
верификация.
- Этап 3. Пробная разводка. Блоки разводятся, размещаются шины пита-
ния и синхронизации, определяются места максимального скопления
трасс и цепи, нарушающие временные ограничения. Информация о то-
пологическом распределении элементов и граф их соединений объеди-
няются в общий отчет для просмотра.
- Этап 4. Если параметры межсоединений и временные характеристики
оказываются приемлемыми, тогда переходят к окончательному размеще-
нию и трассировке. В случае неудовлетворительных результатов преды-
дущего этапа производится повторное разбиение проекта на части, их
новая организация или производится синтез с измененными ограниче-
ниями. После завершения размещения выдаются данные для верифика-
ции законченного изделия. Приступают к генерации тестирующих про-
грамм.
Рис. 2.10. Маршрут проектирования MPGA, используемый фирмой LSI Logic

- Этап 5. Заказчик анализирует данные, полученные после окончательной

разводки изготовителем. Производится просмотр результатов разводки на
моделях. Осуществляется разработка тестовых программ. При выполне-
нии всех требований проект утверждается и передается на изготовление.
- Этап 6. Фирма -изготовитель выпускает фотошаблоны, изготавливает и
проверяет подложки. Готовность прототипных образцов и тестов позво-
ляют приступить к системному тестированию.
- Этап 7. Удачное завершение системных тестов, производимых заказчи-
ком, служит признаком принятия ИС и завершения проекта.
Основное внимание при выборе технологического процесса и используемых
проектных средств фирма уделяет уменьшению числа итерационных возвра-
тов к процедуре синтеза проекта.
Важным средством, которое существенно улучшает методологию проектиро-
вания схем класса ASIC в форме MPGA/SC, можно считать добавление эта-
па прототипирования схемы MPGA схемами FPGA/CPLD. Для обеспечения
эффективности процесса прототипирования желательно выполнение двух
условий. Во -первых, чтобы для конечного и прототипного вариантов про-
дукции либо использовался совпадающий способ задания исходной инфор-
мации, либо взаимные переводы осуществлялись простыми методами. При
этом методы и средства задания исходной информации могут быть различ-
ными. Общение между САПР изготовителя MPGA и САПР изготовителя
FPGA/CPLD может осуществляться при помощи различных стандартных
языков описания аппаратуры (EDIF, Verilog или VHDL). Вторым условием
является обеспечение структурно -архитектурной близости между двумя ва-
риантами реализации, которые гарантировали бы преемственность функ-
циональных характеристик проекта. Описание на уровне регистровых пере-
дач в наибольшей степени позволяет сохранить близость поведения ориги-
нала и прототипа.
Максимальное совпадение между характеристиками ПЛИС и БМК может
быть обеспечено при совмещении в одном лице фирмы -изготовителя MPGA
и фирмы -изготовителя FPGA/CPLD и при наличии у нее соответствующих
типов БИС. В таком случае наиболее рациональным представляется предва-
рительная реализация проекта в форме ПЛИС. Ведущие фирмы -произво-
дители схем ПЛИС Xilinx и Altera стараются поддержать такое направление.
И та и другая фирма выпускают БМК, соответствующие определенным схе-
мам ПЛИС. В качестве примера проектной процедуры конвертации проекта
на рис. 2.11 приведена процедура переноса проекта, реализованного на БИС
фирмы Altera типа АРЕХ20КЕ или АРЕХ20КС, в форму БМК. Из рисунка
видно, как много проверок содержит конвертационная процедура, включая
проверку основных проектных правил и ограничений DRC (Design Rule -
Check). В том числе, показано формирование файлов для автоматической
генерации тестовых последовательностей для оборудования как общего
Файл
' конфигурационных^
данных
К изготовлению масок
Рис. 2 . 1 1 . Процедура конвертации проектов для БИС типа APEX
назначения ATPG (Automatic Test Pattern Generation), так и встроенных

блоков памяти ESB (Embedded System Blocks).
Фирма Altera анонсировала в 2001 году выпуск БМК типа HardCopy. Семей-
ство БМК этого типа позволяют поддерживать методологию конвертации
проектов из ПЛИС типа APEX с минимальным риском иметь расхождение
в поведении прототипа и конечного продукта (при условии, что логическая
емкость приборов лежит в диапазоне от 400 тыс. до 1,5 млн. вентилей). Ми-
нимизация достигается сохранением всех основных ресурсов ПЛИС типа
APEX при переводе ее реализации в жесткие соединения вместо соедине-
ний, определяемых памятью конфигурации.
Особенностью процедуры конвертации является отсутствие необходимости
у проектировщика вмешиваться в ее процесс. Этот процесс не требует от
проектировщика разработки и создания специальных средств тестирования
(типа генерации Test -Bench, методика создания и использования которых
будет более подробно рассмотрена в гл. 3), разработки тестовых векторов
или временного и функционального моделирования. Естественно, что опре-
деленные тестовые проверки разработчик выполнял при разработке и про-
верке реализации своего проекта на ПЛИС типа APEX. Для проведения
миграции требуются выходные файлы работоспособного проекта, сгенери-
рованного САПР Quartus II для БИС типа APEX. На выполнение процесса
конвертации и изготовление функциональных прототипов фирма Altera за-
трачивает порядка 8 недель, для выпуска промышленной партии требуется
около 16—18 недель.
Экономическая выгода применения БМК типа HardCopy видна из следую-
щих сравнительных данных. Стоимость изготовления комплекта масок для
БИС с проектными нормами 0,13 мкм и с шестью слоями металла, которая
выполняется по технологии стандартных ячеек, превышает 750 тыс. долла-
ров. Поскольку к этой стоимости необходимо добавить дополнительные
расходы фирмы -изготовителя БМК на подготовительные операции к проек-
тированию и производственному процессу, то общая сумма расходов пре-
вышает 1 млн. долларов. Для проектирования БМК типа HardCopy фирма
Altera обещает затраты на уровне 300 тыс. долларов [33].
Фирмы, специализирующиеся на производстве полузаказных БИС, также
стараются поддерживать технологии конвертации проектов, выполненных
на схемах типа ПЛИС, что делает целесообразным проектирование по ветви
FPGA -ASIC. Однако временное отставание фирм -изготовителей БИС БМК
в выпуске схем, соответствующих определенному классу схем ПЛИС, от
темпов снижения цены на перспективные типы ПЛИС фирмами -произво-
дителями БИС ПЛИС часто создает ситуацию, когда экономически невы-
годно отказываться от выпуска продукции на основе схем ПЛИС.
Целесообразность конвертации проектов из ПЛИС в форму БМК может
следовать не только из экономических соображений. Как правило, помимо
большей уверенности в работоспособности проекта, этот подход дает и оп-

ределенные дополнительные выгоды, например, допускает работу на боль-
ших системных частотах, меньшую стоимость, меньшую потребляемую
мощность и т. д.
Еще одним важным моментом, который следует учитывать при поиске ра-
циональной формы реализации конечного продукта, является отработан-
ность у фирм технологии конвертации проектов ASIC -ASIC. Наличие таких
технологий создает предпосылки для сохранения у проекта резервов за счет
простоты перевода в реализации с другими и более перспективными харак-
теристиками. Необходимость таких переводов может быть связана как с
экономическими соображениями (схемы с меньшими топологическими нор-
мами, как правило, имеют лучшие эксплуатационные характеристики и
стоят дешевле), так и с возможностью реализовать проект с другими элек-
трическими или эксплуатационными характеристиками (примером может
служить перевод проекта на современные значения напряжения питания,
включение проекта в систему со смешанными выходными напряжениями
и т. д.).
Современное возрастание сложности проектов заставляет искать технологи-
ческие варианты реализации проектов с гарантированными свойствами. Од-
ним из основных путей увеличения надежности проектирования при усло-
вии сокращения времени на проектирование является увеличение доли уже
отработанных и проверенных или просто стандартных решений.
Варианты реализации стандартных решений и способы их использования
проектировщиком могут существенно отличаться. Непрерывно увеличивает-
ся число фирм, специализирующихся на разработке библиотек стандартных
фрагментов для различных типов и видов ASIC продукции (IP -core). Про-
цесс добавления такого стандартного фрагмента может иметь различную
технологическую реализацию. Чаще всего фрагменты разрабатываются и
записываются на одном из языков описания аппаратуры и вставляются
в проект перед процедурой синтеза.
Реже используются варианты добавления стандартных фрагментов на этапах
топологического проектирования, хотя именно топологическая оптимизация
может резко улучшить временные характеристики фрагмента при сохране-
нии его размеров. Для БМК фирма -разработчик IP -core должна обеспечить
простоту переноса топологии стандартного фрагмента (систему межсоеди-
нений) на произвольное место среди массива вентилей. Для технологии
стандартных ячеек может использоваться как перенос топологии стандарт-
ной ячейки на любое место массива ячеек, так и фиксированное размеще-
ние в кристалле стандартных фрагментов. Фирма AMI для фрагментов пер-
вого типа, в зависимости от их сложности, использует название мегаячейка
(megacell) или информационный функциональный блок (datapath function), a
для второго типа — скомпилированный блок (compiled block). Скомпилиро-
ванные блоки (в подавляющем большинстве случаев это те или иные вари -
анты блоков памяти) оптимизированы по площади, скорости и потребляе-

мой мощности, но могут размещаться только в заранее определенных местах
кристалла.
2.2.2. Проектирование
микропроцессорных фрагментов систем
Для большого числа современных проектов (от 60 до 80%) основой функ-
ционирования является работа программного обеспечения на платформах
либо общецелевых, либо заказных (чаще DSP) процессоров. Причины появ-
ления МП в системе могут быть различными — от необходимости использо-
вать сложные программные системы в минимальном конструктивном ис-
полнении, до просто престижных соображений разработчика. Несмотря на
то, что использование 8 -битовых микроконтроллеров в разнообразных
встроенных системах насчитывает уже почти 20 -летнюю историю, не прихо-
дится сомневаться, что существующая практика ориентироваться на встро-
енные микропроцессорные решения сохранится и в будущем. Однако в све-
те новейших технологических и архитектурных достижений микроэлектро-
ники, и особенно в связи с развитием ИС с программируемой структурой,
целесообразные варианты построения и проектирования современных сис-
тем явно изменились и желателен их пересмотр.
Широкое практическое распространение двух альтернативных способов
оперативного изменения поведения системы на уровне корректировки па-
мяти программы МП или на уровне корректировки памяти конфигурации
ПЛИС привели к возникновению новых архитектурных решений. На рис. 2.12
приведены некоторые возможные варианты.
На крайних полюсах этих решений располагаются, с одной стороны, обыч-
ная микропроцессорная система или однокристальный микроконтроллер
МК, а с другой — обычная ПЛИС. При определенных условиях оба вариан-
та могут решать одну и ту же задачу. Ранее замена реализации системы из
дискретных компонентов на МПС (МК) диктовалась либо требованием ми-
ниатюризации конструкции, либо способностью к корректировкам поведен-
ческой реакции без каких -либо конструкционных изменений на любых эта-
пах жизни конструкции. В современных условиях оба варианта отвечают
этим требованиям.
Вариант решения в форме связанных между собой БИС МП и БИС ПЛИС
соответствует реализации с очень гибкими возможностями модификации
организации всей интерфейсной части микропроцессорной системы, а по
гибкости значительно опережает традиционную архитектуру микропроцес-
сора, соединенного с набором программируемых периферийных БИС. По-
добная организация системы позволяет сформировать периферию МП в
произвольных сочетаниях — ограничениями являются не столько логиче -
екая мощность ПЛИС (обычно можно в том же корпусе установить более

мощную ПЛИС), сколько количество конструктивно предусмотренных кон-
тактов ввода/вывода. Классические МПС могут достигать таких возможно-
стей только при многоплатных или мезонинных технологиях, когда за счет
изменения типа платы, подключаемой к основной плате, создается конфи-
гурация системы с заданными ресурсами.
Рис. 2.12. Современная организация систем

с оперативно корректируемым поведением
Еще большими потенциальными возможностями обладают системы, совме-

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

важно для последующего анализа процедуры проектирования SOPC. Во -вто-
рых, широкое распространение ИСПС оказало и оказывает существенное
влияние на различные аспекты процедуры проектирования традиционных
МПС. Таким образом, тесная взаимосвязь и фактическая близость проблем
проектирования традиционных МПС и SOPC заставляют более подробно
остановиться на особенностях реализации микропроцессорных фрагментов
в современной аппаратуре. Вместе с тем, следует учитывать, что методы,
решения и средства, которые создавались и продолжают разрабатываться
для систем на кристалле SOPC, далеко не всегда могут быть применены
в традиционных микропроцессорных системах.
Поскольку методика проектирования микропроцессорной составляющей в
БИС SOPC в значительной мере опирается на опыт, полученный при про-
ектировании традиционных МПС, приводимый ниже материал посвящен
анализу влияния ПЛИС на различные этапы разработки традиционных
МПС. А специфика и проблематика проектирования микропроцессорной
составляющей в SOPC будет рассмотрена в разд. 2.5.
Важнейшим аспектом современного проектирования является ориентация
на привлечение проектных средств, поддерживающих проектирование мик-
ропроцессорных ядер. Методика привлечения заключается либо во включе-
нии этих средств в состав САПР ПЛИС, либо в организации связи инстру-
ментальных средств проектирования программных средств и САПР ПЛИС.
Методика проектирования микропроцессорных систем на традиционной
элементной базе к настоящему времени в достаточной мере стабилизирова-
лась. Состав и назначение отдельных этапов проектирования при ориента-
ции на традиционные реализации сохранились, однако произошли измене-
ния содержания отдельных этапов.
Эти изменения связаны с тем, что теперь не обязательно ожидать реализа-
ции аппаратной части проектируемой системы перед переходом к проекти-
рованию программной части системы, как это приходилось делать до по-
следнего времени. Это положение наглядно иллюстрируется рис. 2.13.
Рис. 2 . 1 3 . Традиционное временное распределение процессов проектирования

Стремление уйти от этого периода ожидания потребовало изменения инст-

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

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

Первым этапом является этап выбора типа МП. Для традиционного подхода
система команд и архитектура МК или МП всегда носили предопределяю-
щий характер и оказывали исключительное влияние на эксплуатационные
характеристики проектируемой системы, поэтому этап выбора типа процес-
сорного ядра был особенно важен. Выбор процессорного ядра предопреде-
ляет все составляющие проектного процесса: доступные аппаратные ресур-
сы, имеющиеся программные заготовки (библиотеки стандартных программ,
наличие разработанных систем реального времени), наличие разработанного
инструментария проектирования и отладки, методики проектирования. Это
положение было особенно существенно для микроконтроллерной реализа-
ции, поскольку выбор семейства предопределяет и допустимые варианты
процессорной периферии (объемов и типов памяти, скоростей и типов дру-
гих периферийных устройств, достаточного количества входных/выходных
портов и т. д.). К настоящему времени острота проблемы несколько умень-
шилась как со стороны HW, так и со стороны SW. В части HW, во -первых,
произошла стандартизация свойств и параметров периферийных блоков, а
во -вторых, в них появилась гибкость и возможность выполнения в опреде-
ленных пределах корректировок внутренней организации. В части SW раз-
работчиками постоянно предпринимаются усилия, чтобы облегчить перено-
симость его с одной аппаратной платформы на другую.
Тем не менее, выбор МП или МК был и остается важнейшим этапом про-
ектирования. Для оценки возможных направлений поиска обратимся к
табл. 2.2 и 2.3, составленным на основании данных, приведенных в [41, 42].
Таблица 2.2. Количество фирм, производящих МП/МК

(кроме процессоров DSP и сетевых)
8 разрядов 16 разрядов 32 разряда 64 разряда

Число фирм 20 9 28 6
Число типов МП/МК 38 15 71 13
Таблица 2.3. Количество фирм, производящих процессоры DSP и сетевые
16 разрядов 32 разряда Специализированные
Число фирм 10 3 10
Число типов МП/МК 13 5 12
В табл. 2.2 приведено количество фирм, производящих МП/МК выбранной

разрядности и общее число выпускаемых типов МП/МК. В таблицу не
включены процессоры DSP и сетевые процессоры. Табл. 2.3 содержит ин-
формацию о DSP -процессорах и специализированных DSP -ядрах.
После 2000 года процессоры DSP по рыночным показателям (объем продаж)
переместились на первое место среди процессорных ядер, сменив традици-
онного лидера — 8 -разрядные МП -ядра. Содержание таблиц подтверждает
следующие выводы. МП и МК, имеющие 8 -разрядную организацию, сохра-
няют большую часть уже завоеванного рынка продукции, причем (из дан-
ных тех же источников) более 40% фирм поддерживают выпуск клониро-
ванных MCS -51. Стремительно развивающийся сектор телекоммуникацион-
ных приложений существенно увеличил выпуск 32 -разрядных МП, а 16 -раз-
рядные решения и для МК, и для МП имеют достаточно ограниченную и
стабильную сферу приложений. Для традиционной МП -реализации опреде-
ленное распространение получил промежуточный вариант — 16 - или даже
32 -разрядное процессорное ядро и 8 -разрядная организация периферии.
Отмеченная ситуация еще более четко прослеживается на отечественном
рынке.
Сложившаяся ситуация возникла потому, что затраты при замене 8 -раз-
рядной шины на 16 -разрядную или, тем более, 32 -разрядную достаточно
велики. В то же время, вполне возможна эмуляция особенностей 16/32 -раз-
рядного процессорного ядра, опираясь на дешевое 8 -разрядное ядро. По-
этому проектировщикам приходится тщательно оценивать соотношение
экономического выигрыша и потерь скорости и увеличения объемов испол-
няемого кода. Для отечественных разработчиков на выбор МП -ядра, по -
видимому, существенное влияние оказывает широкое распространение пер-
сональных компьютеров (ПК) класса PC для реализации разнообразных за-
дач. Необходимость использования в этих компьютерах плат расширения с
32/64 -разрядной организацией шинного интерфейса, составляющих сущест-
венную часть отечественных разработок, создает предпосылки для переноса
центра тяжести перспективных разработок в область больших разрядностей.
Сокращается число употребляемых процессорных ядер. Лишь незначитель-
ное число систем команд и базовых архитектур МП получают широкое рас-
пространение. Большинство фирм, выпускающих МП и МК, пытаются
обеспечить распространение своей продукции не за счет оригинальности

внутренней архитектуры МП или, тем более, системы команд, а за счет бо-
лее эффективных сопровождающих решений (например, удобные типораз-
меры корпусов, малое потребление мощности, малая стоимость, удобный
набор встроенных блоков памяти и т. д.). Такие клонированные МП в неко-
торых случаях полностью замещают продукцию фирмы -разработчика исход-
ной архитектуры МП. Стремление разработчиков максимальным образом
обеспечить преемственность и применимость решений из ранних разрабо-
ток не создают плацдарма для появления новых типов МП и МК.
Вновь разрабатываемые БИС SOPC также ориентируются на включение в
свой состав^наиболее распространенных типов МП и МК. Это позволяет
сэкономить усилия при создании новых вариантов фрагментов програм-
много обеспечения, базируясь на модификации блоков, ранее разработанных
и отлаженных в предшествующих реализациях. Многие из фирм, учтенные в
таблицах, специализируются на выпуске интеллектуальной собственности
(Intellectual Property, IP), соответствующих архитектуре наиболее популярных
процессорных ядер. Для реализации SOPC можно ожидать постепенного
смещения центра тяжести на использование МП с большей разрядностью.
Для 32 -разрядных приложений в настоящее время наибольшее распростра-
нение получили два типа RISC -процессорных ядер — это разработка фирмы
ARM Limited (система команд ARMv4T с расширениями для семейства
ARM7/ARM7TDMI или семейства ARM9 Thumb) и разработка фирмы MIPS
Technologies (MIPS32 4КсВ). Достаточно широкое распространение имеют
архитектуры и системы команд таких МП, как Power PC, 68K/CPU32, ColdFire,
MiniRISC, TinyRISC.OakDSPCore.
Этап выбора периферии

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

средств и блока программируемой логики, что соответствует традиционной
идеологии SOPC и будет рассматриваться в разд. 2.5. Промежуточным вари-
антом является идеология фирмы Agere Systems. В выпускаемые этой фир-
мой ПЛИС семейства ORCA4, помимо элементов программируемой логики,
включен определенный набор стандартных встроенных периферийных уст-
ройств, а также интерфейсных средств, упрощающих связь с целевым МП
(не входящим в состав БИС). Возможность настройки интерфейса на под-
ключение различных типов МП порождает достаточно широкие перспекти-
вы подобного подхода.
Реализация в форме БИС SOPC имеет, помимо обычно перечисляемых дос-
тоинств, еще одну особенность — согласованность характеристик МП и
встроенных блоков памяти. Последнее позволяет существенно поднять так-
товую частоту встроенного МП, например, для БИС Е5 фирмы Triscend так-
товая частота типового МП -семейства 8032 поднята до 40 МГц.
Этап разработки программного обеспечения

После выбора стандартной аппаратуры и разработки специфического обору-
дования ввода/вывода (по крайней мере, после четкой спецификации
свойств и характеристик этого оборудования) переходят к этапу разработки
и отладки программного обеспечения. Временное запаздывание начала ра-
бот по разработке программного обеспечения (отраженное на рис. 2.13) яв-
ляется основной болевой точкой проектирования аппаратно -программных
систем. В разд. 2.5, посвященном проектированию БИС SOPC, будет пока-
зано, как эта проблема решается при современном подходе. Однако и для
традиционной реализации МПС появление ПЛИС существенно повлияло
на применяемые средства и методы разработки и отладки программного
обеспечения. На рис. 2.15 показан состав средств, поддерживающих типо-
вую процедуру разработки программного обеспечения. Если отладку про-
граммного обеспечения предполагается производить сразу в конечной сис-
теме, то этой отладке должна предшествовать отладка аппаратуры, и только
затем отладка аппаратных и программных средств может производиться со-
вместно. Необходимость подобного совмещения отражена на рис. 2.13.
Существенным вопросом, решаемым в начале этого этапа, является выбор
технических средств, поддерживающих разработку и отладку программного
обеспечения. На разных этапах отладки может использоваться различный
набор отладочных средств. Стремление ускорить проектирование может
приводить к тому, что одним из оснований выбора типа МП -ядра может
оказаться ориентация на определенную САПР и спектр поддерживаемых ею
отладочных средств. Конечно, при этом приходится учитывать и другие ха-
рактеристики САПР, такие как доступность, цена, эффективность, удобство
работы и пр. Для проектирования программной части МП -фрагментов на-
бор используемых программ, как правило, объединяется в единый комплекс
и управляется программой, обычно называемой оболочкой проектирования.

Для комплексной отладки набор используемого оборудования не ограничи-
вается ЭВМ и находящимся в ней программным обеспечением, а требует
дополнительного привлечения достаточно большого количества разнообраз-
ного вспомогательного оборудования. Поэтому для такого комплекса
средств, как правило, используется понятие система разработки. Причем,
для всех этих средств разработки и отладки характерна большая ориентация
на возможности и ресурсы, предоставляемые основным (Host) компьюте-
ром. Иногда его называют инструментальным или отладочным компьюте-
ром. Отлаживаемую систему, соединенную с Host -компьютером, называют
в этой cвязке Target -системой.
Рис. 2.15. Состав современной системы разработки МПС

Большое значение имеет возможность прототипирования проектируемой

системы. Традиционно используемые типы прототипных плат и их назначе-
ние были рассмотрены в разд. 2.2.
Средства поддержки
создания программного обеспечения
Рассмотрение состава средств разработки ПО микропроцессорных систем
целесообразно начать с важнейшей составляющей этих систем — средств
упрощения и ускорения процесса создания программного обеспечения. Во-
просам, методологии и технологии создания программного обеспечения
МПС посвящено достаточно большое количество работ [7, 10]. Необходи-
мость ускорения разработки специализированного ПО вызвана тем, что от
этого зависят сроки выхода на рынок конечной продукции. Скорость созда-
ния ПО при ориентации на традиционные методы проектирования не мо-
жет быть существенно увеличена из -за трудности распараллеливания про-
цесса разработки, обусловленного ограниченными возможностями проекти-
ровщиков управлять многосвязными проблемами. Вместе с тем, в реальных
приложениях число параллельно решаемых задач может лежать в диапазоне
от десятков до сотен. Скорость проектирования, достигаемая при примене-
нии существующих методов разработки прикладного ПО, вступает в проти-
воречие с технологией создания новых аппаратных решений. Наряду с раз-
работкой ПО по классическим схемам (линейный подход, процедурный
подход и использование концепций ОСРВ) идет поиск новых подходов к
проектированию прикладного ПО для МПС. В настоящее время наиболь-
шее распространение получили два подхода. Один заключается в использо-
вании систем визуального проектирования, суть другого — применение
стандартных библиотек классов для проблемно ориентированного програм-
мирования. В различных странах идет интенсивный поиск методов и
средств, переводящих процесс разработки прикладного ПО для МПС из
творческого и уникального процесса в стандартный поток выпуска серий-
ной продукции [5].
Не останавливаясь на всей проблематике создания ПО МПС, отметим толь-
ко, что одним из основных направлений быстрой и надежной реализации
программных проектов является широкое использование предшествующих
наработок. Они по источнику возникновения могут быть либо результатом
собственных предыдущих разработок проектировщика, либо входить в со-
став библиотек стандартных программ.
В состав любой современной системы проектирования включаются стан-
дартные библиотеки, а также средства для создания собственных библиотек
пользователей. Стандартные библиотеки могут иметь различную приклад-
ную направленность. Наиболее удобными для использования являются биб-
лиотеки, органически входящие в состав систем проектирования. Боль -
шинство фирм, предлагающих инструментальные средства разработки ПО,

одновременно предлагают и обширные библиотеки, ориентированные на
наиболее распространенные типы МПС и МК. Программные средства под-
держивают все стадии разработки пользовательских приложений. Интегри-
рованные среды для МП и МК выпускаются большим числом фирм. Наи-
большее распространение получили среды разработок SingleStep фирмы
SDS, MULTI фирмы GreenHills Software, VADS, IDE фирмы Keil Software,
Code Composer фирмы Texas Instruments для DSP -разработок.
Значительное число областей приложения микропроцессорных систем свя-
зано с реализацией аппаратно -программных комплексов, работающих в ре-
жиме реального времени. Поэтому существенное место в стандартных сред-
ствах проектирования занимают вопросы упрощения и ускорения разрабо-
ток именно таких систем.
Управление в реальном времени

При использовании МПС в качестве управляющих систем (а этот спектр
продукции представляет весьма значительную часть всей МП -продукции)
задачей программного обеспечения является контроль за физическими про-
цессами и управление ими. Одной из наиболее важных проблем при этом
становится проблема управления процессами в реальном времени. Хотя по-
строение систем, ориентированных на решение таких проблем, в современ-
ных источниках освещено достаточно широко (много информации об
ОСРВ, включая ссылки на публикации по разработке систем реального вре-
мени, можно получить на сайте www.realtime -magazine.com), целесообразно
остановиться на отдельных вопросах реализации подобных систем.
Условно МП -системы, связанные с управлением реальными процессами,
могут быть разделены на три категории: большой сложности, средней слож-
ности и малой сложности. В системах большой сложности основной про-
блемой является распределение ресурсов МП между задачами (распределение
времени). В этих системах могут использоваться ОС общего назначения как
стандартные (такие как Linux, Windows NT), так и расширенные средствами
управления в реальном времени (такие как RT Linux, RTAI). Приобретение
самой ОС и средств разработки для Windows NT, Windows СЕ или RTX по-
требует затрат более 1 тыс. долларов. Время реактивности системы с такими
ОС может лежать в пределах более 1 мс для ОС общего назначения и более
100 мкс для ОС типа RT Linux.
В системах средней сложности основной задачей является время реакции на
события, происходящие в управляемой среде, поэтому здесь применение
ОСРВ оказывается необходимым. Дорогие ОСРВ класса VxWorks обходят-
ся потребителю в 20 тыс. долларов, а более дешевые типа QNX, OS9 —
в 10 тыс. долларов. Время реактивности таких систем лежит в диапазоне
от 10 до 100 мкс. Малыми временами реакции обладает поставляемая фир-

мой WindRiver OCPB VxWorks, что позволяет рекомендовать ее для исполь-
зования в компактных системах реального времени. С 2001 года разработчи-
ки МПС могут бесплатно через Интернет загрузить комплекс Tornado
Prototypes Комплекс включает в себя полную инструментальную среду
Tornado и моделировщик операционной системы VxWorks, работающие в
среде Windows. При таком подходе проект может быть выполнен в рамках
Tornado Prototyper и только на этапе производства конечной продукции по-
требуется приобретение стандартной версии Tornado с включенными сред-
ствами генерации VxWorks.
Требование в системах малой сложности иметь времена реакции порядка
10 мкс оказывается предельным для стандартных СРВ и заставляет отказать-
ся от их применения. В последнем случае необходимо ориентироваться на
аппаратное решение задач управления. И здесь, прежде всего, окажется целе-
сообразным использование ПЛИС и SOPC. Разумное распределение функ-
ций между аппаратной и программной частями SOPC является вариантом
решения возникающих проблем.
Достаточно распространенной ситуацией, особенно для систем средней и
малой сложности, является случай, когда разработчикам ПО представляется
нецелесообразным использование в качестве основы ПО стандартной опе-
рационной системы реального времени ОСРВ. Подобное решение чаще
всего возникает из -за того, что на начальном этапе работ отсутствует или
недостаточно четко специфицирована постановка задач, решаемых про-
граммным обеспечением. Постоянное добавление в ходе разработки новых
функций системы или более сложной ее реакции на совокупности внешних
событий приводит к существенному "разбуханию" программного обеспечения,
и в результате могут возникать ошибки, которые весьма трудно обнаружить,
или даже резкие провалы работоспособности подобной самодеятельной раз-
работки системы управления в реальном времени. В отличие от этого под-
хода ориентация на стандартные средства и механизмы ОСРВ позволяет
проектировщику не только значительно упростить процесс написания про-
грамм, но, что очень важно, приводит к созданию более четко структуриро-
ванной системы, что существенно упрощает ее отладку. В ряде случаев раз-
работчик может остановить свой выбор на той или иной ОСРВ из -за по-
ставляемых одновременно с ОСРВ средств отладки и полезных утилит
отладки. По сравнению с обычными средствами разработки МПС средства
разработки ОСРВ функционально богаче. Как правило, они включают сред-
ства удаленной отладки, средства временного анализа исполнения, средства
эмуляции целевого процессора, средства отладки взаимодействующих задач.
При ориентации на встраивание в состав своей системы стандартной ОСРВ
или ее ядра разработчику необходимо решить вопросы экономической целе-
сообразности. Предлагаемый различными фирмами набор ОСРВ весьма зна -
чителен (более пятидесяти систем упомянуто только в обзорных статьях).

Среди ОСРВ можно выделить группу наиболее популярных систем (соот-
ветственно, у них больше и объем продаж). Это системы VxWorks фирмы
WindRiver Systems, OS -9 фирмы Microware Systems, pSOS фирмы Integrated
Systems, QNX фирмы Quantum Software Systems, LynxOS фирмы Lynx Real -
Time Systems и VRTX фирмы Ready Systems.
Среди ОСРВ традиционно выделяют подкласс ОСРВ, реализующих идеи
ядра. В этот подкласс включаются ОСРВ с монолитным ядром. Внутри ком-
пактного ядра содержится реализация всех основных механизмов реального
времени. Механизмы эти тщательно отработаны и обеспечивают решение
широкого спектра проблем, ядро построено по модульному принципу, сис-
тема легко масштабируется (настраивается на условия конкретного приме-
нения), компактна и ее поведение предсказуемо. Примерами этих систем
являются системы OS -9 и QNX.
Другим вариантом решения задач реального времени для систем малой
сложности (при условии максимального использования стандартных реше-
ний) может являться построение своей ОСРВ i на основе отдельных стан-
дартных решений. Примером фирмы, поддерживающей проектирование
пользовательских ОСРВ, является компания Real -Time User Support Inter-
national (www.rtusi.com).
Помимо экономических соображений разработчик должен учесть техниче-
ские критерии выбора ОСРВ. В основе выбора лежит рассматриваемая далее
цепочка конкретных временных расчетов. На основании анализа событий,
которые могут происходить на управляемых объектах, разработчик выделяет
критические события (события, отсутствие реакции на которые может при-
водить к невосполнимым потерям в системе). С каждым событием сопос-
тавляется критическое время реакции на это событие. После этого ищется
худшая комбинация одновременно возникших критических событий. Цель
такого поиска состоит в определении ситуаций, в которых к ОСРВ предъяв-
ляются наиболее жесткие требования. Знание времен реакции ОСРВ на со-
бытия позволяет достаточно точно определить пригодность той или иной
ОСРВ для управления заданными объектами.
С точки зрения рассматриваемой нами проблемы применения ИСПС суще-
ствует достаточно тесная взаимосвязь с реализацией ОСРВ в SOPC. Такая
близость задач, решаемых ПЛИС и ОСРВ, связана с целевой направлен-
ностью обоих направлений. И то и другое направление связаны с повыше-
нием быстродействия. Одна из основных задач ОСРВ — обеспечение гаран-
тированной временной реакции системы на возникшее событие — может
решаться с новой степенью гибкости, благодаря мобильности аппаратуры.
Возможность построения реконфигурируемых систем на кристалле, а тем
более на динамически реконфигурируемых SOPC, открывает новые пер-
спективы построения систем управления реального времени.
Этапы кодирования и отладки

программного обеспечения
После решения общих принципов построения программного обеспечения
МП -систем разработчики переходят к написанию и отладке ПО. Основные
изменения в методике и средствах отладки связаны с увеличением взаимо-
связи между Host - и Target -системами (при этом не важно, является ли
Target -система прототипом или конечным продуктом).
Изменения начинаются с первых шагов проектирования.
Первый этап работы — создание исходных файлов. Создание исходного файла
независимо от языка программирования поддерживается современными ре-
дакторами. Встроенные в проектную оболочку или внешние подключаемые
(типа Prism Editor) редакторы существенно упрощают процедуру набора и
предварительного контроля вводимых программ. Для этого редактор под-
держивает контекстную цветовую окраску всех синтаксических конструк-
ций программы. Непрерывно проверяется синтаксическая корректность
программы. При сомнениях в синтаксических конструкциях можно вызвать
не только подсказку (Help по конструкции), но и включить в текст состав-
ляемой программы шаблон выбираемой конструкции (Template). Можно
вывести и просмотреть все последующие предложения, содержащие изме-
нения выбранной переменной. Большое количество редакционных действий
над группами объектов значительно упрощает работу с исходным текстом
программы.
Очередной этап работы — компиляция программ обычно поддерживается для
двух основных языков: языка ассемблера и языка С или C++. В последнее
время использование конструкций ассемблера все чаще допускается прямо
среди операторов языка С. В комплекты обычно включаются программы
редактирования связей (компоновщики), оптимизированные библиотеки,
архиваторы/библиотекари и набор различных утилит. Современная компи-
ляция с языка С обычно поддерживает создание различных вариантов про-
граммного кода, например, возможности компиляции от строгого ANSI С
до ANSI С с различными расширениями. Программист имеет возможность
настраивать компилятор на работу с различной степенью локальных или
глобальных оптимизаций, создающих программный код, оптимизированный
по скорости и/или размерам.
Следующий этап — один из самых ответственных этапов проектирования —
отладка программы. В различные периоды развития средств разработки ПО
использовались и получили распространение различные подходы к отладке
программного обеспечения. Традиционное временное распределение взаи-
моотношений между разработкой программного и аппаратного обеспечения
было показано на рис. 2.13.
Неправильная работа может быть связана с ошибками программы и аппара-
туры. Поэтому, чтобы обеспечить быстроту и качество отладки, желательно
пользоваться различными методами и аппаратурой. Отладка может происхо-

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

тальных работ, осуществлять быструю коррекцию аппаратных и програм-
мных решений. Поэтому широкое распространение получают методы уда-
ленной отладки. Отладочные средства сконцентрированы при такой органи-
зации экспериментов около компьютера ведущей системы (Host -системы), а
соединение ведущей системы с отлаживаемой системой (Taiget -системой)
позволяет достаточно просто создавать любые исследовательские комбинации.
Методы
комплексной аппаратно -программной отладки
Исторически первым появился и использовался принцип EPROM -прото -
типирования Идея метода иллюстрируется рис. 2.16. Отладка сводится к
тому, что исследуемая программа, оттранслированная в ПК, при помощи
программатора зашивалась в БИС программируемой тем или ином спосо-
бом схемы ПЗУ (EPROM, ОТР и т. д.). После этого ПЗУ помещалось в от-
лаживаемую систему, на ней выполнялись эксперименты, на основе данных
экспериментов принималось решение о целесообразных направлениях из-
менений разрабатываемой программы, и процесс повторялся.
Отлаживаемая система
Рис. 2.16. Метод EPROM -прототипирования
Метод применялся и для памяти программ, внешней относительно МП/МК,

и для встроенной в МК. Более перспективной представляется модификация
метода, приведенная на рис. 2.17. Она опирается на широкое распростране-
ние в современных программных системах электрически перепрограмми-
руемой памяти типа Flash и методов внутрисистемного программирования
(In System Programmability, ISP) подробно рассматриваемых в разд. 2.6.
Рис. 2.17. Современная модификация метода EPROM -прототипирования
В этом методе объединение отлаживаемой системы с отладочным ПК через

интерфейсный блок позволяет многократно производить вышеописанную
отладочную процедуру без необходимости вынимать из отлаживаемой сис-
темы программируемый элемент (ПЗУ или МК). Вариант интерфейсного
блока определяется протоколом, который поддерживается программируе-
мым элементом. Еще совсем недавно практически отсутствовали средства
внутрисхемного программирования и соответствующие методики. Это при-
вело к распространению промежуточного варианта реализации, носящего
название эмуляция ПЗУ. В основе метода (рис. 2.18) лежит использование
специального оборудования — эмулятора ПЗУ. Базой эмулятора является
БИС ОЗУ, содержимое которого загружается из отладочного ПК. В режиме
эмуляции, когда разъемный элемент эмулятора вставляется в цоколь схемы
ПЗУ (расположенный на отлаживаемой плате), ОЗУ эмулятора выполняет
функции удаленного на момент отладки ПЗУ. В зависимости от сложности
используемого эмулятора, входящее в его состав дополнительное оборудова-
ние позволяет выполнять ряд сервисных функций. В состав отладочных
действий может входить, например, сохранение и передача в отладочный
компьютер трассы исполняемых команд (их последовательность). Эмулятор
может фиксировать значения данных, появляющихся на шинах адреса, и
данных отлаживаемой системы, а также формировать сигналы прерывания
для отлаживаемой системы при выполнении условий, задаваемых разработ-
чиком из инструментального ПК. Реакция на прерывания при этом опреде-
ляется содержимым обрабатывающих подпрограмм, временно подставляе-
мых эмулятором.
В современных условиях диапазон отладочных функций может быть суще-

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

мость блокировки штатной памяти программ и возможность подключения
эмулятора. Перспективным направлением, опирающимся на специфику со-
временных ПЛИС, является встраивание элементов эмулятора ПЗУ в БИС
ПЛ, реализующую функции набора интерфейсных схем микропроцессорной
системы. Для отладочных целей в качестве интерфейсной схемы может быть
выбрана БИС с логическими ресурсами, превышающими последующую се-
рийную реализацию.
Цоколь для
EPROM/OTP/EEPROM
Отлаживаемая система
Прерывание
Рис. 2.18. Метод эмуляции ПЗУ
Недостатки, свойственные предыдущим методам, заставили разработчиков

в ряде ситуаций ориентироваться на методы встроенного монитора. Идея
метода иллюстрируется рис. 2.19. Хотя внешне соединение отладочного ПК
и отлаживаемой системы похоже на соединение, характерное для метода
внутрисхемного программирования, принципы и процедура отладки другие.
Во -первых, Host -система соединяется не со схемой ПЗУ, а с портом процес-
сора, как правило, при этом используется стандартное соединение по по-
следовательному каналу (типа RS232). Во -вторых, основные отладочные
действия выполняются специальной программой -монитором, включенной
в состав программного обеспечения отлаживаемой системы. Ресурсы отладоч-
ного компьютера используются для отображения контролируемых парамет-
ров отлаживаемой программы, для корректировки (при необходимости) этих
параметров и для управления запуском/остановкой отлаживаемой программы.
RS232
Рис. 2.19. Метод встроенного монитора
Главным требованием к отлаживаемой системе (помимо, естественно, нали-

чия свободного последовательного порта) является возможность организа-
ции прерывания работы отлаживаемого программного обеспечения в зада-
ваемых разработчиком местах. Прерывание происходит в тот момент, когда
исполнение программы достигает одной из задаваемых из Host -системы то-
чек останова (break point). Удобнее всего для организации точек останова
использовать команды программных прерываний, вставляемые вместо ис-
полняемой команды. Это относительно легко реализуется при отладке про-
грамм, помещенных в оперативную память. Программное прерывание пере-
дает управление монитору. Набор выполняемых монитором действий опре-
деляется далее разработчиком и зависит от возникшей ситуации.
Метод удобен для тех систем, у которых не предусмотрены или отсутствуют
собственные средства ввода/вывода, которые могли бы служить для получе-
ния отладочной информации. Долгое время этот метод оставался практиче-
ски единственным дешевым и допустимым методом для отладки микрокон-
троллерных систем, у которых все исполнение основной программы проис-
ходит без обращения к каким -либо внешним ресурсам (соответственно, нет,
например, внешнего ПЗУ команд, и поэтому невозможно использовать эму-
ляторы ПЗУ и т. д.).
Современный подход к реализации встроенных мониторов базируется на
встраивании в систему отладочных агентов. Отладочные агенты представляют
собой управляемые программные вставки, которые в определенных услови-
ях могут перехватывать работу основной программы и передавать управле-
ние отладочным фрагментам. Основной проблемой является влияние отла-
дочных фрагментов на штатную работу системы. Наличие вставок позволяет
контролировать работу системы, однако может приводить к некоторой поте-
ре производительности. Удаление/вставление отладочных агентов может из-
менять временные соотношения для отлаживаемых ситуаций. Приемлемым
считается постоянное присутствие отладочных агентов при потере произво -
дительности, не превышающей диапазон значений от 1 до 5%. Наличие от-

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

привели к широкому распространению методов внутрисхемной эмуляции
(ICE, In Circuit Emulator). Реализация метода показана на рис. 2.20. Метод
опирается на тесное объединение ресурсов отлаживаемой и отлаживающей
систем. Объединение осуществляется за счет помещения в цоколь МП или
МК специальной эмуляторной головки, содержащей схему, эмулирующую
МП/МК отлаживаемой системы, и соединенной далее с собственно эмуля-
тором. Метод состоит в управлении со стороны отладочного МП направле-
нием подключения шин отлаживаемого МП. Внутрисхемная эмуляция мо-
жет выполняться с различной полнотой эмулируемых ресурсов. Содержимое
эмулятора позволяет оперативно модифицировать состав элементов ведущей
системы, берущих на себя работу (эмулирующих работу) отлаживаемой сис-
темы. В результате выполнение отлаживаемого программного фрагмента
может осуществляться, опираясь на любую задаваемую разработчиком ком-
бинацию ресурсов отлаживаемой и отлаживающей систем. В предельном
случае содержимое эмулятора заменяет даже процессор отлаживаемой сие -
темы, для этого эмулятор должен содержать симулятор системы команд МП

отлаживаемой системы. Наиболее сложно решается проблема использования
методов ICE для однокристальных микроконтроллеров, поскольку боль-
шинство деталей поведения МК остается внутри кристалла и недоступно
для наблюдения. Поэтому в некоторых случаях фирмы выпускали помимо
базового варианта МК специальную версию (для общецелевого использова-
ния слишком дорогую) эмуляционного кристалла. Основным отличием кри-
сталла (кроме стоимости) является наличие дополнительных контактов, на
которые выводятся сигналы внутренних шин (адреса, данных и управления).
Высокая стоимость традиционных приборов внутрисхемной эмуляции за-
ставляет проектировщиков искать более дешевые решения. Интересным и
перспективным представляется использование в качестве основы внутри-
схемного эмулятора ИСПС. Способность ПЛИС изменять структуру создает
возможность менять тип эмулируемого МП за минуты, легко добавлять но-
вые типы МП, конфигурировать саму систему эмулятора.
Наиболее перспективным методом отладки встроенных микропроцессорных
устройств (в общем случае не только их) являются методы встроенной внут-
рикристальной отладки. Эти методы наибольшее распространение получили
в современных 32 -разрядных МП. Структура кристалла, содержащего встро-
енные средства отладки аппаратно -программных ресурсов, приведена на
рис. 2.21. Но даже у 8 -разрядных процессоров известны варианты встраива-
ния отладочных средств в кристалл. Примером может служить продукция
фирмы Cygnal Integrated Products (www.cygnal.com), в которой комбинация
свойства внутрисистемной программируемоести(ISP), внутренней Flash -
памяти и встроенных в кристалл специальных отладочных средств сущест-
венно облегчает процедуру отладки. Другим примером того же подхода яв-
ляется продукция фирмы Atmel (www.atmel.com). Выпускаемые этой фирмой
AVR -процессоры имеют 8 -битовую архитектуру и поддерживают JTAG -
интерфейс. В состав кристалла включены отладочные средства, которые су-
щественно упрощают процесс отладки.
Более простыми вариантами являются методы соединения отладочных Host -
ПК с отлаживаемой системой через параллельные или последовательные
порты. В качестве приемника в целевой системе могут служить специальные
ИС или выделенные для этих целей контакты МП. В качестве стандарта
подключения используется либо стандарт JTAG, либо разработанный фир-
мой Motorola интерфейс со встроенным в МП отладочным модулем (в тер-
минологии фирмы режим отладки на его базе носит название BDM,
Background Debug Mode). Основными элементами внутрикристальной от-
ладки являются интерфейсный блок, блок формирования точек останова и
средства доступа к отладочной (процессорной) информации из интерфейс-
ного блока.
Данные по эффективности различных отладочных действий для рассмот-
ренных методов организации отладки сведены в табл. 2.4. Сравниваемыми
показателями являются возможность быстрого и оперативного изменения

объектного кода отлаживаемой программы, доступность и удобство наблю-
дения за состоянием основных программных и аппаратных объектов, эф-
фективность управления (легкость корректировок) вышеуказанных объек-
тов, возможность определения аналоговых эффектов на дискретных сигна-
лах и, наконец, цена отладочного средства.
Отлаживаемый кристалл
Рис. 2.21. Методы внутрикристальной отладки
Таблица 2.4. Данные по эффективности различных типов отладки
Измене- Наблюда- Управля- Аналоговые Цена

ние кода емость емость эффекты
EPROM -прото - Нет Низкая Отсутствует Низкая Низкая
типирование
Монитор Нет Средняя Средняя Низкая Низкая
в системе
Внутрисхемная Есть Очень Полная Высокая Высокая
эмуляция высокая
Внутрикристаль- Есть Высокая Полная Низкая Низкая
ная отладка
Для организации и проведения более тонких экспериментов незаменимыми

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

связанных с обработкой аналоговых сигналов
Проектирование фрагментов систем, связанных с обработкой аналоговых
сигналов, было и остается одной из важнейших и сложнейших проблем.
Окружающий нас мир является в значительной мере аналоговым (не-
прерывным), и не удивительно, что для 10% проектов необходима обработка
аналоговой информации. По некоторым оценкам к 2006 году количество
таких проектов достигнет 30%. Работы этого направления требуют решения
как проблем чисто аналоговых (масштабирование, фильтрация и т. д.), так и
проблем стыковки проектов с аналоговым и дискретным представлением
информации, т. е. проблем аналого -цифрового и цифроаналогового преоб-
разований.
Так же, как и для других направлений проектирования, базовыми этапами
являются этапы ввода информации, компиляции и моделирования. Проек-
тирование по этой ветви характеризуется следующими отличительными осо-
бенностями.
За последние годы существенно изменилась элементная база. Успехи мик-
роэлектронной промышленности привели к тому, что набор широкой но-
менклатуры ИС переместился в область более высокой точности и более
быстродействующих приборов. Современные АЦП и ЦАП при интеграль-
ной реализации достаточно уверенно дают 12—14 -разрядную точность при
времени преобразования в единицы и доли микросекунд. Точность и быст-
родействие многих аналоговых датчиков и исполнительных механизмов не
требует больших значений указанных параметров. Поскольку выбор эле-
ментной базы предопределяет не только эксплуатационные характеристики
проекта, но и в значительной мере его конструктивную реализацию, то су -
щественно возросли и требования к выполнению конструкторского этапа

проектирования.
Проектирование аналоговых фрагментов

В основе современных САПР (уже более 30 лет) для моделирования анало-
говых фрагментов остается пакет Spice в различных модификациях. Боль-
шинство фирм -разработчиков систем моделирования сохраняют совмести-
мость своих разработок со стандартами пакета Spice. Изменения касаются
адекватности и точности отражения в моделях свойств реальных элементов.
Объемы библиотек постоянно увеличиваются, а их содержимое модернизи-
руется. Возрастает качество работы алгоритмов моделирования (сходимость
результатов и их адекватность), уменьшается время моделирования. Как
следствие, уменьшаются ограничения на сложность моделируемых систем.
Конечно, улучшаются интерфейсные функции пакетов.
На окончательные характеристики аналоговых систем конструктивная реа-
лизация оказывает большое существенное влияние, чем при реализации
цифровых систем. Возможность получить неработоспособную плату (успеш-
но прошедшую испытания в прототипной реализации) приводит к необхо-
димости моделирования проектов с учетом эффектов, вносимых конкретной
реализацией. При моделировании учитываются паразитные сопротивления,
паразитные емкости монтажа. Более мощные САПР учитывают распреде-
ленный характер этих паразитных элементов.
Проблемой остается конструктивная реализация аналоговых фрагментов.
Имеется весьма существенная специфика проектирования и изготовления
печатных плат. При конструктивной реализации требуется сохранить точ-
ность и быстродействие и к минимуму свести влияние паразитных факторов
(электромагнитные наводки, паразитное падение напряжения, перекрестные
помехи и т. д.). Маршруты проектирования аналоговых фрагментов систем
на современных САПР при ориентации на дискретные компоненты или со-
временные схемы ПАИС показаны на рис. 2.22.
Для проектирования аналоговых фрагментов систем на базе дискретных
аналоговых компонентов могут использоваться САПР различных фирм.
Наибольший интерес среди этой продукции представляют САПР, позволя-
ющие совместить выполнение конструкторской разработки печатной платы
с моделированием проекта. Среди отечественных разработчиков наиболь-
шее распространение получили разработки фирмы MicroSim Corporation
(с 1998 г. входит в состав фирмы OrCAD Corporation). Привлекательность
последних версий ее САПР — DesignLab обусловлена двумя основными
факторами.
Во -первых, система позволяет моделировать аналоговые фрагменты, разво-
дить печатные платы и моделировать поведение фрагмента с учетом пара-
зитных параметров разводки. Более того, САПР позволяет выполнять моде -
лирование для цифровых (включая простейшие схемы ПЛИС) и смешанных

аналого -цифровых устройств. Дополнительно может использоваться про-
грамма Filter Designer, осуществляющая синтез пассивных и активных ана-
логовых фильтров и фильтров на переключаемых конденсаторах. Несом-
ненным достоинством САПР является наличие библиотеки, включающей
40 тыс. графических обозначений символов и около 10 тыс. математических
моделей компонентов.
Во -вторых, работа с DesignLab хорошо изложена в отечественной литера-
туре [22].
Традиционная Современная
процедура процедура
для стандартных ИС для ПАИС
Рис. 2 . 2 2 . Маршруты проектирования для аналоговых или аналого -цифровых

фрагментов систем
При реализации аналоговой части проекта в виде отдельной БИС ПАЙС

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

таких ИС фирмы -разработчики БИС ПАИС выпускают специальные САПР.
Для проектирования на базе ПАИС ispPAC фирма Lattice Semiconductor вы-
пустила САПР под названием РАС Designer. Функционирование аналоговых
программируемых блоков микросхемы CY8C25/26, выпускаемых фирмой
Cypress Semiconductor, задается при конфигурировании кристалла. Фирма
Cypress Semiconductor обеспечивает поддержку проектирования своей про-
дукции на базе различных версий САПР Warp. Наиболее мощная версия
пакета Warp Enterprise (2995 долларов) поддерживает все стадии проектного
потока, включая сервисные функции типа конвертеров графического ввода
в HDL -описания, моделирование поведения на уровне исходного описания,
интерактивной отладки и автоматической генерации создания тестовых по-
следовательностей (Test -Bench).
Еще более интересным представляется подход фирмы ZETEX к проектиро-
ванию и конвертации аналоговых средств обработки. Выпускаемое фирмой
ZETEX семейство ПАИС TRAC (Totally Re -configurable Analog Circuit) отно-
сится к семейству кристаллов с настраиваемой структурой отдельных ана-
логовых ячеек. Загрузка ОЗУ конфигурации ПАИС TRAC выполняется за
счет подключения схем TRAC к стандартным ПЗУ через специальную схему
TRAC -S2. Образование требуемой аналоговой схемы производится путем
внешней коммутации, обычно выполняемой на печатной плате. Подобная
организация соединения ячеек между собой снимает проблему разработки
фирмой специального САПР, решающего вопросы размещения ячеек и
трассировки межсоединений. Чтобы уменьшить влияние межсоединений
ячеек кристалла TRAC на окончательные характеристики системы, фирма
ZETEX организовала выпуск аналоговых схем ZXF36Lxx, относящихся к
классу Computational Application Specific Integrated Circuit (CASIC). Схема
ZXF36Lxx состоит из аналоговых ячеек, аналогичных по структуре ячейкам
кристаллов семейства ZXF36Lxx. Функции, выполняемые ячейками, и кон-
фигурация межсоединений кристалла определяются топологией двух слоев
металлизации. Маршрут проектирования, используемый фирмой ZETEX
при конвертации проектов из представления в форме ПАИС в форму полу-
заказной схемы, приведен на рис. 2.23.
Маршрут проектирования опирается на комбинирование TRAC -технологии

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

Рис. 2 . 2 3 . Проектный поток конвертации проектов фирмы ZETEX
Проектирование фрагментов
со смешанным представлением сигналов
Наибольшие изменения в последнее время (по мнению многих исследовате-
лей — за последние два года) произошли среди средств проектирования
систем со смешанным представлением сигналов, причем, основные измене-
ния — в сфере моделирования и в области создания и применения средств
тестирования. Большое количество ссылок можно найти в обзорной статье [47].
Изменения в методике проектирования прежде всего касаются тщательной
верификации проекта на схемотехническом уровне. Одновременное модели-
рование цифровых и аналоговых сигналов уже значительно сложнее, чем
чисто цифровое или чисто аналоговое моделирование. К проблемам моде-
лирования добавляется проблема использования языков описания систем
такой смешанной природы (хотя здесь имеются значительные успехи — это
рассмотрим чуть ниже). В части эффективности средства проектирования
и моделирования систем со смешанными сигналами значительно уступают
аналогичным средствам для цифровых систем. Но современное состояние
характеризуется значительной динамикой, и можно ожидать существенного
прогресса как в области создания новых типов SOPC, так и в области разра-
ботки средств проектирования.
Информация о продукции фирм, связанных с поддержкой различных этапов
проектирования аналоговых и аналогово -цифровых систем, может быть
найдена в обзорных статьях интернет -журналов. Анализ этих статей демон-
стрирует неослабевающий интерес различных фирм к данному направле-
нию. Сложность решения проблем для систем со смешанным представлени-
ем сигналов находит свое отражение, прежде всего, в уровне цен на постав-
ляемые САПР. Стоимость САПР значительно превышает стоимость САПР
аналогичной целевой направленности для цифровых систем. Приведенные
данные показывают, что усилия разработчиков направлены на автоматиза-
цию различных этапов проектирования.
Поддержка проектировщиков начинается с момента анализа путей реализа-
ции проекта. Уже на этом этапе фирмы предлагают свои готовые решения,
поставляемые в форме моделей стандартных решений или генераторов мо-
делей.
Основные усилия последнего времени направлены на повышение эффек-
тивности совместного моделирования цифровых и аналоговых схем. Мето-
ды событийного моделирования (подробно рассмотренные в разд. "Модели-
рование и реальное время" гл. 3), весьма эффективные для моделирования
цифровых схем, оказываются неприемлемыми для аналоговых и аналого -
цифровых, ибо в последних изменениях сигналов (события) происходят не-
прерывно. Системы моделирования устройств со смешанным представлени-
ем информации часто строят, используя объединение событийного подхода
для представления цифровой подсхемы и численного интегрирования диф -
ференциальных уравнений, являющегося основой пакета Spice. Необходи-

мость такого подхода становится особенно важной для проектов, в которых
в одном кристалле объединяются сотни тысяч вентилей программируемой
логики и аналоговые цепи. Типовыми проблемами для таких проектов яв-
ляются, например, задачи проектирования для АЦП высокого разрешения
или ускоренного моделирования работы фазово -управляемых схем (в анг-
лийской терминологии Phase -Locked Loop, PLL).
Даже беглый анализ данных, приведенных в обзорных статьях интернет -
журнала EDN (www.ednmag.com), показывает, что одной из ведущих фирм
в области создания средств проектирования систем со смешанным пред-
ставлением сигналов является фирма Antrim Design System — разработчик
САПР Antrim -A/MS. Этот пакет (рис. 2.24) помимо традиционных для систем
Менеджер времени
Программы -обработчики описаний
Рис. 2.24. Состав САПР Antrim -A/Ms фирмы Antrim Design System
моделирования блоков содержит богатый набор программ -обработчиков для

различных способов описания аналоговых, цифровых и смешанных блоков.
В состав этого набора входят: релаксационные событийно управляемые
средства моделирования для КМОП цифровых цепей, описанных на вен-
тильном уровне; средства интерпретации Verilog -описаний для цифровых
блоков; программы -обработчики описаний межсоединений и шин питания;
средства моделирования сильносвязанных аналоговых цепей, реализующие
решение систем дифференциальных уравнений по методу Ньютона—Ральф -
сона, и средства моделирования аналоговых блоков, описываемых поведен-
ческими моделями на языке Verilog -A.
Смешанные способы описания и многоуровневое моделирование поддержи-
ваются не только САПР Antrim -A/MS, но и разработками других фирм.
Выгоды многоуровневого подхода состоят в возможности моделировать одну
часть схемы на уровне физических моделей (например, операционные уси-
лители), а другую на событийном (например, схемы логического управ-
ления).
Очень полезным свойством систем рассматриваемого класса, хотя прису-
щим, к сожалению, не всем, является совместимость процедур моделирова-
ния и автоматического размещения и разводки. В отличие от нисходящего
проектирования цифровых систем при их реализации в форме микросхемы,
когда процесс проектирования от архитектурного определения до физиче-
ского расположения на кристалле легко поддается автоматизации и опира-
ется на ранее разработанные САПР, что существенно ускоряет процесс про-
ектирования, аналоговое проектирование не является столь простым и лег-
ким. Иллюстрацией этого положения является приведенный на рис. 2.25
типичный маршрут проектирования аналогового блока, встраиваемого в
кристалл. Из рисунка видно, что проектирование без ручной доводки про-
екта обходится в редких случаях.
Наибольший интерес представляют попытки разработки средств, автомати-
зирующих наиболее ответственный этап проектирования — этап синтеза
устройств, исходя из описания их функционирования. Различие алгоритмов,
необходимых для синтеза аналого -цифрового преобразователя или операци-
онного усилителя, делает задачу разработки САПР, поддерживающих синтез
систем со смешанным представлением информации, весьма проблематич-
ной. Вместе с тем, уже упоминавшаяся выше фирма Antrim анонсировала
выпуск САПР, поддерживающей синтез аналоговых приборов.
Не меньше проблем возникает и при попытках автоматизировать этапы
проектирования, отвечающие за создание пригодной к тестированию ко-
нечной продукции, а также за тесты и аппаратуру для такого тестирования,
однако на этом направлении полученных положительных результатов не-
сколько больше. Интерес представляют разработки фирм ОрМахх и LogicVision
в части разработки САПР, генерирующих тесты для проверки аналоговых и
гибридных систем. Фирма SZ Testsysteme традиционно поддерживает вы-

пуск аппаратуры, предназначенной для тестирования аналоговых и смешан-
ных систем различного класса.
Рис. 2.25. Маршрут проектирования аналогового блока
Существенное значение для развития средств автоматизации различных эта-

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

которые оказываются совместимыми с поведенческими моделями цифровых
блоков, описываемых стандартными средствами Verilog и VHDL. Прежде
чем стать стандартами, новые варианты языков должны были преодолеть
ограничения, обусловленные правами собственности ряда фирм, в том чис-
ле решениями, уже введенными в такие пакеты, как MAST фирмы Analogy,
SpectreHDL фирмы Cadence, HDL -A фирмы Mentor Graphics, Diablo фирмы
VeriBest. Подобно их цифровым прототипам аналоговые и смешанные пове-
денческие модели обеспечивают большую скорость моделирования, чем мо-
дели приборного или вентильного уровня. Дополнительной выгодой пове-
денческих моделей является свойственная им относительная секретность,
поскольку они не показывают, как будет реализован описываемый ими
блок.
После долгих дебатов в 1999 году был принят стандарт IEEE Standard
1076.1 -1999 языка VHDL -AMS, являющийся расширением известного стан-
дарта IEEE 1076 языка VHDL. Язык позволяет описывать сложные проек-
ты, используя комбинацию дифференциальных выражений, алгебраических
ограничений и логических условий. Смешение аналоговых и событийно
управляемых элементов в одном языке оказывается более эффективным,
чем использование макромоделей в Spice. Поскольку VHDL -AMS позволяет
описывать поведение и неэлекгрических элементов, то он может использо-
ваться для систем, смешивающих электрические и неэлектрические компо-
ненты, например, электромеханические и жидкостные электрические сис-
темы. Многие компании -разработчики САПР, в том числе ведущие фирмы
Analogy и Mentor, объявили о своей поддержке нового стандарта VHDL -
AMS и после его утверждения готовы выпустить новые САПР, основанные
на этом стандарте.
Аналогичная ситуация складывается и с языком Verilog. Его расширенный
вариант стандарта — Verilog -AMS standard 1.3, выпущенный Open Verilog
International organization (www.ovi.org), также был принят в 1999 году. По-
добно VHDL -AMS язык Verilog -AMS поддерживает включение в описание
системы неэлектрических компонентов (механических, оптических и т. д.).
Большинство фирм разработчиков САПР для смешанных систем, включая
Analogy, Antrim, Apteq, Cadence, Mentor, Transcendent, и Innoveda, объявили
о включении в будущую выпускаемую продукцию средств поддержки язы-
ков Verilog -AMS, VHDL -AMS или обоих.
Проектирование
аналоговых и аналого -цифровых SOPC
Существующая в настоящее время в микроэлектронике тенденция интегра-
ции в одном кристалле всех элементов современных систем, находящая свое
воплощение в форме выпуска "систем на кристалле" (SOPC), окажется не
полной, если не будет включать в свой состав аналоговых и/или аналого -

цифровых блоков. Включение ПАИС в SOPC дополнительно дает следую-
щие выгоды, характерные для всех ИСПС — возможность модернизаций и
корректировок в весьма значительных пределах, определенная секретность
разработок и их защита от несанкционированного копирования. Дополни-
тельная особенность ПАИС состоит в том, что модернизации и корректи-
ровки фрагмента допустимы не только в форме изменения взаимного со-
единения элементов (т. е. структуры фрагмента), но и форме изменения но-
миналов используемых элементов. Таким образом может достигаться весьма
существенное изменение как характеристик, так и поведения фрагмента.
Соединение в одной системе цифровых, аналоговых и цифроаналоговых
фрагментов имеет свою историю развития. Первые успешные попытки объ-
единения в одном кристалле цифровых и цифроаналоговых фрагментов
осуществлялись фирмой Intel еще в середине 80 -х годов, дальнейшее разви-
тие это направление получило у фирмы Analog Device. Сложности реализа-
ции требуемой совмещенной технологии не обеспечивают желаемых темпов
развития этого направления развития микроэлектроники. Очень немногие
фирмы сейчас могут поддерживать (на условиях экономической рентабель-
ности) выпуск устройств со смешанной технологией.
Наибольших успехов к настоящему моменту достигла фирма Cypress
MicroSystems, Inc. (филиал Cypress Semiconductor). Производимые фирмой
схемы семейства CY8C25***/26*** представляют собой БИС, в основе кото-
рых микропроцессорная часть (8 -разрядный процессор М8С) и программи-
руемая пользователем часть (набор реконфигурируемых аналоговых и циф-
ровых блоков).
Фирма выпустила САПР — PSoC Designer IDE, являющуюся, по сути, ин-
тегрированным пакетом средств разработки встраиваемых SOPC -систем.
Пакет обеспечивает доступ ко всем традиционным средствам отладки мик-
ропроцессорных систем, включая полный отладчик, поддерживающий внут-
рисхемную эмуляцию ICE. На предварительном этапе проектирования и для
моделирования проектов, содержащих смешанное аналого -цифровое пред-
ставление сигналов, фирма Cypress предлагает пользоваться ПО фирмы
Antirim Design System (Antirim -ACV, Antirim -MSS). Между этими фирмами
достигнуты соответствующие лицензионные соглашения, позволяющие на-
деяться на объединение усилий обеих фирм в направлении интеграции про-
ектных средств в форме единого пакета.
Системы автоматизированного проектирования аналоговых и аналого -
цифровых ИСПС еще находятся на начальном этапе своего становления.
Следует ожидать возрастания объема и качества работ, выполняемых этими
САПР.
2.3. Структура и организация САПР

2.3.1. Связь процедуры проектирования и САПР БИС
Как уже отмечалось, разработка современных вычислительных систем, со-
держащих как микропроцессорные решения, так и БИС с программируемой
структурой, немыслима без широкого привлечения САПР. Все методики
проектирования таких вычислительных систем ориентированы на использо-
вание САПР. Правильный выбор САПР предопределяет успешность всей
процедуры проектирования и является важнейшим условием эффективного
проектирования. При хорошем выборе может быть достигнуто существенное
ускорение выпуска продукции, т. е. сокращение времени от спецификации
проекта до выпуска первых продажных образцов (Time -to -Market), во мно-
гих случаях удается сократить и время, необходимое для выпуска серийной
продукции.
Методы и средства проектирования тесно связаны с выбором САПР и, на-
оборот, выбор САПР определяет допустимые и целесообразные методы и
средства проектирования, так что эти вопросы нельзя рассматривать в отры-
ве друг от друга. Взаимосвязь между САПР и выбранным типом БИС ПЛ
значительно более тесная, чем между средствами проектирования МП -
систем и используемым типом МП. Выбор элементной базы для проекта в
значительной мере предопределяет требуемую или требуемые для реализа-
ции проекта САПР.
В общем случае, при выборе САПР приходится учитывать целый ряд сооб-
ражений, а именно:
- распространенность САПР;
- цену САПР, ее сопровождения и модификаций;
- поддержку выбранной элементной базы;
- широту охвата разнообразных этапов проектирования и эффективность
их выполнения;
- наличие широкой библиотечной поддержки стандартных решений;
- возможность и простоту стыковки с другими САПР;
- удобство работы с САПР и ее дружественность;
- легкость изучения;
- возможности корпоративной работы.
-чевидно, трудно найти САПР, которая удовлетворяла бы сразу всем пере-
численным условиям, как ввиду их взаимной противоречивости, так и ис-
ходной неопределенности варианта реализации конечного продукта.
2.3.2. Связь проектной проблемы

с выбором САПР
Как было показано в предыдущих разделах (рис. 2.7 и 2.12), один и тот же
проект может быть реализован с ориентацией на различную элементную
базу. Из рисунков видно, например, что реализация одного и того же проек-
та возможна как в виде раздельных проектов МП и ПЛИС, так и в форме
проекта, реализуемого в БИС класса SOPC. Аналогичная ситуация склады-
вается с выбором САПР. На первоначальных шагах проектирования можно
пользоваться любым вариантом. Программное обеспечение, например, раз-
рабатывать на ранее приобретенных версиях компиляторов, а аппаратуру
проектировать при помощи оценочной версии САПР. Однако на заключи-
тельных этапах проектирования, как правило, все равно придется вернуться
к версии САПР той фирмы, на элементной базе которой решено реализо-
вать проект. Поэтому на первом же шаге целесообразно определиться —
пользоваться ли САПР фирмы -производителя выбранного класса програм-
мируемой БИС ПЛ или SOPC (Xilinx, Altera, Atmel, Actel и др.) или вос-
пользоваться услугами системы проектирования, созданной одной из веду-
щих фирм -производителей САПР, таких как Synopsys, Cadence, Mentor
Graphics, Exemplar Logic, Viewlogic, Symplicity и др.
Чтобы отличать САПР фирм -производителей БИС ПЛ (Vendors) от САПР
фирм, поддерживающих проектирование ПЛИС различных производителей,
для последних обычно используется термин сторонние САПР (САПР незави-
симых фирм). В английской терминологии для обозначения таких фирм
принято использовать термин Third Party EDA Tools. Возможность совмест-
ного использования САПР различных фирм базируется на том, что эти
САПР состоят из отдельных частей, и работа на них носит явно выражен-
ный этапный характер (ввод, компиляция, моделирование, программирова-
ние). Тот факт, что проектные средства состоят из отдельных частей позво-
ляет одной САПР вклиниваться в проектный поток другой. Производители
схем ПЛИС, а тем более БИС SOPC, чаще всего монополизируют возмож-
ность и право монтирования проекта в конкретный тип БИС и поэтому при
применении САПР сторонних фирм, как минимум, на заключительных эта-
пах приходится пользоваться услугами САПР производителей схем ПЛИС.
Ноу -хау (know -how) этих фирм обычно является взаимное соответствие ме-
жду структурой соединений внутри кристалла и загрузочным файлом кон-
фигурации.
Предельным проявлением такой стратегии является, например, САПР фир-
мы Agere Systems — ORCA Foundry 2000. САПР ориентируется на использо-
вание стандартных проектных средств сторонних фирм для решения задач
большинства этапов проектирования. Разработчик использует САПР таких
фирм для ввода, синтеза и моделирования проектов. Наличие в составе
ORCA Foundry определенных интерфейсных средств позволяет загрузить в
него созданную проектную информацию. После этого основной задачей

собственно САПР является разработка топологии межсоединений элементов
структуры FPGA из списка цепей (netlist), ориентированного на конфигури-
рование FPGA. САПР размещает блоки на кристалле, осуществляет их на-
стройку и решает задачу их взаимного соединения, используя встроенные
средства (timing -driven tools). Встроенный в пакет анализатор временных
задержек элементов используемой БИС (static timing analysis tool) обеспечи-
вает определение скорости работы БИС по отдельным соединениям и воз-
вращает аннотированный список цепей БИС, который позволяет организо-
вать моделирование и временной анализ. Выходные файлы ORCA Foundry
являются совместимыми со многими средствами моделирования сторонних
фирм. Это позволяет исследовать и анализировать окончательные времен-
ные характеристики проекта. Генератор программной информации (bit
stream generator) создает выходной файл, интерпретирующий структуру БИС
в битовый информационный поток, который может использоваться для
программирования либо БИС ПЛ, либо специальных конфигурационных
БИС.
Если проектировщик решился на совместную работу с несколькими САПР
(что авторам представляется в современных условиях более предпочтитель-
ным), то их выбор все равно остается достаточно многовариантной пробле-
мой. Ни одна из САПР не является предпочтительной для любых пользова-
тельских приложений.
Стратегия взаимодействия фирм, производящих БИС ПЛ, и фирм, специа-
лизирующихся на разработке САПР, модифицировалась во времени. До на-
чала 90 -х годов фирмы ориентировались на узконаправленную деятельность.
Каждая фирма имела свою узкую специфическую область, в которой и кон-
центрировались все ее усилия, чтобы обеспечить свое лидирующее положе-
ние в выбранной нише. В 90 -х годах началось более тесное взаимодействие
фирм между собой. Практически все САПР стали предусматривать возмож-
ности взаимного обмена (Import/Export Design) проектной информацией на
любом этапе проектирования. Технической основой этого информацион-
ного обмена явилось введение и поддержка практически всеми фирмами
стандартных языков обмена. Промышленным стандартом стал язык EDIF
с версиями 2.0.0 и 3.0.0. В большинстве САПР, однако, предусмотрено
взаимодействие на основе различных языков описания аппаратуры (в том
числе VHDL, Verilog и т. д.), а не на основе какого -то одного языка.
С середины 90 -х годов начался этап совместных разработок в области
САПР. В настоящее время эта тенденция сохраняется и заключается в коо-
перации усилий различных фирм при разработке САПР, при этом каждая
фирма реализует тот этап проектирования и, соответственно, фрагмент
САПР, в котором она является общепризнанным лидером. Техническая реа-
лизация такого объединения осуществляется как в форме единой САПР, так
и в форме взаимосвязанных САПР. Важно, что при этом создается единый
Глава 2, Основы технологии проектирования ИСПС 209
информационный поток проектирования, и все этапы проектирования оказы-

ваются тесно взаимосвязанными.
Способ объединения естественно влияет на окончательные характеристики
САПР. Создание единой САПР задача более сложная, чем просто объедине-
ние нескольких САПР под одной управляющей оболочкой, но зато (помимо
единообразия правил общения) облегчается информационный обмен между
ними и, с точки зрения пользователя, значительно увеличивается объем сер-
висных услуг. Форма единой САПР создает более тесное общение различ-
ных САПР между собой. При этом, например, результаты моделирования
работы какого -либо фрагмента схемы могут отображаться не только в диало-
говом окне временного моделирования, но и в окне изображения электри-
ческой схемы, которая создавалась на этапе ввода информации о проекте.
Задача создания программ -оболочек, интегрирующих совместную работу
САПР различных фирм, в последнее время несколько упростилась, по-
скольку разработчики САПР теперь обычно включают в них интерфейсные
возможности, предоставляемые идеологией языка Tel. В результате можно
организовать совокупность взаимодействующих САПР, каждая из которых
будет выступать как источник команд, так и как исполнитель (приемник)
этих команд. Для этого САПР компонуется как пакет встроенных библио-
тек. Библиотека содержит синтаксический анализатор языка Tel и подпро-
граммы, интерпретирующие как действия команды языка с параметрами,
предусмотренными в САПР. Команды языка Tel могут считываться из ис-
точников различной природы, таких как командная строка, параметры вы-
зова из другой программы (САПР), меню выбора и т. д. Соответственно,
в САПР -приемнике определено выполнение команд.
Примером кооперационной САПР является САПР Foundation для продукции
фирмы Xilinx, которая представляет собой результат совместной разработки
фирм Xilinx, Aldec и Synopsys.
Другим способом кооперации является включение в состав САПР не пол-
ной, а усеченной и специализированной версии пакета. Примером может
служить технология, используемая фирмой Model Technology. Модификации
моделирующей программы этой фирмы под названием ModelSim использу-
ются как составная часть САПР других фирм. Несмотря на усеченность и
специализацию, версии программы предоставляют широкий набор средств
для функционального и временного моделирования проектов, написанных
на языках VHDL и Verilog.
Еще одной формой кооперации является включение фирмой -произво-
дителем ПЛИС в комплект поставляемого программного обеспечения оце-
ночных версий пакетов сторонних фирм. Например, поставляемая фирмой
Atmel САПР Integrated Development System (IDS) Ver. 7.2, включает оценоч-
ные версии LeonardoSpectrum (Exemplar Logic) и ModelSim (Model Techno-
logy).
Фирма Altera также позволяет (а последнее время даже рекомендует) для

большей эффективности процедуры компиляции использовать на предвари-
тельных этапах САПР сторонних фирм. Проектировщик может выбрать для
повышения эффективности компиляции проектов, написанных на языках
VHDL или Verilog HDL, либо компилятор FPGA Express фирмы Synopsys,
либо компилятор LeonardoSpectrum фирмы Mentor Graphics, а для эффек-
тивного моделирования ориентироваться на пакет ModelSim фирмы Model
Technology (подразделение фирмы Mentor Graphics).
Подобная кооперация усилий различных фирм является вполне обоснован-
ной и ожидаемой, а тенденция обращения к специализированным САПР
(на определенных этапах проектирования и в определенных ситуациях)
будет, по -видимому, сохраняться и в дальнейшем.
Еще более критичным оказывается вариант выбора САПР при желании
обеспечить сквозное проектирование, когда в рамках одной САПР должны
совмещаться средства различных ветвей или уровней проектирования
(например, проектирования конфигурации ПЛИС и проектирования печат-
ной платы, на которой БИС ПЛ будет находиться, или проектирование
конфигурации ПЛИС и моделирование ее работы совместно с цифро -ана-
логовыми элементами).
Типичным представителем САПР для смешанного или иерархического проек-
тирования являются САПР фирм Innoveda (бывшая Viewlogic) или OrCAD.
Рассмотрим в качестве типового примера состав, назначение и особенности
реализации средств, входящих в САПР Workview Office фирмы Viewlogic.
WorkView Office является законченной системой программного обеспечения
(для PC -платформ, работающих под Windows 95, 98 или NT), ориентиро-
ванной на автоматизацию различных уровней проектирования электронных
схем. WorkView Office имеет программу -оболочку навигатор проектов (в дру-
гих САПР программа может называться менеджером проектов), дающую
возможность эффективной организации потока проектирования. Навигатор
позволяет управлять как последовательностью выполнения частей пользова-
тельского проекта, так и выбором используемых программ и стандартных
библиотек. С информационной точки зрения САПР представляет собой
классическую трехступенчатую систему (ввод, обработка и верификация),
предназначенную для различных видов обрабатываемой информации на
каждой стадии проектирования. Так, вводимая информация может описы-
вать схему электронного блока, а с помощью навигатора проекта далее вы-
бирается желаемый вид обработки: моделирование поведения этой схемы
(цифровой, аналоговой или смешанной), компиляция в выбранный тип
ПЛИС или разводка печатной платы. В зависимости от выбора на следую-
щем этапе обработки информации проектировщик пользуется соответст-
вующей компиляционной процедурой разводки печатной платы, компиля-
ции в выбранный тип БИС ПЛ или подготовки к моделированию.
И, наконец, на третьем этапе осуществляется верификация готового проек-

та. Анализ поведения разработанной схемы на временной диаграмме, про-
смотр и анализ результатов топологической разработки печатной платы или
анализ файла отчета о результатах размещения схемы в выбранный кристалл
ПЛИС.
Хотя интегрированные САПР безусловно удобны в работе, значительная
стоимость их приобретения заставляет многих проектировщиков оставаться
на позициях использования САПР, решающих локальную проблему сего-
дняшнего дня. При необходимости моделирования работы аналоговых или
смешанных (аналого -цифровых) систем обычно используются современные
версии профессиональной программы PSpice A/D, входящей в состав пакета
DesignLab. Достоинством ее является наличие отечественной литературы,
описывающей основные приемы работы в ней [22]. Распространение имеют
и другие программы (например, Micro -Cap фирмы Spectrum Software [20],
APLAC 7.0, Electronics Workbench 5.0 и т. д.). Программный комплекс кор-
порации MicroSim под названием DesignLab 8.0 используется для сквозного
проектирования аналоговых, цифровых и смешанных аналого -цифровых
устройств, синтеза устройств программируемой логики и аналоговых фильт-
ров. Введение в комплекс интерфейса с другими САПР ПЛ позволил соз-
дать систему, дающую возможность разрабатывать схемы, включающие
CPLD и FPGA различных фирм, моделировать на ПК их поведение совме-
стно с другими аналоговыми и цифровыми компонентами, разрабатывать
печатные платы и на заключительном этапе повторять моделирование с уче-
том паразитных эффектов, соответствующих свойствам реальных образцов
выходной продукции.
Таким образом, если предполагается совместное проектирование цифровых
и аналоговых (в том числе цифроаналоговых и аналого -цифровых) фрагмен-
тов или комплексный (сквозной) подход к проектированию, то проекти-
ровщик стоит перед выбором САПР фирм MicroSim, Viewlogic или OrCAD [21].
На выбор САПР может оказывать желание разработчика иметь возможность
использования результатов проектирования для реализации конечной про-
дукции в других (кроме заданной базовой) технологических формах. Различ-
ные варианты технологической реализации, как правило, будут требовать и
различных проектных процедур, и различных САПР. Так, если после этапа
выпуска опытных образцов на базе БИС ПЛ предполагается дальнейшая
реализация проекта в виде заказной БИС, то переход от ПЛ к такой форме
будет более простым, если при разработке и той и другой формы проекти-
ровщик будет ориентироваться на САПР одной и той же фирмы. Такие воз-
можности (с гарантией работоспособности проекта при другой технологии
изготовления) предоставляют фирмы Synopsys, Cadence или Mentor Graphics
(выбор конкретной фирмы может определяться как типом заказной БИС,
так и просто симпатиями проектировщика).
Большое количество фирм специализируется на выпуске полузаказных БИС.
Основные варианты различаются. Возможна ситуация, когда исходный про -
ект имел прототип в форме БИС ПЛ и, соответственно, проект был описан

средствами САПР выбранного типа ПЛИС, а для реализации проекта в
форме полузаказной БИС потребуется использование САПР фирмы -произ-
водителя БМК. Если же проект сразу ориентировался на реализацию в фор-
ме БМК, то дополнительных преобразований может не потребоваться.
Важнейшей характеристикой САПР БИС ПЛ является эффективность ком-
пиляции. Хотя рекомендуется всегда стараться при проектировании за-
нимать под проект не более 90% ресурсов используемой БИС ПЛ (т. е. ос-
тавлять минимальные резервы для возможных модификаций), стоимость
БИС следующего варианта логической мощности (а иногда и отсутствие
БИС с требуемым быстродействием) заставляет разработчика пытаться "уло-
житься" в ресурсы БИС минимально допустимой логической мощности.
Одним из возможных вариантов, способствующих достижению этой цели,
может оказаться использование САПР фирм Exemplar Logic и Symplicity,
обеспечивающих для проектов, написанных на языках VHDL или Verilog
HDL, как правило, самые высокие показатели по эффективности компиля-
ции (минимальность затрачиваемых логических ресурсов и быстродействие
проекта).
Существенное влияние выбор САПР оказывает и на эффективность вери-
фикации проектов. Этап отладки готового проекта традиционно (как было
показано для типовых МП -систем) поддерживался средствами САПР, не
является исключением и отладка проекта, загруженного в БИС ПЛ. Совре-
менная тенденция заключается во введении в перечень возможностей САПР
функций, способствующих упрощению процедуры отладки готового проек-
та. Например, в САПР Quartus фирмы Altera предусматривается наличие
всех трех составляющих такой процедуры: отладочных средств, помещаемых
в отлаживаемую БИС/СБИС; информационно -транспортировочных средств,
связывающих отлаживаемую БИС и ПК с САПР; программных средств в
составе САПР, управляющих и отображающих результаты отладки. Средства
так называемого SignalTap Logic Analysis позволяют регистрировать состоя-
ния не только на контактах ПЛ, но и во внутренних точках ПЛ в реальном
масштабе времени, занося эту информацию в память ПЛ, передавать сохра-
ненную информацию в компьютер с помощью интерфейса JTAG и отобра-
жать ее в редакторе временных диаграмм (Waveform Editor) для просмотра,
анализа и отладки схемы в БИС.
Еще более сложные средства отладки требуются для БИС, совмещающих
в одном кристалле устройства различной природы. Например, реализованных
по схеме МП+FPGA, как в приборах семейства Е5 типа SOPC ("системы на
кристалле") фирмы Triscend. Здесь необходимо отметить возможность обес-
печения одинаково эффективной отладки не только МП -ядра (на базе
MCS -52) и аппаратного ядра системной логики (типа FPGA), но и их связи
между собой за счет введения в архитектуру специального устройства отлад-
ки (Hardware Breakpoint Unit). Организация такой смешанной отладки опи -
рается на возможности, предоставляемые как архитектурой кристалла, так и

собственно САПР Triscend FastChip.
Не менее сложные средства отладки потребуются для отладки смешанных
БИС, например, в анонсируемых фирмой Atmel приборах, реализующих
в одном кристалле интерфейс PCI и логику FPGA.
Внешне значительно проще выглядит отладка систем типа SOPC, относя-
щихся к классу generic, (например, схем фирмы Altera), в которых объеди-
няются МП -ядра того или иного типа (начиная от 8 -разрядных MCS 8052 и
кончая 32 -разрядными RISC -архитектурами) и другие части проекта, реали-
зованные в рамках единой технологии программируемой логики. Однако,
поскольку реально верификация совместной работы МП, программы и эле-
ментов периферийных устройств осуществляется в рамках типового редак-
тора временных диаграмм САПР MAX+PLUS II, формирование даже отно-
сительно короткой последовательности команд МП может быть серьезно
затруднено сложностью подготовки исходной информации.
Следующим фактором является наличие или возможность использования
стандартных решений. Этот момент также может оказаться решающим при
выборе САПР. Ситуация несколько улучшается и сглаживается с помощью
создания переносимых проектных решений (например, записи функциони-
рования на одном из вариантов языков описания аппаратуры VHDL, Verilog
или EDIF). Однако особенности внутренней организации БИС ПЛ могут
приводить в таком случае к получению после компиляции не самых эффек-
тивных решений (если, конечно, в спецификации проекта эти особенности
не учтены).
2.4. Основные этапы проектирования БИС

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

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

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

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

допустимую организацию и структуру внутренних узлов проекта.
Использование САПР на этом этапе проектирования пока еще явление дос-
таточно редкое, хотя для реализации современных очень сложных проектов
(несколько сотен тысяч вентилей) все чаще используются специальные
блочные редакторы, позволяющие осуществлять декомпозицию проекта без
детализации составных частей. Примером может служить САПР Quartos
фирмы Altera, включающая в свой состав специальное средство, редакти-
рующее проект на уровне блоков (block -level editing).
2.4.3. Этап 3. Разработка общей структуры

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

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

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

ление, а только предваряет его.
Графическую форму задания информации о проекте широко использует,
например, фирма Mentor Graphics Corporation в пакете Renoir (в последней
редакции эта программа носит название HDL Designer). В зависимости от
целевого назначения (и, соответственно, используемых синтаксических кон-
струкций) разработчик должен выбрать тот или иной редактор. Пакет под-
держивает ввод графической информации: для структурного описания уст-
ройства (Block diagram), для описания комбинационных схем на основе таб-
лиц истинности (Truth table), для потокового описания поведения (Flow
chart), для описания в терминах и понятиях автоматов с памятью (в фир-
менной документации используется термин "диаграммы состояний", State
diagram). Результатом работы редакторов является создание описания проек-
та или его фрагментов на одном из языков описания аппаратуры. Даже если
САПР не поддерживает графического ввода, она часто может отображать
текстовое описание в графическую форму. Примером может служить са-
мостоятельное обнаружение САПР Synplify (9—24 тыс. долларов) фирмы
Synplicity фрагментов, соответствующих по построению описанию автоматов
с памятью, с возможностью их дальнейшего графического представления.
К недостаткам графического представления можно отнести отсутствие четких
стандартов соответствия текстового и графического представления. В отличие
от текстовых, графические способы представления проекта обычно узко
специализированы и требуют особых средств для переноса информации
о проекте в другую среду, для чего могут быть применены специальные уни-
версальные языки передачи информации о проекте (типа языка EDIF,
Electronic Design Interchange Format).
Современные языки описания аппаратуры (HDL, Hardware Description Lan-
guages) допускают описание проектируемого устройства как с точки зрения
его поведения, так и с точки зрения его структуры. Эти возможности делают
распространенным представление проекта в форме текстового описания
алгоритмов функционирования его фрагментов в сочетании с текстовым же
описанием межблочных соединений для сложных проектов. Достоинства
текстового способа описания проекта заключаются в его компактности и
относительной простоте автоматизации любых преобразований, включая
начальную генерацию описания проекта. Очень важна возможность исполь-
зования стандартных универсальных языков типа HDL, обеспечивающая
простоту переноса проекта с одной аппаратной платформы на другую и пе-
реход от одной САПР к другой.
Иерархия языков проектирования дискретных устройств

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

ответствующих уровню представления регистровых передач (Register Transfer
Language, RTL). В этом ряду можно отметить популярный в свое время и
ставший прообразом многих современных языков проектирования язык
CDL [29], выполненные в Советском Союзе разработки — язык ПРОЕКТ
Института кибернетики АН УССР [11], Ф -язык (иначе, "Язык функцио-
нального микропрограммирования") Ленинградского института точной ме-
ханики и оптики [15]. Все эти языки предусматривали определение набора
микроопераций, выполняемых в операционном блоке, и описание функ-
ционирования в форме микропрограмм. В современных терминах можно
говорить об использовании структурно -поведенческого описания проекта.
Однако отмеченные языки не были ориентированы ни на машинное моде-
лирование, ни, тем более, на прямую компиляцию в аппаратуру. Возмож-
ности автоматизации проектирования в тот период практически ограни-
чивались логическим синтезом и разводкой плат. Языковое представление
использовалось, главным образом, для спецификации проектов и сопровож-
дения ручного проектирования. Под сопровождением понималось наличие
компактного и наглядного описания для лучшей "обозримости" проектов
сложных систем, планирования работ, а также для обеспечения взаимопо-
нимания между разработчиками подсистем.
Один из первых, и до сих пор один из наиболее распространенных язы-
ков, VHDL, создавался в начале восьмидесятых так же, как язык специфи-
кации проектов. Однако очень скоро были созданы программы моделирова-
ния систем на основании описания в терминах этого языка, а в начале де-
вяностых уже и прямые компиляторы VHDL -программ в аппаратные
реализации различных классов.
К настоящему времени сложилась определенная иерархия языков проекти-
рования дискретных устройств. Критерием отнесения языка к определенно-
му уровню является степень абстракции используемых в языке конструкций.
В этом смысле можно наблюдать определенное соответствие типов языков
проектирования с языками программирования, которое иллюстрируется
табл. 2.5.
Таблица 2.5. Соответствие типов языков проектирования

языкам программирования
Уровень языка Языки Языки проектирования

программирования дискретных устройств
Языки реализации Программный код Таблицы соединений
Приборно (машинно) -ориенти - Языки ассемблера:

рованные языки
простой ассемблер PLDASM,
макроассемблер ABEL, AHDL...
Таблица 2.5 (окончание)
Уровень языка Языки Языки проектирования

программирования дискретных устройств
Процедурно -ориентированные FORTRAN, Pascal, С VHDL, Verilog HDL
языки
Объектно -ориентированные C++, Prolog, Java Hardware -C
языки
Языки реализации наиболее близко отражают результат проектирования, будь

то исполняемая программа или проектируемое изделие. В языках програм-
мирования это программный (машинный) код, представляющий последо-
вательность команд в том виде, в котором она считывается из памяти и
интерпретируется процессором. Из языков проектирования этому уровню
наиболее близко соответствуют языки описания соединений (таблицы со-
единений). Элементарные конструкции таких языков определяют набор
блоков проектируемого изделия и порядок их соединений в том виде, в ко-
тором они будут воспроизведены в устройстве. Тесна» связь языков низкого
уровня с аппаратными средствами проектируемой БИС заставляет компиля-
торы создавать проекты со структурой, заданной проектировщиком (ручное
проектирование может обеспечить получение более выигрышных парамет-
ров). Платой за это обычно является жесткая ориентация на определенную
аппаратуру и производящую ее фирму. Общий недостаток языков этого
уровня — большая трудоемкость разработки, включая трудности поиска
ошибок.
Простейшие машинно -ориентированные языки (язык простого ассемблера)
сохраняют структуру программного кода, т. е. используют представление
"одна машинная команда — один оператор". Однако применяется мнемони-
ческая запись операций, а также символическое представление операндов,
что делает текст более наглядным и контролируемым. Подобный принцип
заложен в язык PLDASM (аббревиатура расшифровывается как PLD
Assembler — ассемблер для ПЛИС). Оператор языка PLDASM задает опера-
цию, выполняемую ячейкой ПЛИС, и имена входных и выходных сигналов
ячеек, фактически операндов [28].
В языки уровня макроассемблера вводятся конструкции (макрокоманды и
макроопределения), которые интерпретируются не одной командой, а неко-
торыми достаточно стандартными последовательностями команд. Могут
вводиться и групповые данные. Одна из важных особенностей языков этого
класса — ориентация на определенный процессор и сохраняющаяся бли-
зость языкового описания и скомпилированной программы. Этим обеспечи-
вается большее по сравнению с языками высокого уровня влияние разра-
ботчика на результирующую программу, что иногда обеспечивает лучшие
показатели критических участков программ, прежде всего, производитель-

ность и затраты памяти.
Подобные свойства характерны для развитых приборно -ориентированных
языков. Обычно это входные языки САПР фирм изготовителей ПЛИС. Та-
кие языки, как правило, содержат опции, ориентированные на эффективное
использование архитектурных особенностей определенных типов ПЛИС, а
также широкий набор библиотечных модулей, оптимизированных с учетом
этих особенностей. Наиболее известные приборно -ориентированные языки
(Device Specific Languages) это AHDL фирмы Altera и ABEL, разработанный
фирмой Aldec и принятый в САПР фирмы Xilinx. Перенос разработок, вы-
полненных на языках ассемблерного уровня, в другие среды затруднен.
Процедурно -ориентированные языки программирования (в дальнейшем назо-
вем их просто процедурными) могут лишь косвенно отражать содержание
будущей реализации, используя специфические синтаксические конструк-
ции для описания порядка преобразований. Наибольшее распространение
получили языки VHDL и Verilog. Процедурные языки проектирования по-
зволяют описывать устройства через алгоритм их функционирования, в том
числе в реальном времени и во взаимодействии с физическим окружением.
Эти языки, как и другие алгоритмические языки высокого уровня, в прин-
ципе позволяют описать любой алгоритм в последовательной форме, т. е.
через последовательность операторов присваивания и принятия решений.
Основное их отличие в способности отражать также и параллельно испол-
няемые в аппаратуре действия, представляемые отдельными параллельно
выполняемыми процессами с общим инициализирующим воздействием.
Кроме того, процедурные языки проектирования расширяются оператора-
ми, позволяющими описывать структуру проектируемого изделия. Впрочем,
и структурное описание во многом подобно структуризации в традиционном
программировании — включение модуля в структуру можно рассматривать
с точки зрения представления в HDL -программе как вызов подпрограммы.
На сегодня процедурные языки являются наиболее универсальным аппара-
том описания цифровых устройств и покрывают диапазоны представления
от уровня элементарных логических ячеек до блочного описания сложных
вычислительных устройств. Практические все современные САПР имеют
встроенные компиляторы процедурных языков и обеспечивают возможность
моделирования поведения и непосредственного преобразования описания
в файлы конфигурации ПЛИС.
Объектно -ориентированные языки (ООЯ) основаны на абстракциях еще более
высокого уровня — классах, объектах. Программа на ООЯ строится как
последовательность вызовов объектов и методов классов. Преимущества
объектного подхода наиболее проявляются при реализации сложных про-
граммных проектов, ибо этот подход позволяет использовать такие важные
свойства классов, как наследование и инкапсуляцию.
Развития ООЯ для проектирования только еще началось. Наиболее разви-
тым представляется язык Hardware -C. Он построен как расширение C++
путем введения специфических классов, необходимых для представления

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

Архитектурно -структурное описание операционного блока базируется на
задании структуры соединений отдельных элементов. Традиционный графи-
ческий способ представления структуры соединений, оставаясь наиболее
наглядным способом, в современных САПР сопровождается текстовым спо-
собом описания. Входящие в состав САПР программные утилиты обычно
обеспечивают автоматическое прямое и обратное преобразование описаний.
Элементный состав операционного блока зависит от состава используемой
библиотеки. Большинство САПР поддерживает иерархическое описание
проектов. На любом уровне проект представляется как совокупность эле-
ментов этого уровня. Набор функциональных возможностей библиотечных
элементов, предлагаемых стандартными САПР, чрезвычайно широк, а по
составу и происхождению библиотеки разделяют на следующие:
- стандартные библиотеки фирмы -разработчика САПР, содержимое кото-
рой соответствует той или иной распространенной серии схем МИС и
СИС (например, ИС типа 74 серии);
- стандартные элементы вычислительной техники (n -входовые логические
элементы, дешифраторы, мультиплексоры, счетчики и т. д.). Параметры
элементов при этом фиксированы;
- типовые элементы вычислительной техники (счетчики, регистры, муль-
типлексоры и т. д.), ряд конкретных параметров которых (разрядность,
полярность управляющих сигналов и т. д.) могут назначаться проекти-
ровщиком произвольно;
- типовые узлы вычислительных систем (периферийные устройства, аппа-
ратные ядра микроконтроллеров и микропроцессоров), часть параметров
которых варьируется проектировщиком (как правило, разработка кон -
фигурации этих узлов выполняется либо фирмой -разработчиком узла,

либо в содружестве с ней);
- узлы вычислительных систем (периферийные устройства, аппаратные ядра
микроконтроллеров и микропроцессоров), часть параметров которых
варьируется проектировщиком. Узлы обычно разрабатываются фирмами,
специализирующимися на выпуске этого вида узлов (результаты разра-
ботки носят название IP, Intellectual Property, а содержимое поставляе-
мого описания носит название ядра интеллектуальной собственности —
core IP);
- элементы, созданные проектировщиком и объединенные в его библиоте-
ку проектировщика.
Любой проект может быть использован в качестве подпроекта в более слож-
ном проекте. Единую библиотеку модулей проектировщика можно и не соз-
давать (хотя желательно иметь некий путеводитель по собственным проект-
ным модулям, а в лучшем случае, базу данных о выполненных проектах).
Как правило, на любом уровне иерархии базовый набор элементов операци-
онного блока (этого уровня) дополняется требуемым для их функциониро-
вания набором регистров, логических схем (обычно многофункциональных
и управляемых), буферных схем и коммутируемых связей между ними. Важ-
но, чтобы на более низких иерархических уровнях описания проекта была
однозначная трактовка функционирования всех элементов ОБ.
Несмотря на оптимизацию схем, соответствующих наиболее распространен-
ным сериям ИС, самым неправильным (с точки зрения авторов) представ-
ляется практикуемый некоторыми проектировщиками прямой перенос схе-
мотехнических решений из реализации в форме СИС и МИС в реализацию
на БИС ПЛ. Получаемые при этом результаты, как правило, не только не
оптимальны, но зачастую не обеспечивают желаемого функционирования
проекта.
Описание поведения элементов операционного блока

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

На этом этапе определяется функционирование УУ, обеспечивающее тре-
буемое взаимодействие элементов ОБ. Следует подчеркнуть, что все состав-
ляющие рассматриваемого этапа проектирования сильно взаимосвязаны, и
если не разрабатываются параллельно, то чаще всего требуют итерационного
выполнения.
Формы и средства описания автоматов разнообразны. Вопросы и примеры
описания поведения автоматов в текстовой форме на различных языках
представлены в последующих главах.
Для повышения наглядности поведения автоматов большинство современ-
ных САПР поддерживает задание этого поведения в графической форме.
Описание в виде схемы переходов (диаграммы состояний) становится одним
из самых распространенных вариантов задания автоматов (в английской
терминологии State Machins). Графические редакторы для создания автома-
тов включаются в состав средств задания исходных проектов современных
САПР (например, в САПР Foundation фирмы Хilinх разработки фирмы
Aldec). Фирма Mentor Graphics для создания текстов на языках VHDL или
Verilog предлагает использовать специальный набор графических редакторов
под названием Renoir (с 2001 года HDL Designer Series). Редактор позволяет
создавать в графической форме описания не только автоматов, но и других
форм задания поведения проектов.
Редакторы разных фирм -производителей СБИС ПЛИС имеют особенности,
но для всех них характерны исключительная простота, естественность и дру-
жественность интерфейса с пользователем, а также отсутствие жесткой необ-
ходимости знания выходного языка редактора. Наиболее совершенные версии
программ типа StateCAD пакета Workview Office фирмы Viewlogic обладают
полным набором средств для выполнения всей проектной процедуры разра-
ботки управляющих автоматов (УА), позволяющих реализовать следующие
операции:
- рисовать граф переходов, включая наименование состояний, направле-
ния, условия и приоритеты условий переходов, формируемые сигналы и
способы их образования;
- проверять корректность составленного графа переходов (повторение
имен, неоднозначность перехода, некорректность перехода и т. д.);
- компилировать проект (формировать выходной текстовый файл) в вы-
бранном языковом базисе;
- моделировать поведение автомата в интерактивном или компиляционном
режиме.
Важное достоинство программы типа StateCAD — возможность широкого
выбора форм представления результата (описания на языках высокого уров-
ня VHDL, Verilog и С, а также на языках низкого уровня ABEL, AHDL).
Заметим, что специфика продукции той или иной фирмы сказывается и на язы-
ках высокого уровня, выражаясь, прежде всего, в отличиях в библиотеках,
требуемых для работы, и в сложности и вариантности допустимых синтак-
сических конструкций для компиляторов. Конечные результаты компиля-
ции одной и той же исходной схемы автомата или последующей компиля-
ции одной и той же программы с языка высокого уровня в загрузочный
файл микросхемы ПЛИС, полученные от компиляторов разных фирм, могут
существенно различаться и иметь различную эффективность. Программа
StateCAD пакета Workview Office удобна тем, что перед трансляцией графа
переходов можно задать не только желательное языковое представление
(VHDL, AHDL, Verilog, ABEL и т. д.), но и фирменные атрибуты, что по-
зволяет оптимизировать запись автомата и избежать применения синтакси-
ческих конструкций, недопустимых для компиляторов соответствующих
фирм.
Как уже отмечалось, при использовании графических редакторов от пользо-

вателя не требуется обязательное владение выходным языком редактора.
Однако в определенных случаях такое владение исключительно полезно.
Полезность ориентации в языковых конструкциях проявляется, например,
в ситуациях, когда автомат должен быть минимизирован по тем или иным
параметрам, прежде всего, по временным интервалам между формируемыми
выходными сигналами, что может приводить к временным состязаниям
сигналов. Именно в этих случаях владение языком и искусство проектиров-
щика облегчают получение наилучших результатов.
2.4.5. Этап 5. Компиляция проекта

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

ляции в САПР сторонних фирм. Как уже отмечалось, основное отличие со-
стоит в отсутствии у последних стадии формирования загрузочного файла.
Результатом работы компиляторов сторонних фирм, как правило, является
структура проекта в базисе выбранного семейства ПЛИС без конкретной
привязки к ресурсам ПЛИС. Чаще всего это носит название представления
на уровне регистровых передач. Программные пакеты сторонних фирм не
только создают такое представление, но дают возможности его просмотра и
автоматизированного анализа.
Классическим примером такого компилятора является пакет LeonardoSpect -
rum фирмы Exemplar Logic, Inc. (подразделение Mentor Graphics). Пакет
может поставляться в различных вариантах: стартовая цена первого уровня
2 тыс. долларов, второго — 8950 долларов, третьего — 17,5 тыс. долларов.
LeonardoSpectrum является набором высокоуровневых средств, предназна-
ченных для синтеза проектов, ориентированных на реализацию в форме
одиночной БИС CPLD, FPGA или в форме ASIC -проектов. Поддерживает
проектирование для ПЛИС фирм Actel, Altera, Agire Systems, QuickLogic,
Xilinx и др. Обеспечивает ввод проектов на языках VHDL и Verilog, отлад-
ку на уровне регистровых передач, оптимизацию, базирующуюся на зада-
ваемых проектировщиком ограничениях, анализ временных характеристик
проекта, формирование выходной информации, необходимой для размеще-
ния и разводки проекта в выбранную БИС, просмотр проекта на вентиль-
ном уровне.
Результат компиляции при использовании САПР фирм -производителей

БИС ПЛ — загрузочный файл, т. е. конфигурационная информация для вы-
бранной микросхемы ПЛИС. Кроме этого, обычно создается и файл отчета,
содержащий всю информацию как о процессе компиляции, так и о его ре-
зультатах. Имеется существенное различие для компиляционных процедур
схем типа CPLD и FPGA. Для FPGA помимо автоматического размещения
и трассировки соединений, как правило, допустимо и ручное вмешательство
проектировщика в процесс на любых его этапах. Этой цели служат редакто-
ры топологии (Floorplanner), позволяющие изменять структуру проекта на
кристалле и повышать производительность проектируемых устройств. А для
схем типа CPLD влияние проектировщика на структуру (а следовательно, и
характеристики) скомпилированной схемы, чаще всего, возможно только
путем косвенного воздействия, за счет либо изменения формы описания
проекта, либо изменения устанавливаемых перед компиляцией опций. Руч-
ная трассировка выбранных цепей возможна, например, в топологическом
редакторе FPGA Editor, входящим в состав САПР Foundation фирмы Xilinx.
Только после успешной синтаксической компиляции проекта или его час-
тей можно переходить к их верификации.
2.4.6. Этап 6. Верификация проекта

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

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

временных характеристик разработанного устройства
Наличие после компиляции проекта в САПР полной модели структуры про-
ектируемого устройства и знание временных параметров всех компонентов
этой структуры позволяет автоматизировать процесс вычисления различных
временных характеристик проекта.
Например, в САПР MAX+PLUS II (фирма Altera) предусмотрено автомати-
ческое вычисление трех основных классов временных параметров:
- минимальных и максимальных задержек между источниками (входными
сигналами) и приемниками (выходными сигналами), информация о ко-
торых выдается в виде матрицы задержек;
- максимально допустимой частоты тактирования элементов памяти, ис-
пользуемых в проекте;
- времен предустановки и удержания сигналов, гарантирующих надежное
срабатывание схем при фиксации сигналов в синхронных элементах па-
мяти.
Многие САПР позволяют также выделять критические пути передачи и
преобразования информации для схемного или топологического представ-
ления проекта.
Хотя выполнение перечисленных вычислений не гарантирует обнаружения
всех ошибок проектировщика, связанных с временными процессами в про-
екте, оно существенно уменьшает число таких ошибок или, как минимум,
позволяет обнаружить в проекте места, опасные с точки зрения сбоев, а
также выяснить причины непредусмотренного поведения проектируемой
системы.
2.4.8. Этап 8. Организация

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

желательные последствия.
Выполнение натурных экспериментов существенно увеличивает вероятность
выпуска бездефектной продукции. Средства ускорения работ на этом этапе
и возможности его переноса на ранние этапы разработки, т. е. до того мо-
мента, когда будет закончено изготовление конечного продукта, известны —
это прототипные системы и средства проведения экспериментов с ними.
Прототипные платы широко использовались и ранее, в частности, при соз-
дании микропроцессорных систем. Аналогична и ситуация при разработке
систем и устройств на основе средств программируемой логики. Прототип -
ная плата содержит одну или несколько микросхем программируемой логи-
ки и дополнительную аппаратуру, связанную с ее целевым назначением,
например, средства управления и отображения, микросхемы быстродейст-
вующих ОЗУ. Широкий спектр прототипных плат выпускается и поставля-
ется различными отечественными и зарубежными фирмами. Здесь можно
указать средства фирм Altera (Demo Board), PLD Applications (платы PCI Bus
Evaluation Board), Xilinx, Virtual Computer Corp., Video Software (платы НОТ
PCI Design Kit) и др.
Как при использовании прототипирования, так и при тестировании конеч-
ного изделия необходимо привлечение аппаратных и программных средств
для загрузки конфигурации, генерации воздействий и контроля правильно-
сти поведения исследуемого устройства. Важный момент проведения экспе-
риментов — генерация тестирующих воздействий. В этом плане БИС ПЛ
обеспечивают новые, не достижимые ранее возможности. Дополнительная
микросхема, а в некоторых случаях и определенная часть ресурсов отлажи-
ваемой БИС, могут использоваться как программируемые генераторы сиг-
налов. При этом содержание тестов легко модифицируется в процессе про-
ведения экспериментов в зависимости от результатов предыдущих шагов
экспериментальных работ. Полезным инструментом отладки могут стать сред-
ства передачи данных о состоянии тестируемого объекта в процессе выпол-
нения эксперимента в инструментальный компьютер с целью визуализации
и детального анализа (некоторые возможности представлены в разд. 2.6).
Многие ПЛИС и соответствующие САПР поддерживают такое взаимодейст-
вие. Но во многих случаях может потребоваться разработка специального
программного обеспечения для ускорения анализа поведения объекта тести-
рования. Естественно, в определенных ситуациях допускается пользоваться
серийной аппаратурой типа многолучевых осциллографов, логических ана-
лизаторов и т. п.
2.4.9. Этап 9. Подготовка

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

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

проектирования SOPC
Если еще совсем недавно схемы БИС и СБИС уже вмещали в себя боль-
шинство ИС, находящихся на одной печатной плате, то теперь один кри-
сталл SOPC вмещает в себя несколько СБИС (таких как МП, память, блоки
ввода/вывода). Задачи, встающие перед проектировщиком, собирающимся
использовать SOPC, внешне не отличаются от задач, уже рассмотренных для
МПС и ПЛИС. Основное отличие заключается в том, что в одном кристалле
должна быть спроектирована и аппаратура, и программное обеспечение.
Однако известно базовое положение теории систем (впервые опубликован-

ное в работах L. Von Bertalanfty) о несовпадении свойств целого и суммы его
частей вполне применимо для SOPC и поэтому требует пересмотра про-
цедуры проектирования SOPC практически по всем направлениям. С появ-
лением кристаллов SOPC требуются и уже начали происходить определен-
ные изменения практически на всех маршрутах проектных процедур.
Современное требование уменьшения времени, необходимого для выпуска
конечного продукта, заставляет искать пути сокращения как времени вы-
полнения любых отдельных этапов проектирования, так и устранения при-
чин, вызывающих необходимость итерационных возвратов к предыдущим
этапам проектирования. Традиционная процедура проектирования, приве-
денная на рис. 2.26, характеризовалась существенным запаздыванием разра-
ботки программ относительно разработки аппаратуры.
Традиционное проектирование без со -верификации
Проектирование HW
Построение прототипов
Отладка HW
Проектирование SW
Кодировка SW
Отладка SW
Завершение проекта
Рис. 2 . 2 6 . Традиционная процедура проектирования
Трудности проектирования SOPC связаны как с необходимостью выполнять

проекты в сжатые сроки, так и с постоянно возрастающей сложностью сис-
тем. По существующим оценкам, средний объем современных проектов
превышает 50 тыс. вентилей и имеет постоянную тенденцию удваиваться
каждые два года, и в окончательной стоимости проекта все большую роль
играют разработанные программные и "зашитые" в ПЗУ аппаратные ресур-
сы. Ожидается, что в ближайшие несколько лет проектами, содержащими
более 100 тыс. вентилей и МП -ядро (core -based), 'будут заниматься более
200 тыс. разработчиков. Возрастание сложности современных проектов как
в части объемов HW (в количестве логических вентилей), так и в части объ-
емов SW (в строках программного текста), делает проблему поддержки дан-
ного направления актуальной.
2.5.1. Специфические технико -технологические

особенности реализации систем типа SOPC
Как уже отмечалось выше, совмещение в одном кристалле программного и
аппаратного исполнения алгоритмов приводит не к арифметическому сло-
жению их потенциальных возможностей. Если на первом этапе появления
кристаллов типа SOPC основное внимание уделялось мобильности перифе-
рийной части МПС, и именно это выдвигалось в качестве основного досто-
инства SOPC, то далее стало понятно, что меняется отношение и к другим
составляющим МПС. Основным фрагментом, определяющим интеллекту-
альность, становится не процессор, а содержимое памяти, не периферия как
таковая, а память ее конфигурации. Процессор, а вернее его конкретная
организация, перестает быть доминирующим фактором, определяющим
производительность системы. Поведение или структуру процессора в совре-
менных системах можно достаточно легко изменить или просто поменять
процессор целиком (см. Agere Systems, http://www.agere.com). Перетрансля-
ция, а вернее эмуляция нового типа процессора (если процессор это
Softcore) может позволить без значительных временных потерь работать
с программой, исходно разработанной для другого процессора. При этом
свойство переносимости написанных на языках С и C++ программ — фак-
тор, существенно облегчающий подобные модификации.
Поскольку целью любого подхода к проектированию являются попытки уп-
рощения составления, а при необходимости и корректировки структуры
системы, то естественным будет желание построения системы по модульно-
му принципу. Тогда построение системы при помощи САПР сведется к из-
влечению необходимых строительных кирпичиков из библиотеки и взаим-
ной подгонке их друг к другу для получения выбранной архитектуры. При-
близительно так компоновались печатные платы из набора дискретных
компонентов ИС. Элементы плат объединялись в модульную структуру
с шинными связями.
Естественно, что этот же прием разработчики электронной аппаратуры по-
пытались сохранить и при переходе от размещения элементов в форме кор-
пусов ИС на печатной подложке к размещению и трассировке виртуальных
компонентов в плоскости кристалла. (Термин "виртуальность" будет исполь-
зоваться для того, чтобы подчеркнуть отличие физического представления
компонента в кристалле от его логического обозначения или описания в
проектной документации). Объединение блоков, в том числе и виртуальных
компонентов, независимо от их типа (HW -core, SW -core, firm -core) осуще-
ствляется с помощью шин. Однако подобный прямой перенос игнорирует
особенности и выгоды размещения элементов на одном кристалле.
При печатном монтаже ключевой стратегией являлась минимизация числа
шинных сигналов, поскольку рост числа контактов и сигналов непосредст-
венно отражался в размерах корпусов ИС, размерах платы и, тем самым,
в стоимости печатной платы. Такая тактика приводила к увеличению разме-

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

сопряженного проектирования
Рассмотренные выше проблемы и современные требования к проектирова-
нию систем и, прежде всего, типа SOPC привели к появлению таких новых
подходов к проектированию, как сопряженное проектирование, сопряжен-
ная верификация и сопряженное моделирование.
Co -проектирование (сопряженное проектирование) — процесс параллель-
ного проектирования аппаратных и программных средств, при котором
осуществляется оценка целесообразности выбора аппаратной или про-
граммной реализации определенного фрагмента проекта. Этот процесс так -
же дает проектировщикам возможность, увидеть (на абстрактном уровне),

как система могла бы работать с данным разделением аппаратных средств
ЭВМ и программного обеспечения.
Co -верификация (сопряженная верификация) — анализ совместной работы
программного обеспечения и аппаратных средств ЭВМ с целью определе-
ния, будут ли они функционировать правильно вместе. С другой стороны,
во время этого процесса анализируется, будут ли одинаково решаться спе-
цифические задачи проекта при аппаратной или программной реализации.
Результатом работы является фиксация выбранного варианта реализации.
Co -симуляция (сопряженное моделирование) — совместное моделирование
работы аппаратных и программных средств, при котором аппаратные сред-
ства ЭВМ описаны, например, в форме программных моделей (обычно это
VHDL - или Verilog -модели).
Возможны две трактовки понятия сопряженного проектирования: либо это
весь процесс проектирования, а со -верификация и со -симуляция его от-
дельные подэтапы, либо это начальный этап проектирования, результатом
которого является декомпозиция проблемы, а со -верификация и со -симуля-
ция это последующие и самостоятельные этапы проектирования. Разные
трактовки приводят к тому, что иногда отдельные решения в данной про-
блемной области ряд авторов выдает за решение общей проблемы. Реально
совместные процедуры выполняются в различных взаимных комбинациях
на различных этапах проектирования.
В целом задача современного проектирования SOPC — выполнять каждый
этап быстрее, с более надежными и достоверными (не требующими пере-
смотра и итерационных возвратов) результатами. Вопрос контроля проекта
становится одним из узловых. Если удается хорошо протестировать каждый
этап проекта и получить оценки его эффективности, то резко уменьшается
число итерационных возвратов в проектной процедуре. Основные этапы
процедуры сопряженного проектирования, базирующиеся на идеях со -
верификации, приведены на рис. 2.27.
Проблемы и методы их решения, опирающиеся на идеи сопряженного про-
ектирования, при совпадении их общих подходов отличаются и оказываются
различными для разных этапов проектирования.
Узловой проблемой проектирования микропроцессорных систем всегда яв-
лялась проблема принятия решения о разделении функций между про-
граммной и аппаратной частями системы. От успешности отнесения решае-
мого фрагмента системной задачи к той или иной реализации зачастую за-
висит успех или неуспех всего проекта.
На начальном этапе проектирования требуется правильно (эффективно, по
конечной оценке) разделить решаемые задачи между аппаратной и про-
граммной реализациями. Перемещение фрагмента от одной реализации
к другой на заключительных стадиях проектирования может вообще ока-

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

сопряженное проектирование обозначает параллельное проектирование
HW - и SW -средств с взаимными и координированными изменениями тех
шагов разработки, где предусмотрено их взаимодействие. Необходимость
перераспределения функций или действий между HW и SW может оказаться
целесообразной на любом шаге этого этапа проектной процедуры, такое пе-
рераспределение может быть исключительно полезным при составлении
частей проекта и его моделей. На заключительных этапах разработки HW
и SW необходимо убедиться в том, что получены правильно функцио-
нирующие части. Основной метод здесь со -верификация. Если совместное
HW/SW -моделирование выполняется достаточно быстро, этот процесс может
использоваться в качестве основы со -проектирования и со -верификации.
Задачей комплексной отладки HW и SW является быстрое устранение оши-
бок проектирования. На этом этапе наиболее сложной становится стыковка
двух разных подходов. Здесь у проектировщиков, представляющих противо-
положные стороны (HW и SW), появляются противоречия в трактовке при-
чин и источников отклонений характеристик системы от запланированных
или ожидаемых. Локализация причины отклонения и способы ее устране -
ния могут требовать очередного перераспределения функций между HW и

SW. Удобнее, чтобы стыковка произошла как можно раньше, и отладка вы-
полнялась средствами, одинаково эффективными и для аппаратуры, и для
программного обеспечения. Не менее важно, чтобы эти средства были оди-
наково удобны для разработчиков HW и SW.
Вопросы разбиения или перераспределения задач между HW и SW могут
возникать даже на этапе встраивания проекта в ИС или на этапах отладки
готового изделия. Однако чем позже, тем сложнее и дороже дается такое
перераспределение.
Идея сопряженного проектирования в SOPC приводит к двум основным
направлениям решения этой глобальной задачи:
- Откладывание вопроса о выделении конкретного исполнителя (для про-
граммной или аппаратной реализации) определенного поведенческого
фрагмента системы на как можно более удаленный момент при условии,
что описание поведения фрагмента существует и может использоваться
для моделирования, а возможно даже для синтеза фрагмента. Програм-
мная реализация может быть достаточно компактной. После реализации
основных функций ядра МП -системы добавление еще одной программы,
как правило, будет очень слабо влиять на объем памяти, уже заложенной
в систему, и не будет требовать замены типа используемой БИС памяти.
Даже существенная модернизация функционирования системы (при пра-
вильно заложенных ресурсах модернизации) не требует изменений кон-
струкции печатной платы при переходе к следующему более емкому кор-
пусу ИС памяти. Основным результатом безоглядного наращивания чис-
ла параллельно исполняемых задач на одном и том же процессоре может
оказаться ситуация, когда программная реализация не сможет вовремя
реагировать на внешние события. Аппаратная реализация, в отличие от
программной, хотя и требует значительных ресурсов, но зато не наклады-
вает столь жестких ограничений на поведение одновременно работающих
фрагментов.
- Возможность не принимать окончательное решение о разделении функ-
ций до как можно более позднего момента. Это позволяет отодвигать
решение вопроса о целесообразной физической реализации фрагмента на
более поздний срок. Такую возможность дает реализация нетиповой час-
ти проекта в форме БИС программируемой логики. При этом модифика-
ция структурной организации этой части системы может не требовать
конструктивного пересмотра. Перераспределение функций между аппа-
ратной и программной частями системы может быть выполнено в любой
момент времени жизни спроектированной системы. Предельным вариан-
том является реализация в форме кристалла типа SOPC, когда конструк-
тивная реализация спрятана внутри одного кристалла.
"Системы на кристалле" оказываются прекрасной технической основой со-
пряженного проектирования — поскольку системы оказываются в значи -
тельных пределах конструктивно инвариантными к аппаратным и про-

граммным решениям. Переход от одного способа реализации к другому не
требует существенной конструктивной переработки. Технологической осно-
вой сопряженного проектирования являются САПР, интегрирующие в себе
средства проектирования и отладки аппаратно -программных систем. Кроме
того, работа как самих САПР, так и проектировщиков существенно упроща-
ется, если возможно использование инвариантных способов описания аппа-
ратной и программной реализации.
До последнего времени реальное использование методов сопряженного про-
ектирования, а тем более соответствующих технических средств, сдержи-
валось целым рядом факторов и оказывалось по силам лишь небольшим
группам проектировщиков, связанных с разработкой новых проектов. Из
приведенных определений ясна общая постановка проблемы, проектная
процедура в таком случае может иметь вид, приведенный на рис. 2.28, одна-
ко вопрос состоит в том, как технически организовать эту действительно
совмещенную процедуру.
Проектирование с со -верификацией
Проектирование HW
Построение модели HW
Отладка модели HW
Построение прототипов
Отладка HW
Проектирование SW
Кодировка SW
Отладка SW
завершение проекта
Рис. 2.28. Процедура сопряженного проектирования
Целый ряд причин тормозит решение в такой общей постановке. Отсутству-

ет техническая база. В проектах еще достаточно 'редко используются со-
временные кристаллы SOPC. Проектировщики вынуждены опираться на
старые САПР, новые САПР оказываются очень дорогими. Нет единых про-
ектных средств самого первого уровня — системного — инвариантных к
реализации. Новые технологии проектирования требуют существенных из-
менений и в мышлении самих проектировщиков.
Проектированием сложных аппаратно -программных систем традиционно

занимаются специалисты трех профилей: системные инженеры, инженеры -
программисты и инженеры -схемотехники. Методы и средства автоматизации,
используемые этими разработчиками, существенно отличаются — програм-
мисты в своей работе больше внимания уделяли вопросам эффективного
описания программного обеспечения с точки зрения его поведения, в то
время как схемотехники традиционно тяготели к средствам, позволяющим
эффективно описывать структуру проектируемой системы.
Уже начиная с системного уровня проектирования, современные инженеры
пересматривают свои взгляды на то, как проекты надо сертифицировать, как
их надо разбивать на части, как их надо верифицировать и отлаживать.
До последнего времени системные инженеры и программисты опирались в
своей работе на языки С и C++, в то время как их партнеры по разработке
аппаратуры предпочитали схемотехническое представление проектов и лишь
в последнее время стали описывать свои разработки на языках VHDL и
Verilog. Расхождение во взглядах на целесообразность использования того
или иного способа описания проекта наносит явный ущерб не только ус-
пешности взаимного общения специалистов (разрабатывающих начинку од-
ного кристалла), но и, что более существенно, замедляет процесс проекти-
рования и ухудшает его качество.
Пересмотр позиций, как будет видно из дальнейшего материала, необходим
почти всюду. Целесообразно сосредоточить усилия на решении задач по че-
тырем ключевым направлениям:
- создание новых средств и методологии проектирования;
- систематическое повторное использование базовых элементов проектов;
- использование передовых САПР;
- введения новых и модернизация существующих стандартов с целью по-
вышения их эффективности.
Методология проектирования
Новые проектные подходы потребовались не только из -за огромной слож-
ности проектируемых схем (десятки миллионов вентилей), но и из -за таких
проблем, как временная корреляция между логическими и физическими
областями или достоверность верификации столь больших систем. Многие
традиционные проектные средства и методологии не срабатывают на таких
масштабах работы. Каждый шаг проектной процедуры, начиная от ввода
проекта и кончая физической загрузкой, должен обеспечивать получение
определенных промежуточных результатов. Если результаты проектирования
на каком -либо этапе не соответствуют требованиям технического задания
или существующим технологическим ограничениям, то результаты проекти-
рования не могут быть переданы на изготовление.
Рассмотрим, к примеру, геометрические размеры. При их величинах на

уровне квадратного микрометра и ниже задержка распространения сигнала
определяется уже не столько процессами в транзисторах, сколько длиной
межсоединения. Отсюда резко возрастает роль этапа размещения и разводки
(устранение ошибок здесь зачастую выполнить сложнее, чем устранить
ошибку в схеме на транзисторах). Проектировщик, для того чтобы убедиться
в правильности работы схемы, должен дождаться топологических результа-
тов и на их основе определить действительные задержки в приборе. Чем
раньше эта информация будет получена, тем раньше можно вернуться (при
необходимости) к более ранним этапам проектного потока и использовать
данные для коррекции произведенных стадий работы.
Вопросы конструкторско -технологической реализации проекта в форме со-
временных БИС ASIC становятся значимыми уже для первых шагов проек-
тирования. Многие неявно видимые связи между физическим и схемотех-
ническим воплощениями проекта оказываются весьма существенными.
Использование идей сопряженного проектирования для SOPC требует ре-
шения двух основных проблем. Первой проблемой является введение таких
средств описания проекта, которые позволили бы сгладить противоречия
между HW - и SW -реализациями. Второй проблемой (способ решения кото-
рой оказывается в значительной мере связанным с первой) является разра-
ботка и использование новой техники верификаций и моделирования. Су-
ществовавшие до последнего времени моделирующие средства не в силах за
приемлемые сроки обработать последовательность событий в столь сложных
системах или могут давать искаженную информацию. Выполнение модели-
рующих процедур на традиционных средствах может занять более года. Тре-
буется введение определенных дополнительных шагов в верификационную
процедуру, чтобы как можно раньше обнаружить те проектные ошибки, ко-
торые способны проявиться только после реализации проекта в форме кри-
сталла, если они остаются незамеченными раньше.
Систематическое повторное использование

Заполнение столь значительных объемов кристаллов (несколько миллионов
вентилей) в ограниченные сроки (8—10 месяцев), определяемые новыми
требованиями рынка (в первую очередь, мирового, да и российского тоже),
требует существенного пересмотра строительных кирпичей, из которых бу-
дет возводиться здание. С одной стороны, хорошо бы, чтобы модули были
как можно большего размера, их тогда меньше понадобится, но при этом
возникает риск потерять управляемость свойствами проекта, и, соответст-
венно, утратить шансы получить высокие характеристики. Нужен достаточ-
но широкий выбор строительных элементов, набор должен быть очень тща-
тельно проверен в разных условиях (отсюда желание, чтобы элементы уже
применялись в других успешных проектах). Требуется исключительно высо-
кая надежность и достоверность используемых модулей — после первого же
отказа их не будут больше применять. Многие авторы используют термин

Reused, чтобы специально подчеркнуть возможность применения модуля не
только в данном проекте, но и в других. Эффективность здесь заключается
не столько в долгой жизни IP, а скорее в обеспечении совместимости и
применимости их в последующих проектах. Для этого модули должны до-
пускать возможность модификации и изменяемости параметров в достаточ-
но широких пределах.
Отсюда основная проблема, где брать такие строительные кирпичи? Суще-
ствуют два основных варианта: использование фрагментов собственных про-
ектов или приобретение чужих разработок. Последний вариант является
покупкой интеллектуальной собственности (IP) сторонних фирм, специали-
зирующихся на выпуске IP -core, которые могут быть HW или SW. Потенци-
ально возможен и третий источник приобретения — создание добровольной
международной инициативы, собирающей и отбирающей лучшие разработ-
ки (по типу Linux, CPM, ОреnС и т. д.). Однако для практической реализа-
ции такой инициативы требуется определенное время и достаточное коли-
чество желающих участвовать. Независимо от источника приобретения,
основной проблемой является надежность модуля и возможность его доста-
точно простого встраивания в свой проект.
Значительный интерес представляет направление, предложенное в 1996 году
фирмой Cadence. Суть его состоит в разработке компонентов, подключение
которых к другим элементам системы будет определяться стандартом. Для
этого стандартом вводится понятие виртуальных компонентов (Virtual
Component, VC) и определяются правила их взаимного подключения. Ком-
понент может быть отнесен к классу виртуальных, если он будет удовлетво-
рять стандарту Virtual Socet Interface Alliance (VSIA).
Элементы набора могут существовать в разных формах:
- hard blocks, которые могут быть использованы для прямого физического
размещения в кристалле;
- firm blocks, которые должны соответствовать определенным физическим
требованиям фирмы -производителя кристалла;
- soft blocks, которые могут быть синтезированы и помещены в часть кри-
сталла, отведенную для ПЛИС.
Очевидно, что HW -блоки должны допускать определенную подгонку (на-
стройку параметров) в рамках семейства кристаллов. Более подробно вопро-
сы практического использования этого подхода будут рассмотрены при ана-
лизе соответствующих САПР.
Современные проектные средства

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

ладение новыми. Понимание описаний, создаваемых автоматическими про-
ектными средствами, необходимо для современного квалифицированного
разработчика.
Внешняя простота общения с графическими интерфейсами современных
САПР не должна заслонять важность уяснения проектировщиком организа-
ции и принципов работы узлов, являющихся результатами его творчества.
Задание поведения узла, выполненное на одном из языков описания аппа-
ратуры, или описание того же блока, но уже на уровне регистровых передач,
должны восприниматься проектировщиком так же, как и схемотехническое
задание структуры этого узла. Проектные средства, используемые для разра-
боток SOPC, должны не только органически объединить два ранее разде-
ленных проектных маршрута HW и SW, но и включить новые проектные
средства. Следует учитывать, что стоимость подобных средств будет на на-
чальных этапах весьма значительной (до нескольких сотен тысяч долларов).
Эффективность стандартов
Стандарты требуются для всех уже рассмотренных участников проектного
потока (включая и структуру самих SOPC). И даже для самих стандартов
обычно не мешает ввести определенные ограничения, лучше в форме стан-
дартов.
Возникновение и развитие методологии проектирования SOPC требует раз-
работки или модернизации стандартов, которые создадут более простые,
надежные, защищенные, закрытые от ошибок связи между различными
уровнями проектирования: системными, логическими и физическими. Од-
ним из наиболее широко используемых сейчас стандартов этого класса яв-
ляется стандарт SDF (Standard Delay Format). Заглядывая вперед, следует
ожидать того же и от стандартов, поддерживающих обмены между проект-
ными средствами не только в структурной, но и во временной областях. Со-
ответственно, для физического уровня того же можно ожидать для библио-
течных и проектных стандартов.
Связь между различными проектными средствами вполне может поддержи-
ваться уже хорошо зарекомендовавшими себя в других областях (не SOPC)
языками Verilog HDL, VHDL и EDIF, хотя некоторые изменения или рас-
ширения, диктуемые спецификой SOPC, могут потребоваться.
2.5.3. Стиль сопряженного проектирования

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

ной процедуре, но и начиная с наиболее ранних моментов проектирования.
Здесь все исследователи подчеркивают важность самого начального этапа
проектирования, а именно этапа спецификации проекта, когда описание
функционирования системы может еще не опираться на отнесение частей к
аппаратной или программной реализации. Основным инструментом провер-
ки и верификации становятся методы и средства системного уровня автома-
тизации (Electronic System Design Automation, ESDA). И первым вопросом
становится выбор средства описания (спецификации) проекта. Важным ока-
зывается возможность объединить разработку HW и SW, начиная с самых
ранних этапов работы.
Несмотря на определенную дуальность представления системы в форме ап-
паратуры и в форме программного обеспечения МПС, существует огромный
разрыв между уже имеющимися наработками и средствами, подготовленны-
ми на С и C++ для программного обеспечения, и наработками на этих же
средствах для аппаратуры. Мир разработок в области аппаратных средств
обладает не меньшим заделом, но на языках описания аппаратуры HDL.
Поэтому серьезным претендентом на роль языка системного уровня проек-
тирования является язык С. Наследство от программных разработок, напи-
санных на С, достаточно обширно, в то время как наследство аппаратных
разработок в лучшем случае доступно на уровне регистровых передач (языки
VHDL и Verilog). Для широкого использования язык системного уровня
должен:
- сохранить систему понятий, использованных проектировщиками при
разработке SW на языке С;
- добавить необходимую временную привязку к конструкциям языка С,
чтобы обеспечить их функционирование в аппаратуре;
- обеспечить сосуществование (для целей со -проектирования и со -модели -
рования) с существующей аппаратурой, написанной на языках HDL
(VHDL и Verilog).
Направление использования языков С и C++ в качестве основы подобного
языка поддерживается рядом компаний. Наиболее яркий представитель
этого направления фирма Synopsys. Поддерживаемая ею разработка под на-
званием SystemC, будет более подробно рассматриваться ниже.
Вместе с тем, ряд компаний расценил создание SystemC как неудачную по-
пытку использования традиционного программного языка для проектирова-
ния и моделирования, которая не дала ничего нового. Поэтому многие пе-
решли к собственным разработкам и достигли определенных результатов.
Язык низкого уровня RTL хорошо определен и является широко исполь-
зуемым языком описания HW, поскольку трансляция из RTL в аппаратуру
также хорошо определена и поддерживается многими производителями.
Вместо многих дней, необходимых для разводки ИС при ориентации на

уровень индивидуальной транзисторной ячейки, даже язык низкого уровня
RTL обеспечивает существенное ускорение процесса проектирования. Еще
большей результативности можно достичь, если опираться на языки более
высокого уровня.
Языки более высокого уровня могут поддерживать конструкции низкого
уровня — уровня RTL. Исходно Very High -Speed 1C (VHSIC) Design Langua-
ges включал VHDL (VHSIC HDL) и Verilog (Verifying Logic) HDL, причем
Verilog планировался как язык моделирования. В настоящий момент оба
языка VHDL International (VI) и Open Verilog International (OVI) сохранили
и свои группы разработчиков, и своих пользователей, но организационно
объединились под именем Accellera. Можно пытаться уменьшить различия
между этими двумя подходами, но ни один из них не может (по крайней
мере, в обозримом будущем) исчезнуть совсем.
Согласиться на один какой -то вариант или обеспечить (взаимное) конвер-
тирование описаний проектов из одного вида в другой (на различных эта-
пах), вот, пожалуй, и весь набор возможных вариантов. В настоящий мо-
мент отсутствует какое -то общепринятое мнение по этому вопросу, и по-
этому далее мы более подробно попытаемся проанализировать плюсы и
минусы различных подходов.
Фирма Co -Design Automation Inc. (www.co -design.com) разработала свое соб-
ственное подмножество языка Verilog под названием Superlog. Язык, в дей-
ствительности, является смешением Verilog и С. Тем самым поддерживается
простота общения с конструкциями обоих языков, но требуется языково -
специфический компилятор. Выгодами Superlog является возможность пря-
мого использования всех IP -языка Verilog без каких -либо модификаций.
Примером попытки совместить достоинства разных языков путем конверта-
ции описаний с одного языка на другой является пакет CynLib фирмы
CynApps (www.cynapps.com), ориентированный на C++. Библиотека пакета
CynLib доступна в режиме on -line. Продажным продуктом фирмы являются
интерфейс Verilog Co -simulation и пакет CynSuite, который имеет синтезатор
(Cynthesizer), транслирующий коды C++/Cynlib в описания Verilog RTL.
Разрабатываются проекты, базирующиеся на расширениях и совмещениях
существующих языков (HW и SW) с попыткой объединить в них достоинст-
ва обоих подходов. Типичным представителем этого пути стала фирма
Cynergy Systems Design Inc. (www.cae -plus.com). Основной идеей здесь явля-
ется создание языка, запатентованного под именем RTLC, который расши-
ряет язык регистровых передач, используя язык С. Целый ряд компаний
поддержал эту инициативу и работает с языком RTLC.
Пакет ArchGen содержит графическую оболочку, позволяющую генериро-
вать описание проекта на языке RTLC, описание проекта может легко мо-
делироваться и, базируясь на графической анимации элементов проекта,
упрощать решение проблем верификации и отладки. Другой продукт,

Builder, этой же фирмы Application Specification Virtual Prototype (ASVP)
также опирается на язык RTLC. Трансляцию (конвертацию) с языка RTL на
язык RTLC может выполнять пакет Afterburner.
Методы, устраняющие связь

сложности систем и скорости моделирования
Ключевым моментом для любой из рассмотренных выше методологий явля-
ется проблема моделирования, именно она предопределяет практическую
применимость идей сопряженного проектирования и со -верификации. Не-
большие проекты и проекты средней сложности могут с приемлемыми вре-
менными затратами моделироваться практически при любом виде входного
описания. Для очень больших же систем SOPC потребуются также сущест-
венные вычислительные мощности или применение методов, ускоряющих
сам процесс моделирования. Проектировщики двигаются различными путя-
ми, чтобы обеспечить компромисс между сложностью систем, точностью
моделирования и временами как подготовки к моделированию, так и к его
проведению.
Наиболее осторожные разработчики стараются использовать любые техни-
ческие средства и приемы, чтобы обеспечить проведение как можно боль-
шего числа тестовых испытаний на уровне как фрагментов, так и целой сис-
темы, но осуществленных до ее изготовления. Как правило, при этом на
первых шагах используются полные функциональные модели процессоров, а
затем тестирование выполняется на уровне прототипных образцов аппарат-
ных средств. Процедура проектирования, характерная для подобного подхо-
да, была приведена на рис. 2.28.
Компромисс по скорости моделирования достигается при использовании в
качестве составных частей предварительно тщательно проверенных IP, таких
как процессорные ядра. Кроме того, как правило, у разработчика имеется
несколько модификаций IP, отличающихся подробностью уровня описания,
это позволяет выбирать уровень описания того же уровня, что и остальной
проект. Однако зачастую более эффективным представляется моделирование
процессорного ядра на высшем допустимом уровне представления. Напри-
мер, моделирование на уровне кодирования логических команд может ока-
заться эффективнее, чем на вентильном уровне.
Для моделирования чаще всего используется подход, называемый моделиро-
ванием управляемым событиями (Event -Driven Simulation, EDS). Подробно
принципы EDS рассматриваются в гл. 3. Процесс моделирования больших
проектов (например, современные ASIC содержат свыше трех млн. вентилей
или более 20 млн. транзисторов) при использовании таких традиционных
средств может растянуться до года. Специально для того, чтобы снять огра-
ничения эффективности, свойственные моделировщикам, построенным на
принципах управления событиями, распространение получают средства мо-

делирования, построенные на принципах циклобазированного моделирования.
Циклобазированное моделирование (Cycle -Based Simulation, CBS) исполь-
зует специальные алгоритмы, которые исключают несущественные вычис-
ления, чтобы поднять производительность расчетов. Основными ограниче-
ниями метода CBS являются:
- результаты моделирования вычисляются только на фронтах тактового
сигнала;
- игнорируется поведение сигналов внутри фаз тактовых сигналов;
- для сигналов вычисляются только два логических состояния (0 и 1).
В результате, ограничивая объем вычислений, циклобазированное модели-
рование может обеспечить существенный выигрыш во времени моделиро-
вания.
Традиционные методы моделирования, управляемые событиями, наоборот,
жертвуют эффективностью, чтобы обеспечить большую функциональность
моделирования. Поэтому значения каждого активного сигнала вычисляются
для каждого элемента в течение всего такта. Полные симуляторы EDS -типа
обычно поддерживают:
- от 4 до 28 различных состояний сигналов;
- моделируют поведение элементов, представляющих собой транзистор,
вентиль, RTL - или HDL -описание;
- выполнение временных вычислений для всех элементов схемы;
- полный стандарт HDL -языков.
Циклобазированное моделирование сфокусировано на функциональном по-
ведении проекта и, следовательно, может быть оптимизировано для дости-
жения этих целей. В результате, эффективность моделирующих средств
этого типа превышает эффективность работы традиционных моделировщи -
ков в 10—1000 раз.
Вместе с тем, отмечая положительные стороны метода CBS, не следует про-
тивопоставлять один метод верификации другому. Использование каждого
из методов оказывается целесообразным для определенных условий приме-
нения. На рис. 2.29 приведен график, показывающий области целесообраз-
ного использования в процессе проектирования БИС высокой плотности
различных верификационных средств.
На рисунке процесс проектирования условно поделен на три основных эта-
па отладки, на каждом из которых целесообразно применение специфиче-
ских средств моделирования и верификации.
Этап отладки отдельных модулей. На начальном этапе верификационной
процедуры целесообразно привлечение средств, построенных на принципах
событийного моделирования. Средства этого типа используются, поскольку

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

отладка тестирование интеграция
Количество
ошибок
в проекте
Событийно -
1000 - управляемое
моделирование
Цикло -
100 - базированное
моделирование
10 -
Время проектирования
Рис. 2 . 2 9 . Области применения различных средств верификации
Этап регрессионного тестирования, который требует периодических возвра-

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

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

поддерживающие проектирование SOPC
Фирмы -производители кристаллов SOPC (а в большинстве случаев это
фирмы, ранее выпускавшие более простые схемы программируемой логики)
сохраняют и традиционное разделение функций со сторонними фирмами,
т. е., как минимум, оставляют за собой заключительные этапы проектирова-
ния кристалла — размещение элементов и трассировку межсоединений.
Однако, в отличие от обычных БИС ПЛ, проектирование схем SOPC требу-
ет проектирования и отладки программного продукта. Если проектирование
SW еще может выполняться на средствах проектирования сторонних фирм,
то отладка (по крайней мере, эффективная) требует применения совмещен-
ных средств. В современных проектных средствах большое внимание уделя-
ется включению средств разработки программных средств в проектные по-
токи разработки аппаратуры. Следует подчеркнуть, что это не просто меха-
ническое подключение еще одного программного средства, а обеспечение
тесной интеграции всех средств проектирования для организации совмест-
ной работы с HW и SW и обеспечение их совместной отладки. Для этого
в современных SOPC предусматривается отладка в рамках системы, интег-
рированной с исходной системой проектирования (Altera, Atmel, Triscend).
Фирма Atmel (http://www.atmel.com) для проектирования систем на базе се-
мейства FPSLIC (AT94) предлагает использовать свою САПР: System
Designer Ver. 2.1. Эта САПР в отличие от САПР других фирм не подключа-
ет, а включает в свой состав специальные версии программных средств, раз-
работанные фирмой Mentor Graphic (синтезатор Leonardo, моделировщик
ModelSim и со -верификационное средство Coverification). Описание проек-
тирования для БИС этой фирмы можно найти в литературе [14].
Фирма Altera (http://www.altera.com) для схем семейства Excalibur (EPXA,
ЕРХМ) на последних этапах проектирования, включая отладку, предлагает
использовать свою САПР Quartus П. Для работы с программным обеспече-

нием САПР обеспечивает переключение своего традиционного рабочего по-
тока в специальный режим проектирования программного обеспечения
(Soft -Mode), который подключает компилятор C/C++ и отладчик. Наиболее
рациональной, однако, фирма считает совместную работу со средствами
сторонних фирм. Примером подобной интеграции могут служить полные
функциональные САПР Quartus II и MAX+PLUS II, синтезирующие средст-
ва от Synopsys и Exemplar и моделирующие средства от Model Technology.
Более подробно организация корпоративной работы с продукцией фирмы
Mentor Graphic будет рассмотрена ниже.
Фирма Triscend (http://www.triscend.com) для проектирования на основе
производимых схем семейств Е5 и А7 предлагает использование САПР: Fast
Chip Triscend Ver. 2.3. Проектный поток, рекомендуемый фирмой, будет
приведен при рассмотрении практического примера в гл. 4.
Разработку SOPC корпоративными усилиями разных фирм можно наблю-
дать, рассматривая САПР и проектные потоки, используемые фирмами
QuickLogic, Cypress MicroSystems и Xilinx.
Фирма QuickLogic (http://www.quicklogic.com) для поддержки проектирова-
ния своих БИС QuickMIPS ESP (на 80% встроенная аппаратура, включаю-
щая ЦП MIPS 4Кс, 16 Кбайт память команд и 16 Кбайт данных и интер-
фейсные узлы, и на 20% FPGA с перемычками типа ViaLink) использует
САПР QuickMIPS development environment для процесса сопряженного про-
ектирования, включая отладку. САПР этой же фирмы QuickWorks Ver. 8.21
поддерживает все этапы проектирования БИС: схемотехнический ввод про-
екта, синтез и компиляцию, временной анализ, функциональное и времен-
ное моделирование, конфигурирование. Имеет лицензионные соглашения
на подключение пакетов САПР других фирм (компилятора Simplify фирмы
Simplicity, HDL -редактора Turbo Writer, моделировщика фирмы VeriBest).
Поскольку выпускаемые фирмой Cypress MicroSystems (http://www.cypress.com)
БИС SOPC семейства CY8C25***/26*** содержат не только типичные для
всех SOPC части (МП и ПЛИС), но и аналоговые блоки, то весьма инте-
ресна организация фирменной САПР: PSoC Designer IDE. САПР представ-
ляет собой интегрированный пакет средств разработки встраиваемых PSoC -
систем. Пакет обеспечивает доступ ко всем традиционным средствам, вклю-
чая полный отладчик, поддерживающий внутрисхемную эмуляцию In -
Circuit Emulator (ICE). Основой IDE является редактор проекта (Device
Editor), обеспечивающий легкий в использовании графический интерфейс
для реконфигурируемости подключаемых к МК устройств (MCU). В состав
Designer IDE входят редактор приложений, библиотеки, ассемблер и компи-
лятор языка С, загрузчик, линкер, отладчик и программатор.
Однако на предварительном этапе проектирования для моделирования про-
ектов, содержащих смешанные аналого -цифровые цепи, фирма Cypress
предлагает использовать ПО лидирующей фирмы — Antirim Design System

(Antirim -ACV, Antirim -MSS).
Для проектирования кристаллов типа SOPC фирмы Xilinx (www.xilinx.com)
может использоваться САПР этой фирмы ES Series. Интерес представляет
сообщение о выпуске САПР, поддерживающей полный цикл проектирова-
ния, ориентированного на описание и SW, и HW на языке С. Примером
одного из первых коммерческих вариантов реализации этого подхода к со-
пряженному проектированию на базе языка С является анонсированная
фирмой Celoxica Limited проектная САПР под именем DK1. Помимо обыч-
ных возможностей пакет поддерживает еще одно важное свойство будущей
системы: обеспечивает не только быстрое (за недели и дни вместо традици-
онных лет) создание электронной продукции, но и реализует фундамен-
тально новый подход к проектированию электронной аппаратуры, позволяя
лучше управлять жизненным периодом продукции за счет поддержки сред-
ствами Интернета корректировки аппаратуры во время ее эксплуатации.
Пакет DK1 фирмы Celoxica Limited разрешает использовать навыки разра-
ботчиков программного обеспечения в создании аппаратуры. Разработчик
записывает сложные алгоритмы поведения проектируемой системы на языке
Handel -C (языке высокого уровня, базирующемся на стандарте ANSI С) для
их преобразования в аппаратуру. В отличие от подходов, когда требовалась
перекомпиляция С -подобных программ на промежуточный язык описания
аппаратуры, пакет DK1 обеспечивает прямое преобразование программы,
написанной на языке С, в аппаратную реализацию. DK1 позволяет на по-
следующих стадиях осуществлять перевод проверенных рынком проектов,
реализованных в форме FPGA, в форму традиционных ASIC -решений. Хотя
некоторые фирмы -производители конечной продукции могут продолжать
выпуск продукции в форме FPGA, чтобы сохранить потенциальные воз-
можности корректирования и улучшения продукции, опираясь на ресурсы
сети Интернет. Пользователи, использующие Internet Reconflgurable Logic
(IRL), могут преобразовывать С -ориентированные проекты прямо в список
соединений FPGA семейства Virtex фирмы Xilinx без перевода их описаний
на языки VHDL, Verilog или в схематическое представление. По мнению
разработчиков DK1, в результате проектирование аппаратуры не будет тре-
бовать привлечения специалистов -схемотехников, а окажется доступным
для прикладных специалистов, включая системных инженеров и инжене-
ров -программистов. Помимо оболочки, Integrated Development Environment
(IDE), пакет DK1 содержит весь набор проектных средств, включая компи-
лятор, моделировщик и отладчик. Этот набор средств обеспечивает выпол-
нение всех типовых проектных этапов, включая компиляцию, моделирова-
ние, оптимизацию и отладку проектов, написанных на высокоуровневом
языке Handel -C. Проектировщик может ориентироваться на использование
поставляемых фирмой прототипных плат и универсальных печатных плат
(типа RC1000), которые готовы к размещению пользовательских проектов,
ориентированных на FPGA семейства Virtex, и могут прямо вставляться в

аппаратуру разработчика.
Пакет работает на IBM PC -совместимых компьютерах под ОС Microsoft
Windows 98, 2000 или NT4.0 и поддерживает БИС фирм Хilinх и Altera. На-
чальная цена 25 тыс. долларов в год для трехгодичной лицензии.
Количество фирм, поддерживающих различные аспекты и этапы проектиро-
вания кристаллов SOPC, весьма велико, предлагаемые ими решения пред-
ставляются интересными и перспективными и могут являться предметом
самостоятельного исследования. Однако основной тон, так же как и в дру-
гих производственных сферах, задают крупные фирмы, материальные, тех-
нические и другие ресурсы которых позволяют им разработать и предложить
не отдельное решение, а группу согласованных решений, образующих ин-
тегрированную систему. Наибольший интерес представляют те предложе-
ния, которые могут в ближайшем будущем получить широкое распростра-
нение и останутся надолго. Как правило, такими решениями являются раз-
работки крупных фирм, специализирующихся на выпуске САПР. Среди
фирм, уделяющих значительное внимание проблемам создания проектных
средств в рассматриваемой области, наибольший вес имеют фирмы Mentor
Graphics, Cadence и Synopsys. Поэтому ниже и рассматриваются основные
программные продукты этих фирм, поддерживающие проектирование сис-
тем SOPC.
Фирма Mentor Graphics

Одним из основных современных средств со -проектирования, получивших
широкое распространение, является пакет Seamless -CVE фирмы Mentor
Graphics. Его задача состоит в построении виртуального прототипа аппара-
туры для работы прикладного SW. Наличие у фирмы программных моделей
большинства процессорных ядер различных фирм позволяет приступить к
написанию и отладке программ практически сразу после выбора типа мик-
ропроцессорного ядра. Большое значение имеет и тот факт, что могут ис-
пользоваться модели разной степени детализации. Пакет обеспечивает раз-
биение проекта на части, со -верификация выполняется с высокой произво-
дительностью, с использованием моделировщика системы команд, когда
моделируется процессорное ядро.
Основное отличие пакета состоит как раз в том, что если моделирование
аппаратной части SOPC выполняется традиционными средствами пакета
ModelSim, то моделировщик процессорного ядра построен на принципах,
отличных от принципов, используемых в традиционных средствах модели-
рования. Благодаря этим изменениям скорость со -моделирования аппарат-
ных и программных частей системы удалось увеличить в несколько сот раз
при сохранении детальности анализа работы аппаратной части системы.
На рис. 2.30 приведен проектный поток, используемый при разработке схем
класса Excalibur фирмы Altera. Проектирование предполагает совместную
работу САПР разных фирм. Как видно из рисунка, пакет Seamless использу-
ется в со -верификационной процедуре. Такое же применение (но во встро-
енном исполнении) пакет находит в проектном САПР фирмы Atmel.
Проектирование Проектирование
Hardware Software
Рис. 2 . 3 0 . Проектный поток для SOPC фирмы Altera
Фирма Cadence
Фирма Cadence Design Systems, Inc. (http://www.cadence.com) выпускает боль-
шое количество САПР, отличающихся целевым назначением, стоимостью,
технической и программной платформой и т. д. С точки зрения сопряжен-
ного проектирования наибольший интерес могут представлять два направ-
ления работ этой фирмы.
Первым является направление, связанное с использованием понятия "вир-

туальные компоненты". Упрощения создания систем на идеях сопряженного
проектирования фирма Cadence пытается добиться в пакете Virtual Compo-
nent Codesign (VCC). Пакет поддерживает спецификацию проектов на раз-
личных языках, включая С, C++, MATLAB и SDL, а также систему SPW
(Signal -Processing Work system), ускоряющую проектирование на системном
уровне сложных систем цифровой обработки сигналов. Пакет предназначен
для распределения задач между HW и SW, для анализа загруженности шины
и процессора и способен контролировать процедуру распределения задач и
состязания за ресурсы в системах реального времени RTOS. Коммуникатив-
ные ссылки помогают конвертировать абстрактные интерфейсные описания
лексемного уровня в действительный уровень сигналов интерфейса. Со -
верификация VCC включает симуляцию, так же как и поддержку Affirma
HW/SW верификатора фирмы Cadence.
Вторым важнейшим направлением деятельности фирмы Cadence можно
считать работы над созданием САПР, ускоряющих моделирование проекти-
руемых систем. Фирмой выпущена САПР SpeedSim — программный па-
кет спроектированный специально для уменьшения времени и цены со -
верификации больших проектов. Пакет был успешно использован для про-
изводственной верификации проекта, содержащего более 5 млн. вентилей.
Построен он на основе метода циклобазированного моделирования для того,
чтобы снять ограничения эффективности, свойственные традиционным мо -
делировщикам, базирующимися на принципах управления событиями. Ре-
зультирующая эффективность пакета в десятки или тысячи раз превышает
эффективность последних. Существенного ускорения работы пакета удалось
достичь путем его реализации в форме однопроходного компилятора с язы-
ка Verilog, как показано на рис. 2.31.
Для получения высокой эффективности при создании SpeedSim в него были
заложены различные новейшие технологии. Можно выделить пять основных
особенностей реализации пакета.
- Технология BDF (Boolean Data flow Engine). Пакет генерирует исключи-
тельно эффективный программный код за счет ориентации на внутрен-
ний код моделирующей ЭВМ.
- Минимизация памяти. Объемы требуемой памяти по сравнению с пакета-
ми на базе EDS уменьшены от 5 до 50 раз.
- Совместное тестирование. На одной рабочей станции с одной копией
проекта может одновременно моделироваться до 32 различных тестов.
- Режим работы Symmetric Multi -Processing. Предусмотрено функциониро-
вание пакета в мультипроцессорной системе, когда он может распаралле-
лить решение задачи между 8 процессорами, работающими с одним сер-
вером.
Традиционный SpeedSim
Рис. 2 . 3 1 . Варианты построения компиляционных процедур
- Быстрые возвратные итерации. В пакете учитывается итерационность

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

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

деляется тем, что проектировщик может опираться на ряд уже созданных
проектных средств. Этот ряд включает проект SystemC, создание которо-
го было инициировано фирмой Synopsys, пакет N2C фирмы CoWare
(www.coware.com) и пакет Ptolemy — для быстрого виртуального прототипи -
рования.
Обзор проектного потока и базовых средств SystemC

В сентябре 1999 года ряд ведущих компаний, разрабатывающих САПР, IP и
ПО для системных и встраиваемых приложений, объявил об инициативе
создания Открытой Системы С (Open SystemC Initiative, OSCI) и немедлен-
ной ее доступности и свободной загрузке. Моделирующая C++ платформа
была названа SystemC. Управляющая группа инициативы включала такие
крупные фирмы, как ARM, CoWare Inc., Cygnus Solutions, Ericsson, Fujitsu,
Infineon, Lucent Technologies, Sony Corporation, STMicroelectronics, Synopsys
Inc. и Texas Instruments. (За основу рассмотрения возьмем версию SystemC
1.0, анонсированную в марте 2000 г.).
Фундаментом системы является специализированная библиотека классов
C++ и проектный маршрут. Назначением подготовительного этапа проек-
тирования является создание моделей, соответствующих поведению процес-
сора и интерфейсных компонентов аппаратуры на цикловом уровне. Базо-
вым принципом был принят иерархический подход, использование которого
может распространяться от абстракций достаточно высокого уровня, до низ-
коуровневой логики. В основу SystemC положили ряд классовых шаблонов,
определяющих небольшой набор новых понятий. К ним относятся асин -
хронность временных операций, методика соединений, эффективность от-
слеживания поведения объектов программы, регистрация и отладка событий
в проекте. Знание адекватных понятий VHDL или Verilog очень помогает
при изучении SystemC: несмотря на расхождение в синтаксисе, в семантике
все же больше совпадений, чем расхождений.
Все строительные блоки в SystemC являются объектами (classes). Фундамен-
тальным строительным блоком является процесс (process). Process подобен
функции в языках С и C++, описывающей некоторое поведение. Описание
законченной системы представляет собой множество параллельных процес-
сов, связанных друг с другом посредством сигналов (signal). Функциониро-
вание процессов может определяться тактовыми сигналами (clock), исполь-
зуемыми для формирования событий или синхронизации процессов.
Для эффективного моделирования HW требуются специальные типы дан-
ных, также являющиеся частью библиотеки SystemC. В состав библиотеки
входят описания одних и тех же модулей, но на разном уровне абстракции
(именно это позволяет обменивать скорость трансляции и моделирования
на точность и адекватность). На высшем уровне иерархии HW системы мо-
жет быть описано исключительно на функциональном уровне, для более
точного моделирования поведения аппаратуры потребуется либо функцио-

нальное ее описание, либо описание на уровне регистровых передач. Про-
граммная часть системы пишется на средствах традиционных С и C++. Что
касается интерфейса между HW и SW, или между HW - и HW -блоками, то
он может описываться на следующих уровнях — на уровне обменов тран-
закциями (transaction -accurate level) или на уровне цикловых обменов (cycle -
accurate level). В пределах одного проекта допускается произвольное смеше-
ние уровней детализации описаний. То же самое относится и к созданию
программных тестов (Test -Bench). Для получения окончательных программ,
подаваемых на вход любого компилятора, совместимого с ANSI C++,
SystemC содержит не только стандартные библиотеки классов, но и компо-
новочную библиотеку, которая включает моделирующее ядро. Программное
обеспечение системы разработки (рис. 2.32), в составе которой обычно ис-
пользуется моделирующая SystemC, позволяет эффективно создавать, моди-
фицировать и отлаживать проект разработчика.
Библиотека Среда Исходные файлы

файлов разработки C/C++
Рис. 2.32. Структурный состав среды разработки с SystemC

Подробное описание SystemC можно найти в Reference Manual Release 1.0.

Здесь же остановимся на кратком описании тех базовых понятий, добавле-
ние которых к универсальному языку программирования позволило в со-
вмещенном варианте моделировать совместное поведение HW и SW. В об-
щем случае, набор этих понятий мог бы иметь другое синтаксическое
оформление, однако важным представляется их целевое назначение и, как
следствие, обязательное присутствие подобных конструкций в языке, пре-
тендующем на системный уровень спецификации аппаратно -программных
систем.
- Modules — набор, содержащий классы. Модули допускают иерархиче-
скую организацию и могут включать другие модули и/или процессы. Мо-
дули имеют (однонаправленные или двунаправленные) порты, которые,
по сути, являются функциональными интерфейсами, обеспечивающими
соединение модулей между собой. Наличие интерфейсов позволяет
скрывать внутри модуля детали его реализации и удобны для включения
в состав модулей различных блоков IP.
- Processes — процессы, которые используются для описания выполняемых
функций. Процессы могут быть как одиночными объектами, так и со-
держать внутренние модули.
- Signals — SystemC поддерживает два типа сигналов: resolved и unresolved.
Сигналы типа resolved, в отличие от сигналов типа unresolved, могут
управляться более чем одним драйвером (в том числе шиной).
- Rich set of signal type — для поддержания моделирования на различных
уровнях абстракции (от функционального до уровня регистровых пере-
дач), включая и поддержку моделирования SW, SystemC поддерживает
значительное число типов сигналов. Этим язык отличается от языка типа
Verilog, который поддерживает только простой и векторный битовый ти-
пы сигналов. SystemC поддерживает и двузначный, и четырехзначный
типы сигналов.
- Rich set of data type — SystemC содержит обширный ряд типов данных,
что позволяет поддерживать множественные проектные наследования и
абстрактные уровни. Типы данных с фиксированной точностью позво-
ляют ускорять моделирование при сохранении приемлемой точности его
результатов. Типы данных с произвольной точностью (ограничения на
задаваемую точность отсутствуют) могут использоваться для вычислений
с повышенной точностью и моделирования больших шин. Система под-
держивает и двузначные и четырехзначные типы данных. Система вклю-
чает и богатый ряд перегружаемых операторов и типов, а также механиз-
мов преобразований для этих типов данных. -
- Clocks — SystemC содержит определение тактовых сигналов (Clocks) как
специального типа сигналов. Такты хронометрируют систему в тече-
ние моделирования. Поддерживается множественность тактовых сигналов
с различными фазовыми взаимоотношениями.
- Reactivity — для моделирования реактивности поведения SystemC имеет

механизмы ожидания фронтов и спадов тактовых сигналов, событий или
сигнальных изменений. Система также поддерживает ожидание опреде-
ленных событий, не связанных с выполнением какой -либо определенной
стадии процесса (наиболее типичным примером является ожидание
асинхронных сигналов сброса).
- Multiple abstraction levels — SystemC поддерживает моделирование на раз-
личных уровнях абстракции, выполняя моделирование от высших уров-
ней функциональных моделей до детализированных моделей на уровне
RTL. Система поддерживает итеративное уточнение моделей от высших
к низшим уровням абстракции.
- Creating functional models — для работы с абстрактными функциональны-
ми моделями SystemC вводит понятие коммуникационного примитива,
называемого каналом (Channel). Канал представляет собой специальный
тип сигнала, при помощи которого могут взаимодействовать между собой
синхронные или асинхронные процессы. Канальное взаимодействие от-
личается от обычного сигнального взаимодействия. Для обеспечения за-
писи в канал или чтения из канала требуется определенное число такто-
вых циклов, однако затраты времени требуемого на обеспечение соеди-
нения не фиксируются, поскольку не являются существенным свойством
канала. Обычно каналы являются средством, используемым на начальных
стадиях моделирования, когда основной интерес представляет системное
функционирование. В подобных ситуациях каналы являются механиз-
мом, призванным гарантировать надежность обмена данными. Каналы в
неявной форме производят необходимое квитирование обмена для гаран-
тирования корректности доставки данных от передатчика к приемнику.
В последующих версиях системы понятие каналов расширено до уровня
многоуровневой коммуникационной семантики, что позволяет описывать
как внутренние (SOPC), так внешние (ввода/вывода) протоколы с раз-
личным уровнем коммуникационной абстракции (уровень передачи дан-
ных, уровень шинного цикла, уровень тактового цикла).
- Cycle -based simulation — для обеспечения высокой скорости моделирова-
ния SystemC включает в свой состав ядро моделирования на уровне цик-
лов моделируемой HW -системы. При этом сохраняются механизмы для
управления моделированием из любой точки входной спецификации.
- Debugging support and waveform tracing — классы, введенные в SystemC,
имеют встроенные средства контроля ошибок реального времени испол-
нения (run -time error checking), которые могут зависеть от течения ком-
пиляции. Ядро системы содержит базовые программы, которые позволя-
ют запомнить временные диаграммы внутренних сигналов моделируемой
системы в выходных файлах (с форматами типа VCD, WIF или ISDB),
что позволяет в дальнейшем просматривать их содержимое типичными
редакторами временных диаграмм.
Процесс проектирования в системе SystemC

Процесс проектирования начинается с того, что разработчики создают
функциональную спецификацию системы. Целью является проверка функцио-
нирования алгоритмов и системы. Функциональная спецификация пред-
ставляет собой описание связей, соединяющих при помощи сигналов и ка-
налов взаимодействующие процессы. Процессы соответствуют определен-
ным действиям и могут требовать подключения различных архитектурных
блоков, которые могут быть реализованы в форме HW или SW. Поскольку
функциональная работоспособность системы может быть проверена путем
компиляции и последующего исполнения программы C++, то функцио-
нальная спецификация может быть преобразована в архитектурную специ-
фикацию.
В архитектурной спецификации процессы отображают работу таких действи-
тельных аппаратных блоков, как процессоры, память, блоки прямого досту-
па к памяти или оборудование ввода/вывода. Взаимодействие между про-
цессами осуществляется при помощи сигналов, соответствующих реальным
соединениям в аппаратуре. Таким образом, в архитектурной спецификации
происходит разделение на программные и аппаратные компоненты, но по-
скольку для описания любых компонентов использован один и тот же язык,
то возможны любые архитектурные перестановки и изменения, вероятны
даже изменения и замещения между программными и аппаратными реали-
зациями.
Завершение архитектурной спецификации и выполнение ее компиляции
позволяет не только убедиться в работоспособности проекта, но и опреде-
лить основные характеристики производительности проектируемой системы.
В соответствии с ранее данным определением это и есть один из вариантов
реализации сопряженной верификации и сопряженного моделирования.
Основное назначение действий этого этапа — проверить эффективность
различных вариантов архитектурного описания, поэтому для ускорения пе-
ребора различных вариантов реализации желательно, чтобы модели этого
уровня описания проекта были максимально простыми и отражали наибо-
лее существенные характеристики моделируемых блоков. Именно поэтому
на описываемом уровне для процессоров, например, используется модель,
соответствующая шинной организации функционирования. Такой же мак-
симально абстрактный уровень описания функционирования применяется и
для других блоков системы.
Если основные вопросы построения архитектуры системы решены, то есте-
ственен переход к следующему этапу проектирования. На этом уровне все
аппаратные и программные блоки должны быть уточнены и доопределены
добавлением необходимых деталей и введением конкретных ограничений на
реализацию. Поскольку HW - и SW -средства работают совместно (парал-
лельно -последовательно) со -верификационные действия должны выпол -
няться непрерывно, чтобы обеспечить правильную работу системы после

подобных корректирующих действий. Усложнение и детализация описаний
аппаратных и программных блоков заставляет переходить к более подроб-
ным и детальным описаниям модулей. Для процессора, например, целесо-
образно подключение к модели функционирования шины Bus -Functional
Model (BFM) еще и модели работы системы команд Instruction Set Simulator
(ISS), для многих других блоков потребуются более подробные поведенче-
ские модели или описания на уровне регистровых передач (RTL). Основной
проблемой при этом является, как уже неоднократно отмечалось выше,
проблема резкого увеличения временных затрат на со -моделирование.
Как правило, начиная с этого момента, работа с HW и SW разделяется. Для
доведения аппаратуры до вентильного уровня должны использоваться соот-
ветствующие синтезирующие средства. Чаще всего требуется перевод описа-
ния на языки описания аппаратуры HDL (VHDL или Verilog), а уже затем
синтезирующая процедура. Работа над обоими направлениями не всегда
может идти синхронно. Достаточно часто SW является источником проти-
воречия между повышенной производительностью системы и минимизаци-
ей ресурсных требований. Для устранения противоречий необходимо про-
анализировать большинство фрагментов системы при их реализации в фор-
ме HW - и SW -проектов. Окончательное решение определяется таким
выбором HW, которое обеспечит максимальную эффективность работы SW
в соответствии с системными ограничениями.
Между ошибками, допущенными в HW и SW, существует большая разница.
Если проектировщик допустил ошибку в аппаратуре, то и программное
обеспечение будет работать с ошибками. Корректность работы обоих частей
проекта является крайне важной. Вместе с тем, средства разработки SW ока-
зываются относительно независимыми от средств сопряженного проектиро-
вания, и поэтому разрабатываемый SW -модуль (код) может много раз с ис-
правлениями возвращаться в верификационную процедуру. Таким образом,
поступают многие средства со -проектирования, чтобы обеспечить механизм
итерационных возвратов.
SystemC не является единственным вариантом решения проблемы и был
выбран исключительно из -за своей распространенности, например, другим
С -базированным решением является пакет CycleC фирмы C -Level Design
Automation (www.cleveldesign.com), написанный на ANSI С.
2.5.5. Понятие
платформенно -базированных проектов SOPC
Значительное количество современных разработчиков поддерживают плат -
форменно -базированное проектирование SOPC. Основной задачей такого
подхода является сокращение времени проектирования путем сосредоточе -
ния внимания проектировщика только на тех аспектах проекта, которые

отличают его проект от любых других. Подход не отрицает и не противоре-
чит большинству подходов, рассмотренных выше, а только добавляет новые
свойства. Обычно под платформенно -базированным проектированием (далее
ПБ -проектирование) понимают проектирование, построенное на стандарт-
ном ряде модулей интеллектуальной собственности (IP), разработанных той
или иной компанией. Как правило, такой набор включает набор процессо-
ров, память с различной организацией, определенные блоки периферии,
контроллеры прерываний и ПДП. Этот подход является одним из вариантов
попытки создать свой собственный проект SOPC без существенных старто-
вых издержек (сюда не входит стоимость приобретения прав на IP).
Выгоды подхода связаны с тем, что базовый набор, как правило, хорошо
определен, протестирован и не требует значительных переделок для других
модификаций (если они не выходят за рамки подключения этого IP к дру-
гим IP данного набора. Очевидно, что здесь допустимы и известные из-
держки, связанные, например, с тем, что не все стандартные компоненты
набора платформы будут соответствовать пожеланиям проектировщика, а
модернизация IP, особенно если они зашифрованы, может оказаться делом
более сложным, чем самостоятельная разработка.
Несмотря на начальный этап развития направления ПБ -проектирования
SOPC, уже наметились некоторые различия в подходах у разных фирм. Од-
ной из ведущих выступила фирма CoWare с пакетом N2C.
Серьезным и интересным конкурентом выступает фирма Virtio Inc.
(www.virtio.com), использующая свою САПР MagicC как компилятор HDL -
моделей. Самым интересным здесь является то, что моделирование и тести-
рование осуществляется в режиме on -line на сайте фирмы.
Проведем сначала краткий анализ самих платформ и общих понятий и про-
блем, а затем рассмотрим особенности их проектирования.
Платформа Xtensa фирмы Tensilica Inc. (www.tensilica.com) относится к клас-
су ПБ -проектирования SOPC (может быть отнесена к подклассу проек-
тируемых и оперативно настраиваемых SOPC) и является 32 -разрядной
200 МГц архитектурой с дополнительным DSP. Отличительной особен-
ностью процессора Xtensa является наличие специального процессорного
генератора Processor Generator, который поддерживает введение в систему
новых команд, определяемых пользователем и задаваемых в формате фир-
менного языка Tensilica Instruction Extension Language (TIEL).
Другим вариантом платформы являются реконфигурируемые SOPC, типич-
ный представитель которых — семейство АТ94К класса приборов FPSLIC
фирмы Atmel или реконфигурируемый коммуникационный процессор
Reconfigurable Communications Processor (RCP) CS2000 фирмы Chameleon
Systems Inc. (www.chameleonsystems.com).
Представители фирмы STMicroelectronics, Geneva (www.isdmag.com /story

/oeg20010228s0084) предлагают вариант гибкого ПБ -проектирования в рам-
ках консорциума Virtual Socet Interchange Alliance (VSIA), активным членом
которого является STMicro.
Технологию конфигурируемой SOC платформенно -базированного про-
ектирования активно разрабатывают и представители фирмы Palmchip
(www.palmchip.com)
Рис. 2.33. Верификация в платформенно -базированном проектировании

Одно из интересных решений проблемы верификации предлагает фирма

Quickturn Design System (www.quickturn.com) в своей разработке под названи-
ем Rapid Prototyping System (RPS). RPS представляет собой реконфигури -
руемую прототипную систему, содержащую индивидуальные логические
блоки, или IP -core. Блоки оформлены в форме небольших плат расширения
PC, называемых платы ядер и коммутируемых на общей плате, собственно и
являющейся RPS. На одной коммуникационной плате может размещаться
до 30 плат ядер, .каждая из которых может содержать IP в форме bonded -out
core, реальным кристаллом или SW -моделью, помещенной в FPGA. Про-
цедура верификации при ориентации на продукцию фирмы Quickturn Design
System может иметь вид, представленный на рис. 2.33.
Несмотря на обилие приведенных выше работ в плане создания САПР для
со -проектирования, со -верификации и со -моделирования, следует иметь в
виду, что, в основном, это еще поисковые исследовательские работы. Какие
проектные средства получат наиболее широкое распространение в будущем
предсказать достаточно трудно, поскольку успех тех или иных решений ле-
жит в плоскости пересечения различных требований, возможностей и вос-
требованности.
2.6. Некоторые аспекты

технологии производства систем с ПЛИС
Важнейшей задачей, встающей перед разработчиками современной элек-
тронной аппаратуры, является создание (или использование готового) тех-
нологического инструментария и методологии его применения для различ-
ных этапов жизни электронного изделия. Важность этих вопросов связана с
тем, что системная верификация и генерация тестовых последовательностей
может требовать до 70% проектного времени. Традиционно выделяются сле-
дующие этапы, связанные с разработкой и использованием специального
технологического оборудования: макетирование проекта, изготовление опыт-
ных образцов, изготовление серийных образцов, модификация и замена
устаревших версий изделия. Каждый из этапов характеризуется как специ-
фическим перечнем задач, так и требуемым инструментарием, специальной
квалификацией персонала и методологией работы. На современном уровне
развития технологии разработки электронных компонентов необходимость
применения специального технологического оборудования смещается в об-
ласть все более ранних этапов проектирования. Теперь даже не всегда про-
сто различить, где инструментарий для проектирования, а где части проек-
тируемого изделия.
Уже на этапе спецификации проекта разработчик должен заложить в буду-
щую конструкцию целый ряд технологических "зацепок", отсутствие кото-
рых на более поздних этапах может оказать крайне негативное влияние.
Задачей макетирования является проверка реализуемости выбранного спосо-

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

большими объемами производства. Поэтому для отечественных разработчи-
ков более характерен подход, предусматривающий большие людские и вре-
менные трудозатраты и меньшие затраты на исследовательское оборудование.
В такой ситуации предпочтительным оказывается применение оборудова-
ния, обеспечивающего возможность решить самый широкий спектр задач за
счет простых перенастроек. Включение в состав технологического оборудо-
вания прототипных плат, построенных на БИС с конфигурируемой структу-
рой, представляется перспективным и относительно дешевым методом дос-
тижения сформулированной цели.
Рассмотренные этапы проектирования серьезно тормозят появление на
рынке новой продукции, поэтому современные идеи, методы, элементная
база и отладочный инструментарий направлены на форсирование работ на
этих этапах. Элементы — это схемы с конфигурируемой структурой и "сис-
темы на кристалле", уже рассмотренные в гл. 1. Идеи — различные варианты
расширения возможностей JTAG -интерфейса, граничного сканирования,
методы со-проектирования и со-верификации. Отладочный инструмента-
рий — различные виды программного обеспечения, позволяющие оценить
интересующие характеристики системы, создать аппаратуру, имеющую уп-
рощенные процедуры ее тестирования, библиотеки и методики, ориентиро-
ванные на современные методы тестирования, различные типы оценочных и
отладочных плат.
Приступая к рассмотрению вопросов упрощения процедуры тестирования
аппаратуры, следует сразу четко определить цели, средства и назначение
тестовой процедуры. Ключевыми моментами являются:
- средства тестирования проекта (верификация, наблюдаемость);
- средства тестирования создаваемой БИС;
- выпуск пригодных к тестированию приборов и средств их тестирования;
- создание и контроль тестового оборудования;
- генерация тестовых последовательностей.
Здесь следует подчеркнуть, что попытка объединить в одном тестовом обо-
рудовании и одной тестовой процедуре и верификацию проекта, и локали-
зацию неисправностей может привести разработчика к значительным вре-
менным потерям.
Существенных выгод, получаемых как на этапе отладки опытных образцов,
так и на этапе выпуска серийной продукции, можно достичь за счет ориен-
тации на современные методики и, прежде всего, методы, ориентированные
на применение JTAG -интерфейса.
Поэтому и рассмотрим идеи, заложенные в стандарт интерфейса, аппарату-
ру, связанную с ним, а также методику использования этих средств на раз -
ных этапах разработки. Заметим, что эти принципы широко поддерживают-

ся современными САПР.
2.6.1. JTAG -интерфейс

Предпосылки возникновения
Методы и средства отладки устройств, содержащих современные БИС, пре-
терпели за последние десятилетия существенные изменения. К середине
70 -х годов используемые методы визуального, а в лучшем случае, ручного
тестирования межсоединений печатных плат, особенно при крупносерий-
ном производстве, полностью себя исчерпали. Широкое распространение
получило структурное тестирование печатных плат, выполняемое с привле-
чением методов технологии "ложе щупов" (в английской литературе — bed of
nails). Эта технология базируется на физическом доступе тестирующей аппа-
ратуры к контролируемой плате с помощью механических щупов (подпру-
жиненных контактов), прижимаемых к печатному монтажу. Идею метода
можно понять из рис. 2.34.
Входной Кристалл ИС Проходной Корп Выходной

контакт ИС провод контакт ИС
• Металлический
проводник
на стороне монтажа
Реакция Тестовое воздействие Резкая
Рис. 2.34. Тестирование на основании метода контактирующих щупов
Технология выдвигает специфические требования к конструкции печатных

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

цепочка, как правило, содержит достаточно много разветвлений, что далеко
не всегда позволяет этим способом однозначно определить действительное
состояние межсоединений. Изготовление тестирующего ложа из контактных
щупов может быть экономически оправданным только при промышленном
и серийном выпуске печатных плат. Поэтому раньше при невыполнении
любого из перечисленных условий приходилось довольствоваться методами
ручного просмотра и индивидуального ручного контроля соединений.
Необходимость изменения технологии тестирования печатных плат (причем,
как непосредственно после изготовления печатной подложки, так и после
установки на нее навесных элементов и их пайки) возникла не только из -за
вышеперечисленных неудобств, но из -за того, что:
- резко возросла цена погрешности изготовления печатных плат или мон-
тажа устанавливаемых на них достаточно дорогих БИС (даже в случаях
единичного изготовления). При этом произошло увеличение вероятности
отказов, связанное с уменьшением физических размеров как контактных
площадок для ножек БИС, так и других последствий высокоплотного
размещения БИС на печатных подложках;
- сегодня изготовление ориентируется на многослойные печатные платы,
используются БИС с технологией SMD (surface mount device) и, как
следствие, применяется двусторонняя установка элементов, контактные
площадки (при числе контактов современных БИС, превышающих 500)
размещаются под корпусом БИС (корпуса типа Ball Grid Array (BGA) и
Fine Line BGA);
- появилась возможность более широкого применения встраиваемых в
БИС специальных тестирующих фрагментов (затраты на добавление тес-
тирующих элементов существенно меньше затрат на настройку). При
этом процедура разработки последовательности тестирования и органи-
зация процесса тестирования должны учитывать новые возможности со-
временной элементной базы (в том числе специфические возможности
микросхем программируемой логики).
Современные системы оказываются исключительно сложными, например,
телекоммуникационные и сетевые приложения требуют разработки плат с
числом внутренних соединений более 5 тысяч. Такое количество цепей на
одной печатной подложке кладет практический предел для применения
коммерческого автоматизированного оборудования Automatic Test Equipment
(ATE). Методы граничного сканирования, рассматриваемые ниже, позволя-
ют вводить практически неограниченное количество виртуальных тестовых
каналов и, тем самым, снимают указанную проблему.
Сегодня каждый серьезный производитель телекоммуникационного, сете-
вого и другого аналогичного оборудования, ориентирующийся на сверх -
плотный монтаж многоконтактных БИС, должен опираться в своих проек-

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

Исторически интерфейс JTAG (Joint Test Action Group) появился как разви-
тие работ европейской группы (JETAG) исследователей проблем разработки
пригодной для тестирования аппаратуры в рамках специальной междуна-
родной группы, созданной по инициативе фирмы Texas Instrument, для вы-
работки стандарта на производство пригодных для тестирования БИС. Ре-
зультатом работы этой группы явился принятый в 1990 году стандарт ШЕЕ
Std. 1149.1 и его усовершенствованная версия стандарт IEEE Std.1149.la
(1993 год).
Предложенный стандарт имел два различных аспекта. Один состоял в разра-
ботке протокола и принципов обмена информацией между БИС, соединен-
ными в последовательную цепочку. В дальнейшем для определения этого
аспекта стандарта будем пользоваться термином "транспортный механизм".
А другой — в специальной (ориентированной на тестирование) организации
связи между основными схемами кристалла БИС и ее внешними контакта-
ми. Такая организация этой связи позволяет передавать значения сигналов
на выходных контактах в транспортный механизм цепочки и наоборот. Это
дает возможность использовать границы БИС для задач тестирования их
межсоединений без физического доступа к каждому ее выводу. Такой под-
ход получил название метода граничного сканирования (Boundary Scan
Testing, BST). Термин "граничное сканирование" представляется более точно
соответствующим задаче сканирования состояния границы между основны-
ми элементами БИС и оборудованием, расположенным вне БИС, чем ис-
пользуемый иногда термин "периферийное сканирование".
Рассмотрим более детально идеи метода граничного сканирования. На
рис. 2.35 схематически показан вариант подачи стимулов и снятия реакций
с "виртуальных" щупов, которые находятся на границах кристалла и конст-
руктивно входят в состав БИС.
Рис. 2.36 показывает структурную организацию БИС, поддерживающей метод
BST, и позволяет понять основную концепцию граничного сканирования.
Металлический Кристалл ИС Проходной Корпус ИС Выходной

проводник провод контакт ИС
на стороне ИС
Входной Тестовое
контакт ИС воздействие
Металлический
проводник Переходное Печатная
на стороне монтажа отверстие плата
Рис. 2.35. Внешний вид печатной платы с БИС, поддерживающими

метод граничного сканирования
Ячейки сканирования (Boundary Scan Cells, BSC) размещены между каждым

внешним выводом микросхемы и схемами кристалла, образующими собст-
венно БИС. Ячейки, с одной стороны, обеспечивают прием, сохранение или
выдачу тестовой информации JTAG -цепочки, а с другой — различные ре-
жимы взаимодействия между внешними контактами БИС, запоминающими
триггерами ячейки BSC и основными (внутренними) схемами кристалла.
Реализация команд тестирования базируется на соответствии длины регист-
ров приема/передачи информации (числа BSC -ячеек) и числа тестируемых
контактов БИС, а также на настройке взаимодействия разрядов этих ре-
гистров с внутренней структурой БИС или состоянием внешних контактов
БИС.
Метод BST задумывался для выполнения следующих тестовых процедур:
- проверки функциональной работоспособности БИС с помощью встроен-
ных в них тестовых цепей;
- проверки качества соединений между контактами различных БИС, смон-
тированных на печатной плате;
- считывания или установки сигналов на выходных контактах БИС в
штатном режиме работы БИС.
Выполнение тестовых процедур предполагает совместную работу трех ос-
новных компонентов:
- источника тестовых команд и данных (тестового прибора), которым
обычно является программа ПК. Этот же ПК тогда выступает и в качест-
ве анализатора результатов тестирования;
Граница кристалла
Г Тестовые данные
Основные
схемы кристалла
ТОО
Схема управления JTAG -интерфейсом
Рис. 2.36. Организация БИС, использующей метод граничного сканирования
- механизма информационной связи тестируемых БИС и тестирующего

ПК. Транспортный механизм интерфейса JTAQ как раз и предусматрива-
ет последовательное перемещение тестовых команд и данных от выход-
ных цепей ПК через цепочку последовательно соединенных БИС к вход-
ной цепи ПК;
- схем управления JTAG -интерфейсом, встроенных в каждую тестируемую
БИС и обеспечивающих соответствующую интерпретацию BSC -ячейками
тестовых команд ПК (реализация собственно метода граничного скани-

рования). Если предполагается тестирование работоспособности внут-
ренних схем отдельных БИС печатной платы, то в архитектуру БИС
должны быть дополнительно встроены аппаратура и специальные тесто-
вые процедуры самотестирования Bilt In Self Test (BIST). Тогда запуск
этой процедуры (автоматически при включении питания или/и по подаче
внешней команды) позволит судить о работоспособности внутренних
схем БИС. Информация об исправности или неисправности БИС будет
передаваться по линиям JTAG -интерфейса.
Правильное понимание организации тестовых процедур предполагает рас-
смотрение взаимодействия всех трех компонентов. Тестовый прибор являет-
ся не только источником всех тестовых процедур, но и устройством, задаю-
щим и синхронизирующим любые действия в цепочке и в тестируемых при-
борах. Многие особенности организации работы 'тестового прибора и
построения схем управления JTAG -интерфейсом отдельных БИС определя-
ются организацией транспортного механизма. Вместе с тем, реализуемые
ПК тестовые эксперименты определяются возможностями, заложенными в
структуру отдельных БИС. Поэтому дальнейшее рассмотрение идет от
транспортного механизма к анализу тестовых возможностей отдельных БИС
и далее к комплексной процедуре тестирования печатной платы.
Транспортный механизм JTAG -интерфейса

Интерфейс JTAG проектировался для организации информационной связи
между произвольным количеством БИС на печатной плате, в приборе и т. д.
Основное требование при этом состояло в минимизации числа контактов
БИС, необходимого для организации информационного обмена. Обычно
используется четыре (реже пять) выделенных для JTAG -интерфейса контак-
та БИС. Эти контакты образуют так называемый порт доступа (Test Access
Port, TAP) контроллера управления портом доступа (ТАР Controller).
Контакты порта доступа:
- ТСК (Test Clock Input) — синхронизация передачи данных и команд;
- TMS (Test Mode Select) — выбор режима передачи (считывание по пе-
реднему фронту СК);
- TDI (Test Data Input) — вход данных и команд (считывание по переднему
фронту ТСК);
- TDO (Test Data Output) — выход данных, команд или состояния
(изменение по заднему фронту ТСК);
- TRST (Test ReSeT) — сброс в исходное состояние контроллера (ТАР
Controller).
Если на печатной плате или в устройстве установлено несколько БИС, под-
держивающих JTAG -интерфейс, то эти схемы могут быть объединены в так
называемую JTAG -цепочку (рис. 2.37).
Рис. 2.37. Структура JTAG -цепочки
Особенностью исполнения любых действий в цепочке является последова-

тельная форма передачи по ней команд и данных. Устройство управления
JTAG -цепочкой (входящее в состав тестирующего прибора) путем управле-
ния состояниями всего двух контактов TMS и ТСК может устанавливать
автоматы ТАР -контроллеров всех БИС в любое требуемое состояние — ис-
ходное состояние, загрузки заданных команд в БИС цепочки, загрузки тре-
буемых данных в регистры или чтения данных из них. В режимах передачи
команд или данных каждому импульсу ТСК соответствует сдвиг на один
разряд информации в совокупности регистров, расположенных в момент
передачи от выходного контакта TDO тестирующего прибора до его же
входного контакта TDI. Соединение нескольких БИС в последовательную
цепочку заставляет, если необходимо, настроить одну из БИС цепочки на
выполнение определенной команды, образовать и вдвинуть в цепочку по-
следовательность битов с длиной, соответствующей набору команд для всех
БИС цепочки. Аналогично, если требуется передать данные в определенную
БИС цепочки, длина цепочки последовательности битов должна соответст-
вовать совокупной длине сканирующих регистров БИС цепочки.
Механизм граничного сканирования

Механизм граничного сканирования определяется организацией сканирую-
щих BSC -ячеек. Они обеспечивают реализацию перечисленных ниже режимов.
- Режимы самотестирования БИС, режимы программирования или чтения
внутрисхемных ЗУ и т. д. В этих режимах внешние контакты отключают-
ся от внутренних схем БИС, внутрь которой передается информация из
BSC -ячеек. Информация соответствует поступившим из JTAG -цепочки
командам или данным. Дальнейшая последовательность действий опре-
деляется поступившей командой и, в частности, может соответствовать
фиксации в ячейках BSC результирующей информации, которую также
можно передать в JTAG -цепочку.
- Режимы тестирования соединения БИС между собой. В этом режиме,
так же как и в предыдущем случае, внешние контакты отключаются от
внутренних схем БИС. Однако, в отличие от предыдущего режима, ин-

формация из ячеек BSC поступает не внутрь БИС, а наружу на ее внеш-
ние выходные контакты. Фиксация в ячейках BSC сигналов, посту-
пивших на входные (или двунаправленные) контакты, позволяет судить
о наличии или отсутствии реального соединения соответствующей груп-
пы контактов. Анализ этой информации осуществляется тестирующим
прибором путем ее передачи по JTAG -цепочке.
Режим тестирования штатной работы БИС. В этом режиме сохраняется
требуемое соединение внешних контактов БИС и внутренних схем кри-
сталла. Фиксация в ячейках BSC значений сигналов от всех контактов
БИС (в задаваемый из JTAG -цепочки момент времени) и последующая
их передача в тестирующий прибор позволяет проектировщику получить
интересующую его информацию. Значения внутренних сигналов тести-
руемой системы становятся известными без организации физического
доступа к контактам контролируемых БИС.
К следующей
ячейке
Вход
Фиксация Тестирование
От предыдущей
ячейки
Рис. 2.38. Структура сканирующей ячейки
Структурная схема сканирующих ячеек, позволяющих обеспечить реализа-

цию описанных выше режимов, в своей основе имеет вид, приведенный на
рис. 2.38. Схема содержит два мультиплексора и два D -триггера. Один из
них, Т1, является триггером в сдвигающем регистре данных JTAG -цепочки:
в состоянии ввода/вывода данных информация сдвигается по цепочке от
предыдущей к следующей BSC -ячейке. В этих же триггерах (при другом со-
стоянии входного мультиплексора) может фиксироваться входная информа-
ция BSC -ячеек. Триггер Т2 является триггером -защелкой, буферизирующим
данные основного сдвигающего регистра. Работа ячейки зависит от режима

использования. В рабочем режиме информация со входа ячейки передается
на выход, соединяя выходной контакт БИС с внутренними ресурсами БИС,
но при этом входная информация ячейки может фиксироваться в тригге-
ре Т1 сдвигающего регистра. В большинстве тестовых режимов вход и выход
ячейки разъединены. Входная информация ячейки может при этом фикси-
роваться в триггере Т1, а выходная информация будет определяться содер-
жимым триггера Т2.
Рис. 2.39. Структура устройства управления граничным сканированием
Интерпретацию команд, поступающих из тестирующего прибора, и на-

стройку БИС на выполнение определенной тестовой процедуры осуществ-
ляет устройство управления граничным сканированием (ГС). По сути, устрой-
ство управления является интерфейсным элементом между BSC -ячейками и
тестирующим прибором. Структурная схема устройства управления приве-
дена на рис. 2.39. Основные и обязательные элементы устройства управле-
ния это три регистра (регистр команд (IR), регистр пропуска (Bypass) и ре -
гистр данных (DR), выходной мультиплексор (MUX) и контроллер управле-

ния (ТАР Controller).
Основным регистром является регистр данных (часто называемый скани-
рующим регистром), образованный из последовательно соединенных триг-
геров Т1 (см. рис. 2.38) сканирующих ячеек. Регистр данных служит источ-
ником или приемником данных при выполнении в JTAG -цепочках любых
команд. С точки зрения устройства управления ГС регистр данных является
одним из трех сдвигающих регистров, включаемых между контактом для
подачи входной информации (контакт TDI) и контактом для получения вы-
ходной информации (контакт TDO).
Организацию различных режимов работы устройства управления ГС обеспе-
чивает дешифратор команд. В цикле записи команд в устройство управле-
ния ГС в регистре -защелке дешифратора команд фиксируется следующая
команда к исполнению. Код очередной команды вдвигается в сдвигающий
регистр — m -разрядный регистр команд (как правило, после включения пи-
тания в этот же регистр заносится идентификационный код БИС).
Одноразрядный сдвигающий регистр, регистр пропуска, предназначен для
ускорения работы JTAG -интерфейса. В режимах загрузки/выгрузки данных
регистр обеспечивает обходной путь для сдвигов многоразрядных данных,
не относящихся к данной БИС.
Команды граничного сканирования

Структура сканирующих ячеек и организация устройства управления гра-
ничным сканированием позволяют соотнести с каждой требуемой тестовой
процедурой выполнение определенной команды, поступающей из тести-
рующего прибора. Стандартом предусмотрена обязательность поддержания
четырех команд граничного сканирования: EXTEST, SAMPLE/PRELOAD,
BYPASS и INTEST. Вместе с тем, допускается введение дополнительных
команд, упрощающих работу с JTAG -цепочками или тестируемыми БИС.
Для решения задач самотестирования БИС предусмотрены две команды
стандарта JTAG — INTEST и RUNBIST. Они предназначены для запуска
процедуры автономного тестирования содержимого кристалла.
Команда RUNBIST производит тестирование кристалла без привлечения
каких -либо внешних данных. Выполнение команды приводит к запуску
встроенной в кристалл тестирующей схемы. Результаты процедуры тестиро-
вания заносятся в регистр DR. Данные, зафиксированные в регистре DR
после завершения команды, позволяют однозначно определить, исправна
БИС или нет.
Команда INTEST проверяет функционирование БИС путем подачи данных
от тестирующего прибора. Запуск процедуры самотестирования, основанной
на данных зафиксированных в регистрах сканирования DR, вызывает вы -
полнение тестовой процедуры основных схем кристалла. Завершение тесто-

вой процедуры приводит к фиксации в регистре DR результата тестирова-
ния, который позволяет однозначно определить, исправна БИС или нет.
Для тестирования внешних соединений БИС на печатной плате предусмот-
рено использование команды EXTEST. Стандарт оговаривает, что код опе-
рации этой команды должен содержать все нули. Исполнение команды
предполагает отключение внутренних схем кристалла от внешних контактов
(оно осуществляется установкой сигнала "тестирование" на рис. 2.38). Со-
стояния выходных контактов БИС определяются информацией, находящей-
ся в регистрах данных DR БИС. В начале выполнения команды в буферных
регистрах DR на фронте сигнала "захват" фиксируется состояние сигналов
на внешних контактах БИС, после этого в следующей фазе этой команды
зафиксированные данные (при включенном сигнале "сдвиг" на мультиплек-
соре 1) могут выдвигаться из БИС и замещаться вновь подаваемыми данны-
ми, и, наконец, на завершающей фазе команды, обновляется состояние ре-
гистров DR (а значит, и состояния выходных контактов БИС) на фронте
сигнала "фиксация". Хотя команда EXTEST позволяет производить тестиро-
вание межсоединений без привлечения каких -либо дополнительных команд,
чаще всего она используется совместно с нижерассматриваемой командой
SAMPLE/PRELOAD, выполняющей роль команды, загружающей информа-
цию в регистр данных.
Для контроля поведения БИС в рабочих режимах тестируемой системы стан-
дартом предусмотрено сканирование значений сигналов, присутствующих на
внешних контактах БИС. Эту задачу выполняет команда SAMPLE/PRELOAD.
Поскольку ее исполнение не предполагает отключение внутренних схем
кристалла от внешних контактов (инверсное состояние сигнала "тестиро-
вание" на рис. 2.38), то в начале выполнения команды в буферных регистрах
DR по фронту сигнала "захват" фиксируется состояние сигналов на внешних
контактах БИС. Значения этих сигналов соответствуют штатному режиму
работы БИС. Интерпретация содержания такого мгновенного "снимка со-
стояния" сигналов на границе тестируемой БИС зависит от состояния дру-
гих БИС, связанных с тестируемой. Если все БИС находятся в штатном ре-
жиме, то содержание "снимка" отражает протекание рабочих режимов в сис-
теме и обычно используется для целей отладки. Возможность задания
произвольной конфигурации тестируемой системы (одна группа БИС сис-
темы формирует тестовые выходные сигналы, а другая группа БИС находит-
ся в рабочем режиме), позволяет организовывать совместное тестирование
межсоединений и функционирования внутренних схем БИС.
Команды CLAMP и HIGHZ позволяют расширить возможности тестирова-
ния межсоединений или состояния и работоспособности выбираемых поль-
зователем групп БИС в проверяемой системе.
Команда HIGHZ переводит все выходные контакты управляемой БИС в
Z -состояние, а устройство управления ГС — в состояние BYPASS. При ми -
нимальности аппаратных затрат ресурсов БИС на реализацию команды ее

применение особенно эффективно при тестировании систем с шинной ор-
ганизацией. Для БИС микропроцессоров реализация такого состояния их
выходных контактов носит название "In -Circuit emulation" и упрощает
использование внешних отладочных эмуляционных средств.
Исполнение команды CLAMP предполагает отключение внутренних схем
кристалла от внешних контактов, ее выполнение приводит к установке на
выходных контактах БИС значений, соответствующих данным, зафиксиро-
ванным в регистре DR, и переводу устройства управления ГС в состояние
BYPASS.
Команда BYPASS позволяет установить устройство управления JTAG -
интерфейсом в состояние сквозного пропуска данных через БИС. Стандар-
том предусмотрено, что код операции команды должен содержать все еди-
ницы. Команда соответствует отключению БИС от процедур тестирования
без изъятия ее из JTAG -цепочки.
Устройство управления JTAG -интерфейса

Основу любого устройства управления JTAG -командами составляет кон-
троллер тестирующего порта доступа (ТАР Controller). Поведением контрол-
лера управляет синхронный конечный автомат, состояния и переходы ко-
торого определяются значениями управляющего сигнала JTAG -цепочки
(сигналом TMS, фиксируемым по переднему фронту тактового сигнала це-
почки — ТСК). Контроллер формирует выходные .сигналы, управляющие
поведением BSC -ячеек, — сдвиг, захват, тестирование.
Диаграмма состояний автомата приведена на рис. 2.40. Условие перехода —
значение сигнала TMS — показано на диаграмме цифрами 0 или 1. В диа-
грамме состояний можно выделить четыре базовых фрагмента:
- состояние TEST -LOGIC_RESET (сброс логики тестирования);
- RUN -TEST\IDLE (состояние ожидания или выполнения внутренних
тестов);
- режим управления вводом/выводом данных (семь состояний от SELECT -
DR -SCAN до UPDATE -DR);
- режим управления вводом команд и чтения состояния (семь состояний
от SELECT -IR -SCAN до UPDATE -IR).
Основу режимов управления образуют три состояния: состояние фиксации
в выдвигаемых регистрах данных на момент начала фрагмента (состояние
CAPTURE -DR или CAPTURE -IR), состояние выдачи из БИС зафиксиро-
ванной информации и получения новой информации в БИС (состояние
SHIFT -DR или SHIFT -IR) и состояние фиксации новой информации
(состояние UPDATE -DR или UPDATE -IR) на момент завершения фрагмен -
та. Состояния PAUSE -DR и PAUSE -IR позволяют приостанавливать про-

движение информации в цепочке на произвольное количество тактов син-
хронизации (например, для выполнения каких -либо действий в БИС с
внешним тактированием).
Рис. 2.40. Диаграмма состояний автомата контроллера
Состояния EXIT1 -DR, EXIT2 -DR, EXIT1 -IR и EXIT2 -IR имеют вспомога-
тельный характер (в том числе для реализации альтернативных переходов),
но могут оказаться полезными при реализации устройств управления рас-
ширенных вариантов интерфейса JTAG, соответствующих новым вводимым
командам.
Стандарты, связанные с JTAG -интерфейсом

Для широкого использования идей и методов граничного сканирования BST
и принципов организации JTAG -интерфейса предложения различных фирм
были включены в ряд стандартов. Наличие стандартов позволяет организо-
вать не только обмен информацией между разработчиками БИС, разработ-
чиками тестирующих средств и проектировщиками аппаратуры, но и обес-
печить согласованную совместную работу тестируемой аппаратуры и тести-
рующего программного обеспечения. Стандарты позволяют однообразно
описывать пользовательские системы, поддерживающие ГС и JTAG -интер -
фейс. К настоящему времени наибольшее распространение получили рас-
сматриваемые ниже стандарты.
Язык BSDL
BSDL — Boundary -Scan Description Language — язык описания организации
и архитектуры граничного сканирования в рамках одиночной БИС. Язык
входит в состав стандарта IEEE Std. 1149.1 и построен как подмножество
языка VHDL. Одной из основных задач, возлагаемых на язык, является соз-
дание программных средств, автоматизирующих процесс создания тестов.
Файлы в формате языка описывают соответствие логических сигналов и фи-
зических контактов, набор команд, поддерживаемых ТАР контроллером,
размер сканирующих JTAG -цепочек, соответствие порядка ячеек ГС в це-
почке номеру внешнего контакта и тип управления внешним контактом.
Язык HSDL
HSDL — Hierarchical Scan Description Language (разработка фирмы Texas
Instruments) — язык, ориентированный на описание информационных по-
токов в группе БИС, объединенных JTAG -интерфейсом. HSDL является
расширением языка BSDL, совместим с ним, вводит в состав стандарта
IEEE Std. 1149.1.а и построен как подмножество языка VHDL. Средства язы-
ка позволяют определить JTAG -цепочку любого уровня, т. е. последователь-
ность БИС, объединяемых в модуле, в системе или на плате, а также допус-
кают описание динамических или реконфигурируемых цепочек. Язык по-
зволяет описать свойства как отдельной БИС, так и группы БИС внутри
тестируемого модуля Unit Under Test (UUT). Модуль — это элемент любого
уровня архитектуры выше уровня БИС (может быть платой или системой).
Язык позволяет:
- создавать определяемые пользователем имена для описания команд ска-
нирования и групп данных;
- объединять отдельные биты тестовых последовательностей в легко управ-
ляемые подмножества битов с назначаемыми пользователем именами;
- задавать условия разнообразных изменений, определяя свойства цепочек
сканирования (статических, динамических или внешних относительно
UUT).
Основной файл BSDL приборного уровня может быть аргументом соответ-

ствующего предложения файла HSDL и использоваться для организации
интерактивной отладки или верификации тестируемого модуля UUT.
Язык SVF
Язык Serial Vector Format (SVF) был разработан фирмами Texas Instruments
и Teradyne в 1991 году. Широко используется для описания тестовых векто-
ров, посылаемых в приборы цепочки, для получения результирующих дан-
ных и маскирования любых данных. Необходимость введения формата дик-
товалась желанием фирм иметь шаблон данных, легко воспринимаемый
широким спектром моделирующих и тестирующих программ и оборудова-
ния. Основным требованием являлась возможность использования языка на
всех этапах проектирования от проектной верификации до окончательной
диагностики.
Другие стандарты
Ряд фирм (например, ASSET InterTech, Inc.) разработали форматы макро-
языков, существенно упрощающих написание различных программ. Макро-
языки позволяют писать программы как для управления различными систе-
мами, так и для контроля и тестирования входящего в них оборудования.
Основным достоинством макроязыков является способность расширять свои
собственные возможности путем введения и определения новых понятий.
Большая избыточность тестовых или загрузочных кодовых последовательно-
стей, циркулирующих в JTAG -цепочках, и, как следствие последовательного
характера передачи, значительные временные затраты на обмен, заставили
разработчиков искать варианты сжатия информации. И хотя издержками
такого подхода является необходимость введения языкового стандарта на
метод сжатия, установка аппаратуры, свертывающей и развертывающей по-
следовательности, целесообразность такого подхода оказалась очевидной.
Все три составляющих метода сжатия получают все большее распростране-
ние. Появился стандарт на язык JAM, структуры и конструкции сверты-
вающей и развертывающей аппаратуры типа JAM Player.
2.6.2. Проблемы и методология создания

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

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

при создании проекта
Стремление разработчиков использовать в своих проектах возможности,
предоставляемые JTAG -интерфейсом (и граничным сканированием, в част-
ности), должно начинаться с первых шагов проектирования.
Если тестирование проекта предполагается строить на базе JTAG -интер -
фейса, то, прежде всего, необходим выбор элементов, обеспечивающих
транспортный механизм интерфейса.
Эти элементы должны иметь возможность подключаться к соответствующе-
му оборудованию. Транспортная система может быть организована по раз-
ному — от простой цепочки (одиночная БИС) до сложных адресуемых,
перестраиваемых и реконфигурируемых цепочек. Существует достаточно
большое количество фирм, которые предоставляют широкую номенклатуру
БИС данного целевого направления. Для более удобной организации скани-
рования может быть использована, например, специальная ИС адресуемого
скан -порта SN74LVT8980, предназначенная для установки на отдельную
плату, а для системного уровня может быть использована ИС контроллера
тестовой шины SN74LVT8996.
После того, как проектировщик определил средства и способы подачи и по-
лучения JTAG -последовательностей, он переходит к решению вопросов
встраивания средств граничного сканирования или самотестирования в сис-
тему (это может быть отдельная БИС, печатная плата или набор таких плат).
Если тестирование межсоединений в готовой продукции планируется по-
строить на основе идей граничного сканирования, то в системе (на плате)
должен быть установлен хотя бы один элемент с возможностью ГС. Интег-
ральные схемы, поддерживающие граничное сканирование, могут быть лю-
бого типа — стандартными, полузаказными или полностью заказными.
Практически любой тип стандартной продукции имеет альтернативные ва-
рианты реализации, которые, в отличие от стандартных, включают средства
ГС. Подавляющее число выпускаемых в настоящее время БИС ПЛ поддер-
живает методы ГС либо в варианте "жестко" встроенной реализации (HW -
соге), либо в форме стандартных фрагментов, встраиваемых в ходе компи-
ляции проекта (SW -core). Для реализации методов ГС в состав стандартных
библиотек фирм, выпускающих схемы класса ASIC по технологии стандарт-
ных ячеек, включаются контроллеры JTAG -интерфейса и регистры ГС. Если
разрабатываются полностью заказные БИС или схемы ASIC, изготавливае-
мые по технологии БМК, то появляется необходимость добавления к опи-
санию проекта средств тестирования. Добавляемые фрагменты, как правило,
выбираются проектировщиком со способом описания, принятым в основ-
ном проекте. Распространение получили описания на уровне регистровых
передач и на уровне языков высокого уровня.
Наличие во многих приложениях фрагментов, для которых затруднена или

экономически не оправдана реализация тестирования на принципах ГС, за-
ставляет разработчиков анализировать возможность архитектурного по-
строения системы, позволяющего охватывать тестированием и те фрагменты
системы, в которых нет элементов, поддерживающих методы ГС. В настоя-
щее время интенсивно разрабатываются формальные методы построения
систем с возможностью контроля фрагментов, не охваченных ГС.
Другим направлением создания надежной продукции (не отменяющим, а
дополняющим методы граничного сканирования, и также опирающимся
на транспортные механизмы интерфейса JTAG) является направление, свя-
занное с таким проектированием БИС, при котором в них оказываются
встроенными средства самотестирования Built -In -Self -Test (BIST). Достаточ-
но большое число фирм занимается этим направлением, и они предлагают
средства, позволяющие автоматизировать создание как аппаратуры, так и
самих тестирующих последовательностей. Наибольших успехов при этом
(как и следовало ожидать) удалось достичь в разработке средств, тестирую-
щих работоспособность регулярных структур, например блоков ОЗУ.
Фирмы, разрабатывающие тестовые фрагменты Hardcore или Softcore (в за-
висимости от технологии изготовления проектируемой БИС), не только пе-
редают их в форме интеллектуальной собственности IP, но и одновременно
с этим поставляют оборудование и программное обеспечение, существенно
ускоряющие процесс проектирования. САПР таких фирм, как Analogy,
Cadence, Intusoft, Mentor Graphics и Synopsys позволяют не только встраи-
вать эти фрагменты в проекты, но и учитывают их в синтезирующих и мо-
делирующих пакетах. В результате разработчик имеет возможность выпол-
нить полный цикл проектных верификационных работ, убеждающих его,
что добавление тестовых фрагментов не привело к искажению штатной ра-
боты проекта.
Работы, выполняемые
при тестировании готовой продукции
После получения готовой продукции в форме БИС или печатной платы раз-
работчик оказывается перед необходимостью выполнения настроечных и
отладочных работ, для ускорения и упрощения которых и вводились средст-
ва, ориентированные на использование методов и средств граничного ска-
нирования и JTAG -интерфейса.
Процедура отладки и привлекаемое для этого оборудование, прежде всего,
определяются видом тестируемой продукции. Необходимо разделять работы,
выполняемые на этапе отладки лабораторных макетов и серийных образцов
продукции (хотя и то, и другое базируется на возможностях JTAG -ин-
терфейса). В простейших случаях, для проведения экспериментов с лабора-
торными образцами или первыми образцами опытных партий процедура
тестирования может опираться на обычный ПК, снабженный соответст-

вующим программным обеспечением и имеющий загрузочный кабель, под-
ключенный, например, к его параллельному порту. Промышленные уста-
новки, предназначенные для тестирования серийной продукции, представ-
ляют собой достаточно большие и дорогие агрегаты, а целесообразность их
применения диктуется большой тиражностью выпускаемой продукции, что,
в свою очередь, требует сокращения времени, необходимого для тестирова-
ния оборудования.
Рассмотрим сценарий отладки лабораторного макета. Сложность проведения
экспериментальных работ связана с тем, что отклонение поведения макета
от ожидаемого может быть связано как с дефектом его изготовления, так и с
ошибкой самого проекта. Более того, в ряде случаев может оказаться де-
фектным само тестирующее оборудование. Поэтому процедура выяснения
причины отклонения оказывается более сложной, чем процедура, исполь-
зуемая при анализе серийной продукции, когда причина отклонений обу-
словлена только технологическими дефектами. Для проведения эксперимен-
тов проектировщик может пользоваться простейшими тестирующими про-
граммами, опирающимися на ресурсы граничного сканирования и JTAG -
интерфейса.
На первом шаге работ проектировщик должен убедиться в работоспособно-
сти элементов, образующих JTAG -цепочку. Тестовые программы автомати-
чески сравнивают идентификационные коды ИС, полученные из цепочки,
с кодами, взятыми из справочных данных фирм -производителей ИС
(фирмы поставляют такие файлы с расширением bsd). Отсутствие данных из
цепочки должно заставить проектировщика использовать программы, лока-
лизующие причину и место нарушения, а несоответствие данных требует
анализа и адекватных действий.
На следующем шаге могут использоваться (если они включены в состав ИС)
встроенные средства самотестирования. Отладочное оборудование при этом
должно через JTAG -интерфейс инициировать процедуры самопроверки в
проверяемых ИС. Информация, полученная из JTAG -интерфейса, после
завершения процедуры самотестирования позволяет убедиться в работоспо-
собности схем, входящих в отлаживаемую систему.
После проверки работоспособности отдельных элементов печатной платы
можно переходить к тестированию соединений этих элементов между собой.
Если все элементы цепочки работают исправно, и в цепочке имеются ИС,
поддерживающие команды и методы граничного сканирования, то сущест-
вующие программы могут автоматически проверять исправность межсоеди-
нений и определять места нарушения контактов или наличия паразитных
соединений. При хорошей организации тестовых последовательностей воз-
можна локализация существующей неисправности с точностью до отдель-
ной сканирующей ячейки. Проверяться могут не только соединения, распо-
ложенные между сканируемыми контактами, но и соединения, разделенные
достаточно простыми логическими цепями, не поддерживающими метод

ГС. В последнем случае одновременно проверяются соединения и функцио-
нирование этих цепей.
Убедившись в отсутствии ошибок межсоединений, проектировщик может
переходить к тестированию оборудования, не поддерживающего ГС. Про-
верка работоспособности такого оборудования может выполняться на ресур-
сах JTAG -интерфейса, если проверяемые фрагменты своими входными и
выходными цепями соединены с контактами сканируемых ИС. Эффектив-
ность тестирования определяется всей совокупностью задействованных эле-
ментов. Структура тестируемого фрагмента, места его подключения к источ-
никам тестирующих сигналов и места снятия с него контрольных сигналов,
организация теста — все эти вопросы должны решаться проектировщиком.
Не в последнюю очередь рациональный выбор этих составляющих опреде-
ляется возможностями их автоматизации.
Различные фирмы предлагают здесь огромный спектр услуг, и в частности
комплексы аппаратуры, программного и методического обеспечения, отли-
чающиеся объемом и уровнем решения проблем, возникающих при автома-
тизации различных этапов проектирования пригодной к тестированию ап-
паратуры. Наибольшее распространение получили пакеты, автоматически
генерирующие тестовые последовательности и шаблоны правильных реак-
ций. Продукция различных фирм отличается и допустимой сложностью тес-
тируемых объектов, и оборудованием, используемым для организации тес-
тирования. Сложнее дело с пакетами, автоматизирующими процесс синтеза
такой структуры фрагмента, которая может быть эффективно протестирована.
Хотя построение аппаратуры, допускающей проведение тестирования в
процессе ее эксплуатации, несомненно, является перспективным, удорожа-
ние при этом самой аппаратуры и процедуры ее проектирования заставляет
рассматривать и альтернативные варианты. Если аппаратура отлаживаемой
системы дает возможность изменения или неоднократной загрузки инфор-
мации в программируемые фрагменты системы, то в этих фрагментах на
этапе проверки работоспособности оборудования может размещаться тесто-
вая информация. Раньше тестовые примеры размещались в памяти команд
микропроцессорных систем, и это существенно упрощало проведение тес-
тирования. Появление в современных системах приборов с программируе-
мой структурой расширяет этот подход. Занесение в память конфигурации
ПЛИС структуры тестового оборудования может производиться в любой
требуемый момент. Поэтому конфигурация, соответствующая тестовым экс-
периментам, может применяться для отладки не только опытных образцов,
но и серийной продукции. Тестирование опытньгх и серийных образцов,
естественно, различаются полнотой, длительностью проведения и т. д.
После того, как разработчик убедился в правильности монтажных соедине-
ний и работоспособности отдельных используемых ИС, в микросхемы па-
мяти программируемых и конфигурируемых приборов может заноситься
рабочая информация. Наступает этап проверки правильности функционирова -
ния проекта в целом. Методика проведения работ на этом этапе в основных

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

штабе времени. Наиболее сложной задачей здесь является реализация
цепей, определяющих момент времени, интересующий проектировщика,
и формирующих сигнал, соответствующий этому моменту.
2. Симуляция любых комбинаций сигналов на сканируемых контактах,
причем сигналы могут быть направлены как наружу, так и внутрь БИС.
Создаваемая комбинация сигналов (во времени и в пространстве) может
быть и такой, какая не бывает в штатном режиме работы системы (или,
по крайней мере, предполагается, что в системе реально такой комбина-
ции не может быть). Подобная возможность позволяет экспериментально
определить реакцию системы на "нештатную" комбинацию сигналов.
3. Если сигналы тактового генератора системы в состоянии управляться или
замещаться сигналами, формируемыми тестирующим оборудованием, а
проектировщика интересует в поведении отлаживаемой системы только
функциональная последовательность смены состояний, то частота подачи
тестирующей последовательности, передаваемой по JTAG -интерфейсу,
может быть соотнесена со скоростью съема данных из регистра гранич-
ного сканирования. Таким образом формируется полностью контроли-
руемая и управляемая тестовая процедура.
Совершенно очевидно, что эффективность рассмотренных выше методик
тестирования системы будет сильно зависеть от конструктивной реализации
проекта. В некоторых случаях только интерактивное участие проектировщи-
ка в создании тестирующих последовательностей обеспечивает увеличение
полноты тестирования. Например, проектировщик может ввести соединение
штатно неиспользуемого контакта БИС ПЛ с электрической цепью, которая
до того не могла быть протестирована. Наличие подобного соединения по-
зволяет при подаче тестовой последовательности на фиктивное соединение
добиться определенности тестирования.
После того, как проект на тестовых примерах заработал правильно и ста-
бильно, можно переходить к подготовке тестов для рабочих испытаний ап-
паратуры. Как уже отмечалось выше, требования к программам тестирова-
ния аппаратуры, в функциональной работоспособности которой практи-
чески отсутствуют сомнения, отличаются от требований, предъявляемым
к программам, тестирующим серийную продукцию. Соответственно, отли-
чаются аппаратные средства и САПР, привлекаемые для подготовки и про-
ведения экспериментов этого этапа работ.
2.6.3. Обзор средств поддержки JTAG -интерфейса

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

ваемые в выпускаемую продукцию и включающие: транспортные средства,
расширяющие возможности JTAG -интерфейса, интеллектуальные средства,
расширяющие возможности ГС, средства BIST, встраиваемые в СпИС и ИС.
Затем средства, образующие саму тестирующую аппаратуру.
И, наконец, программные средства, подготавливающие тестовые последова-
тельности, программные и аппаратные средства, организующие тестирова-
ние на уровне БИС, печатных плат или систем.
Аппаратная поддержка JTAG -интерфейса

Наибольшие усилия в части выпуска стандартной аппаратуры, обеспе-
чивающей работу с JTAG -интерфейсом, прикладываются фирмами Texas
Instrument (www.ti.com) и JTAG Technologies B.V. (www.jtag.com). Только TI
выпускает более 40 типов коммерческой продукции этого направления.
В том числе ИС, отличающиеся от стандартных только наличием встроен-
ных средств JTAG -интерфейса. Например, вместо обычных магистральных
приемопередатчиков (типа АП4, АП5, АП6) могут быть выбраны приемо-
передатчики фирмы Texas Instrument, поддерживающие режимы граничного
сканирования. Выбор предлагаемых ИС достаточно широк — могут быть
выбраны октальные приборы типа ВСТ и АВТ или ИС, предусматривающие
работу с шинами (18/20 бит) типа АВТ/АВТН для питающего напряжения
5 В или LVTH для напряжения 3,3 В.
Для поддержки расширенных вариантов транспортного механизма JTAG -ин-
терфейса фирма предлагает использовать ИС адресуемого скан -порта Addres-
sable Scan Port (ASP) типа SN74LVT8996, который обычно устанавливается
на отдельной плате, а для системного уровня встраивания — контроллер
тестовой шины embedded Test Bus Controller (eTBC) типа SN74LVT8980.
Фирмы -производители ПЛИС в большинстве выпускаемых схем предусмат-
ривают использование JTAG -интерфейса. Однако полнота поддержки
JTAG -интерфейса (число и типы поддерживаемых команд) коррелирована
со сложностью ПЛИС. Иногда приходится включать в проект схему PLD из
семейства БИС с превышением логической мощности по сравнению с тре-
буемой только из -за того, что она поддерживает необходимые команды гра-
ничного сканирования. У некоторых схем фирмы Xilinx элементы JTAG -
интерфейса в явном виде отсутствуют и являются опционными (при их
встраивании в структуру кристалла затрачиваются ресурсы PLD).
Направление деятельности ряда фирм — добавление фрагментов граничного
сканирования в базовую структуру проекта. Основные фрагменты — кон-
троллер тестового доступа и ячейки сканирующих регистров. Подобные
фрагменты могут встраиваться в подготовленный проект не только для
ПЛИС, но и при изготовлении проектов по заказной или полузаказной тех-

нологии.
Так, например, программный пакет фирмы Synopsys (САПР носит название
BSD Compiler) автоматизирует процедуру добавления фрагментов гранич-
ного сканирования к основному проекту, сопровождая ее выпуском тестов
для последующего тестирования конечной продукции. САПР BSD Compiler
позволяет автоматизировать процессы синтеза и верификации логики гра-
ничного сканирования в ИС, выпускаемых по заказной или полузаказной
технологии. Для синтеза BSD Compiler использует описание пользователь-
ского проекта на уровне регистровых передач (RTL) и добавляет требуемые
JTAG -компоненты из фирменной библиотеки (DesignWare). Затем САПР
автоматически проверяет комплексный проект на совместимость со стан-
дартом ШЕЕ 1149.1. И на последнем этапе автоматически создает файлы на
языке BSDL (Boundary Scan Description Language), предназначенные для
тестирования на уровне печатных плат и для генерации функциональных
и параметрических векторов для производственного тестирования.
Фирма Alternative System Concepts Inc., ASC (www.ascinc.com) предлагает па-
кет VBIT (VHDL Built Test), который позволяет проектировщику автомати-
чески вставлять средства JTAG -интерфейса в проекты высокой плотности,
написанные на языке VHDL, еще до начала их логического синтеза.
Другой разновидностью аппаратных добавлений, увеличивающих возможно-
сти тестирования БИС, является добавление к базовому проекту средств
встроенного самоконтроля (BIST). Работы по этому направлению характер-
ны для таких фирм, как Diagonal Systems, Inc. (www.diagonal.com), Fluence
Technology (www.fluence.com), Genesys Testware, InterHDL (www.interhdl.com),
LogicVision (www.Iogicvision.com) и Syntest. Фирмы выпускают средства, ав-
томатизирующие различные этапы проектирования. Проекты, предназна-
ченные для добавления средств BIST, могут использовать описание своей
структуры на одном из стандартных языков описания аппаратуры, таких как
Verilog, VHDL, EDIF или Spice. Продукция перечисленных фирм обеспечи-
вает добавление BIST -функций, автоматическую генерацию тестовых векто-
ров или моделирование отказов.
Одним из представителей, поддерживающих это направление, является фир-
ма LogicVision. Она предлагает широкий набор блоков IP, соответствующих
различным видам встраиваемой тестовой продукции. Тестовая продукция
поддерживает реализацию большого числа типичных приложений и содер-
жит в том числе такие средства, как:
- Memory BIST — встраиваемый IP -блок для встраиваемых динамических
и статических ОЗУ;
- 1C Memory BIST — законченное IP BIST -решение, представляющее со-
бой контроллер и тестирующее обрамление элементов ОЗУ, которое ав -
тематически генерируется как синтезируемый RTL -объект для проектов

на языках VHDL или Verilog;
- PLL BIST — встраиваемые элементы тестовых цепей для цепей фазового
управления Phase -Locked Loops;
- Logic BIST — встраиваемые фрагменты комбинационной логики.
Другим видом продукции этой фирмы является пакет Chip Test Assemble,
который создает и собирает всю тестовую инфраструктуру кристалла в соот-
ветствии со стандартом IEЕЕ 1149.1, включая контроллер и регистр гранич-
ного сканирования.
Программная поддержка тестирования

Естественно, что все описанные выше возможности реализуются в том слу-
чае, когда управление БИС, входящими в состав JTAG -цепочки, выполняет-
ся достаточно интеллектуальным контроллером, обеспечивающим подачу
предварительно разработанных тестовых последовательностей и контроль
последовательностей, получаемых в результате тестирования. Тестовые по-
следовательности, как правило, создаются специальным программным обес-
печением. Программное обеспечение, автоматизирующее процесс подготов-
ки тестовых последовательностей, опирается на систему межсоединений,
реализованных на плате и на тестирующие возможности БИС, расположен-
ных на этой плате.
Целый ряд фирм разрабатывает и поддерживает программные пакеты, авто-
матизирующие указанные выше тестовые процедуры. Предлагаются аппа-
ратно -программные комплексы, выполняющие загрузку тестовых последо-
вательностей, получение контролирующих последовательностей и анализ
полученных результатов. Среди этих фирм можно указать на фирмы ASSET
Intertech (www.asset -intertech.com), Corelis (www.corelis.com), GenRad, Inc.
(www.genrad.com), Flynn Systems Comporation (www.flynn.com), Hewlett -Pac-
kard.
Фирма JTAG Technologies B.V. предлагает, например, пакет JTAGLINK, ко-
торый обеспечивает прямое соединение между схемными редакторами ти-
повых САПР и средствами фирмы, предназначенными для автоматической
генерации тестов Automatic Test Pattern Generation (ATPG). Пакет обеспечи-
вает стыковку с большинством САПР — такими как Mentor Graphics,
Cadence, Viewlogic, OrCAD, Accel, P -CAD, Synopsis, Sunario и др.
Большинство фирм предлагает более простые (и, соответственно, более де-
шевые) пакеты. Например, фирма ACUGEN Software, Inc. (www.acugen.com)
выпускает программное обеспечение, выполняющее автоматическую гене-
рацию тестов Automatic Test Generation (ATG) для приборов программируе-
мой логики (PLD, EPLD, FPGA и небольших GATE Array), а также прибо-
ров, поддерживающих язык описания граничного сканирования BSDL.
Примером фирмы, предлагающей комплекс технических средств, является

фирма Teradyne (www.teradyne.com). Фирма разработала виртуальный тесто-
вый набор, включающий пять средств: Virtual Interconnect Test, Virtual
Component Cluster Test, Boundary Functional Test, Boundary -Scan Intelligent
Diagnostics и Access Analyzer. Первые четыре модуля, генерирующих тесты,
дают проектировщику свободу в выборе тестовой стратегии, базирующуюся
на его тестовых объектах и с различной степенью тестового доступа. Диаг-
ностический модуль быстро изолирует тестовую неисправность, идентифи-
цирует отказавший прибор, тип неисправности и вовлеченные цепи. Анали-
затор доступа обычно используется перед разводкой для помощи проекти-
ровщику разделить сканируемые и не сканируемые дефекты.
Комплексная организация поддержки тестирования

Как уже отмечалось, наибольших успехов при создании пригодных к тести-
рованию проектов Design -For -Testability (DFT) можно достичь, только со-
блюдая единство подхода ко всем составляющим процесса проектирования
и на всех этапах создания продукции.
Естественно, что такой подход могут предложить только крупные фирмы,
имеющие богатый опыт разработки и выпуска САПР. Примером фирм,
стоящих на позициях комплексного решения задачи проектирования при-
годной к тестированию аппаратуры, являются Mentor Graphics Corporation
(www.mentor.com) и Synopsys (www.synopsys.com).
Фирма Synopsys при производстве пригодных к тестированию БИС предла-
гает автоматизировать процесс проектирования, опираясь на последователь-
ную работу разработанных ею трех пакетов: DFT Compiler, BSD Compiler и
TetraMAX ATPG. Первый пакет поддерживает создание целевого проекта,
содержащего требуемые тестовые вставки, второй пакет синтезирует устрой-
ство, содержащее целевую систему, фрагменты, тестирующие ее работу и,
наконец, фрагменты, поддерживающие граничное сканирование, третий па-
кет, опираясь на результаты синтеза собранного проекта, автоматически ге-
нерирует тестовые последовательности Automatic -test -pattern -generation.
До настоящего времени синтез тестов для проектирования пригодных к тес-
тированию проектов выполнялся путем дополнения тестовых фрагментов
к основной части ASIC -проекта, и это приводило к тому, что улучшение
свойств пригодности к тестированию требовало возврата к началу проектной
процедуры. На рис. 2.41 показана традиционная методика добавления тесто-
вых фрагментов к базовому проекту. Чтобы успешно решать все проблемы
времени, площади и рассеиваемой мощности требуется одновременное и
совместное использование новейших средств САПР для создания закончен-
ных DFT -проектов.
Для успешности этой процедуры необходимо, чтобы проектировщики RTL -
описания проекта и проектировщики DFT работали в согласии и с единым
взглядом и видением проекта, используя объединенные проектные средства

и потоки. Конечно, это должно предполагать, что средства DFT не будут
оказывать негативного воздействия на критические временные моменты
основной обработки данных в проекте.
Рис. 2 . 4 1 . Традиционная методика проектирования

пригодной к тестированию аппаратуры
Требуемая технология должна удовлетворять ряду важнейших требований:

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

проектов, предлагаемая и используемая фирмой Synopsys, приведена на
рис. 2.42. Из рисунка видно, что процедура проектирования с первого же
этапа предполагает совместное описание устройства и средств его тестиро-
вания.
Рис. 2 . 4 2 . Последовательность разработки пригодного к тестированию

ASIC - или1 SOPC -проекта
Другие подходы
Приведенный выше материал был посвящен рассмотрению возможностей
JTAG -интерфейса, что определялось, во -первых, его эффективностью при
простоте использования, а во -вторых, слабой освещенностью этого подхода
в отечественной литературе. Чтобы избежать односторонности рассмотре-
ния, стоит упомянуть и об альтернативных вариантах организации тестовых
процедур.
Ряд фирм продолжает выпуск средств, опирающихся на традиционные ме-
тоды и устройства. Среди них такая фирма, как SZ Testsysteme, уже более
20 лет специализирующаяся на выпуске гаммы оборудования, тестирующего
системы со смешанным (цифровым и аналоговым) представлением инфор-
мации и с широким диапазоном возможностей по скорости, диапазону
входных напряжений.
Помимо обычных методов тестирования разрабатываются методы тестиро-
вания, базирующиеся на современных технологиях и нетрадиционных мето-
дах. Так, фирма Teradyne выпускает аппаратуру для автоматической,оптиче -
ской проверки печатных плат Automated Optical Inspection (AOI). Фирма

OptEm Engineering Inc. (www.optem.com) предлагает аппаратуру и програм-
мное обеспечение, которые анализируют печатные платы, затем отображают
корпуса ИС, сопротивления и емкости для всех их внешних соединений и
выдают отчет о местах потенциальных замыканий и цепях, где можно ожи-
дать временных проблем при передаче сигналов.
2.6.4. Системные функции

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

Транспортный аспект стандарта JTAG -интерфейса (стандарт IEEE Std. 1149.1)
позволил стандартизировать, во -первых, прием (передачу) информации в
(из) БИС, входящих в JTAG -цепочку, а во -вторых, исполнение команд
JTAG контроллерами, входящими в состав каждой БИС -цепочки. В резуль-
тате он оказался прекрасным инструментом для создания расширенных вер-
сий JTAG -интерфейса (enhanced JTAG interface), позволив тем самым ис-
пользовать JTAG -интерфейс для решения не только задач тестирования, но
и широкого круга других задач. Возможность адресного направления ин-
формации внутрь БИС, расположенной на печатной плате, и одновремен-
ное указание о запоминании этого потока информации как содержимого
ПЗУ этой БИС, привел к введению специальнбго термина для такой воз-
можности применения JTAG -интерфейса — внутрисхемное программирова-
ние (In System Programmability, ISP). При употреблении термина ISP безраз-
лично, является ПЗУ памятью команд МП или памятью конфигурации БИС
ПЛ. Если же ОЗУ находится в БИС ПЛ, и оно используется как память
конфигурации схемы ПЛИС, то для такого применения JTAG -интерфейса
вводится термин "внутрисхемное реконфигурирование" (In System Reconfi -

gurability, ISR). Если БИС программируемой логики расположена на плате
расширения с интерфейсом PCI (и поскольку по стандарту среди контактов
таких плат предусмотрено наличие и контактов JTAG -интерфейса), то появ-
ляется возможность репрограммировать конфигурацию БИС платы расши-
рения, не вынимая самой платы из компьютера. Такая возможность получи-
ла название In Site Programmability, ISP — с совпадением аббревиатуры для
внутрисхемного программирования.
Развитие средств конфигурирования схем ИСПС

Фирма Xilinx анонсировала выпуск первой производственной системы, ре-
шающей конфигурационные проблемы на системном уровне: технологии
System АСЕ, System Advantaged Configuration Environment. Гибкость и ем-
кость позволяет одной системе АСЕ CF, содержащей 16 -мегабайтную схему
памяти (CF, CompactFlash) и управляющий контроллер, конфигурировать
плату, наполненную БИС FPGA, или целый набор плат, соединенных объ-
единительной платой. Подобная централизация упрощает процедуру кон-
фигурирования систем, содержащих сотни БИС FPGA, позволяет заменять
массив конфигурационных БИС памяти новым содержимым либо осущест-
влять выборочную корректировку. Чтобы изменить или корректировать
конфигурацию системы, можно воспользоваться либо заменой модуля памя-
ти (8 Гбайт), либо корректировать содержимое внутрисистемными средства-
ми через МП -порт, либо загрузить новую конфигурацию, ориентируясь на
сетевые средства, которые используют, например, технологию Internet Re -
configurable Logic (IRL).
У проектировщиков часто возникает необходимость иметь различные моди-
фикации конфигурации. В процессе проектирования могут быть созданы
рабочие, тестовые и отладочные конфигурации. Все эти конфигурации мо-
гут оказаться востребованными в различных ситуациях жизни конечной
продукции.
Встраивание отладочных приборов и инструментов

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

мой Motorola в выпускаемых ею контроллерах (в разд. 2.3 упоминался блок
BDM). В схемах микроконтроллеров этой фирмы широко использовалась
методика внешнего доступа к элементам программного обеспечения. Сейчас
огромные внутренние ресурсы ПЛИС создают платформу для развития ста-
рых и создания новых методик.
Конечно, требуемое теперь время для модификации современной схемы,
включая ее перепрограммирование прямо внутри исследуемой системы, на-
много короче традиционной процедуры перепайки контактов или добавле-
ния ИС на свободном монтажном поле и т. д. Но есть различие поведения
сигналов, выведенных на наружный контакт (для дополнительного контро-
ля, например), и сигналов схем, находящихся внутри кристалла. Методика
отладки должна учитывать возможные модификации схемы, вносимые син-
тезатором ПЛИС, и поэтому предпочтение стоит отдавать средствам, распо-
ложенным непосредственно около исследуемого фрагмента схемы.
Выбор различных вариантов контроля поведения сигналов реализуется, на-
пример, в САПР Quartus фирмы Altera. Проектировщик может ориентиро-
ваться при отладке как на связь со встраиваемым логическим анализатором
внутри БИС программируемой логики этой же фирмы АРЕХ20К (SignalTap
embedded logical analisis), так и на результаты защелкивания в соединитель-
ном устройстве (MasterBlaster) внешних относительно БИС значений сигна-
лов (до 32 сигналов), присутствующих на произвольных соединительных
линиях между БИС.
Для БИС ПЛ класса SOPC фирмы Triscend транспортный механизм JTAG -
интерфейса может использоваться не только для загрузки конфигурации и
программного кода, но и для совмещенной отладки аппаратных и про-
граммных ресурсов. Через JTAG -интерфейс возможна установка аппаратных
точек останова для встроенного в БИС специального блока управления точ-
ками останова (Hardware Breakpoint Unit) микроконтроллера и доступ к его
основным программно -доступным элементам. К ним относятся не только
стандартные предопределенные аппаратные ресурсы типа регистров таймера
и т. д., но и фрагменты, построенные на программируемых элементах. На-
блюдение за контролируемыми параметрами и сигналами возможно не
только после остановки системы, но и в процессе ее штатной работы. В по-
следнем случае разработчик задает временной интервал обновления отла-
дочной информации (из -за большой длины сканирующих регистров темп
такого обновления не превышает долей секунды).
Фирма TI (Texas Instruments) значительное внимание уделяет проблеме ана-
лиза в реальном времени (Real -time Analysis) для отладки своих приложе-
ний, связанных с цифровой обработкой (DSP Solutions). Отладка выполня-
ется в реальном масштабе времени. При этом решаются следующие задачи:
анализ логики работы ПО, получение информации, необходимой для анали-
за производительности и оценки эффективности работы ПО (в том числе и
сбор статистической информации), управление, при необходимости, пове-

дением проекта.
Требования к такому подходу — встраивание предопределенных (базовых)
тестовых ресурсов и ресурсов, назначаемых пользователем (разработчиком),
автоматическое (без постоянного управления проектировщиком) поступле-
ние требуемых данных в отладочные средства, использование интерфейса
реального времени между исследуемым устройством и отладочным средст-
вом: Real -Time Data Transfer (RTDT), JTAG или другого определяемого
пользователем интерфейса. Основными требованиями к базовому тестовому
оборудованию являются минимальное и предсказуемое паразитное воздей-
ствия на выполнение основных функций оборудования и его оптималь-
ность. Точно так же, от встраиваемого разработчиком оборудования требует-
ся наличие в нем механизмов управления его встраиванием и включение
в его состав средств условного включения/выключения.
ГЛАВА 3
Языки описания
дискретных устройств
3.1.Общиеположения
3.1.1. HDL -программа
как модель проектируемого устройства
Языковое описание устройства — это текст, сохраняемый в некотором фай-
ле или нескольких файлах, которые в совокупности составляют представле-
ние разработчика о проекте и используются на всех последующих этапах
проектирования, в том числе при синтезе устройства и его моделировании.
Тексты описаний в большинстве языков проектирования дискретных уст-
ройств по составу синтаксических конструкций и по интерпретации резуль-
татов их исполнения (физического или модельного) очень схожи с традици-
онными языками программирования. Поэтому часто такое текстовое описа-
ние называют программой на языке проектирования, или, коротко, HDL -
программой, а конструкции, описывающие способ формирования результа-
тов, — операторами.
HDL -программа может рассматриваться как знаковая модель дискретного
устройства [1, 34]. Знаковыми моделями называют способы представления
реальных или проектируемых объектов, которые не имеют физического или
геометрического подобия с объектами моделирования, а отражают лишь су-
щественные свойства объектов с использованием принятых формальных
обозначений. Воспроизведение функционирования и иных свойств объекта
по знаковым моделям может выполняться на основе мысленных или ма-
шинных экспериментов с ними. Знаковая модель, как всякая другая модель,
обеспечивает выделение наиболее существенных для разработчика характе-
ристик. Как правило, составитель HDL -программы абстрагируется от кон-
кретной физической реализации, выделяя, прежде всего, воспроизведение
функционирования проектируемого изделия. После выполненных прове -
рочных процедур на основе модели может быть построен объект, т. е. некое

физическое устройство, которое подтвердит или (что при хорошем уровне
моделирования мало вероятно) опровергнет предположения, заложенные в
модель. Естественно, в современных условиях основную работу по интер-
претации модели в физический объект выполняет компьютер, но иногда
пользователь может вмешиваться в процедуру синтеза, т. е. возможны интер-
активные процедуры проектирования.
Современные языки позволяют строить модели (программы), характери-
зующиеся различной степенью приближения к будущей реализации — от
внешнего описания закона функционирования до детального представления
проекта на уровне вентилей или макроячеек БИС. Одним из способов
сближения описания и фактической реализации является иерархическое
проектирование, возможность которого предусмотрена семантикой совре-
менных языков проектирования.
Типы данных
Входная информация в дискретных устройствах — цифровые сигналы, кото-
рые должны поступать в систему через контакты и далее двигаться по це-
пям, называемым также связями, к блокам, выполняющим те или иные пре-
образования, и далее на выходные контакты или к другим блокам. Входным,
внутренним и выходным данным проектов сопоставляются имена связей,
которым соответствуют цифровые сигналы на соответствующих входных и
выходных контактах проектируемой схемы или внутренних цепях проекта.
Источнику сигнала, поступающего на некоторую связь, в языках сопостав-
ляется оператор, присваивающий значения переменной, представляющей
связь или сигнал на этой связи. Такие операторы называют драйверами. Раз-
личие сигналов от связей выполняется только по контекстным при-
знакам.
Основным типом данных в языках являются данные сигнального типа, по
свойствам близкие к обычным логическим данным (часто мы будем назы-
вать их просто логическими). Основное отличие логических данных в язы-
ках проектирования от логических данных языков программирования за-
ключается в наборах допустимых значений, что более подробно будет изло-
жено в разд. 3.1.2. Кроме того, явно или неявно подразумевается, что сигнал
обладает временными характеристиками, в частности, изменение значений
отображающей переменной может происходить не сразу после присвоения
ей нового значения.
Для удобства работы данные могут, как и в обычных языках программиро-
вания, структурироваться и объединяться в агрегаты — массивы, векторы,
записи (VHDL, Verilog), группы (AHDL). В некоторых оговоренных случаях
структурированные логические данные представляются в достаточно "при-
вычных" формах, например как числа или строки. Преобразованиям логи -
ческих данных сопоставляются определенные компоненты в структуре про-

ектируемого устройства.
Помимо данных сигнального типа применяется ряд служебных типов дан-
ных. Из них наиболее важными являются данные арифметического типа и
строчные данные. Хотя программы могут предусматривать преобразования
таких данных, однако эти преобразования реализуются только на этапе
компиляции и, может быть, моделирования проекта. При реализации в ап-
паратуре используются только окончательные результаты преобразований,
обычно в форме констант, задающих конфигурацию аппаратных средств.
Структура и поведение
Модель, отражающая объект проектирования в форме правил преобразования
входных данных в выходные, называется поведенческой. Такая точка зрения на
проект представлена рис. 3.1, о. В общем случае можно записать функцию
преобразования как
Y= F(A, B).
Используя терминологию VHDL, назовем модуль F— PROJECT ENTITY
(дословный перевод — сущность проекта), входы и выходы назовем портами
(PORT). Программные модули на языке VHDL, описывающие проекты
в поведенческой форме, именуют поведенческими архитектурными телами.
Рис. 3 . 1 . Поведенческое (а) и структурное (б) представление проекта
Структурная модель описывает проект в виде совокупности модулей, каж-

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

чае, очевидно, выполнена декомпозиция функции F в виде:
F(A, В) = I(G(A, В), Н(А, В)).
Каждый подблок (в нашем примере блоки G, Н и I), в свою очередь, может
быть представлен в виде поведенческой или структурной модели.
Структурная модель является естественным способом создания сложных
проектов, описание которых целесообразно выполнить по иерархическому
принципу. В программном модуле высшего уровня иерархии содержатся
объявления портов и внутренних связей, а также так называемые декларации
вхождений компонентов (INSTANTION DECLARATION), т. е. определен-
ных синтаксисом языка указаний на включенные компоненты и способ их
соединений. В VHDL такое описание называют структурным архитектур-
ным телом.
На рис. 3.2 представлен типовой набор проектных модулей и их взаимосвя-
зей на примере VHDL. Хотя в других рассмотренных в настоящей книге
языках понятие архитектурного тела явно не определяется, общая структура
комплекса программных модулей иерархического проекта в разных языках
имеет много общего. Рассмотрим процедуру представления иерархических
проектов в языковой форме на основе дисциплины нисходящего проектиро-
вания.
Рис. 3.2. Иерархическая структура проекта

Первым этапом проектирования по дисциплине "сверху вниз" является соз-

дание поведенческой модели высшего уровня иерархии. На рисунке этот
этап отображен исходным первичным модулем ENTITY PROJECT, описы-
вающим интерфейс проекта, и связанным с ним вторичным модулем ВВ
(Behavioral Body) — описанием его поведения. Средствами используемого
пакета проектирования выполняется сеанс моделирования поведения. Часто
может потребоваться несколько коррекций до получения соответствия пове-
денческой модели заданным требованиям.
Если объект является сравнительно простым, то поведенческое описание
высшего уровня после отладки на модели может непосредственно переда-
ваться в подсистему компиляции для синтеза аппаратной реализации. Одна-
ко, как показывает опыт использования САПР, при интерпретации сложных
алгоритмов возникают ситуации, когда компилятор "навязывает" неопти-
мальные решения. Использование детализации описания позволяет смяг-
чить эффект такого навязывания, усилить влияние разработчика на оконча-
тельную реализацию. Некоторые конструкции программ, особенно характе-
ризующиеся большой глубиной вложения операторов, вообще не поддаются
в распространенных САПР прямой интерпретации в соответствующее схем-
ное решение. Кроме того, разделение общего описания на фрагменты об-
легчает реконфигурацию системы за счет замены некоторых блоков другими
блоками аналогичного назначения, не говоря о преимуществах связанных
с возможностью распараллеливания проектной процедуры между несколь-
кими исполнителями.
При структуризации проекта каждой выделенной структурной единице со-
поставляется проектный модуль со своим ENTITY. Модули первого уров-
ня декомпозиции на рисунке обозначены как М11, М12, •• -, М1n. Создается
структурное архитектурное тело SB (Structural Body), соответствующее верх-
нему уровню иерархии. SB содержит декларацию выделенных подблоков и
описание необходимых межблочных связей. Первичное (поведенческое)
описание подблока может быть построено путем "вырезания и копирования"
соответствующих фрагментов текста из поведенческого тела предшествую-
щего иерархического уровня с добавлением требуемых стандартом языка
заголовков. В общем случае, возможно сохранение описания части подбло-
ков в архитектурном теле высшего уровня иерархии в поведенческой форме.
Тогда говорят о смешанных, или структурно -поведенческих телах. Важно
отметить, что ENTITY целостного проекта остается без изменений. После
тестирования структурированной версии описания можно перейти к струк-
туризации подблоков, которая выполняется подобным образом. При необ-
ходимости, после каждого уровня структурная декомпозиция блоков может
быть продолжена. В результате получается древовидная иерархия проекта.
Процесс проектирования можно рассматривать как перемещение по дереву
декомпозиции, а окончательный проект как совокупность однонаправлен-
ных путей в дереве от корня, представленного ENTITY целостного проекта,
к конечным вершинам. На любом этапе декомпозиции (в том числе на ко -
печном и на всех промежуточных этапах) конечными вершинами являются

только поведенческие тела, а промежуточные вершины представлены струк-
турными телами. Если модуль далее не подлежит декомпозиции, он пред-
ставляется только поведенческим телом.
В процессе осуществления конкретного проекта полная декомпозиция
требуется не всегда. На некотором этапе может оказаться выделенной сово-
купность операторов, которая воспроизводится некоторым модулем, при-
сутствующим в библиотеке, поставляемой с САПР, используемой при про-
ектировании, библиотеке предыдущих разработок проектировщика или
приобретаемых у третьих фирм расширениях библиотек. Тогда достаточно в
соответствующем структурном теле сослаться на этот библиотечный модуль.
Однако и в этом случае общая структура проекта сохраняется. Просто ссы-
лаясь на библиотечный модуль, проектировщик фактически подключает к
своему проекту иерархическое поддерево, вершиной которого является мо-
дуль, указанный в ссылке. Само поведенческое или структурное описание
подключаемого модуля от проектировщика может быть скрыто.
Тестирование является одной из важнейших проектных процедур. Можно
рекомендовать одновременно с разработкой программы описания проекти-
руемого устройства изделия создавать программу для тестирования проекта.
Подобная программа представляет структурную модель (SB) тестирующей
установки (Test -Bench), компонентами которой, в общем случае, являются:
проектируемый модуль, генератор тестирующего воздействия (Stimulator) и
анализатор результатов (рис. 3.3).
К нижним уровням
иерархии
Рис. 3.3. Структура модулей для тестирования проекта
Замечание
В языках VHDL и VerilogHDL можно встраивать описание поведения внешних
выводов, фактически, тестового воздействия, непосредственно в программу,
представляющую проектируемый модуль. Тем не менее, создание модуля для
тестирования как самостоятельной проектной единицы представляется более

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

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

Возвращаясь к понятию поведенческой модели, отметим, что известны раз-
личные подходы к описанию поведения в HDL -программах. Для наглядно-
сти рассмотрения этих подходов будем использовать понятие информаци-
онного графа алгоритма (рис. 3.4). Вершинам информационного графа про-
ектируемой системы сопоставляются элементарные действия (операторы),
которые выполняются над исходными или промежуточными данными, а
дугам соответствуют информационные связи [10].
Выделим основные подходы к описанию функционирования дискретных
систем, иногда называемые стилями программирования. Выбор стиля про-
граммирования во многом определяется наклонностями и опытом разработ-
чиков, но надо иметь в виду, что часто стиль существенно влияет на порож-
даемую системой автоматизированного проектирования реализацию.
a б
синхр.
Рис. 3.4. Информационный граф алгоритма: каскадная форма (а)

и конвейерная форма (б)
- Последовательный стиль описания соответствует традиционным подхо-

дам к составлению компьютерных программ. Расположение и порядок
исполнения операторов в тексте описания соответствует порядку прохо-
ждения данных через информационный граф. Любой оператор в тексте
записывается после всех операторов, ему инцидентных, т. е. тех, с кото-
рыми он имеет связи по входу. Такое описание наиболее точно интер-
претируется ярусной формой информационного графа (см. рис. 3.4, а),
которая получается из исходного представления алгоритма путем упоря-
дочения независимых примитивных операторов таким образом, что вер-
шины каждого яруса связаны с вершинами предыдущих. Желательно,
чтобы максимальное число связей осуществлялось вершинами непосред-
ственно предшествующего яруса. Порядок записи операторов одного
уровня не имеет значения. Графы с обратной связью в последовательной
форме интерпретировать в HDL затруднительно, а иногда и невозможно.
- Параллельный стиль предполагает асинхронное и, по возможности, од-
новременное исполнение операторов в реализуемом устройстве. Обычно
блок, реализующий некоторый оператор, непосредственно реагирует на
признак исполнения действия любым из его предшественников. Особен-
ности моделирования поведения параллельного описания в профаммных
системах последовательного типа будут рассмотрены в разд. 3.1.2. Для
представления параллельных процессов используются такие формы запи-

си, которые предусматривают исполнение каждого оператора после вы-
полнения хотя бы одного любого из инцидентных ему операторов (в VHDL
такие операторы называются параллельными и отличаются от последова-
тельных по своей локализации в программе). Порядок записи параллель-
ных операторов безразличен, допустимы обратные связи и петли.
- Потоковый стиль отличается от предыдущего тем, что оператор испол-
няется после готовности всех предшественников данного оператора.
В чистом виде потоковый принцип довольно сложен в реализации, за
исключением случая линейного алгоритма или блочно -линейного алго-
ритма (т. е. алгоритма, разделимого на последовательно соединенные
блоки, каждый из которых может иметь достаточно сложную структуру).
Чаще используется его модификация — конвейер. Операторы, представ-
ляющие вершины одного яруса графа, исполняются после реализации
всех операторов предыдущего яруса. Операторы одного яруса могут опи-
сываться и как последовательные, и как параллельные. Техническая реа-
лизация обычно предусматривает синхронную работу ступеней конвейера
от общего синхронизирующего сигнала, причем период синхронизи-
рующих сигналов больше максимального времени задержки элементов.
На рис. 3.4, б представлена реализация того же алгоритма, что и на
рис. 3.4, а. Прямоугольниками показаны вспомогательные элементы,
фиксирующие состояния входов и выполняющие запуск очередной сту-
пени в синхронные моменты времени. На управляющие входы всех
вспомогательных элементов подается один и тот же сигнал. Обозначения
на управляющем входе отображают относительный порядковый номер
порции данных, подаваемых на очередную ступень конвейера. В случае
рассинхронизации прохождения потоков данных по разным путям встав-
ляются пустые операторы (элементы задержки), отображенные на
рис. 3.4, б заштрихованными кружочками. Конвейерный стиль описания
порождает конвейерные реализации, которые, как известно, обладают
повышенной производительностью, т. к. во время обработки порции
данных некоторой ступенью предыдущая ступень может обрабатывать
следующую порцию данных. В то же время недостатком конвейера в
сравнении с параллельной реализацией может стать большая задержка
результатов относительно момента появления порции данных.
- Автоматный стиль, в отличие от предыдущих, опирается не на модель
передачи данных, а на модель переключения состояний. Стиль основан
на определении некоторого множества состояний проектируемого уст-
ройства и правил перехода из одного состояния в другое в зависимости
от входных сигналов. Каждому состоянию или переходу соответствует
определенный набор действий. Такой подход наиболее эффективен при
описании устройств, характеризующихся циклическим выполнением од-
нотипных последовательностей преобразований, в частности управляю-
щих устройств, процессорных модулей.
Целесообразный стиль создания проекта и привлекаемые для его реализа-

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

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

Известно два противоположных подхода к построению систем моделирова-
ния дискретных устройств — сквозное моделирование и событийное моделиро-
вание [1].
При сквозном моделировании время делится на кванты, длительность кото-
рых выбирается (с необходимой точностью) как наибольший общий дели-
тель времен задержек компонентов. Каждый квант реального времени соот-
ветствует единице модельного времени и отображается вычислительной
процедурой (шагом моделирования), состоящей из двух фаз. Частный и
простейший случай — моделирование с константными задержками, т. е.
равными для всех компонентов. Тогда в первой фазе последовательно вы-
полняются вычисления состояний всех компонентов на основе сигналов,
вычисленных на предыдущем шаге, а результаты сохраняются в буфере
предсказанных состояний. В следующей фазе данные из буфера переписы-
ваются в рабочие ячейки, сохраняющие значение сигналов для очередного
шага.
Если при моделировании предполагаются произвольные задержки компо-
нентов, то используется не простой одноступенчатый буфер предсказанных
состояний, а буферы типа FIFO (первый вошел — первый вышел) для каж-
дого компонента. Глубина каждого буфера равна задержке соответствующего
компонента, выраженной в числе единиц модельного времени. Сдвиг дан-
ных в буфере выполняется после каждого шага моделирования. Таким обра-
зом, результаты, поступающие на вход такого буфера, поступят на его выход
через время, точнее, число шагов, соответствующее выбранной модельной

задержке.
Некоторые особенности имеются при моделировании без учета задержек.
В этом случае каждый шаг моделирования реализуется как итерационная
процедура. Буфер предсказанных состояний может и не требоваться. Вы-
численные состояния сразу доступны программе и используются при моде-
лировании уже следующего компонента моделируемого устройства. Если
после такого прохода по всем компонентам обнаружены изменения по
сравнению с результатами предыдущего прохода, процедура повторяется до
достижения установившегося состояния или до исчерпания заданного числа
итераций. Когда установившееся состояние достигнуто, можно переходить к
очередному шагу моделирования. Если после заданного числа итераций на
каких -либо связях наблюдаются изменения сигналов, можно сделать вывод
о наличии осцилляции и определить эти выходы как неопределенные.
Недостатки сквозного моделирования достаточно очевидны. Это, во -первых,
нерациональные затраты машинного времени, вызванные потребностью
достаточно мелкой дискретизации времени и необходимостью воспроизве-
дения на каждом шаге поведения всех компонентов, в том числе тех, на
входах которых не происходит изменений сигналов. На самом деле такие
компоненты программа моделирования могла бы попросту пропускать. Во -
вторых, налицо нерациональное использование памяти, а это, в сущности,
тоже потеря производительности. При моделировании систем с большим
разбросом задержек требуются сравнительно емкие FIFO -буферы предска-
занных состояний.
Поэтому практически все развитые системы моделирования используют со-
бытийный подход, или, как говорят, дискретную событийную модель. На
каждом шаге моделирования перевычисляются состояния только тех компо-
нентов, на входе которых в данный момент происходят изменения. Измене-
ния логических переменных, как входных, так и промежуточных, называют
событиями. Любое событие может вызвать цепочку других событий. Моде-
лирование системы производится не для равномерно отстоящих моментов
реального времени, а лишь для моментов, для которых ранее были предска-
заны события.
Событийная модель кроме совокупности таблиц, представляющих структуру
моделируемого устройства, использует две основные структуры данных —
календарь событий и поле состояний сигналов.
Календарь событий — это список, каждый элемент которого представляет
запись и содержит значение времени наступления события, имя изменяе-
мого сигнала и предсказанное на интервал времени после наступления со-
бытия значение этого сигнала. Элементы списка упорядочены по возраста-
нию времени появления событий. Перед началом моделирования в кален-
дарь событий заносятся все запланированные в эксперименте события на
входах, т. е. изменения входных сигналов, а в поле состояний сигналов —
исходные состояния (в крайнем случае, неопределенные состояния). Каж-

дый шаг моделирования отражает реакцию системы на одно событие и пре-
дусматривает следующую последовательность действий:
1. Из календаря выбирается запись, соответствующая очередному событию.
В первом цикле выбирается первый элемент календаря событий. В даль-
нейшем выборке подлежит событие, у которого отметка модельного вре-
мени является ближайшей большей по сравнению с отметкой времени
события, проанализированного на предыдущем шаге. Устанавливается
модельное время в соответствии с указателем времени события, а новое
значение сигнала, вызвавшего событие, переписывается в поле текущих
состояний сигналов.
2. По имени сигнала из структурных таблиц последовательно выбираются
компоненты, на входы которых подан изменяющийся сигнал, и для всех
этих компонентов выполняется моделирование, заключающееся в опре-
делении характера изменения его выходных сигналов в ответ на это со-
бытие. Выполняется предсказание изменений выходных сигналов в бу-
дущие моменты модельного времени. Это называют временным распреде-
лением переходов (scheduling a transaction) выходных сигналов. Отметим,
что пока выполняется цикл отработки одного события все сигналы как
бы "заморожены".
3. Модификация календаря событий. При этом выполняется запись всех
новых предсказанных событий в календарь. Отметка времени каждого
нового события вычисляется как сумма текущего времени и времени за-
держки элемента, который генерирует соответствующий сигнал. Событие
помещается в список вслед за имеющимся в списке событием, характе-
ризующимся ближайшей меньшей отметкой времени. Кроме того, в ряде
случаев должны удаляться некоторые события, которые имеются в кален-
даре. Алгоритм удалений зависит от используемой модели задержки. Мо-
дели задержки, используемые в VHDL, и соответствующие правила уда-
лений приведены в разд. 3.2.6. Если изменение входов не приводит к из-
менению выходов, или, как говорят, происходит поглощение события,
то, естественно, календарь не изменяется. Простейший пример такой си-
туации — переход "логический ноль—логическая единица " на входе эле-
мента ИЛИ, на другом входе которого уже присутствует единица.
4. Если в календаре нет событий, предсказанных на время, позднее теку-
щего модельного времени, то моделирование прекращается, в противном
случае выполняется возврат к п. 1.
Событийное моделирование без учета задержек также имеет определенную
специфику. Модель и в этом случае предполагает наличие задержки, но
очень малой, называемой дельта -задержкой (5 -задержка). Дельта -задержка
не несет информации о реальном времени передачи сигналов, а отражает
причинно -следственные связи в объекте моделирования. Если на каком -
либо из элементов при выполнении п. 2 описанного порядка моделирования
предсказывается изменение сигнала, то соответствующее событие заносится

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

нофазного D -триггера, схема которого приведена на рис. 3.5. В таблице
представлено содержание календаря событий (одна строчка — одно собы-
тие) до моделирования, а также после моделирования с учетом задержек,
принятых равными 1 не, и без учета задержек. В исходном состоянии все
сигналы нулевые.
Знак < - означает изменение сигнала. Таблица построена на основе файлов
отчета сеансов моделирования VHDL -описания в системе Model Technology.
Обратите внимание, что одно и то же время может быть присвоено не-
скольким событиям. События, предсказанные на одно и то же время, не
упорядочены, а записываются одно за другим по мере обнаружения перехо-
дов при обработке предыдущих событий.
Таблица 3.1. Результаты моделирования однофазного D -триггера
Исходный Календарь Календарь

календарь после моделирования после моделирования
с учетом задержек без учета задержек
Время Событие Время Событие Время Событие
0 0 0
10 d< -1 10 d< -1 10 d< -1
Исходный Календарь Календарь

календарь после моделирования после моделирования
с учетом задержек без учета задержек
Время Событие Время Событие Время Событие
15 clk < - 1 15 clk < - 1 15 clk < - 1
20 clk < - 0 16 Ь< -1 15 b< -1
25 d< -0 17 q< -1 15 q< -1
30 clk < - 1 20 clk < - 0 20 clk < - 0
35 clk < - 0 21 а< -1 20 а< -1
40 clk < - 1 21 b< -0 20 b< -0
45 d< -1 25 d< -0 25 d< -0
50 d< -0 30 clk < - 1 30 clk < - 1
55 clk < - 0 31 a< -0 30 a< -0
32 q < -0 30 q < -0
35 clk < - 0 35 clk < - 0
40 clk < - 1 40 clk < - 1
45 d< -1 45 d< -1
46 b< -1 45 b< -1
47 q< -1 45 q< -1
50 d< -0 50 d< -0
51 b< -0 50 b< -0
52 q < -0 50 q < -0
55 clk < - 0 55 clk < - 0
Алфавит моделирования
Важной характеристикой метода моделирования цифровых устройств явля-
ется количество различимых состояний сигнала. Каждому состоянию сопос-
тавляется индивидуальный символ, совокупность символов составляет алфавит
моделирования. Естественно, каждое состояние специфически воспринима-
ется приемниками сигналов, поэтому системе моделирования определяется
набор правил преобразования сигналов типовыми цифровыми элементами.
Простейший алфавит — двоичный, содержащий набор {' о', ' 1'}. Функ-
ционирование элементов описывается по правилам алгебры логики. Моде-
лирование на базе этого алфавита весьма экономично, но возможности мо-
делирования ограничены. Невозможно описание шинной логики, в том
числе схем, имеющих высокоимпедансное состояние на выходе (Z -co -
стояние), схем с открытым коллектором и подобных. Затруднено воспроиз-
ведение сбойных ситуаций, например, вызванных подачей управляющих
сигналов на триггеры во время, когда информационные сигналы еще не ус-
тановлены.
Весьма распространен алфавит из четырех символов {'о', 'х', '1', 'Z'}.
Здесь 'х' означает неопределенное состояние. Такой символ присваивается,
в частности, сигналу на выходе логического элемента во время переходного
процесса. Неопределенное состояние принимает выход триггера после пода-
чи активизирующего сигнала на синхронизирующий вход при запрещенной
или неопределенной комбинации сигналов на информационных входах
триггера. Символ ' z ' представляет высокоимпедансное состояние порта или
отключенную линию. Алфавит {'О1, 'X', ' 1 ' , 'Z'} является единствен-
ным, используемым при записи и моделировании программ, написанных на
языке AHDL в системе MAX+PLUS II.
Дальнейшее расширение возможностей — девятиэлементный алфавит, в ко-
тором приняты следующие символы для представления состояний связей:
- 'u' — не инициализировано (сигналу в программе вообще не присваива-
лись другие значения; обеспечивает контроль корректности инициали-
зации);
- 'z' — отключено (все источники, подключенные к связи в высокоимпе -
дансном состоянии);
- 'х' — активное неопределенное состояние;
- ' о' — активный ноль;
- ' 1' — активная единица;
- 'L' — слабый ноль;
- 'Н' — слабая единица;
- 'W' — слабое неопределенное состояние;
- ' - ' — не важно (разработчик может запрограммировать переход в это
состояние, если реализация алгоритма не зависит от результата; выбор
конкретного значения предоставляется компилятору с целью оптимиза-
ции реализации устройства).
Разница между слабыми и активными состояниями состоит в том, что сла-
бый сигнал формируется от источников (называемых драйверами), имею -
щих повышенное выходное сопротивление по сравнению с активными ис-

точниками. В этом случае источник, генерирующий активный сигнал, по-
давляет слабый, если не отключен. Пример элемента, генерирующего сла-
бую единицу, — буфер с открытым коллектором: на выходе у него может
быть активный ноль, но слабая единица.
При записи программ в VHDL пользователь может априорно задать алфавит
моделирования тех или иных языковых конструкций, определяя тип сигна-
лов — от простого двоичного, задаваемого как тип BIT (битовый) до девяти -
компонентного типа STD_ULOGIC. В принципе, пользователь может создавать
свои типы с большим или меньшим числом символов для представления
логических данных, или, что то же самое — числом воспроизводимых в мо-
дели состояний сигналов.
Язык Verilog в качестве базового использует алфавит с {'о', 'х', '1', 'Z'},
однако проектировщик может присвоить драйверу сигнала специальный
атрибут "уровень силы" (strength level), который позволяет моделировать
вентильные и буферные компоненты, а также ключевые и резистивные схе-
мы с учетом соотношения их выходных сопротивлений.
При выборе алфавита моделирования (если это допускает система модели-
рования) следует учитывать, что расширенный алфавит, обеспечивая во
многих случаях большую адекватность моделирования, требует больших за-
трат машинного времени на проведения сеансов моделирования.
3.1.3. Соглашение о правилах записи программ

Программы составляются из лексических элементов, к которым относят
имена (идентификаторы), ключевые (зарезервированные) слова, специаль-
ные символы, числа, текстовые символы (characters) и строки символов.
Лексические элементы объединяются в синтаксические конструкции — вы-
ражения (expression). Выражение — это конструкция, которая объединяет
операнды и знаки операции для формирования результата, являющегося
функцией от значений операндов и семантического смысла знака операции.
Любое выражение может стать операндом в другом выражении. Констант-
ные выражения содержат только определенные в языке записи значений
данных и объявленные ранее в тексте имена констант (параметров).
Выражения в свою очередь составляют предложения. Основные категории
предложений это декларации (declaration) и операторы (statement, дослов-
ный перевод — утверждения). Главное назначение деклараций состоит в оп-
ределении смысла некоторых идентификаторов. Операторы определяют дей-
ствия, предусмотренные описываемым алгоритмом, иногда в неявной форме.
Представление языковых конструкций в настоящей книге, кроме пояснения
их содержательного смысла и примеров использования, предусматривает
формальное определение синтаксиса, т. е. правил вхождения лексических
элементов в эти конструкции. При записи программ необходимо строго
придерживаться синтаксических стандартов языков. В противном случае

компилятор не сможет интерпретировать предложения и будет выдавать со-
общение об ошибке.
Синтаксические конструкции определяются с использованием формализованных
правил их записи — формул Бэкуса—Науэра (BNF). Такие формулы представ-
ляют некоторые трафареты, в которые разработчик подставляет правильно
оформленные конструкции.
Определяемая (или уже определенная) конструкция в BNF представляется
ее названием, в данной книге на русском языке, заключенным в угловые
скобки <>. Допускается опережающее использование конструкции, иными
словами, определение конструкции далее по тексту после ее первого ис-
пользования в определении другой конструкции. Сразу за определяемой
конструкцией ставится знак ::=, который трактуется как "записывается в
форме", после чего записывается трафарет конструкции, состоящий из лек-
сических элементов рассматриваемого языка, определенных конструкций
и специальных метасимволов, смысл которых поясняется далее.
Метасимвол | определяет альтернативные возможности записи конструк-
ции.
Пара метасимволов « » — кавычки -"елочки" — ограничивают конструкцию,
которую можно повторить сколько угодно раз, в том числе ни одного раза.
Например:
<целое десятичное число>::= <цифра> « <цифра> »
<цифра>::= 0 | 1 | 2 | 3 | 4 | 5 | б | 7 | 8 | 9
<идентификатор>::= <буква> « <цифра>|<буква> »
Последнюю формулу можно трактовать так: "идентификатор записывается

в виде любой последовательности букв и цифр, начинающейся с буквы".
Пара метасимволов [ ] — квадратные скобки — будет использоваться для
отображения необязательного элемента синтаксической конструкции VHDL.
Например, BNF -форма
<Вызов функции>::=<имя функции> [ <список ассоциаций>) ]
определяет, что список ассоциаций при вызове функции не обязателен.

Но в языках Verilog и AHDL квадратные скобки используются как основные
символы для выделения индексов. Поэтому при определении синтаксиса
этих языков использованы неполные начертания скобок: [ и ]
Во всех рассмотренных далее языках при записи идентификаторов и ключе-
вых слов допускаются только латинские буквы. Кириллица может использо-
ваться лишь в комментариях и текстовых константах, причем не во всех
системах проектирования, поэтому такая возможность требует специальной
проверки.
В языках VHDL и AHDL не вводится различий в использовании прописных

и строчных букв (за исключением символьных данных). Так, ключевое сло-
во, открывающее декларацию переменных, может быть записано и как
VARIABLE, и как variable, а запись переменной box означает то же, что BOX,
даже если варианты встречаются в одном контексте. Тем не менее, в данной
книге для лучшей читаемости программ на этих языках мы будем придер-
живаться правила, по которому ключевые слова записываются прописными
буквами, а идентификаторы — строчными.
Однако Verilog HDL не допускает прописных букв для отображения ключе-
вых слов. Поэтому в разд. 3.3, посвященном изложению основ этого языка,
авторы вынужденно отказались от наглядного выделения ключевых слов.
Символ "перевод строки" игнорируется известными HDL -компиляторами.
Поэтому разбиение текста программ на строки произвольно. В данной
книге авторы старались при записи листингов программ по возможности
придерживаться правила "одна строка — одно предложение", хотя в некото-
рых случаях предложение будет записываться в нескольких строках. Воз-
можны варианты, когда несколько коротких предложений размещены в од-
ной строке.
При описании синтаксиса языка VHDL синтаксические формулы даются
в варианте VHDL'93. Опции, которые не поддерживаются в VHDL'87, будут
подчеркиваться.
И последнее. Авторы в настоящей работе не ставили своей целью пол-
ное описание синтаксиса языков. Приводятся только наиболее важные, по
мнению авторов, и часто используемые в проектировании конструкции и
принципы составления программ. Некоторые альтернативные BNF -пред -
ставления намеренно опущены, чтобы вычленить наиболее существенные
варианты. Для более детального ознакомления с рядом специфических кон-
струкций потребуется изучение соответствующих стандартов. Однако надо
знать, что стандарты, являясь официальными документами, весьма сложны
для понимания, если не иметь представление о принципах использования
основных конструкций. Кроме того, авторы предполагают, что читатели
знакомы с программированием на общеупотребительных языках, таких как
Pascal и С.
3.2. Основы языка VHDL

3.2.1. Язык VHDL как программная система
Язык VHDL был разработан в США в начале восьмидесятых годов по зада-
нию Министерства обороны как язык спецификации проектов с целью
обеспечения единообразного понимания подсистем различными проектны-
ми группами. В 1987 г. спецификация языка VHDL была принята в качестве
стандарта ANSI/IEEE STD 1076 -1987, который часто называют VHDL'87.

Удобства и относительная универсальность конструкций этого языка доста-
точно быстро привели к созданию программ моделирования систем на ос-
новании их описания в терминах VHDL.
С начала девяностых годов разрабатываются прямые компиляторы VHDL -
программ в аппаратные реализации различных классов. Это наряду с необ-
ходимостью более адекватного представления в языке современных тенден-
ций в цифровой схемотехнике стало стимулом усовершенствования языка и
привело к созданию расширенного стандарта ANSI/IEEE STD 1076 -1993,
или кратко VHDL'93 [56, 57, 58]. К тому же следует отметить, что стандарты
IEEE подлежат обязательному обновлению каждые пять лет. В 1999 г. была
утверждена новейшая версия стандарта IEEE STD 1076.1 -1999, известная как
VHDL -AMS. Наиболее существенным нововведением VHDL -AMS является
появление конструкций, обеспечивающих эффективное описание аналого-
вых и аналого -цифровых устройств. За основу изложения в настоящей книге
принят VHDL'93. Учитывая, что VHDL'87 еще имеет достаточно широкое
распространение, конструкции, которые не поддерживаются VHDL'87, от-
мечаются особо (подчеркиванием, как мы предупредили в предыдущем раз-
деле).
В настоящее время трудно найти САПР дискретных устройств, которая не
воспринимает описания устройств на VHDL или хотя бы на его усеченных
версиях. В этом смысле надо различать набор языковых конструкций, ори-
ентированных на спецификацию и обеспечение возможности моделирова-
ния проекта, и так называемое реализуемое подмножество, т. е. подмноже-
ство, которое может непосредственно интерпретироваться схемными ком-
понентами в окончательном проекте в рамках принятой САПР.
VHDL поддерживает широкий набор задач, возникающих при проектирова-
нии. Он обеспечивает возможность описания устройств с различной сте-
пенью детализации и в различных формах, начиная от внешнего описания
общих принципов функционирования до представления в форме элемен-
тарных цифровых компонентов (вентилей и триггеров). Разрешается пред-
ставление через алгоритм функционирования в форме, близкой к традици-
онным алгоритмическим языкам (так называемое "чистое поведение"). В то
же время присутствуют средства, описывающие проект как набор компо-
нентов и связей между ними, допустимы и смешанные формы описаний.
Поэтому обеспечивается возможность организации проектной процедуры
как последовательной декомпозиции абстрактных спецификаций. Значи-
тельное место в языке отведено средствам моделирования, позволяющим
проектировщику быстро обнаруживать ошибки и сравнивать альтернатив-
ные варианты до сравнительно дорогостоящей фактической реализации
проекта. Все это уменьшает объем рутинной работы, "позволяя разработчику
сконцентрироваться на стратегических решениях и сократить время достав-
ки изделия на рынок" [34].
В соответствии с вышесказанным средства языка VHDL можно отнести

к одному из двух разделов [52, 56] (см. рис. 3.6):
- общеалгоритмический компонент, определяющий набор типов данных и
операторов, обеспечивающих общее описание алгоритма функциониро-
вания;
- проблемно -ориентированный компонент, включающий такие специфиче-
ские и важные для описания аппаратных средств разделы, как специфи-
ческие для аппаратуры типы данных, средства для описания процессов
с учетом их протекания в реальном времени, средства для структурного
представления проекта.
Общеалгоритмический компонент по составу, смыслу и принципам исполь-
зования ее составляющих мало отличается от состава традиционных языков
программирования, да и форма записи (синтаксис и семантика языковых
конструкций) весьма близка к традиционным языкам. Предварительно ос-
тановимся на некоторых составляющих проблемно -ориентированного ком-
понента.
В числе проблемно -ориентированных типов данных прежде всего следует
отметить физический тип, используемый для моделирования поведения ре-
альных цифровых систем. Здесь присутствует предопределенный тип —
время. Пользователь может определить дополнительные типы данных, отра-
жающих электрические (напряжения, токи, сопротивления и т. п.) или ме-
ханические свойства носителя информации.
Многозначная логика формально в языке не определена. Однако входящие
в любой комплекс моделирования на VHDL стандартные пакеты, например
std_iogic_H64, определяют целую совокупность допустимых алфавитов
представления сигналов на основе их декларации как данных перечисли-
мого типа, а также определяют правила их преобразования.
Ограниченные типы данных присутствуют в ряде традиционных языков
программирования, например PASCAL. Но следует иметь в виду существен-
ное отличие. Если в PASCAL ограничение множества допустимых значений
служит лишь для контроля исполнения программы, то в VHDL такое огра-
ничение задает разрядность устройств и связей, представляющих соответст-
вующие данные.
Специфическим понятием языка VHDL является подтип. Данные, отнесен-
ные к подтипу, сохраняют основные свойства данных базового типа и со-
вместимы с ними в выражениях. Но для них определяются дополнительные
ограничения по сравнению с базовым типом, и, возможно, дополнительные
функции, которые относятся только к данным, отнесенным к подтипу.
Среди средств представления поведения системы в реальном времени следу-
ет, прежде всего, отметить средства представления параллелизма в реальной
системе: понятие сигнала, как единицы передаваемой информации между
1
Компоненты VHDL
i
Общеалгоритмический компонент Проблемно -ориентированный компонент
I
Описание поведения Описание поведения

I
(последовательные Структурное описание
во времени
операторы)
Структурное
архитектурное тело
Действи- Представление Описание

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

и охранное выражение ожидания событий
Рис. 3 . 6 . Язык VHDL как программная система

параллельно работающими компонентами; так называемые параллельные

операторы, отражающие непосредственное взаимодействие компонентов;
понятие процесса, как совокупности действий, инициируемой изменениями
сигналов.
При моделировании параллельный оператор интерпретируется таким обра-
зом, что он исполняется при любом изменении сигналов, являющихся его
аргументами, точнее, при отработке реакции на соответствующее событие.
Отметим, что моделирование на основе VHDL -описания должно выпол-
няться на базе дискретной событийной модели. Кроме средств описания
параллельных процессов определены конструкции, явно указывающие пове-
дение объекта проектирования во времени — выражения задержки AFTER,
оператор приостановки WAIT и ряд других.
Средства структурного представления проекта включают оператор вхожде-
ния компонента (Component Instance Statement), задающий тип используе-
мых структурных компонентов и способы их соединений, декларации кон-
фигурации (Configuration Declaration), с помощью которых можно выбирать
вариант реализации включаемого компонента, и ряд других конструкций
языка.
Из представленного предварительного обзора можно видеть, что VHDL
представляет собой развитую алгоритмическую систему, позволяющую опи-
сывать разнообразные структуры и явления в информационных системах.
3.2.2. Структура проекта.

ENTITY и архитектурные тела
Проект в системе проектирования на основе VHDL представлен совокуп-
ностью иерархически связанных текстовых фрагментов, называемых про-
ектными модулями.
Различают первичные и вторичные проектные модули, при этом
<парвичный модуль> ::=
<декларация ENTITY> | <декларация пакета> | <декларация конфигураций
<вторичный модуль> ::= орхитектурное тело> I <тело пакета>
Декларация ENTITY — определяет имя проекта и, необязательно, его интер-

фейс, т. е. порты и параметры настройки. Подчиненное ENTITY архитектур-
ное тело описывает тем или иным способом функционирование устройства
и (или) его структуру.
Пакет — набор объявлений вводимых пользователем типов, переменных,
констант, подпрограмм и т. п. (подобно h -файлам в языке С). Декларация
пакета определяет только смысл глобальных для проекта идентификаторов.
Тело пакета содержит расшифровку порядка вычисления процедур и функ-
ций пакета, определение локальных имен.
Каждому ENTITY сопоставляется одно или и несколько архитектурных тел.

Декларация пакета не требует обязательного присутствия тела пакета. Не-
сколько вторичных модулей, соответствующих одному первичному, состав-
ляют набор возможных альтернативных реализаций объекта, представлен-
ного первичным модулем. Например, одному ENTITY может соответствовать
несколько архитектурных тел, отличающихся степенью детализации описа-
ния и даже алгоритмом преобразования данных, определенных в ENTITY.
Первичные и соответствующие им вторичные модули могут сохраняться в
различных файлах или записываться в одном файле. Важно лишь, чтобы
они были скомпилированы в общую проектную библиотеку, причем пер-
вичный модуль компилируется раньше подчиненного ему вторичного. При
записи первичного и вторичного модуля в одном файле первичный модуль
записывается ранее соответствующего ему вторичного.
Типовой текст программы на языке VHDL имеет следующую структуру:
•CVHDL программа>: : =
«
« <объявление библиотеки> » « <oбъявление использования> »
<первичный модуль>
»
« <вторичный модуль> »
•Составление библиотеки> : : = LIBRARY <имя библиотеки>;
Иными словами, текст представляет произвольный набор первичных и вто-

ричных модулей, причем каждому первичному модулю может предшество-
вать указание на библиотеки и пакеты, информация из которых исполь-
зуется для построения этого модуля. Указание использования (Use Clause)
применяется для различных целей с определенными модификациями син-
таксиса. В данном контексте используется конструкция
<объявление использования>:: =
USE <имя библиотеки>.<имя пакета>.<Имя модуля>
USE <имя библиотеки>.<имя пакета>.АЬЬ
Эта запись определяет место хранения используемой информации. Вариант

записи USE - ALL обеспечивает доступ ко всем модулям объявленного пакета.
Отметим, что даже если несколько первичных модулей в одном програм-
мном файле ссылаются на одинаковые библиотеки и модули, декларация
использования предшествует каждому первичному модулю индивидуально.
Упрощенная форма синтаксиса декларации ENTITY имеет вид:
<Декларация ENTITY> ::=
ENTITY <имя проекта> IS
[<объявление параметров настройки>]
[<объявление портов>]
END [ ENTITY ] <имя проекта>;
<объявление параметров настройки> : : =

GENERIC (<имя>:<тип> [ :=<выражение> ]
«;<имя>:<тип> [ :=<выражение> ] »
);
<объявление портов> : : =
PORT (<имя>:<режим><тип> [<выражение>]
«;<имя>:<режим><тип> [ =<выражение>]»
);
<режим> ::= IN | OUT | INOUT
Объявление параметров настройки включается в ENTITY ДЛЯ создания про-

ектов, которые предполагается использовать как фрагменты в разнообраз-
ных других проектах, причем возможна модификация некоторых свойств
встраиваемого фрагмента, точнее выбор параметра из множества значений,
определенного типом параметра.
Определение портов задает имена входных (IN), ВЫХОДНЫХ (OUT) И двуна-
правленных (INOUT) ЛИНИЙ передачи информации и тип данных, передавае-
мых через порты. Объявление портов, как следует из представленных пра-
вил синтаксиса, не обязательно. Но возникает вопрос: зачем может понадо-
биться устройство, не имеющее входов и выходов? Оказывается, такая
конструкция позволяет эффективно сочетать описание собственно проекти-
руемого устройства и алгоритм его тестирования. Программы, создаваемые
для отладки и называемые Test-Bench, обычно включают описание как са-
мого проектируемого устройства, так и модель внешней среды, в частности
генератор тестового воздействия. Такая система внутренне определена.
Для параметров и входных портов можно задавать значение по умолчанию,
представляемое выражением, отделенным от типа знаками :=. Эти значения
принимаются, если соответствующим единицам информации не присвоены
другие значения в модулях высшего уровня иерархии.
Архитектурные тела представляют содержательное описание проекта. Архи-
тектурное тело в некотором смысле подчинено соответствующему ENTITY.
Различают структурные архитектурные тела (описывающие проект в виде
совокупности компонентов и их соединений), поведенческие архитектурные
тела (описывающие проект как совокупность исполняемых действий) и
смешанные тела. Формальных признаков, по которым архитектурное тело
можно было бы отнести к определенному типу, не вводится — различие
в составе используемых в программе операторов. Определены следующие
правила записи архитектурных тел:
<Архитектурное тело> ::=
ARCHITECTURE <имя архитектуры> OF <имя ENTITY> IS
<раздел деклараций>
BEGIN
<раздел операторов>
END [ ARCHITECTURE ] <имя архитектуры>;
Глава 3. Языки описания дискретных устройств 32?
Здесь имя архитектуры — это любое индивидуальное имя проектного моду-

ля. Имя ENTITY задает первичный модуль, которому подчиняется архитек-
турное тело. В разделе деклараций объявляются локальные для этого модуля
информационные единицы — типы данных, сигналы, подпрограммы и т. д.
Раздел операторов описывает правила функционирования и (или) конструи-
рования устройства в терминах языка.
Одному ENTITY может быть сопоставлено несколько архитектурных тел. Рас-
смотрим в качестве примера совокупность проектных модулей, представ-
ленных в листинге 3.1. Программа описывает устройство, реализующее под-
счет числа разрядов входного шестнадцатиразрядного кода input, установ-
ленных в состояние логической единицы с выдачей результата в числовой
форме на выход output. Одному ENTITY bit_count сопоставлено три архитек-
турных тела, представляющих функционирование устройства с различной
степенью детализации. Формальный синтаксис операторов будет определен
далее, но представляется, что читатель, знакомый с программированием в
общеупотребительных языках, сможет понять суть записанных преобразова-
ний. Следует сделать только два вводных замечания. Во -первых, всякий
фрагмент, начинающийся с двойного тире (--) до конца текущей строки
является комментарием. Во -вторых, присвоение значения в зависимости от
контекста задается либо знаком :=, либо знаком <=, детали представлены в
последующих разделах.
Архитектурное тело, названное pure_behave (чистое поведение), определяет
алгоритм функционирования в самом общем виде и в традиционной форме.
Алгоритм описан как последовательный просмотр битов слова с прибавле-
нием единицы к результату, если очередной бит есть логическая единица.
Хотя компиляторы доступных САПР способны подготовить по этому опи-
санию процедуры моделирования и даже прямую интерпретацию устройства
в БИС, фактическая реализация, как показывает практика, не является оп-
тимальной. В данном случае наблюдались излишние затраты на элементы
суммирования и неэффективность реализации по быстродействию. Дело
в том, что сумма формируется последовательно (заметим, что последова-
тельно не просто во времени, шаг за шагом, как было бы в программных
реализациях, а за счет передачи данных через последовательность устройств,
прибавляющих единицу к коду).
В то же время "чистое поведение" является эффективным способом специ-
фикации устройств и улучшения взаимопонимания между разработчиками.
Кроме того, использование описания в форме "чистого поведения" значи-
тельно повышает скорость выполнения моделирования сложных проектов.
Тогда отдельные фрагменты, которые в данный момент не интересуют про-
ектировщика, представляются в самой общей форме, а разработчик сосредо-
тачивается на фрагментах, требующих детальной отладки. Для практической
реализации целесообразно выполнить декомпозицию устройства. При реа-
лизации сложных проектов такая декомпозиция становится еще более акту -
альной, позволяя разработчику временно ограничить поле интересов наибо-

лее критичными участками и организовать их детальную проработку.
Архитектурное тело four_channel_behave предусматривает параллельный под-
счет единиц в группах по четыре разряда каждая и суммирование промежу-
точных значений. При сохранении самого алгоритма компилятору "подска-
зывается" реализация, обеспечивающая повышение быстродействия за счет
частичного распараллеливания выполняемых действий.
И наконец, в архитектурном теле comb_iogic предпринимается попытка
приблизить описания к реализации в структурах программируемой логики,
построенных на основе ячеек типа "четырехвходовая таблица истинности".
Функция ones_in_thetrade (число единиц в тетраде) здесь будет реализо-
ваться как набор из трех таких ячеек, т. к. каждый разряд кода результата
является функцией четырех разрядов входного кода. Кроме того, в архитек-
турном теле используются конструкции операторов присваивания, в явном
виде задающие задержки компонентов, чем обеспечивается подготовка про-
екта к моделированию с учетом временных параметров.
LIBRARY ieee;
USE ieee.std_logic_1164.ALL; — пакет, содержащий определение
— преобразований данных в многозначном алфавите
USE ieee.std_logic_util.ALL; — пакет, содержащий функции преобразования
— форматов из битового вектора
— в эквивалентное число и наоборот, и т. п.
ENTITY bit_count IS
PORT( input : IN std_logic_vector (15 DOWNTO 0 ) ; — битовый вектор
— в многозначном представлении
output: OUT integer RANGE О ТО 15); — целое в объявленном диапазоне
END bit_count;
ARCHITECTURE pure_behave OF bit_count IS

— декларация встроенной подпрограммы —
FUNCTION bits_in_word( x:std_logic_vector (15 DOWNTO 0))
RETURN integer IS -
VARIABLE i,z :integer RANGE 0 TO 15;
BEGIN z:=0;
FOR i IN 0 TO 16 LOOP — цикл просмотра всех разрядов
IF x(i)='l' THEN — если разряд установлен в единицу
z:=z+l; — прибавить к результату
END IF;
END LOOP;
RETURN z;
END bits_in_word;
— конец декларации подпрограммы —
BEGIN
output<= bits_in_word(input); — вызов подпрограммы
END pure_behave;
ARCHITECTURE four_channel_behave OF bit_count IS

SIGNAL vl,v2,v3,v4: std_logic_vector (3 downto 0 ) ;
FUNCTION ones_in_word(n:integer;
x:std_logic_vector (3 downto 0))
RETURN integer IS
VARIABLE i,z : integer;
BEGIN z:=0;
FOR i IN 0 TO n LOOP
IF x(i)='l' THEN
z:=z+l;
END IF;
END LOOP;
RETURN z;
END ones_in_word;
BEGIN
vl<=input(3 downto 0 ) ; — "разрезание" аргумента
v2<=input(7 downto 4 ) ;
v3<=input(ll downto 8 ) ;
v4<=input(15 downto 12);
— четырехкратный вызов функции подсчета единиц в коде
— и суммирование результатов
output<=ones_in_word(4,vl)+ones_in_word(4,v2)+
ones_in_word(4,v3)+ones_in_word(4,v4);
END four_channel_behave;
ARCHITECTURE comb_logic OF bit_count IS

FUNCTION ones_in_thetrade( x:std_logic_vector (3 downto 0))
RETURN integer IS
VARIABLE z:integer RANGE 0 TO 4;
TYPE LUT IS ARRAY (0 to 15) OF integer;
CONSTANT result: LUT:=
(0,1,1,2,1,2,2,3,1,2,2,3,2,3,3,4); — таблица истинности для функции
— "число единиц в четырехразрядном коде"
BEGIN
z:=conv_integer(х); — преобразование код — номер в таблице
return result(z); — выборка значения из таблицы
END ones_in_thetrade;
SIGNAL numberl,number2, numbers, number4: integer RANGE 0 to 4;
BEGIN
number1=ones_in_thetrade (input (3 downto 0)) AFTER 2 ns;
number2<=ones_in_thetrade (input (7 downto 4)) AFTER 2 ns;
number3<=ones_in_thetrade (input (11 downto 8)) AFTER 2 ns;

number4<=ones_in_thetrade (input (15 downto 12)) After 2 ns;
output<= (numberl+number2 ) + (number3+number4 ) after 10 ns;
END comb_logic;
Функция bits_in_thetrade определяет правило работы некоторой подсхемы.

Альтернативным способом представления "законченных" фрагментов явля-
ется объявление вхождения компонента (Component Instance), которое со-
держит ссылку на ENTITY включаемого библиотечного компонента и указа-
ние порядка его подключения. Формальные правила включения библиотеч-
ных модулей в проект рассмотрены в разд. 3.2.11.
В общем случае, архитектурное тело включает сигналы, процессы и компо-
ненты (точнее их декларации). Процессы, т. е. взаимодействующие объекты,
в архитектурном теле могут быть представлены специальным оператором
PROCESS или так называемыми параллельными операторами. Включаемый
компонент в свою очередь представлен в библиотеке архитектурным телом,
которое содержит сигналы, операторы и включаемые компоненты. При по-
строении общей модели компилятор выполняет детализацию описания пу-
тем увязывания сигналов и компонентов встраиваемых блоков с сигналами
модуля высшего уровня иерархии. Если встроенный компонент содержит
декларации вхождений других компонентов, детализация продолжается. Де-
тализация проекта заканчивается, когда достигнута декомпозиция на архи-
тектурные тела, представленные "чистым поведением", т. е. совокупностью
сигналов и процессов.
3.2.3. Типы данных

Язык VHDL основан на концепции строгой типизации данных, т. е. любой
единице информации в программе должно быть присвоено имя, и для нее
должен быть определен тип. Определение информационной единицы раз-
мещается в разделе деклараций программного модуля, в котором оно ис-
пользуется, или иерархически предшествующего модуля. Тип данных опре-
деляет набор значений объектов, отнесенных к этому типу, а также набор
допустимых преобразований этих данных. Данные разных типов несовмес-
тимы в одном выражении.
Данные, используемые в программах, относятся к одной из категорий: кон-
станты, переменные и сигналы. Различие между сигналами и переменными
определяется в следующем разделе. Декларация объектов имеет следующий
синтаксис:
<декларация объектов> ::=
<категория> <имя>«,<имя>» :<тип> [ :=<выражение>];
<категория> ::= CONSTANT |VARIABLE I SIGNAL
Одна декларация может определять несколько объектов. Выражение в дек-

ларации должно совпадать по типу с декларируемым объектом и задает зна-
чения константы либо начальные значения сигналов и переменных. Про-
стые примеры:
CONSTANT a: integer:=15;
VARIABLE b,c: BIT;
SIGNAL d,e : DOUBLE_WORD;
В последнем примере предполагается, что тип DOUBLE_WORD был ранее оп-

ределен пользователем.
Если декларируемый объект является агрегатом, то в одной декларации
можно определить все компоненты агрегата. Например, пусть определен тип
STACK как массив из восьми целых. Для того чтобы объявить переменную
этого типа и задать ее начальное значение, можно записать:
VARIABLE S t a c k _ i n s t a n t i o n : s t a c k : = (4, 5, 7,129, 64, 7, 87, 67};
Язык VHDL предопределяет некоторый базовый набор типов данных, кото-

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

данных и агрегатные типы. Объект, отнесенный к скалярному типу, рас-

сматривается как законченная единица информации. Агрегат представляет
упорядоченную совокупность скалярных единиц, объединенных одинако-
вым именем. Классификация типов данных VHDL приведена на рис. 3.7.
Предопределенные типы данных

Сначала остановимся на предопределенных типах.
<предопределенные типы>::=
INTEGER | REAL | BIT | BOOLEAN | CHARACTER | STRING | TIME | BIT_VECTOR|
SEVERITY_LEVEL | FILE_OPEN_STATUS | FILE_OPEN_KIND
Типы INTEGER и REAL, определяют ч и с л е н н ы е д а н н ы е — целые и действитель-

ные, соответственно. Д и а п а з о н представления чисел может зависеть от реа-
л и з а ц и и , но стандартными считаются д и а п а з о н ы {—2 3 1 +1, +2 3 1 —1} для типа
38 38
INTEGER и {10 , —10 } д л я REAL. К а к уже упоминалось, числа в проектном
модуле могут представлять к а к к о н ф и г у р а ц и о н н ы е параметры, так и собст-
в е н н о обрабатываемую в проектируемом устройстве и н ф о р м а ц и ю . В по-
следнем случае надо иметь в виду, что число фактически является укоро-
ч е н н о й записью обрабатываемых кодов, но над этими кодами определены
арифметические операции:
- + — сложение или повторение;
- - — вычитание или инверсия;
- * — умножение;
- / — деление;
- mod — ЧИСЛО ПО модулю (5 mod 3 = 2);
- rem — остаток от деления;
- abs — модуль (абсолютное значение числа);
- ** — возведение в степень.
Определены для этих кодов также и операции арифметического отношения
=, /=, <, <=, >=, >, которые дают результат типа BOOLEAN. В арифметических
выражениях предполагаются традиционные способы определения старшин-
ства операций, включая использование скобок.
Данные типа BIT могут принимать значения из множества {'0', ' 1 ' } . На
данных типа B I T определены логические операции:
- NOT — инверсия;
- OR — операция ИЛИ;
- NOR — операция ИЛИ -НЕ;
- AND — операция И;
- NAND — операция И -НЕ;

- XOR — неравнозначность;
- XNOR — равнозначность.
Операции XOR и XNOR в версии VHDL'87 не определены.
Операции определены по правилам положительной логики (a AND Ь дает

значение ' 1', только если оба члена выражения равны ' 1', a a OR ь — если
хоть один из операндов равен ' 1' и т. д.).
Данные типа BOOLEAN также могут принимать два значения: {TRUE, FASLSE}, и
на них определены те же операции, что и над данными типа BOOLEAN. Раз-
ница между типами BIT и BOOLEAN состоит в том, что первые используются
для представления уровней логических сигналов в аппаратуре, а вторые для
представления обобщенных условий, например результатов сравнения. Так,
если переменная select определена как бит, то нельзя записать условный
оператор в виде
IF select THEN ...
следует записывать
IF s e l e c t = ' l ' THEN...
Если бы переменная select была определена как BOOLEAN, то, наоборот, пер-
вый вариант был бы допустим, а второй нет.
Данные разных типов несовместимы, поэтому недопустимо выражение
' О ' AND TRUE
Тип CHARACTER объединяет все символы, определенные в используемой опе-

рационной системе — буквы, цифры, специальные символы. VHDL'87 до-
пускает применение только первых 128 символов кодов ASCII (латинские
буквы, цифры, специальные символы). В тексте программы символьная
константа записывается как стандартный символ, заключенный в одинар-
ные кавычки ('а', ' Ь ' , ' ; ' и т. п.). Отметим, что символы '0' и '1' имеют
двойное назначение — и как символ, и как логическое значение. В каждом
конкретном случае тип определяется по контексту.
Тип TIME — время — используется для задания задержек элементов и време-
ни приостанова процессов при моделировании. Запись временной констан-
ты имеет вид
<целое> <единица измерения времени>
Определены такие единицы измерения времени: fs — фептосекунда, ps —
пикосекунда, ns — наносекунда, us — микросекунда, ms — миллисекунда,
s — секунда.
ТИП SEVERITY_LEVEL задает Следующее множество значений: {note, warning,

error, failure} и используется для управления работой компилятора или
программы моделирования. С помощью переменных и констант этого типа
в операторах ASSERT определяются действия, которые следует выполнить при
обнаружении некоторых условий: просто выдать сообщение (note или
warning), прервать моделирование ИЛИ КОМПИЛЯЦИЮ ( e r r o r И f a i l u r e ) .
ТИПЫ FILE_OPEN_STATUS и FILE_OPEN_KIND обеспечивают ВОЗМОЖНОСТЬ КОНТРО -

ЛЯ процедур обмена между программой моделирования с файловой систе-
мой инструментального компьютера.
Типы STRING и BIT_VECTOR относятся к агрегатным и фактически определены
как неограниченный массив символов и массив битов, соответственно. Бо-
лее подробно правила использования массивов и их элементов рассмотрены
далее. В тексте программы строковая константа заключается в двойные ка-
вычки.
Например, пусть module_type — параметр настройки типа STRING. Тогда
запись
IF (module_type="СУMMATOP") GENERATE
откроет последовательность операторов, которая будет исполняться, только
если задано соответствующее значение параметру.
Пользователь имеет возможность определить собственные типы, используя
декларацию типа:
<декларация типа> ::= ТУРЕ <имя типа> IS <определение типа>;
<Определение типа> :: =
<определение перечислимого типа>
|<определение целого типа>|<определение действительного типа>
|<определение физического типа>
|<определение типа массивов>| Определение типа записей>
Скалярные типы, вводимые пользователем

Определение перечислимого типа имеет вид:
<Определение перечислимого типа> : : =
(перечислимое значение «, перечислимое значение »)
<перечислимое эначение> : : =
<идентификатор> | <символьная константа>
Примеры:
- TYPE s t a t e IS (S0,S1,32,S3)
Может представлять, например, набор допустимых состояний системы,
для каждого состояния определяются выполняемые действия и правила
перехода в другое состояние.
- TYPE colour IS (white, black, red, green, blue, yellow, argenda)

Набор цветов. Переменные этого типа могут использоваться, например,
для управления выводом на дисплей как в сеансах моделирования, так и
в реальных устройствах.
- TYPE s t d _ u l o g i c IS ( 'U', 'X','0','1','Z','W,'L','H','-');
Тип std_uiogic и порождаемый на его основе подтип std_logic ис-
пользуются для представления сигналов в девятизначном алфавите (см.
разд. 3.1.3). Хотя формально эти типы не относятся к предопределенным,
их определение включено в пакет std_logic_H64, являющийся неотъем-
лемой частью всех современных интерпретаторов языка. Иными словами,
эти типы, равно как соответствующий векторный тип std_logic_vector,
можно фактически считать предопределенными.
Определение численных типов пользователя целесообразно, во -первых, для
контроля совместимости данных в программах, а во -вторых, для точного
задания разрядности слов, представляющих данные в проектируемом объек-
те. В общем случае определение ограниченного типа подчиняется синтакси-
ческому правилу:
<определение ограниченного типа> ::=[ <базовый тип> ] <диапазон>
<диапазон>::= RANGE <ограничение><направление><ограничение> | RANGE<>
<направление> ::= DOWNTO | ТО
Направление (TO — увеличение, DOWNTO — уменьшение) должно быть согла-

совано с соотношением ограничений.
Примеры:
TYPE Unsigned_short IS INTEGER RANGE 0 TO 255;
TYPE my_data IS INTEGER RANGE -2**(n -l)+l TO 2**(n -l) -l;
TYPE input_level IS -10.0 TO +10.0;
Тип unsigned_short объединяет целые положительные числа, которые могут

быть представлены в байтовом формате.
Тип my_data объединяет целые в диапазоне, который объявляет пользователь
через разрядность данных п. В этом случае пользователь точно указывает
компилятору число разрядов, необходимое для представления данных, обес-
печивая экономию ресурсов микросхемы по сравнению с неограниченным
типом.
При объявлении типа input_ievei базовый тип явно не задан, используется
тип ограничений в соответствии с типом их фактических значений.
Пусть пользователь в одном проекте вводит два типа:
TYPE data IS integer RANGE О ТО 15;
TYPE controle IS integer RANGE 0 TO 15;
Хотя с точки зрения представления эти типы равноценны, оказывается, что

управляющие сигналы controle и сигналы данных data несовместимы, что
облегчает контроль корректности описания.
Физические типы
Наряду с предопределенным типом TIME пользователь может определить
другие физические типы, которые будут отражать физические (механи-
ческие, электрические или иные) свойства носителя информации.
<определение физического типа> ::=
RANGE <диапазон>
UNITS
<имя базовой единицы>
<имя вторичной единицы> = << <значение единицы> »
END UNITS [ <имя типа>];
Пример:
TYPE v o l t a g e IS RANGE -5E6 to +5E6;
UNITS uV; — базовая единица — микровольт
mV= 1000 uV; — милливольт
V=1000 mV; — вольт
END UNITS v o l t a g e ;
Введение такого типа позволяет описывать и моделировать сопряжение

цифровой логической схемы с аналоговыми источниками. Пусть входной
порт analog_input И константа threshhold (порог) объявлены как voltage, a
сигнал compare (сравнение) как BIT. Тогда можно записать:
compare <= '1' WHEN analog_input>threshhold ELSE
'0';
Массивы и записи
Массив, как и в других языках, — это набор данных, объединенных общим
именем и различаемых по порядковым номерам (индексам). Для того чтобы
вводить объект типа массив, необходимо предварительно объявить соответ-
ствующий тип на основе следующих синтаксических правил:
<определение типа массива> ::=
ARRAY ( <диапазон> «, <диапазон> ») OF
<тип элемента массива>
Диапазон задает множество допустимых значений индекса. Число измере-

ний массива формально не ограничено. Если диапазон задан конструкцией
RANGE<>, то это является объявлением неограниченного массива. В этом слу-
чае определяется не диапазон значений индекса, а только тип индексной
переменной. Такое определение предполагает задание диапазона при опре-

делении конкретного экземпляра объекта, относимого к такому типу, на-
пример, при вызове подпрограмм. В подобных случаях диапазон устанавли-
вается динамически в соответствии с диапазоном подставляемого фактиче-
ского параметра.
Примеры:
TYPE ram IS ARRAY (length -1 DOWNTO 0) OF integer
RANGE 2**width -l DOWNTO 0;
TYPE raml IS ARRAY (length -1 DOWNTO 0,width -1 DOWNTO 0) OF std_logic;
TYPE ram2 is ARRAY ( integer RANGEO, integer RANGE <>) OF std_logic;
Во всех приведенных декларациях объявляется в сущности одно и то же,

а именно матрица ячеек памяти емкостью length слов по width разрядов в
каждом, причем предполагается, что эти параметры были ранее определены.
Однако выполнено это разными способами, а значит, и ссылаться на эти
типы следует по -разному. RAM и RAMI определены как ограниченные типы
массивов, ram — как одномерный массив целых, a raml — как двумерный
массив битов. RAM2 определен как неограниченный тип и требует задания
границ индексов при декларации объектов выбранного типа.
Декларации объектов, принадлежащих приведенным типам, могут выглядеть
следующим образом:
VARIABLE ram_instance: ram;
VARIABLE raml_instance: raml;
VARIABLE ram2_ins: ram2 (length -1 downto 0,width -l downto 0 ) ;
При обращении к элементам массива в программе индексы помещаются

в скобках следом за именем массива. Тип индексного выражения должен
соответствовать типу индекса, объявленного при декларации типа массива.
При обращении к элементу многомерного массива индексные выражения
записываются через запятые в порядке, определенном в декларации типа.
ram2_ins(у,5):=хО; — хО определено как бит; у — целое;
z<= raml_instance (Y) — Y и z — целые
Для одномерных массивов определено несколько групповых операций,

в которых массив рассматривается как единое целое. Это, прежде всего, опе-
рация конкатенации & (объединение строк). Например, приведенная ниже
последовательность операторов присваивает сигналу ь значение " l i o n o o i " .
а:="1001";
Ь<= "1101" & а;
Здесь: а и ь — строки или битовые векторы, причем а — переменная,

а ь — сигнал.
Операции сдвига определены для одномерных массивов типа BIT или

BOOLEAN и записываются следующим образом:
<имя массива> <символ операции сдвига> <целое>
В VHDL'93 определены следующие операции сдвига: логические сдвиги

влево и вправо s i i и sri, арифметические сдвиги влево и вправо sla и зга,
циклические сдвиги влево и вправо roi и гог.
Целое в записи выражения для сдвига определяет число разрядов, на кото-
рые осуществляется сдвиг кода.
В VHDL'87 операции сдвига не определены.
В составе ряда САПР поставляются пакеты, определяющие арифметические

операции над битовыми массивами (кодами). Так, в системе проектирова-
ния MAX+plus П арифметические операции над кодами определяются во
встроенном пакете std_iogic_arith.
Запись — эта структура данных, каждая информационная единица которой,
называемая полем записи, имеет индивидуальное имя и может быть инди-
видуального типа. Обычно записи используются для агрегатирования раз-
личных данных, характеризующих один объект. Для использования записей
как переменных сначала надо объявить соответствующий тип:
•Определение типа эаписи> ::=
RECORD <список полей записи: тип>;
«<список полей записи: тип>;>>
END RECORD;
Пример. Определим тип pixel, представляющий цветовые составляющие

отображения точки на экране в формате FULL COLOR (полная цветопере-
дача), предусматривающем восьмиразрядное представление трех цветовых
составляющих.
TYPE pixel IS
RECORD red,green,blue: integer RANGE 0 TO 255;
END RECORD;
Тогда тип "видеопамять" может быть определен как

TYPE video_ram IS ARRAY(integer RANGEO,integer RANGE <>) OF pixel;
Экземпляр видеопамяти будет определяться, например, следующим образом:

SIGNAL VRAM : video_ram (679 DOWNTO 0, 839. DOWNTO 0);
Этот экземпляр может сохранять информацию об изображении размером

680 строк по 840 элементов в строке. Выборка значения красной состав -
ляющей верхнего левого элемента изображения из такой памяти описывает-

ся оператором
Out_red <= VRAM ( 0 , 0 ) . r e d ;
Следующий пример определяет обобщенный тип для представления конеч-

ных автоматов. Автомат, как известно, определяется множеством входов,
множеством состояний и множеством выходов, а также соответствующими
функциями на этих множествах. Значит, можно ввести универсальный тип
TYPE state_machine IS
RECORD s:state;
x:machine_input;
у:machine_output;
END RECORD;
Здесь state, machine_input и machine_output — ранее определенные пере-

числимые типы.
Функции переходов и выходов конкретного экземпляра автомата будут
определяться в разделе операторов соответствующего архитектурного тела.
Подтипы
Специфическим понятием языка VHDL является подтип. Объекты, отне-
сенные к подтипу, сохраняют совместимость с данными типа, из которого
выделяется подтип так называемого базового типа. Однако введение под-
типа:
О определяет множество допустимых значений данных подтипа как под-
множество допустимых значений базового типа;
О позволяет вводить дополнительные функции преобразования, определяе-
мые только для данных подтипа.
Синтаксис декларации подтипа определен следующим образом:
<двкларация подтипа> ::=
<имя подтипа> IS [<имя функции разрешения> ]
<имя базового типа или подтипа> [<ограничение>];
Пример:
SUBTYPE bit_in_word_number IS integer RANGE 31 DOWNTO 0;
Определен подтип типа integer. Данные этого подтипа предполагается ис-

пользовать для индексации бита в 32 -разрядном коде. Данные совместимы
с данными типа integer. Однако присвоение этим данным значений вне
указанного диапазона вызывает сообщение об ошибке.
3.2.4. Сигналы и переменные.

Оператор PROCESS
Любой проект является описанием явлений в дискретных системах. Эти яв-
ления могут представляться тремя различными категориями данных: кон-
станты, переменные и сигналы. SIGNAL — это информация, передаваемая
между модулями проекта или представляющая входные и выходные данные
проектируемого устройства. Сигналу присваиваются свойства изменения во
времени. VARIABLE — это вспомогательная информационная единица, ис-
пользуемая для описания внутренних операций в программных блоках.
Присвоение значения сигналу отображается знаком <=, а переменной —
знаком :=.
Для того чтобы представить различия сигналов и переменных, следует сде-
лать несколько предварительных замечаний. В языке VHDL введены два типа
операторов — последовательные и параллельные. Последовательные операторы
выполняются последовательно друг за другом в порядке записи. Такие опе-
раторы во многом подобны операторам традиционных языков программиро-
вания и описывают набор действий, которые последовательно выполняются
над исходными данными с целью получения результата. К этому классу
операторов относят оператор присваивания переменной, последовательный
оператор присваивания сигналу, условные операторы, оператор выбора и
ряд других.
Исполнение параллельных операторов инициируется не по последовательно-
му, а по событийному принципу, т. е. они исполняются тогда, когда реали-
зация других операторов программы создала условия для их исполнения.
Параллельные операторы представляют части алгоритма, которые в реаль-
ной системе могут исполняться одновременно. Эти части взаимодействуют
между собой и с окружением проектируемой системы. Параллельные опера-
торы могут быть простыми и составными. Составной оператор включает не-
сколько простых операторов, для которых определены общие условия ини-
циализации. Такая совокупность операторов называется телом составного
оператора. Важнейшим составным оператором является оператор процесса
PROCESS, синтаксис которого определен следующим образом:
<оператор процесса> : : =
[ <метка процесса>:] PROCESS[ ( <список инициализаторов:^ ] [ IS ]
<раздел деклараций>
BEGIN
« <раздел операторов>»
END PROCESS [<метка процесса>];
<раэдел операторов> ::=« <последовательный оператор>»
Ключевое слово is в версии VHDL'93 является необязательным, а в VHDL'87

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

PROCESS. При моделировании фрагменты алгоритма, заключенные в опера-
тор PROCESS, будут исполняться друг за другом после возникновения в сис-
теме "инициализирующего события" — изменении одного из сигналов, пе-
речисленных в списке инициализаторов, или в заранее определенный мо-
мент времени. Параллельные операторы в теле процесса не определены.
Переменные могут быть определены только в теле процесса, а сигналы во
всем архитектурном теле.
( Замечание ^
Некоторые параллельные и последовательные операторы совпадают по фор-
ме записи. В этом случае различие устанавливается по контексту: если опера-
тор локализован в теле процесса, он трактуется как последовательный, а если
в другом месте программы — как параллельный.
Наиболее явно разница между сигналами и переменными проявляется при

интерпретации операторов последовательных присвоений. Для обоих видов
сохраняется общее для последовательных операторов правило начала испол-
нения: первый оператор в процессе исполняется после выполнения условий
инициализации процесса, а каждый следующий сразу после исполнения
предыдущего. Однако результат присвоения переменной непосредственно
доступен любому последующему оператору в теле процесса. Трактовка опе-
ратора последовательного присвоения сигналу существенно отличается от
трактовки присвоения переменной или операторов присваивания в тради-
ционных языках программирования. Присвоение сигналу не приводит не-
посредственно к изменению его значения. Новое значение сначала заносит-
ся в буфер, называемый драйвером сигнала, и следующие операторы в теле
процесса оперируют со старыми значениями. Фактическое изменение зна-
чения сигнала выполняется только после исполнения до конца процессов и
других параллельных операторов, инициированных общим событием, или
после исполнения оператора останова WAIT (см. разд. 3.2.6).
Общие правила интерпретации оператора PROCESS можно свести к следующим:
П PROCESS "запускается" при изменении любого сигнала, перечисленного
в списке инициализаторов.
Если список инициализаторов пуст, то процесс безусловно исполняется
при начальном запуске, а также сразу за исполнением последнего опера-
тора в разделе операторов этого процесса. При этом надо иметь в виду,
что оператор процесса без списка инициализаторов обязательно должен
содержать в своем теле оператор ожидания WAIT. Иначе исполнение лю-
бых других операторов в программе блокируется.
П Все операторы раздела операторов выполняются подряд друг за другом от
начала до конца, за исключением случаев приостановки исполнения дей -
ствий оператором WAIT. Тогда после приостановки может быть иниции-

ровано исполнение других процессов и параллельных операторов, а реа-
лизация операторов, следующих за оператором WAIT, продолжится после
наступления события, объявленного в этом операторе.
Раздел деклараций определяет локальные объекты, используемые в следую-
щем за ним программном блоке, в данном случае, в разделе операторов.
Рассмотрим проектный модуль, объявленный ENTITY two_j>rocess_exampie и
представленный архитектурным телом test (листинг 3.2). Проект не имеет
портов. Это является иллюстрацией реализации Test -Bench, т. е. внутренне
определенного модуля, создаваемого для проверки функционирования неко-
торого узла. Модуль содержит описание исследуемого узла, в данном случае
комбинационной схемы, представленной оператором, отмеченным меткой
ui, и генератора тестового воздействия, выделенного меткой stimulator.
Связи между узлами проекта представлены сигналами хО, xi и х2. Кроме
того, выход логической схемы представлен сигналом z, который может от-
ражаться в качестве результата программой моделирования. Операторы
PROCESS включают определение вспомогательных внутренних переменных
yi, у2, i и stim_vector. Отметим, что stim_vector — вектор стимулирующего
возмущения — является кодовым эквивалентом номера цикла моделирова-
ния и получается из него с использованием функции conv_vector, опреде-
ленной в пакете std_iogic_utii. Процесс stimulator безусловно запускается
в начале сеанса моделирования. Оператор WAIT приостанавливает исполне-
ние последовательности вложенных операторов на 50 пс модельного време-
ни. В этот момент изменения сигналов хО, xi или х2 инициируют исполне-
ние процесса ui, все вложенные операторы которого безусловно исполня-
ются друг за другом до конца.
Интересно, что единственное изменение переменной stim_vector и соответ-
ствующих сигналов может вызвать несколько повторений выполнения опе-
раторов в процессе и2. Дело в том, что для процесса и2 изменение любого
бита входного вектора является событием, вызывающим его исполнение, а
значит, если в векторе меняются несколько битов, процесс инициируется
несколько раз. Это можно наблюдать при моделировании в пошаговом ре-
жиме в системе интерпретации VHDL -программ фирмы Model Technology.
По истечении времени приостанова, если тест еще не выполнен до конца,
происходит повторение операторов процесса stimulator с начала. Заметим,
что переменные в VHDL трактуются как статические данные, т. е. при каж-
дом следующем исполнении процесса используются значения, определен-
ные при предыдущем исполнении вплоть до очередного присвоения.
Когда тестовая последовательность исчерпана (в данном случае i=8, и выда-
ны все необходимые кодовые комбинации), оператором ASSERT выдается со-
общение, и сеанс оканчивается оператором "бесконечного останова" WAIT.
LIBRARY ieee
USE ieee.std_logic_1164.ALL;
USE work.std_logic_util.all;
USE STD.textio.ALL;
ENTITY two_j>rocess_example IS
END labl;
ARCHITECTURE test OF twojprocess_example IS

SIGNAL z, xO,xl,x2:std_logic;
BEGIN
ul:PROCESS(xO,xl,x2)
VARIABLE yl,y2:std_logic;
BEGIN
yl:=xO and (not xl) and x2;
y2:=xO and (not xl) and (not x2);
z<= yl or y2;
END PROCESS;
stimulator: PROCESS
VARIABLE i:integer:=0;
VARIABLE stim_vector:std_logic__vector(2 DOWNTO 0 ) ;
BEGIN
stim_vector:=conv_std_logic_vector(i,3);
xO<= stim_vector(0);
xl<= stim_vector(1);
x2<= stim_vector(2);
WAIT FOR 50 ns;
i:=i+l;
if (i=8) then
ASSERT false REPORT "End of Stimulation !"
SEVERITY NOTE;
WAIT;
END IF
END PROCESS;
END test;
Укажем на некоторые наиболее существенные различия сигналов и пере-

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

ратору присваивания сопоставляется некий буфер, называемый контей-
нером или, чаще, драйвером сигнала [6, 34]. Оператор присваивания пе-
редает новое значение драйверу сигнала, и лишь после того, как выпол-
нены преобразования во всех процессах, инициированных общим
событием, содержание драйвера передается сигналу. Передача значения
сигналу может быть еще более задержана, если оператор присваивания
содержит выражение задержки AFTER.
П Переменная определена только внутри тела процесса, сигнал — во всем
архитектурном теле.
О Переменной можно переприсваивать значение в теле процесса. Сигнал
внутри одного процесса может иметь только один драйвер. То есть при-
своение значения сигналу может быть выполнено только один раз в теле
процесса (на различных несовместимых путях реализации алгоритма мо-
гут быть несколько операторов присваивания значений одному сигналу).
Проследим эту разницу на примерах. В листингах 3.3, а и 3.3, б приведены
фрагменты программ, описывающих одну и ту же совокупность преобразо-
ваний, но в первом случае именем cs обозначен сигнал, а во втором именем
cv — переменная.
Signal elk: bit; Signal clkrbit;

signal cS, b: integer; signal b: integer;
constant a,d: integer:=10; constant a,d: integer:=10;
process (elk)
process
(elk) variable cV;
begin cS<= a; begin cV:= a;
b<=cS+d; b<=cV+d;
— cS<=b; —недопустимо cV:=b
end process; end process;
Если перед исполнением этих процессов (после изменения elk) сигнал cs и

переменная cv имели значение 4, а ь = 3, то после реализации процесса в
листинге 3.3, a cs и ь примут значение 14, т. к. присвоение значения сигна-
лу cs в первом операторе тела не влияет на следующие операторы.
Во втором случае при тех же исходных данных после завершения процесса
получим ь = 20 и cv = 20.
3.2.5. Атрибуты в языке VHDL

Атрибуты — скаляры, отражающие некоторые свойства объектов, исполь-
зуемых в программных модулях (типов, переменных, агрегатов). Например,
атрибуты типа используются для сжатого представления информации о
множестве значений, объединенных типом, а атрибуты сигнала — для пред-
ставления временных свойств сигнала. В разделах операторов нельзя при-
сваивать значение атрибуту, способ его определения задается декларацией
атрибута. Атрибуту присваивается имя и тип, имя используется как обычная
переменная в выражениях того типа, который присвоен атрибуту. Имя атри-
бута записывается следующим образом:
<имя атрибута> : : =
<имя атрибутируемого объекта>'<конструктор атрибута> [(<выражение>)]
Конструктор атрибута определяет свойство объекта, представляемое атрибу-

том. Необязательное выражение может задавать дополнительные данные,
используемые для вычисления значения атрибута.
Бывают предопределенные атрибуты и атрибуты, вводимые программистом.
В данной книге мы ограничимся только представлением наиболее употреби-
тельных предопределенных атрибутов.
Предопределенные атрибуты типов приведены в табл. 3.2. Здесь т — имя
типа. N — целое, ах — "вспомогательное" выражение, тип которого совпада-
ет с типом т. Тип перечисленных атрибутов, кроме т'роз и т'image, совпа-
дает с атрибутируемым типом. Атрибут т'роз — принимает целое значение,
а Т' image — строка.
Таблица 3.2. Предопределенные атрибуты типов

Вид атрибута Вычисляемое значение Атрибутируемый тип
т'left Левая граница значений т Любой скалярный

т' r i g h t Правая граница значений т Любой скалярный
т' low Нижняя граница значений т Численный, физический
т' high Верхняя граница значений т Численный, физический
т' image (X) Строка символов, представляющая Любой
значение х
т' роз (х) Позиция значения х в наборе Перечислимый
значений т
т' v a l (N) Значение элемента в позиции N Перечислимый,
в наборе значений т физический, целый
т' l e f t o f (X) Значение в наборе значений т, Перечислимый,
записанное в позиции слева от X физический, целый
Вид атрибута Вычисляемое значение Атрибутируемый тип
т' r i g h t o f (X) Значение в наборе значений т, Перечислимый,

записанное в позиции справа от х физический, целый
т' pred (X) Значение в наборе значений т Перечислимый,
на одну позицию меньшее х физический, целый
т' succ (X) Значение в наборе значений т Перечислимый,
на одну позицию большее х физический, целый
Для перечислимых типов номер позиции значения отсчитывается от нуля,

присвоенного крайнему левому значению с инкрементом номера позиции
для каждого следующего значения. Для перечислимых типов справедливо:
T'leftof = Т'pred; (3.1)
Т'left = Т'low; (3.2)
Т'right = Т'high; (3.3)
Т'rightof = Т'succ. (3.4)
Например, для типа std_iogic справедливо:

Std_logic'low = 'U';
Std_logic'pos('1') = 3;
Std_logic'val (7) = 'H';
Std_logic'succ('Z') = 'W
Пусть совокупность возможных состояний некоторого устройства объявлена

типом
TYPE s t a t e IS :=( sO, s i , s2, s3, s4, s5)
а текущее состояние представлено сигналом current_state. Рассмотрим по-

ведение фрагмента, представленного процессом:
PROCESS
IF current_state = state'right THEN
current_state<=state'left;
ELSE current_state <=state'succ(current_state);
WAIT 100 nS;
END IF;
END PROCESS;
Через каждые 100 не происходит инициализация этого процесса и изме-

нение состояния. Устройство поочередно принимает состояния в порядке
записи в списке значений типа от s о до s 5, а из s 5 выполняется переход

в начальное состояние so.
Для атрибутов целых типов номер позиции совпадает с фактическим значе-
нием вспомогательного выражения, а для атрибутов физических типов —
числом базовых единиц в значении вспомогательного выражения. Может
показаться, что такое определение является тавтологией. Однако это не так.
Позиция, в отличие от аргумента, не несет физического смысла и, как гово-
рят, представлена "анонимным целым", позволяющим объединять в выра-
жениях свойства различных носителей информации.
Пусть требуется определять заряд Q, передаваемый по некоторой цепи по-
стоянным током i за время т. Тогда следует объявить соответствующие типы
и переменные:
TYPE current IS range integer'low TO integer'high;
UNITS uA; — микроампер;
mA= 1000 uA; — миллиампер;
A=1000 mA; — ампер;
END UNITS current;
TYPE charge IS range integer'low to integer'high
UNITS pQ; — пикокулон;
uQ= 1000 pQ;
END UNITS current;
VARIABLE I : current;
VARIABLE Q : charge;
VARIABLE Т : time;
Тогда оператор вычисления заряда можно записать следующим образом:

Q:= charge'val ( current'pos( I) * time'pos( T) * E -9);
Множитель Е -9 согласует размерности единиц измерения. Напомним, что

базовой единицей времени является фептосекунда (1 фс = 10~15 с).
СМЫСЛ КОНСТрукТОрОВ leftof, pred, left, low, right, high, rightof, succ ДЛЯ Ц6 -
лых и физических типов зависит от направления (то или DOWNTO), объявленного
в декларации типа. Если объявлено прямое направление, то справедливы
правила (3.1—3.4), а если обратное, то T'ieft= T'high; T'ieftof= T'succ
и т. д.
Предопределенные атрибуты массивов, приведенные в табл. 3.3, упрощают
запись подпрограмм и описаний настраиваемых модулей. Они, в частности,
позволяют записывать границы обработки безотносительно к фактическому
размеру массива.
В табл. 3.3 А — имя типа массива, а N — порядковый номер измерения
многомерного массива. Для одномерного массива N = I , но можно выражение
в скобках при записи атрибута вообще опускать. Тип результата всегда сов -
падает с типом индекса. Смысл конструкторов left, low, right, high такой
же, как у конструкторов типов.
Таблица 3.3, Предопределенные атрибуты массивов
Имя атрибута Результат

A'left(N) Левая граница диапазона индексов А/ -й координаты
массива А
A1right(N) Правая граница диапазона индексов А/ -Й координаты
массива А
A'low(N) Нижняя граница диапазона индексов W -й координаты
массива А
A1high(N) Верхняя граница диапазона индексов ЛАЙ координаты
массива А
A'range(N) Диапазон индексов Л/ -й координаты массива А
1
A reverse_range (N) Обратный диапазон индексов ЛАЙ координаты массива А
A'length(N) Диапазон индексов ЛАй координаты массива А
В качестве примера листинг 3.4 представляет декларацию функции glue,

аргумент которой есть битовый массив типа arr_type, который определен
в вызывающей программе, а возвращаемое значение — вектор, объединяю-
щий четыре старших и четыре младших бита аргумента.
FUNCTION glue (x:arr_type) return bit_,_vector (7 downto 0) IS

BEGIN
RETURN ( x(arr_type'right downto arr_type'right -3)
& x(arr_type'left+3 downto arr_type'left));
END glue;
Замечание
Конструктор range возвращает не одно значение, а множество значений "от -
до". Например, для типа массива
TYPE byte IS ARRAY (7 downto) OF bit;
атрибут byte 'range принимает значение ""7 DOWNTO о", атрибут
byte ' reverse_range — значение "О то 7", а атрибут byte ' length — значе-
ние 8.
Атрибуты сигналов являются эффективным средством анализа поведения
сигнала во времени. В табл. 3.4 символ s означает имя сигнала.
Таблица 3.4. Атрибуты сигналов

Имя атрибута Тип атрибута Значение
S1 DELAYED (Т) То Же, ЧТО у S Значение S, существовавшее на время т перед
вычислением атрибута
S'EVENT BOOLEAN Сигнализирует об изменении сигнала
S'STABLE BOOLEAN S'STABLE = n o t S1EVENT
S'ACTIVE BOOLEAN TRUE, если присвоение сигналу выполнено, но
значение еще не изменено (не кончен времен-
ной интервал, заданный выражением a f t e r )
S1QUIET BOOLEAN S 1 ACTIVE = n o t S'QUIET
S'LAST_EVENT TIME Время от момента вычисления атрибута до по-
следнего перед этим изменения сигнала
S'LAST ACTIVE TIME Время от момента вычисления атрибута до по-
следнего присвоения значения сигналу (не
совпадает с last_event при наличии слова
a f t e r в определяющем выражении)
Например, в конструкции
IF current_state'event THEN <оператор>;
вложенный оператор будет исполняться только, если в момент инициализа-
ции исполнения этой конструкции сигнал current_state меняет свое зна-
чение.
Выражение
а=а'DELAYED (5 ns)
истинно, если сигнал а не менял свое значение в течение 5 не модельного
времени до вычисления этого выражения.
3.2.6. Последовательные операторы

Последовательные операторы (Sequential Statement) по характеру исполне-
ния подобны операторам традиционных языков программирования. Опера-
торы этого типа обязательно "вложены" в оператор PROCESS или подпро-
грамму и выполняются последовательно друг за другом в порядке записи.
Результаты исполнения последовательных операторов недоступны прочим
программным модулям по крайней мере до того, как будет выполнен опера-
тор ожидания WAIT, или не будут выполнены до конца все процессы, ини-
циированные общим событием. Это можно трактовать так, что с точки эре -
ния "окружения" все операторы, в теле процесса от его начала до оператора

WAIT, а при отсутствии WAIT — до конца тела, исполняются одномоментно.
При использовании выражения задержки сигнала AFTER изменение сигнала
прогнозируется на еще более отстоящий момент времени.
Ниже приведен полный список последовательных операторов языка.
•последовательный оператор> ::=
<оператор ожидания>
<оператор проверки>
•«^последовательное сигнальное присваивание>
<присваивание переменной>
<вызов процедуры>
<условный оператор>
<оператор выбора>
<оператор повторения>
<оператор перехода к новому циклу>
<оператор выхода из цикла>
<оператор возврата>
<пустой оператор>
Перейдем к последовательному рассмотрению этих операторов (исключение

составят операторы вызова процедуры и возврата, которые будут рассмотре-
ны специально в разд. 3.2.9).
Операторы присваивания
Эти операторы уже затрагивались в разд. 3.2.2 и 3.2.3. Здесь подробнее
рассмотрим последовательное сигнальное присваивание (необходимо отличать
последовательное сигнальное присваивание от параллельного присваива -
нияния, подробно рассмотренного в разд. 3.2.7). Синтаксическая формула
оператора присваивания значения сигналу имеет вид:
<оператор присваивания сигналу> :: -
<приемник> < - [ <модель задержки>] <прогноз поведения>;
<модель эадвржки> ::=
TRANSPORT | [ REJECT <вьгражение времени> ] INERTIAL
•Спрогноэ поввдения> ::= <элемент поведения> «, Олемент поведения> »
<элвмвнт поввдания> ::= <эначащее выражение> [AFTER <выражение времени>]
Приемник — объект сигнальной категории, представленный простым име-

нем или компонентом агрегатного сигнала. Прогноз поведения (в стандар-
тах VHDL — Wave -form, временная диаграмма) задает порядок изменения
сигнала после события, инициирующего исполнение этого оператора. При
этом временные интервалы для определения переходов задаются относи-
тельно времени возникновения инициирующего события.
Значащее выражение — любое выражение, дающее результат того же типа,

что и приемник.
Например, сигнал, соответствующий временной диаграмме, приведенной на
рис. 3.8, описывается оператором:
х < = 4 ' AFTER 5 n s , 'O'AFTER 2 0 n s , ' Z ' AFTER 50 n s , ' 0 ' AFTER 70 n s ; (3.5)
5ns
20ns
50 ns
70ns
Рис. З.8. Пример временной диаграммы
Если временное выражение опущено, полагается нулевая задержка (так на-

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

х<= transport 'Z' after 35 ns;
будет сформирована временная диаграмма, представленная на рис. 3.9.

Штриховая линия для сравнения представляет прогноз, сформированный
присвоением (3.5).
5 ns
4->
20ns
30 ns
50 ns
70ns
Рис. 3.9. Исключение переходов при транспортной модели задержки
По умолчанию, а также если использовано объявление INERTIAL, предпола-

гается инерционная задержка. В VHDL'87 слово INERTIAL не определено,
инерционная задержка выбирается по умолчанию при отсутствии опции
"модель задержки".
Инерционная модель используется для описания устройств, не реагирую-
щих на импульсы, длительность которых меньше некоторого наперед задан-
ного значения. В этом случае, подобно транспортной задержке, в календарь
событий добавляются новые предсказанные переходы и удаляются все пере-
ходы, предсказанные в предшествующих присвоениях на время большее
времени нового прогнозируемого перехода. После этого просматривается
интервал модельного времени, который предшествует новому предсказы-
ваемому переходу и длительность которого определена временным выраже-
нием в подстроке REJECT. Все переходы в этом интервале, которые приводят
к значению, отличающемуся от нового предсказания, удаляются. Если клю-
чевое слово REJECT отсутствует, то интервал, в котором выполняется такое
удаление, определяется значением, указанным после слова AFTER.
Пусть через 10 не модельного времени после выполнения присвоения (3.5)
выполнен оператор:
х<= INERTIAL ' Z ' AFTER 20 n s ;
Тогда временная диаграмма модифицируется до вида, приведенного на
рис. 3.10. Нетрудно видеть, что короткий переход в состояние логического
нуля удален.
1
' 1
5ns
20ns
50ns
4 ^
П
70 ns
Рис. 3.10. Исключение переходов при инерционной модели задержки
Оператор условия и оператор выбора

Оператор условия I F и оператор выбора CASE позволяют описывать совокуп-
ности действий, некоторые из которых исполняются при возникновении
определенных условий в реальном устройстве и при моделировании, а иные
при тех же условиях не исполняются.
<оператор условия> ::=
IF <булевское выражениеХГМДО
<оператор> «<оператор> »
«ELSIF <булевское выражение> THEN
<оператор> «<олератор> »
»
[ ELSE <оператор> «<оператор> » ]
END IF;
В качестве операторов в приведенной конструкции могут выступать любые

последовательные операторы, в том числе и операторы условия или выбора.
В этом случае говорят об иерархическом вложении операторов. Формальных
ограничений на глубину вложений не вводится, хотя надо иметь в виду, что
некоторые компиляторы могут оказаться неспособны выполнить прямую
реализацию в аппаратуре синтаксических конструкций с большим числом
уровней вложения. Для пояснения порядка исполнения оператора рассмот-
рим менее формальную, но достаточно обобщенную форму его записи:
IF Bi THEN Si
ELSIF Bi THEN Si
ELSIF B2 THEN S2
. . — и т. д.
ELSIF Bn THEN Sn
ELSE S n+ i
END I F ;
где BI, B2, B3, ..., BI, ..., Bn — булевские выражения; Si, s 2 , s 3 , ..., Si, ..., sn,
Sn+i — совокупности последовательных операторов.
Сначала выполняется последовательное, в порядке вхождения в оператор

условия, вычисление булевских выражений BI, в 2 , в3, ..., Б! до тех пор, пока
для одного из них (допустим, вО не получено значение TRUE. Тогда выпол-
няется одна и только одна совокупность з 1 5 записанная непосредственно за
выражением "ELSIF в г THEN". Любая совокупность Si может содержать не-
сколько последовательных операторов или всего один оператор, но не менее
одного последовательного оператора. После этого исполнение оператора
условия прекращается, т. е. последующие булевские выражения не прове-
ряются и, соответственно, совокупности S, для />/' не выполняются. Если
при каком -либо условии никаких действий не предусмотрено, то все равно
после этого выражения проверки данного условия должен размещаться опе-
ратор, в данном случае пустой оператор.
с Замечание
Пустой оператор NULL, в принципе, может быть записан в любом месте в теле
процесса или подпрограммы. Но именно в операторах условия и выбора его
использование имеет явно определенный смысл.
Если вычисление ни одного из булевских выражений не дало значения TRUE,
выполняется совокупность sn+i, а если при этом ключевое слово ELSE отсут-
ствует, то не выполняется никаких действий.
Разберем несколько примеров.
Сначала рассмотрим простейшую конструкцию без использования ключе-
вого слова ELSE:
IF en='l' THEN register_state:= data;
END IF;
Здесь при en, не равном логической единице, ничего не происходит.
Процесс, представленный в листинге 3.5, содержит условный оператор в
"полной форме". Нетрудно убедиться, что описана реализация двух логиче-
ских функций:
Q= a AND b; P= a XNOR b
example_IF_l:PROCESS (a,b)
BEGIN
IF a = '!' AND b = '!' THEN
q <= '!'; P<= '!'
ELSIF a = '0' AND b = '0' THEN
q <= '0'; p<=4'
ELSE q <= '0'; p<='0'
END IF;
END PROCESS example_IF_l;
В следующем примере (листинг 3.6) описан регулятор температуры, входами

которого являются сигнал датчика температуры temperature и логический
сигнал включения регулировки enabie_reguiation, а выходами — логические
сигналы intensive_heat — сигнал включения интенсивного нагрева,
siow_heat — слабый подогрев, cooling — охлаждение, например, включение
вентилятора.
ENTITY temperature_controle IS
PORT ( temperature: IN i n t e g e r ( 50 downto 0);
enable_regulation: IN b i t ;
i n t e n s i v e _ h e a t , slow_heat, cooling: OUT b i t )
END temperature_controle;
ARCHITECTURE behave OF temperature_controle IS
BEGIN
PROCESS
BEGIN
IF Enable_regulation='0' then Intensive_Heat<='0';—прекращение работы
Slow_heat<='0';
Cooling<='0';
ELSIF temperature>30 then — повышенная температура
Intensive_Heat<='0';
Slow_heat<='0';
Cooling<='l';
ELSIF temperature>20 then NULL; — нормальная температура
ELSIF temperature>10 then — слегка пониженная температура
Intensive_Heat<='0';
Slow_heat<=4';
Cooling<='0';
ELSE Intensive_Heat<='l'; — очень низкая температура
Slow_heat<='0';
WAIT FOR 1 sec;
END PROCESS;
END BEHAVE;
BNF -форма оператора выбора имеет вид:
•Соператор выбора> : : =
CASE <Кшочевое выражение> IS
WHEN <вариант> «|<вариант>» => <оператор> « <оператор> »
« WHEN <вариант> «|<вариант>» => <оператор> «<оператор> » »
END CASE;
<вариант> ::= <константное выражение> I <диапазон> | OTHERS
В качестве разделителя в списках выбираемых вариантов используется вер-

тикальная черта, т. е. в определении оператора выбора вертикальная черта
это не метасимвол, в отличие от любых других определений, а синтаксиче-
ский элемент определяемой конструкции.
Тип константного выражения или диапазона в записи варианта совпадают
с типом ключевого выражения. В частности, в качестве этого выражения
может использоваться строка, которая соответствует значению битового век-
тора или вектора типа std_iogic.
При каждом исполнении оператора выбора реализуется единственная по-
следовательность вложенных операторов, а именно та, которой предшеству-
ет вариант, совпадающий со значением ключевого выражения в момент ис-
полнения оператора. Если вариант представлен диапазоном, то соответст-
вующая последовательность операторов исполняется при условии, что
значение ключевого выражения принадлежит этому диапазону.
Ключевое слово OTHERS определяет операторы, которые исполняются, если
значение ключевого выражения не совпадает ни с одним вариантом и не
входит в объявленные диапазоны. Если алгоритм предусматривает варианты,
при которых не производится никаких действий, то в операторной части
таких вариантов записывается пустой оператор NULL.
Практически любой разветвленный фрагмент можно описать с использова-
нием и оператора условия, и оператора выбора. Применение одного из спо-
собов записи — дело вкуса программиста. Тем не менее, оператор CASE луч-
ше использовать, когда выбор ветви алгоритма связан с одной переменной,
принимающей дискретное множество значений. Иногда набор условий лег-
ко приводится к одной такой переменной. Например, фрагмент программы
в листинге 3.5 может быть преобразован в эквивалентную программу, пред-
ставленную в листинге 3.7.
example_case_l:PROCESS (a,b)
VARIABLE d: std_logoc_vector (1 DOWNTO 0 ) ;
BEGIN
d:=a & b
CASE d IS
WHEN "11" => q <= Ч'; P<= '!';
WHEN "00" => q <= '0'; p<=4';
WHEN OTHERS=>q <= '0'; p<='0';
END CASE;
END PROCESS;
Следующий фрагмент (листинг 3.8) иллюстрирует использование в качестве

выражения варианта констант перечислимого типа, а также описание оди -
наковых действий для нескольких вариантов. Описан порядок формирова-

ния адреса памяти address для некоторого процессорного элемента в зави-
симости от выполняемого цикла обмена. Выполняемый цикл обмена задает-
ся сигналом bus_controle, Принадлежащим ТИПУ bus_operations. СПИСОК
значений типа и их смысл представлен в листинге. В различных циклах в
качестве источника кода адреса могут выступать счетчик адреса команд
(program_counter), регистр КОМЭНД (command_register) ИЛИ регистр данных
(data_register).
ARCHITECTURE function_description OF address_generator

TYPE bus_operations IS
( fetch, — цикл выборки команды
immediate_read, — выборка непосредственного операнда
direct read, direct write, — чтение и запись
— с прямой адресацией памяти
io_read, io_write, — ввод и вывод на внешние устройства
indirect read, indirect write — чтение и запись по косвенному адресу
SIGNAL bus_controle: bus_operations;

SIGNAL program_ counter, — счетчик адреса команд
command_register, — регистр команд
data_register — регистр данных
: std_logic__vector (31 downto 0) ;
BEGIN
PROCESS(bus_controle)
BEGIN
CASE bus_controle IS
WHEN fetch | immediate_read => adress <=program_ counter;
WHEN direct_read I direct_write | io_read | io_write =>
adress <=command_register;
WHEN indirect_read | indirect_write =>adress <= data_register;
END CASE;
END PROCESS;
END function_description;
Используя задания набора вариантов из диапазона значений, можно опера-

тор выбора в предыдущем примере записать более коротко:
CASE bus_controle IS
WHEN fetch | immediate_read => adress <=program_ counter;
WHEN direct_read TO io_write =>adress <=coramand_register;
WHEN indirect_write DOWNTO indirect_read =>adress <= data_register;
END CASE;
При аппаратной интерпретации оператора условия и оператора выбора в

устройстве фактически реализуются подсхемы, исполняющие все возмож-
ные альтернативы, из которых в конкретной ситуации инициализируется
только одна.
Оператор ожидания
Исполнение операторов, записанных в теле процесса, приостанавливается,
если очередной оператор является оператором ожидания (фактически —
оператором приостанова) WAIT. При этом результаты исполнения предшест-
вующих операторов заносятся в календарь событий и могут быть инициали-
зированы другие процессы. Прекращения состояния приостанова процесса
зависит от условий, определенных в операторе WAIT. Определено несколько
модификаций оператора WAIT:
<оператор ожидания> :: =
WAIT;
IWAIT ON <имя сигнала> «,<имя сигнала> »;
IWAIT UNTIL <условие>;
(WAIT FOR <выражение времени>;
Вариант оператора WAIT без дополнительных уточняющих конструкций со-

ответствует "бесконечному останову". В этом случае после достижения та-
кого оператора процесс никогда больше не будет исполняться. Указанную
версию можно использовать для описания процедур инициализации систем,
а также фрагментов, работа которых при некоторых условий прекращается
навсегда. Обычно такой оператор завершает программы генерации тестов,
означая окончание тестовой последовательности.
Список сигналов в варианте WAIT ON эквивалентен списку инициализаторов
процесса: продолжение исполнения будет продолжено после того, как один
из сигналов списка изменит свое значение. Так процесс с_1, представ-
ленный фрагментом программы в листинге 3.9, эквивалентен процессу
exampie_if_i, представленному в листинге 3.5, но, в общем случае, в теле
процесса может быть несколько операторов WAIT, каждый из которых отде-
ляет фрагмент, инициируемый своей совокупностью событий.
Приостанов, заданный конструкцией WAIT UNTIL, заканчивается, когда вы-
полнено заданное оператором условие, т. е. соответствующее выражение
принимает значение TRUE. Процесс с_2, представленный листингом 3.10, по
составу операторов подобен процессу с_1, но фактическое исполнение су-
щественно отличается. Здесь, например, после выполнения присвоений,
предусмотренных строкой, отмеченной комментарием "останов 1", устройст-
во и его программная модель не реагируют ни на какие изменения пере-
менных а и ь до тех пор, пока они одновременно не примут значение логи-
ческого нуля.
С_1:PROCESS c_2 : PROCESS

BEGIN BEGIN
WAIT ON a,b; WAIT UNTIL a = '1' AND b = '1';
IF a = '!' AND b = '1' THEN q <= 4 ' ; p < = 4 ' ; — останов 1
q <= 'l';p<='l'; WAIT UNTIL a = '0' AND b = '0';
ELSIF a = '0' AND b = '0' THEN q <= '0'; p<=4';
q <= '0'; p<=4'; WAIT ON a,b;
ELSE q <= '0'; p<=4'; q <= '0'; p<='l';
END IF; END PROCESS с 2;
END PROCESS с 1;
Вариант ожидания по времени иллюстрируется процессом Generator, пред-

ставленным в листинге 3.11. Данный процесс выполняется "бесконечно",
приостанавливаясь каждые 50 не модельного времени, причем перед приос -
тановом уровень сигнала clock меняется на противоположный. В момент
приостанова могут быть инициированы параллельные операторы програм-
мы, в том числе другие процессы.
Generator: PROCESS
BEGIN
Clock<='0';
WAIT FOR 50 ns
clock <= not clock;
END PROCESS Generator
Процесс, содержащий оператор WAIT, не может иметь списка инициализато-

ров. Это связано с тем, что трудно описать систему, в которой может про-
изойти повторная инициализация действий, в то время как реакция на пре-
дыдущее событие еще не реализована, например, произошло изменение од-
ного из инициирующих сигналов, когда время ожидания еще не вышло.
Еще раз напомним, что оператор WAIT, как и другие последовательные
операторы, может размещаться только в теле процесса или теле подпро-
граммы.
Операторы повторения
Операторы повторения LOOP позволяют сокращенно записывать совокупно-
сти однотипных действий.
<оператор повторения> ::=
[ <метка оператора повторения> ] [ <итерационная схема> ] LOOP
<оператор> « <оператор> »
END LOOP [ <метка оператора повторения> ];
<итерационная схвма> ::=
WHILE <условие> I FOR <имя переменной> IN <диапазон>
Последовательность операторов (здесь могут быть только последовательные

операторы), заключенная между словами LOOP и END LOOP, называется телом
оператора повторения или телом цикла. Операторы в теле цикла выполняют-
ся друг другом в порядке записи, причем такое выполнение повторяется
многократно. Число повторений определяется итерационной схемой.
Оператор повторения, не содержащий явного объявления итерационной
схемы, предполагает бесконечное повторение последовательностей вложен-
ных в него операторов. Такая модель, в целом, соответствует поведению ре-
альных дискретных устройств, повторяющих некоторую последовательность
действий вплоть до отключения питания. В то же время эта конструкция
имеет логический смысл, только если тело цикла содержит оператор ожида-
ния WAIT или оператор выхода из цикла EXIT. В противном случае бесконеч-
ное безусловное повторение блокировало бы исполнение любых других опе-
раторов и процессов. Листинг 3.12 представляет описание двух процессов,
каждый из которых содержит бесконечный цикл. Процесс ciock_generator
описывает устройство, непрерывно генерирующее последовательность пря-
моугольных импульсов. Процесс execute после начальной установки ждет
положительный фронт импульса CLK, и в ответ на это событие выдает на
порт очередное значение.
ENTITY sequence_of_numbers IS
GENERIC (max_value: integer :=63);
PORT ( out_data: out integer range 0 to max_value;
Clk : inout bit);
END sequence_of_numbers;
ARHITECTURE behavior OF sequence_of_numbers IS
BEGIN
clock_generator: PROCESS
?
BEGIN clk<='0 ;
LOOP WAIT FOR 50 ns;
clk<= not elk;
END LOOP;
END PROCESS clock_generator;
execute : PROCESS
VARIABLE INT_STATE: INTEGER RANGE 0 TO max_value:=0;
BEGIN
Out data<=0;
LOOP
WAIT UNTIL (clk='l' and elk'event)
IF (int_state=max value) then int_state:=0;
ELSE int_state:=int_state+l;
END IF;
out_data<= int_state;
END LOOP;
END PROCESS execute;
END behavior;
Оператор с ключевым словом WHILE обязательно содержит в теле цикла опе-

раторы, изменяющие описанное в итерационной схеме условие. Операторы
цикла повторяются, пока при вычислении условия не получается значения
FALSE. Условие проверяется каждый раз перед исполнением тела цикла. На-
пример, оператор
WHILE param>=0 LOOP
Param :=; — некоторое выражение, изменяющее param
END LOOP;
Выполняется, пока переменная param не получит отрицательного значения,

причем если param было отрицательно перед исполнением оператора, то те-
ло исполняться вообще не будет.
Оператор повторения с ключевым словом FOR повторяется для всех значе-
ний переменной из заданного итерационной схемой диапазона.
Отметим, что присвоенные в теле цикла значения переменных могут быть
исходными данными для очередного цикла. Если же в цикле выполнено
присвоение значения сигналу, то в следующих операторах тела и очередных
повторениях того же цикла используются старые значения, если только тело
цикла не содержит операторов ожидания.
В качестве примера рассмотрим программу в листинге 3.13, представляю-
щую описание синхронной линии задержки на время восьми тактов син-
хронизирующего импульса. Физически это может быть восьмиразрядный
регистр сдвига. При каждом переходе сигнала elk в единичное состояние
запоминающие элементы shift с первого по шестой переходят в состояние,
соответствующее состоянию предыдущего элемента перед изменением elk,
a shift (0) принимает значение входного сигнала. Таким образом, shift (б)
задержан относительно din на время, соответствующее семи периодам сиг-
нала. Сигнал dout задержан еще на один период - тактирующего сигнала.
Интересно отметить, что если бы вектор shift был определен как перемен-
ная, то в силу того, что присвоения переменной непосредственно учитыва-
ются в последующих циклах, все биты вектора shift принимали бы значе-
ние din после каждого нарастающего фронта сигнала elk.
ENTITY delayer IS
port (elk, din:in std_logic;
dout:out std_logic);
END delayer;
ARCHITECTURE test OF delayer IS
SIGNAL shift: std_logic_vector (6 downto 0};
BEGIN
PROCESS(elk)
Variable i: integer range 7 downto 0;
BEGIN
IF clk='l' THEN
shift(0)<=din;
FOR i IN 1 TO 6 LOOP
shift(i)<= shift(i - 1 ) ;
END LOOP;
dout<=shift(6);
END IF;
END PROCESS;
END test;
Если при моделировании и, в частности, при описании тестовых воздейст-

вий смысл операторов повторения практически не отличается от смысла
подобных конструкций в традиционных языках программирования, то при
интерпретации в аппаратуре имеются существенные отличия. Предусматри-
вается не просто последовательное во времени повторение набора преобра-
зований, а реализация набора устройств, выполняющих однотипные дейст-
вия, причем эти устройства работают параллельно.
Число устройств определяется итерационной схемой. Для оператора с клю-
чевым словом FOR — это просто число значений переменной в объявленном
диапазоне. Для варианта с ключевым словом WHILE условие не может быть
связано с сигнальными данными, способными изменяться в реальном уст-
ройстве. Например, в материалах фирмы Altera определено, что "операторы
повторения должны иметь логически постоянные границы". В противном
случае не ясно, сколько повторяющихся блоков в устройстве реально потре-
буется.
Кроме раздела "итерационная схема" порядок реализации повторений может
задаваться дополнительными операторами: оператором перехода к следую-
щему циклу NEXT и оператором выхода из цикла EXIT.
Оператор NEXT блокирует исполнение всех последующих операторов в теку-
щем цикле и обеспечивает автоматический переход к следующей итерации.
Оператор записывается следующим образом:

<оператор перехода к следующему циклу> ::=
[ <метка>: ] NEXT [ <метка оператора повторения> ] [ WHEN <условие>]
Фактически, конструкция
Ml: LOOP Si
NEXT WHEN В;
S2
END LOOP;
где Si и S2 — последовательности операторов, а в — логическое выражение,

эквивалентна
Ml: LOOP Si
IF n o t В THEN S 2
END LOOP;
Оператор EXIT прекращает исполнение не только текущего цикла, но всех

последующих циклов, заданных итерационной схемой исполняемого опера-
тора. BNF -форма оператора EXIT имеет вид:
•Сепаратор прекращения цикла> :: =
[ <метка>: ] EXIT [ <метка оператора повторения> ] £ WHEN <условие>]
Например, оператор вида

LOOP Si — оператор Si меняет значения аргументов выражения В
EXIT WHEN В
S2
END LOOP;
эквивалентен
B= TRUE;
WHILE n o t В LOOP
SI
IF n o t В t h e n S2
END LOOP;
Необязательная метка в операторах NEXT и EXIT используется при записи

вложенных циклов. Такая метка указывает, что прерывается не только дан-
ный цикл, но и все иерархически предшествующие ему циклы, вплоть до
цикла, оператор которого помечен этой меткой. Рассмотрим в качестве
примера совокупность вложенных операторов повторения, представленных
в листинге 3.14. Здесь цикл, помеченный mi, содержит две последовательно-
сти операторов Su и Si2, между которыми включен оператор повторения,
помеченный т2. И далее для последующих уровней вложения, mi — это мет -
ка уровня, a su и S l 2 — последовательности операторов, вложенных в опера-

тор повторения / -го уровня. Если при вычислении условия в получено зна-
чение TRUE, прерывается исполнение циклов предыдущих уровней вложения
вплоть до т2. То есть следующей будет выполняться совокупность операто-
ров Si2. Если в = FALSE, то циклы будут завершаться "обычным образом"
при возникновении условий, заданных итерационными схемами.
m l : LOOP Su
m2: LOOP S 2 i
m 3 : LOOP S 3 i
mk: LOOP SM.

NEXT m2 WHEN B;
S)t2
END LOOP mk;
S32
END LOOP m 3 ;
S22
END LOOP m2;
Si 2
END LOOP m l ;
Оператор проверки
Оператор проверки ASSERT относится к категории конструкций, не подле-
жащих реализации в аппаратуре. Оператор служит для выявления специфи-
ческих ситуаций, которые могут возникать в процессе компиляции и моде-
лирования (т. е. программной интерпретации описания проекта), и выдачи
в этих ситуациях сообщения разработчику. Синтаксис оператора проверки
определен следующим образом:
<оператор проверки> : : =
ASSERT <булевское выражение> [ REPORT <строка сообщения> ]
[ SEVERETY <уровень важности>];
При выполнении этого оператора в процессе моделирования проверяется

условие, и если получено значение TRUE, выполняется переход к следующе-
му оператору программы. В противном случае на терминал выводится стро-
ка сообщения. Если опция "REPORT <строка сообщения>" отсутствует, выдает-
ся стандартное сообщение "Assertion violation" (нарушение условий про-
верки). После этого поведение моделировщика определяется значением
уровня важности. Уровень важности — это выражение (обычно константа)

типа SEVERITY_LEVEL. Напомним, что данные этого типа могут принимать
четыре значения, причем значения NOTE и WARNING имеют чисто информаци-
онный характер, и в этом случае моделирование после выдачи сообщения
продолжается, а значения ERROR и FAILURE используются для обнаружения
полностью некорректных ситуаций, требующих прекращения моделирова-
ния. По умолчанию (т. е. при отсутствии в тексте указания важности) под-
разумевается уровень ERROR.
Например, если требуется при моделировании просто выводить на монитор
информацию о том, что сигнал controi_ievei изменился, и не прерывать
моделирование, то можно записать в программе
ASSERT NOT control_level'event
REPORT "Изменение сигнала control_level"
SEVERITY NOTE;
Следующий пример иллюстрирует введение сигнализации о возникновении

при моделировании недопустимой ситуации — одновременной подачи на
входы R и s триггера сигналов логической единицы:
ASSERT R = ' l ' NAND 3 = 4 ' ;
Отсутствие в этой записи ключевых слов REPORT и SEVERITY означает, что

используются значения по умолчанию. То есть, если при моделировании
возникнет ситуация, когда сигналы R и s одновременно установлены в еди-
ницу, на терминал выводится строка "Assertion violation", и моделирова-
ние прекращается.
3.2.7. Параллельные операторы

Параллельные операторы это такие, каждый из которых выполняется при
любом изменении сигналов, используемых в качестве его исходных данных.
Результаты исполнения оператора доступны для других параллельных опе-
раторов не ранее, чем будут выполнены все операторы, инициализирован-
ные общим событием (а может быть и позже, если присутствуют выражения
задержки). В языке VHDL к классу параллельных операторов относятся:
<Параяяаяьный оператор>::=
<оператор процесса>
I <оператор параллельного присваивания>
I <параллельный вызов процедуры>
I <параллельный оператор проверки>
I <оператор блока>
| <оператор вхождения компонента>
I <оператор генерации>
Оператор процесса уже рассматривался в предыдущих разделах. Здесь важно

отметить, что этот оператор определен именно как составной оператор па-
раллельного типа. Под составным оператором понимается оператор, имею-
щий тело, которое содержит несколько вложенных операторов. Оператор
процесса начинает исполняться при изменении сигналов, входящих в спи-
сок инициализаторов (при отсутствии такого списка — безусловно после
выполнения всех вложенных операторов), а результаты его исполнения дос-
тупны другим параллельным операторам только после исполнения всех опе-
раторов, инициируемых теми же событиями, в том числе процессов.
Параллельное присваивание определено в трех различных формах:
<Параляеяьное присааивакие> : :=
[ <метка> : ] безусловное параллельное присваивание>
I [ <метка>: ] <условное присваивание>
I [ <метка> : ] <присваивание по выбору>
По синтаксису и правилам исполнения безусловное параллельное присваи-

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

присваивания и последовательного присваивания сигналу:
О параллельное присваивание локализуется в общем разделе архитектур-
ного тела, а последовательное — только в теле процесса;
П последовательное присваивание сигналу выполняется после того, как
инициировано исполнение процесса и выполнены все предшествующие
операторы в теле процесса;
О оператор параллельного присваивания выполняется сразу (с точки зрения
модельного времени) после изменения сигналов в правой части этого
оператора.
В обоих случаях результаты присвоения сначала фиксируются в драйвере
сигнала и передаются сигналу, т. е. могут влиять на другие операторы, толь-
ко после исполнения всех операторов и процессов, инициированных одним
событием, или через интервал модельного времени, заданный опцией AFTER.
Условное присваивание и присваивание по выбору во многом сходны с услов-
ным оператором и оператором выбора, соответственно — описанные дейст-
вия выполняются при определенных условиях. Различие, кроме единых для
всех параллельных и последовательных операторов свойств, состоит в том,

что условный оператор и оператор выбора являются составными, т. е. усло-
вие может задавать в них исполнение последовательности действий, а в опе-
раторах присваивания — только присвоение одного значения.
<Услоеное присваивание} -: : =
<приемник> <= [QUARDED] [<модель задержки>]
«<прогноз поведения> WHEN <условие> ELSE »
<прогноз поведеция>;
Пример. Двухвходовый буфер с тремя состояниями на выходе может быть

представлен следующим оператором:
Z_out<= TRANSPORT xO AFTER 2 ns WHEN (adr = '0' and en=4') ELSE
xl AFTER 2 ns WHEN (adr=4' and en='l') ELSE
'Z' AFTER 5ns;
Здесь битовый сигнал adr задает номер включаемого канала, а еп — разре-

шение передачи.
BNF -форма присваивания по выбору имеет вид:
<присваивание по выбору> ::=
WITH <ключевое выражение> SELECT
<приемник> <= [ QUARDED ] [<модель задержки>]
«<прогноз поведения> WHEN <вариант>,»
<прогноз поведения> WHEN <вариант>;
Смысл и синтаксис конструкции "вариант" точно совпадает с соответствую-

щим элементом оператора выбора.
Следующий оператор эквивалентен описанию буфера с тремя состояниями,
представленному в предыдущем примере:
WITH a & Ъ SELECT
Z_out<= TRANSPORT xO AFTER 2 ns WHEN "01",
xl AFTER 2 ns WHEN "11",
'Z 1 AFTER 5 ns WHEN OTHERS;
Важно отметить, что если условный оператор I F и оператор выбора CASE не

могут выполняться над данными, вырабатываемыми модулями, представ-
ленными различными операторами процесса, то условное присваивание и
присваивание по выбору позволяют описывать такие ситуации.
Пример. Пусть три блока (процесса) работают параллельно с выходом на
общую шину через буфер с тремя состояниями, причем выбор подключае-
мого модуля задается сигналом, подаваемым на порт channei_seiect. Про-
граммный модуль, описывающий такой буфер, представлен в листинге 3.15.
ENTITY three_channel IS
PORT ( data_in: IN integer; — условные входные данные
Channel_select: IN integer range 1 TO 3;
Z: OUT integer);
END three_channel;
ARCHITECTURE skeleton OF three_channel IS

SIGNAL datal,data2, data3 : integer;
BEGIN
WITH Channel_select SELECT
z<= datal WHEN 1;
data2 WHEN 2;
data3 WHEN 3;
'Z' WHEN others;
PROCESS
BEGIN datal<= END PROCESS;
PROCESS
BEGIN data2<= END PROCESS;
PROCESS
BEGIN data3<= END PROCESS;
END skeleton;
Параллельные операторы проверки и вызова подпрограмм соотносятся с соот-

ветствующими последовательными операторами проверки и вызова подобно
соотношению параллельного и последовательного присваивания, а именно:
они имеют одинаковый синтаксис и правила выполнения, но различаются
локализацией и условиями запуска к исполнению.
Оператор блока
Оператор блока BLOCK, подобно оператору PROCESS, является составным опе-
ратором, тело которого включает несколько операторов, но, в данном слу-
чае, параллельных. Операторы тела блока, как и другие параллельные опера-
торы, обеспечивают возможность представления параллелизма в моделируе-
мой системе. Эти операторы инициируются не по последовательному, а по
событийному принципу, а результаты их исполнения становятся доступны
другим операторам как включенным в блок, так и размещенным в других
блоках или "индивидуально", только после исполнения всех операторов,
инициированных одним событием.
В этом смысле операторы, включенные в блок, не отличаются от "инди-
видуальных" параллельных операторов.
Глава 3. Языки описаний дискретных устройств 363
Объединение операторов в блоки обеспечивает следующие возможности:

О структуризация текста описания, т. е. возможность явного и наглядного
выделения совокупности операторов, описывающих законченный функ-
циональный узел;
О возможность объявления в блоке локальных типов, сигналов, подпро-
грамм и некоторых других локальных понятий;
П возможность приписывания всем или некоторым операторам блока об-
щих условий инициализации.
Упрощенные правила записи оператора блока определены таким образом:
<оператор блока> ::=
<метка блока>: BLOCK [ ( охранное выражение) ] [ IS ]
[ <раздел деклараций блока> ]
BEGIN
<раздел операторов блока>
END BLOCK [ <метка блока>];
Наиболее специфическими аспектами блочной организации являются поня-

тия охранного выражения и охраняемого оператора присваивания.
Охранное выражение — это любое выражение логического типа, аргумен-
тами которого являются сигналы. Любое изменение сигналов, входящих
в охранное выражение, вызывает вычисление значения этого выражения и
присвоение полученного значения предопределенной переменной QOARD.
Область действия переменной QUARD — все тело блока, и она может исполь-
зоваться как обычная логическая переменная во вложенных операторах бло-
ка. Например, узел выборки данных из тридцатидвухразрядного регистра на
восьмиразрядную линию, в котором транслируется байт, указанный двух-
разрядным кодом номера byte_sei, может быть представлен таким блоком:
1 1
Select_byte: BLOCK ( s e l e c t » 1 ' and read - ' l ) IS
BEGIN dbus<= reg(7 downto 0) WHEN QUARD and byte_sel="00" e l s e
reg(15 downto 0) WHEN QUARD and byte_sel="01" e l s e
reg(23 downto 16) WHEN QUARD and byte_sel ="10" e l s e
reg(31 downto 24) WHEN QUARD and byte_sel ="11" e l s e
"ZZZZZZZZ";
END BLOCK s e l e c t _ b y t e ;
Охраняемый оператор присваивания использует значение переменной QUARD

без явного указания условия в программе. Если QUARD ='0', то исполнение
операторов присваивания, содержащих ключевое слово QUARDED, в таком
блоке запрещено.
Например, два модуля, подключенные к общей шине, могут быть представ-
лены в одном архитектурном теле таким образом, как в листинге 3.16.
ARCHITECTURE quard_exaniple OF two_block IS
SIGNAL data_bus: Std_logic_vector (N_ -l downto 0 ) ;

— n определяется в разделе GENERIC проекта two_block;
BEGIN
<описание других блоков системы>
unitl: BLOCK ( adr='0' and read_data='1')
SIGNAL dataO : Std_logic_vector (N_ -l downto 0 ) ;
BEGIN
Data_bus<=QUARDED dataO AFTER <выражение задержки>
PROCESS BEGIN <Вычисление dataO>
END PROCESS;
END BLOCK unitl;
Unitl: BLOCK ( adr='l' and read_data=Ч')
SIGNAL datal : Std_logic_vector (N_ -l downto 0 ) ;
BEGIN
Data_bus<=QUARDED datal AFTER <выражение задержки>
PROCESS BEGIN вычисление datal>
END PROCESS;
END BLOCK unitl;
Более подробно проблемы описания соединений блоков с использованием

шин передачи данных рассмотрены далее в разд. 3.2.10.
3.2.8. Описание в VHDL

типовых дискретных устройств
Комбинационные логические схемы
Математической моделью комбинационной логической схемы является ло-
гическая функция. Известно много способов задания логической функции,
из которых наибольшее распространение получили:
П алгебраическое представление;
П табличное представление;
П представление через бинарную декомпозицию, в пределе в виде двоич-
ного дерева решений;
О декомпозиция в априорно заданном базисе функций меньшего числа
аргументов.
В принципе, любую логическую функцию можно записать в любой из пере-
численных форм, а также в их комбинации. Логическая форма полезна при
сравнительно небольшом числе аргументов (не более пяти -шести). Бинар-

ная декомпозиция позволяет осуществлять разложение логической функции
на совокупность функций меньшего числа переменных. Табличное пред-
ставление является более универсальным, но достаточно трудоемким и
трудно контролируемым при большом числе аргументов. В подобных ситуа-
циях применимы смешанные подходы. Декомпозиция в заданном базисе, на
наш взгляд, мало продуктивна для проектирования схем на ПЛИС, но,
в принципе, может применяться при переводе ранее разработанных устройств
на новую элементную базу. Выбор того или иного способа представления
может определяться самой процедурой проектирования, точнее, способом
создания алгоритма функционирования устройства. Часто сам алгоритм соз-
дается по логике "если определенный аргумент (вход) установлен в логиче-
скую единицу, то реализуется одна совокупность действий, иначе другая".
Выделенные совокупности, в свою очередь, могут быть далее разложены на
основе анализа следующих аргументов. Такие рассуждения автоматически
приводят к описанию логической схемы в форме двоичного дерева решений.
Часто способ записи логических функций связан просто с опытом и лич-
ными предпочтениями разработчика. Язык VHDL представляет возможно-
сти использования любой исходной формы задания без необходимости руч-
ного перевода из одной формы в другую.
Реализация комбинационной логической схемы на основе алгебраической
формы записи логической функции интерпретируется оператором присваи-
вания, в правой части которого записывается эквивалентное логическое
выражение. Однако следует обратить внимание на ряд особенностей интер-
претации, связанных с взаимной синхронизацией операторов. Один из про-
стейших способов — использование параллельных операторов присваива-
ния. Программа (листинг 3.17) представляет описание комбинационной
логической схемы с двумя выходами, приведенной на рис. 3.11, в нормаль-
ной форме И -ИЛИ с использованием параллельных присваиваний.
Реальная интерпретация программы в аппаратной среде может существенно
отличаться от схемного варианта, приведенного на рисунке. Компиляторы
САПР проводят автоматическую оптимизацию схемы независимо от формы ее
задания. В данном случае при реализациях в ПЛИС, построенных на основе
четырехвходовых LUT, функции F1 и F2 будут целиком реализованы на одной
макроячейке каждая, а сигнал a_and_b как таковой не воспроизводится, или,
как говорят, поглощается.
ENTITY simple_logic IS
PORT (a,b,c,d: in std_logic;
out!, out2: out std_logic);
END siniple_logic;
ARCHITECTURE concurrent OF simple_logic IS

SIGNAL a_and_b: s t d _ l o g i c ;
BEGIN
outl<=a_and_b or ( с and d and not b) or ( not a and not b and d ) ;
out2<=a_and_b or (not a and с and d) or (a and not b and not d)
or (b and not с and d ) ;
a_and_b <= a and b;
END concurrent;
Рис. 3 . 1 1 . Пример комбинационной логической схемы

Можно применять также и последовательную форму записи правила функ-

ционирования с использованием оператора процесса. Архитектурное тело
описанного в этой форме устройства, изображенного на рис. 3.11, представ-
лено в листинге 3.18. Здесь важно отметить, что все входные сигналы ком-
бинационной схемы должны быть включены в список инициализаторов
процесса с тем, чтобы любое их изменение вызывало исполнение оператора
присваивания. Кроме того, в данном случае недопустимо a_and_b деклари-
ровать как сигнал. Это обязательно переменная, причем ее вычисление зада-
ется оператором, предшествующим операторам вычисления результирующих
сигналов. В противном случае наблюдается некорректное представление по-
ведения, заключающееся в том, что используются значения не непосредст-
венно полученные в процессе текущего исполнения оператора PROCESS,
а значения, вычисленные ранее после предыдущего изменения одного из
входных сигналов.
ARCHITECTURE sequential OF simple_logic IS

—SIGNAL a_and_b: std_logic; — недопустимо в данном контексте
BEGIN
PROCESS (a,b)
VARIABLE a_and_b: std_logic;
BEGIN
a_and_b := a and b;
outl<=a_and_b or ( с and d and not b) or ( not a and not b and d);
or (b and not с and d);
END sequential;
Если a_and_b это все -таки сигнал (например, необходимый для передачи
информации другим операторам программы или на порты), то следует вы-
делить его вычисление в отдельный процесс или параллельный оператор,
как показано в листинге 3.19.
ARCHITECTURE two_j?rocesses OF simple_logic IS

SIGNAL a_and_b: std_logic;
BEGIN
PROCESS (a,b)
BEGIN
a_and_b <= a and b;
END PROCESS
PROCESS (a,b, c,d,a_and_b)
BEGIN
outl<=a_and_b or (с and d and not b) or (not a and not b and d ) ;
or (b and not с and d ) ;
END PROCESS;
END two_processes;
Табличное представление логической функции можно отобразить в VHDL -npo -

грамме несколькими способами.
Первый способ состоит в представлении таблицы истинности логической
функции в виде константного битового вектора, каждый / -и компонент ко-
торого представляет значения логической функции на наборе, численный
эквивалент которого равен значению /. Очевидно, что "вычисление" функ-
ции сведется к выборке элемента массива, индекс которого равен числен-
ному эквиваленту входной кодовой комбинации.
Формирование такого численного эквивалента выполняется с использова-
нием функций преобразования типов сигналов, которые представлены во
всех системах проектирования, способных интерпретировать описания про-
ектов на VHDL. Эти функции могут иметь разные названия и даже синтак-
сис, что не меняет сути. Мы в дальнейшем будем записывать такие преобра-
зования, используя функции преобразования типов, определенные в пакете
std_iogic_utii системы интерпретации VHDL -программ фирмы Model Tech-
nology.
В функции conv_integer (vect) аргумент ОТНОСИТСЯ К Типу b i t _ v e c t o r ИЛИ
std_iogic_vector произвольной длины, а возвращаемое значение — числен-
ный эквивалент двоичного кода аргумента (беззнаковое целое в диапазоне
от 0 до 2Л—1, где п — разрядность аргумента).
В функции conv_std_iogic_vector (argi, n) оба аргумента целые беззнако-
вые, а результат — л -разрядный двоичный код (std_iogic_yector), являю-
щийся двоичным эквивалентом argl.
Листинг 3.20 содержит архитектурное тело, функционально соответствую-
щее программе, представленной в листинге 3.17. В этом варианте определе-
ние результата выполняется путем прямой выборки значения из таблицы по
индексу, формируемому из входных сигналов, с использованием функции
conv_integer.
ARCHITECTURE table_ presentation OF simple_logic IS

TYPE truth_table_4xl IS ARRAY (0 to 15) OF std_logic;
CONSTANT function!: truth_table_4xl :=
CONSTANT function2: truth_table_4xl:=

/ i r p i -ii- ,i /л
^ U , J
i i -ri i л i i n t i f i i i l l i т i i л i i n * Ч ' Ч ' Ч ' 'ГИ Ч М •
\ J , . L , U , U , U , . I . , . I . , U , U , . I . , . L , J . , U , . L J ,
SIGNAL digital_equivalent: integer range 0 to 15;

BEGIN
Digital_equivalent <= conv_integer (d & с & b & a) ;
Outl<= functionl(digital_equivalent);
Out2<= function2(digital_equivalent);
END table_jpresentation;
Возможно использование последовательных операторов присваивания с уче-

том тех же особенностей, которые были отмечены при изложении интер-
претации функций с использованием логических выражений. Существен-
ным недостатком присвоения путем выборки из таблицы являются трудно-
сти воспроизведения при временном моделировании поведения устройств,
у которых переходы 0—1 и 1—0 различны по времени, а также анализ сбой-
ных ситуаций (гонки, риски). Если это в проекте представляется важным,
лучше на основании таблицы истинности построить оператор присваивания
по выбору или использовать последовательный оператор выбора. Для выхода
outi устройства (см. рис. 3.11) оператор присваивания по выбору, описываю-
щий поведение сигнала во времени, может выглядеть следующим образом:
v<=d & с & Ь & а;
WITH v SELECT
OutK='X', '0' AFTER 1 ns WHEN "0000",
'X', '0' AFTER 1 ns WHEN "0001",
'X', '0' AFTER 1 ns WHEN "0010",
'X', '1' AFTER 2 ns WHEN "0011",
'X1, 'O1 AFTER 1 ns WHEN "0100",
'X', '0' AFTER 1 ns WHEN "0101",
'X', 'O1 AFTER 1 ns WHEN "0110",
•X', '!' AFTER 2 ns WHEN "0111",
'X1, Ч1 AFTER 2 ns WHEN "1000",
'X', 'O1 AFTER 1 ns WHEN "1001",
'X', '0' AFTER 1 ns WHEN "1010",
'X1, Ч1 AFTER 2 ns WHEN "1011",
'X', '!' AFTER 2 ns WHEN "1100",
'X', 4' AFTER 2 ns WHEN "1101",
•X', '0' AFTER 1 ns WHEN "1110",
1
'X , 4' AFTER 2 ns WHEN "1111",
'X' WHEN OTHERS;
Использование оператора выбора может обеспечить более компактную запись:
v:=d & с & b & а;
CASE v IS
WHEN "0000" I "0001" 10010"! "0100" | "0101" |

"ОНО" I "1001" | "1010" | "1100" | "1110"
1
=>0utl<= 'X', 'О AFTER I ns;
WHEN "ООН" | "0111" I "1000" | "1011" | "1100" | "1101" | "1111"
1
=> Outl<= 'X , '!' AFTER 2 ns;
WHEN OTHERS => Outl<= 'X';
END CASE;
При этом еще раз подчеркнем, что такой оператор должен находиться в теле
процесса, причем переменные d, с, ь и а должны входить в список инициа-
лизаторов этого процесса.
Представление функции в форме бинарного дерева решений основано на по-
следовательном переходе от представления функции большого числа пере-
менных через суперпозицию функций меньшего числа переменных. Теоре-
тической основой метода является разложение Шеннона:
2
, ..., XN) v xif(\,x2, ..., XN).
Тогда вычисление первого терма разложения записывается как одна воз-
можная альтернатива условного оператора или условного присваивания, а
вычисление другого — как противоположная:
IF x l = ' 0 ' THEN z<= <подформула, полученная из f заменой xi на нуль>;
ELSE z<= <подформула, полученная из f заменой xi на единицу>;
END I F ;
Подформулы разложения могут быть, в свою очередь, далее разложены:
хъ ..., XN) •= *x{f(0,x2, ..., XN) v *i/(l,;t 2 , ..., XN) = л * ! [Лх2/(0,0, .....
, ..., XN) v дг2/(1,1, ..., XN)],
и т. д. Однако хочется еще раз отметить, что описание логики в виде бинар-
ного дерева или поддерева часто вытекает из самой логики создания проекта.
Оператор процесса, содержащий описание комбинационной схемы, пред-
ставленной на рис. 3.11 с использованием условного оператора, приведен
в листинге 3.21. Здесь вспомогательные переменные prl и рг2 введены для
возможности представления несимметричных переходных процессов. Если
это не существенно, то можно ограничиться присвоением значений сигна-
лам outi и out2 непосредственно в условном операторе.
PROCESS (a,b,c,d)
VARIABLE prl,pr2:std_logic;
BEGIN
IF b = ' l ' THEN p r l := a; pr2:=a or (d and not c ) ;
?
ELSIF a='0 THEN prl:=d; pr2:=not d or с;
ELSE prl:=c and d; pr2='0';
END IF;
1
Outl<= 'X , Ч'AFTER 2 ns WHEN p r l = 4 ' ELSE
'X','0'AFTER 1 ns WHEN prl='0' ELSE
1
'X ;
1
Out2<= 'X ,Ч'AFTER 2 ns WHEN pr2='l' ELSE
'X','0'AFTER 1 ns WHEN pr2='0' ELSE
'X';
END PROCESS;
Операторы условного присваивания записываются индивидуально для каж-

дой функции, но структурно подобны представленному условному оператору.
В заключение рассмотрения схем комбинационной логики в листинге 3.22
приведены программные модули, описывающие некоторые базовые узлы
цифровых устройств: дешифратор (ENTITY decode), мультиплексор (ENTITY
mux), схема выделения признака четности (ENTITY parity). Декларация биб-
лиотек и пакетов здесь опущена. Значения параметров настройки, опреде-
ленных в декларации GENERIC (л — разрядность входного или выходного
кода и delay — время задержки), могут задаваться в модулях высшего уров-
ня иерархии, в которые эти узлы включаются. При автономном использо-
вании проектных модулей decode, mux и parity принимается п = 16 и
delay = 2 ns.
ENTITY decode IS
GENERIC (n: integer:=16); — число выходов
PORT (input: IN integer RANGE 0 TO n -1;
EN: IN std_logic; — разрешение
output:OUT std_logic_vector (n -1 DOWNTO 0));
END decod;
ARCHITECTURE behave OF decod IS
BEGIN
PROCESS(en,input)
VARIABLE i: integer RANGE 0 TO n -1;
BEGIN
FOR i IN 0 TO 15 LOOP
IF en='l' and i=input THEN
output(i)<='!' AFTER 2 ns;
ELSE output(i)<='0' AFTER 1 ns;
END IF;
END LOOP;
END PROCESS;
END behave;
ENTITY mux IS
GENERIC (n: integer:=16; — число входов
delay:time:=2 ns); — задержка распространения
PORT (adress: IN integer RANGE 0 TO n -1;
data: IN std_logic_vector ( n -1 DOWNTO 0 ) ;
output:OUT std_logic);
END mux;
ARCHITECTURE behave OF mux IS
BEGIN
Output<= data(adress) AFTER delay;
END behave;
ENTITY parity IS
GENERIC (n: integer:=16; — число входов
delay:time:=2 ns); — задержка распространения
PORT (data: IN std_logic_vector ( n -1 DOWNTO 0 ) ;
parit_check: OUT std_logic);
END parity;
ARCHITECTURE parit_behave OF parity IS
BEGIN
PROCESS (data)
VARIABLE i:integer RANGE 0 to n -1;
VARIABLE temp:std_logic;
BEGIN
temp: ='0' ;
FOR i IN 0 TO n -1 LOOP
temp:= temp xor data(i);
END LOOP;
parit_check<=temp AFTER delay;
END PROCESS;
END parit_behave;
Описание триггеров и регистровых схем

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

триггерами:
П асинхронное управление;
О статическое управление, или управление уровнем;
П динамическое управление, или управление фронтом;
О смешанные варианты.
Асинхронное управление характеризуется тем, что события на информаци-
онных входах непосредственно вызывают изменение состояния триггера.
Единственный нетривиальный триггер с асинхронным управлением это
RS -триггер, функциональная модель которого может быть представлена сле-
дующим образом:
PROCESS (R,S)
BEGIN IF R='l' and S='l' THEN
ASSERT FALSE REPORT " Illegal input combination"
SEVERITY note;
ELSIF 3 = 4 ' THEN Q<='1';
ELSE Q<='0';
END IF;
END PROCESS;
Здесь R, s и Q определены как сигналы или порты типа BIT.

Если требуется выполнить моделирование с учетом возможных переходных
состояний входов и выходов, то следует ввести ряд уточнений, например
таких, как в программе (листинг 3.23).
ENTITY R_S_flip_flop IS
GENERIC (delay: time:=2 ns;);
PORT (R,S:IN std_logic;
Q,NQ: OUT std_logic)
END R_S_flip_flop;
ARCHITECTURE R_S_timing OF R_S_flip_flop IS
BEGIN
PROCESS (R,S)
BEGIN IF R='l' and S='0' THEN Q<= 'X','l' AFTER 2*delay;
1 1 I
NQ<= X , 0' AFTER delay;
ELSIF R='0' and S='l' THEN Q<='X','0' AFTER delay;
NQ<='X',4' AFTER 2*delay;
ELSIF R='l' and S='l' THEN Q<='X','0' AFTER delay;
NQ<='X','0' AFTER delay;
ELSIF R='0' and S='0'

and Q'DELAYED(delay)='0' and NQ Q'DELAYED(delay)='0'
then Q<='X'; NQ<='X';
ELSE Q<='X'; NQ<='X';
END IF;
END PROCESS;
END R_S_timing;
Программа в листинге 3.23 соответствует поведению триггерной ячейки на

двух перекрестно соединенных элементах ИЛИ -НЕ. Она учитывает возмож-
ности подачи на вход неопределенных сигналов, отражает переход обоих
плеч триггерной ячейки в состояние логического нуля при одновременной
подаче логической единицы на входы сигналов установки и сброса, а также
неопределенность дальнейшего поведения после одновременного перехода
этих сигналов из единичного состояния в нулевое. Впрочем, если описывать
простой RS -тригтер, то легче его показать как соединение пары логических
ячеек И -НЕ или ИЛИ -НЕ:
Q<=not (NQ or S) after delay;
NQ<= not (Q or R) after delay;
Но описание, подобное приведенному в листинге 3.23, может быть совме-

щено с объявлением других способов управления при моделировании ком-
бинированных триггерных структур.
В триггерах со статическим управлением при пассивном уровне сигнала на
управляющем входе изменение состояния невозможно, а при активном
уровне изменения информационных сигналов приводят к изменению со-
стояния. Рассмотрим процесс d_ievei, описывающий D -триггер с потенци-
альным управлением, иногда называемый защелкой (Latch), для которого
положительный сигнал является разрешающим.
d_level: PROCESS (clock, data)
BEGIN IF clock='l' THEN Q<=data AFTER delay;
END IF;
END PROCESS;
Тело процесса исполняется как после любого изменения сигнала clock

(тактирующий сигнал), так и сигнала data (информационный сигнал), одна-
ко при ciock='0' изменение состояния Q не происходит.
При динамическом управлении изменение состояния триггера происходит
только непосредственно после фронта или спада сигнала на тактирующем
входе. Новое состояние определяется сигналами на информационных входах
в момент изменения управляющего сигнала, а само по себе изменение со-
стояний информационных входов не вызывает изменения состояния триг-
гера.
Оператор процесса d_edge в листинге 3.24 интерпретирует это правило и

отличается от оператора d_ievel списком инициализаторов. Указанный
процесс вызывается только при изменении сигнала clock, причем измене-
ние состояния может происходить, если произошел переход clock в состоя-
ние логической единицы. Следующее состояние определяется состоянием
информационного входа. Но если сигнал data стабилен перед фронтом
clock в течение интервала времени, меньшего, чем необходимое для данного
триггера время предустановки deiay_d_cik, следующее состояние не опреде-
лено.
D_edge: PROCESS(clock)
BEGIN IF clock='l' THEN
IF data'last_event<delay_d_clk THEN
Q<='X';
ELSE Q<=data AFTER delay;
END IF;
END PROCESS;
При представлении комбинированных триггерных устройств в число ини-

циализаторов процесса, в котором описывается такое устройство, включают
и асинхронные входы, и тактирующий сигнал. При составлении программы
необходимо учитывать относительные приоритеты управляющих сигналов и
их совместимость. В качестве примера оператор PROCESS, представленный
в листинге 3.25, содержит упрощенное описание комбинированного JKRS -
триггера (переходные состояния в этой модели игнорируются и временные
соотношения опущены). Входы асинхронной установки и сброса s и R, как
обычно, являются более приоритетными по сравнению с входом синхрони-
зации clock (в данном случае представлена синхронизация положительным
фронтом). Только при нулевых сигналах на входах R и s выполняется опера-
тор выбора CASE, интерпретирующий функционирование J -K -триггера.
PROCESS (clock,r,s)
VARIABLE Qinternal:= BIT;
VARIABLE variant: bit_vector (2 downto 0 ) ;
BEGIN variant := j&k;
IF R='l' and S='l' THEN
ASSERT FALSE RETORT " Illegal input combination"
SEVERITY ERROR;
ELSIF 3 = 4 ' THEN Q<=4';
ELSIF R='l' THEN Q<='0';
ELSIF R='0' and S='0' and clock='l' and not clock'stable THEN — **
CASE variant IS
WHEN "10" => Qinternal: = 4 ' ;
WHEN "01"=> Q i n t e r n a l : = ' 0 ' ;
WHEN "00"=> Qinternal:=Qinternal;
WHEN "11"=> Qinternal:= not Qinternal;
END CASE;
END IF;
Q<=Qinternal;
END PROCESS;
Особо следует обратить внимание на конструкцию ciock=4' and not

clock'stable в условии, помеченном двумя звездочками. Простое условие
ciock='l' оказывается недостаточным для корректного описания поведения.
При переходе сигналов к или s в состояние логического нуля приведенный
в листинге процесс будет инициализирован. Если бы отсутствовало допол-
нительное условие not clock'stable, был бы выполнен один из вариантов
оператора выбора, даже если в данный момент нет изменений на входе
clock. Это не соответствует реальному поведению. В целом, во избежание
подобных коллизий можно рекомендовать использовать запись вида
X
IF <сигнал синхронизации> =<значение> and

not <сигнал синхронизации>'STABLE THEN ...
всегда, когда описываются устройства с динамически управляемыми триг-

герами.
Регистр — это набор триггеров, объединенных общими цепями управления.
Соответственно регистры в программах удобно представлять процессами,
список инициализаторов которых включает управляющие сигналы, а в теле
процесса находятся операторы присваивания, определяющие состояние
триггеров регистра после изменений управляющих сигналов. Логика анализа
условий выполнения операторов в теле этого процесса не отличается от та-
кой же логики для одиночных триггеров.
Состояния триггеров отражаются переменными или сигналами. Можно ис-
пользовать скалярное представление и индивидуальные имена для всех
триггеров регистра, однако чаще используется групповое представление.
Представление в виде битового вектора (типа bit_vector или std_iogic_
vector) обеспечивает сочетание простоты описания групповых действий над
содержимым регистра с простотой выделения информации о состоянии от-
дельных разрядов. В качестве примера в листинге 3.26 представлена про-
грамма, описывающая преобразователь параллельного кода в последова-
тельный с асинхронной загрузкой кода и синхронным сдвигом.
LIBRARY ieee;
ENTITY Parallel_to_sequential IS
GENERIC ( n:integer:=8);
PORT (elk,load: IN std_logic;
din:IN std_logic_vector (n -1 DOWNTO 0 ) ;
dout:OUT std_logic);
END new_del;
ARCHITECTURE test OF Parallel_to_sequential IS

SIGNAL reg: std_logic_vector (n -1 DOWNTO 0 ) ;
BEGIN
dout<=reg(n - l ) ;
PROCESS
VARIABLE i: integer n -1 DOWNTO 0;
BEGIN
WAIT UNTIL load= ' 1';
reg<=din; —загрузка кода
j: -0;
WHILE j<n LOOP — n сдвигов после загрузки
WAIT UNTIL clk='l' and not elk'stable;
FOR i IN n -1 DOWNTO 1 LOOP
reg (i)<=reg (i -1) ;
END LOOP;
reg(0}<='0';
j:=j+l;
END LOOP;
END PROCESS;
END test;
При включении описываемого этой программой устройства (и аналогично,

после начала моделирования) начинается этап ожидания сигнала загрузки
load. Получив ioad='i', устройство осуществляет n сдвигов, каждый из ко-
торых выполняется по положительному фронту сигнала elk. Каждый сдвиг
представлен в программе как последовательность присвоений состоянию
каждого разряда состояния предыдущего в операторе FOR. В программе ис-
пользованы как описания действий с целым вектором при загрузке, так и
действий с отдельными разрядами вектора для описания процедуры сдвига
и формирования выходного сигнала.
( Замечание }
Подобное описание соответствует семантике VHDL'87, хотя и не противоречит
VHDL'93, где операции сдвига введены как стандартные.
В ряде случаев удобно использовать для представления содержимого регист-

ра ограниченные целые и перечислимые типы данных. Такое представление
может обеспечить большую наглядность и улучшить понимаемость про-
грамм. Формально такие типы данных определены как скалярные, а по су-
ществу могут в сжатой форме отражать групповой объект — код состояния
регистра.
Например, программа (листинг 3.27) представляет описание простого опе-
рационного блока, предназначенного для выполнения следующего набора
операций с содержимым регистра данных data_register: clear — очистка,
пор — сохранение состояния, load — загрузка данных, shift — сдвиг в сто-
рону старших разрядов, inc — инкремент содержимого, dec — декремент.
Код операции command для наглядности представлен данными перечисли-
мого типа instruction, а данные — как ограниченные целые. Чтобы соот-
ветствующие данные могли быть "понятны" другим проектным модулям, эти
типы должны быть объявлены в общедоступном пакете, в данном примере,
в пакете OPER_UNIT_DECL. Код операции загружается при единичном сигнале
на ВХОДе load_command И МОЖ6Т сохраняться В регистре instruction_register
в течение нескольких следующих операций, инициируемых положительным
фрОНТОМ сигнала execute.
Данные типа instruction и типа data в аппаратуре представлены многораз-
рядным кодом. Для доступа до конкретного разряда кодов, отнесенных
к такому типу данных, необходимо использовать функции преобразова-
ния типов. Функции преобразования "битовый вектор — целое" и обратно
определены в ряде стандартных пакетов, например std_iogic_utii системы
ModelSim. Для типов, определяемых пользователем, может потребоваться
создание специальных функций преобразования.
PACKAGE oper_unit_decl IS
TYPE instruction IS (clear, пор,load,shift,inc,dec);
TYPE data IS RANGE 0 TO 255;
END;
USE work.oper_unit_decl.all;
ENTITY oper_unit IS
PORT ( load_coinmand, execute: IN bit;
command: IN instruction;
data_in:IN data;
data_put:OUT data);
END oper_unit;
ARCHITECTURE test OF oper_unit IS

SIGNAL data_register: data;
SIGNAL instruction_register:instruction;
BEGIN
PROCESS (load_coramand)
BEGIN instruction_register<=command;
END PROCESS;
PROCESS (execute)
BEGIN IF execute='l' and not execute'stable THEN
CASE instruction_register IS
WHEN load => data_register<=data_in;
WHEN пор =>null;
WHEN clear=> data_register<=0;
WHEN shift => data_register<=data_register*2;
WHEN inc => data_register<=data_register+l;
WHEN dec => data_register <=data_register -l;
END CASE;
END IF;
END PROCESS;
END test;
На основании вышесказанного можно рекомендовать придерживаться сле-

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

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

vector), и как числа. Логика формирования выходной величины арифмети-
ческого узла может представляться в программе как с помощью логических
выражений, так и в арифметической форме. С точки зрения представления
поведения варианты эквивалентны, но описание преобразований в арифме-
тической форме интерпретируется в реальном устройстве типовыми узлами
библиотеки системы проектирования, а запись в логической форме обеспе-
чивает большую степень вмешательства разработчика в создание техниче-
ской реализации. Часто форма представления определяется удобствами опи-
сания сложных структур, содержащих арифметические узлы.
Описание арифметических преобразований данных, представленных в чис-
ленной форме, достаточно традиционно — используются арифметические
выражения. Относительно операций над кодами отметим, что стандарт язы-
ка VHDL не определяет арифметических операций над двоичными вектора-
ми. Однако все современные системы интерпретации языка сопровождают-
ся пакетами, содержащими определение функции преобразования "число -
битовый вектор" и "битовый вектор—число", а также пакетами, встроенные
функции которых позволяют оперировать с битовыми векторами как числа-
ми при различных способах кодирования. Один и тот же арифметический
символ в применении к преобразованию кодов может интерпретироваться
по -разному. Это определяется тем, какой пакет объявлен используемым в
программе. Например, в системе ModelSim знак " + " применительно к дан-
ным типа std_iogic_vector будет интерпретирован различно. Если в про-
грамме определено использование пакета std_iogic_unsigned, то операция
интерпретируется как сложение по правилам беззнаковой двоичной ариф-
метики (старший разряд слева). Если объявлено использование пакета
std_iogic_signed, то тот же знак задает сложение в дополнительном коде
(крайний левый разряд знаковый), а если ни один пакет не указан, знак
сложения, примененный к вектору, рассматривается как ошибка. Пакеты по
умолчанию скомпилированы в системную библиотеку IEEE.
Листинг 3.28 представляет первичный проектный модуль ENTITY add_subb —
сумматор -вычитатель чисел в беззнаковом двоичном представлении, при
этом разрядность width является параметром настройки. Этому ENTITY со-
поставлено два архитектурных тела. Вариант используемого в конкретном
проекте архитектурного тела и разрядность сумматора задаются в модуле
высшего уровня иерархии проекта (см. разд. 3.2. Л).
В архитектурном теле arithmeticjoresentation используется арифметическая
форма представления преобразований. Для обеспечения доступа к содержа-
щимся в системной библиотеке функциям, определяющим арифметические
преобразования битовых векторов, в программе имеется декларация исполь-
зования соответствующего пакета (данный пример ориентирован на реа-
лизацию в системе отладки ModelSim v.5.5). С целью обеспечения возмож -
ности контроля переполнения использовано "внутреннее" расширение раз-

рядной сетки, т. е. введены вспомогательные переменные а, ь и s, причем а
и ь получаются из входных кодов добавлением нуля со стороны старших
разрядов. При сложении и вычитании в расширенном формате наличие пе-
реполнения в основных разрядах приведет к появлению единицы в допол-
нительном разряде результата s, который и используется как сигнал пере-
полнения. Код фактического результата получается переименованием ос-
новных разрядов суммы s.
Логическая форма представления иллюстрируется архитектурным телом
comb_logic. Здесь более явно задана структура проекта — в данном случае
предполагается схема с групповым переносом [27]. Сумматор разбивается на
группы по четыре разряда, внутри групп формируются разряды суммы и
разрядные переносы по последовательной схеме (переменные carry). Вход
переноса каждой группы (fast_carry) формируется с использованием из-
вестной логики ускоренного переноса на основании входных сигналов пре-
дыдущей группы.
LIBRARY IEEE;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned."+";
ENTITY add_subb IS
GENERIC (width:INTEGER);
PORT ( data_a,data_b: IN std_logic_vector (width -1 DOWNTO 0 ) ; — входы
direction, — '0' -сложение, '1' -вычитание
carry_in: IN std_logic; — входной перенос
sum :OUT std_logic_vector(width -1 DOWNTO 0 ) ; — результат
overflow: OUT std_logic); — переполнение
END add_subb;
ARCHITECTURE arithmetic_presentation of add_subb is

SIGNAL a,b,s:std_logic_vector( width DOWNTO 0 ) ;
BEGIN
a<= '0'& data_a; b<= '0'& data_b;
s<= a + b + carry_in WHEN direction ='0' ELSE
a — b -carry_in;
sum <= s(width -1 DOWNTO 0);
overflow<= s(width);
END arithmetic_presentation;
ARCHITECTURE comb_logic OF add_subb IS

CONSTANT group: INTEGER:= width/4;— число групп при разбиении по четыре
— разряда в группе
BEGIN
PROCESS( data_a,data_b, carry_in)
ТУРЕ carry_array IS ARRAY (4 DOWNTO 0, group -1 DOWNTO 0) OF std_logic;
VARIABLE carry: carry_array; — переносы
VARIABLE i :INTEGER RANGE 0 TO 3;
VARIABLE group_number: INTEGER RANGE 0 TO group - 1 ;
VARIABLE c_b,lb: INTEGER RANGE width -1 DOWNTO 0;
VARIABLE fast_carry : — выходы группового переноса
std_logic_vector (group -1 DOWNTO 0 ) ;
VARIABLE ps,pm,a_carr: std_logic_vector (width -1 DOWNTO 0 ) ;
BEGIN
вспомогательные переменные для вычисления переносов
IF direction='0' THEN a_carr:= data_a;
else a_carr:= not data_a;
END IF;
ps:= a_carr xor data_b; — Partial Sum — разрядные полусуммы
pm:= a_carr and data_b; — Partial multiply — разрядные произведения
конец вспомогательных переменных
FOR group_number IN 0 TO group -1 LOOP — цикл по группам разрядов
lb :=4*group_number;— номер младшего разряда в группе
IF group_number=0 THEN carry (group_number,0):=carry_in;
ELSE carry(group_number,0):= fast_carry (group_nutriber - l ) ;
END IF;
FOR I IN 0 TO 3 LOOP — анализ разрядов внутри группы
C_b:= lb+ I; — абсолютный номер разряда
sum(c_b) <= data_a(c_b) xor data_b(c_b) xor carry(group_number - , I ) ;
carry(group_number,i+1) := (a_carr(c_b) and data_b(c_b))
or ((a_carr(c_b) or data_b(c_b)) and carry(group_number,i));
END LOOP;
FAST_CARRY(GROUP_NUMBER):=
pm(lb+3)
or (pm(lb+2) andps(lb+3))
or (pm(lb+l) and ps(lb+3)and ps(lb+2))
or (pm(lb) and ps(lb+3)and ps(lb+2)and ps(lb+l))
or (carry(group_number,0)and ps(lb+3)and ps(lb+2)and ps(lb+l)and ps(lb));
END LOOP;
overflow<= fast_carry(group - 1 ) ;
END PROCESS;
END comb_logic;
Профамма (листинг 3.28) соответствует комбинационной схеме суммирова-

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

тинге 3.29, несмотря на подобие выполняемых операций (в обоих процессах
выполняются инкремент и сдвиг), представляют совершенно различные ал-
горитмы функционирования и технические реализации. Процесс comb задает
комбинационные схемы арифметических преобразований входных кодов,
в то время как процесс registered определяет счетчик и регистр сдвига. Ис-
ходными данными могут быть как целые, так и битовые векторы.
comb: PROCESS ( data_a, data_b)

begin
shift<= data_a sla 1;
inc <= data_b+l;
END PROCESS;
registered: PROCESS (clock)

begin ...
If (clock='l') then
shiftl<= shiftl sla 1;
incl <= incl+1;
END IF;
END PROCESS;
Описание конвейерных реализаций рассмотрим на примере программы

конвейерного умножителя (листинг 3.30). Реализуется стандартная вычисли-
тельная схема для умножения целых чисел, представленных в двоичной
форме:
product = sum (i=0 to n-1)[а х 2i х b(i)];
где а — множимое, b(i) — i -й разряд множителя, п — разрядность операндов

и product — результат.
Особенность реализации состоит в том, что исходные аргументы data_a и
data_b продвигаются в каждом такте, инициируемом фронтом тактового
сигнала, между ступенями конвейера. В каждой i -й ступени конвейера к на-
копленной на предыдущей ступени сумме прибавляется произведение мно-
жимого, сдвинутого на i разрядов, и i -го бита множителя.
В конвейерной схеме в любой такт времени в каждой i -й ступени конвейера
сохраняется и обрабатывается пара сомножителей, поступившая на вход
устройства на i тактов ранее текущего такта, и соответствующий этой паре
промежуточный результат. Одновременно в конвейере находятся в различ-
ных стадиях обработки данные, поступившие на вход в нескольких последо -
нательных тактах. Таким образом достигается повышение производительно -

сти устройства по сравнению с комбинационной реализацией. Однако при
этом увеличивается время задержки формирования каждого отдельного ре-
зультата.
LIBRARY IEEE;
USE work.std_logic_util.all;
ENTITY pipe_nul IS
GENERIC ( width:integer:=8);
PORT ( data_a,data_b: IN integer RANGE 0 TO 2**width -l;
clock: IN std_logic;
product :OUT integer RANGE 0 NO 2**(2*width) -1
);
END pipe_mul;
ARCHITECTURE behave OF pipejnul IS

TYPE shift_array IS ARRAY (width -1 downto 0)
OF integer RANGE 0 TO 2*width -l;
TYPE partial_mult_array IS ARRAY (width downto 0)
OF integer RANGE 0 to 2**(2*width) - 1 ;
SIGNAL a_shift,b_shift:shift_array;
SIGNAL P_mult:partial_mult_array;
BEGIN
PROCESS( clock)
VARIABLE i:integer RANGE width -1 DOWNTO 0;
VARIABLE b,bO: std_logic_vector( width -1 DOWNTO 0 ) ;
BEGIN
IF( clock='1') and not clock'stable THEN
bO:= to_yector(data_b,width);
IF ( bO(0) = '1') THEN p_mult(0)<=data_a;
else p_mult(0)<=0;
END IF;
a_shi ft(0)<= data_a;
b_shift(0)<= data_b;
FOR i IN 1 TO width LOOP
a_shift(i)<=a_shift(i -l)sra 1;
b_shift(i)<=b_shift(i - 1 ) ;
b:=conv_std_logic_vector(b_shift(i -1),width);
IF (b(i) = '1') THEN
p_mult(i)<= a_shift(i -l)+ p_mult(i-1);
ELSE p_mult(i)<=p_mult(i - 1 ) ;
END IF;
END LOOP;
product<= p_mult (width);

END I F ;
END PROCESS;
END behave;
Замечание
Если в списке инициализаторов процесса в программе (листинг 3.30) записать
имена входных портов, а промежуточные данные определить как переменные,
программа преобразуется в описание матричного умножителя комбинационно-
го типа. Впрочем, в этом случае нет необходимости формировать цепочку
элементов задержки исходных данных a _ s h i f t и b_shift, т. к. для формиро-
вания значений частичных произведений можно непосредственно использовать
данные с портов.
Описание цифровых автоматов

Моделью последовательностного дискретного устройства является конечный
автомат, т. е. система, способная находиться в одном из состояний из неко-
торого дискретного множества, изменять состояние в зависимости от входа
и формировать выходы в соответствии с определенным алгоритмом. Мы
ограничимся представлением синхронных автоматов, изменение состояний
в которых происходит в моменты появления фронта сигнала на тактирую-
щем входе. Интервал времени между двумя соседними фронтами тактирую-
щего сигнала назовем тактом работы автомата.
Сначала рассмотрим описание автоматов в абстрактной форме, т. е. когда
используются обобщенные обозначения состояний, входов и выходов как
данных перечислимого типа. Далее показано, как создавать описания более
близкие к реальности, определяя входы, состояния и выходы как данные
типа битового вектора или именованные сигналы.
Традиционно деление автоматов на автоматы Мили и автоматы Мура. В по-
следнее время набор применяемых моделей, исходя из требований и воз-
можностей практики, расширился — используются автоматы Мили с асин-
хронными выходами, автоматы Мура с предустановкой и ряд других моди-
фикаций.
В автомате Мили состояние и выходной сигнал в очередном такте опреде-
ляются состоянием и входным сигналом в предыдущем такте работы [15].
Такой модели соответствует структура, проведенная на рис. 3.12.
Пусть автомат Мили задан таблицей переходов и таблицей выходов
(табл. 3.5), где в клетках таблицы переходов записаны состояния, в которые
переходит автомат из исходного состояния при соответствующем входе, а
в клетках таблицы выходов записывается выход при тех же условиях. Не-
трудно видеть, что приведенный пример соответствует реверсивному счет-
чику, причем выходы Y1 и Y2 соответствуют выдаче сигналов переноса.
Рис. 3 . 1 2 . Структура автомата Мили
Таблица 3.5. Таблицы переходов и выходов автомата Мили
Таблица переходов Таблица выходов

Вход Исходное состояние Вход Исходное состояние
SO S1 S2 S3 SO S1 S2 S3
хо SO S1 S2 S3 ХО YO YO YO YO
Х1 S1 S2 S3 SO Х1 YO YO YO Y1
Х2 S3 SO 81 S2 Х2 Y2 YO YO YO
Фрагмент VHDL -программы, описывающий такой автомат, имеет вид, при-

веденный в листинге 3.31. Предполагается, что перечислимый тип state за-
дан списком имен, сигналы у и х объявлены как порты в декларации ENTITY,
соответствующей архитектурному телу, в котором определен данный про-
цесс, а их тип задан списком имен — значений.
Процесс после задания исходного состояния (s<=so) входит в бесконечно
повторяющуюся петлю, в начале которой помещен оператор WAIT. Приме-
ненная конструкция оператора соответствует синхронному автомату, со-
стояние которого изменяется по тактирующему сигналу p_cik, причем p_cik
является глобальной переменной проекта.
Важно обратить внимание, что изменения состояний происходит в момент
появления нарастающего фронта сигнала p_cik, т. к. запускающее событие
определено как "появление единицы и наличие переходного процесса на
входе p_clk".
Использование в качестве условия продолжения процесса выражения "not

p_clk' stable" соответствует реальной структуре устройства, реализующего
автомат. В таком устройстве состояние отображается состоянием регистра.
Так как этот регистр является датчиком информации о текущем состоянии
и одновременно приемником нового значения, во избежание гонок необхо-
димо использовать регистры с динамическим управлением. После вычисле-
ния нового состояния и выходных сигналов процесс переходит в состояние
ожидания нового запускающего события. Обратите внимание на то, что
сигналы вычисляются на основе состояний, которые были перед фронтом
тактирующего сигнала, а не вычисленных в текущем цикле.
Mealey_nach:PROCESS
VARIABLE s: state;
BEGIN
s<=SO;
LOOP
WAIT UNTIL (p_clk='l' and not p_clk'stable);
— Реализация переходов
CASE S IS
WHEN SO => IF x=xO THEN s<=sO;
ELSIF (x=xl) THEN s<=Sl;
ELSE s<=s2;
END IF;
WHEN SI => IF x =xO THEN s<=Sl;
ELSIF x =xl THEN s<=S2;
ELSE s<=SO;
END IF;
WHEN S2 => IF x =xO THEN s<=S2;
ELSIF x =xl THEN s<=S3;
ELSE s<=S1;
END IF;
WHEN S3 => IF x =xO THEN s<=S3;
ELSIF x =xl THEN s<=SO;
ELSE s<=S2;
END IF;
END CASE;
Формирование выходов
IF ( s = s3 and x=xl) THEN y<=yl;
ELSIF (s =sO and x=x2) THEN y<=y2;
ELSE y<=yO;
END IF;
END loop;
END process;
Рис. 3.13. Каноническая реализация автомата Мура
В автомате Мура выходной сигнал зависит только от состояния автомата

в текущий момент времени и обычно включается в состав отмеченной таб-
лицы переходов. Такому представлению соответствует структура, приведен-
ная на рис. 3.13. Описание автомата на основании модели Мура отличается
не только тем, что значение х не входит в выражение для вычисления выхо-
да, но и самой структурой программы. Действительно, при вычислениях по
программе (листинг 3.31) аргументом является предыдущее состояние. В мо-
дели Мура подобная запись вызывает как бы запаздывание на один такт.
Чтобы корректно представить автомат Мура, целесообразно определение
выходов выделить в отдельный процесс, инициатором которого является
сигнал, отображающий состояние автомата s. Типовая структура подобной
программы приведена на рис. 3.14.
ATCHITECTURE <имя архитектурного тела>

OF <имя ENTITY> IS
TYPE state IS < идентификаторы состояний>
SIGNAL S: state;
BEGIN
F2: PROCESS (S) — комбинационная логика
BEGIN
Y<=F2(S);
END PROCESS F2;
MEM: PROCESS (clock,reset) — регистровая память
VARIABLE В: state;
BEGIN
IF reset='l' THEN < исходное состояние>
IF clock='l' and clock'event THEN
b :=Fl(x,S); — комбинационная логика
S<=b;
END IF
END PROCESS MEM;
END <имя архитектурного тела>;
Рис. 3.14. Структура программы описания автомата Мура

В качестве примера в листинге 3.32 представлено описание автомата Мура,

заданного отмеченной таблицей переходов (табл. 3.6). Предполагается, что
перечислимые типы mash_in, state и mash_out определены в пакете
State_mashine_define, скомпилированном В рабочую библиотеку work.
Таблица 3.6. Отмеченная таблица переходов автомата Мура

Состояния / выходы
Вход SO/YO S1/Y1 S2/YO
хо SO S1 SO
Х1 S1 S2 S1
USE work. State_mashine_define.all

ENTITY moor_example IS
PORT(clock, reset, :IN std_logic;
X: IN mash_in; — допустимые значения ХО и X1
z: OUT mash_out); — допустимые значения YO и Y1
END moor_example;
ARCHITECTURE abstraction OF moor_example IS
SIGNAL moor: state; — список допустимых значений (SO,S1,S2);
BEGIN
PROCESS (clock,reset)
BEGIN
IF reset='l' THEN moor<=SO;
ELSIF clock='l' and clock'event THEN
CASE moor IS
WHEN S0=> IF x=XO THEN moor= SO;
ELSE moor= S1;
END IF;
WHEN sl=> IF x=XO THEN moor= S1;
ELSE moor= S2;
END IF;
WHEN s2=> IF x=XO THEN moor= SO;
ELSE moor= S1;
END IF;
END CASE;
END IF;
END PROCESS;
PROCESS (moor)
BEGIN
IF moor=Sl THEN z<=Zl;
ELSE z<= ZO;
END IF;
END PROCESS;
END abstraction;
В реальных системах входы и выходы представлены конкретными кодовыми

комбинациями и их представление в абстрактной форме не всегда удобно.
Однако запись функций переходов и выходов при представлении соот-
ветствующих данных в форме битовых векторов структурно не отличается
приведенных примеров, записанных для абстрактного представления: доста-
точно указывать в выражениях условий не абстрактные имена входов, а со-
ответствующие коды. Отметим, что любому абстрактному входу соответству-
ет одна и только одна кодовая комбинация. Иногда более компактная и на-
глядная запись получается, если условия переходов формируются как
функции конкретных битов входного кода, а каждому переходу соответству-
ет установка или сброс конкретного бита результата. В качестве примера
перепишем представление автомата, заданного табл. 3.6 и представленного
процессом meaiey_mach в листинге 3.33, при использовании следующего
кодирования входов и выходов:
хО="00", xl="01", x2="lx", yO="00", yl="01", у2= ""10".
Mealey_mach:PROCESS
VARIABLE s: state;
Variable prom: std_logic_vector (1 downto o ) ;
BEGIN
s<=SO;
LOOP
WAIT UNTIL (p_clk='l' and not p_clk'stable);
Prom="00"
CASE S IS
WHEN SO => IF x(l) = 4' THEN s<=s3; prom(l) : = '!'; ~x=x2
ELSIF x(0)='0' THEN s<=sO; —x=xO
ELSE s<=sl; —x=xl
END IF;
WHEN SI => IF x(l)='l' THEN s<=sO;
ELSIF x(0)='0' THEN s<=sl;
ELSE s<=s2;
END IF;
WHEN S2 => IF х(1) = Ч' THEN s < = s l ;

ELSIF x ( 0 ) = ' 0 ' THEN s<=s2;
ELSE s<=s3;
END I F ;
WHEN S3 => IF x ( l ) = ' l ' THEN s < = s l ;
ELSIF x ( 0 ) = ' 0 ' THEN s<=s3; p r o m ( 0 ) < = ' 1 ' ;
ELSE s<=s0;
END I F ;
END I F ;
END CASE;
y<=prom;
END loop;
END process;
Следующий простой пример иллюстрирует описание управляющего автома-

та с объявлением индивидуальных имен входных и выходных сигналов,
причем в данном примере роль выходных сигналов исполняют непосредст-
венно биты кода состояния автомата. Автомат задан графом переходов,
представленным на рис. 3.15.
Рис. 3.15. Граф переходов автомата с именованными входами и выходами
На дугах переходов отражены только значения сигналов, вызывающие пере-

ход из соответствующего состояния. Алгоритм предполагает, что в исходном
состоянии, обозначенном idle, устройство ожидает единичного уровня сиг-
нала на входе START. После этого в течение одного такта автомат находится
в состоянии подготовки (prepare), выдавая на выход сигнал, также обозна-
ченный prepare, который сопоставлен младшему биту кода состояния. Пе-
реход в состояние работы (work) из состояния подготовки безусловный.
Далее, до тех пор пока не получен единичный сигнал на входе STOP, автомат
сохраняет свое состояние, выдавая единичный управляющий сигнал, кото -
рый сопоставлен старшему биту коду состояния. Сигнал STOP переводит ав-
томат в исходное состояние.
В программе (листинг 3.34), описывающей этот автомат, переменная со-
стояния STATE представлена вектором, "составленным" из выходных сигна-
лов, а логика переходов базируется на анализе только тех входных сигналов,
которые важны в соответствующем состоянии.
ENTITY direct_inout_asignments IS
PORT( clk,reset:IN bit;
start,stop:IN bit;
work,prepare:inout bit);
END direct_inout_asignments;
ARCHITECTURE behave OF direct_inout_asignments IS
BEGIN
PROCESS (clk,reset)
VARIABLE state: bit_vector (I DOWNTO 0 ) ;
BEGIN state:=work & prepare;
IF reset='l' THEN work<='0'; prepare<='0';
ELSIF clk='l' and clk'event THEN
CASE state IS
WHEN "00"=> IF start='l' THEN
prepare<=' 1';
END IF/-
WHEN "01"=> prepare<='0';work<='1';
When "10"=> IF stop='l' THEN
work<='0';
END IF;
WHEN "11"=>NULL;
END CASE;
END IF;
END PROCESS;
END behave;
При описании аппаратуры на языке VHDL следует учитывать, что при ком-
пиляции программы структура синтезируемой схемы и ее временные харак-
теристики существенно зависят от формы записи автомата.
Варианты, подобные представленному листингом' 3.34, позволяют миними-
зировать запаздывание между выходными сигналами и регистром памяти.
В тех же случаях, когда необходимо минимизировать время удержания
входных данных, целесообразно использовать структуру автомата Мура
с предустановкой в соответствии со схемой, приведенной на рис. 3.16. Ти-
повая структура такой программы представлена на рис. 3.17.
Рис. 3.16. Автомат Мура с предустановкой
a r h i t e c t u r e moore2 of State_mashine is
<описания локальных сигналов>
process — схемы с памятью
begin
<установка исходного состояния>
wait u n t i l c l o c k = ' l ' and clock'event;
X1<=X; — предустановка входа
S<=F 1 (Xl,S); — изменение состояния
end process;
process (S,X1) — комбинационная логика
begin
Y<=F2(S,X1);
end process;
end moore2;
Рис. 3.17. Структура описания автомата Мура с предустановкой
И, наконец, следует отметить такую модификацию модели последовательно -

стных схем, как автомат Мили с асинхронными выходами, являющийся по
сути гибридом автоматов Мили и Мура. В этой модели выходной сигнал
является функцией от текущего состояния и состояния входов в текущий
момент времени. Структурное представление такого автомата представлено
на рис. 3.18. Программа, описывающая указанную реализацию, может быть
подобна по структуре рис. 3.14, с той разницей, что в список инициализато-
ров процесса F2 и в состав аргументов для вычисления выхода войдет не
только сигнал состояния, но и входной сигнал.
Рис. 3.18. Автомат Мили с асинхронными выходами
3.2.9. Подпрограммы
Подпрограммы в VHDL, как и в других алгоритмических языках, обеспечи-
вают, во -первых, структуризацию описания проекта за счет разделения его
на законченные внутренне определенные блоки, а во -вторых, являются
средством экономии времени проектировщика, позволяя заменить несколь-
ко описаний сходных фрагментов алгоритма одним объявлением подпро-
граммы и соответствующими ссылками на нее (вызовами) в основном тексте.
Каждая подпрограмма, используемая в проектном модуле, должна быть
представлена телом подпрограммы в разделе деклараций этого модуля или
проектного модуля, иерархически старшего по отношению к данному. Под-
робнее концепция видимости деклараций рассматривается далее в разд. 3.2.12.
Различают два вида подпрограмм — процедуры (PROCEDURE) и функции
(FUNCTION).
Оба вида содержат в своем теле набор последовательных операторов, которые
задают совокупность действий, исполняемых после вызова этой подпро-
граммы. Процедура возвращает результаты либо путем непосредственного
преобразования объектов, определенных в вызывающей программе (гло-
бальных сигналов или переменных), либо за счет сопоставления объектов
через список соответствий. Функция же определяет единственное значение,
используемое в выражениях, в которые включен вызов этой функции.
Объявления подпрограмм отображаются в текстах телами подпрограмм, ко-
торые подчиняются следующему синтаксическому правилу:
<тело подпрограммы> :: =
<спецификация подпрограммы> IS
<раздел деклараций подпрограммы>
BEGIN
« <последовательный оператор> »
END [ PROCEDURE | FUNCTION ] <имя подпрограммы>;
<спецификация подпраграммы> :: =
PROCEDURE <имя подпрограммы> [ (Интерфейсный список>) ]
FUNCTION <имя подпрограммы^ [ (<интерфейсный список>) ]
RETURN <тип>
<интерфейскый список> ::=
<элемент интерфейсного списка> «;<Элемент интерфейсного списка>»
<элемент интерфейсного списка>::=
[ CONSTANT | VARIABLE | SIGNAL ]
<формальный параметр> «,<формальный параметр>»
:<направление> <тип> [ :=<константное выражение> ]
Спецификация подпрограммы определяет ее интерфейс — имя, входные и

выходные данные. Формальный параметр следует понимать как имя, при-
сваиваемое на время исполнения подпрограммы фактическому параметру,
т. е. объекту, сопоставленному этому формальному параметру в списке соот-
ветствий оператора вызова. Входные данные подпрограммы специфициру-
ются направлением IN, выходные — направлением OUT, а данные, которые
воспринимаются подпрограммой и возвращаются в вызывающую программу
измененными, — как INOUT. Указание категории элемента списка (CONSTANT,
VARIABLE или SIGNAL) обеспечивает контроль корректности использования
подпрограммы. По умолчанию определено, что сопоставляемый объект от-
носится к категории VARIABLE. Несоответствие типа или категории фактиче-
ского или формального параметра является ошибкой. Необязательное кон-
стантное выражение, завершающее представление элемента интерфейсного
списка, допустимо только для параметров категории VARIABLE. Оно опреде-
ляет значение по умолчанию, т. е. принимаемое соответствующей перемен-
ной, если при каких -либо условиях вызова подпрограммы присвоение иного
значения не предусматривается.
В разделе деклараций подпрограммы могут определяться локальные, т. е.
определенные только в теле подпрограммы, объекты: вложенные подпро-
граммы, типы и подтипы данных, переменные, константы, атрибуты. Раздел
операторов содержит только последовательные операторы.
Вызов подпрограмм подчиняется единому для процедур и функций синтак-
сическому правилу:
<вызов подпрограммы> ::=
<имя подпрограммы>[ <список соответствий> ]
<список соответствий :: =
([ <Формальный параметр>] =><фактический параметр>
«,[ <Формальный параметр> ] => фактический параметр>»)
<фактический параметр> ::=
<выражение> | <константа> I <имя сигнала> | <имя переменной> |
<вызов функции>
Вызов процедуры записывается в программе как отдельный оператор, а вы-

зов функции используется в выражениях того же типа, что и тип возвра-
щаемого параметра, как обычная переменная.
Язык VHDL, в отличие от традиционных языков программирования, разли-
чает последовательный и параллельный вызов подпрограммы. Синтаксиче-
ски они одинаковы, но различна их локализация и правила исполнения.
Вызов функции трактуется как параллельный, если входит в параллельный
оператор, чаще всего — в оператор параллельного присваивания, и как по-
следовательный, если входит в последовательный оператор.
Оператор вызова процедуры является последовательным, если локализован в
теле процесса или теле другой подпрограммы. В иных случаях оператор вы-
зова подпрограммы интерпретируется как параллельный оператор. Одна и
та же подпрограмма может вызываться как параллельным, так и последова-
тельным оператором. Как и другие последовательные операторы, оператор
последовательного вызова выполняется после исполнения всех операторов,
предшествующих ему в теле процесса или теле подпрограммы. Параллель-
ный оператор вызова исполняется после изменения любого из сигналов,
перечисленных в списке соответствий этого оператора. Иными словами,
параллельный вызов процедуры эквивалентен процессу, тело которого сов-
падает с телом процедуры с точностью до обозначений, а список инициали-
заторов содержит входные фактические параметры оператора вызова.
Например, в листинге 3.35 представлены несколько узлов суммирования -
вычитания в различной форме (естественно, это лишь иллюстративный
пример — практически в подобных случаях используют одинаковую форму).
Предполагается, что все сигналы определены в ENTITY проекта, причем
controie определен как бит, остальные отнесены к типу integer.
ARCHITECTURE add_exainples OF somethin IS

PROCEDURE add_SUBB
( signal a,b:IN integer;
signal Operation : in std_logic; — '0' -add '1' — subb
signal Result: out integer) IS
BEGIN IF operation='0' THEN result<= a+b;
ELSE result<=a -b;
END IF;
END add_subb;
BEGIN
First: add_subb(xl,yl,controie,zl) ;
Second: add_subb( a=>xl,b=>yl, result=>z2, operation=>controle);
Third: PROCESS ( x2,y2, controle)
BEGINIF, controle='0' THEN z3<= x2+y2;

ELSE z3<=x2 -y2;
END IF;
END PROCESS;
fourth: PROCESS (controle)
BEGIN — .... <дополнительные операторы>
add_subb( хЗ,уЗ,controle, z4);
END PROCESS;
END add_examples;
Параллельные операторы вызова f i r s t и second иллюстрируют альтерна-

тивные способы записи списков соответствия. Первая форма записи списка
ассоциаций соответствует позиционному сопоставлению фактических и
формальных параметров подпрограмм, а вторая — сопоставлению по имени.
Позиционное сопоставление требует точного совпадения порядка записи
фактических параметров в списках соответствия и порядка записи формаль-
ных параметров в интерфейсном списке подпрограммы. Если какой -либо
параметр не используется или используется значение входа по умолчанию,
соответствующая позиция в списке отмечается как пустая. При сопоставле-
нии по имени порядок записи не имеет значения, важно лишь совпадение
имени формального параметра с именем, указанным в декларации подпро-
граммы.
Оператор процесса t h i r d реализует такие же преобразования, что и опера-
торы вызова f i r s t и second. Обратите внимание: список инициализаторов
этого процесса совпадает со списком формальных параметров оператора
f i r s t . И наконец, вызов подпрограммы в теле процесса fourth, внешне
совпадающий с оператором f i r s t , будет выполняться только при измене-
нии сигнала controle и после выполнения всех предшествующих ему до-
полнительных операторов.
Важное значение в подпрограммах имеет оператор возврата RETURN. В про-
цедуре этот оператор прекращает ее исполнение, передавая управление вы-
зывающей программе. Если исполнен оператор RETURN в процедуре, вызван-
ной последовательным оператором, то после него выполняется оператор
вызывающей программы, следующий за оператором вызова. После испол-
нения оператора RETURN в процедуре, вызванной параллельным оператором,
интерпретатор программы обращается к календарю событий и инициирует
исполнение оператора, связанного со следующим событием в календаре.
При отсутствии оператора возврата исполнение процедуры завершается по-
следним оператором в порядке записи.
Оператор возврата в теле функции обязателен. Он также прекращает испол-
нение подпрограммы, но, кроме того, выполняет присвоение значения ре-
зультату, который используется в вызывающей программе на месте вызова
функции.
Например, программа в листинге 3.36 содержит функцию, возвращающую

значение 0, если хоть один элемент во входном массиве равен нулю, и сум-
му всех элементов этого массива в противном случае. В операторе повторе-
ния последовательно проверяются элементы фактического массива, и если
очередной элемент нулевой, выполнение подпрограммы прекращается опе-
ратором RETURN о (возвращается нулевой результат). Если же нулевого эле-
мента в массиве нет, выполняется накопление суммы для всех элементов, и
это значение возвращается в вызывающую программу оператором RETUNN
sum. Имена result и input должны быть определены в иерархически стар-
шем модуле проекта как данные целого типа.
ARCHITECTURE nothing OF something IS

TYPE v IS ARRAY (integer rangeO) OF integer;
FUNCTION sum_until_zero (SIGNAL data:IN v)
return integer IS
VARIABLE i,sum:integer;
BEGIN FOR i IN data'range LOOP
IF data(i) =0 THEN RETURN 0;—обнаружен нулевой элемент
ELSE sum:= sum+data(i);
END IF;
END LOOP;
RETURN sum;
END sum_until_zero;
SIGNAL data_array : v ( 0 TO 15) ;
BEGIN
PROCESS(data_array)
BEGIN
result <= input+ sum_until_zero(data_array);
END PROCESS;
END nothing;
В связи с рассмотренным примером отметим еще одно обстоятельство.

Здесь в описании функции тип формального параметра определен как неог-
раниченный массив целых. Фактический параметр отнесен к тому же типу,
но при декларации сигнала определен фактический его размер. Размер мас-
сива в подпрограмме автоматически устанавливается равным размеру фак-
тического массива. Атрибут фактического массива data'range использован
для задания числа повторений оператора LOOP. Такой прием часто использу-
ется для создания подпрограмм обработки массивов произвольной размер-
ности.
3.2.10. Разрешаемые сигналы и шины

В предыдущих разделах мы обходили рассмотрение случаев, когда несколь-
ко источников подключаются к одной линии. Если сигнал имеет один драй-
вер, то его значение определяется достаточно просто. После исполнения
или перехода в состояние ожидания всех процессов и параллельных опера-
торов, вызванных общим событием, предсказанные изменения передаются
из драйверов сигналов, являющихся, в сущности, программными буферами,
в поле данных системы моделирования. Это и определяет новое значение
сигнала.
Однако во многих системах к одной линии подключено несколько источни-
ков. Например, шина данных компьютера может принимать сигналы от
процессора, памяти, периферийных устройств, а к линии данных матрицы
запоминающего устройства подключается достаточно много ячеек памяти, а
также буферы ввода/вывода. Этому соответствуют программные модели,
в которых один сигнал назначается в нескольких параллельных операторах
и процессах. В VHDL не любые сигналы способны принимать значение в
соответствии со значениями нескольких источников. Сигналы, значения
которых автоматически определяются исходя из состояний нескольких ис-
точников (драйверов), называют разрешаемыми (resolved). Разрешаемым мо-
жет быть объявлен конкретный сигнал или подтип данных, к которому
такой сигнал отнесен при его декларации. Мы ограничимся объявлением
сигнала как разрешаемого (resolved) через использование декларации разре-
шаемого подтипа. Напомним, что декларация подтипа может содержать имя
функции разрешения (resolution function). Функция разрешения определяет
правило вычисления сигнала, формируемого несколькими независимыми
источниками. В общем случае функция разрешения зависит от конкретных
условий приложения проекта, в том числе технологии изготовления проек-
тируемого устройства, и если в системе интерпретации отсутствует подхо-
дящий аналог, требуется разработка соответствующей программы.
Функция разрешения локализуется в том же программном модуле, что и
декларация подтипа, и вызывается всякий раз, когда меняет состояние лю-
бой из драйверов разрешаемого сигнала. Можно сказать, что по умолчанию
предполагается наличие в программном модуле параллельного вызова этой
функции, причем драйверы сигналов являются ее фактическими параметра-
ми, а возвращаемое значение присваивается сигналу.
Рассмотрим в качестве примера представление линии, к которой подклю-
чаются элементы с выходами типа "открытый коллектор". Если хоть один
источник выдает на линию уровень логического нуля, то на линии устанав-
ливается логический нуль. Источники могут быть независимыми и даже
представленными в различных проектных модулях. Если принять, что пере-
ходные состояния несущественны, можно ограничиться двоичным пред-
ставлением. Однако тип BIT не может быть использован в подобной ситуа -
ции, ибо является неразрешаемым. Введем тип odw, как разрешаемый под-
тип типа BIT, и соответствующую функцию разрешения:
FUNCTION resolved_odw( s:bit_vector) RETURN bit IS
VARIABLE c: bit:='l';
BEGIN FOR i IN s'range LOOP
IF s(i)='0' THEN c:='0'; EXIT;
END IF;
END LOOP;
RETURN c;
END resolved_odw;
SUBTYPE odw IS resolved_odw bit;
Пусть эти декларации содержатся в пакете wired_logic, скомпилированном

в рабочую библиотеку work. Тогда узел передачи на общую линию сигналов
от нескольких независимых источников можно описать следующим образом
(листинг 3.37).
library ieee;
use work.pack_wired_or.all;
ENTITY open_drain is
PORT (data,selector:in bit_vector(7 DOWNTO 0 ) ;
single:IN bit;
output:OUT odw);
END open_drain;
ARCHITECTURE example OF open_drain IS

BEGIN
output<='0' WHEN single='0' ELSE '1';
multiple_assign: PROCESS(data,selector)
BEGIN FOR i IN 0 TO 7 LOOP
IF( data(i)='l' and selector(i)='l') THEN output<='0';
END IF;
END LOOP;
END PROCESS;
END example;
В программе (листинг 3.37) описана ситуация, когда к линии output под-

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

что драйверы одного сигнала, являющегося ее фактическим параметром, по
умолчанию трактуются как неограниченный массив, объединяющий состоя-
ния этих драйверов. После изменения состояния любого драйвера выполня-
ется просмотр всех элементов массива, причем число повторений задается
атрибутом s'range, определяющим границы фактического массива. Если
обнаружен драйвер, сохраняющий значение логического нуля, цикл пре-
кращается и сигналу присваивается нулевое значение.
К счастью, при проектировании чаще всего не требуется создание собствен-
ных разрешаемых подтипов данных. В современных системах интерпрета-
ции всегда присутствует пакет std_logic_H64, в котором, в частности, оп-
ределен подтип std_logic как разрешаемый подтип девятизначного пере-
числимого типа std_ulogic (см. разд. 3.2.3).
Приведем текст (листинг 3.38) определения подтипа std_logic [34].
TYPE s t d l o g i c _ t a b l e is a r r a y ( s t d _ u l o g i c , s t d _ u l o g i c ) of s t d _ u l o g i c ;
CONSTANT r e s o l u t i o n _ t a b l e : s t d l o g i c _ t a b l e := (
|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', '0'), — | 0 |
('U', 'X', 'X', '1', '1', '1', '!', '1'f '!') i — | 1 |
('U', 'X', '0', '1', 'Z', 'W, 'L', 'H', 'Z'), — | z |
('U', 'X', '0', '1', 'W, 'w, 'W, •w, 'W'), — | W
|
('U', '0', '1', 'L', 'w, 'W ,
1
'L1), — | L
('U',
'X',
'X', '0', '1',' H', 'W,
'L',
'W, 'H',
|
' H ' ) , -- | H
|
'w',
1
('U', 'X', '0', '1', 'Z , 'L', 'H', '- ' ) — | - |
FUNCTION r e s o l v e d ( s : s t d _ u l o g i c _ v e c t o r ) RETURN s t d _ u l o g i c IS
VARIABLE r e s u l t : s t d _ u l o g i c : = ' - ' ; — Значение по умолчанию -
— самый слабый сигнал
BEGIN
IF (s'LENGTH = 1) THEN RETURN s ( s 'LOW);
ELSE — просмотр всех драйверов
FOR i IN s 'RANGE LOOP
result := resolution_table(result, s ( i ) ) ;
END LOOP
RETURN r e s u l t ;
END IF;
END resolved;
SUBTYPE std_logic IS resolved std_ulogic;
Функция разрешения resolved устанавливает значение сигнала в соответст-

вии с "наиболее сильным" значением сигнала среди драйверов. Например,
активный нуль и активная единица определены как самые сильные и подав-
ляют любые другие сигналы, кроме друг друга. Если присутствуют два драй-
вера равной силы, но имеющие различные значения, результат считается
неопределенным.
Использование подтипа std_logic позволяет облегчить решение многих
проблем, возникающих при моделировании шинных соединений. Этот под-
тип и порождаемый на его основе тип std_logic_vector стали фактическим
стандартом. Данные этого типа нередко используют и в случаях, когда сиг-
налы имеют единственный драйвер и даже если при моделировании доста-
точно воспроизводить меньшее число состояний. Однако платой за такую
универсализацию может стать увеличение затрат машинного времени при
моделировании.
В листинге 3.39 приведено описание одного разряда матрицы статического
запоминающего устройства. Состояние ячеек памяти представлено массивом
переменных cell. Если i -я ячейка выбрана, т. е. сигнал разрешения en(i)
установлен в единицу (имеется в виду, что адрес представлен унитарным
кодом или код адреса подвергнут дешифрации в дополнительных узлах), а
усилитель записи отключен (wr='0')> то состояние ячейки передается на
разрядную линию данных dat_bus и далее на усилитель чтения. Если же
присутствует сигнал записи (wr='1'), то линия данных и выбранная ячейка
принимают значение входного сигнала. Проблема в том, что ячейка в зави-
симости от состояния линии данных является и приемником, и источником
сигнала, причем вход и выход — это одна и та же точка схемы.
Чтобы корректно описать эту ситуацию, следует приписать ячейкам "слабые"
состояния, а сигналу на линии данных — разрешаемый тип.
LIBRARY ieee;
USE IEEE.std_logic_l164.all;
ENTITY ram_array IS
GENERIC ( length:integer:= 64);
PORT( en:IN std_logic_vector(length -1 DOWNTO 0 ) ; — входы выборки
wr,rd: IN std_logic; — wr -запись, rd — чтение
data:INOUT std_logic
);
END ram_array;
ARCHITECTURE behave OF ranwarray IS
SIGNAL cell: STD_uLOGIC_VECTOR(LENGTH -1 DOWNTO 0 ) ;
SIGNAL data bus: std logic;
BEGIN
data_bus<='Z' WHEN (wr='0') ELSE — входной буфер
'1' WHEN (wr='l' and data='l') ELSE
'0' WHEN (wr='l' and data='0') ELSE
'X';
transmit: PROCESS( rd, data_bus) — выходной буфер
BEGIN
IF rd='l' THEN
CASE data_bus IS
WHEN 'l'|'H'=> data<= '1';
WHEN 'O'l'L'=> data<= '0';
WHEN OTHERS => data<= 'X';
END CASE;
ELSE data<='Z';
END IF;
END PROCESS;
cells:PROCESS (data_bus, en) — линейка запоминающих ячеек
BEGIN
FOR i IN О ТО length -1 LOOP
IF en(i)='l' THEN
CASE datajous IS
WHEN '1'|Н'=> cell(i)<= 'H';
WHEN '0'|'L1=> cell(i)<= 'L';
WHEN 'Z' => null;
WHEN others => cell(i)<= 'W1;
END CASE;
END IF;
END LOOP;
END PROCESS;
data_bus_drive: PROCESS (en,data) — поведение линии данных
— в режиме чтения
BEGIN
FOR i IN 0 ТО length -1 LOOP
IF (en(i) -'l') THEN
data_bus<=cell(i);
END IF;
END LOOP;
END PROCESS;
END behave;
В приведенной программе процесс cells отображает изменение состояния

выбранной ячейки в зависимости от состояния линии data_bus. Если к ли-
нии данных подключен активный источник, то ячейка переходит в состоя-
ние, соответствующее сигналу на линии, с той разницей, что состояние за-
поминается как слабый сигнал. Варианты оператора CASE, связанные с со -
стояниями 'L' и 'н', определяют подтверждение состояния ячейки, если

только одна эта ячейка подключена к линии данных. Если линия данных
находится в состоянии ' z', выбранная ячейка сохраняет свое состояние. Во
всех остальных случаях фактическое состояние ячейки в ближайшем буду-
щем непредсказуемо, что отражается символом слабого неопределенного
состояния 'w'. Процесс transmit описывает состояние линии входа/выхода
данных. Заметим, что тип порта входа/выхода определен как разрешаемый,
а значит, в иерархических проектах к этому порту можно подключать другие
драйверы.
Сигнал, представляющий линию данных data_bus, имеет драйвер, связан-
ный оператором условного присваивания, и набор драйверов по числу ячеек
памяти. Если wr='1', то активный сигнал драйвера оператора условного
присваивания подавляет слабые сигналы от подключенной ячейки. Если
wr='0', то этот драйвер принимает значение ' z', и оно подавляется слабыми
сигналами ячеек памяти при исполнении функции разрешения, если какие -
либо из них выбраны. В случае одновременной выборки нескольких ячеек,
находящихся в разных состояниях, data_bus принимает неопределенное сла-
бое значение 'W', что в свою очередь приводит к переходу выбранных ячеек
в состояние 'W'.
3.2.11. Структурное представление проекта

В предыдущих разделах рассмотрено несколько языковых понятий, служа-
щих структуризации описания проекта: понятия процесса, блока, подпро-
граммы.
Язык VHDL предоставляет еще одну возможность структуризации описа-
ния — так называемые структурные архитектурные тела (Structural Architec-
tural Body, SAB). Структурное архитектурное тело представляет проект в ви-
де набора используемых компонентов и их связей, т. е. приближает описа-
ние к реальной конфигурации проектируемого устройства, как минимум, к
представлению разработчика об этой конфигурации. Все используемые в
проекте компоненты должны иметь свое ENTITY и однозначно заданное по-
ведение, например поведенческое архитектурное тело, которое следует зара-
нее скомпилировать в библиотеку проекта или иную библиотеку, объявлен-
ную перед ENTITY составного проекта.
SAB представляется наиболее эффективным средством создания иерархиче-
ских проектов. Применение концепции SAB упрощает совместную работу
нескольких исполнителей над одним проектом. Упрощается включение в
новые проекты ранее созданных модулей, а также использование стандарт-
ных библиотек проектных модулей.
По форме структурные и поведенческие архитектурные тела не различаются.
Различие состоит в составе используемых операторов и деклараций.
В разделе объявлений SAB, кроме характерных для любых архитектурных

тел деклараций, таких как декларации типов, сигналов, констант, включа-
ются специфические подразделы: обязательный подраздел декларации про-
тотипов используемых компонентов и необязательный подраздел объявления
конфигураций. Раздел операторов SAB содержит операторы вхождения компо-
нентов, которые, собственно, и определяют порядок соединения компонен-
тов. Могут включаться и другие параллельные операторы, а если таких опе-
раторов относительно много, подобное архитектурное тело называют сме-
шанным, или структурно -поведенческим.
Каждому модулю, используемому в качестве структурного компонента
в SAB, должно сопутствовать объявление прототипа. Синтаксис декларации
прототипа компонента имеет вид:
COMPONENT <имя ENTITY компонента> is
[ <образ настройки> ]
<образ порта>
END COMPONENT [ <имя ENTITY компонента>];
Здесь <образ настройки> и <образ порта> — прямая копия высказываний

GENERIC и PORT из текста объявления ENTITY соответствующего компонента.
Если в устройстве есть несколько одинаковых модулей, то прототип декла-
рируется только один раз. Например, если в проект входит несколько одно-
типных регистров, представленных в библиотеке одним и тем же ENTITY, то
в структурном теле размещается единственная декларация прототипа реги-
стра, даже если конкретные экземпляры имеют различные параметры. Тем
не менее каждому экземпляру, включаемому в проект, называемому также
вхождением модуля (INSTANCE), при структурном описании присваивается
собственное имя. Это собственное имя предъявляется в разделе операторов
архитектурного тела в виде метки оператора вхождения компонента.
В подразделе объявления сигналов обязательно объявление всех соединений
между блоками. Каждый сигнал относят к типу, определенному в разделе
PORT соответствующего модуля.
Иногда в соединяемых модулях однотипные, в сущности, сигналы портов

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

(Component Instantiation Statement), которые определяют порядок соедине-
ния включаемых в проект модулей и, возможно, их параметры.
<оператор вхождения компонента> : : =
<метка вхождения> : ([ COMPONENT ] <имя компонента>)
GENERIC MAP (<Список соответствий параметров настройки>)
PORT MAP (<список соответствий порта>);
<список соответствий :: =
([ «Формальный параметр>] =><фактический параметр>
«,[ «Формальный параметр> ] => фактический параметр>»)
По форме списки соответствий настроек и порта совпадают со списком со-

ответствий вызова подпрограмм. Но для параметров настройки фактическим
параметром может быть только константное выражение, а для порта —
только имя сигнала либо имя порта "главного" модуля. Нельзя объявлять
в качестве фактического параметра в списке соответствий порта имя входа
или выхода другого компонента. Все связи осуществляются только через
объекты, объявленные в текущем архитектурном теле как сигналы. (В прин-
ципе, объявление сигналов может осуществляться в общедоступном модуле
PACKAGE.)
Подобно вызову подпрограмм возможны полная и сокращенная формы
записи списка соответствий. В сокращенной записи (без формальных пара-
метров) все элементы списков соответствий записываются в том же порядке,
как в списках параметров и сигналов порта данного компонента. Если ис-
пользуется полная форма списка соответствий, то порядок записи элементов
в списке произволен.
Рассмотрим для примера структурное описание устройства, изображенного
на рис. 3.19. Предположим, что ENTITY и архитектурные тела модулей У, W
и Z скомпилированы в рабочую библиотеку проекта. Каждому вхождению
компонента в проект присвоено собственное имя. Например, компонент U1
структурной схемы реализован как модуль типа V, т. е. модуль V является
его прототипом.
Не вдаваясь в детали описания функционирования этих компонентов, опре-
делим, что узел U1 принимает байты данных по линии А, в зависимости от
управляющих сигналов преобразует их и выдает результат на четырехбайт -
ный выход. Модуль W выполняет некоторые преобразования входного слова
данных. В конкретной структуре компонент U2 принимает старший байт
данных от компонента U1 и преобразует его. Этот байт замещает старший
байт выходных данных компонента U1, и сформированный таким образом
код поступает на вход компонента U3, выход которого является выходом
устройства.
В архитектурном теле программы описания этого устройства, представлен-
ном в листинге 3.40, после объявления прототипов компонентов определены
Глава 3, Языки описания дискретных устройств 407
сигналы: каждой линии связи сопоставляется сигнал с собственным именем.

Для большей наглядности на рисунке и в тексте программы порты модулей
обозначены строчными буквами, а сигналы — прописными, хотя формально
это не имеет значения. Строчные и прописные буквы в обозначениях имен
равнозначны, а имена портов компонентов и имена сигналов независимы и,
в частности, могут совпадать.
CONT INPUT
Рис. 3.19. Структурное представление проекта
Каждый компонент в архитектурном теле представлен своим оператором

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

представленные группой А(31 DOWNTO 0), переименованы оператором с мет-
кой rename и подвергнуты преобразованию в целый тип для согласования
с типом данных, определенным для входного порта модуля W.
Обратим внимание на форму записи списков соответствия. Для компонен-
тов U1 и U2, прототипами которых являются модули V И W соответственно,
используется сокращенная форма записи списков соответствия портов, при-
чем для компонента U2 опущен список соответствия параметров, что озна-
чает, что принято значение по умолчанию — в данном случае width := 8.
Оператор вхождения для компонента Z показывает полные формы списков
соответствия. Ключевое слово OPEN в качестве формального параметра озна-
чает неиспользуемый порт. Для входного порта это соответствует использо-
ванию постоянного значения сигнала, определенного по умолчанию.
ENTITY structure_example IS
PORT ( input: IN std_logic (7 DOWNTO 0 ) ;
controle: IN std_logic (3 DOWNTO 0) ;
s: OUT std_logic);
END structure_example;
ARCHITECTURE structure OF primer IS
COMPONENT V
PORT( A:IN std_logic_vector (7 DOWNTO 0 ) ;
CONTROLE:IN std_logic_vector (3 DOWNTO 0 ) ;
B: OUT std_logic_vector (31 DOWNTO 0 ) ;
C:OUT std_logic);
END COMPONENT;
COMPONENT W
GENERIC (width:integer:=8);
PORT( A:IN integer RANGE 2**width -l DOWNTO 0;
B: OUT integer RANGE 2**width -l DOWNTO 0 ) ;
END COMPONENT;
COMPONENT Z
GENERIC (width:integer:=16);
PORT( A: IN std_logic_vector (width -1 DOWNTO 0)
C:in std_logic;
B,D: OUT std_logic);
END COMPONENT;
SIGNAL c, e: std_logic_vector (7 DOWNTO 0);

SIGNAL cI, eI -.integer RANGE 0 TO 255;—цифровые эквиваленты сигналов С и Е
SIGNAL a, f: std_logic_vector(32 DOWNTO 0 ) ;
SIGNAL d: std_logic;
BEGIN
Ul: v
PORT MAP (input, controle, a,d);
U2:W
PORT MAP (cI,eI);
U3:z
GENERIC MAP(width=>32)
PORT MAP(A=>f,C=>d, B=>S,D=>OPEN);
— согласование типов данных
rename: c<= a(31 DOWNTO 24);
cI<= cony_integer ( c ) ;
e<= conv_std_logic_vector ( eI, 8);
f<=e & a(23 DOWNTO 0};
END structure;
Оператор вхождения можно трактовать как вызов процедуры со специаль-

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

компонентов
Очень часто устройства проектируются не только как изделия с наперед за-
данными свойствами, но и для возможности их использования в различных
приложениях, требующих однотипных преобразований. Соответственно,
текстовое описание желательно создавать в формах, допускающих модифи-
кацию в определенных пределах свойств представляемых объектов проекти-
рования. Есть два основных пути создания программ, описывающих мно-
жество модулей с идентичными функциями, иначе — перестраиваемых мо-
дулей:
- использование параметров настройки (GENERIC);
- разработка нескольких архитектурных тел, подчиненных общему ENTITY,
иными словами, имеющих одинаковую алгоритмическую сущность при
различии способа описания или способа реализации.
Модуль, содержащий декларацию параметров настройки (GENERIC), называ-
ют параметризованным. Фактическое значение задается в списке соответст-
вий оператора вхождения.
Параметры, определяющие количественные свойства реализаций (например,

разрядность данных, время задержки), используются в выражениях внутри
подчиненных архитектурных тел как обычные константы. Но, кроме того,
часто применяются параметры структурного характера, уточняющие функ-
ции, реализуемые конкретными вхождениями параметризованного модуля
и/или его структуру. Чаще всего такие параметры используются в операто-
рах генерации, синтаксис которых определен как:
<оператор генерации> : : =
<метка оператора генерации>: <схема генерации> GENERATE
<параллельный оператор> «<параллельный оператор>»
END GENERATE [ <метка оператора генерации>];
<схема гвнерации> : : =
IF <булевское выражение> | FOR <имя> IN <диапазон>
Схема генерации с ключевым словом IF разрешает (или блокирует) создание

компонентов, представленных вложенными параллельными операторами.
Схема с ключевым словом FOR определяет число компонентов, создаваемых
в структуре модуля в зависимости от значения параметра настройки.
Программа (листинг 3.41) представляет регистр с синхронной загрузкой па-
раллельного кода, который, в зависимости от параметров настройки, может
интерпретироваться как сдвигающий регистр со сдвигом в сторону старших
разрядов (right), со сдвигом в сторону младших (left), или реверсивный ре-
гистр сдвига (bidir). Каждая версия представлена в программе своим опера-
тором PROCESS. Операторы I F -GENERATE, в зависимости от значения пара-
метра настройки dir, который может задаваться при включении модуля в
другие проекты, определяют конфигурацию, используемую в конкретном
проекте. В данном случае может быть выбрана одна из трех возможных вер-
сий. Оператор проверки прекращает компиляцию и выдает сообщение об
ошибке, если при включении задано недопустимое значение параметра на-
стройки.
LIBRARY ieee;
USE IEEE.std_logic_1164.all;
ENTITY shIFt_register IS
GENERIC( num_bits: integer:=8; — число разрядов
dir:string:="right"); — тип регистра — "left" — со сдвигом влево
"right" — со сдвигом вправо
"bidir" — реверсивный
PORT (clk:IN std_logic;
oper:IN std_logic_vector (1 DOWNTO 0 ) ;
— 00 — пустая операция
— 10 — левый сдвиг для типа "bidir" и сдвиг для других типов
— 01 — правый сдвиг для типа "bidir" и сдвиг для других типов

— 11 — загрузка кода
dl, dr:IN std_logic;
input:IN std_logic_vector (num_bits -l DOWNTO 0 ) ;
output:OUT std_logic_vector (num_bits -l DOWNTO О)
);
end shift_register;
ARCHITECTURE behave OF shift_register IS
BEGIN
ASSERT (dir="left" or dir="right" or dir= "bidir") REPORT
"mode must be 'left1, 'right1 or 'bidir' "
SEVERITY error;
LEFTSHIFT: IF dir="left" GENERATE
PROCESS(clk)
VARIABLE "state:std_logic_vector(num_bits -l DOWNTO 0 ) ;
BEGIN
IF (clk='l'and clk'event) THEN
IF (oper="ll") THEN state:=input;
ELSIF (oper="10" or oper="01") THEN
FOR i IN num_bits -l DOWNTO 1 LOOP
state(i):=state(i -1) ;
END LOOP;
state(0):=dl;
END IF; --oper
END IF; —clk='l'
output<= state;
END PROCESS;
END GENERATE LEFTSHIFT;
RIGHTSHIFT: IF dir="right" GENERATE
PROCESS(clk)
VARIABLE state:std_logic_vector(num_bits -l DOWNTO 0 ) ;
BEGIN
IF (clk='l'and clk'event) THEN
ELSIF (oper="01" or oper="10") THEN
FOR i IN 0 TO num_bits -2 LOOP
state(i):=state(i+l);
END LOOP;
state(NUM_BITS -1):=dR;
END IF; —oper
END IF; —clk='l'
output<= state;
END PROCESS;
END GENERATE RIGHTSHIFT;
bidir: IF dir="bidir" GENERATE

PROCESS(clk)
VARIABLE state:std_logic_vector(num_bits -l DOWNTO 0 ) ;
BEGIN
IF (clk='1'and clk'event) THEN
ELSIF (oper="01") THEN
FOR i IN 0 TO num_bits -2 LOOP
state(i):=state(i+1);
END LOOP;
state(NUM_BITS -1):=dR;
ELSIF (oper="10") THEN
FOR i IN num_bits -l DOWNTO 1 LOOP
stated) :=state(i -l) ;
END LOOP;
state(0):=dl;
END IF; — oper
END IF; — clk='1'
output<= state;
END PROCESS;
END GENERATE bidir;
END behave;
В случаях, когда вариативность компонента достигается разработкой не-

скольких архитектурных тел, т. е. первичному проектному модулю (ENTITY)
этого компонента в библиотеке проекта соответствует несколько различных
архитектурных тел, проектный модуль высшего уровня иерархии должен
содержать объявление конфигурации компонента. Объявление конфигура-
ции определяет, какое именно архитектурное тело компонента используется
в текущем проекте или сеансе отладки. Объявление конфигурации компо-
нента подчиняется следующему синтаксическому правилу:
<конфигурация компонента> ::=
FOR <спецификация компонента> <индикатор привязки>;
<индикатор привяэки> ::=
ENTITY <имя Entity>( <имя архитектурного тела>)
<спецификация компонента> ::= <список вхождений> : <имя компонента>
<список вхождений> ::=
<метка вхождения> «, <метка вхождения> » I OTHERS I ALL
Пусть, например, в библиотеку проекта скомпилирован текст программы,
приведенной ранее в листинге 3.1, т. е. проекту высшего уровня иерархии
доступны его ENTITY и несколько архитектурных тел. Создадим проект,
включающий три таких компонента, каждый из которых анализирует шест-
надцать разрядов входного кода, а также блок суммирования результатов,
Глава 3. Языки описания дискретных устройств _ 4 13
получаемых в каждом из компонентов. Предположим, что по некоторым

соображениям оказалось целесообразным один из компонентов представить
"чистым поведением", а два других — на уровне логических макроячеек.
Тогда архитектурное тело такого проекта может иметь следующий вид
(листинг 3.42):
ENTITY bit_count_usage IS
Port (real_input:IN std_logic_vector ( 47 DOWNTO 0} ;
Real output: OUT inreger RANGE 0 TO 48);
END bit_count_usage;
ARCHITECTURE selected_architectures OF bit_count_usage IS
COMPONENT bit_count
PORT ( input : IN std_logic_vector (15 DOWNTO Ob -
output: OUT integer RANGE 0 TO 15);
END COMPONENT;
FOR ml: bit_count USE ENTITY work.bit_count (pure_behave) ;
FOR others: bit_count USE ENTITY work.bit_count (comb_logic) ;
SIGNAL first, second, third: integer RANGE 0 TO 15;
BEGIN
ml : bit_count
PORT MAP( input => real_input (15 DOWNTO 0) ,output=>first) ;
m2 : bit_count
PORT MAP( input => real_input (31 DOWNTO 16), output=> second);
m3 : bit_count
PORT MAP( input => real_input (47 DOWNTO 32),output=> third);
real_output<=first+second+ third;
END selected_architectures ;
В данном примере объявление конфигураций компонентов следует тракто-

вать таким образом.
Для представления компонента ml в проекте используется первичный про-
ектный модуль ENTITY bit_count, реализованный в соответствии с подчи-
ненным ему архитектурным телом pure_behave. Остальные компоненты
bit_count реализуются в соответствии с архитектурным телом comb_logic.
Кроме записи конфигурации непосредственно в архитектурном теле, ссы-
лающемся на конфигурируемый модуль, язык VHLD предусматривает воз-
можность записи конфигураций в отдельно выделенном первичном проект-
ном модуле, который называется декларацией конфигурации (Configuration
Declaration). Иерархический уровень декларации конфигурации такой же,
как у декларации ENTITY и декларации пакетов, и декларация конфигурации
не может быть их составной частью. Конфигурации компонентов, содержа-
щиеся в модуле декларации конфигурации, во -первых, доступны для раз -
личных архитектурных тел, а во -вторых, обеспечивают возможность сквоз-

ного конфигурирования иерархических структур. BNF -форма декларации
конфигурации имеет вид:
<декларации конфигураций :: =
CONFIGURATION <имя конфигураций OF <имя ENTITY> IS
FOR <имя архитектурного тела>
«<конфигурация компонента> END FOR »
END FOR:
END [ CONFIGURATION ] [ <имя конфигураций ];
Пусть, например, конфигурации компонентов исключены из архитектурного

тела selected architectures, и для их объявления создан проектный модуль
следующего содержания:
CONFIGURATION ttt OF bit_count_usage IS
FOR selected architectures
FOR ml: bit_count USE ENTITY work.bit_count(pure_behave);
END FOR;
FOR OTHERS: bit_count USE ENTITY work.bit_count(comb_logic);
END FOR;
END FOR;
END CONFIGURATION;
Тогда оператор включения модуля bit_count_usage в иерархический проект

может выглядеть следующим образом:
<метка вхождения>: COMPONENT work.ttt
PORT(input=> <аргумент>, output=> <приемник результата>);
Запись соответствует синтаксису VHDL'93. В VHDL'87 после метки указы-

вается только имя ENTITY. Конфигурация (если объявленному ENTITY таковая
сопоставлена) подключается по умолчанию.
В общем случае декларация конфигурации может также содержать объявле-
ния параметров и даже объявления соответствий портов.
3.2.13. Пакеты в VHDL

Концепция видимости описаний
Мы уже неоднократно обращались к понятию пакета (PACKAGE) в VHDL.
Пакет — это программный модуль, содержащий описание объектов, доступ-
ных нескольким другим программным модулям. В пакете могут быть объяв-
лены глобальные типы, константы, функции, сигналы и т. п. Фактически,
общие для нескольких подпроектов типы и сигналы можно объявить только
в пакете.
Рассмотрим более формально правила записи пакетов.
Пакет представляется двумя структурными единицами — обязательным пер-

вичным модулем "декларация пакета" (PACKAGE DECLARATION) и необязатель-
ным вторичным модулем "тело пакета" (PACKAGE BODY).
<двкпарация пакета> ::=
PACKAGE <имя пакета> IS
<раздел деклараций пакета>
END [ PACKAGE ] [ <имя пакета> ];
Раздел деклараций пакета может содержать спецификации подпрограмм,

декларации типов и подтипов, констант, сигналов, атрибутов, компонентов
и ряда других объектов.
Тело пакета содержит конкретизацию способов вычисления функций и за-
писывается в соответствии со следующим синтаксическим правилом:
<package_body> :: -
PACKAGE BODY <имя пакета> IS
<раздел деклараций пакета>
END [ PACKAGE BODY ] [ <имя пакета> ];
Раздел деклараций тела пакета содержит тела подпрограмм (спецификация

этих подпрограмм обязательно присутствует в разделе деклараций пакета),
а также дополнительные декларации объектов, используемых в представ-
ленных подпрограммах. Могут декларироваться типы, константы, вложен-
ные подпрограммы, объекты некоторых иных классов. Эти объекты недос-
тупны для других проектных модулей.
В качестве примера в листинге 3.43 приведен текст программы, содержащий
декларацию и тело пакета std_logic_utii, имеющегося в числе пакетов, со-
провождающих систему отладки VHDL программ ModelSim. Декларация
пакета содержит объявление функций, включенных в тело пакета, в данном
случае, функций преобразования типов данных из std_logic_vector в поло-
жительное целое и наоборот.
library IEEE;
use IEEE.std_logic_1164.all;
package std_logic_util is
function CONV_STD_LOGIC_VECTOR(ARG: INTEGER; SIZE: INTEGER)
return STD_LOGIC_VECTOR;
function CONV_INTEGER(ARG: STD_LOGIC_VECTOR) return INTEGER;
end std_logic_util;
package body std_logic_util is

type tbl_type is array (STD_ULOGIC) of STD_ULOGIC;
c o n s t a n t tbl_BINARY : t b l _ t y p e : =
('0', '0', '0', ' 1 ' , '0', '0', '0', '1', '0');
function CONV_STD_LOGIC_VECTOR(ARG: INTEGER; SIZE: INTEGER)

return STD_LOGIC_VECTOR is
VARIABLE result: STD_LOGIC_VECTOR(SIZE -1 DOWNTO 0 ) ;
VARIABLE temp: integer;
BEGIN
temp := ARG;
for i in 0 to SIZE -1 loop
IF (temp mod 2) = 1 THENresult(i) := '11;
else result(i) := '0';
end IF;
IF temp> 0 THEN temp := temp / 2;
else temp := (temp — 1) / 2; — simulate ASR
end IF;
end loop;
return result;
end;
function CONV_INTEGER(ARG: STD_LOGIC_VECTOR) return INTEGER is

VARIABLE result: INTEGER;
BEGIN
assert ARG'length <= 32
report "ARG is too large in CONV_INTEGER"
severity FAILURE;
result := 0;
for i in ARG'range loop
IF i /= ARG'left THEN
result := result * 2;
IF tbl_BINARY(ARG(i)) = '1' THEN
result := result + 1;
end IF;
end IF;
end loop;
return result;
end;
end std_logic_util;
Любая декларация, содержащаяся в заголовке пакета, доступна любому про-

ектному модулю, или, как говорят, становится видимой из этого модуля,
если пакет предварительно скомпилирован в одну из библиотек системы
проектирования, например рабочую библиотеку проекта work, а модуль со-
держит высказывание использования этого пакета (Use Clause). Декларация
использования пакета, приведенного в листинге 3.43, может выглядеть сле-

USE work. Std_logic_util.all;
Концепция видимости объектов в VHDL

Рассмотрим в более широком аспекте принципы, заложенные в концепцию
видимости языка.
Разделы деклараций могут присутствовать в различных программных блоках:
- в заголовке пакета;
- в теле пакета;
- в ENTITY;
- в архитектурном теле;
- в блоке или процессе;
- в теле подпрограммы.
Всякий проектный модуль может использовать объекты, объявленные в мо-
дулях высшей по отношению к этому модулю иерархии, используя их име-
на, если объект с тем же самым идентификатором не объявлен в этом моду-
ле. Недопустимы ссылки "вниз" или на другие ветви иерархии.
Эти концепции иллюстрируются примером диаграммы видимости объявле-
ний (рис. 3.20). Диаграмма представляет гипотетический проект с интерфей-
сом, заданным ENTITY main, которому подчинены два архитектурных тела
f i r s t и second. Рассмотрим подробнее архитектурное тело first. В разделе
операторов этого тела присутствуют два независимых блока BLOCK1 и BLOCK2,
причем в BLOCK1 вложен еще один программный модуль BLOCK3. Соотноше-
ния видимости не изменятся, если на месте операторов блоков BLOCK1 и
BLOCK2 записать операторы процесса.
Операторы в составе BLOCK1 могут использовать объекты, определенные в
разделах описаний этого блока, равно как в иерархически старших по от-
ношению к нему программных конструкциях: разделе описаний и парамет-
ров настройки ENTITY main. Операторам блока BLOCK3 доступны не только
эти объекты, но и объекты, дополнительно определенные в разделе описа-
ний BLOCK3. Однако описания, локализованные в блоке BLOCK2, не доступны
остальным операторам блока BLOCK1 и, соответственно, не разрешается об-
ратная ссылка. Некоторые запрещенные варианты использования объявлен-
ных объектов отображены на рисунке стрелками, помеченными крестиками.
Декларации, содержащиеся в ENTITY, видимы для операторов всех подчи-
ненных ему архитектурных тел независимо от уровня вложения. Объявления
"внутри" архитектурного тела невидимы для других архитектурных тел, в том
Рис. 3.20. Пример диаграммы видимости деклараций

в совокупности программных модулей
числе относящихся к одному ENTITY. Декларации имен портов и параметров

настройки, содержащиеся в ENTITY некоторого проекта, могут быть сделаны
доступными для архитектурных тел, относящихся к ENTITY другого проекта,
через объявление прототипа в подразделе декларации компонентов (пример
допустимой ссылки отображен на рисунке штрихпунктирной линией).
Декларации, содержащиеся в пакете, доступны любому программному мо-
дулю, если его текст содержит высказывание использования этого пакета
(Use Clause). В любом модуле, имеющемся в программе, содержащей такое
высказывание, допустимо использовать объекты, объявления которых имеют-
ся в декларации пакета. В том числе, становятся доступны подпрограммы,
содержащиеся в теле этого пакета. Такой принцип назовем обусловленной
видимостью, а соответствующие ссылки на диаграмме видимости отражены
штриховыми линиями. Операторы в телах подпрограмм могут использовать
объекты, представленные разделе деклараций тела пакета, в декларации па-
кета, а также локальные объекты, объявленные в теле этой же подпрограммы.
3.3. Элементы языка Verilog HDL

3.3.1. Предварительные замечания
Язык Verilog HDL, сокращенно Verilog, был разработан фирмой Gateway
Design Automaton как язык моделирования, ориентированный на внутреннее
использование. Фирма Cadence приобрела Gateway в 1989 году и открыла
Verilog для общественного пользования. В 1995 году был определен стандарт
языка — Verilog LRM (Language Reference Manual), IEEE1364 -1995 [55].
Несмотря на то, что VHDL был создан ранее и, в принципе, предоставляет
более широкие возможности, Verilog HDL стал достаточно популярен среди
разработчиков систем, и компиляторы с этого языка, наряду с VHDL -
компиляторами, включены в подавляющее большинство САПР интеграль-
ных схем [51, 54]. Привлекательными свойствами языка Verilog можно счи-
тать близость к синтаксису и семантике языка С, меньшее по сравнению с
VHDL число служебных слов, что упрощает его изучение. Кроме того, из -за
своих расширенных возможностей VHDL проигрывает Verilog по эффектив-
ности, т. е. на описание одной и той же конструкции в Verilog потребуется в
3—4 раза меньше символов ASCII, чем в VHDL [13]. Вопрос, какое пред-
ставление порождает лучшее техническое решение при реализации в аппа-
ратуре средствами типовых САПР, остается дискуссионным. Далее часто
будет приводиться сравнение конструкций языков Verilog и VHDL, предпо-
лагая, что читатель хотя бы кратко ознакомился с содержанием предыду-
щего раздела. Читателям, которые хотят изучить только Verilog, все же сле-
дует ознакомиться хотя бы с разд. 3.2.1 и 3.2.4.
Базовой единицей языка Verilog является проектный модуль, или просто

модуль, интегрирующий, в отличие от соответствующих конструкций VHDL,
как определение интерфейса, так и правил функционирования представляе-
мого устройства или блока. Элементами проектного модуля являются декла-
рации и операторы. Концепции языка позволяют описывать устройства с
использованием различных уровней абстракции, в том числе в форме
"чистого поведения", представления регистровых передач и вентильного
уровня представления. Модуль может содержать операторы включения
других модулей, что позволяет создавать иерархические проекты. Обеспечи-
вается поддержка процессов как нисходящего, так и восходящего проекти-
рования.
Поведенческое представление дискретных устройств задается в форме ариф-
метических и логических преобразований над исходными и промежуточны-
ми данными. Состав и обозначения разрешенных операций соответствует
составу операций языка С и его обозначениям. Обеспечивается возможность
представления взаимодействующих подсистем, для чего в языке определены
как параллельные, так и последовательные операторы и процедуры. Парал-
лельные операторы отображают поведение цепей без памяти, а при модели-
ровании исполняются при изменении любого операнда в правой части опе-
ратора. Порядок записи параллельных операторов не имеет значения.
Последовательные операторы заключаются в выделенные программные бло-
ки и при моделировании выполняются последовательно друг за другом в
порядке записи. Результаты преобразований доступны для других блоков
программы только после выполнения всех вложенных в блок операторов.
Для каждого такого блока могут быть явно определены функции блокировки
или инициализации предписанных преобразований со стороны других бло-
ков (сравните с понятием PROCESS языка VHDL). В число последовательных
операторов, в частности, входят последовательные операторы присваивания,
условный оператор I F , оператор выбора CASE, операторы повторения LOOP.
Вводятся конструкции, которые представляют действия, исполняемые в те-
чение некоторого ненулевого временного интервала.
Структурное представление проектов обеспечивается возможностью встраи-
вания в проект других модулей, причем используются традиционные для
алгоритмических языков конструкции, аналогичные вызову соответст-
вующих подпрограмм. Кроме того, в языке предопределен широкий набор
логических примитивов, примитивов для представления двунаправленных
цепей передачи и резистивных цепей.
В данной книге примитивы для представления двунаправленных цепей пере-
дачи и резистивных цепей не рассматриваются, т. к. эти конструкции очень
редко используются при проектировании ПЛИС.
Упрощенно структура текстового файла в Verilog определяется следующим

образом:
<исходный текст> ::=
« <Директива компилятора> »
<описание> «<описание>»
<описание> ::= <описание модуля> | <описание примитива>
<описанив модуля> ::=
module <имя модуля> [ (<порт> «,<порт>») ];
« <Декларация> | <параллельный оператор>»
endmodule
| macromodule [ (<порт> «,<порт>») ];
«<Декларация> | <параллельный оператор>»
endmodule
<порт> ::=
<объявление соответствия порта>
| . <имя порта> ([ <объявление соответствия порта> ])
<декларация> ::=
<декларация параметров>
| <спецификация портов>
| <декларация сигналов>
| <декларация времени>
| <декларация численных переменных>
| <декларация событий>
| <декларация логических ячеек>
<параллельные операторы> : ==
<параллельное присваивание>
| <оператор вхождения модуля>
| <оператор блока>
| <оператор инициализации>
| <оператор постоянного повторения>
| <вызов подпрограмм>
Из приведенных правил синтаксиса следует, что текст программы может

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

блюдаемыми, т. к. их определение войдет в другие выражения. Использова-
ние концепции макромодуля обеспечивает уменьшение времени моделиро-
вания.
В теле модуля параллельные операторы и декларации размещаются в произ-
вольном порядке, хотя любой объект декларируется раньше его использова-
ния в операторах. Правила декларирования будут определены позднее. Сей-
час отметим, что имена портов сначала объявляются в списке портов, затем
вводится их спецификация, т. е. определяется направление — вход, выход
или двунаправленная линия, а потом декларируется тип. Спецификация
порта определяется следующими правилами:
<спвцифюсация порта> :: -
<направление> [ <диапазон индексов> ] <имя> «,<имя> »;
<направление> ::=
input | output | inout
В необязательном разделе <директивы компилятора> могут быть заданы неко-
торые параметры процедур компиляции и моделирования.
Наиболее употребительные директивы компилятора это 'timescaie, 'define,
'include, 'ifdef, 'else, 'endif.
Директива 'timescale определяет два параметра для управления процессом
моделирования. Первый задает масштаб времени, т. е. физический времен-
ной интервал, соответствующий единице модельного времени в выражени-
ях, задающих время останова и задержки (временные интервалы в програм-
мах задаются целым числом). Второй параметр задает точность представле-
ния временных интервалов при преобразовании в модели данных этого
типа, например, при округлениях.
Так, директива
'timescaie 1 ns/10 ps
определяет, что абстрактная единица в выражениях, задающих время, экви-
валентна 1 наносекунде, а разрешение программы моделирования 10 пико -
секунд. Впрочем, именно такое объявление не имеет смысла, т. к эти значе-
ния принимаются по умолчанию.
Директива 'define задает имена константам в программном модуле (не пу-
тайте с параметрами). После такого объявления имя может использоваться
в выражениях, но ему должен предшествовать апостроф. Например, если
записана директива
'define gate_delay=5 // определение константы "задержка вентиля",
то в модуле допустимо выражение
у= # 'gate_delay а & Ь // использование константы для задания
// задержки схемы И
Отметим, что комментарии в Verilog выделяются так же, как в С:

- подстрока текста или целая строка, начинающаяся с двух знаков дроби
до конца строки, является комментарием;
- любой фрагмент текста, начинающийся с пары знаков /* и заканчиваю-
щийся парой знаков */, является комментарием.
Директива 'include позволяет включить в создаваемый файл текст из дру-
гого файла. Директивы условной компиляции 'ifdef, 'else, 'endif подобны
аналогичным директивам С -компиляторов и используются, например, для
выбора имен и констант в зависимости от параметров, определенных в про-
ектах высшего уровня иерархии.
3.3.2. Типы данных

Основная форма представления информации, с которой оперирует
Verilog HDL, — это сигнальные данные, отображающие состояние компо-
нентов и цепей в описываемом устройстве. Кроме того, используются слу-
жебные данные, служащие для задания конфигурации, управления модели-
рованием и компиляцией, а также отображения результатов в процессе мо-
делирования. К служебным типам данных относятся время, действительные
и целые числа, строки. Правда, числовые значения в некоторых случаях
могут сопоставляться сигналам.
Язык Verilog не предоставляет возможности объявления пользователем соб-
ственных типов данных.
Цепи и регистры
Сигналы в Verilog HDL представляются в четырехзначном алфавите {0, 1, X, Z}.
Однако для декларации линий связи, к которым подключаются источники,
характеризующиеся специфическими электрическими параметрами, напри-
мер проходные ключи, схемы с открытым коллектором и т. п., драйверам
сигнала могут быть приписаны дополнительные атрибуты — уровни силы
(Strength Level) — которые доопределяют способ вычисления истинного
значения сигнала на линии.
Введено две группы типов данных для представления сигналов: цепи (nets)
и регистры (registers). Каждой группе соответствуют специфические спо-
собы сохранения присвоенных значений и, в конечном счете, различные
схемные решения для их реализации в аппаратуре.
Цепи представляют физические связи между структурными компонентами
устройства. Сама по себе цепь не сохраняет состояние — она должна управ-
ляться драйвером, который соответствует оператору параллельного присваи-
вания, причем имя драйвера совпадает с именем цепи. Это, собственно, и от-
ражается в принятом в языке Verilog названии операторов этого типа —
"continuous", т. е. непрерывные, постоянно воздействующие на цепь.
Регистр — это обобщенное понятие, отражающее элементы, способные сохра-

нять состояние. Программная модель предусматривает сохранение состояния
от каждого присвоения до следующего. Иными словами, оператор присваива-
ния значения регистру действует как сигнал установки нового значения.
В Verilog определен широкий набор конструкций для задания условий из-
менения состояний регистров и представления различных способов управ-
ления триггерными устройствами.
Синтаксис основных деклараций переменных задается следующими прави-
лами:
<двкларация цепи> ::=
<тип цепи> [ signed [<право доступа>] <диапазон>] [<задержка>]
<список переменных>;
| <тип цепи> [ signed ] [ <сила драйвера> ]
[ [<право доступа>] <диапазон>] [ <задержка> ]
<список присвоений>;
<декларация регистра> : : =
neg [signed ] [ [<право доступа> ] <диапазон> ]
<список переменных>;
<список пврвменных> ::=
<имя переменной> «,<имя переменной>»
<право доступа> :: =
scalared | vectored
<диапазон> :=
[<константное выражение> : <константное выражение>]
<сила драйвера> ::=
(<Уровень силы 0>, <Уровень силы 1>)
Тип цепи может задаваться из следующего множества значений:

<тип цепи> : : =
wire | wand | wor | supply0 | supplyl | t r i . | triO.I t r i l I
triand.| t r i o r . | trireg
Замечание
В языке Verilog, в отличие от VHDL, не различаются понятия сигнала и пере-
менной — все данные, которые могут изменяться, называют переменными
(variables). Специфика выполнения операций назначения и сохранения со-
стояния переменных определяется их типом (net или r e g i s t e r ) , а в некото-
рых случаях способом записи оператора присваивания.
Типы цепей wire и t r i с точки зрения программной интерпретации эквива-

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

венному источнику, а тип tr1 — для представления связей, управляемых
несколькими источниками (драйверами).
Прочие типы цепей используются для представления различных вариантов
монтажной и коммутационной логики, которые не характерны для ПЛИС, и
в данной книге не рассматриваются.
Если в декларации отсутствует объявление диапазона, то соответствующее
имя присваивается скалярной переменной, представляющей состояние од -
новыходного логического элемента или одной линии соединений. В про-
тивном случае предполагается объявление битового вектора, т. е. кода, число
разрядов которого и порядок их нумерации задается конструкцией
<диапазон>. Право доступа определяет, возможен ли доступ к отдельным
компонентам вектора, т. е. можно ли присваивать значения отдельным раз-
рядам кода и использовать эти значения в других выражениях. Если перед
указанием диапазона записано ключевое слово vectored, то доступ к отдель-
ным компонентам вектора не допускается. Если присутствует ключевое сло-
во scalared (а также по умолчанию), каждый компонент кода может уста-
навливаться и анализироваться индивидуально. Ключевое слово signed мо-
жет сопровождать декларацию векторов и задавать правила преобразования
битовых векторов в арифметических операциях. При его отсутствии пред-
ставляемый вектор рассматривается как двоичное представление беззнако-
вого целого (старший разряд значащий). Если слово signed присутствует,
вектор рассматривается как представление целого в дополнительном двоич-
ном коде (старший разряд знаковый).
Задержка определяет интервал модельного времени, после которого резуль-
тат операции присваивания этой переменной фактически изменяет ее зна-
чение. Могут задаваться несколько значений задержки, проявляющихся
в различных условиях (см. разд. 3.3.5). Объявление переменной может со-
держать присвоение значения, причем в такой конструкции присвоение
может содержать не только константные выражения, но и выражения,
включающие другие переменные. Иными словами, декларация переменной
может фактически совмещать функции объявления переменной и оператора
присваивания.
Конструкция <сила драйвера> присутствует только в тех случаях, когда дек-
ларация переменной содержит присвоение, и если в тексте программы име-
ется несколько операторов присваивания значения этой переменной. Уро-
вень силы задает условия взаимного подавления сигналов от нескольких
источников, подключенных к общей линии. Индивидуально задаются уров-
ни силы для состояния драйвера, соответствующего состоянию логического
нуля (<уровень силы 0>) и логической единице (<уровень силы 1>). Подроб-
нее об учете уровня силы в операторах присваивания см. в разд. 3.3.5.
Примеры:
reg a; // скалярная регистровая переменная
wire wl, w2; // декларация двух цепей
wire #5 w3= wl && w2; // совмещение объявления цепи и присваивания:
// w3 принимает значение логического И от значений wl и w2
// через 10 единиц модельного времени после изменения
// любого из них
reg[3:0] v; // 4 -разрядный векторный регистр,
// включающий v[3], v[2], v[l] и v[0],
// причем v[3] — старший разряд, a v[0] — младший
tri [15:0] busa; // 16 -разрядная шина с тремя состояниями
reg signed [0:3] signed_reg; // 4 -разрядный регистр, код в котором
// трактуется как число в диапазоне от -8 до +7
Любой разряд группы, объявленной как scalared, может использоваться в

выражении как скаляр, при этом используется имя группы и индекс, запи-
сываемый в квадратных скобках непосредственно за именем группы. Если
в скобках указан диапазон, то в операции участвует подгруппа разрядов из
указанного диапазона. Если же переменная, объявленная как группа, при-
сутствует в выражении без указания диапазона индексов, то в операции
участвуют все разряды группы.
Пример. Пусть определено
reg [15:0] regA, regb;
reg scal;
reg [3:0] regC;
и выполнено присвоение
regA = 16 'b 1111 1011 1101 0000;
Тогда приведенные операторы дадут следующие результаты:
а= regA[5]; / / а принимает значение 0
regB=regA; // regB принимает значение 16'b 1111 1011 1101 0000;
гедС=rеgА[7:3]; // rеgС принимает значение 4 ' b l l 0 l ;
Правила записи векторных констант

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

:[ <Разрядность представления> ] [ <базовый формат>] <число>
<баэовый формат> :: =
| 'd // десятичный формат, цифры 0 -9;
| 'h // шестнадцатеричный формат, цифры 0 -9, буквы a -f, x,z
| 'о // восьмеричный формат, цифры 0 -7, буквы x,z;
| 'b // восьмеричный формат, цифры 0,1, буквы x,z;
При записи числовых констант прописные и строчные буквы эквивалентны.

По умолчанию принимается десятичный формат. Для всех форматов, кроме
десятичного, используются не только традиционные символы, представ-
ляющие численный эквивалент кода соответствующей группы разрядов, но
и символы высокоимпедансного состояния "z" и неопределенного состояния
"х". Все разряды группы, специфицированной символами V и V, прини-
мают такое состояние.
Опция Разрядность представления> точно определяет число двоичных разря-
дов, значения которых заданы соответствующей константой.
Примеры:
5 'd 3 // пятибитовый код в десятичном представлении,
// эквивалентно 5 'b 00011.
12 'h 4x2 // двенадцатибитовый код в трехразрядном шестнадцатеричном
// представлении, эквивалентно 12 'b 0100хххх0010.
6 'о zl // шестибитовый код в двухразрядном восьмеричном
// представлении, эквивалентно 6 'b zzz00l
Если значение константы ограниченной длины присвоено векторной пере-

менной, имеющей больше разрядов, то старшие разряды этой переменной
принимают нулевое значение, если крайний левый символ в записи кон-
станты имеет любое значение '0' или '1'. Если же крайний левый символ
имеет значение х или z, то дополнительные старшие разряды приемника
принимают такое же значение.
Память
Одномерный массив битов в Verilog определяется как вектор, т. е. перемен-
ная соответствующего типа с указанием границ индексов. Двумерный бито-
вый массив представляется исключительно как пронумерованная совокуп-
ность битовых векторов и называется памятью (memory). Синтаксис декла-
рации памяти имеет вид:
<Декларация памяти> : : =
<декларация элемента памяти> <диапазон>;
Декларация элемента памяти> : : =
reg [<диапазон> ] <имя>;
begin stringvar= "Simulation started";

result_string={"Seance of", stringvar);
$display(" %S", result_string);
end;
Параметры
Параметрами (parameter) в Verilog называют константные значения, исполь-
зуемые в программах через объявленное имя. Синтаксис декларации пара-
метров определен следующим образом:
<декларация параметров> : : =
parameter <имя>=<константное выражение>
«,<имя>=<константное выражение> »;
Программный модуль может содержать сколько угодно деклараций парамет-
ров. Тип параметра совпадает с типом константного выражения.
Примеры:
parameter x=25, f=9; // Два параметра (константы) целого типа;
parameter pi=3.14157; // Константа действительного типа;
parameter word_size=8, last_bit_number= word_size - l ;
// значение Last_bit_number
// задано арифметическим выражением,
// включающим ранее определенный параметр;
parameter delay=100; // время задержки, выраженное в единицах
// модельного времени.
Хотя значения параметров являются константами внутри модуля, в котором
они определены, при включении в иерархические проекты им может быть
присвоено значение, отличное от предопределенного в декларации.
3.3.3. Операции и выражения

Выражение — это конструкция, которая объединяет операнды и знаки опе-
рации для формирования результата. В языке Verilog в качестве операнда
могут использоваться числа, имена переменных (цепей, регистров, целых и
временных переменных), выделенные биты и группы битов регистров и це-
пей, а также вызовы функций, которые возвращают значения любого из пе-
речисленных типов.
За редкими исключениями данные разных типов совместимы в одном вы-
ражении, что отличает язык Verilog от VHDL. Даже если операнды имеют
разную разрядность, их можно объединять в одном выражении, при этом по
умолчанию используется расширение разрядности более короткого операн-
да. С точки зрения использования в выражениях данные целого типа и дан-
ные времени характеризуются теми же правилами, что и переменные реги-
стрового типа.
Символы операций совпадают с принятыми в языке С. Их список приведен

в табл. 3.7. В то же время интерпретация операций в Verilog имеет некото-
рые особенности.
Таблица 3.7. Символы операций Verilog
Группа Символы Применимость

операций операций Наименование к данным
типа r e a l
Конкатенация {) Нет
Арифметические +, - Унарные арифметические Да
операции Бинарные арифметические Да
+,-,*,,/
% Модуль числа Нет
Операции сдвига >>,<< Сдвиг кода вправо или влево Нет
на заданное число разрядов
Операции >, >= Больше, больше или равно Да
отношения
<, <= Меньше, меньше или равно Да
Операции ==, != Равно — не равно (особенности Да
сравнения вычисления см. далее)
Нет
Операция &, ~& Свертка по И или И -НЕ Нет
свертки Свертка по ИЛИ или ИЛИ -НЕ Нет
Л
Свертка по "исключающему ИЛИ" Нет
Л
~ или ~ Л Свертка по "исключающему Нет
ИЛИ -НЕ"
Поразрядные Инверсия Нет
операции Поразрядное И (И -НЕ) Нет
&, ~&
1,~1 Поразрядное ИЛИ (ИЛИ -НЕ) Нет
^ Поразрядное "исключающее ИЛИ" Нет
^~ или ~^ Поразрядное Нет
"исключающее ИЛИ -НЕ"
Логические ! Логическая инверсия Да
операции Логическое И
&&
Да
II Логическое ИЛИ Да
Условная ? Если <условие>?,
операция то оначение 1 > : иначе
оначение 2>
В отсутствии скобок операции групп, приведенных в таблице выше, имеют

больший приоритет, т. е. являются старшими по сравнению с операциями
групп, стоящих ниже их в таблице. Внутри каждой группы используются
традиционные правила старшинства операций.
Рассмотрим особенности записи и интерпретации некоторых операций в
языке Verilog.
Арифметические операции
Набор арифметических операций и правила старшинства достаточно тради -
ционны для алгоритмических языков. Однако следует отметить, что резуль-
таты преобразования данных регистрового типа отличаются от результатов
выполнения операций над данными целого типа. Данные регистрового типа
рассматриваются как целое число в двоичном беззнаковом представлении.
То есть, если мы присваиваем регистровой переменной константное зна-
чение
- N <базовый формат> X
то эта переменная будет представлена ы -разрядным дополнительным кодом

числа -х. Пусть, например, определено:
integer intA;
reg [15:0] regA;
Тогда
regA= -4'dl2 // присвоен код "1111 1111 1111 ОНО",
// являющийся дополнением до двух кода числа +12, двоичный
// эквивалент которого равен "0000 0000 0000 1010"
intA= regA/3 // присвоено значение 21841, потому что код, находящийся
// в regA, представляет число 65526
Операции отношения и сравнения

Результат операции отношения — это скалярная величина, принимающая
значение 1, т. е. "истинно", если элементы справа и слева от символа опера-
ции удовлетворяют знаку операции в арифметическом смысле, и 0, т. е.
"ложно", если не удовлетворяют. При этом учитываются отмеченные выше
особенности представления данных, т. е. для регистровых данных большим
считается код, у которого единица при просмотре слева направо появляется
раньше. Если в коде любого из операндов присутствует хоть один разряд со
значением ' х' или ' z •, результат принимает значение ' х •. Подобно испол-
няются операции сравнения "==" и "'.=". Несколько иначе формируется ре-
зультат в операциях "===" и "!==". Здесь, если в сравниваемых кодах в оди-
наковых позициях находятся одинаковые значения, в том числе символы
неопределенности, то коды считаются равными, а при любых отличиях не-

равными. Результат операций "===" и "!==" может быть только 1 или 0.
Операции сдвига
В операциях сдвига операнд, находящийся слева от знака операции, сдвига-
ется влево или вправо на число разрядов, записанное справа. Освободив-
шиеся разряды заполняются нулями.
Логические и поразрядные операции

Результатом логической операции ИЛИ, И и инверсии, записываемых как
II, && и \, может быть единица, отображающая значение "истинно", нуль для
представления значения "ложно" или значение 'х 1 , что значит "неопределен-
но". В операции ИЛИ неопределенное значение поглощает нуль, но само
поглощается единицей. В операции И неопределенное значение поглощает
единицу, но само поглощается нулем. В практике чаще всего логические
операции используются для скалярных операндов, в частности для объеди-
нения в одном условии результатов операций отношения и сравнения.
При применении к целым переменным результат операции && дает 0, только
если один из операндов имеет значение 0, а в применении к векторным —
если все разряды одного из операндов нулевые. Наоборот, операция 11 дает
значение 1, если хоть один из операндов имеет определенное ненулевое
значение. Унарная логическая инверсия истинна, если код операнда не ну-
левой.
В отличие от логических операций, поразрядные операции выполняются
независимо над парами одноименных разрядов операндов. Эти частичные
результаты собираются в том же порядке, что и в операндах, формируя ре-
зультирующий код. Если операнды имеют различную разрядность, то более
короткий операнд дополняется нулями со стороны старших разрядов. Длина
кода результата равна длине большего операнда.
Операции свертки
Операции свертки имеют то же обозначение, что и поразрядные, но явля-
ются унарными и дают скалярный результат. Все разряды операнда рассмат-
риваются как скалярные аргументы соответствующей многоместной опера-
ции. Например, при выполнении свертки по И разряды аргумента анализи-
руются последовательно друг за другом, причем каждый раз выполняется
операция И над значением нового разряда и результатом анализа предыду-
щего. Анализ может быть завершен, если на каком -то этапе получен нуле-
вой результат. Фактически свертка по И даст нуль, если в коде операнда
содержится хоть один нуль, а результат будут равен единице, если все разря-
ды установлены в единицу. Если же в каком -либо разряде присутствует не -
определенное значение или символ высокоимпедансного состояния ' z' и

нет разрядов, установленных в нуль, результат принимает неопределенное
значение ' х ' . Подобные рассуждения можно привести для остальных опе-
раций свертки.
Необходимо обращать внимание на правильное расположение пробелов
в записях операций свертки, которое отличает их от логических операций.
Так запись А && в представляет логическое преобразование "А, объединенное
по логике И с в", а А & SB следует трактовать как "А, объединенное по логи-
ке И с результатом свертки в", т. е. А & (&в). Отметим, что если А — код, то
аргумент &в будет дополняться нулями со стороны старших разрядов.
Условная операция
Условная операция является единственной тернарной операцией, синтаксис
которой определяется следующим образом:
<условное выражение> ? <выражение 1> :<выражение2>
Если при вычислении условного выражения получено значение "истинно",

то в качестве результата используется <выражение!>, а если "ложно", то
<выражение2>. Если же получено значение "неопределенно", то выполняет-
ся поразрядная операция над результатами вычисления <выражения!> и
<выражения2>. При этом разряду результата приписывается значение 0, если
при вычислении обоих выражений в соответствующих разрядах получен О,
значение 1, если при вычислении обоих выражений в соответствующих раз-
рядах получена 1, и неопределенное значение во всех остальных случаях.
3.3.4. Операторы initials always

Как и в VHDL, в языке Verilog различают два вида операторов — парал-
лельные (по терминологии разработчиков языка "continuous" — непрерыв-
ные) и последовательные (названные разработчиками языка "procedural" —
процедурные). Последовательные операторы выполняются друг за другом в
порядке записи, параллельные же при любом изменении сигнала, исполь-
зуемого в качестве аргумента. Последовательные операторы должны быть
локализованы в теле составных операторов. Поэтому рассмотрение способов
описания поведения устройств начнем с операторов этого типа.
Оператор инициализации i n i t i a l запускается к исполнению единственный
раз при начале моделирования и используется либо для задания начальных
состояний в моделируемом устройстве, либо при записи программ модели-
рования (Test -Bench) для описания сигналов, поведение которых предопре-
делено сценарием отладки.
Синтаксис оператора инициализации определен следующим образом:
<оператор инициализаций ::= initial <оператор>
Может создаться впечатление, что оператор инициализации задает единст-

венное действие. Однако это не так. Вложенный оператор может быть со-
ставным. Не вдаваясь пока в детали определения составных операторов и
блоков, отметим, что составной оператор представляет последовательность
операторов, выполняемых друг за другом в порядке записи, ограниченную
ключевыми словами begin и end. После исполнения всех действий, предпи-
санных вложенными операторами, оператор "зависает" и не влияет на ис-
полнение остальных программных конструкций.
Рассмотрим программу (листинг 3.44), представляющую тест для проверки
некоторого устройства, в данном примере представленного оператором па-
раллельного присваивания.
module top;
reg [2:0] а;
wire [4:0] b;
assign 15 b ={c,&a,a};// параллельный оператор, изменение а и с вызывает
// его исполнение через 5 единиц модельного времени
initial c=l'b1; // нет необходимости в конструкции begin -end, потому

// что вложен единственный оператор
initial
begin
а = 'bООО; // начальное значение
# 1 0 0 а = ' b 1 0 ; // каждый оператор выполняется через 100 ед. модельного
// времени после исполнения предыдущего
#100 а = 'bill;
#100 а = 'Ы10;
end
initial
begin // запуск системной функции отображения результатов
$monitor($time,, "a=%b, b=%b",a, b ) ;
#1000 $finish;
end
endmodule
Операторы инициализации начинают исполняться "одновременно" (в том

смысле, что их результаты недоступны для операторов, также имеющих
нулевую отметку времени).
В результате моделирования будет получено:
О а=000, b=хххх
5 а=0000, b=10000
100 а -110, b=10000
105 а=110, b=10110

200 а=111, b=10110
205 а=111, b=11111
300 а=110, b=11111
305 а=110, b=10110
1000 $finish
Оператор постоянного повторения always также первый раз исполняется

при начале моделирования, но затем повторяется каждый раз после завер-
шения вложенного оператора. Синтаксис оператора имеет вид:
<оператор постоянного повторения> ::= always <оператор>
Если вложенный оператор составной, то действия повторяются после ис-

полнения последнего оператора из числа вложенных в него. В связи с цик-
лическим характером оператора always, он может иметь смысл только при
наличии в его теле конструкций, предусматривающих его переход в состоя-
ние ожидания. Это может быть ожидание заданных моментов времени или
иных событий в системе. Если не предусмотреть переход оператора в со-
стояние ожидания, все другие операторы в программе будут заблокированы.
Например, конструкция
always a= ~а;
порождает бесконечный цикл с нулевой задержкой, в то время как
always #delay a= ~a;
представляет генератор импульсов единичной скважности и периодом
2*delay, причем в интервале ожидания могут исполняться другие операторы,
например, вызываемые изменением переменной а.
Наиболее часто оператор always используется в сочетании с операторами, со-
держащими указание событий, инициирующих его исполнение (см. разд. 3.3.8).
В этом случае после исполнения действия, предписанного вложенным опе-
ратором, процесс приостанавливается до возникновения соответствующего
события. Из изложенного видно, что оператор always подобен процессу в
VHDL, содержащему список чувствительности или вложенный оператор
ожидания.
3.3.5. Операция присваивания,

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

записанного слева от знака равенства. Приемником может быть простая пе-
ременная, элемент вектора, группа разрядов вектора, а также объединение
объектов указанных типов. Если приемник — совокупность объектов, то ее
элементы записываются в фигурных скобках через запятые. Эти правила
можно свести к следующим BNF -формулам:
<приемник> ::=
Олемент приемника>
I {Олемент приемника> «, Олемент приемника>» }
<элемент приемниха> ::=
<имя> Г [<индексное выражение> Г : <индексное выражение> 1 ] 1
Применение правил к приемнику, содержащему единственный скалярный

элемент, представляется очевидным. В случае группового приемника разря-
ды результата присваиваются разрядам элементов приемника в порядке их
записи в списке элементов приемника. Например, если определено
wire [6:0] regA= 5'bОО10010;
wire [1:0] regB= 3'blx;
wire с =l'bz;
reg [3:0] d,e;
то в результате присваивания
{d,e}= {с, regB, regA[4:0] }
ПОЛУЧИМ d=4'bzlxl, е=4' b0010.

В Verilog определены два основных типа операторов присваивания —
continuous, т. е. непрерывные операторы, и процедурные — procedural. Не-
прерывные присваивания всегда рассматриваются как параллельные, т. е.
исполняются при изменении любой переменной, присутствующей в правой
части операции присваивания. Процедурные выполняются только при опре-
деленных условиях, задаваемых специальными конструкциями. Они могут
быть последовательными, т. е. выполняться друг за другом в порядке запи-
си, если локализованы в так называемых последовательных блоках, или па-
раллельными, если включены в параллельные блоки.
Непрерывное присваивание
Приемником в операторе непрерывного присваивания может быть только
переменная типа "цепь", скалярная или векторная. Синтаксис оператора па-
раллельного присваивания имеет вид:
<оператор параллельного присваиваний : : =
assign [ <сила драйвера> ] [ <задержка>] <присваивание> «,<присваивание>»;
<эадержха> ::=
# <параметр задержки>
| # ( <параметр задержки>, <параметр задержки>
[,<параметр задержки> ] }
<параметр задержки> ::=
<Выражение времени>
| <Выражение времени> : <Выражение времени> : <Выражение времени>
Оператор исполняется при изменении любой переменной, присутствующей

в правой части операции присваивания. Однако после вычисления результат
заносится только в буфер (драйвер), а временная отметка предсказанного
изменения заносится в календарь событий. Приемник получает новое зна-
чение только тогда, когда начнется отработка этого вновь предсказанного
события, т. е. через интервал модельного времени, заданный выражением
<задержка>. После этого результат сохраняется вплоть до следующего ис-
полнения оператора, т. е. изменения любого аргумента.
Если опция <задержка> отсутствует, предполагается дельта -задержка, т. е.
новое событие заносится в календарь событий с той же отметкой времени,
что и инициирующее событие, но после всех событий, которые уже занесе-
ны в календарь и имеют такую же отметку времени. Таким образом, пока не
исполнены все операторы, инициированные общим событием, аргументами
преобразований являются состояния сигналов на момент начала отработки
этого события.
Задержка может быть задана одним, двумя или тремя параметрами. Рас-
смотрим сначала константные параметры задержки для скалярных данных.
Если параметр единственный, то он задает значение модельного времени
задержки для любых переходов. Если присутствует второй параметр, то пер-
вый определяет время задержки для перехода из нулевого состояния в еди-
ничное, а второй — из единичного в нулевое. Третий параметр, если он
есть, специфицирует время задержки перехода в z -состояние. Например,
рис. 3.21 отображает результат моделирования программы, представленной
в листинге 3.45.
module delay_example;
reg sl,s2,v;
wire result;
assign # ( 10,5,15}
result=(sl=l) : 1'bl : 1'bz,
result=(s2==l) : v : 1'bz;
initial s1=0; s2=0;v=0;
#10 sl=l;
#20 sl=0;
#25 s2=l;
#15 v = l ;
#10 v=0;
#10 s2=0;
#20 $finish;
endmodule
res
0 1 2 3 4 5 6 7 8 9 1 0 1 1
Рис. 3 . 2 1 . Определение задержек в операторах параллельного присваивания
Некоторая специфика определена для присваивания значений векторам.

В этом случае:
- если при вычислении выражения в правой части присвоения младший
значащий бит (LSB) переходит в состояние единицы или сохраняется
в состоянии единицы, то используется значение задержки, записанное в
списке первым;
- если при вычислении выражения в правой части присвоения LSB пере-
ходит в состояние нуля или сохраняется в состоянии нуля, то использу-
ется второе значение, записанное в списке на второй позиции;
- если при вычислении выражения в правой части присвоения LSB пере-
ходит в состояние z или сохраняет состояние z, то используется третье
значение;
- если при вычислении выражения в правой части присвоения LSB нахо-
дился в неопределенном состоянии, или новое значение неопределенное,
то используется наименьшее из значений задержки из списка.
В случаях, когда разработчика интересует время задержки для отдельных
разрядов индивидуально, следует записывать не групповое присвоение, а
индивидуальные присвоения для разрядов.
Эти правила иллюстрируются программой LSB_as_selector распечаткой ре-
зультатов исполнения, приведенными в листинге 3.46.
module LSB_as_selector;
reg [2:0] а;
wire [2:0] b,c;
assign #(10,20) b = a;
c[0]=a[0];
c[l]=a[l];
c[2]=a[2];
initial
begin
a = 'bOOOO;
#100 a = 'bOlO;
#100 a = 'b101;
#100 a = 'b1ll;
end
initial
begin
$monitor($time,, "a=%b, b=%b",a, b) ;
#1000 $finish;
end
endmodule
Compiling source file // распечатка результатов

Highest level modules:
LSB_as_selector
0 a=000, b=xxx, b=xxx
10 a=000, b=0000, c=0000 // предыдущее состояние было х, использовано
// минимальное значение
100 a=010, b=000, c=000
110 a=010, b=000, c=010 // с[1] перешло в 1 с минимальной задержкой
120 a=010, b=010, c=010 // b[0]сохранил 0, для b используется время
// перехода в нулевое состояние
200 a=101, b=000, c=010
210 a=101, b=101, c=lll // b[0] перешел в 1, для b и с[0] использовано
// значение задержки для положительного фронта
220 a=101, b=101, c=101 // для с[1] задержка максимальна
300 a=lll, b=101, c=101
310 a=lll, b=lll, c=lll // b[1] сохранил единицу, для b и с[1]
// использовано меньшее значение задержки
Параметр задержки может быть не только числовой константой, но и име-

нем параметра или переменной и даже вычисляемым выражением. И нако-
нец, задержка может быть объявлена тремя параметрами, представляющими,
соответственно, минимальное, среднее и максимальное время задержки,
причем набор таких значений может быть задан индивидуально для каждого
вида перехода.
Язык Verilog позволяет описывать устройства, в которых несколько источ-
ников работают на одну линию, при этом каждому источнику сопоставляет-
ся собственный оператор непрерывного присваивания переменной, пред-
ставляющей сигнал на этой линии. Если при этом лишь один из таких ис-
точников может быть в активном состоянии, то ситуация описывается
относительно просто: если хоть один источник находится в активном со-
стоянии, переданное им значение, как более "сильное", по определению по-
давляет "слабые" сигналы, представляющие источники, находящиеся в от-
ключенном состоянии (z -состоянии). Однако в практике возникают и иные
ситуации. Во -первых, может быть необходимо обнаружение при моделиро-
вании сбойных ситуаций, связанных с некорректной активизацией несколь-
ких драйверов, возможно подключение к шинам схем с открытым коллекто-
ром и подобных компонентов, выходное сопротивление которых, а значит
влияние на результат, будет неодинаково в различных условиях. Конструк-
ция, определяющая степень такого влияния, называется "сила драйвера" и мо-
жет включаться в оператор параллельного присваивания.
Сила драйвера задается парой значений уровня, выбранных обязательно из
разных столбцов приведенного списка:
supplyl supplyO
strongl strongO
pulll pullO
weakl weakO
highzl highzO
Значения, заканчивающиеся символом 1, определяют уровень силы драйвера

в состоянии логической единицы, а заканчивающиеся символом 0 — в со-
стоянии логического нуля. Порядок записи безразличен. Если на сигнал
действует несколько драйверов, имеющих различный уровень силы, то сиг-
налу присваивается значение того, кто в данный момент представлен наи-
более сильным сигналом (значения в приведенном списке упорядочены,
причем выше в списке представлены более сильные значения). Если под-
ключены равносильные драйверы, сигналу присваивается неопределенное
значение. Например, моделирование фрагмента, представленного в листин-
ге 3.47, породит временную диаграмму, отображенную на рис. 3.22.
Wire а;
Reg b,c;
Assign (strongO,weakl) a=b;
Assign (strongl,weakO) a=c;
Initial с=0; b=0;

#10 с=1;
#10 Ь=1;
#10 с=0;
#10 с=1;
#10 b=0;
z -состояние
неопределенное состояние
Рис. 3.22. Влияние уровня силы драйвера на значение сигнала
Последовательные присваивания
Процедурные последовательные операторы присваивания, которые мы бу-
дем называть просто последовательными присваиваниями, потому что по-
следовательными могут быть только процедурные присваивания, локализу-
ются в так называемых последовательных блоках. Подробнее концепция
блока будет рассмотрена далее, пока же определим, что последовательный
блок — это последовательность операторов, заключенная между парой ключе-
вых слов begin и end. Последовательные операторы выполняются друг за
другом в порядке записи, а приемником в них может быть только перемен-
ная регистрового типа. Но с точки зрения доступности результатов присвое-
ния для последующих операторов имеются модификации. Язык Verilog не
различает, в отличие от VHDL, категорий сигналов и переменных. Но для
отображения причинно -следственных связей наряду с параллельными операто-
рами вводятся специфические, подобные VHDL, механизмы управления доступ-
ностью, задаваемые формой записи оператора: блокирующие и неблокирующие
операторы присваивания, и соответствующая символика.
Блокирующее присваивание запрещает исполнение других присваиваний до

своего завершения. Это гарантирует строго последовательное исполнение
операторов в блоке, даже если в записи результата присутствует опция за-
держки. Кроме того, такое определение делает результат присвоения непо-
средственно доступным любому последующему оператору в текущем про-
граммном блоке. Интересно, что если в блоке ни один оператор не содер-
жит признаков приостанова исполнения, то с точки зрения окружения все
операторы в блоке происходят как бы одновременно, и никакие промежу-
точные преобразования "невидимы" для других блоков.
Если присвоение содержит опцию задержки, то изменение предсказывается
на момент модельного времени, отстоящий от момента исполнения опера-
тора на объявленное число квантов модельного времени. Иными словами,
если имеем несколько последовательных операторов со своими указаниями
времени, то время задержки очередного присвоения от начала исполнения
первого есть сумма задержек предшественников. Примеры блокирующих при-
своений и соответствующие комментарии можно найти в листингах 3.44—3.46.
Неблокирующее присваивание отображается сочетанием символом <= и раз-
решает исполнение последующих операторов еще до собственного заверше-
ния.
Более того, если совокупность неблокирующих операторов инициирована
общим событием, то эти операторы начинают исполняться одновременно с
точки зрения правил, определенных дискретной событийной моделью, т. е.
все они используют значения операндов, определенные до начала исполне-
ния всей совокупности. Новые значения запоминаются в буфере до испол-
нения всех операторов, вызванных общим событием.
Неблокирующие присваивания предоставляют путь описания регистровых
устройств с обратными связями. Рассмотрим следующий фрагмент:
always 110
begin
a_blocked=input;
b_blocked=a_blocked;
a_non_blocked<= input;
b_non_blocked<= a_non_blocked;
end
Каждые 10 единиц модельного времени последовательно выполняются все

операторы присваивания, причем отметка времени для всех изменений оди-
накова. Но поведение переменных b_blocked и b_non_blocked существенно
различно. Переменные a_blocked и b_blocked примут одинаковое значение
input. В то же время присваивание переменной b_non_blocked выполняется
параллельно с присваиванием a_non_blocked. To есть пара переменных
a_non_blocked и b_non_blocked моделирует линию задержки на время
10 единиц модельного времени.
Можно видеть, что блокирующее присваивание эквивалентно присваиванию

значения переменной в VHDL, а неблокирующее — последовательному сигналь-
ному присваиванию.
3.3.6. Операторы принятия решений

Оператор условия и оператор варианта позволяют выбрать один из возмож-
ных путей исполнения алгоритма в зависимости от текущих условий. С точ-
ки зрения их интерпретации в процессе моделирования они относятся
к классу последовательных (процедурных) операторов и исполняются вслед
за оператором, предшествующим им в программном блоке. При реализации
в аппаратуре воспроизводятся блоки, выполняющие все описываемые аль-
тернативы, из которых либо инициализируется в каждый момент только
один блок, либо выходные сигналы считываются только с одного из блоков.
<оператор условия> ::=
if ( <выражение>) <оператор>
[else <оператор>];
Если вычисление выражения дает ненулевой результат, выполняется первый
оператор. Если выражение дает нуль, то в сокращенной версии (без ключе-
вого слова else), не выполняется никаких действий, а в полной версии —
второй оператор. Важно отметить, что в Verilog отсутствует логический или
булевский тип данных, а в качестве выражения, определяющего выбор,
можно использовать любые выражения, дающие целый результат. При этом
оператор
if (expression)...
имеет тот же смысл, что оператор
if (expression !=0)...
Логика исполнения оператора в целом подобна исполнению условного опе-
ратора в языке С, но имеется важная особенность, связанная с тем, что
в Verilog вычисление выражения может дать неопределенное значение. В этом
случае исполняется ветвь else. Здесь уместно напомнить, что операции
сравнения определены в двух версиях. Если используется обозначение "=="
(два знака равенства), то результат сравнения считается неопределенным,
если хоть один разряд операндов не определен. Если используется обозна-
чение "===" (три знака равенства), то операнды считаются совпадающими и
в тех случаях, когда у них в одноименных разрядах присутствуют неопреде-
ленные значения.
Ни в коем случае нельзя в операции сравнения использовать обозначение "
(один знак равенства), ибо один знак равенства представляет присваивание.
На месте первого оператора может использоваться пустой оператор, отобра-

жаемый знаком "точка с запятой". В качестве оператора может использо-
ваться составной оператор, т. е. последовательность операторов, ограничен-
ная операторными скобками begin и end, а также другой условный опера-
тор. Конструкция с многовариантным выбором может выглядеть, например,
следующим образом:
if (<выражение1>)
if (<выражение2>) <оператор1>
else <оператор2>
else if (<выражение 3>) <операторЗ>
else <оператор4>
В этом примере <оператор!> выполняется при ненулевых результатах вычис-

ления <выражения1> И <выражения2>, <операторЗ> ВЫПОЛНЯСТСЯ ПРИ НУЛЕВЫХ
результатах вычисления <выражения1> и ненулевых для <выраженияЗ> и т. п.
При большом количестве альтернатив и при возможности свести признаки
выбора в единственную переменную более компактное описание процедуры
принятия решений дает оператор варианта.
<оператор варианта> :: =
<определитель оператора варианта>( <ключевое выражение>)
« <Вариант> «,<Вариант> » : <оператор>»
endcase
•Сопределителъ оператора аарианта> ::= case | casez | casex
<вариант> := <константное выражение> | default
Трактовка версии оператора выбора с ключевым словом сазе достаточно

традиционна: исполняется лишь тот оператор, значение варианта которого
совпадает со значением ключевого выражения. Если ни один из вариантов
не совпадает с вычисленным значением ключевого выражения, то выполня-
ется ветвь default или не выполняется ни один оператор. В отличие от С
и подобно VHDL, выполняется только один вариант. Например, следующий
оператор описывает дешифратор с трехразрядным адресным входом, входом
разрешения и восемью выходами при представлении выбранного выхода
низким уровнем сигнала.
case (en,in_code)
4'd8: result = 8'bOllllllll;
4'd9: result = 8'b101111111;
4'dlO: result = 8'bllOlllll;
4'dll: result = 8'b11101111;
4'dl2: result = 8'bllllOlll;
4'dl3: result = 8'blllllOll;
4'dl4: result = 8'bllllllOl;
4'dl5: result = 8'blllllllO;
4'd0, 4'dl, 4'd2, 4'd3, 4'd4, 4'd5, 4'd6, 4'd7: result = 8 ' b l l l l l l l l ;
default result = 8'bx;
endcase
Отметим, что в версии с ключевым словом case при сравнении учитываются

все разряды, в том числе должны совпадать значения разрядов, обозначен-
ных как неопределенные и находящихся в z -состоянии. Рассмотрим пример,
в котором предусмотрена возможность определения вариантов с неопреде-
ленным значением аргумента:
case (select[l:2])
2'ЬОО: out = 0;
2'bOl: out = a;
2'bOx,
2'bOz: out = a ? 'bx : 0;
2'b1О: out = b;
2'bxO,
2'bzO: out = b ? 'bx : 0;
default: out = 'bx;
endcase
Если бы в этом примере отсутствовали варианты, представляющие неопре-

деленные значения, то при неопределенных сигналах на входе select выход
также принял бы неопределенное значение. Здесь же нули на входах а или ь
"подавляют" неопределенные значения на входах select. Отметим, что при
интерпретации этой программы при нулевом сигнале на входе s e l e c t [1]
состояние входа s e l e c t [2] не имеет значения.
Версии оператора варианта с ключевыми словами casex и casez позволяют
задавать совокупность вариантов, которые выполняются при совпадении
хотя бы некоторых разрядов, а остальные разряды при этом не важны (так
называемые "don't care"). В версии casez не учитываются при проверке на
совпадение разряды, имеющие значение z как в записи варианта, так и
в результате вычисления ключевого выражения. Так, коды 'b00zz101 и
'bzz1010z с точки зрения выбора в операторе casez совпадают. Оператор
с ключевым словом casex рассматривает разряды, установленные в состояние
высокого импеданса или неопределенное состояние, как несущественные.
При этом символы неопределенности могут содержаться как в результате
вычисления выражения, так и в записи варианта, причем в записи варианта
вместо символов z и х можно использовать вопросительный знак. Напри-
мер, приоритетный декодер может быть представлен следующим оператором:
casez (ir)
5'bl????: request_code=5;
5'bOl???: request_code=4;
5'bOOl??: request_code=3;
5'b 00 01?: reques t_code=2;

5'b 0000l: request_code=l;
5'b 00000: request_code=0;
endcase
3.3.7. Операторы повторения

В языке Verilog определены четыре формы операторов повторения:
<оператор повторения> : : =
f o r e v e r <оператор>
| r e p e a t ( <выражение>) <оператор>
| while ( <выражение>)<оператор>
| for ( <присвоение>; <выражение>; <присвоение>) <оператор>
Во всех случаях вложенный оператор может быть простым или составным,

т. е. содержать совокупность последовательных операторов, заключенную
между ключевыми словами begin и end.
Оператор с ключевым словом forever повторяется бесконечно каждый раз
после исполнения вложенного оператора. При моделировании исполнение
может быть прекращено вызовом системной функции $finish или систем-
ными средствами. Очевидно, что такой оператор может быть полезен, толь-
ко если вложенная в него конструкция предусматривает прерывания выпол-
нения, например блокирующие присваивания с объявлением времени, опе-
ратор ожидания wait.
Остальные формы операторов повторения по синтаксису, да и по интерпре-
тации записанных действий, практически не отличаются от таких же опера-
торов языка С, поэтому ограничимся несколькими простыми примерами.
Отметим только, что реализуемые подмножества языка требуют использова-
ния "логически статических" выражений для операторов повторения.
Листинг 3.48 представляет описание последовательного умножителя. Опера-
тор always начинает исполняться после положительного фронта сигнала
s t a r t . После приема кодов сомножителей в сдвигающие регистры и обну-
ления регистра результата составной оператор, вложенный в оператор repeat,
повторяется, причем число повторений задается выражением в скобках,
в нашем случае, параметром size, значение по умолчанию для которого оп-
ределено как 8. Исполнение вложенного оператора инициировано сигналом
clock и предусматривает стандартные для последовательного умножения
действия: прибавление содержимого регистра множимого к результату, если
младший разряд регистра множителя нулевой, с последующим сдвигом ко-
дов в регистрах множимого и множителя.
module multiply (clock,start, a,b,result,ready);

input clock,start;
input a,b;
output result,ready;
parameter size = 8, longsize = 16;
wire [size:l] a,b;
reg [size:l] opb;
reg ready;
reg [longsize:1] result;
reg [ longsizble:1] opa;
always @ ( posedge start)
begin
opa = a; // загрузка новых исходных данных
opb = b;
result = 0;
ready= 0;
repeat (size) // повторить для всех разрядов
@ ( posedge clock) // блок инициируется фронтом clock
begin
if (opbfl]) result = result + opa;
opa = opa « 1 ;
opb = o p b » 1;
end
ready=l;
end
endmodule
Фрагмент, представленный в листинге 3.49, описывает процесс подсчета

числа единиц в байте входных данных in_data. На каждом шаге алгоритма
выполняется сдвиг кода аргумента, и, если в младшем разряде нуль, к ре-
зультату прибавляется единица. Цикл прекращается, когда сдвигающий ре-
гистр очищен.
begin
reg [7:0] shi ft_reg;
result = 0 ;
shift_reg = rega;
while(shift_reg)
begin
if (shift_reg [0]) result = result + 1;

shift_reg = shift_reg» 1;
end
end
Этот же алгоритм может быть записан с использованием оператора for:

begin :countls
reg [7:0] shift_reg;
result = 0;
for (shift_reg = rega; shift_reg!=0; shift_reg = shift_reg» 1}
if (tempreg[0]> result = result + 1;
end
В операторе for первое присвоение задает начальное значение переменной

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

Выше уже неоднократно отмечалось, в языке Verilog порядок исполнения
операторов определяется не только и не столько порядком их записи. Пре-
дусмотрен широкий набор средств, определяющих условия, при которых
оператор будет исполнен. Эти условия оформляются в виде префиксов опе-
раторов и выражений языка, в том числе логических и арифметических вы-
ражений, а также и выражений присваивания. Среди этих средств наиболее
важное значение имеют префиксы управления временем и префиксы событий-
ного управления.
В разд. 3.3.5 приведен ряд примеров использования префикса времени перед
операцией присваивания. Префикс начинается с символа #, после которого
записывается число, имя переменной времени или выражение. Однако дей-
ствие этого префикса в различных ситуациях неодинаково.
Префикс времени перед оператором непрерывного присваивания означает
вычисление нового значения на основе текущих значений аргументов и со-
хранение этого значения в буфере на время, заданное параметром префикса.
Префикс перед словом begin, открывающим последовательный блок, озна-
чает задержку начала исполнения всего блока.
Если префикс предшествует последовательному оператору, то оператор ис-
полняется после предыдущего в последовательности через временной ин-
тервал, заданный префиксом. Фактически, это означает приостанов испол-
нения программного блока. В качестве исходных данных для оператора
используется значение переменных на момент начала его исполнения. Заме -
тим, что изменения аргументов могут быть произведены другими операто-

рами, исполняемыми в "параллельно" инициированных блоках.
Если префикс времени предшествует блокирующему оператору присваива-
ния, то вычисленное значение присваивается приемнику сразу после ис-
полнения оператора, а если оператору неблокирующего присваивания — то
после исполнения всех операторов, инициированных общим событием.
И наконец, префикс, расположенный перед записью операции в правой
части оператора присваивания (такую запись называют "intra -assignment
control", что можно перевести как управление изнутри присвоения), означа-
ет задержку присвоения результата приемнику, хотя при вычислении выра-
жения также используются значения аргументов, существовавшие на мо-
мент инициализации оператора.
Перечисленные правила иллюстрируются программой, представленной в
листинге 3.50 и на рис. 3.23, показывающем результаты ее моделирования.
module delay_example;
wire d;
reg а,Ь,с; assign #10 d=a;
initial
begin a=0;
#20 a=l;
#20 a=0; end
i n i t i a l #5
begin b=a;
#20 b=a;
#20 b=a;
end
initial
begin #5 c= #5 a;
#20 c - #5 a;
#20 c= #5 a;
end
endmodule
На рисунке кружками отмечены моменты вычисления новых значений в

операторах присваивания, а стрелки указывают моменты изменения сигна-
лов, вызванные соответствующим оператором.
Если представление инициализации операторов с указанием времени харак-
терно скорее для моделирования, то другой вид управления инициализаци-
ей, а именно событийное управление, непосредственно влияет на реализа-
цию проекта.
О 10 20 30 40 50 60
Рис. 3.23. Управление изнутри присвоения
Событийное управление отображается в программе префиксом события, кото-

рый предшествует оператору, блоку или выражению.
<префикс собкгия> : : =
@(<событийное выражение> « or <событийное выражение> »)
| @<идентификатор события>
<событийное выражение> : : =
<выражение>
| posedge <скалярное выражение>
| negedge <скалярное выражение>
Событийное выражение вычисляется "непрерывно", т. е. его значение пере-
определяется при любом изменении входящих в него операндов.
Простейший случай — использование простого выражения в качестве собы-
тийного — означает, что оператор будет исполняться при любом изменении
значения выражения. Например, оператор
@ (clock) q=d;
будет исполняться при любом изменении сигнала clock, т. е. как после по-
ложительного, так и после отрицательного фронта управляющего сигнала.
Но такая конструкция не вполне соответствует поведению большинства ре-
альных триггерных схем, которые реагируют только на один из фронтов.
В принципе, конечно, можно использовать в качестве управляемого опера-
тора не простое присвоение, а условный оператор с целью блокирования
действий на одном из фронтов, но Verilog предоставляет более компактную
запись такого поведения. Префикс, содержащий слово posedge, обеспечи-
вает исполнение оператора только при изменении результата вычисления
выражения, записанного в скобках, из нулевого состояния в единичное.
Таким образом, оператор

always @ (posedge (clock & enable)) q=d;
определяет D -триггер с динамическим управлением, срабатывающий при
разрешающем единичном сигнале на входе enable по нарастающему фрон-
ту сигнала clock.
Аналогично, ключевое слово negedge задает чувствительность только к спа-
ду значения выражения. В префиксах со словами posedge и negedge выра-
жение должно быть скалярным, т. е. таким, результатом которого является
одноразрядный результат.
Если оператор может быть инициализирован при различных ситуациях, ис-
пользуется объединение инициирующих событий с использованием слова
or. Тогда любое из перечисленных событий приводит к исполнению опера-
тора. Так оператор
always @(posedge clock or d) if(clock) q=d;
интерпретирует D -триггер с потенциальным управлением положительным

уровнем сигнала clock.
Следующий пример описывает J -K -триггер с динамическим управлением и
асинхронным сбросом:
always @(posedge clock or posedge reset)
begin
if( reset) q<=0;
else case {j,k}
0:;
l:q<=l'bO;
2:q<=l'bl;
3:q<=~q;
endcase
end
Префикс событийного управления, подобно префиксу времени, может за-

писываться перед выражением в правой части присвоения. Это означает,
что выражение вычисляется в момент исполнения оператора, но фактиче-
ское присвоение выполняется при наступлении события. Включение допол-
нительного выражения повторения позволяет задать поведение, при кото-
ром присвоение будет выполняться после заданного числа инициирующих
событий. Например, оператор
a_delayed= repeat (5) @(posedge clock) a_origin;
определяет, что значение a_origin, имевшееся на момент исполнения опе-
ратора, будет присвоено регистровой переменной a_delayed только по про-
шествии пяти нарастающих фронтов тактирующего сигнала.
Если какая -то комбинация условий инициализации операторов применяется

достаточно часто, то такому событию можно присвоить идентификатор и
далее использовать это имя. Например, событию "фронт тактового сигнала"
можно было бы присвоить имя и в дальнейшем использовать это имя сле-
event specific_situation; // присвоение имени событию
always @(posedge clock)
posedge reset -> specific_situation; // определение события
always @(specific_situation)... // событийное управление
3.3.9. Блоки
В предыдущих разделах мы неоднократно использовали блочное представ-
ление программы. Составные операторы, вложенные в операторы инициа-
лизации и в операторы постоянного повторения, являются простыми при-
мерами блоков. Блок объединяет операторы, связанные общими правилами
инициализации. В данном разделе дается более подробное изложение кон-
цепции блока, принятой в языке Verilog.
Различают последовательные и параллельные блоки. Формальный синтаксис
блока определен следующим образом:
<блетс> : : =
Открывающее слово
[ : <имя блока> [ <раздел деклараций блока>] ]
« <оператор> »
<закрывающее слово>
Раздел деклараций может содержать декларации локальных имен (констант,

регистровых и численных переменных, а также событий), определенных
только внутри данного блока.
Последовательный блок ограничивается закрывающим и открывающим сло-
вами begin и end. Операторы в последовательном блоке исполняются друг
за другом в порядке записи. При наличии префиксов задержки время в про-
цессе исполнения такого блока накапливается (см. ранее приведенные приме-
ры в листингах 3.44—3.47 и др.). Исполнение завершается после реализации
последнего оператора в блоке.
Параллельный блок заключен между словами fork (распараллелить) и join
(объединить). Порядок записи операторов в таком блоке не имеет значения.
Операторы исполняются параллельно в смысле, определенном дискретной
событийной моделью, т. е. по мере возникновения в системе инициирую-
щих событий (изменения состояний определенных переменных или дости-
жения системой моделирования предопределенных отметок времени), при -
чем задержки вложенных операторов исчисляются от момента инициализа-

ции параллельного блока. Изменение значений сигналов, которые произво-
дятся в других блоках перед исполнением каждого оператора, учитываются
в результатах вычисления выражений.
Рассмотрим фрагмент, представленный в листинге 3.51, результаты модели-
рования которого приведены на рис. 3.24. Здесь время исполнения всех
операторов, вложенных в параллельный, отсчитывается от фронта сигнала а.
initial
begin a=0;
#10 а - 1;
120 а= 0;
#70 а=1;
#20 а=0;
end
always @(posedge a)
begin
fork
#20 b=0; //
#10 b=a; // Это присвоение выполнено раньше предыдущего
# 30 b=l'bz; // время отсчитывается от фронта сигнала а
join
#5 b=l'bz; // время отсчитывается от выполнения последнего
// оператора в параллельном блоке
end
endmodule
Рис. 3.24. Результаты моделирования программы (листинг 3.51)
В целом, однако, представляется, что подобное поведение удобнее описы-

вать с использованием непрерывных присвоений или блокирующих при-
своений.
3.3.10. Подпрограммы
Как и в традиционных языках программирования, использование подпро-
грамм позволяет обеспечить структуризацию, следовательно, лучшую пони -
маемость программ, а также экономит время проектировщика, позволяя од-
нократно описывать однотипные фрагменты устройств и/или алгоритмы их
функционирования. И так же, как и в других языках, в Verlog различают два
вида подпрограмм, отличающихся по способу возвращения результата в вы-
зывающую программу: задачи (task) и функции (functions). При вызове всем
объектам подпрограммы, которые представлены локальными именами и ко-
торые мы будем называть формальными объектами, сопоставляются факти-
ческие объекты — значения или имена переменных, используемые в кон-
кретном вызове вместо соответствующих формальных объектов.
В большинстве публикаций по программированию, в том числе при представ-
лении языка VHDL в данной книге, для определения информации, передавае-
мой между вызывающей программой и подпрограммой, используются термины
"формальный параметр" и "фактический параметр". Но в Verilog понятие
"параметр" имеет несколько иной смысл, а параметр может сам быть переда-
ваемым объектом. Поэтому во избежание путаницы здесь использовано отно-
сительно нетрадиционное название для обозначения данных, сопоставляемых
при вызове.
Задача возвращает результаты через сопоставление формальных и действи-

тельных объектов, функция возвращает единственное значение через имя под-
программы на месте ее вызова в выражении. Подобный аппарат определен
почти во всех языках программирования. Однако в Verilog есть специфиче-
ские отличия по сравнению с традиционными языками как с точки зрения
синтаксиса деклараций, так и с точки зрения правил использования.
Правила декларирования подпрограмм могут быть сведены к следующему:
<декларация подпрограммы> : : =
<заголовок подпрограммы>
« <декларация> »
« <оператор> »
<Закрывающее слово подпрограммы>
<Заголовок подпрограммы> ::= task <имя>; | function <имя>;
<закрывающее ключевое слово подпрограммы> : : = endtask | endfunction
Можно обратить внимание на то, что в отличие от большинства традицион-

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

быть хоть один входной формальный объект.
Кроме отмеченных отличий существуют следующие:
- Программный модуль "Задача" может содержать опции событийного и
временного управления, т. е. для задачи могут предусматриваться условия
инициализации и предполагаться ее выполнение в течение некоторого
времени. Функция выполняется с "нулевой задержкой", конструкции,
специфицирующие событийное или временное управление, в функциях
запрещены.
- В задаче допускается вызов других задач и функций, функция может вы-
зывать другую функцию, но не задачу.
- В разделе операторов функции должно содержаться присвоение значения
имени функции.
Вызов задачи, как и вызов функции, предусматривает запись имени, вслед
за тем в скобках через запятые записываются фактические объекты, причем
порядок записи фактических объектов строго соответствует порядку появле-
ния имен отображающих формальных объектов в декларации подпрограммы.
Вызов задачи рассматривается как оператор, и его инициализация подчиня-
ется общим правилам исполнения операторов.
- В последовательном блоке вызов задачи инициируется после исполнения
предыдущего оператора. Возможно дополнительное управление инициа-
лизацией с использованием префиксов событийного или временного
управления. Естественно, внутри себя задача может моделировать про-
цесс, протекающий во времени.
- В параллельных блоках исполнение задачи инициируется при возникно-
вении событий, предусмотренных префиксами операторов вызова, в том
числе после достижения указанного префиксом времени.
Вызов функции традиционно включается в выражение, и предусмотренный
алгоритм исполняется мгновенно (с точки зрения дискретной событийной
модели), как только инициирован оператор, использующий это выражение.
По умолчанию при реализации в аппаратуре каждому вызову функции,
имеющемуся в программе, сопоставляется регистр для сохранения результа-
та, состояние которого может измениться в момент исполнения соответст-
вующего оператора.
В качестве примера в листинге 3.52 приведено описание устройства, реали-
зующего преобразование
r e s u l t = а х b — с х d;
Умножители представлены вызовами задачи mul. Алгоритм умножения, ис-
пользованный в описании задачи mul, эквивалентен алгоритму, представ -
ленному модулем multiply в листинге 3.47. Здесь только немного модифи-

цирована запись: использовано автоматное описание алгоритма и вызов
функции для суммирования. Для реализации операций сложения и вычита-
ния используется вызов функции asd_subb, причем из примера видно, что
вызовы функции входят в правые части операторов присваивания, в том
числе могут содержаться внутри задачи. Результат вычитания произведений
присваивается порту r e s u l t при исполнении непрерывного оператора, ко-
торый инициируется положительным перепадом сигнала готовности одного
из умножителей.
module mult_and_subb (clock,start, a,b,c,d, result);

input clock,start,input a,b,c,d;
output result;
wire [8:1] a,b,c,d;
reg ready;
reg [17:1] result;
reg [16:1]prodl,prod2;
function add_subb;
input opa,opb;
input direction; // 1 - сложение, О - вычитание
if (direction) add_subb=opa+opb;
else add_subb=opa -opb;
endfunction
task mul;
parameter size=8;
input elk,start;
input [size:l] opa,opb;
output [2*size:I] product;
output ready;
reg ready, state;
reg [size:l] shift_opb;
reg [2*size:l] shift_opa,product;
reg [3:0]count;
begin
@ ( posedge clock or posedge start)
if (start) state=0;
else case (state)
0: begin if (start)
shift_opa = opa;
shift_opb = opb;
product = 0;
count=size;
ready= 0;
state=l;
end
1: begin if (count==0) begin
state=0;
ready=l;
end
else if (shift_opb[l])
product = add_subb(product,shift_opa,1);
shift_opa - shift_opa « 1 ;
shift_opb = shift_opb» 1;
count= add_subb(count,1,0);
end
endcase
end
endtask
mul (8,clk,start,a,b,prodl,ready);
mul (8,clk,start,c,d,prod2,);
always @(posedge ready) result=add_subb({l'bO,prodl},{I'b0,prod2},0);
endmodule
3.3.11. Структурное описание проекта

Большинство современных языков проектирования аппаратуры поддержи-
вают возможность описания проекта в виде совокупности заранее описан-
ных компонентов и их связей, и язык Verilog не является исключением.
Всякая иерархия представлена главным проектным модулем, который назы-
вают вершиной проекта, и совокупности подчиненных проектных модулей.
Вершина проекта содержит операторы вхождения компонентов. Подчинен-
ный проектный модуль может быть, в свою очередь, вершиной следующей
иерархии. В общем случае, проектные модули независимы в том смысле,
что каждый может использоваться самостоятельно в различных конструкци-
ях и быть вершиной проекта. Проектные модули, относящиеся к одному
проекту, могут находиться в одном файле или представляться несколькими
файлами. В последнем случае проектные файлы должны компилироваться
в библиотеку проекта в порядке их вхождения в иерархию снизу вверх.
Вхождение проектного модуля в проект высшего иерархического уровня
отображается оператором вхождения, формальный синтаксис которого опре-
деляется следующим образом:
<опвратор жхождения> ::=
<имя модуля> [ <присвоение значений параметрам> ]
<объявление вхождения> «,<объявление вхождения> »;
•(присвоение значений параматрам> : : =

# ( <выражение> «,(выражение> »)
•(объявление вхождения> : : =
(имя вхождения> (список соединений)
<списох соединений» : : =
(соединение порта модуля> «,<соединение порта модуля> »;
I (именованное соединение> «,(именованное соединение> »
<соединение порта модуля> : : = <выражение> | <пробел>
<именованное соединениe> :: = . (имя порта> ( [<выражение>])
При описании вхождения модуля в иерархический проект используются два
имени: имя вхождения и имя модуля. Первое присваивает собственное имя
включаемой подсхеме, а второе определяет способ ее функционирования и
реализации в форме указания имени программного модуля, описывающего
его функционирование или структуру. Несколько вхождений могут быть
представлены однотипными подсхемами, т. е. ссылаться на одинаковый
программный модуль, но каждый экземпляр имеет собственное имя. Как
видно из синтаксических правил, допустимо объявление нескольких одно-
типных встраиваемых модулей в одной декларации.
Оператор вхождения может рассматриваться как вызов подпрограммы
с проблемно -ориентированным интерфейсом вызова. Кроме того, отличие
состоит в том, что внутренние переменные включаемого модуля определены
как статические, сохраняющие значения между инициализациями. Фор-
мальные объекты включаемого модуля (параметры и сигналы) при инициа-
лизации оператора замещаются фактическими объектами вызывающей
программы. Оператор вхождения модуля обязательно параллельный, это
означает, что преобразования, определенные в операторной части включае-
мого модуля, выполняются всякий раз, когда изменяются фактические объ-
екты оператора вхождения.
Список присваиваемых при вызове фактических значений параметров предше-
ствует имени вхождения. Порядок записи фактических значений параметров
строго соответствует порядку объявления формальных имен параметров в опи-
сании включаемого модуля.
Сопоставление формальных и фактических переменных при вызове осуще-
ствляется либо в соответствии с позицией в соответствующем списке, либо
по имени (именованное соединение). Недопустимо использовать разные
способы сопоставления в одном операторе. При позиционном сопоставле-
нии порядок записи фактических объектов в списке соединений порта точ-
но соответствует порядку записи имен портов в тексте описания модуля.
Неиспользуемые порты, а также входные порты, для которых значение
сигналов выбирается заданным по умолчанию, отмечаются символом
<пробел>. При сопоставлении по имени описание подключения порта на-
чинается со знака "точка", после чего записано имя порта, а затем, в скоб -
ках, имя сигнала или выражение, вычисляющее значение сигнала, подавае-

мого на порт.
Рассмотрим в качестве примера модуль умножения восьмиразрядных опе-
рандов на базе четырехразрядных умножителей, интерфейс которых соот-
ветствует модулю, представленному листингом 3.47 (операторная часть мо-
дуля multiply может быть и другой, например представлять параллельную
схему — в данном случае это не существенно). Программа (листинг 3.53)
представляет устройство с четырьмя параллельно работающими блоками,
каждый из которых выполняет попарное умножение тетрад кодов операндов
с последующим взвешенным суммированием частичных произведений по
формуле:
Product = mult * fact =
= (16 * mult[7:4] + mult[3:0]) * (16 * fact[7:4] + fact[3:0]) =
= 256(mult[7:4] * fact[7:4]) +
+ 16(mult[7:4] * fact[3:0] + mult[3:0] * fact[7:4]) + fact[3:0] * mult[3:0]=
= 256 * higher + 16 * (middlel + middle2) + lower;
Для трех встроенных умножителей использовано сопоставление портов по

имени, а для одного последнего — позиционное сопоставление.
module multSxS (clk,strt, mult,factor,product);

input clk,strt;
input mult,factor;
output product;
wire [8:1] mult,factor;
reg [8:1] vl, v2, v3,v4,elder_part;
reg [9:1] middle_jpart;
wire [16:1] product;
wire fin;
multiply #(4,8)
lower (.clock(clk),.start(strt),.a(mult[4:1]),.b(factor[4:1]),
.result(vl),.ready(fin)),
middlel(.clock(clk),.start(strt),.a(mult[8:4]),
.b(factor[4:1]),.result(v2)),
middle2(.clock(clk),.start(strt),
.a(mult[4:1]),.b(factor[8:4]),.result(v3)),
elder (clk,strt,mult[8:4],factor[8:4],);
always @(posedge fin)
begin
middle_part={l'bO,v2}+ {I'b0,v3}+ {5'dO,vl[8:4]};
elder_part= {3'dO,middle jpart[9:4]}+v4;
end
assign product={elder_part,middle_part[4:1],vl[4:1]};
endmodule
Отметим, что в программе, во избежание потери бита переполнения, раз-

рядность переменной middie_part и кодов, используемых для ее вычисле-
ния, расширена на один разряд в сторону старших.
Иногда удобно объединить совокупность объявлений параметров несколь-
ких различных компонентов в общую область программы. Это можно сде-
лать с помощью специального программного блока декларации параметров
defparam. В примере, представленном программой (листинг 3.54), модуль
верхнего уровня иерархии top содержит два экземпляра регистра -защелки
latch, но один из них (ml) — пятиразрядный, а второй (т2) — десятираз-
рядный. Эти параметры, а также времена задержки регистров, определены
В Выделенном программном модуле parameter_def i n i t i o n .
module top( inl,in2,enl,en2,adr_write,out);

input [0:4] inl;
input [0:9]in2;
input enl,en2,adr_write;
output[0:9] out;
wire [0:4] ol;
wire [0:9] o2;
wire [0:9] out;
latch ml (datl, inl, enl); // оператор вхождения
latch m2 (o2, in2, en2);
assign 15 out={5'dO,ol}& adr_write | o2 & !adr_write; // переключатель
endmodule
module latch (out, in, clk,en); // встраиваемые модули
parameter size = 1, delay = 1;
input [0:size -l] in;
input clk,en;
output [0:size -l] out;
reg [0:size -l] out;
always @(posedge elk or posedge elk)
I delay out = in;
endmodule
module parameter_definition; // модуль декларации параметров
defparam
top.ml.size = 5,
top.ml.delay = 10,
top.m2.size = 10,
top.m2.delay = 20;
endmodule
3.3.12. Примитивы
Подклассом встраиваемых модулей являются примитивы. Общее их свойст-
во — они имеют единственный выходной порт. Различают предопределен-
ные примитивы и примитивы, определяемые пользователем (User Defined
Primitives, UDP).
Предопределенные примитивы
Образы предопределенных примитивов по умолчанию присутствуют в биб-
лиотеке, и дополнительных деклараций не требуется, а вызов подчиняется
общим правилам объявления вхождений.
Приведем список наиболее употребительных предопределенных примитивов
Verilog:
<имя предопределенного примитива> ::=
and | nand (or |nor | xor | xnor | buf (bufifO | bufifl | not
Имя предопределенного примитива определяет реализуемую логическую

функцию всех входных объектов в соответствии с общеупотребительной но-
тацией. Предопределенным параметром примитивов является время задерж-
ки, объявление которого предшествует имени вхождения, как и принято в
декларации параметров вхождения, и выделяется символом #. Список соот-
ветствий портов начинается в примитивах с выходного порта, после чего в
произвольном порядке записываются информационные входы. Для буфер-
ных схем (buf, bufifo, bufifl) список заканчивается указанием соответствия
входа разрешения.
Включение примитивов, по сравнению с включением других модулей, дает
дополнительные возможности. Во -первых, имеется прямая возможность
объявления силы драйвера, соответствующего логической ячейке (это указа-
ние размещается непосредственно за именем модуля перед именем вхожде-
ния и параметром задержки, если таковой определяется). Указание силы
драйвера определяет состояние линий связи, к которой подключается не-
сколько источников по тем же правилам, что и для параллельных присвое-
ний. Во -вторых, вводится возможность определения совокупности прими-
тивов в форме вектора. Например, схема сравнения кодов может быть пред-
ставлена следующим образом (листинг 3.55):
module code_compare (inpl,inp2,result);

parameter length=8;
input [lenlth -l:0] inpl,inp2;
output result;
wire [lenlth -l:0] inpl, inp2,bit_wise _comp;
wire result;
xor #(5) comp [lenlth -l:0] (bit_wise_comp, inpl, inp2,);

assign result= | bit_wise_comp;
endmodule
Здесь конструкция
xor comp[lenlth -l:0](inpl, inp2, bit_wise_comp)
представляет набор из l e n i t h элементов "исключающее ИЛИ", имеющих
задержку 5 единиц модельного времени каждый. Выходы этих элементов
объединяются по логике ИЛИ, формируя единичный сигнал, если хоть в
одном из разрядов аргументов имеется несовпадение.
Все же нам представляется, что описание комбинационных логических схем
с использованием обычных логических выражений и присвоений выглядит
более естественно и наглядно. Правда, разработчики языка утверждают, что
представление логических преобразований с использованием примитивов
позволяет уменьшить время моделирования.
Примитивы, определяемые пользователем

Пользователю предоставлена возможность создания собственных примити-
вов (User Defined Primitive, UDP), а именно моделей устройств, имеющих
произвольное число входов, но единственный выход. Может быть задана
произвольная логическая функция. Допускается создавать как UDP комби-
национного типа, так и примитивы, обладающие памятью и фактически
представляющие триггеры со специфическими функциями переходов.
Для определения UDP вводится специальная программная единица primitive.
По своему иерархическому уровню primitive эквивалентен модулю и может
находиться в тексте программы как до, так и после модуля, который содер-
жит ссылку на этот примитив. Определение UDP разрешено представлять
также в другой программе, заранее скомпилированной в библиотеку проек-
та. Определение UDP не должно входить в другой модуль (помещаться
в программе между ключевыми словами module и endmodule).
Определение UDP подчиняется следующим синтаксическим правилам:
<UDP> :: =
primitive <имя UDP> (<имя выхода>,
<имя входа> «,<имя входа> » ) ;
input <имя входа> «,<имя входа> »;
output <имя вькода>;
[ <спецификация выхода> ] // только для последовательностных UDP
[ <определение исходного состояния> ] // только для
// последовательностных UDP
<таблица истинности>
endprimitive
Обратите внимание на то, что смысл имен входов и выходов определен два-
жды. Во -первых, он однозначно задается порядком записи в заголовке (т. е.
в скобках после имени примитива), а во -вторых, специфицируется высказы-
ваниями input и output. Несовпадение этих двух определений является
ошибкой.
Синтаксис определения UDP комбинационного типа отличается от синтак-
сиса определения последовательностных UDP, поэтому рассмотрим их раз-
дельно. В комбинационных UDP не предусматривается определение исходного
состояния и спецификации выхода.
Синтаксис таблицы для комбинационного UDP определен следующим об-
разом:
<таблица для комбинационного UDP> ::=
table
« <список значений входов> : <значение выхода комбинационного UDP>;>>
endtable
<список значений входов> ::= Оначение входа> « <значение входа> »
Оначение входа> : : = 0 | 1 | х | ? | b
Оначение выхода комбинационного UDP> :: = 0 | 1 | х
Слева от двоеточия в каждой строке таблицы приводится возможная комби-

нация значений аргументов, а справа — значение выхода при такой комби-
нации на входе.
Порядок записи значений входов должен строго соответствовать порядку
следования их имен в заголовке определения примитива.
Значения входов и выхода 0, 1 и х имеют традиционный для Verilog смысл.
Символ ? означает "не важно", т. е. отмеченный таким образом вход не
влияет на результат. Символом ь обозначают совокупность комбинаций вхо-
дов, для которых не важно, находится ли соответствующий вход в нулевом
или единичном состоянии, но неопределенное состояние этого входа будет
вызывать другие результаты и требует дополнительного описания.
В листинге 3.56 в качестве примера приведена программа, содержащая оп-
ределение примитива vote (голосование), реализующего распространенную
функцию большинства
major =x&y | y&z | x&z;
и модуль двухразрядного сумматора, включающий этот примитив.
primitive vo'te (major,х, у, z) ;

input х,у,z;
output major;
table
//х у 2 major
1 1? 1;
? 1 1 1;
1 ? 1 1;
0 0 ? 0;
0 ? 0 0;
? 0 0 0;
endtable
endprimitive
module add_2bit ( in l,in2, cin, result, cout) ;
input inl,in2, cin,
output result, cout;
wire [1:0] inl,in2,result;
wire [1:0] carry;
vote tt4 cl (carry[0],inl[0],in2[0],cin);
vote #4 c2 (carry[1],inl[1],in2[1],carry[0]);
assign #4 cout=carry[l];
result[0]=(inl[0] && in2[0] && cin) || carry[0] && (inl[0] || in2[0] ||
cin),
result[l]= inl[l] && in2[l] && carry[0] ||
carry[1] && (inl[l] || in2[l] || carry[0]);
endmodule
Определение UDP последователъностного типа (фактически автомата с двумя

устойчивыми состояниями, т. е. триггера) отличается, прежде всего, тем, что
для выхода вводится дополнительная спецификация, определяющая его как
регистровую переменную в соответствии с общими правилами языка Verilog:
rеg <имя выхода>;
Возможно определение начального состояния автомата за счет включения

оператора вида:
i n i t i a l <имя выхода> = <значение>;
Синтаксис представления таблицы для последовательностного UDP опреде-
лен следующим образом:
<таблица для последовательностного UDР> ::=
table
« <список значений входов>:<исходное состояние>:<состояние перехода>; »
endtable
<состояиив перехода> ::= 0 | 1 | х | -
Состояние и выход имеют одно и то же значение.

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

щий сохранение состояния.
Для примера в листинге 3.57 приведено определение примитива, соответст-
вующего синхронному RS -триггеру с потенциальным управлением (единич-
ный уровень разрешающий). При нулевом сигнале на входе clk, а также
если на обоих информационных входах нулевые сигналы, состояние тригге-
ра не изменяется. Если clk=1, а на информационных входах присутствует
запрещенная комбинация сигналов или неопределенные сигналы, то со-
стояние элемента считается неопределенным.
primitive rsff_sync(q,clk,r,s),
input clk,r,s;
output q; reg q;
table
// clk r s q(t) q(t+l
0 ? ? 7 -;
? 0 0 7 -;
I 0 1 7 1;
1 1 0 7 0;
1 1 1 7 x;
1 ? x 7 x;
1 x ? 7 x;
1 ? X 7 x;
endtable
endprimitive
Для последовательностных UDP с динамическим управлением для одного

из входов, определенного как синхронизирующий, записывается два значе-
ния сигнала в форме (v,w), где v*w и v, w e {0,l,x,b,?}. Это означает,
что изменение выхода происходит после изменения соответствующего сиг-
нала из состояния v в состояние w.
Программа (листинг 3.58) иллюстрирует такую запись. Представлен J -K -
триггер с асинхронным сбросом по входу г (активный низкий уровень) и
переключением нарастающим фронтом сигнала elk.
primitive jkff_r(q, r, clk, j, k ) ;

input clk,r,j,k;
output q; reg q;
initial q=l'bO;
table
// r clk j k q(t) q(t+l)

0 ? 7 7 ? 0;
1 (1?) 7 ? 7 -;
1 (01) 0 0 ? -;
1 (01) 1 0 ? 1;
/
1 (01) 0 1 ? 0;
1 (01) 1 1 l 0;
1 (01) 1 1 0 1 .
J -/
endtable
endpriroitive
3.4. Язык AHDL

3.4.1. Общая характеристика языка
и структура программы
Язык описания аппаратуры Altera HDL (AHDL) был создан фирмой Altera в
1983 году. Компилятор с этого языка интегрирован во все пакеты проекти-
рования фирмы (MAX+PLUS II, Quartus), а также разработки других фирм,
и обеспечивает прямую компиляцию описания в файл конфигурации любых
БИС разработки фирмы, равно как передачу описания в подсистему моде-
лирования и преобразование в описания во входные языки других пакетов [4].
Весьма важным свойством языка, упрощающим создание сложных проек-
тов, является наличие средств, позволяющих легко модифицировать отдель-
ные фрагменты и использовать их в процессе иерархического проектирова-
ния устройства. Следует учитывать, что существенное влияние на конечный
результат проектирования, т. е. на скомпилированный проект, оказывают не
только используемые конструкции языка, но и установленные опции режи-
мов компиляции. Эти опции сохраняются в файле конфигурации, имя кото-
рого совпадает с именем проекта, а расширение обозначается как acf. Такой
файл создается автоматически при открытии проекта, и исходно в нем уста-
новлены опции, принятые в системе по умолчанию. Изменение опций про-
екта в САПР MAX+PLUS II можно осуществлять, используя пункт систем-
ного меню ASSIGN, либо редактор топологии FLOORPLAN EDITOR, a
также путем прямой корректировки конфигурационного файла с помощью
текстового редактора.
Язык AHDL относится к классу приборно -ориентированных языков. Опи-
сание устройств в языках этого класса обеспечивает больший по сравнению
с языками высокого уровня контроль разработчика над создаваемой реали-
зацией. Ряд конструкций языка служат для эффективного использования
архитектурных особенностей микросхем программируемой логики фирмы

Altera. В сущности, язык AHDL является языком структурного описания,
т. е. способом представления набора типовых компонентов и их настроек, а
также связей между ними. Хотя в языке имеются конструкции, которые
"выглядят" как описания поведения, например оператор условия I F -THEN,
оператор выбора CASE, оператор повторения FOR -GENERATE, надо иметь в ви-
ду, что фактически подобные синтаксические конструкции являются описа-
нием определенных структур. Так оператор I F -THEN -ELSE представляет пере-
ключатель, который в зависимости от управляющего сигнала, задаваемого
условием, подключает к своему выходу (выходам) выходы одной из подсхем,
описанных в альтернативных вариантах оператора. Поведенческий аспект
скрыт от проектировщика в моделях компонентов, используемых внутри
системы проектирования на этапе симуляции собранного проекта. При
мысленном сопоставлении AHDL -программе некоторого поведения можно
считать, что операторы языка относятся к классу параллельных операторов,
т. е. выполнение действия, заданного оператором, происходит при любом
изменении операндов другими операторами. При функциональном модели-
ровании предполагается дельта -задержка, а при временном — задержки,
значения которых близки к реальным задержкам в выбранных микросхемах.
Проект в AHDL может быть представлен одним текстовым файлом, содер-

жащим описание проекта (AHDL -программу) и называемым проектным или
логическим модулем (Design File). Иерархические проекты, кроме файла опи-
сания верхнего иерархического уровня (Top -Level Design File), содержат со-
вокупность файлов, представляющих нижние уровни иерархии (Low -Level
Design Files). В этом случае, программы каждого уровня иерархии содержат
ссылки на модули следующего низшего уровня. Допускаются ссылки не
только на проектные модули, описанные в языке AHDL, но и на модули,
представленные в других формах, принятых в САПР MAX+PLUS II и
Quartus (графической форме и других языках). Имя проекта должно совпа-
дать с именем модуля верхнего уровня иерархии.
Программа на языке AHDL должна обязательно содержать две секции —
предпроектную секцию (Subdesign Section), описывающую интерфейс проек-
та, и логическую секцию (Logic Section), описывающую структуру и функ-
ционирование схемы, составляющей собственно проект. Кроме обязатель-
ных секций в начало программы допускается помещать необязательную
секцию заголовка (Title Section). Для легкой идентификации проекта целесо-
образно всегда включать в эту секцию оператор заголовка проекта, а осталь-
ные подсекции использовать в тех случаях, когда этого требует логика фор-
мирования проекта.
Рекомендуемая последовательность секций логического модуля и их назна-
чение представлены в табл. 3.8.
Таблица 3.8. Рекомендуемая последовательность

секций логического модуля и их назначение
№ Наименование Обязат./
не обязат.
Назначение
1 Секция заголовка Не обяз.

(Title Section)
Оператор заголовка Задает собственное имя
проекта (Title Statement) проекту для связывания
с другими проектами
Оператор(ы) включения ' Включает фрагменты заголовка,
(Include Statement) находящиеся в других файлах
Оператор(ы) объявления Объявляет имена и фактические
констант (Constant значения констант
Statement)
Оператор(ы) вычисляемых Объявляет идентификатор
функций (Define Statement) встраиваемой функции и способ
вычисления ее значения
Оператор объявления Объявляет параметры
параметров (Parameter настройки при создании пара -
Statement) метризированных модулей
Оператор(ы) объявления Предъявляет образы
прототипов (Function используемых в данном проекте
Prototype Statement) подпроектов
Оператор опции проекта Определяет трактовку
(Options Statement) двоичного кода в арифмети-
ческих операторах
Оператор(ы) проверки Проверяет корректность
(Assert Statement) конфигурации и выдает
сообщение об ошибке
Секция предпроекта
(Subdesign section)
Заголовок предпроекта Обяз. Определяет порты проекта
Подсекция переменных Не обяз. Присваивает имена внутренним
(Variable Section) узлам проекта, включая связи,
комбинационные схемы,
регистры, автоматы,
встраиваемые модули
Оператор(ы) проверки Не обяз. Проверяет корректность
сообщение об ошибке
№ Наименование Обязат./ Назначение

не обязат.
3 Логическая секция Обяз. Секция включает нижеперечис-
(Logic Section) ленные операторы в произволь-
ном порядке
Оператор умолчания Не обяз. Объявляет значение
(Defaults Statement) переменной, которое она примет
по умолчанию (при отсутствии
явного присвоения)
Логическое уравнение Не обяз. Присваивает значение пере-
(Boolean Equation) менной
Оператор выбора Не обяз. См. разд. 3.4
(Case Statement)
Условный оператор Не обяз. См. разд. 3.4
(If -then Statement)
Оператор повторения Не обяз. Генерирует совокупность одно-
(For Generate Statement) типных модулей
Оператор Не обяз. Воспроизводит одну из альтер-
условной генерации нативных реализаций проекта
(If — Generate Statement) в зависимости от параметров
настройки
Прямой вызов функции Не обяз. Определяет способ
(In -Line Logic Function подключения встраиваемых
Reference) модулей
Оператор таблицы Не обяз. Задает логические функции
(Truth Table Statement) и функции переходов автоматов
в табличной форме
Оператор проверки Не обяз. Проверяет корректность
сообщения об ошибке
3.4.2. Типы данных и выражения.

Оператор присваивания
Как и в других языках, в AHDL определены скалярные и групповые типы
данных. Группой называется совокупность объектов, которые подвергаются
совместному или одинаковому преобразованию.
Определены следующие типы данных: логический, целочисленный, символьный
и перечислимый. Специальных средств декларации типа не предусмотрено —
тип устанавливается по контексту. Отметим, что перечислимый тип приме-

няется только для задания состояния цифровых автоматов. Скалярному
данному соответствует простое имя, которое, как и в других языках, записы-
вается в виде произвольной последовательности цифр и букв, начинающей-
ся с буквы.
Данные символьного и целочисленного типов не могут изменяться в реали-
зованном проекте, и их значения учитываются только на этапе компиляции.
Символы (чаще объединяемые в строки) используются для определения ва-
рианта конфигурации настраиваемых (параметризируемых) модулей, а также
задают содержание выводимых сообщений в операторах проверки. Данные
целочисленного типа служат для задания параметров конфигурации, границ
групповых данных, индексов элементов в группах. Целые числа можно ис-
пользовать для представления групповых логических констант в виде цело-
численного эквивалента соответствующего двоичного кода, однако и этот
случай мы определим как данные логического типа.
Целые числа можно представлять в различных форматах: десятичном, дво-
ичном, восьмеричном и шестнадцатеричном. Десятичный формат записыва-
ется как простая последовательность цифр 0—9. В других форматах после-
довательность разрешенных цифр заключается в двойные кавычки, перед
которыми записывается символ формата. Способы записи чисел сведены
в табл. 3.9.
Таблица 3.9. Способы записи чисел
Формат числа Разрешенные Символ Пример

цифры формата
Десятичный 0 -9 1248
Двоичный 0,1, х В;Ь В"1х001"
Восьмеричный 0 -7 О; о; Q; q 0"705"
Шестнадцатеричный 0 -9,A,B,C,D,E,F Н; h; X; х Н"1АЕ F"
Арифметические данные могут входить в арифметические выражения. Ариф-

метические выражения, кроме типовых операций: сложение '+', вычитание
'—', умножение '*', деление нацело 'DIV' — могут включать специальные
функции, список которых приведен в табл. 3.10. Значения арифметических
выражений вычисляются только на этапе компиляции проекта, а при реали-
зации соответствующие значения рассматриваются как константы. Результат
вычисления арифметического выражения — положительное целое. По умол-
чанию, если при логарифмировании и делении получено дробное значение,
выполняется округление до ближайшего большего целого. Отрицательный
результат заменяется нулевым.
Таблица 3.10. Специальные функции
Название Обозна- Пример Комментарий

чение
Возведение ^ а^2
в степень
Модуль MOD a MOD Ь Остаток отделения
а на b
Двоичный LOG2 LOG2(12 -4)
логарифм
Выбор значения 7; (а<5) ? 3:8 Если выражение
в скобках истинно,
то выбирается первое
значение, иначе
второе
Округление CEIL CEIL(Iog2(156)) = 7
до ближайшего
большего целого
Округление FLOOR FLOORCL5 DIV 4) = 3
до ближайшего
меньшего целого
Логический тип является единственным способом представления сигналов в

проектируемой системе. Данные этого типа (переменные, порты и констан-
ты) могут принимать три значения: GND, соответствующее логическому нулю,
vcc, которое соответствует логической единице, и z — высокоимпедансное
состояние. Состояние z могут принимать только логические переменные,
представляющие выходы буферов с тремя состояниями или двунаправлен-
ные порты. Переменным и портам в соответствующих разделах программы
должны быть сопоставлены имена и спецификации. Спецификация поясня-
ет специфические свойства носителя данных и способ их использования.
Приведем формальное определение синтаксиса разделов, связанных с объ-
явлением констант, портов и переменных.
<оператор объявления константы> ::=
CONSTANT <имя> = <константное_выражение>;
<константное_выражение> ::=
<арифметическое константное выражение>|
<логическое константное выражение>|
<арифметическое константное выражение> ::=
<целое>|<имя_константы>|<арифметическое_выражение>
<логичеокое константное аыражение> ::=<целое> | VCC | GND
<предпроектная свкция> ::=
SUBDESIGN <имя_модуля>
(<имя_порта> «,<имя_порта>»:<спецификация порта>
«;<имя_порта> «,<имя_порта>»:<спецификация порта>»
)
<имя_порта> ::=
<имя>|
<имя>[<граница>..<граница>] Г [<граница>..<граница>] 1
<спецификация порта> ::=
INPUT [ = Оначение по умолчанию> ]
| OUTPUT
| BIDIR [ = Оначение по умолчанию> ]
| MASHINE INPUT I MASHINE OUTPUT
Оначение по умолчания» : := Г =GND | =VCC ]
<граница> ::=<арифметическое константное выражение>
<подсекция переменных> ::=
VARIABLE <имя_переменной> «,<имя_переменной>»:
<спецификация_переменной>;
<«имя_переменной> «,<имя_переменной>»:<спецификация_переменной>;»
«<декларация вхождения подпроекта> »
<имя_первменной> ::=
<имя>
| <имя> <индексное выражение> [ <индексное выражение>]
<индвксноe выражение> :=
[<граница>..<граница>] | []
<спeцификация перемeнной> ::=
NODE I TRI_STATE_NODE | <имя_примитива>
Кдекларация цифрового автомата>
Поясним некоторые введенные конструкции.

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

соответственно, a BIDIR — порт ввода/вывода. К двунаправленному порту
можно подключать только элементы, имеющие высокоимпедансное со-
стояние выхода, а точнее, сопоставить в программе имя порта проекта и
имя порта встраиваемого модуля, имеющего такие свойства. (Подробнее
о встраивании модулей в проект см. в разд. 3.4.7 и 3.4.9). Для скалярных
входных и двунаправленных портов можно определять значение по умолча-
нию. Это значение будет использоваться, если проект включается в проект
высшего уровня иерархии, а соответствующий контакт не задействован.
Порты MASHINE INPUT и MASHINE OUTPUT обеспечивают передачу сигналов
цифровых автоматов между модулями одного иерархического проекта. Про-
ект высшего уровня иерархии таких портов иметь не может.
Переменная, специфицированная как NODE, обычно является выходом ком-
бинационной логической схемы (например одной или нескольких макро-
ячеек), функция которой задается оператором присваивания значения этой
переменной в логической секции. Переменная, специфицированная как
TRI_STATE_NODE, представляет шину, к которой можно подключать компо-
ненты, допускающие высокоимпедансное состояние на выходе. Перемен-
ные, специфицированные как примитивы или вхождения подпроектов, от-
ражают встраиваемые модули как поставляемые с системой проектирования,
так и создаваемые проектировщиком, причем способ их соединения опреде-
ляется в логической секции.
Скалярные логические переменные могут входить в булевские выражения.
Табл. 3.11 содержит список определенных в AHDL двуместных и одномест-
ных булевских операций. Символическое и буквенное обозначение опера-
ций равнодопустимы (эквивалентны). Например, а & !Ь эквивалентно a AND
NOT ь. Важно иметь в виду, что знак !, стоящий перед именем операнда, ин-
вертирует только операнд, а этот же знак, стоящий перед другим знаком
операции (#, & или $), задает инверсию результата соответствующей опера-
ции. Так а !# ь эквивалентно ! (а # Ь). В сложных логических выражениях
сохраняются общепринятые правила старшинства (см. правую колонку
табл. 3.11) и раскрытия скобок. Логическое выражение может быть правой
частью оператора присваивания (в AHDL оператор присваивания обознача-
ется обычным символом равенства =), а также входить как условие в опера-
торах условия.
Таблица 3.11. Список определенных в AHDL

двуместных и одноместных булевских операций
Обозначение Уровень
Название Буквенное Символьное приоритета
Инверсия NOT I 1
И (конъюнкция) AND & 2
Обозначение Уровень
Название Буквенное Символьное приоритета
И -НЕ NAND !& 2

Исключающее ИЛИ XOR $ 4
Равнозначность XNOR !$ 4
ИЛИ (дизъюнкция) OR 1 5
ИЛИ -НЕ NOR !# 5
Для примера рассмотрим программу (листинг 3.59), описывающую модуль,

названный simple. Проект содержит три логических уравнения, одно из
которых формирует внутреннюю переменную с на основе входных данных,
а два других — выходные данные. При реализации в универсальном базисе
(И, ИЛИ, НЕ) потребуется инвертор, два элемента И и один элемент ИЛИ.
Фактически же, компилятор (по возможности) автоматически игнорирует
факторизацию, и, в данном случае, устройство будет реализовано на двух
ячейках типа "четырехвходовая LUT" для семейств класса FLEX, либо двух
макроячейках SUM_OF_PRODUCT для микросхем семейств класса МАХ.
Если модуль simple включается в качестве компонента в другой проект, то
порт b может и не подключаться, при этом используется значение по умол-
чанию, и в таком случае выход out2 будет генерировать константную логи-
ческую единицу.
SUBDESIGN simple
(
аО, al: INPUT;
b: INPUT=VCC;
outl, out2 : OUTPUT;
VARIABLE с : NODE;
BEGIN
c= al & !aO
outl = с & b;
out2 = c#b;
END;
Элементы постоянных групп могут участвовать в логических выражениях

как скаляры. При этом после имени группы в квадратных скобках указыва -
ется индекс элемента. Например, elem[5 -i] представляет пятый справа

элемент группы elem[7. .0]. Индекс может быть представлен числом, цело-
численной константой или переменной, а также арифметическим выраже-
нием. Кроме того, в логическое выражение может входить целая группа или
любая его часть. Это допускается, если разрядности групп, участвующих в
логическом преобразовании, совпадают, а также если в преобразовании уча-
ствуют группа и скалярная переменная. При этом операции выполняются
над парами, имеющими одинаковые относительные позиции в группе, без-
относительно к их индексам. В квадратных скобках после имени группы
указывается диапазон битов, участвующих в преобразовании. Если диапазон
явно не указан, в преобразовании участвует вся группа.
Пусть, например, в разделе переменных определено:
. 2 ] , с [ 4 . . 1 ] , x,y,u,v :node;
Тогда допустимы следующие операторы:

- а[3..0]=с [4..1];
Эквивалентно а [0]=с[1], • а[1]=с[2]; а[2]=с[3]; а[3]=с[4].
- а[2..0]=Ь[5..3] & с[4..2];
эквивалентно а[0]=Ь[3] & с[2]; а[1]=Ь[4] & с[3], а[2]=с[4], а[3] не
изменяется.
- а[ ]=с[ ] & ! Ь [ 5 . . 2 ] ;
Эквивалентно а [0]=b [2] & ! с [ 1 ] ; а[1]=Ь[3] & ! с [ 2 ] , И Т . Д.
- а[ ]= с[ ] tt х;
ЭКВИВАЛЕНТНО а [0 ]=с[1] I x; а[1]=с[2] # х, И Т. Д.
Как уже отмечалось, число может использоваться как сокращенная форма

записи двоичной константной группы. Таким образом:
Ь[5..2]=с[ ] # 9; — эквивалентно b [2 ] =VCC; b[3]=c[2]; b[4]=c[3]; b[5]=VCC;
Число разрядов группы в правой части оператора присваивания (прием-

ника) не обязательно совпадает с разрядностью выражения в левой части
(источника), но оно должно быть кратно числу разрядов источника. Если
это так, то источник повторяется в поле приемника слева направо до запол-
нения поля приемника. Например, присвоение Ь[7..2]= в"01" дает резуль-
т а т ы ? . . 2]= В"010101".
В то же время выражение а[] в с [1. .0] на представленном в примере набо-
ре данных недопустимо, т. к. группы, участвующие в преобразовании, име-
ют некратную разрядность. Ошибкой является также отсутствие индексного
выражения после имени, присвоенного группе. Так на представленном на -
боре данных недопустима запись а=с. Подобное присвоение следует запи-

сывать так: а [] =с [].
Для логических групповых данных кроме "обычных" логических операций
определены арифметические операции и операции сравнения. Операции
сравнения возвращают логический нуль (GND), если условия сравнения не
выполнены, и логическую единицу (vcc) — в противном случае. Арифмети-
ческие операции над группами — инверсия, инкремент, сложение и вычи-
тание — предполагают реализацию арифметических операций над кодами
аргументов по правилам беззнаковой двоичной арифметики, причем по
умолчанию (если не установлена опция OPTIONS BITO=MSB) разряд с наи-
меньшим номером считается младшим.
Примеры. Пусть res, arg1, arg2 — группы одинаковой разрядности, а и с —
скаляры. Тогда допустимы такие операторы:
a=(arg[ ]>arg[ ]) !&с;
res[5..0]=argl[ ] + arg2[ ]; res[]=in[ ] -H"A7";
increm_value[ ]=init_value[]+l.
Кроме одномерных и двумерных групп, определяемых в предпроектной сек-

ции и подсекции переменных и называемых постоянными, программист мо-
жет объединять скалярные переменные и другие постоянные группы во вре-
менные группы (в материалах фирмы Altera — sequential, что переводится
как последовательные). Временная группа не требует декларации и непо-
средственно входит в выражения или является приемником в операторе
присваивания. BNF -форма временной группы имеет вид:
<врвменная_группа> ::=(<имя_переменной> «,<имя_переменной>»)
Временная группа определена только в пределах текущего оператора и объ-

единяет с целью описания одинаковых преобразований несколько логиче-
ских переменных или других групп. Фактически, выполняется операция
конкатенации компонентов. Например, при реализации присвоения
(d,a[2..0])=b[4..1] # (x,y,u,v);
будет получено a[0]=b[l] I v; a[l]=b[2] I u; a[2]=b[3] I y; d=b[4] # x.
3.4.3. Оператор выбора и оператор условия

Оператор условия ( I F -THEN STATEMENT) и оператор выбора (CASE STATEMENT)
по смыслу и даже синтаксически не отличаются от подобных конструкций
языка VHDL (см. разд. 3.2.6). Тем не менее, AHDL предоставляет некоторые
дополнительные возможности.
В операторе I F -THEN условием может быть не только выражение сравнения,
но и любое логическое выражение, дающее скалярный логический резуль-
тат. Так .конструкция I F а & ь THEN эквивалентна I F a&b==vcc THEN, и даже
I F а&b==1 THEN. В последнем случае единица — это, в сущности, констант-

ная группа из одного разряда. Впрочем, на наш взгляд, вторая версия из
приведенных представляется предпочтительной, т. к. обеспечивает "ясность"
прочтения программы.
Другая особенность AHDL — возможность не записывать все альтернатив-
ные варианты. Если какая -либо переменная не определяется ни в одном из
альтернативных вариантов операторов, то при возникновении соответст-
вующих условий эта переменная принимает так называемое базовое значение.
По умолчанию базовое значение — это логический нуль GND для скалярных
переменных и строка нулей для групп. Однако базовое значение может быть
определено также в подсекции умолчания. Указанные особенности иллюст-
рируются программой, представленной листингом 3.60. Если а и ь примут
значение нуля, выход получит значение, заданное в разделе умолчаний. Ес-
ли бы раздел DEFAULTS отсутствовал, то при тех же условиях на выход выда-
вался бы нулевой код.
SUBDESIGN defalt_example
( a,b:INPUT;
е[3..0]:INPUT
с[3..0]:OUTPUT)
BEGIN
DEFAULTS c [ ] = B " l l l l " ;
END DEFAULTS;
if a then c [ ] = e [ ] ;
elsif b then c[]=e[]+ B"1110";
end if;
Использование DEFAULTS позволяет подобным образом сократить запись

оператора CASE, правда, в операторе CASE такое же сокращение дает конст-
рукция "WHEN OTHERS".
Еще один способ сокращения длины записи — использование логических
покрытий. Логическое покрытие определяет совокупность комбинаций аргу-
ментов, на которых логические выражения принимают одинаковое значе-
ние. Для записи логического покрытия используют символ 'х' — неважное
значение (do not care). Запись B"11xx" покрывает комбинации аргументов,
имеющих две единицы в старших разрядах. Использование логического по-
крытия в операторе CASE иллюстрируется описанием приоритетного шифра-
тора, представленным листингом 3.61. Здесь присвоение значения порту
request_exist явно присутствует только в одном из вариантов, который вы-
бирается, если все входы — логические нули. В остальных случаях принима-
ется значение по умолчанию. Присвоение переменной неопределенного
значения (строка priority_levei=B"xx" в рассматриваемом примере) предос -
тавляет компилятору возможность выбрать произвольное значение с целью

оптимизации схемной реализации.
SUBDESIGN priority
( ena:input= V C C ; — разрешение запроса
interupt_request[3..0]: INPUT; — линии входа запроса
priority_level[l..0] : OUTPUT; — код запроса
request_exist: OUTPUT — есть запрос
)
BEGIN
DEFAULTS request_exist=VCC;
END DEFAULTS;
CASE (ena,interupt_request[]) IS
WHEN B"OXXXX",B"10000" => request_exist[]=GND
priority_level[]=B"XX";
WHEN B"11XXX" =>priority_level=B"ll";
WHEN B"101XX" =>priority_level=B"10";
WHEN B"1001X" =>priority_level=B"01";
WHEN B"10001" =>priority_level=B"00";
END CASE;
END;
3.4.4. Таблицы в AHDL

Таблицы истинности часто позволяют компактно представлять логику
функционирования как комбинационных, так и регистровых схем, в том
числе цифровых автоматов. В языке AHDL введен специальный оператор
таблицы (TRUTH TABLE STATEMENT), обеспечивающий возможность описания
нескольких логических функций многих переменных в табличной форме.
<оператор таблицы> : : =
TABLE
<список аргументов> => <список выходов>;
<список значений аргументов>=хсписок результирующих значений>;
«<список значений аргументов> => <список результирующих значений>;>>
END TABLE;
<список аргументов> ::=<аргумент>| «, <аргумент>»
<аргумант> ::=
<имя_порта>I<имя_переменной>
|<состояние автомата>
|<имя встроенного модуля>.<имя порта модуля>
<список выходов> ::=<выход> «, <выход> »
<выход> ::= <имя_порта>|<имя_переменной>|<состояние автомата>
| <имя встроенного модуля>.<имя порта модуля>
<список результирующих эначений> ::=
<константное выражение> «, <константное выражение> »
Каждая строка оператора таблицы, кроме первой, сопоставляет набору зна-

чений аргументов набор результатов. Значения в списках значений записы-
ваются в том же порядке, что и имена данных в списках аргументов и выхо-
дов, в первой строке таблицы, причем значения записываются в форматах,
соответствующих типам переменных в списках. Вопросы включения в таб-
лицы состояний автоматов и портов встроенных модулей рассматриваются
далее. Логический нуль и логическая единица в таблицах записываются
в укороченной форме — как цифра 0 и 1, соответственно. Число строк не
ограничено, хотя, очевидно, не превышает общего числа комбинаций аргу-
ментов. Сокращение длины таблицы обеспечивается использованием базо-
вых значений, а также логических покрытий комбинаций аргументов. При-
менение символов 'х' в разделе результирующих значений разрешает ком-
пилятору для реализации соответствующего условия использовать любое
значение с целью минимизации. В качестве примера запишем оператор таб-
лицы, описывающий такую же логическую функцию, что и оператор CASE
в листинге 3.61 в предыдущем разделе.
TABLE
ena, interupt_request[] => request_exist, priority_level[];
0, В"ХХХХ" => О, В"ХХ";
1, В"0000" => О, В"ХХ";
1, В'ЧХХХ" => 1, В"11";
1, В"01ХХ" => 1, В"10";
1, В"001Х" => 1, В"01";
1, В"0001" => 1, В"00";
END TABLE;
3.4.5. Оператор повторения

Оператор повторения (FOR -GENERATE STATEMENT) в AHDL присутствует только
в одной модификации — с априорно заданным числом повторений. В фак-
тической реализации производится не просто повторение действия как та-
кового, а реализация совокупности единообразно описанных компонентов.
Синтаксис оператора повторения имеет вид:
<оператор повторения>::=
FOR <переменная цикла> IN <диапазон> GENERATE
<оператор> «<оператор»>
END GENERATE;
<диапаэон> ::=<граница> ТО <граница>
Переменная цикла — любое имя, не совпадающее с ключевыми словами

или другими идентификаторами в программе. Переменная цикла не требует
специального объявления и всегда является целой.
Во многих случаях повторяющиеся действия (фрагменты) представимы про-
стыми операторами над группами. Поэтому в AHDL -программах оператор
FOR -GENERATE следует использовать при описании рекуррентных алгоритмов,
когда результаты исполнения некоторых циклов (фактически, выход струк-
туры, сгенерированной на одном из проходов цикла компилятором) исполь-
зуются в качестве исходных данных для последующих циклов.
В листинге 3.62 представлен пример описания узла контроля на четность
входного байта. Для каждого i -го разряда формируется сигнал odd_carry[i+1],
являющийся признаком четности совокупности этого разряда и всех преды-
дущих.
TITLE "odd_checker";
CONSTANT length=8; — число разрядов
( odd_in:INPUT; — вход расширения
data[length -1..0]:INPUT;
odd_result:output
)
VARIABLE odd_carry[length..0]:node;
BEGIN odd_carry[0]=odd_in;
FOR i IN 0 TO length -1 GENERATE
odd_carry[i+1]= odd_carry[i] $ d a t a f i ] ;
END GENERATE;
odd_result=odd_carry[length];
end;
Завершая обзор основных операторов языка AHDL, укажем, что допустимы

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

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

деле деклараций переменных следующим образом:
<Вхождение рвгистра> ::=
<имя> [ [<граница>. .<граница>] ] : <тип триггера>;
<тип триггера> ::=
LATCH ] OFF | DFFE | JKFF | JKFFE I SRFF | SRFFE | TFF | TFFE
Регистровая схема определяется как группа триггеров, т. е. с указанием диа-

пазона индексов.
В табл. 3.12 сведены триггеры, содержащиеся в библиотеке примитивов па-
кета MAX+PLUS II и доступные к использованию в AHDL -программах.
Таблица 3.12, Триггеры, содержащиеся в библиотеке примитивов

пакета MAX+PLUSII
Тип регистра Список контактов
LATCH d, e n a , q
OFF d, clk, clrn, prn, q
DFFE d, clk, c l r n , prn, ena, q
JKFF j,k, clk, c l r n , prn, q
JKFFE j,k, clk, c l r n , prn, ena, q
JKFF s,r, clk, clrn, prn, q
JKFFE s,r, clk, c l r n , prn, ena, q
TFF t, c l k , c l r n , prn, q
TFFE t, clk, c l r n , p r n , ena, q
В таблице, кроме имен триггеров, приведены списки предопределенных

портов, где:
- clk — синхросигнал (определено динамическое управление, причем по-
ложительный фронт активный);
- clrn — асинхронный сброс (активный логический ноль);
- prn - асинхронная установка (активный логический ноль);
- ena — разрешение работы (ena=vcc разрешает запись данных в триггерах
LATCH и разрешает прохождение сигнала elk в остальных типах триг-
геров);
- d , j , k , r , s — информационные входы в соответствии с общепринятым
обозначением информационных входов триггеров [3, 15, 27];
- q — выход триггера.
Функция переходов однозначно задается типом триггера. В логической сек-

ции сигналы на входах триггеров определяются логическими выражениями.
При этом вход представляется как последовательность имени регистра или
триггера и имени контакта (в соответствии с табл. 3.12), разделенных точ-
кой. Если в программе отсутствует присвоение какому -либо из управляю-
щих входов, то по умолчанию считается, что на этот вход подана логическая
единица.
Выходы триггеров, представляемые в форме <имя>,q, могут использоваться
как аргументы в любых логических выражениях. Если выход триггера или
регистра является также и выходом схемы, можно применить два варианта:
или ввести порт со своим именем, а в логической секции выполнить при-
своение порту значения выхода триггера, или объявить одно и то же имя
триггера дважды: сначала в предпроектной секции со спецификацией OUTPUT
и, кроме того, в секции переменных со спецификацией типа триггера.
Указанные правила иллюстрируются программами, приведенными в лис-
тингах 3.63 и 3.64. Модуль, описанный листингом 3.63, представляет вось-
миразрядный регистр с асинхронным сбросом и синхронной загрузкой,
причем загрузка выполняется при единичном сигнале на входе load. Отме-
тим, что отсутствие присвоения значения входу рrn означает, что этот вход
пассивен.
Программа из листинга 3.64 описывает счетчик с тремя состояниями с
асинхронным сбросом, построенный на J -K -триггерах (JKFF). Аналог этой
схемы на дискретных компонентах представлен на рис. 3.25. Отметим, что
практическая реализация в микросхемах фирмы Altera отличается от пред-
ставленной на рисунке. Триггеры типа J -K компилятор преобразует в соот-
ветствующую реализацию на D -триггерах, гарантируя при этом функцио-
нальную совместимость.
Рис. 3.25. Счетчик с тремя состояниями (аналог программы в листинге 3.64)

SUBDESIGN b u r _ r e g SUBDESIGN counts

( c l k , l o a d , r e s e t , d [ 7 . . 0 ] : INPUT; ( clk, reset:INPUT;
q[7..0] : OUTPUT; ql,q2: OUTPUT)
) VARIABLE
VARIABLE ql,q2:jkff;
ff[7..0] : DFFE;
BEGIN BEGIN
f f [ ] . c l k = clk; ql.clk=clk;
ff[].clrn=reset ql.clrn=reset;
ff [].ena = load; q2.clk=clk;
ff[].d = d [ ] ; q2.clrn=reset;
q[] = fffj.q; ql.j=!q2.q;
END; ql.k=!q2.q;
q2.j= ql.q;
q2, k= q2.q;
END;
Нижеприведенные профаммы описывают регистровые устройства, ориенти-

рованные на реализацию арифметических действий с сохранением результа-
тов. Профамма, представленная листингом 3.65, описывает реверсивный
счетчик. По умолчанию его разрядность равна 8 и задана в разделе парамет-
ров. Однако при включении этого модуля в качестве компонента в иерархи-
ческие структуры могут задаваться иные значения (см. разд. 3.4.9). Измене-
ние состояния счетчика выполняется по фронту сигнала clk, если при этом
присутствует входной перенос (carry_in:=vcc), или контакт carry_in вообще
не используется. После переполнения счетчик переходит в нулевое состоя-
ние. Выходной перенос не предусмотрен; в принципе, его роль может ис-
полнять старший разряд счетчика, естественно, с потерей эффективной раз-
рядности.
PARAMETERS
(n=8 — разрядность
);
SUBDESIGN revers_count
( clk: INPUT,
reset, up_down, carry_in : input=VCC;
q[n..O] : OUTPUT
VARIABLE
q[n..0]:dff;
BEGIN
q[].clk=clk & carry_in;
q[].clrn=!reset;
IF up_down==vcc THEN
q[].d=q[].q+1;
ELSE q[].d=q[].q - l ;
END IF;
END;
Программа, представленная в листинге 3.66, описывает накапливающий

сумматор и, на наш взгляд, не требует специальных комментариев.
PARAMETERS (n=8);
SUBDESIGN accum_add
( clk,.reset:INPUT;
data[n -l..0]:INPUT;
sum[n -l..0]: OUTPUT;
overflow : OUTPUT — переполнение
)
VARIABLE
q[n..0]:dff;
BEGIN
q[].clk=clk;
q[].clrn=reset;
q[].d=q[].q+(GND,data[]);
sum[]=q[n - l . . 0 ] . q ;
overflow=q[n]. q;
END;
3.4.7. Монтажная логика и буферные примитивы

Специфический класс встроенных функций языка AHDL — это так назы-
ваемые примитивы буферов. Кроме достаточно универсального модуля TRI,
используемого для представления схем с тремя состояниями на выходе,
имеется ряд "приборно -ориентированных" примитивов, позволяющих вклю-
чать в проект специфические ресурсы микросхем программируемой логики
фирмы Altera.
В общем случае, монтажная логика описывается путем записи в профамме
нескольких операторов, присваивающих значение одной и той же перемен-
ной или фуппе. Такое присвоение интерпретируется как объединение по
логике ИЛИ логических выражений, соответствующих правым частям этих
операторов.
Так, совокупность присвоений

Wired_or= select[1] & a l ;
Wired_or= select[2] & a2:
Wired_or= select[3] & a3;
воспроизводит функции монтажного ИЛИ для трех сигналов al, a2, аЗ, вы-
бираемых кодом select [ ], и эквивалентна
Wired_or=select[l] & al I Wired_or # select[2] & a2 I select[3] & a3;
Заметим, что если ни один из сигналов не выбран, принимается базовое

значение, т. е. GND.
Если какой -либо драйвер дает высокоимпедансное состояние, то соответст-
вующее присвоение игнорируется, за исключением случая, когда все драй-
веры в высокоимпедансном состоянии — тогда выход принимает значение
'z' (это правило подобно правилам преобразования, установленном для дан-
ных подтипа STD_LOGIC в языке VHDL). Высокоимпедансное состояние не
может быть присвоено сигналу через "обычное" логическое выражение или
таблицу. Это состояние могут принимать только выходы примитивов TRI,
OPDRN или порт, специфицированный как BIDIR.
Примитив TRI имеет два входных порта и один выходной. Первый вход
IN — вход данных, второй ОЕ — управляющий. При логической единице на
входе ОЕ — выход повторяет вход данных, в противном случае находится в
высокоимпедансном состоянии. Примитив OPDRN имеет один вход и один
выход. Если на вход поступает логический нуль, то на выходе присутствует
логический нуль, в противном случае выход находится в высокоимпеданс-
ном состоянии.
Программа (листинг 3.67) иллюстрирует подключение двух источников
(регистры v[0][] и v[1] []) на общий выход через буферы с тремя состоя-
ниями выхода под управлением кода select[]. Обратите внимание на то,
что фактически присвоение значения переменной io в программе выполня-
ется дважды, и, кроме того, допустимы присвоения значения соответствую-
щему сигналу в модуле высшего уровня иерархии.
SUBDESIGN Double_bus_reg
(
clk : INPUT;
load[l..0],select[l..0] : INPUT;
io[7..0] : BIDIR;
)
VARIABLE v[l..0][7..0]:NODE; — два восьмиразрядных регистра
W[l..0][7..0]:TRI; — два трехстабильных восьмиразрядных буфера
BEGIN
FOR j IN 0 ТО 1 GENERATE
FOR i IN 0 ТО 7 GENERATE
v [ j ] [ i ] = D F F ( i o [ i ] , clk, load[j],);
w[j][i].oe=select[j];— каждый буфер управляется своим сигналом
— разрешения
w[j][i].in=v[j][i]; — и имеет свой вход
i o [ i ] = w [ j ] [ i j . o u t ; — здесь представлено по два присвоения значения

— каждому биту выходного порта от одного из двух буферов.
END GENERATE;
END GENERATE;
END;
Замечание
Здесь для описания подключения регистров использована конструкция "In -Line -
Function Reference" (вызов функции в строке) — подробнее об этом см. разд. 3.4.9.
Примитивы CARRY и CASCADE (в языке — соответствующие функции) явно

указывают компилятору на необходимость использования специфических
ресурсов микросхем семейств FLEX и APEX — цепочечного логического
переноса и логики прямой связи смежных элементов [4, 31]. Применение
этих ресурсов может обеспечить уменьшение времени задержки в логиче-
ских схемах, реализованных на основе последовательной декомпозиции
логических выражений, а также уменьшить затраты коммутационных ресур-
сов микросхемы. Хотя синтаксически оба примитива имеют один формаль-
ный входной параметр и возвращают один результат, в качестве фактиче-
ского параметра этих функций можно использовать логические выражения
и таким образом определять сравнительно сложную логику связи смежных
макроячеек.
Фактический параметр примитива CASCADE обязательно записывается в фор-
ме логической операции И или ИЛИ, один из операндов которой это кон-
станта или выход другого примитива CASCADE, а второй операнд — про-
извольная логическая функция. Возвращаемое значение функции CASCADE
присваивается переменной типа NODE, которая может стать аргументом сле-
дующего примитива CASCADE или использоваться в одном (и только одном)
логическом выражении в операторе присваивания. Во втором случае эта пе-
ременная должна объединяться по логике И либо ИЛИ с произвольной ло-
гической функцией для формирования сигнала. В БИС семейств FLEX та-
кая запись интерпретируется структурой, показанной на рис. 3.26. Здесь
представлены две макроячейки, объединенные через каскадирующий буфер.
Узел каскадирования, обозначенный С, в зависимости от записи фактиче-
ского параметра примитива CASCADE выполняет операцию И либо ИЛИ, а
LUT реализует произвольную функцию четырех аргументов. Принцип ис-

пользования примитива CASCADE иллюстрируется программой (листинг 3.68),
которая представляет узел проверки двух шестнадцатиразрядных кодов на
равенство. Несовпадение любой пары одноименных битов дает логическую
единицу, распространяющуюся по цепочке каскадированных макроячеек.
CascOUT
Рис. 3.26. Пример каскадирования макроячеек
SUBDESIGN comp_casc
( а[15..0],Ь[15..0]:INPUT;
result:OUTPUT;
)
VARIABLE t e m p [ 7 . . 0 ] : NODE;
BEGIN
temp[0]=GND;
FOR j IN О ТО б GENERATE
tertptj+11 - cascade* (a[2*j] $ b [ 2 * j ] )
f (a[2*j+l] $ b [ 2 * j + l ] ) # temp[j]),
END GENERATE;
r e s u l t = temp[7]#(a[14] $
tt (a[15] $ b [ 1 5 ] ) ;
END;
Глава 3. Языки описания дискретных устройств _ 489
Логическое выражение, используемое как формальный параметр примитива

CARRY, может содержать произвольную логическую функцию трех перемен-
ных, одна из которых является выходом другого, следующего в цепочке,
примитива CARRY. Другая функция тех же трех переменных может использо-
ваться как независимый выход. Наиболее часто логика CARRY служит для
создания арифметических устройств. Любой i -й ячейке такой цепочки сле-
дует сопоставить оператор:
Outi - .d = F1i (ai, b, с,); ci+l = CARRY (F2i (ai ,bi ,c,)); i = (0, n -1);
со = const,
где F1i и F2I — логические функции, реализуемые первой и второй настраи-

ваемыми логическими схемами LUT соответствующей макроячейки.
Примитивы LCELL и SOFT служат для указания компилятору на необходи-
мость или возможность включения макроячеек в структуру реализованного
Вызов функции LCELL гарантирует, что выражение, определяющее фактиче-
ский параметр, будет воспроизводиться отдельно выделенной макроячейкой.
Например, выражение
х= а & b t с & d;
и выражение
х= LCELL ( а & b) t LCELL ( с & d) ;
реализуют одну и ту же функцию. Но первая воспроизводит ее на одной

макроячейке, а вторая на трех (два элемента И и один ИЛИ). Явное выде-
ление части выражения примитивом LCELL позволяет наблюдать результат
реализации соответствующей подфункции в сеансе моделирования. Дело
в том, что если даже объявить вспомогательную переменную для представ-
ления части логического выражения, но записать ее формирование с по-
мощью "обычного" присвоения, а не с использованием примитива LCELL, то
в проекте такая переменная может "исчезнуть" в результате поглощения в
другом выражении. Явная декомпозиция и использование LCELL могут быть
полезны также для выравнивания задержек распространения сигналов по
разным путям в схеме. Правда, этой возможностью следует пользоваться
весьма осторожно, т. к. время распространения зависит не только и не
столько от числа ячеек в цепи передачи, сколько от расположения логиче-
ских ячеек и распространения сигналов по цепям связи.
Примитив SOFT подобен LCELL, но предоставляет компилятору возможность
использовать или не использовать выделенную ячейку для реализации логи-
ческого выражения, являющегося фактическим параметром функции LCELL.
Это в некоторой степени рекомендует компилятору способ декомпозиции
сложных выражений, если такая декомпозиция потребуется. Кроме того,

присвоение вида
<переменная>= SOFT(<выражение>)
делает переменную в правой части оператора наблюдаемой в сеансах моде-

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

В AHDL цифровой автомат определен как переменная перечислимого типа.
Имя автомата и список допустимых значений этой переменной (состояний
автомата) определяются в разделе переменных:
•(декларация цифрового автомата> ::=
<Имя_автомата>: MACHINE [ OF BITS (<бит состояния> «,<бит состояния>») ]
WITH STATES (<список состояний>);
<список состояний> ::=
<Имя состояния> [ = <код состояния> ]
«,<имя состояния> [ =<код состояния> ] »
<Имя состояния> ::=<идентификатор>
У любого автомата по умолчанию определены три управляющих входа:

- <имя_автомата>. reset — подача логической единицы на этот вход безус-
ловно переводит автомат в исходное состояние, т. е. первое из перечис-
ленных в списке состояний;
- <имя_автомата>.с1k — автомат может изменять свое состояние по поло-
жительному фронту этого сигнала в соответствии с определенной в логи-
ческой секции функции переходов;
- <имя_автомата>. еnа — сигнал разрешения работы; изменение состояния
(кроме сброса) может происходить только при единичном сигнале на
входе епа. Если вход не используется, переключение автомата разрешено.
Число состояний определяется алгоритмом работы и выполняется на этапе
содержательного представления проекта. Каждому состоянию присваивается
уникальное имя. Задание кода состояния не обязательно. Отметим, что ме-
тодические материалы фирмы Altera [31] рекомендуют использовать сокра-
щенную форму (без явного присвоения состояниям кодов в списке состоя-
ний и использования ключевого слова OF BITS), предоставляя назначение
кодов состояния компилятору пакета MAX+PLUS II. Полагают, что автома-
тическое назначение состояний обеспечит лучшую оптимизацию проекта
в соответствии выбранным разработчиком критериями качества. В таком

случае влияние разработчика на выбор способа кодирования реализуется
путем задания опций проекта в системе MAX+PLUS II. Может быть задано
либо двоичное кодирование состояний, либо кодирование по принципу
"одно состояние — один бит". Двоичное кодирование обеспечивает умень-
шение числа триггеров в регистровом блоке автомата, а кодирование "одно
состояние — один бит" — упрощение логической части схемы. По умолча-
нию для микросхем семейств МАХ используется первый способ (двоичное
кодирование), а для семейств FLEX — второй.
Функция переходов задается набором операторов, присваивающих перемен-
ной, представляющей автомат, значения (идентификаторов состояний) из
числа объявленных в списке состояний. При этом могут использоваться и
логические выражения, операторы I F -THEN, CASE, а также оператор таблицы
и их сочетания.
В языке AHDL входы и выходы — это обязательно логические переменные
(AHDL, в отличие от VHDL, не допускает объявления входов и выходов как
данных перечислимого типа, но, в отличие от Verilog HDL, в нем возможно
и даже рекомендуется задавать набор состояний их именами, а не кодами).
Описание автоматов Мура и автоматов Мили с асинхронными выходами
совпадают по форме и отличаются только логическими соотношениями,
задающими функции выходов. В автоматах Мура выход зависит только от
состояния, а в автоматах Мили и от входа. Для представления автомата Ми-
ли с синхронизируемыми выходами следует его выходные переменные спе-
цифицировать как триггеры, а на входы синхронизации и установки этого
"дополнительного" регистра подать те же сигналы начальной установки и
синхронизации, что и на остальные управляющие входы автомата. В лис-
тинге 3.69 приведено описание автомата Мили, заданного графом переходов
(рис. 3.27), с использованием оператора таблицы.
В ряде работ, в том числе [3] и материалах фирмы Altera, автомат Мили с
асинхронными выходами назван просто "автоматом Мили", каноническая вер-
сия автомата Мили не рассматривается, да и автомат Мура определен иначе,
чем принято здесь. Авторы пользуются классификацией автоматов, введенной
в работах [15, 24], и не вправе обсуждать терминологию в пределах данной
книги, но обращают внимание читателя на возможные разночтения.
SUDDESIGN my_meal
( clock, r e s e t , x i n : INPUT;
y [ l . . 0 ] : OUTPUT)
VARIABLE
meal: MACHINE WITH STATES
(sO,sl,s2);
y[l..0]: dff; — * * *
BEGIN
meal.reset=!reset;
meal.clk=clock;
y[].clrn= !reset;
y[].clk=clock;
TABLE
meal, xin => meal,
sO, 0 => sO, B"00"
sO, 1 => si, B"01"
si, 0 => sO, B"01"
si, 1 => s2, B"10"
s2, 0 => s2, B"01"
s2, 1 => si, B"10"
END TABLE;
END;
1/01
0/00
1/10
0/01
Рис. 3.27. Граф переходов и выходов автомата Мили (пример)
Рис. 3.28 иллюстрирует способ реализации этого автомата при компиляции

в микросхемы семейства FLEX (принято унитарное кодирование состояний)
и является расшифровкой файла отчета результата компиляции в системе
MAX+PLUS II. Компилятор назначил такие коды состояний: so = B"000",
si = в"110", s2 = в"101". Функции логики синтезированы в форме:
F1 = xin & m2 # !xin & ml;
F2 = xin & ml # !xin & m3;
F3 = xin & m2 # !m2 & m3;
F4 = xin & m2 # !xin &ml;
F5 = xin & m3 # !xin &(ml # m2);
Если из программы исключить строку, отмеченную комментарием "***", то

получим автомат Мили с асинхронными выходами, в котором выходы реа-
лизуются комбинационной логикой.
Рис. 3.28. Реализация автомата по листингу 3.69 в микросхемах типа FLEX10K
В листинге 3.70 представлена программа, интерпретирующая автомат Мура,

заданный отмеченной таблицей переходов (см. табл. 3.6). Здесь вход и выход
закодированы одним битом каждый, причем ХО и YO представлены логиче-
ским нулем, а X1 и Y1 — логической единицей.
SUBDESIGN my_moor3
( clock, r e s e t , v:INPUT;
у: OUTPUT)
VARIABLE
moor: machine with
states(SO,S1,S2);
BEGIN
moor.reset=reset;
moor.clk=clock;
CASE moor IS
WHEN s0=> IF v = g n d THEN moor= s0;
ELSE moor= s i ;
END I F ;
WHEN sl=> IF v = g n d THEN moor= s1;
ELSE moor= s 2 ;
END I F ;
WHEN s2=> IF v==gnd THEN moor= sO;
ELSE moor= s1;
END IF;
END CASE;
IF moor=sl THEN y=GND;
ELSE y=VCC;
END IF;
END;
Явное кодирование состояний разработчиком, как отмечено, рассматривает-

ся в рекомендациях фирмы Altera как вспомогательная опция. В частности,
это может быть полезно, если выходы регистра состояний автомата непо-
средственно используются как выходные сигналы, т. е. реализуется автомат
Мура без выходной логики. Биты кода состояний именуются и могут ис-
пользоваться в качестве аргументов логических выражений логической сек-
ции. Кроме того, допустимо бит кода состояния использовать как выход
проекта. В этом случае имя бита объявляется дважды — при декларации
автомата и декларации порта. Интересно, что возможно определить число
битов состояния, меньше необходимого для присвоения кода всем состоя-
ниям. В этом случае объявленные биты будут "привязаны" к коду состояния,
остальные же произвольно доопределятся компилятором.
Программа (листинг 3.71) интерпретирует тот же автомат, что и программа
(листинг 3.70), но здесь использовано явное задание одного из двух битов
кода состояния, а также табличное представление функции переходов.
SUBDESIGN my_moor3a
( clock, reset, v:INPUT;
z: OUTPUT)
VARIABLE
moor: machine of bits (z)
with states(sO= B"l",
Sl= B"0",
S2— В Т };
BEGIN
moor.reset=reset;
moor.clk=clock;
TABLE
moor, v => moor;
sO, 0 => sO;
sO, 1 => s1;
s1, 0 => s1;
s1, 1 => s2;
s2, 0 => sO;
s2, 1 => s1;
END TABLE;
END;
В приведенных примерах подключение автомата в сложные проекты пред-

полагается путем передачи через порты сигналов. Используются специфи-
кации портов INPUT и OUTPUT. Кроме того, AHDL позволяет непосредственно
экспортировать и импортировать состояния автоматов. Тогда один из портов
модуля -источника, представляющего управляющий автомат, специфициру-
ется как MACHINE OUTPUT, а порт модуля -приемника — как MACHINE INPUT.
Пример иерархического проекта, один из модулей которого экспортирует,
а другой импортирует состояние автомата, рассмотрен далее.
3.4.9. Иерархическое проектирование в AHDL

Любой проектный модуль может использоваться в качестве компонента в
другом проекте. Для этого текст описания модуля верхнего уровня иерархии
должен содержать ссылку на прототип включаемого модуля (подпроекта) и
операторы, описывающие соединения включаемого модуля с прочими ком-
понентами проекта. Ссылка в форме записи оператора объявления прототи-
па (Function Prototype Statement) может содержаться либо непосредственно
в секции заголовка программы, либо в специальном файле. Такой "подклю-
чаемый" файл обычно имеет расширение inc и создается в тех случаях, когда
несколько проектов содержат сходные разделы в секции заголовка (Tytle
Section).
Подлючаемый файл может создаваться с помощью обычных текстовых ре-

дакторов. Кроме того, в системе MAX+PLUS II включаемый файл с декла-
рацией прототипа любого проектного модуля может создаваться автоматиче-
ски. Достаточно, имея в окне редактора системы текст описания этого мо-
дуля, вызвать к исполнению команду Create Default Include File меню File.
Имя создаваемого в этом случае подключаемого файла совпадает с именем
SUBDESIGN включаемого проектного модуля и, соответственно, с именем тек-
стового файла, содержащего описание этого модуля.
Для доступа к информации, заключенной в подключаемом файле, модуль
высшего уровня иерархии должен содержать оператор включения (Include
Statement) файла, записываемый в форме:
<опвратор включения> :: =
INCLUDE "[ <путь к файлу> ] <имя подключаемого файла>.inс";
Текст подключаемых файлов может содержать любой набор операторов, до-

пустимых в секции заголовка проекта, в том числе объявление прототипа.
Этот текст как бы замещает при компиляции оператор включения. Путь к
файлу — традиционная для DOS запись локализации файла в системе.
В общем случае синтаксис оператора объявления прототипа имеет вид:
<оператор объявления прототипа> ::=
FUNCTION <имя подпроекта> ( <список входов>)
[ WITH ( <список параметров>)]
RETURNS ( <список выходов>);
Список входов содержит имена портов, содержащихся в предпроектной

секции прототипа и специфицированных как INPUT или MACHINE INPUT, спи-
сок выходов содержит имена портов, специфицированных в описании про-
тотипа как OUTPUT, BIDIR или MACHINE OUTPUT. Список параметров содержит
имена, содержащиеся в разделе PARAMETERS текстового файла, описывающего
прототип. Имена входов, выходов и параметров в декларации прототипа
точно совпадают с именами соответствующих данных в программе, описы-
вающей модуль -прототип, и заносятся в списки через запятые, причем по-
рядок записи в списках не имеет значения. Например, если в проект вклю-
чается модуль accum_add, представленный программой (листинг 3.66), следу-
ет включить в текст описания проекта декларацию прототипа (или оператор
включения файла, содержащего такую декларацию) следующего вида:
FUNCTION accum_add (clk, r e s e t , d a t a [ ( n - 1 } . . 0 ] )
WITH (n)
RETURNS (sum[(n - 1 ) . . 0 ] , overflow);
Для модулей, поставляемых со стандартной библиотекой системы

MAX+PLUS II, в системе присутствуют соответствующие подключаемые
файлы, доступные к использованию в любых проектах, выполняемых в этой

среде. Оператор включения такого файла в программе, использующей биб-
лиотечный модуль, обязателен, хотя путь можно не указывать. Прототипы
примитивов (триггеров, буферных схем) автоматически подключаются к лю-
бому проекту и дополнительной декларации не требуют.
Каждое конкретное использование некоторого компонента называют вхож-
дением. Конкретизация соединений вхождения, а при необходимости также
и параметров настройки, возможно двумя способами: через использование
декларации вхождения (Instance Declaration) или через прямой вызов функции
(In -Line -Function Reference).
Декларация вхождения размещается в подсекции переменных, т. е. здесь
каждому встроенному модулю присваивается собственное имя и объявляется
способ его реализации — имя функции прототипа и значения параметров
настройки. BNF -форма декларации вхождения имеет вид:
<декларации вхождения подпроектга (AHDL) > :: =
<Имя вхождения> «,<имя вхождения>»:<имя функции>
[ WITH (<имя параметра> = <значение>
«,<имя параметра> = <значение>») ]
Если для параметризованного модуля в декларации вхождения отсутствует

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

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

торых представлены данным оператором. Индексное выражение в имени
порта прототипа должно присутствовать, если порт прототипа является
группой. Такое индексное выражение определяет, какие разряды или какой
из разрядов группы определяются данным оператором.
Использования Instance Declaration иллюстрируется программой, озаглав-
ленной "two register example" (листинг 3.72). Проект содержит два регист-
ра -защелки (lpm_latch), объединенных в группу reg[1..0] и вызываемых
из библиотеки параметризованных модулей системы MAX+PLUS II. Каж-
дый регистр загружается с общего входа din по своему синхросигналу. Вы-
ход формируется как результат побитового сравнения содержимого регист-
ров в обратном порядке, т. е. старший разряд одного регистра сравнивается
с младшим разрядом другого.
TITLE "two register example";

FUNCTION lpm_latch (data[LPM_WIDTH - 1 . . 0 ] , — входной код
gate, — сигнал разрешения записи
aclr, aset, aconst) — вспомогательные входы
WITH (LPM_WIDTH, LPM_AVALUE)
RETURNS (q[LPM_WIDTH -l..0]); — выходные данные
PARAMETERS (n=8);
Subdesign double_reg
(loadO,loadl,reset:input;
din[n -1..0]: input;
eq [n -1..0]:output
VARIABLE reg[1..0] : lpm_latch WITH (LPM_WIDTH=n);

BEGIN
reg[0].data[]=din[];
reg[0].gate=load0;
reg[l].data[]=din[];
reg[l].gate=load1;
reg[].aclr=reset;
FOR i IN 0 to n -1 GENERATE
Eq[i]= regfl].q[i] !# regfO].q[n -l - l ] ;
END GENERATE;
END;
Другой способ включения модулей в иерархический проект называют пря-

мым вызовом функции (In -Line -Function Reference). Такой вызов не требует
декларации вхождений в секции переменных и во многих случаях обеспечи-
вает более компактную запись. Вызов записывается индивидуально для каж -
дого вхождения и размещается в логической секции. Оператор вызова имеет

синтаксис:
<прямой вызов фунхции> ::=
<выходные цепи> = <имя функции> (<список соответствий входов>)
[ WITH (<Список соответствий параметров>)]
[ RETURNS (<список соответствий выходов>]
<входные цвпи> ::= <имя переменной>
| (<имя переменной> «,<имя переменной>»
<соофветствиe входа> : := [<имя входного порта>=] <имя переменной>
<соответствие параматра> : : = [ . <имя параметра>= ] <константа>
<соответствие выхода> ::= . <имя выходного порта>
Уточним, что в случаях, когда функция возвращает несколько значений,
фактические переменные в левой части оператора присваивания записыва-
ются как временная группа — в круглых скобках, разделенные запятыми.
Все списки в рассматриваемом контексте записываются как последователь-
ность элементов списка, разделенных запятыми. Укороченные формы запи-
си списков соответствии предполагают позиционное сопоставление факти-
ческих и формальных параметров функций, а полные — сопоставление по
имени.
Позиционное сопоставление требует точного соответствия порядка следова-
ния имен и параметров в списках порядку их следования в декларации про-
тотипа. Если какой -либо вход или параметр не используется или использу-
ется значение по умолчанию, соответствующая позиция в списке отмечается
как пустая. То же касается описания входных цепей. При сопоставлении по
имени порядок записи не имеет значения, важно лишь совпадение имени
формального параметра с именем, указанным в декларации прототипа.
Разные способы прямого вызова непараметризированных модулей иллюст-
рируются программой, представляющей проект MACRO (листинг 3.73). Проект
содержит два четырехразрядных счетчика, первый запускается входным сиг-
налом clk, а второй — сигналом переполнения первого. К выходу второго
счетчика подключен дешифратор. Списки входов и выходов первого счетчи-
ка и дешифратора представлены с использованием сопоставления по имени,
а второго счетчика — через позиционное сопоставление. Отметим, что в
этом примере для декларации прототипа использованы библиотечные под-
ключаемые файлы, но в тексте программы декларация прототипа 4 count
воспроизведена для лучшего ее понимания как комментарии.
INCLUDE "4count";
INCLUDE "16dmux";
—FUNCTION 4count (clk, clrn, setn, Idn, cin, dnup, d, c, b, a)
—RETURNS (qd, qc, qb, qa, cout);
—FUNCTION 16dmux (d, с, b, a)

—RETURNS ( q n [ 1 5 . . 0 J ) ;
SUBDESIGN macro
(
clkl : INPUT;
out[15..0] : OUTPUT;
)
VARIABLE
ql[3..0], q2[3..0] : NODE;
carryl:node;
BEGIN
(ql[3..0]/carry)= 4count (.clk=clk,.dnup= GND)
returns (.qd,.qc,.qb,.qa,.cout);
(q2[3..0],) = 4count (carryl,,,,, GND,,,,);
out[15..0]=16dmux(.(d,c,b,a)=q[3..0]);
END;
Для иллюстрации задания параметров модулей рассмотрим прямой вызов

модуля ipm_add_sub (настраиваемый сумматор -вычитатель) из библиотеки
параметризованных модулей системы MAX+PLUS И. Прототип функции
для этого модуля имеет вид:
FUNCTION lpm_add_sub (cin, dataa[LPM_WIDTH -1..0], datab[LPM_WIDTH -1..0],

add_sub, clock, aclr)
WITH (LPM_WIDTH, LPM_REPRESENTATION, LPM_DIRECTION, ONE_INPUT_IS_CONSTANT,
LPM_PIPELINE, MAXIMIZE_SPEED)
RETURNS (result[LPM_WIDTH -1..0], cout, overflow);
Пусть на его основе строится восьмиразрядный сумматор в беззнаковом

формате, причем его входы и выходы объявлены в проекте как переменные.
Тогда прямой вызов с использованием списков с сопоставлением по имени
будет иметь вид:
(sum[],cout)=lpm_add_sub (.сin=gnd, . d a t a a [ ] = а [ ] , . d a t a b [ ] = b )
WITH (LPM_WIDTH=8, LPM_REPRESENTATION="UNSIGNED", LPM_DIRECTION="ADD")
RETURNS(.result[],.cout);
Вызов функции при тех же условиях, но с позиционным сопоставлением,

запишется так:
(SUM[],cout,)=lpm_add_sub (gnd, a [ ] , b [ ] , , , )
WITH (8, "UNSIGNED", "ADD",,,);
Пример описания иерархического проекта, в котором передача информа-

ции между модулями осуществляется через порты MACHINE OUTPUT
и MACHINE INPUT представлен программами mult16_l6 (листинг 3.74),
part_mult (листинг 3.75) и mult_contr (листинг 3.76). Проект реализует

умножение шестнадцатиразрядных операндов с выдачей 32 -разрядного
результата. Используется последовательное умножение полуслов входных
аргументов и накопление взвешенной суммы частичных произведений в со-
ответствии с алгоритмом
OUT[31..0]= in_a[7..0]xin_b[7..0] +(in_a[7..0]xm_b[15..8]+

+in_a[15..8]xin_b[7..0])x28+
+(in_a[15..8]xm_b[15..8])x216.
Здесь используется традиционное при построении операционных устройств
разделение на блоки — устройство управления, описанное программой
mult_contr, и операционный блок part_mult. Устройство управления после
сигнала s t a r t последовательно проходит четыре состояния: STEP1, STEP2,
SТЕРЗ и STEP4, каждому их которых соответствует определенная фаза вычис-
лительного алгоритма, после чего возвращается в исходное состояние IDLE.
Операционный блок принимает сигнал состояния, и в зависимости от фазы
цикла вычислений, коммутирует входные полуслова на соответствующие
входы встроенного параллельного комбинационного умножителя. В качестве
умножителя использован библиотечный модуль LPM_MULT из библиотеки па-
раметризованных модулей САПР MAX+PLUS П. Выходной коммутатор
операционного блока позиционирует частичные произведения в разрядной
сетке результата в зависимости от фазы цикла вычислений. В программе
верхнего иерархического уровня mult16_16 декларируются включаемые мо-
дули и переменные, обеспечивающие связи между ними. В том числе вво-
дится переменная, представляющая состояние автомата в устройстве управ-
ления и специфицируемая ключевым словом MACHINE. Кроме того, програм-
ма mu1t16_16 содержит описание накапливающего сумматора и триггера
готовности ready. Накапливающий сумматор, выход которого является вы-
ходом устройства, представлен логическим оператором.
Отметим, что автомат меняет свое состояние по положительному фронту
синхросигнала, результат на выходе блока part_muit появится с задержкой
относительно этого фронта, складывающейся из задержки автомата, комму-
таторов и параллельного умножителя. Чтобы код на входе накапливающего
сумматора успел сформироваться к моменту фиксации в нем суммы, сумма -
гор синхронизируется отрицательным фронтом тактового сигнала.
INCLUDE "mult_contr,inc";
INCLUDE "partjnult.inc";
SUBDESIGN mult16_16
( clk,reset,start: INPUT;
in a[15..0],in b[15..0]: INPUT; — входные данные
out[31..0]: OUTPUT; — произведение
ready: OUTPUT — готовность результата
)
VARIABLE result[31..0]:dffe;
ready: dff;
busy: NODE;
controle:MACHINE; — декларация "внешнего" автомата
BEGIN
(busy,controle)=mult_contr (clk, reset, start); — вхождение автомата
result[].d=result[].q+part_mult (in_b[],in_a[],controle);—накопление
result[].ena=busy; — работа/ожидание
result[].clk=!clk;
out[]=result[];
ready.clk=busy; — триггер готовности данных
ready. d= VCC;
ready.clrn=start;
END;
INCLUDE "lpm_imlt.inc";
CONSTANT Z_code= b"00000000";
SUBDESIGN part_mult
(inl[15..0],in2[15..0]:INPUT;
controle:MACHINE INPUT;
p_m[31..0] : OUTPUT) — частичное произведение
VARIABLE a[7..0],b[7..0],c[15..0]:NODE;
BEGIN
c[]=lpm_mult (.dataa[]=a[],.datab[]=b[])
WITH (LPM_WIDTHA=8, LPM_WIDTHB=8, LPM_WIDTHP=16,LPM_WIDTHS=16);
CASE controle IS
WHEN stepl => a[]=inl[7..0];b[]=in2[7..0]; — умножение
— младших байтов
p_m[]=(z_code,z_code,c[]); — размещение в младших разрядах
— результата
WHEN step2 => a[]=inl[15..8];b[]=in2[7..0]; — перекрестное
— умножение
p_rti[] = (z_code,c[] ,z_code); — размещение в средних разрядах
WHEN step3 => a[]=inl[7..0];b[]=in2[15..8]; — перекрестное
— умножение
p_m[]=(z_code,с[],z_code);
WHEN step4 => a []= i n l [15 ..8 ];b []= i n 2[ 1 5. . 8 ] ; — умножение
— старших байтов
Глава 3. Языки описания дискретных* устройств 503
p_m[]=(c[],z_code,z_code); — размещение в старших разрядах
END CASE;
END;
SUBDESIGN mult_contr
(clk,reset,start: INPUT;
busy: OUTPUT;
controle: MACHINE OUTPUT;
)
VARIABLE Int_state:MACHINE WITH STATES
(idle,stepll,step2,step3,step4);
BEGIN
int_state.clk=clk;
int_state.reset=reset;
controle=int_state;
TABLE
int_state, start=> int_state, busy;
idle , 0 => idle, 0;
idle , 1 => STEP1, 0;
stepl, x => step2, 1;
step2, x => step3, 1;
step3, x => step4, 1;
step4, x => idle, 1;
END TABLE;
END;
В приведенных выше программах неоднократно использовались параметри-

зованные модули, поставляемые с библиотеками САПР MAX+PLUS II.
А можно ли создать собственный параметризованный модуль? В принципе,
да. Но надо иметь в виду трудозатраты на создание параметризованного мо-
дуля и на возможные модификации исходного текста описания. Использо-
вание параметров количественного типа, например разрядности данных, не
требует особых затрат. Намного сложнее предусмотреть и описать возмож-
ные модификации структуры и алгоритма функционирования, в том числе
контроль корректности задания конфигурации при вызове описания из
других модулей в иерархических проектах. Во многих случаях разработка
параметризованной версии оказывается неоправданной. Тем не менее, рас-
смотрим некоторые особенности создания параметризованных модулей.
Параметризованный модуль, кроме обязательных предпроектной и логиче-
ской секций, содержит оператор объявления параметров, синтаксис кото-
рого определен как:
<оператор объявления параметров> ::=
PARAMETERS (<имя> [ Оначение по умолчанию> ]
«,<имя> [ Оначение по умолчанию> ] ») ;
<Оначение по умолчанию> ::=<строка> | <выражение>
Параметры внутри проектируемого модуля рассматриваются как константы,

но их значение может быть установлено при включении модуля в качестве
компонента в более сложный проект. Если модуль применяется автономно,
или в проекте высшего уровня иерархии некоторые параметры не определе-
ны, используется значение по умолчанию.
Параметры, задающие функции, реализуемые конкретными вхождениями
параметризованного модуля, чаще всего используются в операторах услов-
ной генерации, синтаксис которого определен как:
<оператор условной генерации> :: =
IF <выражение проверки> GENERATE
<оператор> «<оператор>»
[ ELSE GENERATE <оператор> «<оператор>»]
END GENERATE;
Оператор условной генерации может присутствовать в логической секции

проектного модуля и в подсекции переменных. Аргументами выражения
проверки являются параметры конфигурации. Выражение проверки может,
например, предусматривать сравнение параметров с константами (равно, не
равно и т. п.) или между собой. Если выражение истинно, реализуется пер-
вая группа операторов, в противном случае вторая, а в случае отсутствия
конструкции ELSE GENERATE вообще никаких. Особый случай — проверка
того, используется ли определенный порт при включении модуля в проект
высшего уровня. Для такой проверки в AHDL предусмотрена функция USED
(<имя>), которая возвращает логическую единицу, если порт с указанным
именем определен в проекте высшего уровня, и ноль — в противном случае.
Главное отличие оператора I F -GENERATE от условного оператора I F -THEN со-
стоит в том, что он выполняется только на этапе компиляции проекта, а не
в физической реализации. Иными словами, в реализуемом устройстве будет
воспроизведена только одна из возможных альтернатив в зависимости от
задаваемых в модуле верхнего иерархического уровня значений параметров.
Отметим, что, в отличие от VHDL, оператор I F -GENERATE в AHDL может
представлять альтернативные реализации.
Полезным инструментом иерархического проектирования является оператор
проверки, с помощью которого можно задать контроль корректности зада-
ния параметров при компоновке сложных проектов.
<оператор проверюи> : : =
ASSERT <выражение проверки> REPORT <строка сообщения>
[ <переменная сообщения> «,<переменная сообщения> » ]
[ SEVERITY <уровень важности> ]
<уровень важности> ::= INFO | WARNING | ERROR
Если выражение проверки ложно, то в процессе компиляции на терминал

выдается строка сообщения, причем если в этой строке присутствует символ
%, то на этом месте выводится значение переменной сообщения. Если в
строке несколько символов %, то значения переменных сообщения выводят-
ся в порядке их записи в списке. Уровень важности задает реакцию компи-
лятора на обнаруженное несоответствие. Объявление уровня важности как
ERROR или отсутствие конструкции SEVERITY является указанием прекратить
компиляцию, в остальных случаях после выдачи сообщения компиляция
продолжается.
Указанные возможности иллюстрируются на примере программы (лис-
тинг 3.77), которая может быть использована для представления различных
по существу блоков — сумматора, вычитателя или управляемого сумматора -
вычитателя. Кроме того, программу можно использовать как описание ком-
бинационной схемы, так и схемы с памятью. Дополнительный параметр на-
стройки — число разрядов.
Операторы I F -GENERATE разрешают или блокируют реализацию определен-
ных последовательностей деклараций или операторов. Например, в зависи-
мости от значения параметра type выходные данные программы определя-
ются либо как узлы, либо как D -триггеры. Обратите внимание, что операторы
проверки позволяют осуществлять контроль корректности задания парамет-
ров настройки.
PARAMETERS (type="registered",
direction="ADD",
Width=8);
ASSERT ( width>0)
REPORT "value of width must be greater then %" width
SEVERITY error;
ASSERT ((type="registered") # (type=="unregistered"))
REPORT "invalid design type declaration"
SEVERITY ERROR;
ASSERT( (Direction=="ADD")#(Direction=="SUBB")#(Direction=="ADD_SUBB"))
REPORT "direction must be ADD,SUDD or ADD_SUBB"
SEVERITY ERROR;
SUBDESIGN add_s
( cin,clock, clear, control, a[width -l..0],b[width -l..0] :INPUT;
result [width -1..0],cout: OUTPUT)
VARIABLE
argl[width..0], arg2[width..0], int_res[width..0],arg3[width..0]:NODE;
IF (type =="registered") GENERATE result[width -1..0],cout : dff;
END GENERATE;
BEGIN
ASSERT type="registered" !$ used (clock)
REPORT "for registered type use clock input"
SEVERITY WARNING;
Assert direction="ADD_SUBB" !$ used (control)
report "for registered type use clock input"
SEVERITY ERROR;
IF (type ="registered") GENERATE result[].clk=clock; cout.clk=clock;
result[].clrn=clear; cout.clrn=clear;
(cout.d,result[].d)=int_res[];
ELSE GENERATE (cout,result[])=int_res[];
END GENERATE;
IF cin==vcc THEN arg3[]=l; ELSE arg3[]= -!;
END IF;
argl[]=(a[width -1],a[]); — расширение знакового разряда
arg2[]=(b[width -1],b[]);
IF (direction="ADD") GENERATE int_res [ ] =argl [ ]+arg2 [ ]+arg3 [ ] ;
END GENERATE;
IF (direction="SUBB") GENERATE int_res [ ] =argl [ ] -arg2 [ ] -arg3 [ ] ;
ELSE GENERATE
IF (control=vcc) THEN int_res [ ] =argl [ ]+arg2 [ ]+arg3 [ ] ;
ELSE int_res[]=argl[] -arg2[] -arg3[];
END IF;
END GENERATE;
END;
3.5. Что дальше?

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

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

ет. "Война языков", происходившая до середины 90 -х годов, прежде всего
между VHDL и Verilog, к сегодняшнему дню закончилась "вничью". По дан-
ным опросов [49], 60% разработчиков предпочитают Verilog, а 40% — VHDL.
При этом в Америке шире используется Verilog, европейские компании от-
дают предпочтение VHDL. В России VHDL имеет явное предпочтение, хотя
бы потому, что VHDL отражен в целом ряде книг [6, 8, 56, 57], но до сих
пор нам не известна книга на русском языке, систематически излагающая
Verilog.
Относительно языков ассемблерного уровня, следует ожидать, что они со-
хранят свою экологическую нишу. Наряду с графическими способами зада-
ния и схемным вводом в виде таблиц соединений они будут использоваться
для представления критичных по времени исполнения фрагментов в проек-
тах, ориентированных на конкретную элементную базу.
Наряду и параллельно с развитием языков происходит развитие средств их
интерпретации. Естественно, новые опции и изменения синтаксических
конструкций языка, вводимые в новых версиях стандартов, должны свое-
временно отслеживаться при разработках САПР, но это не является особой
проблемой, т. к. свежие версии компиляторов появляются значительно ча-
ще, чем происходит обновление стандартов. Более важным в разработках
новых версий САПР и их оценке являются следующие моменты.
Одна из существенных проблем, связанных с использованием языков про-
ектирования, — это различие между "эталонным языком" и "реализуемым
подмножеством языка". Уже неоднократно отмечалось, что язык при проек-
тировании используется для решения взаимодополняющих, но различных
задач: спецификация проекта, моделирование и, наконец, синтез реализа-
ции. В языки включено достаточно много конструкций, которые предназна-
чены исключительно для целей моделирования. Наиболее очевидные при-
меры — это операторы предупреждения языков VHDL и AHDL (Assert
Statements), функции управления выводом в Verilog. Современные САПР не
интерпретируют опции временного управления (операторы WAIT FOR в языке
VHDL и префиксы вида |<время> в Verilog). Выражения задержки, установ-
ленные пользователем, тоже игнорируются синтезаторами. Обычно значе-
ния задержки назначаются в системе проектирования по результатам синте -
за, причем в ряде САПР предусмотрена генерация уточненного програм-

много текста, в котором отражаются задержки реальных компонентов син-
тезированного устройства. Подобные уточненные описания предназначены
для моделирования более сложных проектов, в том числе для экспорта в
другие системы моделирования.
Кроме этого, пользователь вправе предусмотреть в программе фрагмен-
ты, ориентированные только на реализацию процедур моделирования. При
записи таких фрагментов разработчик может не обращать внимание на эф-
фективность и даже возможность их физической реализации — важна лишь
простота и наглядность описания — и в этом случае допускается применить
даже достаточно экзотические конструкции, вроде рекурсивных вызовов
процедур или операторов повторения с необъявленными заранее признака-
ми их завершения. Такие фрагменты обычно просто удаляются после пред-
варительного тестирования и отладки перед передачей программы в подсис-
тему синтеза. Существуют системы интерпретации, в которых программным
блокам можно сопоставлять специфические признаки, определяющие, ка-
кие из них подлежат реализации, а какие используются только при модели-
ровании. Например, синтезатор системы MAX+PLUS II игнорирует опера-
торы INITIAL в программах на Verilog. Иногда разработчик намеренно
использует несинтезируемые конструкции на начальных этапах проектиро-
вания для обеспечения большей наглядности спецификации или для сокра-
щения времени предварительной отладки (как для экономии собственных
трудозатрат, так и машинного времени для моделирования), предполагая
дальнейшую декомпозицию проекта на реализуемые фрагменты (см. пример
в разд. 3.2.1).
Но в то же время имеется ряд конструкций языков, которые в принципе
синтезируемы, но не поддерживаются в конкретных САПР. Рассмотрим,
например, VHDL -программу, представленную в листинге 3.78.
ENTITY unrealis IS
PORT( clock:IN bit;
a,b: IN integer RANGE 0 TO 15;
compare_out : OUT bit_vector (1 DOWNTO 0)
);
END urealis;
ARCHITECTURE behave OF unrealis IS
BEGIN
PROCESS (clock)
VARIABLE more, less:bit;
BEGIN
IF (clock='0')THEN
IF a>=b THEN more:='l'; less:='0';
ELSE more: ='0'; less:='1';
END IF;
ELSE compare_out<=more&less;
END IF;
END PROCESS;
END behave;
Эта программа описывает устройство, которое по заднему фронту сигнала

clock выполняет сравнение входных кодов с фиксацией результата на внут-
ренних триггерах more и less. По переднему фронту clock происходит пе-
резапись результата в выходной регистр compare_out. При попытке скомпи-
лировать этот файл в системе MAX+PLUS II было получено сообщение об
ошибке следующего содержания: "Else clause following clock edge must hold
state of signal compare_out" (конструкция ELSE, следующая за фронтом такти-
рующего сигнала, должна сохранять состояние сигнала compare_out), хотя
ни в стандарте, ни сопроводительных материалах фирмы ничего о таком
ограничении не упомянуто. Эта же программа была успешно скомпилиро-
вана компилятором SimplifyPro, а результат компиляции в форме EDIF -
файла был импортирован в систему MAX+PLUS II и без ошибок реализован
в составе БИС семейства FLEX10K. Имеется достаточно много других при-
меров, когда компилятор "отказывался" интерпретировать регистровые схе-
мы, синхронизируемые несколькими различными сигналами.
Еще хорошо, если неподдерживаемая опция перечислена в материалах, со-
провождающих систему проектирования, или явно указывается компилято-
ром, как в приведенном примере. Например, материалы по САПР
MAX+PLUS II определяют, что не поддерживаются такие конструкции
VHDL, как параметры настройки (кроме библиотечных параметризованных
модулей), объявления конфигураций, данные действительного типа и мно-
гое другое. Компилятор языка Verilog этой САПР не поддерживает числен-
ные типы данных (кроме индексных выражений и оператора FOR), боль-
шинство операторов цикла, шинные типы данных, опции задержки и силы
драйвера в операторах присваиваний и т. д.
К сожалению, многие неподдерживаемые опции не документируются. Воз-
никали проблемы при интерпретации некоторых сложных конструкций,
прежде всего фрагментов с большим числом вложений операторов. При
этом компилятор MAX+PLUS II выдавал не слишком определенное сооб-
щение "unknown problem" (неизвестная проблема). Поиск ошибки (впрочем,
это даже и нельзя назвать ошибкой разработчика в традиционном смысле)
в подобной ситуации становится чрезвычайно трудным.
В целом, несмотря на стремление разработчиков САПР обеспечить универ-
сализацию средств синтеза и даже попытки стандартизации реализуемых
подмножеств языков, сохраняется значительное расхождение в наборе кон-

струкций языков, входящих в реализуемое подмножество языка различных
интерпретаторов. Разработчик, перед тем как приступить к описанию своего
проекта, должен ознакомиться с ограничениями, определенными в той сис-
теме проектирования, которую он собирается использовать.
Сокращение объема нереализуемых подмножеств языков является одним из
существенных направлений усовершенствования САПР больших интеграль-
ных схем.
Другим аспектом развития САПР дискретных устройств является повыше-
ние качества синтеза. Разрабатываются и внедряются новые эффективные
алгоритмы оптимизации проектов по различным критериям. Обычно разра-
ботчик может задать критерий оптимизации — минимальное время или
оптимальное использование ресурсов. Но наиболее совершенные средства
последних поколений дают результаты, многократно превосходящие резуль-
таты, которые давали "старые" версии, одновременно по обоим параметрам.
Возможности средств синтеза, представляемые различными фирмами, в этом
смысле оказываются существенно различными, причем в настоящее время
выигрывают фирмы, которые специализируются именно на разработках
САПР. Их компиляторы на сегодня существенно превосходят по возможно-
стям системы, предлагаемые непосредственно производителями ПЛИС.
Фирма Altera даже рекомендует в критических случаях для предварительной
компиляции VHDL - и Verilog -проектов, ориентированных на реализацию
в ПЛИС этой фирмы, использовать средства третьих фирм, например
Simplicity или Cadence, и импортировать результат синтеза в собственные
САПР фирмы, несмотря на наличие в последних встроенных компиляторов.
По опыту авторов такая процедура, в частности использование предвари-
тельной компиляции с применением компиляторов LeonardoSpectrum фирмы
Mentor Graphics, позволяет в сложных проектах экономить до половины ис-
пользуемого ресурса. Кроме того, таким образом часто удается интерпрети-
ровать программы, не доступные для интерпретации встроенными компиля-
торами САПР фирмы Altera, как было показано выше на примере.
И наконец, значительные усилия разработчиков языков и средств их интер-
претации направлены на повышение уровня абстракции описания. VHDL и
Verilog показали себя весьма эффективными средствами проектирования
"досистемных" уровней представления устройств. Эти уровни объединяют
вентильный уровень представления, уровень регистровых передач и уровень
операционных блоков. Однако современный этап развития средств обработ-
ки информации, в том числе разработка встраиваемых систем на кристалле,
требует более обобщенного представления алгоритма, включая совместное
представление и аппаратных, и программных частей проекта.
Под системным уровнем проектирования создатели и пользователи САПР
информационных систем понимают "учет архитектурных особенностей сиc -
тем SoC/ASIC до разделения задачи между программной и аппаратной

частью... Это является важным поводом для использования языков систем-
ного уровня перед началом утомительной работы на уровне регистровых
передач" [49]. Языки системного уровня рассматриваются не только как
средства ускорения моделирования, но и ориентированы на решение задач
сопряженного проектирования и сопряженной верификации.
Как VHDL, так и Verilog в их современной форме оказываются недостаточ-
ными для представления комплексных аппаратно -программных проектов.
С одной стороны, эти языки не обладают достаточной мощностью для опи-
сания сложных процессов обработки данных (во всяком случае, программы
при использовании только возможностей HDL были бы чрезвычайно гро-
моздки), да и компиляторов HDL -программ в машинный код типовых ком-
пьютеров на сегодня не известно. Если даже предположить представление
процессорного блока и программной части задачи с использованием типо-
вых HDL, потребовались бы несоразмерно большие затраты машинного
времени на процедуры моделирования, отладки и верификации. Традици-
онные же языки программирования, прежде всего C/C++, не содержат
средств для представления многих аспектов поведения аппаратной подсис-
темы.
На сегодня можно выделить два основных подхода к созданию языка сис-
темного уровня будущего. Первый ориентируется на расширение языка
C/C++ и введение в него конструкций для описания специфики аппарат-
ных средств. Другой подход предусматривает расширение языков проекти-
рования, чаще упоминается Verilog, за счет введения абстрактных понятий
системного уровня. Как и следовало ожидать, первый подход приветствует-
ся, прежде всего, системными программистами, а второй — разработчиками
аппаратуры и, в некоторой степени, создателями прикладных управляющих
программ.
В рамках первого подхода можно упомянуть SystemC, SpecC, CycleC, Han -
delC. Наиболее продвинутой является разработка языка SystemC, выполнен-
ная совместно фирмами Cadence, CoWare и Adelante Technologies в рамках
проекта Open SystemC Initiative. В своей основе SystemC представляет вер-
сию C++, в которой введены классы для представления времени, паралле-
лизма, специфических для аппаратуры типов данных и т. п. Возможности
оперировать с такими объектами, собственно, и являются отличительной чер-
той именно языков проектирования. Введены, кроме того, специальные
конструкции для моделирования взаимодействия подсистем. Интересно от-
метить, что эти классы построены на принципах описания, заложенных в
VHDL, что по мнению авторов статьи [47] привлечет к этому языку не толь-
ко системных программистов, но и сторонников VHDL. К сожалению, воз-
можности и качество синтеза аппаратной части проектов на основе SystemC
пока оставляют желать лучшего.
В направлении развития "от языков проектирования" наибольший интерес

представляет Superlog, предложенный фирмой Co -design Automation. Superlog
является расширением Verilog. Авторы проекта считают, что "проектиров-
щики, работающие с языками проектирования, чрезвычайно легко адапти-
руются к новым возможностям"[49]. Среди привлекательных свойств языка
(а точнее, системы моделирования Systemsim на его базе) авторы проекта
также указывают на допустимость смешивания в одной программе фрагмен-
тов, записанных на С, Verilog и Superlog, мощные средства верификации.
Время покажет, какое из этих направлений будет более плодотворным, а
может быть, как с VHDL и Verilog, возникнет ситуация их параллельного
использования. В ближайшей же перспективе они, безусловно, будут разви-
ваться параллельно.
Разумеется, развитие языков системного уровня не сможет привести к ума-
лению роли Verilog и VHDL. Они по -прежнему остаются предпочтительны-
ми для детального моделирования аппаратуры и для создания проектов
с преимущественно аппаратными средствами обработки. Более того, с по-
вышением эффективности компиляторов они могут частично вытеснять
языки ассемблерного уровня и схемотехнические приемы проектирования.
ГЛАВА 4
Примеры проектирования устройств

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

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

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

сколько последовательных операторных вершин позволяет реализовать их
исполнение на одних и тех же компонентах, т. е. сократить количество обо-
рудования за счет потери быстродействия. Поэтому важным этапом, в об-
щем случае, является определение необходимого числа модулей того или
иного типа для реализации требуемой микропрограммы.
Максимальная производительность достигается, когда принятая структура
не накладывает ограничений на совместимость микроопераций. Это выпол-
няется, лишь если каждый узел преобразования используется для выполне-
ния функционально эквивалентных операций только над одним словом
данных, но не над разными словами. За каждым регистром данных, сохра-
няющим результат для последующих шагов, закрепляется индивидуальное
устройство логических преобразований. Тогда все функционально совмес-
тимые операции могут исполняться в одном такте [15].
Предельным противоположным случаем является подход, основанный на
обобществлении преобразований (прежде всего, комбинационных схем) по
отношению ко всем регистрам хранения промежуточных данных. На любое
элементарное преобразование или пересылку отводится отдельный такт ра-
боты устройства, т. е. достигаются наименьшие затраты оборудования при
минимальной производительности. Возможны смешанные варианты.
Даже для простейших двуместных преобразований слов данных, например
сложения слов, возможны как параллельное преобразование всех разрядов,
так и последовательная обработка групп разрядов в преобразователе мень-
шей разрядности с разделением во времени функций входов и выходов.
Правда, для ПЛИС такой подход применительно к простой логике обычно
неоправдан, т. к. базовая ячейка выполняет одновременно функции логики
и функции хранения результата для последующих шагов алгоритма.
Рассмотрим более показательный пример — реализацию умножения. Не-
зависимо от способа реализации умножение двух чисел, представленных
в двоичном коде, требует использования nх(m -1) полных одноразрядных
сумматоров, где m и п — число разрядов сомножителей. Реализация умно-
жения с использованием n -разрядных сумматоров порождает широкую но-
менклатуру параллельных умножителей, в том числе матричную и пирами-
дальную структуры, смешанные варианты [27]. Устройства этого класса спо-
собны выполнять умножения за один такт работы схемы. Подобными
характеристиками обладают схемы, построенные на основе набора парал-
лельных умножителей меньшей разрядности с последующим суммировани-
ем частичных произведений (см., например, листинг 3.53). Для повышения
допустимой частоты поступления сомножителей используют конвейериза-
цию (см. листинг 3.30). Альтернативная версия — использование единствен-
ного сумматора. В этом случае умножение выполняется за число тактов,
равное разрядности множителя. В каждом такте к ранее накопленному ре-
зультату прибавляется произведение сдвинутого кода множимого на очеред -
5/g Проектирование систем на микросхемах программируемой логики
ной разряд множителя. Известно достаточно много промежуточных вариан-

тов, характеризующихся различными аппаратурными затратами, для кото-
рых время исполнения варьируется от одного такта до числа тактов, равного
разрядности одного из сомножителей и даже больше, если выделены от-
дельные такты для сдвига операндов и частичных сумм.
Представленные примеры иллюстрируют тот факт, что перед разработчиком
почти всегда имеется определенное поле выбора для определения соотно-
шения затрат оборудования и производительности. Иногда приходится в
процессе проектирования возвращаться к этапу формирования схемы алго-
ритма, если полученный вариант не удовлетворяет системным требованиям.
Порядок разработки операционных устройств с микропрограммным управ-
лением иллюстрируется примером синтеза устройства умножения последо-
вательного типа с одновременным анализом двух битов множителя. Пусть
на этапе анализа системных требований установлено, что умножение долж-
но инициироваться внешним сигналом и занимать около N/2 тактов работы
системы. Тогда можно принять последовательный алгоритм с умножением
в каждом такте множимого на два разряда множителя и накоплением полу-
ченных произведений в регистре результата.
Реализуемый в рассматриваемом примере алгоритм (граф -схема алгоритма
представлена на рис. 4.1) состоит в том, что по сигналу s t a r t сомножители
загружаются во внутренние регистры операционного блока — множимое в
Rg1, а множитель в Rg2 и обнуляются регистр результата Rg3 и счетчик цик-
лов СТ. После этого выполняется N/2+1 циклов, где N— разрядность мно-
жителя, в каждом из которых вычисляется частичное произведение, т. е.
произведение множимого на число, представленное очередной парой битов
множителя, причем эти частичные произведения накапливаются в регистре
результата.
В каждом i -м цикле оцениваются показатели
Si = a!х M(2хi - 1) + а0 х M(2хi - 2) + aс x Ci-1
0, если S, < 2;
C i = 1, в противном случае;
где М(j) — j -й разряд множителя; Ci-1 — бит переноса, возникающий

в предыдущем цикле при анализе предшествующей пары битов множителя;
al, а0 и ас— относительные веса соответствующих битов, причем а0 = ас = 1,
a1 = 2.
Можно видеть, что показатель Si представляет сумму численного эквивален-
та двухразрядного среза кода множителя и дополнительного члена ас х Ci-1,
который равен единице, если значение подобного показателя в предыдущем
цикле (Si-1) таково, что не позволяет непосредственно сформировать в этом
цикле частичное произведение. Соответствующая недостача должна коррек-
тироваться в текущем цикле.
НЕТ
СТ:=0; RgR:=0;
Rg1:=D1;Rg2:=D2;c:=0
НЕТ
СТ:=СТ+1; Rg1:=Rg1 * 2 ; Rg2:= Rg2 /2
Рис. 4 . 1 . Граф -схема алгоритма умножения
Каждый цикл предусматривает умножение множимого на показатель Si и

прибавление такого произведения к ранее накопленной сумме частичных
произведений с учетом фактического веса учитываемых в текущем цикле
разрядов множителя. Логика двухразрядного умножения сводится к сле-
дующему.
Если Si = 0 или Si = 4, то содержимое RgR не изменяется. Если Si= 1, то
к накопленной сумме прибавляется сдвинутый на 2х(i—2) разрядов код
множимого. Если Si = 2, то к содержимому Rg3 прибавляется сдвинутый на
2х(i—1) разрядов код множимого. Если Si — 3, то из содержимого RgR вычи-

тается сдвинутый на 2x(i -2) разрядов код множимого. Бит С устанавливает-
ся в единицу, если Si > 2, и в нуль в остальных случаях, в том числе перед
первым циклом.
Для удобства технической реализации код множимого в конце каждого цик-
ла сдвигается на два разряда в сторону старших разрядов, а код множителя
на два разряда в сторону младших, что позволяет избежать необходимости
применения сдвигателей на произвольное переменное число разрядов. Тогда
реализация каждого шага алгоритма накапливающего суммирования преду-
сматривает анализ двух младших битов в регистре множителя. В зависимости
от этого может выполняться одно из следующих действий: прибавление к
накопленной частичной сумме кода, находящегося в данный момент в реги-
стре множимого, вычитание из накопленной суммы этого же кода, либо
прибавление к накопленной сумме удвоенного (сдвинутого на один разряд)
кода регистра множимого.
Заметим, что общее число операций вида прибавление или отнимание кода
множимого и результата может быть на единицу больше величины N/2. До-
полнительное сложение требуется, если в цикле N/2 образуется недостача,
т. е. С установлен в единицу. Это же является причиной необходимости уве-
личения разрядности регистра множимого и регистра результата до значе-
ния N/2+2.
Для рассматриваемого примера необходимо использовать следующий набор
блоков:
-- (2хN+2) -разрядный регистр результата;
-- N -разрядный сдвигающий регистр множителя с возможностью парал-
лельной загрузки и со сдвигом на два разряда в сторону младших разря-
дов в каждом такте;
-- (2хN+2) -разрядный сдвигающий регистр множимого с возможностью
параллельной загрузки и со сдвигом на два разряда в сторону старших
разрядов в каждом такте;
-- счетчик циклов, имеющий N/2+1 состояние;
-- комбинационная схема, которая имеет два информационных (2хN+2) -
разрядных входа и один управляющий вход. В зависимости от управляю-
щих сигналов выход комбинационной схемы может формироваться в од-
ном из пяти вариантов:
• нулевой код;
• код с одного из входов (назовем его первым);
• сумма кодов, поданных на входы;
• разность кодов, поданных на входы;
• сумма кода, поступающего на первый вход с удвоенным (т. е. сдвину-

тым на один разряд в сторону старших разрядов) кодом, поступающим
на второй вход.
В соответствии с этим структурная схема умножителя приобретает вид,
представленный на рис. 4.2. Далее рассматривается описание устройства на
языке VHDL.
Рис. 4 . 2 . Структурная схема умножителя
В VHDL -программе (см. листинг 4.1) линиям связи компонентов соответст-

вуют сигналы. Идентификаторы и функциональное назначение этих сигна-
лов определены в табл. 4.1.
Таблица 4.1. Идентификаторы и функциональное назначение

сигналов VHDL -программы из листинга 4.1
Обозначение Идентификатор Функциональное назначение

на схеме в VHDL -программе
Выходной код регистра множимого
q_rg2 q_rg2 Выходной код регистра множителя
last_state last_state Сигнал, сигнализирующий о том, что счет-

чик содержит код заданного числа циклов
и означающий конец операции умножения
со_с count_controle Код, задающий операцию счетчика циклов
rg_c register_controle Код, задающий операцию сдвигающих

регистров
c_l_c comb_logic_control Код, задающий операцию, реализуемую

комбинационной схемой
product product Регистр накопления частичных сумм

(произведение)
о I u out_logical_unit Выход комбинационной схемы
Разработка модели поведения цифрового автомата

Прежде всего, определяется набор состояний управляющего автомата и на
схеме алгоритма помечаются эти состояния. Общее правило разметки со-
стояний состоит в следующем [15]: входу каждой вершины схемы алгоритма,
следующей за операторной, сопоставляется состояние автомата.
Однако в нашем примере общее число состояний может быть уменьшено, а
соответственно, повышено быстродействие устройства. Операции, опреде-
ленные на всех путях многовариантного выбора, совместимы с операциями,
определенными в следующим за ними блоке, и могут быть выполнены од-
новременно с последними без каких -либо дополнительных аппаратурных
затрат. Таким образом, управляющий автомат должен иметь два состояния,
которые на схеме алгоритма обозначены S0 и S1 и помечены крестиками.
В VHDL -программе состояние может быть представлено переменной или
сигналом перечислимого типа. В программе (листинг 4.1) принято обозна-
чение допустимых значений, совпадающее с обозначениями на схеме алго-
ритма, поэтому примем допустимые значения данных перечислимого типа
как S0 и S1.
Управляющие автоматы могут быть представлены в различной форме. В дан-
ном примере, ориентированном на описание устройства в VHDL, применен
оператор выбора САSЕ, при этом в качестве ключа выбора варианта ис-
пользована переменная, представляющая состояние автомата в текущий мо-
мент времени. Внутри каждого варианта определяется состояние перехода и
значения выходных сигналов в соответствии с состоянием входов управ-
ляющего автомата. Следует обратить внимание на необходимость установ-
ки автомата в исходное состояние перед началом работы: выражение
I F r e s e t = ' 1 ' THEN state<=s0, -. Программа предполагает, что использована
синхронизация управляющего автомата спадом тактирующего сигнала: вы-
ражение I F clock='0' AND NOT c l o c k ' s t a b l e THEN. Такая синхронизация
для используемых операционных узлов обеспечит стабильность входных
управляющих сигналов в моменты тактирования.
Разработка текстового описания устройства

Здесь мы кратко прокомментируем основные разделы VHDL -программы
устройства умножения, рассматриваемого в качестве примера. Использовано
смешанное структурно -поведенческое представление проекта.
В разделе ENTITY заданы внешние управляющие сигналы — тактовый clock,
начальный сброс reset, запуск одиночной операции умножения s t a r t ,
а также входные и выходные информационные сигналы ini, in2 и output.
Подраздел объявления компонентов архитектурного тела представляет ис-
пользуемые типовые операционные узлы — сдвигающий регистр со сдвигом
на два разряда double_shift_register, счетчик count и регистр -защелку
latch. Программы, описывающие поведение этих компонентов, должны
быть заранее скомпилированы в рабочую библиотеку проекта. Не вдаваясь в
детальное представление этих компонентов, будем считать, что они изменя-
ют состояние синхронно с передним фронтом сигнала clk, а выполняемое
при этом действие определяется для регистра и счетчика состоянием управ-
ляющих входов в соответствии с комментариями к декларации прототипов.
В разделе описания сигналов предъявлены соединения между компонентами
в соответствии с табл. 4.1.
Раздел операторов архитектурного тела mixed OF ex_mult содержит опера-
торы параллельного типа, в том числе операторы объявления вхождений
компонентов, оператор процесса, помеченный меткой controle_unit, пред-
ставляющий поведенческое описание блока управления, и оператор при-
сваивания по выбору, с помощью которого удалось описать работу всей
комбинационной части операционного устройства. Каждое вхождение ком-
понента представлено своим GENERIC MAP — объявлением параметров на-
стройки конкретного образца, и PORT MAP — перечислением точек присоеди-
нения внешних выводов узла к линиям внутренних и сигналов к портам
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE_IEEE.std_logic_unsigned.ALL;
ENTITY ex_mult IS — Entity проекта
PORT( reset,clock,start:IN std_logic;
IN1,IN2:IN std_logic_vector (7 DOWNTO 0 ) ;
last_state:INOUT std_logic;
output:OUT std_logic_vector (15 DOWNTO 0)
);
END ex_mult;
ARCHITECTURE mixed OF ex_mult IS

COMPONENT count — синхронный загружаемый счетчик
GENERIC (number_of_states:integer; — число состояний
number_of_bits:integer); — число разрядов);
PORT( clk, — синхронизация,
reset, carry_in:std_logic; — сброс, перенос
oper:IN std_logic_vector (1 DOWNTO 0 ) ;
сигналы управления — "00" пусто
— " 0 1 " - +1
— " 1 0 " загрузка
dat_in: IN std_logic_vector (number_of_bits -l DOWNTO 0 ) ;
dat_out:OUT std_logic_vector (number_of_bits -l DOWNTO 0);
carry_out:OUT std_logic );
END COMPONENT;
COMPONENT latch — регистр -защелка
GENERIC ( number_OF_bits:INteger); — число разрядов
PORT (clock: IN std_logic; — синхронизация
input: IN std_logic_vector(17 DOWNTO 0 ) ;
output: OUT std_logic_vector(17 DOWNTO 0));
END COMPONENT;
COMPONENT double_shift_register — регистр со сдвигом на два разряда

— и вдвиганием нуля в освободившиеся
GENERIC( num_bits: integer; dir:string);
— dir := "left","right","bidir" ( Влево -вправо -двунаправленный)
PORT(clk:IN std_logic;
control:IN std_logic_vector (1 DOWNTO 0 ) ; — 00 - пусто
— 10 — сдвиг вправо
— 01 — сдвиг влево
— 11 — загрузка
input:IN std_logic_vector (num_bits -l DOWNTO 0 ) ;
output:OUT std_logic_vector (num_bits -l DOWNTO 0)
);
END COMPONENT;
ТУРЕ states IS (sO,sl);
SIGNAL zero: std_logic_yector(17 DOWNTO 0):="000000000000000000" ;
SIGNAL one:std_logic:='1';
SIGNAL q_rg2: std_logic_vector (7 DOWNTO 0 ) ;
SIGNAL regISter_control,count_control: std_logic_vector(1 DOWNTO 0 ) ;
SIGNAL corob_logic_control: std_logic_vector(2 DOWNTO 0);
SIGNAL q_rgl,OUT_logical_unit,product:std_logic_vector(17 DOWNTO 0);
SIGNAL count_OUT: std_logic_vector (2 DOWNTO 0 ) ;
SIGNAL state: states;
BEGIN
output<=product(15 DOWNTO 0 ) ;
— функции блока комбинационной логики:
"000" — выход равен нулю
— "100" - повторение product
— "101" - прибавление
— "110" — вычитание
— "111" - прибавить удвоенное значение входа
WITH comb_logic_control SERECT
out_logical_unit<= zero WHEN "000",
product+q_rgl WHEN "101",
product - q_rgl WHEN "110",
product+q_rgl*"10" WHEN "111",
product WHEN others;
rgl:double_SHIFT_REGISTER
GENERIC MAP(18, "left")
PORT MAP(clk=>clock,oper=>register_control, input(17 DOWNTO 8)
=>zero(9 DOWNTO 0),input(7 DOWNTO 0)=> inl,output=>q_rgl);
rg2:double_shift_register
GENERIC MAP( 8, "right")
PORT MAP(clock,register_control,in2, q_rg2) ;
counter: count
GENERIC map(number_of_states=>5,number_of_bits=>3)
PORT map( clk=>clock, reset=>reset,carry_in=>one,
oper=> count_control,
dat_in=>zero(2 DOWNTO 0),
dat_out=>count_OUT,
carry_put=>last_state);
rg3: latch
GENERIC MAP( number_of_bits=>18)
PORT MAP(clock=>clock, input=>out_logical_unit, output=> product);
controle_unit: — управляющий автомат

PROCESS(reset,clock)
VARIABLE c:std_logic;
VARIABLE condition:std_logic_vector (2 DOWNTO 0 ) ;
BEGIN
condition:=q_rg2(l) & q_rg2(0) & с;
IF reset='l' THEN state<=sO;
ELSIF clock='0' and not clock'stable THEN
CASE state IS
WHEN sO=> IF start='l' THEN register_control<="ll";
state<=sl;
c:='0'; count_control<="ll";
comb_logic_control<="000";
ELSE state<=sO; register_control<="00";
с:='0'; count_control<="00";
END IF;
WHEN sl=> IF last_state='l' THEN
state<=sO;
IF c='l' THEN comb_logic_control<="101";
ELSE comb_logic_control<="100";
END IF; —carry
ELSE
CASE condition IS
WHEN "010"=> comb_logic_control<= "101";
WHEN "100" => comb_logic_control<= "111";
WHEN "110" => comb_logic_control<= "110";
WHEN "101"=>comb_logic_control<= "110";
WHEN others=>comb_logic_control<="100";
END CASE;
c:=q_rg2(l) and (q_rg2(0) or c) ;
END I F ; — count_overflow
count_control<="01";
regISter_control<="10";
END CASE; — state
END IF; reset=l or clock=0
END PROCESS; - - END controle_unit
END mixed;
4.1.2. Операционные устройства

конвейерного типа
Как отмечалось, повышение производительности операционных устройств
для реализации многошаговых процедур, в частности таких, в которых на
каждом шаге использованы результаты предыдущих шагов исполнения
алгоритма, может быть достигнуто при конвейерной реализации блока об-
работки.
Глава 4. Примеры проектирования устройств с применением ПЛИС _ 525
В качестве примера рассмотрим реализацию конвейерного устройства для

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

число в восьмиразрядном двоичном представлении; М — мантисса, т. е.
число, модуль которого принадлежит интервалу [0,5; 1-2 - 2 3 ], представ-
ленное в прямом двадцатичетырехразрядном коде, причем старший разряд
знаковый, а запятая фиксируется между знаковым и старшим значащим
разрядами.
Предполагаем, что входные и выходные данные нормализованы, т. е. приве-
дены к форме, при которой старший значащий разряд мантиссы установлен
в единицу.
Операции сложения и вычитания чисел, представленных в формате с пла-
вающей запятой, предусматривают выполнение следующих действий:
1. Выделение операнда, у которого порядок больше, и вычисление разности
порядков. Это необходимо для последующего выравнивания порядков
при обработке мантисс.
2. Модификация кодов мантисс, т. е. перевод в дополнительный код ман-
тисс чисел, которые будут суммироваться с отрицательным знаком
(отрицательных слагаемых, отрицательных вычитаемых и положительных
вычитателей).
3. Выравнивание порядков. Выполняется сдвиг мантиссы меньшего числа
влево на число разрядов, равное разности порядков.
4. Сложение кодов мантисс. Для возможности обнаружения переполнения
предварительно знаковые разряды операндов дублируются. Признак пе-
реполнения это несовпадение значений основного и дублирующего зна-
ковых разрядов после сложения.
5. Коррекция переполнения. Если обнаружено переполнение, результат
предыдущего этапа сдвигается на один разряд в сторону младших, а по-
рядок увеличивается на единицу.
6. Модификация результата. Если результат отрицательный, результат пре-
образуется в прямой код.
7. Нормализация результата. Мантисса сдвигается так, что старшая едини-
ца в значащих разрядах результата размещается в старшем разряде. Зна-
ковый разряд не модифицируется. Одновременно порядок результата
уменьшается на столько единиц, на сколько разрядов сдвинута мантисса.
Можно обратить внимание, что большинство этапов должны выполняться
последовательно. Тем не менее, первые два этапа функционально независи -
мы и требуют существенно различных средств, поэтому могут совмещаться

во времени. Кроме того, преобразования по пунктам 4 и 5 достаточно про-
сты и реализуются последовательно включенными комбинационными схе-
мами за время, сравнимое с временем исполнения других этапов. Поэтому
можно принять структуру устройства сложения чисел с плавающей точкой,
представленную на рис. 4.3.
result_p result_m
Рис. 4.3. Структура конвейерного сумматора чисел в формате с плавающей запятой
На рис. 4.3 и программе (листинг 4.2), отображающей поведение этого уст-

ройства, обозначено:
-- p1 и m11 — порядок и модифицированная мантисса большего по модулю
числа, а р2 и m21 — их задержанные значения;
-- m12 — модифицированная мантисса меньшего числа, а m22 — ее значение
после выравнивания порядков;
-- dif_p — модуль разности порядков;
-- mз, m4, рз, р4 — результаты промежуточных этапов вычисления мантиссы
и порядка.
Программа (листинг 4.2) представляет поведенческую интерпретацию пове-
дения ступеней конвейера на языке VHDL. Для лучшей структуризации
проекта описания ступеней выделены в отдельные программные единицы —
процессы.
Для того чтобы обеспечить конвейерную обработку, выходы любой ступени
представлены регистрами, причем все регистры синхронизируются общим
тактовым сигналом. При описании в VHDL это находит свое отражение в
том, что операторы присваивания выходным сигналам ступеней вложены в
операторы PROCESS, инициируемые общим тактовым сигналом. Структура
программы в языке Verilog HDL аналогична: следует записать подобную со-
вокупность блоков, снабдив каждый из них префиксом событийного управ-
ления от фронта тактирующего сигнала.
LISRARY IEEE;
USE ieee.std_logic_arith.ALL;
USE ieee.std_logic__unsigned.ALL;
ENTITY pipe_add IS
PORT (clk : IN std_logic;
add_subb : IN std_logic; — 0 — сложение
mx,my : IN std_logic_yector(23 DOWNTO 0 ) ;
px,py : IN std_logic_vector(7 DOWNTO 0)
result_m : OUT std_logic_vector(23 DOWNTO 0 ) ;
result_p:OUT std_logic_vector(7 DOWNTO 0);
);
END pipe_add;
ARCHITECTURE behave OF pipe_add IS

SIGNAL m11,ml2,m21,m22,m3,m4:std_logic_vector(23 DOWNTO 0 ) ;
SIGNAL maxp,dif_p,p2,p3,p4: std_logic_vector(7 DOWNTO 0);
BEGIN
PROCESS(clk)— приведение знаков; выделение большего
VARIABLE mod_mx,mod_my:std_logic_vector(23 DOWNTO 0 ) ;
BEGIN
IF mx(23)='0'THEN mod_mx:=mx;
ELSE mod_mx:= mx(23)& (not mx(22 DOWNTO 0) +1) ;
END I F ;
IF (my(23) x o r ADD_subb) = ' 0 ' THEN mod_my:=my;
ELSE mod_my:= my(23)& (not ray(22 DOWNTO 0) +1);
END IF;
IF px>= py THEN maxp<=px; difj><=px -py;
m11<=mod_mx; ml2<=mod_my;
ELSE maxp<=py; dif_p<=py -px;
ml2<=mod_mx; mll<=4nod_my;
END IF;
END PROCESS;
PROCESS(clk) — Выравнивание порядков

BEGIN
p2<=maxp; — трансляция большего порядка
m2K=mll; — мантисса большего числа передается без изменений
IF dif_p)<24 THEN
m22<=to_stdlogicvector(to_bitvector(m12) sla conv_integer(dif_p));
ELSE m22<="000000000000000000000000";
END IF;
END PROCESS;
process (clk) — сложение, коррекция при переполнении
variable sum,pr: std_logic_vector(24 downto 0 ) ;
variable switch:std_logic_vector (1 downto 0 ) ;
begin
sum:=rol2(23)& ml2 + m22(23)& m22;
if not(sum(23) = sum(23)) then
sum:=to_stdlogicvector(to_bitvector(sum) sla 1);
p3<=p2+l;
else p3<=p2;
end if;
m3<=sum(23 downto 0 ) ;
end process;
process (clk) — модификация результата
Begin
р4<=рЗ; —синхронизация данных
if m3(23)='0' then m4<= m3(23 downto 0 ) ;
else m4<= '1' & (not m3 (22 downto 0))+1;
END IF;
END PROCESS;
PROCESS (clk) — нормализация
VARIABLE i:integer;
BEGIN
FOR i IN 0 TO 22 LOOP — определение позиции старшей единицы
EXIT WHEN m3(22 -i)='l';
END LOOP;
result_m <= to_stdlogicvector(to__bitvector(m3) sla 1);
result_p <= p3+i;
END PROCESS;
END behave;
В зависимости от требований проекта можно объединять логику смежных

ступеней (что приведет к уменьшению числа тактов преобразования, но мо-
жет потребовать увеличения длительности такта), или наоборот, разбить
основные этапы на более мелкие подэтапы, имея в виду включение регист-
ровых схем между узлами, реализующими подэтапы. В общем случае при
проектировании может потребоваться вмешательство разработчика для де-
тальной проработки фрагментов и осуществление дополнительной их струк-
турной декомпозиции для получения улучшенных характеристик реализации.
Список допустимых операций представленного арифметического устройства
достаточно легко может быть расширен. Например, для реализации умно-
жения на втором этапе следует предусмотреть умножение мантисс (вы-
равнивание порядков при сложении может быть выполнено как умноже-
ние), а на третьем этапе выполнять сложение порядков. Блок нормализации
никак не модифицируется. Естественно, требуется управление коммутацией
данных внутри блоков, реализующих фрагменты алгоритма. Такие коммута-
торы, распределенные по пути распространения данных, управляются кодом
выполняемой операции, который "движется" по параллельному пути, со-
ставленному из элементов задержки, синхронно с перемещением данных,
которые обрабатываются в этой операции.
Приведенные в данном разделе примеры относились к реализациям ариф-
метических преобразований. Такой выбор был сделан, потому что обработка
численных данных, по мнению авторов, понятна наибольшему числу воз-
можных читателей книги и наиболее наглядна. Но такие подходы и подоб-
ные структурные реализации могут быть применены также и для создания
систем обработки иной информации — логического анализа, поиска ин-
формации в сложных структурах данных, обработки текстов, изображений
и т.д.
4.2. Реализация модулей памяти в ПЛИС

Все современные ПЛИС высокой сложности включают в свой состав блоки
статической памяти (ЗУ) с произвольным доступом достаточно большого
объема (см. гл. 1). Внутренняя память ПЛИС организована по модульному
принципу и может реконфигурироваться в самые разнообразные структуры.

Поэтому проблема реализации подсистем памяти в проектах состоит не
столько в проектировании отдельных блоков памяти и даже не в создании
средств доступа (буферизация адреса и данных, управление, сигнализация
о состоянии и т. д.), сколько в выборе конфигурации из числа вариантов,
предлагаемых в библиотеках типовых решений САПР, и их соответствую-
щего представления в проекте.
Известно, что с точки зрения способа доступа к информации устройства
памяти разделяются на:
- память с адресным доступом (оперативная RAM и постоянная ROM),
существуют также однопортовая и многопортовая адресная память;
- память с последовательным доступом;
- память с ассоциативным доступом.
В книге [27] описаны принципы работы и типовые варианты структурной
реализации этих видов памяти.
Данный раздел представляет обзор вариантов конфигурации и характери-
стику специфических особенностей блоков памяти на примере состава биб-
лиотеки параметризованных модулей (Library of Parameterized Modules, LPM)
фирмы Altera.
4.2.1. Память с адресным доступом

Варианты однопортовой памяти с адресным доступом представлены в биб-
лиотеке САПР MAX+PLUS II несколькими параметризованными модулями:
-- LPM_RAM_DQ — RAM с раздельными линиями входа и выхода данных;
-- LPM_RAM_IO — RAM с общей линией входа и выхода данных;
-- LPM_ROM — постоянная память.
Листинг 4.3 представляет VHDL -прототип модуля LPM_RAM_DQ.
COMPONENT lpm_ram_dq
GENERIC (LPM_WIDTH: POSITIVE;
LPMJTYPE: STRING := "L_RAM_DQ";
LPM_WIDTHAD: POSITIVE;
LPM_NUMWORDS: STRING := Positive;
LPM_FILE: STRING := "UNUSED";
LPM_INDATA: STRING := "REGISTERED";
LPM_ADDRESS_CONTROL: STRING := "REGISTERED";
LPM_OUTDATA: STRING := "REGISTERED";
LPM HINT: STRING := "UNUSED");
PORT ( d a t a : IN STD_LOGIC_VECTOR(LPM_WIDTH -1 DOWNTO 0 ) ;

a d d r e s s : IN STD_LOGIC_VECTOR(LPM_WIDTHAD -1 DOWNTO 0 ) ;
wr: IN STD_LOGIC := '1';
i n c l o c k : IN STD_LOGIC := '1';
o u t c l o c k : I N STD_LOGIC : = ' 1 ' ;
q: OUT STD_LOGIC_VECTOR(LPM_WIDTth -l DOWNTO 0 ) ) ;
END COMPONENT;
Рассмотрим основные параметры конфигурации модуля и вытекающие из

этого особенности функционирования. Параметры LPM_WIDTH и LPM_NUMWORDS
достаточно очевидны: они задают организацию памяти — разрядность и об-
щее число хранимых слов. Разрядность кода адреса задается параметром
LPM_WIDTHAD. Рекомендуется (но не обязательно), чтобы это значение было
равно Log2 (LPM_NUMWORDS). Если LPM_WIDTHAD окажется меньше этой величи-
ны, то часть памяти становится попросту недоступна, а если больше, то на
кодовых комбинациях, численный эквивалент которых превышает
LPM_NUMWORDS, из памяти считывается неопределенное значение ' х'.
Параметр LPM_TYPE — это специфический параметр, обязательный для моду-
лей библиотеки LPM, параметр просто повторяет имя ENTITY прототипа.
Параметр LPM_FILE определяет имя файла, который может содержать дан-
ные, записываемые в память при инициализации. Параметр LPM_HINT уста-
навливает дополнительные опции для синтеза. Если в проекте установлено
значение USED, то при синтезе устройства памяти учитываются глобальные
опции логического синтеза, определенные для остальной части проекта.
Если установлено значение UNUSED, то эти опции не учитываются.
Параметры LPM_INDATA, LPM_ADDRESS_CONTROL, LPM_OUTDATA относятся к типу
STRING и могут принимать значения REGISTERED и UNREGISTERED. Если при-
нято значение REGISTERED, то соответствующие порты (data — вход данных,
q — выход данных и address — вход адреса) внутри модуля сопровождаются
буферными регистрами, причем адресный буфер и буфер входных данных
стробируются сигналом inclock, а выходной буфер данных — сигналом
outclock.
Здесь важно отметить, что если вход адреса стробирован, то работа устрой-
ства памяти осуществляется по конвейерному принципу. По фронту сигнала
inclock адрес фиксируется в буферном регистре и подвергается внутренней
дешифрации, но в матрице памяти в этот момент выбрана ячейка, адрес ко-
торой был записан в буфер в предыдущем цикле обращения. Именно в эту
ячейку в режиме записи заносятся данные, которые в этот момент находятся
в буфере входных данных, а в режиме чтения данные из этой ячейки посту-
пают на выход. Указанные особенности иллюстрируются временными диа-
граммами, представленными на рис. 4.4.
Рис. 4.4, а показывает временную диаграмму процесса записи для случая
стробированного адресного входа и входа данных. Строка диаграммы ram
отображает действия, выполняемые в каждом временном интервале в мат-

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

также зафиксирован в буфере адреса в предыдущем такте работы. Рис. 4.4, б

иллюстрирует случай нестробированного входа данных. Обратим внимание,
что данные, которые в момент синхроимпульса присутствуют на входе, за-
писываются по адресу, зафиксированному в предыдущем такте.
На рис. 4.4, в представлена диаграмма процесса чтения для режима строби -
руемых входа адреса и выхода данных. После каждого импульса in_clock на
выходе матрицы памяти ram_data возникают данные, записанные в матрице
по адресу, зафиксированному в буфере в предыдущем такте (A1 соответству-
ет D1 и т. д.). Если выход не стробирован, эти данные непосредственно
транслируются на выход. Для случая стробированного выхода данные фик-
сируются в выходном буфере по каждому импульсу out_ciock.
Пример включения модуля LPM_RAM_DQ представлен в листинге 4.4. Библио-
течный модуль сконфигурирован на реализацию блока памяти объемом
10 Кбайт с фиксацией по фронту синхроимпульса входов адреса и данных и
нестробируемым выходом. Этот модуль включен в проект block_mema, пред-
ставляющий устройство, способное выполнять блочные пересылки между
модулем памяти и другим! стройствами в синхронном режиме.
Декларация прототипа в данном случае не требуется, т. к. содержится в пакете
lpm_components, по определению скомпилированному в системную библио-
теку LPM и доступную всем проектам, выполняемым в среде MAX+PLUS II.
По сигналу s t a r t начальный адрес передаваемого блока in_adr, длина бло-

ка block_length и признак чтение/запись wr фиксируются во внутренних
регистрах. Каждый следующий такт работы инициирует чтение или запись
данных по адресу, находящемуся в счетчике адреса с последующим инкре-
ментом адреса. После выполнения запланированного числа обменов устрой-
ство переходит в состояние ожидания очередного запроса.
LIBRARY ieee;
USE ieee.std_logic_arith.ALL;
LIBRARY 1pm;
USE 1pm.lpm_components.ALL;
ENTITY biockjnema IS
PORT(data: IN std_logic_vector (7 DOWNTO 0);
in_adr,block_length : IN integer RANGE 0 TO 1023;
wr, clock,reset,start: IN std_logic;
busy:out std_logic;
q: OUT std_logic_vector (7 DOWNTO 0));
END block mema;
ARCHITECTURE example OF block_mema IS
SIGNAL address:integer RANGE 0 TO 1023;
SIGNAL paddress: std_logic_vector (9 DOWNTO 0 ) ;
TYPE state IS (idle, working);
SIGNAL inclock,we: std_logic;
SIGNAL s:state;
BEGIN
paddress<=conv_std_logic_vector(address,10);
inclock<= clock WHEN s=working ELSE
'0';
busy<= '1' WHEN s=working ELSE
'0';
PROCESS (clock,reset)
VARIABLE fin_address:integer;
BEGIN
IF reset='1' THEN s<=idle;
ELSIF clock='l' AND clock'event THEN
CASE s IS
WHEN idle=>
we<=wr;
IF start='l' THEN s<=working;
address<=in_adr;
fin_address:=address+ block_length;
ELSE s<=idle;
END IF;
WHEN working => address<=address+l;
IF address=fin_address THEN s<=idle;
END IF;
END CASE;
End IF;
End PROCESS;
ram_inst: lpm_ram_dq
GENERIC MAP (lpm_widthad => 10,lpm_outdata=>"unregistered",
lpm_width => 8)
PORT MAP (data => data, address => paddress, we => we,
inclock => inclock, q => q ) ;
END example;
Набор параметров настройки для модуля памяти с мультиплексированными

ЛИНИЯМИ ВХОДа/ВЫХОДа l p m _ r a m _ i o И МОДУЛЯ ПОСТОЯННОЙ п а м я т и lpm_rom
ничем не отличаются от ipm_ram_dq. В число управляющих сигналов этих
модулей введен сигнал разрешения, в отсутствии которого линии входа/вы-
хода находятся в высокоимпедансном состоянии. Очевидно, что lpm_rom не
имеет линий входа данных и сигнала разрешения записи.
Модули двухпортовой памяти достаточно давно введены в состав библиотек

фирмы Altera. Классическая двухпортовая память представлена в библиоте-
ках САПР MAX+PLUS II компонентом csdpram, прототип которого приве-
ден в листинге 4.5.
COMPONENT csdpram
LPM_WIDTHAD: POSITIVE;
LPM_NUMWORDS: STRING := "UNUSED";
FILE: STRING := "UNUSED");
PORT (dataa, datab: IN STD_LOGIC_VECTOR(LPM_WIDTH -1 DOWNTO 0 ) ;
addressa, addressb: IN STD_LOGIC_VECTOR(LPM_WIDTHAD -1 DOWNTO 0);
clock, clockx2, wea, web: IN STD_LOGIC;
qa, qb: OUT STD_LOGIC_VECTOR(LPM_WIDTH -1 DOWNTO 0 ) ;
busy: OUT STD_LOGIC);
END COMPONENT;
Смысл параметров настройки совпадает со смыслом параметров настройки

других модулей памяти.
Каждый порт представлен входом адреса (addressa для канала А и addressb
для канала в), входом данных (dataa и datab, соответственно) и выходом
данных (qa и qb). Модуль обеспечивает полностью симметричный режим
работы. Возможно обращение к обоим портам в одном цикле как по чте-
нию, так и по записи с произвольными адресами запроса. Единственное, и
вполне естественное, ограничение — это недопустимость одновременной
записи по одному адресу. В такой ситуации приоритет отдается запросу по
каналу А, и одновременно выдается информационный сигнал busy, сооб-
щающий устройству, подключенному к каналу в, об отказе в обслуживании.
В подобном случае это устройство должно повторить попытку доступа в
следующем цикле работы.
В последних типах микросхем (семейства АСТЕХ, Mercury) и более поздних
версиях САПР предусматриваются широкие возможности конфигурирова-
ния многопортовой памяти [48]. Варианты конфигурирования многопорто-
вой памяти для семейства Mercury приведены на рис. 4.5.
Вариант конфигурации (рис. 4.5, а) представляет симметричную двухпорто-
вую память, подобную представленному в листинге 4.5 прототипу. Вариант
(рис. 4.5, 6) представляет упрощенный, несимметричный вариант, в котором
порт А работает только на запись, а порт в только на чтение. Вариант кон-
фигурации (рис. 4.5, в) соответствует четырехпортовой памяти с двумя пор-
тами ввода и двумя портами вывода. Возможны, кроме того, смешанные ва-
рианты.
Рис. 4 . 5 . Варианты конфигурации модуля двухпортовой памяти

4.2.2. Память с последовательным доступом

В памяти с последовательным доступом записываемые данные образуют не-
которую очередь. Считываются данные из очереди одно за другим либо
в том же порядке, в котором осуществлялась запись, либо в обратном по-
рядке. Моделью последовательного ЗУ является цепочка последовательно
соединенных элементов хранения, в которой данные передаются между со-
седними элементами.
С точки зрения порядка доступа можно выделить несколько вариантов:
- устройства, реализующие дисциплину "первый пришел — первым вышел"
(FIFO);
- файловые ЗУ;
- циклические ЗУ;
- устройства, реализующие дисциплину "последний пришел — первым
вышел" (LIFO).
Разница между FIFO -памятью и файловым ЗУ состоит в том, что в первом
запись в "пустой" буфер сразу становится доступной для чтения. В файловых
ЗУ данные поступают как бы в начало цепочки элементов хранения и появ-
ляются на выходе после числа обращений, равного количеству элементов в
этой цепочке. Так как операции считывания и записи могут быть взаимно
независимы, фактическое расположение данных в файловых ЗУ на момент
считывания не связано с каким -нибудь внешним признаком. Поэтому запи-
сываемые данные объединяют в блоки, обрамляемые специальными симво-
лами конца и начала (файлы, отсюда и название). Процесс приема данных
из файлового ЗУ начинается после того, как в последовательности выходных
данных приемник обнаружит символ начала блока. В циклических ЗУ еди-
ницы записи доступны одно за другим с постоянным периодом, определяе-
мым емкостью памяти. Считывание по дисциплине LIFO характерно для
стековых запоминающих устройств.
Время доступа к требуемой единице хранения информации в последова-
тельных ЗУ представляет собой случайную величину. В наихудшем случае
для доступа к нужной записи может потребоваться "просмотр" всего объема
хранимых данных.
В организации ЗУ с последовательным доступом известны два существенно
различных подхода:
-продвижение информации в цепочке элементов (подобно регистрам
сдвига);
- хранение информации в выбранных ячейках адресного ЗУ с управлени-
ем адресом доступа по определенному алгоритму.
При реализации блоков последовательной памяти в ПЛИС применяют оба
подхода. Устройства на основе адресных ЗУ, как правило, более экономич -
ны. Но причиной использования регистровой реализации может быть не-

достаточный объем встроенной в ПЛИС памяти или даже ее отсутствие
(например, при реализации на сравнительно дешевых микросхемах, таких
как серии МАХ7000 и МАХЗООО фирмы Altera, XC9500 и CoolRanner фирмы
Xilinx). Кроме того, следует заметить, что регистровые реализации при про-
чих равных условиях обеспечивают работу на большей тактовой частоте
в сравнении со схемами на основе адресной памяти.
Рассмотрим эти подходы на примере памяти типа FIFO. Подобным образом
строятся блоки памяти последовательного типа с иными дисциплинами дос-
тупа.
Описание на языке VHDL FIFO -буфера, построенного на использовании
сдвига информации в последовательной цепочке регистров, представлено в
листинге 4.6. Структурными элементами этого устройства является блок
регистровой памяти (БРП) men, содержащий length регистров по width
разрядов каждый, и length -разрядный регистр -указатель конца очереди rg,
в котором всегда присутствует только одна единица, указывающая позицию
в БРП, в которую будет заноситься очередное данное.
При записи новая информация записывается в БРП на место, указанное
единицей в регистре -указателе, после чего содержимое rg сдвигается в сто-
рону младших разрядов. Содержимое остальных регистров не изменяется.
При чтении на выход выдается информация из последнего регистра БРП,
а содержимое остальных переписывается в соседние регистры с большим
порядковым номером. Информация в регистре -указателе сдвигается в сто-
рону младших разрядов.
В случае одновременного запроса на запись и чтение все регистры БРП,
кроме указанного единицей в регистре -указателе, принимают содержимое
их предыдущих соседей. А регистр, который отмечен единицей в регистре -
указателе, принимает входные данные. Содержимое регистра -указателя не
изменяется.
Наличие единицы в старшем разряде регистра -указателя является сигналом
"буфер пустой" (empty), а в младшем — сигналом "буфер полон" (full). Эти
сигналы должны анализироваться источником и приемником данных, кото-
рые в соответствующих ситуациях приостанавливают запросы на доступ.
Чтобы избежать потерю единицы в регистре -указателе, при сдвиге в сторону
младших разрядов самый младший разряд сохраняет единицу, если она в
нем была. Аналогично, при сдвиге в сторону старших разрядов самый стар-
ший разряд сохраняет единицу, если она в нем была.
LIBRARY ieee;
use ieee.std_logic_arith.all;
Глава 4. Примеры проектирования устройств с примененном ПЛИС 539
entity fifo IS
generic (length,width:integer:=8) ;
port(start,wr,rd,elk:in STD_LOGIC;
FULL, EMPTY:out STD_LOGIC;
datin:in std_logic_vector(width -1 downto 0 ) ;
datout:out std_logic_yector(width -1 downto 0));
END fifo;
ARCHITECTURE registered OF fifo IS

TYPE memory is ARRAY (length -1 downto 0) of std_logic_vector(width -1
downto 0);
signal men:memory;
signal rg: std_logic_vector(length -1 downto 0) ;
begin
full<=rg(0); '
empty<=rg(length - 1 ) ;
datout<=men(length - 1 ) ;
men(0)<= datin when w r = 4 ' and rg(0)='l' else men(O);
Process(rd,wr,start,elk)
variable v: std_logic_vector(1 downto 0 ) ;
begin
v:=rd&wr;
if (start='l') then — начальные установки
rg<=conv_std_logic_vector(0,length);
rg(length -1)<='1';
elsif clk='l' and clk'event then
for i in length -1 downto 1 loop — сдвиг данных в регистровом массиве
case v is
when "10"=> men(i)<=3nen(i -l) ;
when "01"=> if rg(i)='l' then men(i)<=datin;
end if;
when"ll"=> if rg(i)='l' then men(i)<=datin;
else men(i)<=men(i-l);
end if;
when others=>null;
end case;
end loop;
case v is — логика регистра управления записью
when "10" =>
rg(length -2 downto l)<=rg(length -3 downto 0 ) ;
rg(length -1)<= rg(length -1) or rg(length - 2 ) ;
rg(0)<='0';
when "01"=> rg(length -2 downto 1) <= rg(length -1 downto 2 ) ;
rg (0)<= rg(0) or rg(l);
rg(length -l)<='0';
when others=> null;

end case;
end i f ; — s t a r t
end process;
end registered;
В качестве примера реализации FIFO -буфера с размещением информации

в блоке адресной памяти рассмотрим мегафункцию csfifo (Cycle -Shared
FIFO Buffer) из библиотеки параметризованных модулей САПР MAX+PLUS II.
VHDL -прототип этой функции представлен в листинге 4.7, а внутренняя
структура — на рис. 4.6. Нетрудно убедиться, что декларация модуля csfifo
практически совпадает с декларацией ENTITY модуля fifo, представленного
в листинге 4.6. Отчасти изменены имена портов и введен дополнительный
синхросигнал clockx2, имеющий удвоенную частоту в сравнении с сигна-
лом clock.
COMPONENT csfifo
LPM_NUMWORDS: STRING := "UNUSED");
PORT (data: IN STD_LOGIC_VECTOR(LPM_WIDTH -1 DOWNTO 0 ) ;
wreq, rreq, clock, clockx2, clr: IN STD_LOGIC;
empty, full: OUT STD_LOGIC;
q: OUT STD_LOGIC_VECTOR(LPM_WIDTH -1 DOWNTO 0)
);
END COMPONENT;
Устройство содержит блок оперативной памяти RAM и два счетчика: CT1 —

указатель адреса начала очереди и ст2 — указатель адреса конца очереди.
Синхросигнал clockx2 делит период основного тактового сигнала clock на
две фазы. Первая фаза отводится для чтения данных их памяти, а вторая —
для записи данных. Если любое из этих действий в текущем цикле обраще-
ния не предусмотрено, в соответствующей фазе ничего не делается.
Если присутствует запрос на чтение, то в первой фазе на адресный вход RAM
подается код со счетчика CT1, а выходной код RAM фиксируется в выходном
регистре. После этого выполняется инкремент содержимого CT1. Если при-
сутствует запрос на запись, то во второй фазе на адресный вход подается
код со счетчика ст2, на входе данных RAM присутствует код, зафиксирован-
ный во входном регистре данных, и активизируется вход разрешения записи
WE. После этого выполняется инкремент содержимого СТ2. Если присутству-
ют запросы и на запись, и на чтение, то оба процесса выполняются после-
довательно в соответствующих фазах работы устройства.
Рис. 4.6. Структурная организация библиотечного модуля c s f i f o
Если в конце цикла работы содержимое счетчиков CT1 и ст2 оказалось рав-
ным, то, в зависимости от типа цикла, должны выдаваться дополнительные
сигналы состояния. Если такое событие произошло в цикле, в котором было
только чтение, это является признаком очистки буфера (empty), а если в
цикле, в котором была только запись, это является признаком полного за-
полнения буфера (full). В цикле чтения/записи такая ситуация возникнуть
не может.
4.2.3. Память с ассоциативным доступом

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

знака, а в некоторых версиях сохраняется в ячейках памяти. Разряды, отме-
ченные в коде маски как несущественные, не учитываются при анализе ис-
комого признака и тега на совпадение. Дисциплина выдачи слов в случае,
если тегу удовлетворяют несколько слов, а также дисциплина записи новых
данных, могут быть самыми разнообразными в зависимости от области
применения [27].
Подвидом ассоциативной памяти является Content Addressable Memory
(САМ), т. е. память, адресуемая по содержанию [48]. В САМ результатом
обращения является номер ячейки памяти, содержимое в которой соответ-
ствует признаку поиска. Впрочем, если полученный таким образом адрес
подать на блок памяти RAM, сохраняющий фактические данные, то полу-
чим полное ассоциативное запоминающее устройство.
Для пояснения принципов обращения к ассоциативной памяти рассмотрим
рис. 4.7.
Рис. 4.7. Сравнение процессов выборки в адресной памяти (а),

полной ассоциативной памяти (б) и САМ (в, г)
На рис. 4.7, а для сравнения представлена "классическая" память с адрес-

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

венным параметром. На выход выдается поле данных той ячейки, в которой
обнаружено совпадение поля тега и входного слова. Заметим, что физически
адрес не сохраняется в ячейке, а соответствующее поле на рисунках лишь
отражает один из выходов дешифратора адреса.
Память типа САМ представлена в двух вариантах. В варианте, представлен-
ном на рис. 4.7, в, при чтении на выход передается код адреса ячейки памя-
ти, в которой обнаружено совпадение образа и признака поиска. Причем,
если обнаруживается несколько образов, удовлетворяющих признаку поис-
ка, на выходные линии могут последовательно выдаваться несколько адре-
сов, начиная с наименьшего. Вариант, представленный на рис. 4.7, г, назы-
вают схемой с декодированным адресным выходом. Здесь число выходных
линий равно числу слов в памяти, причем выходной код содержит единицы
в разрядах, соответствующих ячейкам, содержимое которых удовлетворяет
признаку поиска, и нули в остальных разрядах.
В большинстве реализаций ассоциативной памяти физический адрес ис-
пользуется в процессе записи для задания места сохранения заносимых дан-
ных. Но известны устройства, в которых новая запись замещает наиболее
долго не используемую (дисциплина Last Recently Used, LRU).
Наиболее распространенная область использования ассоциативной памя-
ти — кэширование данных, т. е. запоминание копий информации, переда-
ваемой между какими -либо устройствами (например процессором и основ-
ной памятью) для уменьшения числа передач по магистрали. Используется
ассоциативная память также для модификации логических адресов в систе-
мах с виртуальной организацией памяти, при аппаратной интерпретации
алгоритмов поиска данных.
Рис. 4.8 представляет конфигурацию внешних цепей мегафункции altcam из
библиотеки параметризованных модулей САПР Quartus версии 1999.10 и
выше, а табл. 4.2 — набор параметров настройки этой функции. В микро-
схемах семейства АРЕХ20КЕ поддерживается троичное представление запи-
сываемой информации, включая уровни логического нуля, логической еди-
ницы и значение "не важно" (фактически, маскирование некоторых битов
сравниваемых кодов). В более ранних семействах и в семействе Mercury
поддерживается только поиск без маскирования.
Таблица 4.2. Набор параметров настройки мегафункции аltcam
Параметр Назначение Значение

по умолчанию
WIDTH Число разрядов слов памяти
WIDTHAD Число разрядов входа адреса
NUMWORDS Число хранимых слов 2 Л WIDTHAD
Параметр Назначение Значение

по умолчанию
LPM_FILE Файл, задающий содержимое памяти, UNUSED
устанавливаемое при инициализации
MATCH_MODE В режиме MULTIPLE допускается совпаде- MULTIPLE
ние признака с содержимым нескольких
ячеек, иначе наличие нескольких совпаде-
ний приводит к ошибочной работе
OOTPUT_REG Задает использование стробируемого UNREGISTERED
буферного регистра на выходе
OUTPUT_ACLR Задает использование входа сброса ON
буферного регистра на выходе
PATTERN_REG Задает использование стробируемых INCLOCK
буферных регистров на входах данных
и адреса
PATTERN_ACLR Задает использование входа сброса ON
буферного регистра на входе данных
WRADDRESS_ACLR Задает использование входа сброса ON
буферного регистра на входе адреса
WRX_REG Задает использование стробируемого INCLOCK
буферного регистра на входе маски
WRX_ACLR Задает использование входа сброса ON
буферного регистра на входе маски
Рис. 4 . 8 . Конфигурация внешних соединений мегафункции a l t c a m

Для того чтобы записать новую информацию в память без применения мас-
кирования, достаточно в течение двух периодов синхросигнала inclock под-
держивать активный (единичный) уровень на входах разрешения тактового
сигнала inclocken и разрешения записи wr_en, а также сохранять неизмен-
ными код адреса wraddress и данных pattern. Если используется режим
маскирования битов, то одновременно активизируется вход wrxused, а на
вход wrx подается код маски, в котором биты, установленные в единицу,
отмечают разряды, не учитываемые при сравнении. Запись данных с маски-
рованием должна продолжаться не менее трех периодов синхросигнала. Ес-
ли подан активный сигнал на вход wrdelete, то содержимое ячейки, адрес
которой присутствует на входе wraddress, стирается.
Реализация процесса чтения зависит от режима, задаваемого параметром
конфигурации MATCH_MODE. В простейшем режиме SINGLE -MATCH MODE выяв-
ляются только однократные совпадения. Если окажется, что несколько об-
разов удовлетворяют признаку, правильная работа не гарантируется. При-
знак поиска подается на вход p a t t e r n и фиксируется по сигналу mciock.
Если образ, соответствующий признаку, имеется в памяти, то по сигналу
outclock при единичном уровне на входе outclocken на выход выдается
адрес ячейки, в которой обнаружено совпадение. При этом на выходе mbits
присутствует дешифрированный адрес, т. е. код, содержащий единицу в
разряде, номер которого соответствует адресу совпадения. Дополнительно
при обнаружении совпадения в единицу устанавливается выход mf ound.
В режиме MULTILPLE -MATCH допускается совпадение нескольких образов с
признаком. Чтение в этом режиме требует минимум двух тактов сигнала.
Доступ инициализируется подачей признака на вход p a t t e r n и единичного
сигнала на вход mstart. К концу второго такта на выход maddress выдается
наименьший адрес из числа адресов ячеек, в которых обнаружено совпаде-
ние, а на выход mbits — код, содержащий единицы во всех разрядах, соот-
ветствующих адресам ячеек, в которых обнаружено совпадение. Кроме того,
при обнаружении совпадений их общее число выдается на выход mcount, a
выход mf ound устанавливается в единицу. Адреса следующих ячеек, в кото-
рых обнаружены совпадения, могут быть получены последовательно после
очередных тактовых сигналов.
Режим FAST MULTIPLE -MATCH аналогичен предыдущему, но отличается тем,
что для получения информации о первом совпадении требуется только один
такт работы. Платой за такое ускорение является увеличение аппаратурных
затрат почти вдвое.
Затраты на реализацию САМ емкостью 32 слова по 32 разряда для режима
SINGLE_MATCH в микросхемах семейства APEX 20KE составляют один блок
ESB и 35 логических макроячеек.
Использование САМ позволяет существенно повысить производительность
систем, в которых реализуются поисковые алгоритмы.
4.3. Цифровые фильтры

Обычно цифровая обработка сигналов (ЦОС) предусматривает реализацию
двух взаимодополняющих и взаимозависимых задач. Первая — это выделе-
ние некоторой совокупности признаков, характеризующих исследуемый
сигнал, например вычисление корреляционных моментов, энергетических
характеристик сигнала, спектральный анализ, частотная селекция и т. д.
Следующая задача — логический анализ совокупности признаков с целью
идентификации объекта или принятия определенных решений в зависимо-
сти от результатов анализа. Во многих случаях достаточно реализации лишь
первой задачи. Особенно это относится к устройствам, результат обработки
в которых непосредственно воспринимается человеком, например фильтрам
в аудио - и видеосистемах.
Трудоемкость преобразований, реализуемых на этапе логического анализа,
как правило, значительно уступает трудоемкости этапа выделения призна-
ков. К тому же логический анализ трудно поддается распараллеливанию.
Поэтому в настоящее время аппаратная реализация задач этого этапа прак-
тически не используется. В то же время аппаратная поддержка предвари-
тельных этапов обработки обеспечивает значительный рост производи-
тельности систем обработки сигналов и изображений и является во многих
случаях оптимальным решением по критерию соотношения производитель-
ности и стоимости. Результаты предварительной обработки (отфильтрован-
ный сигнал, спектральная функция и т. д.) можно передавать в процессор-
ное ядро системы для логического анализа. В данной книге мы остановимся
только на реализации типовых задач этапа выделения признаков в наблю-
даемом сигнале, прежде всего задачи фильтрации.
Основной операцией ЦОС является дискретная свертка, вычисляемая как
скалярное произведение двух векторов
(4.1)
где X и V — векторы, причем Х={хi}, i = 1, ..., п — последовательность от-

счетов обрабатываемого сигнала.
Компонентами вектора V={vi}, / = 1, ...,n в зависимости от постановки зада-
чи могут быть отсчеты того же или другого сигнала (вычисление коэффици-
ентов корреляции и автокорреляции), совокупность значений базисной
функции (спектральный анализ) или постоянные коэффициенты (класси-
ческие цифровые фильтры частотной селекции).
Если вычисляется не одно, а одновременно несколько результирующих зна-
чений, то преобразование можно записать в векторно -матричной форме:
Y = A*X
что эквивалентно:
(4.2)
Выражение (4.2) является основой для вычисления корреляционных и спек-
тральных функций, для многополосной фильтрации. Учет взаимной обу-
словленности коэффициентов матрицы А позволяет уменьшать число опе-
раций типа сложение/умножение и является основой для построения быст-
рых алгоритмов спектральных преобразований.
Основные пути и особенности выполнения операции дискретной свертки
проиллюстрируем на примере реализации нерекурсивных цифровых фильт-
ров, иначе называемых фильтрами с конечной импульсной характеристикой
(КИХ -фильтры). При вычислении очередного отсчета результата КИХ -
фильтра в качестве компонентов одного из векторов свертки используются
отсчеты входного сигнала в предыдущие моменты времени, а второй вектор
является упорядоченной совокупностью значений дискретной импульсной
переходной характеристики, т. е.:
л -1
где Т — период дискретизации, j — порядковый номер отсчета выходного

сигнала, h — дискретная импульсная переходная характеристика фильтра.
Или в сокращенной форме записи:
(4.3)
/=о
Структурной моделью КИХ -фильтра является цепочка элементов, каждый
из которых задерживает принимаемое значение на время одного периода
дискретизации, а выход каждого соединен с входом следующего и схемой
умножения на постоянный коэффициент. Выходы умножителей суммиру-
ются для получения очередного отсчета выходного сигнала.
В большинстве случаев используют КИХ -фильтры с линейной фазово -
частотной характеристикой, потому что, как известно, такие фильтры со-
храняют форму преобразуемого сигнала в полосе пропускания. Одной из
особенностей фильтров с линейной фазово -частотной характеристикой
является симметрия вектора коэффициентов {hi} относительно его сере-
дины, т. е.
h n / 2 + i = hn/2-(i+i), i = 0, л/2, при четном n;
h(n - 1 ) / 2 + i = h(n-i)/2 -i, i = 1, (n -1)/2 при нечетном n.
То есть значения отсчетов некоторых пар сигналов можно складывать до

выполнения умножения на одинаковые коэффициенты [23]. Структурная
модель такой реализации для n = 8 представлена на рис. 4.9.
Рис. 4.9. Структурная модель КИХ -фильтра
Как и при реализации других вычислительных алгоритмов, вычисление дис-

кретной свертки возможно как за счет последовательного выполнения опе-
раций умножение -накопление в единственном операционном блоке, так
с использованием разнообразных структур параллельного и параллельно -
последовательного типа.
Поведенческое описание устройства последовательного типа на языке
VHDL представлено в листинге 4.8. Программа предполагает, что по внеш-
нему сигналу samlpe, отмечающему появление очередного отсчета входного
сигнала, происходит сдвиг информации в линии задержки и запись нового
отсчета в первую ячейку этой линии. Импульс samlpe синхронизирован
с тактовым сигналом, но появляется значительно реже тактового сигнала.
В течение следующих power/2 тактов (параметр power задает порядок
фильтра и, соответственно, число элементов задержки) выполняется после-
довательное умножение значений отсчетов, сохраняемых в линии задержки,
на соответствующие коэффициенты, и прибавление произведения к накоп-
ленной за п предыдущих тактов сумме. После этого накопленная сумма
произведений передается на выход, а работа схемы приостанавливается до
возникновения сигнала о появлении очередного отсчета. Предполагается,
что константа xmax (диапазон представления входных данных) и тип

data_array определены в одном из доступных пакетов как
CONSTANT xmax: integer;
ТУРЕ data_array IS ARRAY RANGE <> of integer RANGE -xmax TO +xmax;
Диапазон выходных данных фильтра может уточняться по результатам ис-
следования типовых сигналов в проектируемой системе. В данном примере
принято, что код результата расширяется на 1оg2 xmax -разрядов по срав-
нению с кодом исходных данных: удвоение разрядности дает умножение,
а дальнейшее расширение может требоваться при сложении.
ENTITY fir IS
GENERIC (power: integer: =8; — порядок фильтра, предполагается четный;
h : data_array) ;
PORT ( clock, new_sample : IN bit;
input: IN integer RANGE -xmax TO xmax;
output:OUT integer RANGE -4*xmax*xmax TO 4*xmax*xmax) ;
ARCHITECTURE seqiential_behave OF fir IS
SIGNAL pipe : data_array (power -1 DOWNTO 0) ;
BEGIN Pipe_line_shifting: PROCESS (clock)
VARIABLE j : INTEGER;
BEGIN IF (clock='l' and clock' event and new_sample=' 1' ) THEN
FOR j IN power -1 DLOWNTO 1 LOOP
Pipe(j)<=pipe(j -l) ;
END LOOP;
pipe ( 0 ) <= input ;
end if;
END PROCESS;
multiply_and_accumulate : PROCESS (clock)
VARIABLE i: integer;
VARIABLE result: integer RANGE -2*xmax TO 2*xmax) ;
Begin
IF clock='l' and clock' event then
If new_sample='0' THEN
i:=0; result:=0;
ELSIF i<power/2 THEN result := (pipe (I) +pipe (power -i) ) *h(i) ;
ELSIF i=power/2 THEN

output <=result
END IF;
END IF;
END PROCESS;
END sequential_behave;
Если последовательный вариант не удовлетворяет по быстродействию, то

приходится прибегать к параллельным, предпочтительно к конвейерным,
реализациям.
Учитывая параллельность путей распространения информации в структуре
вычислителя свертки (см. рис. 4.9), можно расположить параллельно испол -
няемые преобразования в общих ярусах конвейерной структуры, причем
результаты в каждом ярусе фиксируются в регистрах, синхронизируемых
общим сигналом. На каждую двуместную операцию суммирования выделя-
ется один ярус. В том числе сумматоры, необходимые для реализации одной
операции умножения, можно расположить в нескольких различных ярусах.
Наиболее специфические фрагменты описания конвейерной схемы на языке
VHDL представлены в листинге 4.9. Декларация ENTITY, а также описание
линии задержки здесь опущены, т. к. в точности соответствуют таким же
разделам программы, приведенной в листинге 4.8. Используется структурно -
поведенческое представление, причем для реализации конвейерного умно-
жителя предполагается включение модуля pipe_mul, представленного в лис-
тинге 3.30 (см. разд. 3.2.6). Отметим, что все промежуточные суммы объ-
явлены как сигналы, и присвоения этим сигналам значений записаны
в общем теле процесса, что и соответствует конвейерной организации про-
цедуры накопления результатов.
ARCHITECTURE pipe_lined OF fir IS ...

COMPONENT pipe_mul ...END COMPONENT;
SIGNAL zO,zl,z2,z3: integer range -2* xmax to 2*xmax;

CONSTANT double:integer= 2*xmax*xmax;
SIGNAL multO,multl, mult2,mult3: integer RANGE - double TO double;
SIGNAL vl,v2: integer RANGE -2*double TO 2*double;
mO: pipe mul
PORT MAP( zO, hO, clk, multO);
ml: pipe mul
PORT MAP(zl, h1, clk,multib);
m2: pipe mul
PORT MAP( z2, h2, clk,mult2);
m3: pipe mul
PORT MAP(z3, h3, clk,mult3);
adding: PROCESS(clk)
zO<=x(0)+x(7);
zl<=x(l)+x(6);
z2<=x(2)+x(5);
z3<=x(3)+x(4);
vl<= mult0+multl;
v2<= mult2+mult3;
out<=vl+v2 ;
END PROCESS;
Если некоторые промежуточные данные, в том числе промежуточные суммы

в описании умножителя, объявить как переменные, получим реализацию
конвейера с укрупненными блоками, в каждом из которых будет исполнять-
ся несколько сложений. Уменьшение числа ступеней конвейера уменьшает
число тактов задержки результата относительно моментов поступления дан-
ных, но это для большинства приложений не является существенным. В то
же время, уменьшение объема преобразований в каждой ступени уменьшает
необходимую длительность такта работы схемы и дает возможность обраба-
тывать более высокочастотные сигналы.
Замечание
Наряду с фильтрами с конечной импульсной характеристикой известны рекур-
сивные фильтры, иначе называемые фильтрами с бесконечной импульсной ха-
рактеристикой (БИХ -фильтры). Их особенностью является то, что результат
определяется как свертка не только входного сигнала, но и ранее полученных
отсчетов выходного сигнала:
Реализация во многом подобна реализации КИХ -фильтра. Но имеется сущест-

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

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

ной на константу может быть обеспечено прямой выборкой результата из
устройства памяти, хранящей коды произведений, по адресу, задаваемому
кодом входной переменной. Однако, как правило, такой "прямолинейный"
подход оказывается неприемлем. Во -первых, при больших порядках фильтра
количество и объем встроенных в ПЛИС блоков памяти может быть попро-
сту недостаточным, потому что выборка значений произведений из блоков
памяти должна осуществляться параллельно, а во -вторых, быстродействие
блоков памяти, как правило, хуже быстродействия логических компонентов
ПЛИС. В подобных случаях целесообразным решением становится деком-
позиция умножителя в базисе типовых ячеек ПЛИС.
Рассмотрим такое представление, ориентируясь на наиболее часто встре-
чающуюся конфигурацию базовой ячейки ПЛИС, которая может настраи-
ваться на воспроизведение произвольной функции четырех переменных.
Тогда, например, для восьмиразрядного представления входных данных вы-
ражение (4.1) можно переписать в форме
л -1 л -1
(4.4)
где в квадратных скобках записан диапазон разрядов, учитываемых в преоб-

разовании.
Предполагается деление по правилам деления целых чисел с отбрасыванием
остатка, т. е. для представления aj-i необходимо максимум 8 разрядов, и,
значит, эта функция может быть воспроизведена с использованием 8 ячеек
типа четырехвходовой LUT. Аналогично, для реализации bj-i достаточно че-
тырех ячеек. При значительном разбросе значений коэффициентов фильтра
разрядность некоторых частичных произведений оказывается еще меньше,
что является дополнительным резервом экономии оборудования.
Разложение (4.4) не является единственно возможным. Удачным оказалось
объединение в группы одноименных разрядов различных компонентов век-
тора отсчетов преобразуемого сигнала:
(4.5)
xj.,[k] x ^ x 2* + Xj_,[k] xA, - x 2*, (4.5)

/=0*=0 <=0*=4
где k — номер разряда.
Внутренние суммы в этом выражении являются функциями четырех пере-
менных, и каждый разряд такой суммы воспроизводится единственной
ячейкой типа четырехвходовой LUT. Количество разрядов, необходимое для
представления этих сумм, уменьшается с уменьшением номера разряда, что
позволяет значительно сократить аппаратные затраты.
Рассмотрим этот подход подробнее на примере двумерной дискретной

свертки, являющейся базовой операцией многих задач обработки изображе-
ний и, прежде всего, двумерной пространственной фильтрации.
Принцип цифровой фильтрации изображений основан на том, что значение
показателя яркости или цветности элемента изображения (пиксела) моди-
фицируется с учетом значений показателей соседних элементов [18]. Преоб-
разования, реализуемые двумерным нерекурсивным фильтром, могут быть
представлены соотношением:
*=*/•/=// '
где x(i,j) и z(i,j) — * -е элементы у' -й строки входного и выходного изобра-
жений; Wk,i,ij ~ весовые коэффициенты, задающие вид преобразования; kk,
ki, li, Ik — границы диапазона элементов, учитываемых при формирования
отсчетов выходного изображения.
В практических приложениях наиболее часто учитывают лишь ближайшие
соседние элементы (ki = li = — 1, kk = Ik = 1) и предполагают пространст-
венную инвариантность преобразования (wk,l,i,j = wk,l). Иными словами, вы-
полняется точечное (т. е. поэлементное) умножение матрицы, составленной
из смежных отсчетов входного сигнала, на матрицу коэффициентов преоб-
разования
A=X*W= (4.6)
с последующим суммированием членов матрицы А.
Замечание
В рамках данной книги мы ограничимся этим случаем, хотя при дополнитель-
ных затратах ресурсов элементов программируемой логики возможна реализа-
ция фильтров, учитывающих большие зоны взаимного влияния отсчетов.
Не останавливаясь на способах выбора коэффициентов матрицы W, отме-

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

вания зависит от соотношения параметров k и М.
Если в этой матрице знаки коэффициентов, кроме центрального, изменить

на отрицательные, то получим обостряющий фильтр. Таким образом, мно-
гие функции обработки изображений могут быть реализованы в рамках од-
ной и той же структуры за счет изменения коэффициентов.
Анализ типовых матриц преобразования и сопоставление выражения (4.5) с
возможностями современных микросхем программируемой логики позволя-
ет сделать следующие выводы.
В большинстве практических приложений отсчеты изображения представ-
ляются как беззнаковые целые в восьмибитовом формате, причем исполь-
зуются целочисленные значения параметров М и k из весьма ограниченного
диапазона (обычно между 0 и 20). В принципе, это дает возможность при-
менять умножители с малой разрядностью множителя. Однако для сохране-
ния средней яркости изображения приходится нормировать результаты пу-
тем деления взвешенной суммы отсчетов на сумму весов. Деление является
операцией, трудно реализуемой в среде программируемой логики. Поэтому
целесообразно использовать умножения 8 -битовых данных на 8 -битовые
коэффициенты, причем коэффициенты преобразований следует скорректи-
ровать в соответствии с соотношением:
Деление результата на 256 получается отбрасыванием младшего байта.

Последовательная реализация всех преобразований для каждого пиксела в
одном умножителе -накопителе на современных ПЛИС не обеспечивает тре-
бований обработки в темпе поступления данных в видеосистему. Приходит-
ся переходить к параллельной или параллельно -последовательной реализа-
ции (например, последовательные преобразования данных для элементов
одной строки и параллельное исполнение преобразований для разных
строк) в сочетании с конвейеризацией вычислений.
Данные на вход фильтра поступают последовательно строка за строкой. По-
этому для реализации двумерной фильтрации необходимо использовать
FIFO -буфер емкостью не менее двух строк изображения. Из возможных ва-
риантов реализации такого буфера наиболее целесообразным представляется
использование встроенных блоков памяти программируемых БИС. В част-
ности, БИС семейства FLEX10K содержат встроенные блоки RAM суммар-
ной емкостью до 24 Кбайт и допускающие режим READ -MODIFY -WRITE т. е.
считывание данных и запись новых по одному адресу в одном цикле обра-
щения. Возможность совмещения считывания и записи в одном цикле по-
зволяет перейти от традиционной архитектуры FIFO к памяти с цикличе-
ским доступом, отличающейся постоянным местом хранения принимаемой
информации и общим для обоих буферов счетчиком адреса доступа, кото -
рый инкрементируется после каждого цикла и переходит к нулевому адресу

после переполнения.
Число умножений, необходимое для вычисления значения одного пиксела
для окна преобразования 3x3, равно 9. Однако большинство матриц преоб-
разования симметричны — в приведенных примерах симметричны относи-
тельно центра матрицы, некоторые алгоритмы используют матрицы с верти-
кальной, горизонтальной или диагональной симметрией.
Сумму вида
назовем сверткой по i-му столбцу окна преобразования изображения для

точки i,j.
Очевидно, что в случае вертикально симметричной матрицы
т. е. члены, соответствующие произведениям элементов правых колонок

матрицы коэффициентов, и окна изображения, полученные при вычисле-
нии элемента изображения z(i, j), можно использовать и для вычисления
элемента z(i+2,j). Это позволяет уменьшить число параллельно выполняе-
мых умножителей до 6. Если алгоритм обработки предусматривает матри-
цу, симметричную и относительно центральной вертикали, и относительно
центральной горизонтали, то число операций умножения на один пиксел
можно довести до трех. Но это оказалось неэффективным, т. к. потребует
увеличения объема памяти для хранения вычисленных неполных сумм про-
изведений для последних двух строк пикселов. Компромиссом является ис-
пользование только свойств вертикальной симметрии в сочетании с предва-
рительным суммированием таких элементов текущего окна, которые умно-
жаются на одинаковые коэффициенты, подобно одномерному фильтру.
В этом случае требуется четыре умножения и память для сохранения значе-
ний отсчетов двух последних строк изображения.
Исходя из вышеизложенного, можно рекомендовать структурную схему вы-
числительного блока фильтра изображений, приведенную на рис. 4.10. Здесь
каждый синхроимпульс вызывает загрузку нового отсчета на вход и сдвиг
содержимого буферов. Буферные схемы BUF обеспечивают задержку на один
период тактовой частоты каждая. Если в некоторый момент времени узел
свертки (MULT_ADD) А вычисляет сумму произведений трех смежных элемен-
тов одного столбца изображения на центральные элементы матрицы преоб-
разования, то в этот же момент узел свертки В вычисляет сумму произведе-
ний следующих трех элементов тех же строк на элементы правого столбца
матрицы преобразования, формируя свертку по правой колонке этого же
окна преобразования. В качестве свертки левых столбцов матрицы преобра-

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

нове комбинационного матричного умножителя или по конвейерной схеме.
Однако для случая постоянства коэффициентов оказывается возможным
отказаться от операции умножения как таковой и заменить блоки перемно-
жения памятью или комбинационной логикой. Но и в реализациях на осно-
ве логических преобразований целесообразно разбивать схему по глубине на
цепочку синхронизируемых блоков.
Как было показано при рассмотрении одномерных фильтров, при интерпре-
тации умножения на константу с использованием ячеек типа LUT наиболее
экономичная реализация получается, если выполнена декомпозиция выра-
жения свертки так, чтобы были объединены одноименные или соседние
разряды преобразуемых данных. В этом случае декомпозиция свертки по
средней (нулевой) колонке окна в базисе четырехвходовых ячеек типа LUT
имеет вид:
S i , j , 0 = (xi,j[1..0] w00+ X*I,J[1..0]W01)+

+(x i , j [3..2] w 0 0 + x*ij[3..2] wo1)* 24+
+(xi,j [5..4] w00+x*ij [5..4]w01)*28+ (4.7)
+(x i , j [7..6] w 0 0 + x* i j [7..6]w 0 1 )*212+
+x* i j [8]w 0 , 1 *216=
= V10+V20+V30+V40+V50>
Как видно, при таком разложении совместному преобразованию подверга-

ются пары одноименных разрядов различных входных кодов.
Зависимость члена разложения V10 от младших битов аргументов xi,j и xi,j*
приведена в табл. 4.3. Таблицы функций V20, V30 и V40 полностью тождест-
венны, а выражение для члена V50 очевидно.
Таблица 4.3. Зависимость члена разложения V10

от младших битов аргументов xij и x*ij
Для представления без потерь каждого скобочного выражения в (4.7) доста-

точно 11 разрядов, но относительный вклад членов разложения в оконча-
тельный результат уменьшается по логарифмическому закону с уменьшени-
ем первого индекса их обозначения. Поэтому практически без потери точ-
ности можно не воспроизводить восемь младших разрядов члена V10, шесть
младших разрядов V 20 и т. д.
Выходы логических схем, воспроизводящих отдельные члены разложения (4.7),
последовательно суммируются по пирамидальной схеме с учетом соотноше-
ния их весов.
Свертка по правому столбцу окна преобразования строится аналогично, а в
качестве значения свертки по левому столбцу можно использовать результат
свертки по правому столбцу ранее обработанного окна.
Для получения наилучших показателей по быстродействию и затратам обо-
рудования при реализации сверток следует произвести детальный анализ
информационных путей и выполнить коррекцию связей. Составление рас-
писания продвижения данных в конвейерных структурах позволяет избежать
возможных ошибок рассинхронизации потоков данных и скорректировать
задержки параллельных каналов, выделить общие компоненты, присутст-
вующие в параллельных потоках, и в некоторых случаях объединить их, а
в данном случае также обеспечить объединение на входах сумматоров пира-
миды суммирования термов, наиболее близких по формату представления.
Рассмотрим процедуру составления расписания для узла двумерной свертки,
построенного из двух одномерных сверток вида (4.7).
Обозначим MI — набор данных, в том числе промежуточных, необходимых
для вычисления свертки среднего столбца окна изображения с центром в
точке с координатами {/, J}, RI — набор данных для вычисления свертки
правого столбца, а Li, — левого столбца того же окна.
Предполагаем, что блоки LUT реализованы в виде комбинационной логики,
а сумматоры и буферы — на триггерных ячейках с общей синхронизацией.
Рассмотрим рис. 4.11.
Пусть в некоторый момент времени на вход узла поступают с FIFO -буферов
данные, соответствующие (i +1) -м пикселам строк j - 1 , j и j+1. На линиях А
и В этот момент присутствуют отсчет i-го пиксела j -й строки и суммы от-
счетов i-х пикселов строк j-1 и j+1, в совокупности составляющие набор Mi, -
для первого слоя конвейера. Но эти же данные являются исходными для
вычисления правого столбца предыдущего окна (Ri -1) и левого столбца сле-
дующего окна (Li+1). Одновременно на выходах сумматоров 1, 2, 9, 10 при-
сутствуют суммы соответствующих членов разложения (4.7) для предыду-
щего отсчета Mi-1, RI-2 Lt. Четыре верхние LUT воспроизводят умножение
входного набора на боковой столбец матрицы коэффициентов, а четыре
нижние — на центральный столбец матрицы коэффициентов. На выходах
Рис. 4 . 1 1 . Функциональная схема двумерного фильтра
сумматоров 4 и 11 находятся частичные суммы для набора данных Mi-2,

Ri-3, Li-1 и т. д. Чтобы соответствующие данные синхронно появились в
точках суммирования результатов свертки по столбцам, приходится включить
буферы задержки на один такт 3, 5 и 8. Например, в рассматриваемый мо-
мент времени сумматор 13 складывает свертку центральных столбцов мат-
риц, соответствующих (i -3) -му элементу строки со сверткой левых столбцов
тех же матриц, а на выходе сумматора 18 имеем окончательный результат

обработки для (j—6) -го пиксела j -й строки.
При рассмотрении путей реализации в ПЛИС основных процедур ЦОС
нельзя не обратить внимание на то, что большое число фирм предлагают
готовые решения в этой области, относящиеся к категории IP (Intellectual
Properties).
В частности, фирма Altera в составе библиотеки MegaCore предлагает набор
из более 60 мегафункций ЦОС, включающий КИХ -фильтры, медианный
фильтр, двумерные фильтры, процессоры быстрого преобразования Фурье и
быстрого косинусного преобразования, аудио - и видеокодеки, модули сжа-
тия сигналов и многое другое [32]. Модули оптимизированы и верифициро-
ваны для реализации в микросхемах семейств APEX и FLEX®, но многие из
них могут быть экспортированы в системы проектирования других фирм в
форме EDIF - и VHDL -файлов (хотя при конвертации эффективность реали-
зации может ухудшаться).
В частности, для синтеза, тестирования и реализации КИХ -фильтров фирма
Altera разработала специализированный компилятор. В рекламных материа-
лах фирмы утверждается, что использование этого компилятора уменьшает
время проектирования высокопроизводительных цифровых фильтров с не-
скольких недель до одного дня, а полученная реализация в десятки раз эко-
номичнее, чем реализация на стандартных процессорах ЦОС. Компилятор
имеет графический интерфейс и позволяет задавать вид частотной характе-
ристики, специфицировать формат данных, порядок фильтра, коэффициен-
ты интерполяции и децимации. В число опций проекта входит также вари-
ант структурной реализации — параллельная или последовательная. Обеспе-
чена стыковка со средствами проектирования системного уровня третьих
фирм, например MATLAB, Simulink, а также системами моделирования на
языках VHDL и Verilog.
Все это в значительной мере освобождает разработчика от рутинных работ
по синтезу, описанию и отладке фрагментов ЦОС проекта. Тем не менее
нам представляется, что материал данного раздела поможет разработчикам
лучше осознать основные проблемы и пути реализации ЦОС в структурах
программируемой логики, грамотно подойти к выбору того или иного вари-
анта, а при возможности осуществить необходимые доработки, исходя из
требований конкретного проекта.
4.4. Пример
автоматизированного проектирования
аппаратно -программной системы
Данный раздел посвящен рассмотрению полной проектной процедуры для
ПЛИС типа SOPC. Современные методы и средства проектирования рас-
смотрим на примере разработки микропроцессорной системы, являющейся
Глава 4. Примеры проектирования устройств с применением ПЛИС 56?
модернизацией более ранней разработки устройства на базе микроконтрол-

лера MCS -48. Реализация функций реального прибора, предназначенного
для увлажнения дыхательной смеси, с целью сокращения объема примера
существенно упрощена.
Так же, как в условиях реальных разработок, сузим область анализируемых
вариантов. При переходе на новую элементную базу проектировщик должен
стараться максимальным образом использовать ранее разработанные и про-
веренные решения, прежде всего, это касается фрагментов программного
обеспечения. В рамках этого пожелания в данном проекте достаточно есте-
ственным представляется при анализе возможных вариантов реализации
МП -ядра ограничиться рассмотрением вариантов, базирующихся на MCS -51,
поскольку при этом упрощается процедура перевода большинства решений
MCS -48 на MCS -51. В качестве элементов программируемой логики (кроме
специально оговоренных случаев) будем ориентироваться на продукцию
фирмы Altera. Это допустимо, поскольку проектируемый прибор не должен
обладать каким -либо исключительными свойствами — малым потреблением
мощности, обеспечением секретности разработки (наличием битов секрет-
ности), требованием радиационной стойкости и, соответственно, ориента-
ции на ПЛИС с пережигаемыми перемычками и т. д.
В состав разрабатываемой системы должен входить 12 -разрядный аналого -
цифровой преобразователь, записывающий по запросу параллельный код в
буферное ОЗУ емкостью 256 двенадцатиразрядных слов, 8 входов и 8 выхо-
дов для дискретных сигналов и блок сравнения двух входных восьмиразряд-
ных кодов с содержимым регистра уставок, которое задается программным
обеспечением МП -ядра и сохраняет значения текущих установок. Исполь-
зование схем класса СИС и МИС должно быть в модернизированном вари-
анте минимизировано за счет применения схем программируемой логики.
На начальном этапе проектирования осуществляется анализ и выделение
общесистемных ограничений на основе требований на разработку микро-
процессорной системы. Основным содержанием этапа является разделение
функций между программным обеспечением, опирающимся на стандартные
компоненты микроконтроллерной части системы, и специфическим аппа-
ратным обеспечением. На этом этапе разрабатывается архитектура про-
граммной части будущей системы и производится распределение задач по
возможным направлениям реализации. Поскольку в рамках данного раздела
нас преимущественно интересуют вопросы, связанные с разработкой аппа-
ратных фрагментов системы, то содержание и порядок разработки про-
граммного обеспечения подробно здесь рассматривать не будем. Для опре-
деленности будем считать, что для размещения ПО требуется не менее
16 Кбайт памяти. Стандартное для всех МП -систем оборудование (такое,
как последовательный канал, таймеры), обычно требуемое и используемое
при разработке и изготовлении реальных приборов, для упрощения примера
из рассмотрения исключены.
Будем считать, что требования к системе с указанием распределения функ-

ций между SW и HW могут соответствовать рис. 4.12. Необходимость аппа-
ратной реализации сравнения содержимого регистра уставок с данными ка-
налов В и С, так же как аппаратная поддержка режима записи данных в
блок памяти (RAM) и управление работой аналого -цифрового преобразова-
теля (ADC) связаны со скоростными требованиями к обработке соответст-
вующих данных. На рисунке требуемые блоки управления имеют названия
Cnt_cmp, cnt_ADC и будут использоваться в дальнейшем описании проекта.
Рис. 4.12. Функциональная схема аппаратно реализуемых фрагментов проекта
Для этого этапа проектирования характерно (как минимум, предваритель-

ное) согласование внешних и внутренних (между SW и HW) интерфейсных
функций разрабатываемой системы. В нашем примере сигналом, иниции-
рующим запись блока данных (128 слов) в память, является сигнал start,
а квитирующим сигналом, определяющим допустимость начала нового цик-

ла записи, является нулевое значение сигнала Busy. Запись в память должна
производиться в последовательности: старшие 8 разрядов результата преоб-
разования, младшие 4 разряда того же результата. О завершении записи
блока данных программное обеспечение МП -ядра должно быть проинфор-
мировано выставлением сигнала прерывания int.
4.4.1. Рассмотрение технического задания

на разрабатываемое устройство
и выбор элементной базы
Реализация проекта возможна в различных вариантах. В соответствии с при-
нятым соглашением анализироваться будут варианты, имеющие в качестве
МП -ядра тот или иной вариант контроллера MCS -51.
К основным можно отнести следующие варианты реализации:
использование обычного контроллера семейства MCS -51, автономных
средств аналого -цифровой обработки и размещение всей дискретной час-
ти проекта в ПЛИС (для конкретности будем ориентироваться на ПЛИС
фирмы Altera);
использование БИС класса SOPC generic фирмы Altera и мегафункции
фирмы CAST для реализации МП -ядра;
использование микроконтроллера, совместимого по системе команд с
MCS -51 со встроенными средствами аналого -цифровой обработки (для
определенности будем ориентироваться на применение БИС ADuC812
фирмы Analog Devices), и реализация недостающих дискретных элемен-
тов в ПЛИС фирмы Altera;
использование БИС класса SOPC фирмы Triscend семейства Е5, содер-
жащей в качестве МП -ядра встроенный микроконтроллер 8032 и кон-
фигурируемую логику типа FPGA, и реализация внешнего аналого -
цифрового преобразования (для определенности протокола будем ориен-
тироваться на применение БИС AD7892 фирмы Analog Devices).
Рассмотрим эти варианты более подробно.
Первый вариант реализации (рис. 4.13) предполагает использование в ка-
честве МП -ядра классической микросхемы MCS -51 (одну из БИС фирмы
Atmel) и применение БИС ПЛ фирмы Altera для реализации недостающих
дискретных компонентов. Необходимый объем памяти команд требует ис-
пользования БИС семейства AT87F55 или АТ89С55 либо применения внеш-
ней памяти команд (EEPROM Insraction), что в свою очередь предполагает
включение в состав ПЛИС специального регистра, защелкивающего стар-
шие разряды адреса, — Reg_BD. Требуемые объем и скорость заполнения бу-
ферной памяти заставляют при выборе типа ПЛИС ориентироваться на се -
мейства, содержащие встроенные блоки ОЗУ — т. е. типа FLEX10K. По-

следнее заставляет включить в состав устройства специальное загрузочное
ПЗУ (память конфигурации ПЛИС). Суммарные затраты на комплектацию
устройства составят сумму в несколько десятков долларов. Конструктивно
(как видно из рисунка) система должна содержать 5 или 6 корпусов ИС.
AT 89C51
data
Ain
PortD
Рис. 4.13. Вариант реализации проекта на БИС МК фирмы Atmel

и БИС ПЛ фирмы Altera
ПЛИС (ЕРХ10К50)
В/С
Рис. 4.14. Вариант реализации проекта на БИС ПЛ класса SOPC generic
Второй вариант реализации имеет укрупненную функциональную схему,

соответствующую приведенной на рис. 4.14. Основу проекта составляет
ПЛИС класса SOPC generic, конфигурация которой включает МП -ядро (на
базе стандартной мегафункции) и требуемую дополнительную логику: вы-

ходной регистр Reg_D, регистр формирования адреса памяти команд Rеg_BD,
входные регистры Reg_A, Reg_B и Reg_c, буфурное ОЗУ (RAM) и автоматы,
управляющие работой ADC и ОЗУ (Avt_RAM). Помимо БИС ПЛ схема со-
держит дополнительные элементы: ИС времязадающего генератора (OSC),
ИС ПЗУ конфигурации (EEPROM config), ИС ПЗУ команд (EEPROM
Instuction), ИС аналогового коммутатора (MUX) и ИС АЦ преобразователя
(ADC). Поскольку мегафункция микроконтроллера в этом варианте реа-
лизации требует (в зависимости от скоростных требований) от 2400 до
2860 логических ячеек, то для воплощения проекта понадобится БИС ПЛ
класса не ниже 10К50. Стоимость ее в варианте семейства FLEX10K превы-
сит 200 долларов, поэтому ориентация на такой проект будет экономически
неоправданной при выпуске даже опытной партии устройств. Реализация
этого варианта может иметь смысл только для ускорения проектных работ и
использоваться для прототипизации проекта. Перевод проекта на более со-
временные типы ПЛИС (например, схемы класса АСЕХ) существенно
улучшает экономические показатели (стоимость БИС не превысит 30 дол-
ларов), однако это приводит к необходимости построения системы с раз-
личными (5 и 3,3) уровнями питающих напряжений.
Третий вариант реализации (рис. 4.15) является самым экономичным по
числу требуемых для реализации системы числа микросхем. Основу схемы
образуют две БИС (БИС ADuC812 фирмы Analog Devices и БИС ПЛ фирмы
Altera). БИС ADuC812 фирмы Analog Devices разработчики отнесли к классу
микропреобразователей (MicroConverter), поскольку она содержит на одном
кристалле микроконтроллер, память, АЦП и ЦАП. Для реализации устрой-
ства дополнительно потребуется одна БИС конфигурационного ПЗУ
(EPROM) и одна ИС времязадающего генератора (OSC). Структура устрой-
ства, конфигурируемого в БИС ПЛ, сохраняет элементы предыдущих вари-
антов. Стоимость БИС класса ADuC812 фирмы Analog Devices не превыша-
ет 15 долларов, но и стоимость БИС ЕРХ10К10 фирмы Altera чуть больше
10 долларов. Приобретение средств, сопровождающих разработку, может
потребовать затрат порядка 100 долларов.
Последний вариант (рис. 4.16), опирающийся на продукцию фирмы
Triscend, потребует для своей реализации, помимо БИС семейства Е5, четы-
рех схем СИС (организация БИС семейства Е5 позволяет объединить в од-
ной БИС ПЗУ память команд МК и память конфигурации БИС ПЛ —
EEPROM). Блоки, реализуемые конфигурируемой системной логикой (CSL)
кристалла Е5, функционально совпадают с блоками, размещенными в БИС
ПЛ предыдущего варианта. Стоимость БИС семейства в зависимости от так-
товой частоты и количества конфигурируемых ячеек системной логики мо-
жет колебаться от 10 до 100 долларов. Сформулированные требования по-
влекут за собой использование ИС с логическими ресурсами, характерными
для БИС типа ТЕ5002. При выборе ИС аналого -цифрового преобразователя
для определенности остановимся, например, на продукции фирмы Analog

Devices — схеме AD7892 (12 -разрядном АЦП с возможностью приема ин-
формации в параллельной или последовательной формах).
ADUC812 плис
PortD
Рис. 4.15. Вариант реализации проекта на БИС ADuC812 и БИС ПЛ ЕРХ10К10
С экономической точки зрения основные затраты необходимо разделять на

затраты, необходимые для выпуска каждого экземпляра конечной продук-
ции, и на расходы, связанные с начальными вложениями в проект. В по-
следних, по -видимому, основную долю будут составлять затраты, связанные
с приобретением лицензии на требуемые САПР, и закупкой загрузочного
оборудования. Общие затраты типа NRE будут максимальными для трех по-
следних вариантов и могут достигать сумм порядка 170 долларов. Затраты,
связанные с выпуском отдельных экземпляров конечной продукции, скла-
дываются из стоимости комплектующих и стоимости изготовления. Хотя
стоимость комплектующих элементов будет минимальной для первого ва -
Triscend E5
PortD
Рис. 4.16. Вариант реализации проекта на БИС ПЛ класса SOPC

фирмы Triscend E5
рианта, стоимость изготовления и отладки аппаратуры для него в условиях

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

реализации проекта на кристаллах типа SOPC (в примере — БИС фирмы
Triscend), является возможность совершенствования и модернизации проек-
та, включая полное изменение аппаратной и программной начинки кри-
сталла (т. е., практически, реализацию других проектов), без каких -либо
конструктивных изменений.
Процедура декомпозиции проекта

После того как принято решение о базовых элементах проекта, разрабатыва-
ется предполагаемая архитектура аппаратной части будущей системы и про-
изводится распределение ресурсов по трем возможным направлениям реали-
зации. Отдельные фрагменты проекта при ориентации на кристаллы класса
SOPC могут строиться, используя возможности, предоставляемые:
предопределенными ресурсами МП -ядра;
ресурсами системной логики кристалла;
ресурсами интегральных схем, внешних относительно кристалла.
Следует подчеркнуть, что идеология реализации системы на кристалле при-
водит к отличиям таких систем от систем в многокристальном исполнении.
Первое отличие состоит в существенном увеличении скорости реализации
отдельных команд (это связано, в частности, с тем, что элементы системы
находятся на одном кристалле). Второе отличие состоит во введении допол-
нительных архитектурных элементов структуры (отсутствующих при класси-
ческой реализации той же структуры). Такими элементами для кристаллов
типа Е5 являются контроллеры ПДП и сторожевой таймер.
После выбора способов реализации двух частей устройства можно перехо-
дить к детализации технического задания на проектирование SW и HW БИС
SOPC.
Выбор САПР
Важное значение для быстрейшего и успешного завершения проекта имеет
принятие на этом этапе обоснованного решения об привлекаемых средствах
проектирования. На последних этапах проектирования (этапах монтирова-
ния проекта в БИС и подготовки конфигурационного файла) практически
всегда приходится обращаться к базовой САПР фирмы -производителя кри-
сталла SOPC. Для выбранного типа БИС SOPC семейства Е5 фирмы Triscend
необходимо ориентироваться на САПР под названием FastChip. Допустимые
для проектирования в САПР FastChip направления проектного потока при-
ведены на рис. 4.17.
Существование альтернативных вариантов выполнения проектного потока
связано с возможностью или необходимостью привлечения на определен-
ных ветвях проектирования САПР сторонних фирм. Поскольку в состав
Рис. 4 . 1 7 . Проектный поток в FastChip

FastChip не включены компиляторы для МК типа 8051, то подготовка про-

граммной части проекта обязательно требует привлечения каких -либо сис-
тем проектирования, ориентированных на разработку программного обеспе-
чения для MCS -51. Формально, проектирование может выполняться на
любой системе проектирования, но наилучшая стыковка с FastChip выпол-
няется для небольшого числа систем проектирования. Наилучшее и гаран-
тированное согласование обеспечивается при использовании инструмен-
тальных средств разработки фирмы Keil Software (www.keil.com) для семейства
микроконтроллеров 8051. Средства проектирования фирмы Keil поддержи-
вают все стадии разработки программного обеспечения. Программные сред-
ства включают средства компиляции с языков ассемблера и С, интегриро-
ванную среду разработки, содержащую отладчик и моделировщик. Для раз-
работки однопроцессорных многозадачных систем могут привлекаться
средства операционной системы реального времени RTX 51, входящей в со-
став САПР Keil Software. Поскольку вопросы разработки программного
обеспечения микропроцессорных систем выходят за рамки данного раздела,
далее будут затрагиваться только те аспекты разработки программного обес-
печения, которые тесно связаны с реализацией аппаратных частей системы.
Реализацию аппаратной части проекта принципиально можно выполнить,
опираясь только на возможности САПР FastChip Triscend. Однако трудно
реализовать сложные проекты, оставаясь в рамках библиотеки стандартных
решений, доступных из редактора САПР FastChip. Конечно, любой проект
может быть представлен в форме соединенных между собой примитивов,
которые входят в состав библиотеки САПР. Но принятый в редакторе
FastChip способ объявления соединений блоков путем использования сов-
падающих имен для соединяемых входных и выходных контактов блоков
оказывается не всегда удобным. Отсутствие отображения этих соединений
на экране так же далеко не всегда приемлемо. Этот вариант соответствует
одноуровневой организации аппаратной части системы. При составлении
сложных проектов и для их документирования целесообразно привлечение
САПР других фирм, которые могут поддержать иерархическое описание и
построение проекта. Практическая реализация такой возможности требует
выполнения ряда условий.
Во -первых, в САПР FastChip предусмотрен импорт описания блоков,
созданных в формате языка EDIF.
В настоящий момент библиотеки примитивов фирмы включены в состав
библиотек таких крупнейших фирм, как Innoveda и Cadence. Поэтому
для графического ввода проектов (или их фрагментов) могут использо-
ваться редакторы графического ввода ViewDraw фирмы Innoveda или
OrCAD Capture фирмы Cadence.
В структуру синтезирующих компиляторов фирм Synopsys или Synplicity
включено представление о структуре строительных элементов FPGA
фирмы Triscend, а также о правилах и возможностях их соединения меж -
ду собой. Поэтому для синтеза проектов, ориентированных на реализа-

цию в SOPC Е5, могут использоваться компиляторы FPGA Express или
FPGA Compiler II фирмы Synopsys или компилятор Synplify фирмы
Synplicity. Достоинство использования компиляторов этих фирм заклю-
чается в возможности составления проектов на языках высокого уровня
• VHDL и Verilog.
Во -вторых, САПР FastChip не содержит встроенных средств для верифи-
кации проектов. Однако поскольку САПР FastChip позволяет экспорти-
ровать созданный проект в форме описания на языках VHDL и Verilog,
то для верификации проектов могут использоваться моделировщики,
ориентированные на эти языки. В первую очередь, это хорошо зареко-
мендовавшие себя моделировщики VHDL - и Verilog -описаний фирмы
Model Technology, хотя, конечно, могут использоваться и другие моде-
лировщики, например, VCS и VSS фирмы Synopsys, VerilogXL фирмы
Cadence, SpeedWave VHDL Analyzer фирмы Innoveda и др.
Ускорения проектирования можно достичь, ориентируясь на использование
отладочных плат для выбранного семейства БИС (в нашем случае Е5). По-
добные платы выпускают фирмы Triscend и XESS. Применение отладочных
плат целесообразно не только на заключительных стадиях проектирования в
качестве прототипа будущего проекта, но и на начальных этапах для озна-
комления с особенностями проектирования данного типа SOPC.
4.4.2. Разработка аппаратной части БИС SOPC

Этап 1. ТЗ на проектирование аппаратной части БИС
Независимо от формы представления, ТЗ на проектирование аппаратной
части кристалла Е5 будет очевидно содержать следующие ключевые све-
дения:
объем буферного ОЗУ, выделяемого из общего объема памяти, соответст-
вует 256 двенадцатиразрядным словам;
запись в ОЗУ осуществляется блоками по запускающему сигналу start,
формируемым внешней средой;
начало записи блока данных в ОЗУ и ее завершение сопровождается со-
ответствующими изменениями сигнала Busy;
о завершении записи МП -ядро информируется выставлением сигнала int;
аппаратура SOPC управляет ADC, выставляя сигнал nconvstr;
сигнал nЕОС выставляется ADC после завершения процедуры преобразо-
вания;
чтение данных из ADC осуществляется аппаратурой SOPC путем выстав-
ления сигналов ncs и nRD в сторону ADC;
аппаратура SOPC обеспечивает передачу двенадцатиразрядных данных в

ОЗУ МП побайтно в два приема, формируя и анализируя необходимые
сигналы управления контроллера прямого доступа (DMA);
запись очередных данных в ОЗУ обеспечивается передачей сначала вось -
ми старших, а затем четырех младших битов данных.
Ресурсы CSL БИС Е5 использованы для реализации функции трех входных
ВОСЬМИРАЗРЯДНЫХ ПОРТОВ (Reg_A, Reg_B И R e g _ c ) И ОДНОГО ВЫХОДНОГО ВОСЬМИ -
разрядного порта (Reg_D).
Этап 2. Разработка общей структуры

аппаратной части проекта
Перечисленные выше пункты ТЗ определяют основные блоки проектируе-
мой системы БИС и их взаимодействие. Блочная схема устройства приведе-
на на рис. 4.18. На рисунке опущены соединения БИС SOPC с загрузочным
ПЗУ и схемой тактового генератора. Элементы структуры должны опираться
на ресурсы программируемой логики кристалла Е5 (CSL -логики). Функцио-
нальное назначение блоков следует из их названий. Схема укрупненно ото-
бражает следующие процессы.
Блок Cnt_Adc отвечает за управление отдельными циклами преобразова-
ния и запись одиночных данных от аналого -цифрового преобразователя в
промежуточном регистре. Блок обеспечивает прием блока данных задан-
ной длины и формирует сигналы, требуемые для записи принимаемых от
АЦП данных в ОЗУ МП.
Блок Cnt_cmp обеспечивает процедуру сравнения сигналов, поступающих
в порты МП А и в, и формирует необходимые внешние сигналы управле-
ния "больше", "меньше" или "равно". Выбор рабочего канала определяет-
ся входным сигналом в/с.
Следующим шагом проектировщика является обоснованный выбор средств,
при помощи которых будут проектироваться отдельные фрагменты проекта.
Как правило, специфические характеристики, свойственные проектируемым
фрагментам, позволяют определить рациональность применения того или
иного проектного средства. Для проекта, выбранного в качестве примера,
в аппаратной части Е5 можно выбрать ряд блоков, реализация которых це-
лесообразна с привлечением различных средств.
Для реализации блока управления приемом информации от аналого -
цифрового преобразователя (блок cnt_Adc) будем ориентироваться на
возможности, предоставляемые компилятором Synplify фирмы Synplicity.
Окончательным результатом работы компилятора при этом будет импор-
тируемый модуль на языке EDIF. Поскольку в качестве входной инфор-
мации для Synplify должен использоваться текстовый файл на языке
VHDL, то для подготовки текстового описания этого блока будут приме -
няться программные пакеты фирмы Mentor Graphic. Представляется сле-

дующая последовательность работ: графический ввод и составление тес-
товой процедуры Test -Bench с использованием САПР HDL Designer, а за-
тем верификация полученного VHDL -описания с помощью САПР Model
Technology.
ПЛИС Triscend E5
Рис. 4 . 1 8 . Блок -схема устройства, реализуемого программируемой CSL -логикой

кристалла Е5
Для реализации блока сравнения двух восьмиразрядных кодов с регист-

ром уставок (блок Cnt_cmp) будем ориентироваться на возможности, пре-
доставляемые графическим редактором САПР OrCAD. Как и для преды-
дущего фрагмента, окончательным результатом при этом будет импорти-
руемый модуль на языке EDIF.
Для реализации проекта на верхнем уровне иерархии будем ориентиро-
ваться на возможности, предоставляемые структурным редактором САПР
FastChip. На этом уровне обеспечивается подключение импортируемых
описаний блоков cnt_ADC и cnt_cmp как к внешним выводам кристалла,
так и к внутренней шине встроенного МП. Кроме того, на этом уровне
обеспечивается подключение к шине МП портов ввода/вывода цифровой
информации: выходного регистра Reg_D, входного регистра Reg_c, вход-
ных ПОрТОВ Reg_A И Reg_B И регистра уставок Reg_Ust.
В соответствии с принятым распределением функций проектируемого уст-
ройства последовательно рассмотрим проектирование блоков cnt_ADC,
Cnt_cmp и общей схемы.
Этап 3. Проектирование основных компонентов

блока Cnt_ADC— блока управления записью данных от АЦП
Функционально блок СNT_АDС решает следующую задачу — обеспечивает
управление процедурой получения блока данных от АЦП и передачу ее в
память МП, опираясь на ресурсы контроллера ПДП, встроенного в микро-
процессорную часть кристалла. Решение этой основной задачи сопровожда-
ется решением двух вложенных подзадач:
формированием необходимой последовательности сигналов, управляю-
щих работой АЦП, для получения 12 -разрядного кода результата с обес-
печением его временного сохранения;
формированием необходимой последовательности сигналов, управляю-
щих передачей сохраненных данных в память МП.
Общая структура блока Cnt_ADC приведена на рис. 4.19 (для удобства рас-
смотрения дополнительно на рисунке изображен и внешний аналого -
цифровой преобразователь ADC). Ключевым элементом схемы является авто-
мат управления Avt_ADC. Операционная часть фрагмента содержит два реги-
стра Reg_Buf1 и Reg_Buf2 для промежуточного хранения 8 - и 4 -разрядных
частей данных от АЦП, мультиплексор мuх, счетчик Count, отвечающий за
длину принимаемого блока данных.
Триггеры Т1 и Т2 введены в схему устройства для синхронизации сигналов
асинхронно работающих блоков — АЦП и автомата. Функциональное на-
значение управляющих сигналов очевидно. Сигналы, квитирующие обмен
блока данных, — start, Busy. Сигналы, квитирующие управление одиноч-

ным циклом преобразования АЦП, — nconvst, nЕОС. Сигналы, обеспечи-
вающие передачу данных от АЦП, — ncs, nRD и сигнал Load, обеспечиваю-
щий запись данных Data в регистры промежуточного хранения Reg_Buf1 и
Reg_Buf2. Сигнал Load используется одновременно для наращивания значе-
ния счетчиком count числа принятых слов. Начальный сброс счетчика осу-
ществляется сигналом Res_count. Состояние сигнала End_count указывает
заполнение буфера памяти.
Разбиение передачи 12 -разрядных кодов на две посылки потребовало раз-
биения регистра на две части (8 и 4 разряда) и введения сигнала ОЕ, управ-
ляющего съемом информации из этих частей. Мультиплексор мuх обеспечи-
вает подключение выхода выбранного промежуточного регистра (Reg_Buf)
к МП для передачи данных в память. Для одиночной передачи данных по
каналу прямого доступа к памяти (DMA) служит система квитирующих сиг-
налов Req_DMA И Ack_DMA.
Автомат синхронный — тактовый сигнал clk, сигнал асинхронного сбро-
са — Rst.
Проектирование управляющего автомата Avt_ADC

Возможный алгоритм работы автомата Avt_Aoc блока cnt_ADC, отвечающий
протоколу, необходимому для правильной работы БИС AD7892 фирмы
Analog Devices, может иметь вид, соответствующий схеме переходов автома-
та, приведенной на рис. 4.20. Схема переходов при помощи графического
редактора пакета HDL Designer Series фирмы Mentor Graphics была занесена
в соответствующий диаграммный файл.
Перейдем к описанию поведения автомата Avt_ADC, управляющего считыва-
нием данных из АЦП во временный регистр Reg_Buf и записью этих данных
в память МП, и поддерживающего для этих обменов требуемое взаимодей-
ствие квитирующих сигналов.
Основу алгоритма образует циклическая последовательность смены состоя-
ний, определяющая выполнение 128 циклов обрабатываемого блока.
Исходно (по сигналу Rst и по завершении цикла записи блока данных) ав-
томат находится в состоянии IDLE_ST. В этом состоянии автомат формирует
сигнал Busy, сигнализирующий о готовности к приему блока данных от
АЦП, и сигнал Res_count, обнуляющий счетчик числа циклов записи count,
и продолжает находиться в состоянии IDLE_ST до появления сигнала start,
который приводит к переходу автомата в последующее состояние START_ST.
В этом состоянии формируется сигнал запуска процедуры преобразования:
сигнал nconvst устанавливается в 0.
В состоянии WAIT1_ST автомат остается до тех пор, пока не поступит сигнал
готовности данных от ADC — сигнал nЕОС не станет равным нулю.
Signals Status
SIGNAL SCOPE DEFAULT RESET STATUS
Busy OUT '0' Comb
nConvSt OUT '1' Comb
Load OUT '0' Comb
OE OUT '0' Comb
Req_DMA OUT '0' Comb
nRD OUT '0' Comb
Res Count OUT '0' Comb
Рис. 4.20. Граф -схема переходов автомата управления Avt_ADC
В состоянии LOAD_ST формируются сигнал квитирования nRD для АЦП, сиг-

нал запуска записи данных Load от ADC в промежуточный регистр и сигнал
запроса DMA_Req к контроллеру ПДП. Одновременно с запросом подготавли-
вается передача в МП старшего байта данных из регистра, для чего форми-
руется сигнал ОЕ.
В состоянии WАIТ2_sт формируется сигнал ОЕ. В этом состоянии автомат ос-
тается до тех пор, пока не появится сигнал ACK_DMA, подтверждающий го-
товность МП к приему данных по каналу ПДП. По этому сигналу выходные
данные Reg_Buf1, находящиеся на выходе мультиплексора, переписываются
в ОЗУ.
В состоянии DMA_ST формируются новый сигнал запроса Req_DMA к контрол-
леру ПДП и подготавливается передача в МП младших 4 -х разрядов данных
из регистра Reg_Buf2, для чего снимается сигнал ОЕ.
Автомат безусловно переходит из состояния DMA_ST в состояние WAIT3_ST.
В этом состоянии он остается до тех пор, пока не появится сигнал ACK_DMA,
подтверждающий готовность МП к приему данных по каналу ПДП.
В состоянии ENDTR_ST анализируется сигнал End_Count. Если сигнал
End_count равен 1, что соответствует завершающему 128 циклу приема
оцифрованных данных от АЦП, то автомат переводится в начальное состоя-
ние IDLE_ST, в противном случае автомат переходит в состояние START_ST,
запускающее новый цикл преобразования.
Пояснения к синтаксису VHDL -программы устройства управления

Для автомата нашего примера с помощью программы пакета HDL Designer
Series фирмы Mentor Graphics была выполнена трансляция диаграммы. По-
лучен вариант, ориентированный на возможности языка высокого уровня
описания аппаратуры YHDL. Фрагмент кода, соответствующий заданному
автомату, приведен (с несущественными изменениями и сокращениями от-
носительно оригинала) в листинге 4.10.
— hds header_start
— hds header_end
LIBRARY ieee;
USE ieee.std_logic_l164.all;
USE ieee.std_logic_ariht.all;
ENTITY Avt_ADC IS
PORT(Clk, Start, Rst, nEOC, Ack_DMA, End_Count : in std_logic;
nConvSt, Busy, Load, Req_DMA, OE, nRD, Res_Count: out std_logic);
END Avt ADC;
— hds interface_end
LIBRARY ieee;
USE ieee.std_logic_ariht. all;
ARCHITECTURE fsm of Avt_ADC IS

— Architecture Declarations
TYPE state_values IS (IDLE_ST, START_ST, WAIT1_ST, LOAD_ST,
WAIT2_ST, DMA_ST, WAIT3_ST, ENDTR_ST,);
SIGNAL current_state, next_state: state_values;
BEGIN
cloced: process (Clk, Rst)

BEGIN
IF Rst = '1' THEN
current_state <= IDLE_ST;
— Reset Values
ELSIF rising_edge(Clk) then
current_state <= next_state;
— Default Assignment To Internals
END IF;
END PROCESS cloced;
NEXTSTATE: PROCESS (current_state, Start, nEOC, Ack_DMA, End_Count)

BEGIN
— Defaults Assignment
nConvSt <= '1';
Busy <= ' 1';
Load <= '0';
ReqDMA <= '0';
OE <= '0';
nRD <= '0';
Res_Count <= '0';
— Combined Actions
CASE current_state IS
WHEN IDLE_ST =>
Busy <= '0';
Res_count <= '1';
IF Start = '1' THEN
next_state <= START_ST;
END IF;
WHEN START_ST =>
nConvSt <= '0';
next_state <= WAIT1_ST;
WHEN WAIT1 ST =>
IF nEOC = 'О' THEN

next_state <= LOAD_ST;
END IF;
WHEN LOAD_ST =>
Load <= '1';
nRD <= '0';
Req_DMA <= '1';
OE <= '1';
WHEN WAIT2_ST =>
OE <= '1';
IF Ack_DMA = '1' THEN
next_state <= DMA_ST;
END IF;
WHEN DMA_ST =>
Req_DMA <= '1';
WHEN WAIT3_ST =>
IF Ack_DMA = '1' THEN
next_state <= ENDTR_ST;
END IF;
WHEN ENDTR_ST =>
IF End_Count = '1' THEN
next_state <= IDLE_ST;
ELSE
next_state <= START_ST;
END IF;
WHEN OTHERS =>
next_state <= IDLE_ST;
END CASE;
END PROCESS nextstate;
— Concurrent Statements
END fsm;
Разделы проектного модуля типичны для языка VHDL. В самом начале ука-
зывается используемая в проекте библиотека (IEEE). В заголовочном разделе
ENTITY перечислены имена и типы всех сигналов: входных внешних управ-
ляющих — тактового clk, начала работы с блоком start, начального сброса
Rst, окончания блока данных End_count, запроса на запись байта данных
Ack_DMA, флага готовности АЦП nЕОС и выходных управляющих — запуска
АЦП nconvst, квитирования АЦП nRD и ОЕ, управления счетчиком адреса
ResAdr, управления режимом записи буферного регистра Load, запроса ПДП
Req_DMA и управления внешним выходным сигналом Busy.
Следующий раздел — ARCHITECTURE — представляет собой описание архитек-
туры или поведения (в нашем случае поведения) блока, интерфейс которого
был описан в ENTITY. Как и в обычных языках, в начале раздела дается опи-
сание типов и объявление переменных, используемых при описании дейст-
вий, выполняемых в разделе ARCHITECTURE. В данном автомате определен пе-
речислимый тип данных STATE_VALUES со всем списком допустимых значе-
ний (они, естественно, совпадают с именами, введенными в граф -схеме
переходов). Далее в тексте объявлены два сигнала (signal): current_state и
next_state введенного типа STATE_VALUES. Введение двух сигналов связано
с необходимостью определения текущего и следующего состояний автомата
при переходе от одного состояния к другому.
Главная часть архитектурного тела содержит два оператора процесса. Пер-
вый процесс по имени clocked запускается на исполнение каждый раз, ко-
гда происходит изменение любого входного сигнала clk или Rst. При со-
ставлении программы автомата учитывалась необходимость его установки
в исходное состояние при подаче сигнала сброса: выражение IF (Rst='l')
THEN current_state<=IDLE_ST;. Однако его основное действие — назначение
автомату нового состояния — происходит только по переднему фронту сиг-
нала clk. Использование для тактирования автомата переднего фронта
синхронизирующего сигнала: предложение ELSIF (rising_edge (clk)) THEN
c u r r e n t _ S t a t e < = n e x t _ s t a t e ; END I F ; СЛУЖИТ ДЛЯ СИНХрОНИЗаЦИИ Выбранных
библиотечных операционных узлов и обеспечит стабильность входных
управляющих сигналов в моменты тактирования.
Поведение управляющего автомата в тексте программы задано вторым про-
цессом по имени nextstate. Процесс запускается каждый раз, когда изменя-
ется состояние автомата (current_state) или изменяется какой -либо вход-
ной сигнал. Содержимое этого процесса и определяет поведение управляю-
щего автомата.
В начале процесса выходные сигналы устанавливаются в начальные состоя-
ния, соответствующие значениям по умолчанию.
Последовательность смены состояний конечных автоматов в языке VHDL
удобно описывать посредством оператора выбора CASE, используя в качестве
ключа выбора варианта переменную состояния автомата в текущий момент
времени (current_state). Внутри каждого варианта определяется состояние
перехода и значения выходных сигналов, формируемых в соответствии с
входными условиями. Состояние перехода из текущего состояния в сле-
дующее осуществляется с помощью оператора назначения переменной
next_state нового значения. В тех случаях, когда переход из текущего со-
стояния зависит от внешних сигналов, этот оператор назначения входит
в состав условного оператора, логическое выражение которого совпадает с
последовательностью условий, встречающихся на соответствующих путях
переходов на схеме алгоритма. Аналогично определяются и выходные сиг-
налы, вырабатываемые на переходах и задающие исполняемые в других бло-
ках операции.
Компиляция из графической формы в текстовую осуществляется многими

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

Для проверки правильности составления и работоспособности автоматов
необходимо проведение тестовых испытаний. Возможны разные подходы
к организации тестирования. Наибольшее распространение получили сле-
дующие варианты.
В первом случае программа САПР, создающая текстовое описание авто-
мата (такая как, например, программа StateCAD), проверяет наличие
комбинаций входных сигналов, соответствующих неопределенному на-
правлению перехода автомата, и поэтому требует формирования полного
перечня входных сигналов, однозначно определяющих направления пе-
реходов.
Второй подход состоит в том, что используемая САПР может обеспечи-
вать так называемый режим анимации. В этом режиме САПР последова-
тельно проходит по всем состояниям автомата. Переход в очередное ак-
тивное состояние осуществляется путем установки желаемых значений
входных сигналов. Таким образом, в интерактивном режиме разработчик
может проверить все нужные состояния, переходы и значения выходных
переменных, меняя на каждом шаге значения входных переменных.
В общем случае проверка работоспособности автомата (созданного любым
способом) может осуществляться на основании традиционных методов соз-
дания тестирующих программ (Test -Bench). Современные САПР упрощают
этот подход, предлагая автоматическое создание тестового блока Test -Bench.
Возможности автоматизации изменяются в достаточно широких пределах: от
автоматического формирования только интерфейса блока Test -Bench до ав-
томатического формирования последовательности входных сигналов, обес-
печивающей перебор всех возможных состояний автомата. Для рассматри-
ваемого примера проектирования было целесообразно ориентироваться на
возможности пакета HDL Designer в части формирования тестирующих
программ Test -Bench. Поэтому пакет был запущен на создание Test -Bench и
автоматически сформировал ENTITY для тестирующей программы. Для за-
полнения архитектурного тела можно использовать любые редакторы, вхо-
дящие в состав HDL Designer, например графический редактор описания
потоков Flow Chart или редактор таблиц истинности Truth Table.
"Подводные камни" могут ждать проектировщиков не только при организа-

ции 'переходов. Особое внимание при проектировании автоматов следует
уделять вопросам формирования выходных сигналов. Выходные сигналы
могут назначаться как выход простой комбинационной схемы или как вы-
ход триггерной схемы, тактируемой синхросигналом. В результате каждый
из вариантов оформления имеет свои особенности. Наиболее важным поло-
жительным свойством триггерных выходов является гарантированное отсут-
ствие паразитных просечек (рисков), обусловленных ярусной организацией
логических схем. В отличие от триггерных, комбинационные выходы обес-
печивают изменение их состояния сразу после изменения входных сигналов
(асинхронное изменение), что для ряда практических приложений может
представляться существенным свойством.
Отмеченное выше положение делает целесообразным организацию допол-
нительных исследований, например, вариантов тестирования, основанных
на моделировании поведения автомата при его воплощении в базисе логи-
ческих ячеек, близких по структуре к будущей реализации. Для ячеек CSL
SOPC типа Е5 фирмы Triscend сходные логические ячейки реализованы,
например, в ПЛИС фирмы Altera типа АСЕХ. Простота организации мо-
дельных экспериментов в САПР MAX+PLUS II делает допустимым и целе-
сообразным проверку поведения автомата при реализации его модели в
БИС типа АСЕХ. Конечно, проведение таких экспериментов потребует об-
работки VHDL -описания автомата, например, компилятором Synplify фир-
мы Synplicity и далее передачу EDIF -файла в САПР MAX+PLUS II для
компиляции в БИС АСЕХ. Предварительная обработка VHDL -описания
пакетом Synplify целесообразна не столько из соображений достижения
лучших результатов компиляции, сколько для получения возможности про-
извести анализ скомпилированной САПР структуры на регистровом и вен-
тильном уровнях.
Разработка общей структуры блока Cnt_ADC

Описание блока cnt_ADC может, как и в большинстве других проектов, ори-
ентироваться на различные возможности и средства описания, предостав-
ляемые САПР HDL Designer. Допустим как поведенческий, так и структур-
ный подход. Наиболее компактным и быстрым способом спецификации
блока является создание его текстового описания. Для демонстрации воз-
можностей САПР HDL Designer воспользуемся структурным редактором
САПР и будем ориентироваться на использование элементов стандартных
библиотек пакета. Структурная схема блока cnt_ADC приведена на рис. 4.21.
При ее составлении использовались стандартные элементы библиотеки
HDL Designer ModuleWare:
- два одиночных D -триггера adff;
- четырехразрядный банк триггеров df f;
- восьмиразрядный банк триггеров df f ;

- восьмиразрядный счетчик cntr;
- один восьмиразрядный мультиплексор 0mux2;
- четырехразрядная константа нуля.
dataH
dout
Ack DMA
Start
nEOC
nConvSt
Busy
Req_DMA
Рис. 4 . 2 1 . Структурная схема блока управления Cnt_ADC

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

константы нуля диктуется требованием выравнивания разрядностей, запи-
сываемых по каналу данных ПДП.
В состав блока включен и ранее разработанный и протестированный модуль
автомата Avt_Adc.
На заключительном этапе структурная схема блока cnt_ADC транслировалась
на язык VHDL. Далее использовался компилятор Synplify фирмы Synplicity
для получения EDIF -файла, который будет в дальнейшем импортироваться
в САПР FastChip Triscend для создания требуемой аппаратной части разра-
батываемой системы.
Этап 4. Проектирование блока Cnt_Cmp

Спецификация блока Cnt_cmp выполнялась на базе возможностей, предос-
тавляемых графическим редактором Capture OrCAD фирмы Cadence. Схема
блока приведена на рис. 4.22. Основные элементы схемы: двухвходовые
мультиплексоры мuх2 и схема сравнения COMPS выбраны из библиотеки при-
митивов фирмы Triscend. Для этого библиотека была специально подключе-
на к САПР OrCAD. После составления схемы требуется проверка ее пра-
вильности, для чего должны использоваться стандартные средства пакета
OrCAD. На заключительном этапе разработки осуществляется трансляция
списка соединений примитивов схемы в конфигурацию логических ячеек
SOPC фирмы Triscend. В результат получается EDIF -файл, который также
будет в дальнейшем импортироваться в САПР FastChip Triscend для созда-
ния требуемой аппаратной части разрабатываемой системы.
Этап 5. Проектирование общей схемы —

сборка проекта из отдельных фрагментов
Нетрудно видеть, что на верхнем уровне иерархии для реализации рассмат-
риваемого устройства (рис. 4.23) из библиотеки элементов САПР FastChip
можно использовать следующий набор библиотечных настраиваемых модулей:
- Три группы восьмиразрядных элементов (в результате образующих тра-
диционные входные порты МП -ядра):
• входные контакты — Inp_A, Inp_B, Inp_c;
• входные буферные регистры RD — Reg_A, Reg_B, Reg_c;
• адресные селекторы — AdrSel_A, AdrSel_B, AdrSel__C.
- Две группы восьмиразрядных элементов (в результате образующих тра-
диционные выходные порты МП -ядра):
• выходные буферные каскады WR — WR_D, WR_Ust;
• адресные селекторы — Adrsel_D,
• ВЫХОДНЫе регистры — Reg_D, Reg_Ust.
Рис. 4.23. Структура конфигурируемых аппаратных ресурсов

проектируемой системы
- Для организации ввода данных в ОЗУ по линии ПДП требуется использо-

вание входного буфера Reg_DMA и связанного с ним селектора адреса DMA.
Кроме библиотечных модулей в схему необходимо импортировать файлы
EDIF, определяющие конструкцию блоков Cnt_ADC и Cnt_cmp. Для подклю-
чения управляющих сигналов к входам автомата Cnt_ADC используется мо-
дуль входных контактов — Inp_cnt.
Понятие параметризированных модулей соответствует возмЪжности настро-
ить выбранный библиотечный элемент на определенный режим функцио-
нирования, на определенную разрядность данных, их полярность и т. д.
Построение проекта в САПР Triscend FastChip состоит в образовании тре-
буемой схемы из используемых в проекте модулей путем описания соеди-
нения модулей между собой. Модули будут соединены друг с другом, если
к их выводам приписать цепи (net) с одинаковыми именами. Поскольку
схема соединений непосредственно не отображается на экране, разработчик
должен следить за правильностью соединений.
После определения структуры аппаратной части проекта (ресурсов CSL)
разработчик задает расположение внешних контактов аппаратной части сис-
темы по периметру кристалла.
Следующий шаг проектной процедуры связан с проверкой корректности по-
строения конфигурируемой части проекта. САПР проверяет правила созда-
ния проекта и выдает предупреждения или сообщения об ошибках. Проек-
тировщику сообщаются имена неподключенных цепей или цепей, имеющих
несколько источников сигналов, и т. д.
После проверки корректности САПР может быть запущена на выполнение
процедуры распределения логических ресурсов по кристаллу и образования сис-
темы их соединений (в терминологии фирмы Triscend процедура носит на-
звание Bind, связывание). Результатом этой процедуры является создание
файла конфигурации программируемой логики кристалла. Теперь САПР
готова в любой момент времени загрузить созданную конфигурацию в кри-
сталл. Если предполагается отладка только автономно работающих (без про-
цессора) аппаратных ресурсов, то можно приступать к работам, описанным
в разд. 4.4.5. Встроенные в кристалл Е5 средства внутрикристальной отладки
создают уникальные возможности для настройки аппаратных решений.
4.4.3. Настройка
предопределенных ресурсов кристалла
Поскольку мало вероятно, что проектировщик выбрал для реализации сво-
его проекта кристалл SOPC, но собирается опираться в проекте только на
аппаратные ресурсы кристалла, то, как правило, далее разработчик присту -
пает к действиям, связанным с использованием встроенного в кристалл

SOPC процессора и его периферийных узлов. Эти действия предполагают
разработку той части программного обеспечения микропроцессорного ядра,
которая обеспечит правильную настройку начальных параметров перифе-
рийных блоков, а также тех блоков и аппаратных связей, которыми процес-
сор связан с программируемой логикой (разработанной проектировщиком
аппаратурой). В рассматриваемом примере необходима инициализация двух
блоков. Это контроллер прямого доступа к памяти и контроллер прерыва-
ний. Задание параметров предопределенных (Hardcore) ресурсов кристалла
в САПР FastChip осуществляется в интерактивном режиме путем выбора
пиктограмм периферийных устройств и заполнения соответствующих опций
выпадающего меню. За начальную настройку процессорных ресурсов в
САПР FastChip отвечает так называемый заголовочный файл.
Создание заголовочного файла

После спецификации всех аппаратных ресурсов САПР Triscend FastChip
выполняет программу вторичной инициализации (Secondary initialization),
которая формирует заголовочный файл (Tailored Header File format). Основ-
ная особенность формата этого файла состоит в том, что он содержит на-
значение логических адресов для символьных имен объектов, использован-
ных в проекте. Это является одним из удобств, предлагаемых системной ин-
теграцией. Имена всех пользовательских модулей области CSL кристалла,
связанных с интерфейсной шиной (CSI Bus) микропроцессора при помощи
селекторов адреса, становятся автоматически доступными программному
обеспечению микроконтроллера и могут использоваться на последующих
этапах проектирования программной части проекта, включая компиляцию,
верификацию и отладку.
4.4.4. Разработка программного обеспечения

Разработка программного обеспечения для кристаллов Е5 практически ни-
чем, кроме отмеченных выше свойств расширенной версии заголовочного
файла, не отличается от стандартного процесса разработки программного
обеспечения. Эта разработка должна осуществляться с помощью внешних
относительно Triscend FastChip компиляторов, поскольку САПР не содер-
жит интегрированных в нее подобных средств. В качестве средств разработ-
ки программной части проекта может использоваться большинство сущест-
вующих компиляторов (таких как Franklin, IAR, Tasking и т. д.), однако
более полную интеграцию с пакетом Triscend FastChip могут обеспечить ин-
струментальные средства разработки программного обеспечения фирм Keil
Software или Archimedes Software. Именно поэтому фирма Triscend рекомен-
дует пользоваться указанными средствами.
Инструментальные средства разработки программного обеспечения совре-
менных САПР (такие как продукция фирмы Keil Software) позволяют не
Глава 4. Примеры проектирования устройств с применением ПЛИС 59/
только, разрабатывать прикладные программы на языке ассемблера или С,

но и, что очень важно, поддерживают все стадии их разработки. Для фирмы
Keil Software — это интегрированная среда разработки mVision и высоко-
уровневый отладчик -симулятор dScope. Интегрированная среда разработки
осуществляет настройку всех программ пакета и управление всеми стадиями
разработки, включая вызов специализированного текстового редактора
(цветовое выделение синтаксиса и диалоговое исправление ошибок), вызов
менеджера проектов (простая интеграция различных файлов в проект) и вы-
зов отладчика.
Как правило, разработка программного обеспечения микроконтроллеров
состоит из написания трех основных частей: заголовочного файла (Header
File), основной программы (Main Function) и подпрограмм обработки пре-
рываний (Interrupt Service Routine, ISR).
В рассматриваемом примере вопросы разработки программного обеспечения
микропроцессорной системы рассматриваться не будут. Новой разработки
практически не требуется, поскольку модернизация ранее существующей
системы почти не изменила функционирования элементов, связанных с
программным обеспечением МП. В своей основе программное обеспечение
берется от старой разработки. Исключение составляют фрагменты, связан-
ные с новым объектом — контроллером прямого доступа к памяти. Про-
граммная реализация режима ПДП в Triscend E5 осложнена тем, что кон-
троллер прямого доступа поддерживает доступ к расширенному относитель-
но стандартного (MSC -51) 64 -килобайтного пространства данных. Однако
в результате при помощи контроллера ПДП можно, например, получить
доступ к внешней относительно кристалла памяти команд или данных.
Компиляция и создание объектного кода

После создания всех модулей программной части проекта выполняется его
компиляция. Время создания объектного кода программного обеспечения
наступает после того, как объектный код отдельных модулей программы
синтаксически и логически отлажен. Для Keil Software этому соответствует
вызов директивы создания объектного кода. Созданный в результате компо-
новки файл может далее впрямую использоваться САПР Triscend FastChip.
Разработка на этом этапе завершается компиляцией кода программ и созда-
нием результирующего файла <project>.hex. Для обеспечения работоспособ-
ности создаваемого программного обеспечения целесообразна его отладка
в рамках симулирующих программ.
Кодовая симуляция и отладка

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

фирмы Keil Software не является исключением. Высокоуровневый отладчик -
симулятор dScope, входящий в состав комплекса, позволяет производить
отладку проектов на языке ассемблера, языке С или в смешанных форматах.
С его помощью путем моделирования поведения окружающей среды и пре-
допределенных ресурсов процессора (таймеров, параллельных или последо-
вательных каналов ввода/вывода и т. д.) можно производить отладку про-
граммного обеспечения в пошаговом режиме или режиме работы с точками
останова. Удобство отладки обеспечивается возможностью легкой организа-
ции контроля за состоянием всех объектов программы в различных окнах
наблюдений. Кроме того, возможна также оценка производительности и
эффективности кодового представления программного обеспечения.
4.4.5. Монтирование ресурсов SOPC в кристалл

и комплексная отладка проекта
Следующим этапом работ является создание загрузочного файла. Загрузоч-
ный файл содержит информацию об аппаратной и о программной частях
системы, загружаемых в кристалл SOPC. Список цепей, соединяющих мо-
дули CSL, и информация, настраивающая вентили на требуемый режим
функционирования, берутся из файла конфигурации кристалла. А содержи-
мое памяти программ микропроцессорного ядра — из выходного файла па-
кета Keil Software.
Загрузка проекта
Как и большинство других БИС ПЛ, семейство кристаллов Е5 фирмы
Triscend позволяет загружать проект в реальный кристалл различными спо-
собами. Загрузка в оперативную память БИС Е5 может выполняться из
внешней последовательной памяти типа EPROM или из внешней парал-
лельной памяти типа SRAM, Flash Memory или EPROM. Загрузка проекта в
постоянную память обычно является финальным действием в проектной
процедуре. Наличие же возможности загружать проект в ОЗУ реальных
микросхем непосредственно из персонального компьютера (с помощью
JTAG -интерфейса) позволяет построить более эффективную процедуру ве-
рификации проекта как при отладке прототипа, так и при натурных экспе-
риментах на конечной продукции.
Натурная отладка проекта

Обычно совместная отладка функционирования аппаратных и программных
частей системы возможна только после создания опытного образца системы.
Для отладки кристаллов типа SOPC могут использоваться как традиционные
средства и методы (рассмотренные в предыдущих разделах), так и методы,
Глава 4. Примеры проектирований устройств с применением ПЛИС 593
учитывающие возможность перепрограммирования БИС ПЛ, т. е. структу-

ры, обрамляющей микропроцессор или микроконтроллер. Более того, могут
быть разработаны специальные тестовые конфигурации (нередко опираю-
щиеся на тестовые варианты ПО МК), которыми следует пользоваться не
только на этапе проверки результатов проектирования, но и на этапах изго-
товления, выпуска или контроля промышленной продукции.
Весь комплекс средств, связанных с проектированием программируемой
логики класса реконфигурируемых систем на кристалле (CSoC), начиная от
архитектуры кристаллов и кончая ресурсами САПР, поддерживающих соз-
дание реальной аппаратуры на всех этапах разработки, позволяет сущест-
венно уменьшить время проектирования и ускорить выпуск конечной про-
дукции на рынок.
Для ускорения разработок проектов фирма Triscend, как и большинство
других фирм производителей БИС ПЛ, выпускает специальные отладочные
средства, например плату Triscend Evaluation Board, содержащую в своей
основе кристалл TE520S40.
Другой отладочной платой является демонстрационная плата myCSoCKit,
разработанная фирмой XESS Inc., USA и содержащая в своей основе кри-
сталл TE505S16.
Как уже отмечалось, кристаллы Е5 фирмы Triscend поддерживают расши-
ренный вариант JTAG-интерфейса, обеспечивающего загрузку программной
и аппаратной частей проекта внутрь кристалла. Допустимы два варианта
комплексной отладки проекта. Один состоит в использовании сначала про-
тотипных плат и лишь затем в переходе к отладке в конечной системе, дру-
гой сразу ориентируется на отладку в выпускаемой продукции.
Заложенные в кристалл Е5 уникальные возможности внутрикристальной
отладки позволяют САПР FastChip работать не только в режиме редактиро-
вания и компиляции проекта, но и в режиме отладки реальной аппаратуры
(Real-Time In-System Debug). На эти же возможности могут опираться и ти-
повые инструментальные средства отладки микропроцессорных систем
(например, уже упоминавшийся пакет фирмы Keil Software). Каждый из ва-
риантов имеет свои достоинства и целесообразные области применения.
Удобство и эффективность комплексной отладки аппаратно-программных
средств в САПР FastChip достигается за счет возможности устанавливать
точки останова в отлаживаемых программах путем занесения информации
в специальные встроенные в кристаллы Е5 аппаратные средства (Hardware
Breakpoint Unit). Переход САПР FastChip в режим отладки (Debug) сопро-
вождается открытием в основном меню дополнительного окна наблюдения
за отлаживаемыми объектами (Debug Watch).
Отладка аппаратуры непосредственно в FastChip имеет определенные огра-
ничения по наглядности и доступности к объектам по их символическим
именам. Поэтому отладку больших объемов программного обеспечения бо-
лее рационально производить, опираясь на режим отладки реальной аппара-

туры отладчика пакета Keil Software. Особенно удобен такой режим при от-
ладке программного обеспечения, разработанного на языке С. Установка
точек останова либо в исходном тексте программы, либо и в дизассемблер-
ной форме этого же текста существенно проще, чем установка абсолютных
значений точек останова в FastChip.
Вариант отладки проекта непосредственно в целевой системе имеет целый
ряд преимуществ по сравнению с отладкой при помощи моделирующих
программ и даже с прототипными системами. САПР позволяет загружать
отлаживаемый вариант программной и конфигурационной памяти в реаль-
ную БИС сразу целевой системы и отлаживать проект с требуемыми вре-
менными параметрами при наличии всего целевого окружения (Software и
Hardware). Информация о состоянии отдельных модулей проекта и величи-
нах, выбранных для наблюдения параметров, возможность модифицировать
величины адресуемых элементов проекта, потактовое или пошаговое выпол-
нение программы — все это позволяет существенно упростить процедуру
поиска обычно трудно локализуемых допущенных в проекте ошибок. Ряд
особенностей отладочного режима работы FastChip делает его похожим на
отладку с помощью внутрисхемных эмуляторов. Например, очень удобной
оказывается возможность наблюдения за значениями контролируемых объ-
ектов отлаживаемой системы с циклическим обновлением результатов.
Завершение проектирования БИС SOPC, включающей аппаратные ресурсы,
требуемые для функционирования микропроцессорной системы и отвечаю-
щей требованиям технического задания на разработку микропроцессорной
системы, позволяет приступить к выполнению заключительных этапов про-
ектирования, связанных с конструкторской разработкой всей системы цели-
ком в форме конечного продукта.
4.4.6. Разработка конструкции устройства

Исходной информацией для заключительного этапа проектирования, а
именно разработки конструкторско-технологической документации на пе-
чатную плату, содержащую проектируемую микропроцессорную систему,
являются не только данные о межсоединениях стандартных элементов сис-
темы, но и сведения о размещении сигналов по контактам ввода/вывода
БИС SOPC.
Ввиду того, что память БИС Е5 организована в форме SRAM, требуется ре-
шение о способе загрузки памяти конфигурации и памяти МП. Кристалл Е5
допускает использование различных видов БИС ПЗУ, хранящих загружае-
мую после включения питания память конфигурации и кода. Возможны две
основные формы загрузки: последовательная и параллельная. Загрузка из
последовательного ПЗУ требует значительных временных затрат, но зато
большее количество контактов БИС SOPC может быть использовано в каче-

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

лин, Ю. М. Барнаулов, В. А. Бердышев и др.; Под ред. С. С. Бадулина.—
М.: Радио и связь. 1981.— 240 с.
2. Автоматизация проектирования БИС. В 6 кн.: Практ. пособие. /Под ред.
Казеннова. — М.: Высш. шк., 1990.
3. Антонов А. П. Язык описания цифровых устройств AlteraHDL. Практи-
ческий курс. — М.: ИП РадиоСофт, 2001. — 224 с.
4. Антонов А. П., Мелехин В. Ф., Филиппов Ф. С. Обзор элементной базы
фирмы Altera. — СПб.: ЭФО, 1997. — 142 с.
5. Астапкович А. М. Микропроцессорные системы (тОСРВ) для встроен-
ных систем управления// в сб. "Информационно-управляющие системы
и сети"/ Под общ. ред. М. Б. Сергеева. — СПб: Политехника, 1999. —
248с.
6. Армстронг Д. Моделирование дискретных систем на языке VHDL / Пер.
с англ. Т. А. Теплицкого; Под ред. Ю. А. Татарникова. — М.: Мир,
1992. - 176 с.
7. Баранов С. Н., Котляров В. П., Морозов Н. Б. Технология разработки
программного обеспечения микроЭВМ: Учеб. пособие. — Л.: ЛПИ,
1989. - 96 с.
8. Бибило П. Н. Основы языка VHDL. — М.: Солон-Р, 1999. — 200 с.
9. Бродин В. Б., Шагурин И. И. Микроконтроллеры: Архитектура, про-
граммирование, интерфейс. — М.: Радио и связь. 1999. — 247 с.
10. Водяхо А. И., Горнец Н. Н., Пузанков Д. В. Высокопроизводительные
вычислительные системы обработки данных. — М.: Высшая школа,
1997. - 303 с.
11. Глушков В. М., Капитонова Ю. В., Летичевский А. А. О языках описа-
ния данных в автоматизированной системе проектирования вычисли-
тельных машин (ПРОЕКТ)/ Кибернетика. 1970. № 6. — с. 3—16.
12. Грушин С. И., Душутин И. Д., Мелехин В. Ф. Проектирование аппарат-

ных средств микропроцессорных систем: Учеб. пособие. — Л.: ЛПИ
им. Калинина, 1990. — 78 с.
13. Емец С. Verilog — инструмент разработки цифровых систем // Схемо-
. техника, № 1—4, 2001.
14. Кривченко И. Системная интеграция в микроэлектронике — FPSLIC //
Chip News. — 1998. — № 3. — с. 4.
15. Майоров С. А. Новиков Г. И. Структуры электронных цифровых вычис-
лительных машин. — Л.: Машиностроение, 1979. — 384 с.
16. Норенков И. П., Маничев В. Б. Основы теории и проектирования
САПР: Учеб. для втузов по спец. "Вычислительные маш., компл., сист. и
сети". — М.: Высш. шк., 1990. — 335 с.
17. Программируемые логические ИМС на КМОП-структурах и их приме-
нение / П. П. Мальцев, Н. И. Гарбузов, А. П. Шарапов, А. А. Кны-
шев. — М.: Энергоатомиздат, 1998. — 158 с.
18. Прэтт У. Цифровая обработка изображений. Т. 1—2. — М.: Радио и
связь, 1983.
19. Рабинер Л. Р., Гоулд Б. Теория и применение цифровой обработки сиг-
налов / Перевод с англ. А. П. Зайцева и др.; Под ред. Ю. Н. Александ-
рова. — М.: Мир, 1978. — 648 с.
20. Разевиг В. Д. Система схемотехнического моделирования Micro-Cap V. —
М.: Солон, 1997. - 273 с.
21. Разевиг В. Д. Система проектирования цифровых устройств OrCad. —
М.: Солон-Р, 2000. — 160 с.
22. Разевиг В. Д. Система сквозного проектирования электронных уст-
ройств DesignLab 8.0. — М.: Солон-Р, 2000. — 698 с.
23. Стешенко В. Б. ПЛИС фирмы ALTERA: проектирование устройств об-
работки сигналов. — М.: ДОДЕКА, 2000. — 128 с.
24. Соловьев В. В. Проектирование цифровых систем на основе программи-
руемых логических интегральных схем. — М.: Горячая линия — Теле-
ком, 2001. — 636 с.
25. Соловьев В. В., Васильев А. Г. Программируемые логические интеграль-
ные схемы и их применение. — Мн.: Беларуская навука, 1998. — 270 с.
26. Уваров А. Р. CAD 2000, ACCEL EDA. Конструирование печатных плат.
Учебный курс. — СПб.: Питер, 2001. — 320 с.
27. Угрюмое Е. П. Цифровая схемотехника. — СПб.: БХВ-Петербург,
2000. - 528 с.
28. Угрюмов Е. П., Грушвицкий Р. И., Альшевский А. Н. БИС/СБИС с ре-
программируемой структурой: Учеб. пособие. — СПб.: ТЭТУ, 1997. —
96с.
Список литературы 599
29. Чу Я. Организация ЭВМ и микропрограммирование. — М.: Мир. 1975. —

592с.
30. Шалыто А. А. Методы аппаратной и программной реализации алгорит-
мов. — СПб.: Наука, 2000. — 780 с.
31. Altera Digital Library CD-ROM. — 2001.
32. Altera: The DSP leader for programmable logic // News and Views. Altera. —
2000. - Feb. - pp. 31-32.
33. Altera presents hardcopy devices: the low-risk, low-cost solution for high-
density PLD // News and Views. Altera. — 2001. 4 quart. — pp. 31—32.
34. Ashenden P. J. The designer's guide to VHDL. — San Francisco: Morgan
Kaufman Publishers. — 1996. — p. 688.
35. Atmel Corporation Programmable Logic and System-Level ICs Data Book. —
Atmel Corporation. — 2000.
36. Boundary-Scan Tutorial, ASSET Inter Tech. Inc 2000. — p. 74.
37. Bursky D. Advanced CPLD Architectures Challenge FPGAs, Gas //Electronic
Design. - 1998. - № 22. - pp. 78-86.
38. Bursky D. Embedded Logic And Memory Find a Home In FPGA // Elec-
tronic Design. — 1999. — № 14. — pp. 43—56.
39. Bursky D. High-Density FPGA Family Delivers Megagate Capacity // Elec-
tronic Design. — 1997. — № 25. — pp. 67—70.
40. Chang D., Mazek-Sadowska M. Dynamically Reconfigurable FPGA // IEEE
Transaction on Computers. — 1999. — № 6 — pp. 565—578.
41. Cravotta R. EDN's 28 t h annual microprocessor/microcontroller Directory //
Electronic Design News. — 2001.— Sept. 27. — p. 33.
42. Cravotta R., Butler M.H. DSP directory 2001 // Electronic Design News. —
2001. - March 29. - p. 63.
43. Dipert B. ASICs get 'embed' with FPGAs // Electronic Design News. —
1999. - Aug 19. - p. 20.
44. Dipert B. Cunning Circuits Confound Crooks // Electronic Design News. —
2000. - October 12. - pp. 103-112.
45. Dipert B. Programmable — logic directory // Electronic Design News. —
2001. - Aug 30. - p. 36.
46. Dipert B. The best (or worst?) of both worlds // Electronic Design News. —
1 9 9 9 . - N o v l l . - p . 139.
47. Lipman J. New mixed-signal tools // Electronic Design News. — 1999. —
June 10. — p. 76.
48. Mercury programmable logic device family. — Altera data sheet. — 2001. —
Feb. - p. 83.
49. Maniak D. Design languages vie for system-level dominance // Electronic

Design. — 2001. — Oct. 1. — pp. 53—59.
50. Nelson Rick. Design Techniques Ensure Testable SOCs Test & Measurement
World, September 1999.
51: Palnitcar Samir. Verilog HDL: A guide to digital design and synthesis. — CA.:
SunSoft Press. Prentice HALL. — 1998. — p. 467.
52. Salcic Z VHDL and FPGA in Digital systems design, Prototyping and custo-
mization. — Boston/London: Kluwer academic Publishers. — 1998. — p. 548.
53. The Programmable Logic Data Book. — Xilinx. — 2000.
54. Thomas D, Moorby P. Verilog — hardware description language. — MA.:
Kluver Academic Publishers, 1994. — p. 320.
55. Verilog HDL Reference manual. — IEEE 1364 standard. — 1997.
56. VHDL для моделирования синтеза и формальной верификации аппара-
туры: сб. статей/ Под ред. Ж. Мермье; Пер. с англ. В. В. Топоркова и
Т. С. Трудовой; Под ред. В. М. Михова. — М.: Радио и связь, 1995. —
360с.
57. VHDL'92. Новые свойства языка описания аппаратуры VHDL /Ж.-М.
Берже, А. Фонкуа, С. Мажено, Ж. Руйар; Пер. с англ. А. И. Тихонова;
Под ред. В. М. Михова. — М.: Радио и связь, 1995. — 256 с.
58. VHDL Language Manual. - IEEE PRESS. - 1994.
59. Weiss R. Programmable Logic Now Bestows Configurability Upon All Kinds
Of Chips //Electronic Design. — 2001. — May 7. — pp. 58—64.
Предметный указатель
в
BIT VECTOR 328 Автомат.
О с памятью 215
О Мура 385, 388
О Мили 385
CPLD — сложные программируемые О режим анимации 583
логические схемы 34 Автоматизация:
О генерации тестовых векторов 287
О тестовых процедур 288
Автоматическая генерация тестовых
последовательностей 283
DLL, PLL — схемы управления Автоматическое создание тестового блока
синхросигналами 76 Test-Bench 583
Алфавит:
О моделирования 310
О моделирования девятиэлементный 311
FPGA — программируемые Аналоговые и смешанные поведенческие
пользователем вентильные матрицы модели 204
35,52 Аппаратные ядра 37, 68, 69, 91
Архитектурное тело 318
О поведенческое 320
I О структурное 320, 404
Архитектурно-структурное описание 221
IP — единицы интеллектуальной
Атрибуты 339
собственности 37
О массивов 341
О сигналов 342
О типов 339
Soft-ядро:
О процессора Microblaze 79
О процессора NIOS 91
SOPC: Базовые матричные кристаллы 28
О система на программируемом Базовые ячейки 29
кристалле 36, 67 Библиотека стандартных фрагментов 172
О с однородной структурой 67 Библиотека функциональных ячеек 29
602 Предметный указатель
д
БИС/СБИС:
О заказные 24, 25, 27, 29-31, 35-37,
41, 61, 75, 76, 80, 100, 101, 103, 104, Декларации:
107-110, 119 О ENTITY 318, 319
О полузаказные 29 О вхождения подпроекта 497
Блок BDM 294 О конфигурации 414
Блок управления 215 О объектов (VHDL) 324
Блоки ввода/вывода: О пакета 318, 319, 415
О CPLD43, 50 О прототипов компонентов 405
О FPGA56 О памяти 427
Блочные: О подпрограммы (Verilog) 455
О БМК29 О регистра 424
О SOPC со специализированными О цепи 424
ядрами 80 О цифрового автомата (AHDL) 490
О SOPC с процессорными ядрами 80 Декомпозиция проекта 143
О редакторы 215 Диапазон 329
Буферные примитивы 485 Динамические системы 151
Директивы компилятора (Verilog) 422
Дискретная событийная модель 307
В Драйвер сигнала 335, 338, 399, 423
Вентильные матрицы 28
Верификация проекта
на схемотехническом уровне 200
Виртуальные компоненты 68, 231, 239, Задача (Verilog) 455
251
Внутрикристальная отладка 212, 293, 593 И
О ПЛИС 284
Внутрисистемное программирование 188 Инструментальный компьютер 181
Внутрисхемная эмуляция 275 Интегрированная среда разработки 149, 591
Внутрисхемное программирование 292 Интегрированный пакет разработки PSoC-
Внутрисхемное реконфигурирование 293 систем 247
Встроенные блоки памяти 31, 61, 65, 71, Интеллектуальная собственность (IP)
75, 81, 131 сторонних фирм 239
Встроенные средства самотестирования Интерфейсный список 395
282 Информационный граф алгоритма 303
Выбор: Интегральные схемы:
О САПР 206 О на стандартных ячейках 26
О типа МП-ядра 180 О полностью заказные 26
О полузаказные 26
О элементной базы проекта 153
Итеративное уточнение моделей 256
Вызов:
О процедуры 396
О функции (Verilog) 456 К
Календарь событий 307
Клонирование проектов 106
Комментарии:
Градация быстродействия 119
О VHDL321
Граничное сканирование 266
О Verilog 423
Группы:
Компиляция:
О постоянные 473
О программ 186
О временные 477
О проекта 224
н
Конвейерный умножитель 383
Конвертация проектов 28, 100, 159
О из ПЛИС 171 Набор эталонных схем 112
Контроллер JTAG-интерфейса 275
Конфигурирование ПЛИС 592
Кооперационные САПР 209
Кросс-отладка 187
Кэш-логика 87 Обработка аналоговых сигналов 195
Объявление конфигурации 405, 412
Оперативное изменение поведения
Л системы 173
Оператор:
ЛИЗМОП-транзисторы: О блока 362
О двухзатворные 40 ° Verilog 453
О однозатворные 39 О варианта (Verilog) 445
Логические расширители 48 О включения (AHDL) 496
О возврата 397
м о вхождения
° компонентов 405
Макроячейки 42 ° Verilog 458
Маршрут проектирования аналогового О выбора:
блока 202 - VHDL349
- AHDL477
Матрицы:
О генерации 410
О распределения термов 48
О инициализации 434
О соединений 42
О непрерывный 434
Матричные БИС 29
О объявления прототипа (AHDL) 496
Метод:
О ожидания 352
О EPROM-прототипирования 188
О параллельный 318, 334, 359
О верификации 244
О последовательный 334, 343
О внутрисхемной эмуляции 192
О повторения 353
О встроенного монитора 190 ° AHDL 480
О встроенной внутрикристальной ° постоянного 436
отладки 193 О присваивания 344, 360
О стандартных ячеек 145 ° AHDL 474
О удаленной отладки 188 ° Verilog 436, 442
Методология: 0
блокирующий 442
О "сверху вниз" 143 D
неблокирующий 442
О "снизу вверх" 143 ° непрерывного (Verilog) 437
Механизм JTAG-интерфейса 269 ° по выбору 360
Моделирование: ° параллельного 360
D
О аналоговых фрагментов 196 последовательного 335
О многоуровневое 202 ° условного 360
О сквозное 306 О проверки
О событийное 307 - AHDL 505
- ASSERT (VHDL) 358
О управляемое событиями 243
О процедурный 434
О циклобазированное 244, 251 О процесса 334
Модель задержки: О пустой 348, 350
О инерционная 346 - VHDL.358
О транспортная 345 - AHDL 477
Модули интеллектуальной О таблицы (AHDL) 479
собственности (IP) 259 Продолжение рубрики см. на с. 604
Оператор (проб.): ПЛИС:

О условия: О оперативно репрограммируемые 40
° Verilog 444 О с комбинированной архитектурой 35, 61
° AHDL477 Подпрограммы (VHDL) 394
° VHDL 347 Подтипы 333
О условной генерации 504 Последовательный блок 453
Операции: Примитивы 462
О арифметические (Verilog) 432 О предопределенные 462
О логические (Verilog) 433 О определяемые пользователем (UDP) 463
О отношения и сравнения (Verilog) 432 Пробиваемые перемычки типа antifus 39
О свертки 433 Прогноз поведения 344
О сдвига (Verilog) 433 Программируемая матричная логика 32
О условные 434 Программируемые логические матрицы 32
Операционные системы реального Проектирование:
времени 184 О аппаратно-программных систем 237
Операционный блок 215 О аналоговых фрагментов 196
Описание аналоговых, цифровых О на концептуальном уровне 149
и смешанных блоков 202 О на основе МИС и СИС 146
Оптическая проверка печатных плат 292 О с иерархическим описанием 571
Отладка: о связи между МП-ядром и периферией
О в реальном масштабе времени. 294 147
О аналоговых и гибридных систем 203 Проектный модуль (Verilog) 420
О программного обеспечения 186 Прототипирование схем БМК схемами
Отладочные: FPGA/CPLD 169
О кросс-системы 187 Прототипные платы 228, 248, 593
О оборудование 195 Процедура:
О платы 572 О проектирования:
О средства 156 D
БИС по методу стандартных ячеек 164
О сценарии 284
° БИС по технологии БМК 166
Отладчик-симулятор 591, 592
° ИСПС154
Отлаживаемая система (Target-система)
О разработки программного обеспечения
188 180
Охранное выражение 363 О VHDL 394
Охраняемый оператор 363 Процесс проектирования 143
Оценки логической емкости 114 О организация 149
Процессорный генератор 259
п
Пакет 414
Память конфигурации типа Flash 40 Разрешаемые сигналы 399
Параллельный блок 453 Расширенные версии JTAG-интерфейса 292
Параметры: Реализация проектов на кристаллах SOPC
О в Verilog 430 569
О задержки 440 Реализуемое подмножество языка 507
О настройки 319, 320, 371, 406, 409, Регистры:
410, 417, 419, 497, 505 О AHDL482
Переменные и сигналы 334 О Verilog 423
Переносимость проектных решений 213 Редактор:
Периферийное сканирование 105 О временных диаграмм 226
Плавкие перемычки типа fuse 39 О для создания исходных файлов 186
Платформенно-базированное Режим отладки BDM 193
проектирование 259 Реконструкция проектов 106
Реконфигурация: Совместное:
О в системе 105 О описание устройства и средств
О на системном уровне 293 его тестирования 291
Реконфигурируемая прототипная о проектирование цифровых
система 261 и аналоговых фрагментов 211
О тестирование межсоединений
и функционирования БИС 274
Co-моделирование аппаратных
и программных частей системы 249
Самотестирование БИС 273 Сопряженная верификация 233
САПР: Сопряженное:
О для смешанного или иерархического О моделирование 233
проектирования 210 о проектирование 232
О независимых фирм 207 ° на базе языка С 248
О сквозного проектирования 210 Специализированные ИС 23
Секция: Спецификация:
О заголовка 468 О подпрограммы 395
О логическая (AHDL) 468 О проекта 234, 241
О предпроектная (AHDL) 468 О функциональная 257
Семейство микросхем: Способ описания проекта:
О АРЕХ20К/КЕ, АРЕХИ 70 О графический 216, 222
О Excalibur фирмы Altera 91 О поведенческий 217
О FLEX фирмы Altera 61 О структурный 217
О FPSLIC фирмы Atmel 82 О текстовый 216, 222
О ispPAC фирмы Lattice Semiconductor Способы конфигурирования ИСПС 104
95 Средства:
О Virtex, Virtex E.Vutex II фирмы Xilinx 74 О автоматизации системного этапа
0 E5 и A7 фирмы Triscend 88 проектирования 150
О CY8C25/26 фирмы Cypress О встроенного самоконтроля (BIST) 287
Semiconductor 98 о коммутации VersaRing 75
Сила драйвера 425, 441 О описания проекта 238
Синтез: О проектирования систем со смешанным
О и верификация логики граничного представлением сигналов 200
сканирования 287 Стандартные:
О тестов для проектирования пригодных О библиотеки классов
к тестированию проектов 289 для проблемно-ориентированного
Система: программирования 182
О автоматизированного проектирования О ИС23
аналоговых и аналого-цифровых Стандарты Verilog-AMS и VHDL-AMS 203
ИСПС 205 Стили программирования 303
О автоматического проектирования, Стратегия проектирования 141
Структура БМК:
САПР 140
О бесканальная 29
О межсоединений FPGA 58
О канальная 29
О моделирования устройств со Структуры с динамическим
смешанным представлением реконфигурированием 69
информации 200 Схемы с переключаемыми конденсаторами 94
О на кристалле 235
О разработки программного
обеспечения 181
Системный уровень автоматизации 241
Событийное управление 449 Таблицы (Verilog) 464
Co-верификационная процедура 257 Табличный ФП типа LUT 54
Тело: О разрешения 399

О оператора повторения 354 О VHDL394
О пакета 318, 415 Функциональная:
Тестирование: О спецификация 141
О межсоединений 270, 274 О ячейка 29
О печатных плат 264 Функциональные блоки CPLD 46
р проекта 226
О соединений элементов между собой
282
О функционирования БИС 271
Тестовые процедуры 269 Цепи (nets) 423
Технология стандартных ячеек 163 Цифровые автоматы (описание на VHDL)
Типы: 385
О BIT 326
О BOOLEAN 327
О CHARACTER 327
О INTEGER 326
О REAL 326 Частота работы системная 117
О STRING 328 Численные данные (VHDL) 326
О TIME 327 Число эквивалентных вентилей 111
О данных
AHDL 472
Время (Verilog) 428
действительный 428 Эмуляционные средства 246
логический Эмуляционный кристалл 193
символьный (AHDL) 471
Эмуляция ПЗУ 189
целочисленный (AHDL) 471
Этап:
целый (Verilog) 428
О массива 330 О декомпозиции проекта 214
<> памяти конфигурации 40 О системного проектирования 142
О перечислимый 328 О технологической реализации проекта
О физические, 330 156
О цепей триггерные 424 О отладки аппаратно-программных
систем 244
Эффективность:
О верификации проектов 212
Указание использования (Use Clause) 319 О совместного моделирования цифровых
Управление: и аналоговых схем 200
О временем 449
О процессами в реальном времени 183
О триггерами 373
а
асинхронное 373 Язык:
а
динамическое 374
о статическое 374 О взаимосвязи различных САПР
между собой Tel 209
О описания:
Ф ° RTLC 242
0
Superlog 242
Формулы Бэкуса—Науэра (BNF) 313 О системного уровня:
Функции: 0
описания 241
О преобразования: ° проектирования на базе языка С 252
° число— битовый вектор 380 Языки, связанные с тестированием
D
битовый вектор — число 380 аппаратуры 277
ect
КАТАЛОГ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

& Если вы хотите быть
в курсе всех последних
событии «а рынке
программного
обеспечения.
® Если вы хотите получать
наиболее полную
информацию
о программных продуктах
из первых рук -
от самих производителей»
119991 г. Москва,
ул. Губкина, 8 ® если вы ведете честный
www.softline.ru Лицензионное ПО
Подпишитесь на новый полноцветный каталог, издаваемый одним из крупнейших

поставщиков программного обеспечения в России, и вы будете регулярно получать
его по почте. Кроме того, по вашему желанию на ваш электронный адрес будут
регулярно приходить еженедельные новости рынка программного обеспечения
от компании SoftLine
Подписка БЕСПЛАТНО
для руководителей и специалистов
в области информационных технологий,
представляющих организации,
имеющие более 10 компьютеров!
ВЕСЬ МИР
компьютерных книг
Более 1600 наименований книг в
ИНТЕРНЕТ-МАГАЗИНЕ www.coinputerbook.ru

Проектирование Систем На Микросхемах Программируемой Логики

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Проектирование Систем На Микросхемах Программируемой Логики

Загружено:

Авторское право:

Доступные форматы

Ростислав Грушвицкий

Грушвицкнй Р. И., Мурсаев А. X., Угрюмое Е. П.

Группа подготовки издания:

Лицензия ИД № 02429 от 24.07.00. Подписано печать 10.08.02.

I S B N 5 94157 -002 -3 ° Грушвицкий Р. И., Мурсаев А. X., Угрюмое Е. П., 2002

Глава 1. Элементная база электронных устройств и систем.

1.7. СБИС типа "система на кристалле" с блочными структурами

Глава 2. Основы технологии проектирования ИСПС

Этапы кодирования и отладки программного обеспечения 186

Простые арифметические узлы 379

Устройство управления JTAG -интерфейса 275

Простые арифметические узлы 379

Глава 4. Примеры проектирования устройств с применением ПЛИС 513

Список литературы 597

Предметный указатель 601

Интересы России требуют преодоления сложившегося в последнее десяти-

Ряд работ посвящены описанию языков проектирования аппаратуры

при этом имели место взаимный обмен материалами и коллективное обсуж-

Что такое "микросхемы с программируемой структурой?" Почему они по-

вает распределение решения задачи не только во времени, аив пространст-

Благодаря программированию структур для электронной промышленности

размерности, конфигурируемые для выполнения фрагментов алгоритма оп-

ими. Такие индивидуальные части системы ранее приходилось строить с

Аппаратные ускорители вычислений также не являются чем -то существенно

чиная от описания проекта, его моделирования и отладки, вплоть до разра-

ных САПР встраивать в проект разнородные компоненты и использовать

1.1. Общие сведения. Предшественники.

Рис. 1.1. Классификация цифровых интегральных схем

К стандартным относятся следующие виды цифровых ИС.

- БИС/СБИС запоминающих устройств (Memory IC), относящиеся к наи-

Можно без преувеличения сказать, что вопросы реализации проектов на

делия с помощью индивидуальных межсоединений. Реализация требует из-

1.1.2. Базовые матричные кристаллы

с целью исключения из нее микросхем малого и среднего уровней интегра-

ричные) нужны только шаблоны рисунков межсоединений. Например, при

при программировании часть соединений под воздействием точно сфокуси-

1.1.3. Классификация логических микросхем

- типу памяти конфигурации ("теневой" памяти);

ределяется конструктивными параметрами матрицы — числом конъюнкто -

Программируемая матрица ИЛИ микросхем ПЛМ составлена из дизъюнк -

Микросхемы программируемых пользователями вентильных матриц FPGA

канонической архитектурой, а ПЛИС комбинированной архитектуры при

Класс SOPC делится на подклассы однородных и блочных систем на кристалле.

и здесь нужно отметить наличие у некоторых SOPC второго типа интер-

Р и с . 1.3. Классификация ПЛИС по признакам кратности программирования

В однократно программируемых ПЛИС используются элементы с необра-

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

ми порядка десятков-сотен, т. к. ультрафиолетовое облучение постепенно

триггера в состояние 0 или 1. В рабочем режиме триггер сохраняет неизмен-

1.1.4. Общие (системные) свойства

- Низкая стоимость, обусловленная массовым производством и высоким

1.2. CPLD — сложные программируемые

(PIA, Programmable Inerconnect Array). Число таких сигналов т. Выходные

Рис. 1.4. Обобщенная структура CPLD

Блоки ввода/вывода связаны с внешними двунаправленными выводами I/O,

(в частности, сигналов обратной связи). Необходимость в таких сигналах

1.2.2. Программируемая матрица соединений

ПМС были бы чрезмерно сложны, поскольку любое соединение образуется

1.2.3. Функциональные блоки CPLD

Рис. 1.6. Структура функционального блока CPLD

Основными частями функциональных блоков CPLD являются программи-

В CPLD матрица элементов ИЛИ чаще всего не является полностью фикси-

На рис. 1.8 раскрыта схема одной из идентичных макроячеек ФБ. Прообра-

Рис. 1.8. Пример схемы макроячейки функционального блока CPLD