Атрибут компилятора enum_encoding

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

Каждый символ состоит из последовательности «0» и «1». Символ «0» означает низкий логический уровень, символ «1» — высокий.

Рассмотрим пример объявления атрибута.

type is (, ,... ); attribute ENUM_ENCODING: STRING;

Спецификация атрибута определяет кодирование для перечисления литералов.

attribute ENUM_ENCODING of : type is «... »;

Символ задает представление , и т. д. Следует помнить, что применение этого атрибута приводит к несоответствиям моделирования при использовании, например, операторов отношения. Пример:

attribute ENUM_ENCODING: string; type COLOR is (RED, GREEN, BLUE, YELLOW, ORANGE); attribute ENUM_ENCODING of COLOR: type is «10000 01000 00100 00010 00001»; -- перечислимый литерал RED представляется как 10000, -- GREEN как 01000, и т.д.

Метакомментарии (Metacomments)

Метакомментарии используются для управления компиляцией. Существуют два типа метакомментариев:

-- RTL_SYNTHESIS OFF -- RTL_SYNTHESIS ON

Средства синтеза игнорируют любое описание на VHDL после директивы RTL_SYNTHESIS OFF и возобновляют процесс синтеза по директиве RTL_SYNTHESIS ON. В следующем занятии мы начнем рассмотрение синтезируемого подмножества языка Verilog.

26. Языки высокоуровневого описания аппаратного обеспечения.

1. Скриптовый подход к автоматизации тестирования

1.1. Состав текстовых языков поддержки тестирования

В системе HLCCAD реализовано интерактивное тестирование проектов, когда разработчик, остановив моделирование, может задать входные воздействия и проследить с помощью симуляции реакцию проекта на них. Кроме того, в системе поддерживается использование высокоуровневых компонентов (программ, написанных на языках типа Object Pascal или C++) для подачи входных воздействий и определения эталонных реакций. Однако наиболее привычным и соответствующим типичной квалификации разработчика аппаратного обеспечения является использование специальных скриптовых языков (наглядных для пользователя текстовых языков, интерпретируемых системой в процессе симуляции) для автоматизации тестирования. В системе HLCCAD реализовано три таких языка:

• Язык описания содержимого ОЗУ/ПЗУ используется для определения, по каким адресам ОЗУ/ПЗУ нужно записывать те или иные данные и какие именно. Поддерживаются распространенные стандартные форматы BIN и Intel Hex, а также собственный формат MEM (во многих случаях более удобный для разработчиков ввиду своей большей наглядности и компактности).

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

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

1.2. Универсальная поддержка скриптовых языков автоматизации тестирования

Сегодня можно отметить две важные тенденции в автоматизации тестирования проектов аппаратного обеспечения [4–6]: стремление к использованию скриптовых языков и отсутствие де-юре и де-факто стандарта такого языка.

Поэтому чрезвычайно важно обеспечить гибкость в поддержке подобных языков. В системах IEESD/HLCCAD/WInter обработка текстовых языков обеспечивается с помощью специально разработанного универсального синтаксического анализатора (UniSAn) [7, 8]. UniSAn обеспечивает возможность определить текстовый язык с помощью расширенных формул Бекуса—Наура; имеет средства для анализа и исправления ошибок в таких описаниях; по корректным описаниям строит сжатое автоматное представление описания языка.

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

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

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

2. Лингвистическое обеспечение автоматизации тестирования

2.1. Язык описания содержимого ОЗУ/ПЗУ

Система поддерживает несколько видов форматов. Среди них стандартные форматы Intel Hex и BIN. Кроме того, был разработан свой формат прошивки памяти MEM.

Файл прошивки памяти указывается в параметрах устройства (локальное меню над устройством в редакторе схемы пункт меню «Список параметров», далее имя памяти — Filename, ROM, Code memory). По расширению файла система выбирает формат файла:

• HEX — Intel HEX format;

• BIN — BIN format;

• иначе — MEM-формат.

Intel 8-bit Hex File Format — это обычный текстовый файл. Информация представлена в виде записей. Каждая запись это текстовая строка в файле. Записи могут идти в произвольном порядке. Значения представлены 2 или 4 цифрами в шестнадцатеричной системе счисления.

Формат записи:

:LLAAAARRDDDD......DDDDCC

LL	Поле длины. Длина записи в байтах.
AAAA	Поле адреса. Адрес первого байта.
RR	Поле типа записи. 00 – данные, 01 – конец записей.
DD	Поле данных.
CC	Поле контрольной суммы. Дополнение всех данных в записи по модулю 256.

Пример:

:06010000010203040506E4 :00000001FF

Первая запись в примере адресует с позиции 100H числа от 1 до 6. Вторая запись информирует о последней записи в файле.

Файл прошивки памяти «BIN».

Содержимое файла в формате BIN последовательно по байтам загружается в память устройства.

Файл прошивки памяти «MEM».

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

• $DD <Size> — размерность слова в битах (по умолчанию — 8);

• $A <Address> — номер слова, с которого будут прописываться следующие команды (по умолчанию — 0);

• $AN <Notation> — система счисления, в которой будет задаваться адрес (по умолчанию — 16);

• $DN <Notation> — система счисления, в которой будут задаваться данные (по умолчанию — 16).

Все слова, начинающиеся не с символа «$», считаются данными. При записи очередного значения указатель текущего адреса увеличивается на разрядность слова.

Символ «;» считается указателем комментариев. Все символы в строке после «;» не обрабатываются.

Пример:

0 0 $DD 16 $A F5 A0F0 10 101A 1663 $DN 2 011001 110010 1100101

2.2. Язык управления тестовыми воздействиями и эталонными реакциями

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

Любая схема разрабатываемого устройства может быть связана с собственным файлом тестовых воздействий (рис. 1.).

Файл тестовых воздействий (рис. 2) представляется в виде текстовых команд. Для анализа файла тестовых воздействий введено понятие текущего модельного времени. Эта величина определяет время активизации события в случае, если при его описании оно не определено. Например, разработчик может указать время установки значения на контакт в момент модельного времени, равного 5 пс.

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

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

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

Таблица 1. Формат языка тестов

Название	Правило	Описание
Установить значение	ItemName = ValueStr [Time] где	Устанавливает значение на контакт в указанный момент времени
	ItemName	В качестве ItemName можно указать имя контакта схемы или корпуса: «In1» или «Package1.In1». Можно устанавливать значения переменных моделей – значения памяти, регистров, битов или флагов: «Package1.R1». Если устройство содержит совпадающие имена (например, имя регистра и имя контакта), то перед именем ItemName можно дополнительно указать тип элемента в квадратных скобках – pin, mem или reg (например: [pin] In1=10[,2]).
	ValueStr	«Значения ValueStr могут содержать текстовую строку со значением, где дополнительно после запятой можно указать систему счисления значения. Указанная система счисления действует на все остальные значения в командах до следующего изменения.
	Time	Параметр Time задает время активизации команды. Допустимы два варианта: AT TimeValue – в указанный момент времени; AFTER TimeValue – после последней выполненной команды и спустя указанный интервал времени. TimeValue представляет собой время в пикосекундах. Дополнительно можно изменить масштаб времени, указав дополнительно тип: sec, ms, us, ns или ps.
Проверить значение	ASSERT ItemName LogicOper ValueStr [Time] [REPORT String] [SEVERITY MessageType]	Если условие не выполняется, то генерируется сообщение с типом SEVERITY и текстом REPORT. Тип сообщения (MessageType) может принимать следующие значения: Warning, Message, Fatal, Error. В качестве LogicOper можно указать: = – «Равно»;  – «Не равно»; > – «Больше»;  – «Больше или равно»; < – «Меньше»;  – «Меньше или равно».
Интервал времени	WAIT Time	Установить указатель модельного времени в указанный момент времени
	WAIT FOR Time	Увеличить указатель модельного времени на указанный интервал времени
Остановить моделирование	STOP_ Time	Остановить моделирование в указанный момент времени
	STOP_ FOR Time	Остановить моделирование после указанного интервала времени
Генератор значений	GENERATOR_ItemName GenParams END	В качестве GenParams можно указать параметры генератора. Параметры генератора разделяются запятыми.
	а) COUNT_	• COUNT_ Value – количество событий для генерации;
	б) FROM_ TO	• [FROM_] Time TO Time – интервал активизации;
	в) FROM_ RANGE	• [FROM_] Time RANGE Time – интервал активизации;
	г) DELAY_	• DELAY_ (Time, Time, ...) – величины пауз между значениями;
	д) INTERVAL_	• INTERVAL_ Time – величина паузы между значениями;
	е) FREQUENCY_	• FREQUENCY_ Herz – частота появления значений (Hz, kHz, MHz, GHz);
	ж) DATA_	• DATA_ (ValueStr2, ValueStr2, ...) – значения;
	з) FILE_	• FILE_ FileName – имя файла со значениями;
	и) PHASE	• PHASE_ Time – задержка перед первым значением. Если не указаны значения, то величина значения будет увеличиваться на единицу каждый раз при активизации генератора. Отсчет значений начинается с нуля. Интервал генерации по умолчанию равен 1 пс.
Работа с дампом памяти	LOAD FileName ON ItemName [Time]	Загрузить содержимое дампа памяти из файла прошивки
	DIFFMEM FileName ON ItemName [Time]	Проверить содержимое дампа памяти и содержимое файла прошивки

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

2.3. Язык управления пакетным тестированием

Язык управления пакетным тестированием (язык сценария) обеспечивает построение «сценария» автоматического тестирования.

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

• моделирование с учетом тестовых воздействий;

• моделирование сгенерированного по схеме VHDL-описания для тестирования системами сторонних фирм.

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

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

Описание метки всегда начинается с первой позиции в строке и заканчивается символом «:». Выполнение происходит с первой строки.

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

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

Языком сценария предусмотрено использование переменных для хранения промежуточных значений. Объявление переменной не требуется. При первом использовании имени переменной происходит ее инициализация. Например, при выполнении команды «Counter=10», будет выделено место для значения переменной «Counter» и записано в нее 10.

Операции над выражением имеют следующий синтаксис:

Value = Expression

В качестве Expression может быть записано любое арифметическое или логическое выражение с использованием скобок:

A=B+C; B=C*(A+B)-5; C=(A>B) or not (B+5<12);

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

Для обращения к значениям параметров, переданных после имени файла сценария, необходимо указать символ «%» и номер параметра (например, %5 или %12). Например, если были переданы параметры:

Test.CLD «D:\Project1.prd»

то в тексте сценария Test.CLD можно указать:

IncludeProject %1

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

В языке сценария также присутствует оператор ветвления:

IF Expression THEN

При условии, что выражение Expression не равно 0, происходит выполнение команд, расположенных после ключевого слова THEN. В противном случае происходит переход на следующую строку. Например:

IF ErrorCount>0 THEN ECHO «Incorrect device»

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

Таблица 2. Команды общего назначения

Правило	Описание	Пример
LoadDesktop FileName	Загрузить содержимое рабочего стола из файла, определенного параметром FileName	LoadDesktop «D:\Desktop.env»
IncludeProject FileName	Загрузить в «Инспектор проектов» проектный файл, определенный параметром FileName	IncludeProject «D:\Project1.prd»
ExcludeProject FileName	Отключить в «Инспекторе проектов» проектный файл, определенный параметром FileName	ExcludeProject «D:\Project1.prd»
ExcludeProjects	Отключить в «Инспекторе проектов» все проекты	ExcludeProjects
Language = LanguageName	Изменить язык системы на LanguageName	Langauge=»Russian»
Goto LabelName	Перейти на метку LabelName	Goto «Label1»
ExecSoft FileName [, Params]	Исполнить файл FileName с параметрами Params	ExecSoft «Programator.exe» ExecSoft «Programator.exe», «Device1»
Rem	Признак комментария – текст до конца данной строки игнорируется	Rem Это комментарий
Log = FileName	Изменить имя LOG-файла	Log «D:\LogFile.log»
FileToLog FileName	Вывести содержимое текстового файла FileName в LOG.файл	FileToLog «D:\NewLogFile.log»
SaveLog	Принудительно сохранить LOG.файл	SaveLog
Exit	Прервать выполнение	Exit
Set «echo» = on или off	Включить или выключить режим записи результата исполнения команд	Set echo=on
Call FileName	Выполнить сценарий из файла FileName	Call «D:\Script2.hcl
Message MessageType TextString	Передать сообщение пользователю, где MessageType – тип сообщения (Message, Error, Warning); TextString – текст сообщения	Message error «Ошибка»

Таблица 3. Команды для моделирования

Правило	Описание	Пример
Check DeviceName	Проверить устройство DeviceName на наличие ошибок	CheckDevice «Device1»
Run DeviceName	Выполнить моделирование устройства DeviceName	Run «Device1»
Trace DeviceName	Выполнить шаг моделирования устройства DeviceName	Trace «Device1»
Reset	Выключить режим моделирования	Reset

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

Project FileName

где FileName — это имя файла проекта. Следует отметить, что команда не подразумевает подключения проекта в случае его отсутствия в «Инспекторе проектов».

С помощью команды «Folder FolderName» происходит переход курсора на папку FolderName в текущей ветви. Для перехода на уровень выше нужно указать в качестве имени две точки «..». Допускается использование нескольких параметров FolderName, разделенных символом «\».

Пример команды запуска процесса симуляции устройства (номера строк приведены для нижеследующего комментария примера):

1 IncludeProject «D:\i8051.prd» 2 IncludeProject D:\HLCCAD\Projects\Standard\Standard.prd» 3 Project «i8051.prd» 4 Folder «Tests» 5 Run «Test i8051» 6 Reset 7 Folder «..» 8 Run «Tests\Test i8051» 9 Reset

Команды в первой и второй строке подключают проекты «i8051» и «Standard».

Команда в строке 3 устанавливает курсор на проект «i8051». Команда в строке 4 перемещает курсор в папку «Tests». После выполнения команды в 5 строке производится запуск симуляции устройства «Test i8051». После останова процесса моделирования выполняется команда в строке 6, которая выключает процесс симуляции. Команда в строке 7 перемещает курсор из папки «Tests» в «корень» проекта. Команда в 8 строке запускает процесс симуляции для того же устройства, что и в строке 5. Команда в 9 строке повторно выключает процесс моделирования.

Допускается принудительная установка файла тестовых воздействий для устройства командой «MTest = Expression», также указание предела моделирования «MLimit = Expression».

Для генерации описания на VHDL предусмотрена команда:

BuildVHDL DeviceName VHDLOpt

В качестве параметра DeviceName указывается имя синтезируемого устройства, а в качестве VHDLOpt — параметры генерации, разделенные символом «;». В качестве параметра можно указать:

• Dir=FileDir — каталог, в котором будут расположены генерируемые файлы;

• Test=True или False — признак генерации тестов;

• TestType=VHDL или VEC — тип тестовых воздействий;

• Delays= True или False — признак наличия команд управления модельным временем;

• ZEmul= True или False — признак эмуляции Z состояния;

• Filename=Project или Device — способ выбора имени генерируемых файлов.

Для изменения значений параметров устройства предусмотрена команда:

With Device DeviceName do DeviceOperands end

где DeviceName — имя устройства, а DeviceOperands — команды, разделенные символом «;». В качестве DeviceOperands можно указать:

• Set Param ParamName as Expression — установить значение параметра ParamName значением выражения Expression;

• Exec Param ParamName — выполнить внешний параметр устройства.

3. Примеры практического использования пакетного тестирования

3.1. Поддержка «реинжиниринга» систем на базе СИС

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

Опираясь на уникальные возможности системы HLCCAD, мы предложили нетрадиционный подход к решению задач «реинжиниринга». Этот подход основан на предварительной подготовке моделей микросхем средней степени интеграции, использованных при первичной разработке системы. Такие модели должны обеспечивать адекватную симуляцию и VHDL-генерацию. Для микросхем семейств K155 и родственных, с использованием справочных описаний в HLCCAD созданы иерархические модели соответствующих микросхем из стандартных компонентов HLCCAD [2]. На рис. 5 представлен пример реализации модели. Полный перечень реализованных моделей представлен в таблице 4.

Таблица 4. Реализованные модели микросхем серии SN74

DEVICE	аналог	КР1533	1564	1594	КР1554
		ALS	HC	ACT	AC
OO	ЛА3	+	+	+	+
O1	ЛА8	+	+
O2	ЛЕ1	+	+	+	+
O3	ЛА9	+	+
O4	ЛН1	+	+	+	+
O5	ЛН2	+	+	+
O8	ЛИ1	+	+	+	+
O9	ЛИ2	+	+
10	ЛА4	+	+	+	+
11	ЛИ3	+	+	+
12	ЛА10	+
15	ЛИ4	+
20	ЛА1	+	+		+
21	ЛИ6	+	+		+
22	ЛА7	+
28	ЛЕ5
30	ЛА2	+	+
32	ЛЛ1	+	+	+	+
33	ЛЕ11	+
34	ЛИ9				+
42	ИД6		+
51	ЛР11		+
74	ТМ2	+	+	+	+
75	ТМ7		+
77	ТМ5		+
85	СП1		+
86	ЛП5	+	+		+
107	ТВ6		+
109	ТВ15	+	+	+	+
112	ТВ9	+	+	+	+
113	ТВ10	+
114	ТВ11	+
125	ЛП8		+	+
136	ЛП12	+
138	ИД7		+	+
139	ИД14	+	+	+	+
147	ИВ3		+
148	ИВ1		+
151	КП7	+	+	+
152	КП5		+
153	КП2	+	+	+	+
154	ИД3		+
157	КП16	+	+	+	+
158	КП18	+	+	+	+
160	ИЕ9	+	+	+
161	ИЕ10	+	+	+	+
162	ИЕ11	+	+
163	ИЕ18	+	+	+	+
164	ИР8	+	+
165	ИР9	+	+
166	ИР10	+	+
169	ИЕ17			+
173	ИР15		+
174	ТМ9	+	+	+	+
175	ТМ8	+	+	+	+
180	ИП2		+
190	ИЕ12	+	+
191	ИЕ13	+	+
192	ИЕ6	+	+		+
193	ИЕ7	+	+		+
194	ИР11		+
237			+
238			+
240	АП3	+	+	+	+
241	АП4	+	+	+	+
242	ИП6	+	+
243	ИП7	+	+
244	АП5	+	+	+	+
245	АП6	+	+	+	+
251	КП15	+	+	+
253	КП12	+	+	+	+
257	КП11	+	+	+	+
258	КП14	+	+	+	+
259	ИР30	+	+
266	ЛП13		+
273	ИР35	+			+
280	ИП5		+
283	ИМ6		+
298	КП13		+
299	ИР24	+	+	+	+
323	ИР29	+		+	+
352	КП19	+	+	+
353	КП17	+
365	ЛП10		+
366	ЛН6		+
367	ЛП11		+	+
368	ЛН7	+	+	+
373	ИР22	+	+	+	+
374	ИР23	+	+	+	+
377	ИР27		+	+
378	ИР18		+
379	ИР19		+	+
393	ИЕ19		+
465	АП14	+
466	АП15	+
520				+
521				+
533	ИР40		+	+	+
534	ИР41		+	+	+
540			+
541			+	+
563			+	+
564			+
573	ИР33	+
574	ИР37	+
620			+
623			+
640	АП9	+	+	+	+
643	АП16	+
645			+
646	АП20		+	+	+
648			+
651			+
652			+
664			+
665			+
821				+
823				+
825				+
841				+
843				+
845				+
873	ИР34	+
874	ИР38	+
1000	ЛА21	+
1002	ЛЕ10	+
1003	ЛА21	+
1004	ЛН8	+
1005	ЛН10	+
1008	ЛИ8	+
1010	ЛА24	+
1011	ЛИ10	+
1020	ЛА22	+
1032	ЛЛ4	+
1034	ЛП16	+
1035	ЛП17	+

Система HLCCAD обеспечивает пакетную проверку адекватности справочным описаниям (посредством симуляции) и автоматическую генерацию корректных VHDL-описаний нужных микросхем.

Таким образом, корректное по построению перепроектирование старых систем заключается фактически в графическом вводе схем в HLCCAD и исправлении ошибок ввода (с помощью симуляции). При необходимости, на этом этапе можно провести и модификацию выполняемых системой функций в целях модернизации или адаптации к новым условиям функционирования. Далее HLCCAD обеспечивает автоматическую генерацию синтезируемого VHDL-описания спроектированной системы для загрузки в САПР более низкого уровня (Altera MaxPlus II, Xilinx ISE и др.).

Очевидно, что использование такого подхода резко сокращает сроки «реинжиниринга» систем, построенных на микросхемах средней степени интеграции произвольных семейств.

Ниже в качестве примера приведен фрагмент файла сценария, обеспечивающий пакетное тестирование созданной библиотеки моделей микросхем серии К155 (зарубежный аналог — серия SN74).

Set «echo»=off; LoadDesktop «F:\HLCCAD\testing.env»; Set «NeedLoadModelingDesktop»=off; Set «FullOutputTesting»=on; Language=»English»; ExcludeProjects; Log=»F:\Tester\74ac.log»; MLimit=»None»; glTestBAT=»D:\VHDLtester\VHDLTester.bat»; glTestBATPath=ExtractFilePath(glTestBAT); IncludeProject «F:\HLCCAD\Tests\SN74D\74AC\74ac.prj» IncludeProject «F:\HLCCAD\Tests\SN74D\74HC\74hc.prj» IncludeProject «F:\HLCCAD\Tests\SN74D\SN74\Sn74.prj» Project «F:\HLCCAD\Tests\SN74D\74AC\74ac.prj» echo «Testing 74ac.prj 00»; SaveLog ClearErrors MLimit=»55000»; MTest=»F:\HLCCAD\Tests\SN74D\74AC\tests\ 00.tst» Echo «Modeling»; SaveLog; Run «00»; Reset; if ErrorCount = 0 then VOutput=CurDir «\VHDL\74ac\a00»; BuildVHDL»00», Dir=VOutput, Test=True, TestType=VEC, Delays=False, ZEmul=True,FileName=Device; if ErrorCount = 0 then echo «External VHDL modeling»; SaveLog; ExecSoft glTestBat, VOutput «\ a00 « glTestBATPath; VResult=File(VOutput «\a00.crs»);if VResult<>»Ok» then echo VResult; echo «Testing 74ac.prj 02»; SaveLog ClearErrors MLimit=»40000»; MTest=»F:\HLCCAD\Tests\SN74D\74AC\TESTS\ 02.tst» Echo «Modeling»; SaveLog; Run «02»; Reset; if ErrorCount = 0 then VOutput=CurDir «\VHDL\74ac\a02»; BuildVHDL «02», Dir=VOutput, Test=True, TestType=VEC, Delays=False, ZEmul=True, FileName=Device; if ErrorCount = 0 then echo «External VHDL modeling»; SaveLog; ExecSoft glTestBat, VOutput «\ a02 « glTestBATPath; VResult=File(VOutput «\a02.crs»);if VResult<>»Ok» then echo VResult;

3.2. Контроль работоспособности новых версий HLCCAD

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

Для этого все разработанные в HLCCAD проекты снабжаются тестовыми файлами и файлами сценария, и все такие сценарии объединяются для организации последовательной загрузки, компиляции и симуляции в HLCCAD, генерации векторных тестов (в формате Max+Plus II) по результатам симуляции; компиляции и симуляции средствами Max+Plus II.

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

• ошибки компиляции в HLCCAD;

• ошибки симуляции в HLCCAD;

• ошибки компиляции сгенерированных VHDL-описаний средствами Max+Plus II;

• ошибки симуляции сгенерированных VHDL-описаний средствами Max+Plus II.

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

Ниже приводится пример отображения на сайте разработчиков процесса регрессионного тестирования HLCCAD.

Тестирование: общая информация

Total devices	Всего устройств в данном проекте
All errors	Всего ошибок в данном проекте
Modeling errors	Всего ошибок моделирования в HLCCAD
VHDL compile errors	Всего ошибок компиляции в Max+Plus II
VHDL simulation errors	Всего ошибок симуляции в Max+Plus II

Последнее тестирование производилось 13 декабря 2002 года

Project	Total devices	All errors	Modeling errors	VHDL compile errors	VHDL simulation errors	time of testing
74ac.log	26	6	0	6	0	4:08
74act.log	21	4	0	4	0	3:19
74hc.log	50	7	0	7	0	8:28
sn74.log	59	10	0	10	0	9:56
dsp.log	4	0	0	-	-	0:10
gcsw2000.log	4	2	1	1	0	0:32
multipliers.log	7	6	0	6	0	1:40
proverka.log	6	0	0	0	0	1:08
students_h.log	12	1	1	-	-	0:25
students_m.log	12	4	1	3	0	2:12
test_standard_devices_h.log	159	12	12	-	-	0:54
test_standard_devices_m.log	158	27	9	18	0	30:32
mpa.log	8	8	8	-	-	0:10
Total	526	87	32	55	0	63:39

27. Язык описания аппаратных средств

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

HDLs являются стандартными текст на основе выражения пространственной и временной структуры и поведения в электронных системах. Как и параллельном программировании языках HDL синтаксис и семантику содержит явные обозначений для выражения параллельный. Однако, в отличие от большинства программных языков программирования, HDLs также включать четкую концепцию времени, которая является одним из основных атрибутов аппаратного обеспечения. Языки, чья единственная характеристика заключается в том, чтобы выразить схемы связи между иерархией блоков правильно классифицированы как netlist языков, используемых в электрических компьютерного проектирования (CAD).

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

Это, безусловно, можно представлять аппаратных семантики с использованием традиционных языков программирования, таких как C + +, хотя функционировать такие программы должны быть увеличены с большим и громоздким библиотеки классов. Прежде всего, однако, программное обеспечение языки программирования, не содержат каких-либо возможностей для явным выражением времени, и поэтому они не функционируют как язык описания аппаратных средств. До недавнего внедрения SystemVerilog, C + + интеграция с логикой тренажер был одним из немногих способов использования ООП в аппаратной проверки. SystemVerilog является первым крупным HDL предложить объект ориентации и сбор мусора.

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

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

28. История HDLs

Первые описания аппаратных языки ISP (набор команд процессора) разработанный в университете Карнеги-Меллона, и Карл, разработанная в Университете Кайзерслаутерн, как около 1977. Провайдеры, однако, больше похож на язык программирования, программное обеспечение, используемые для описания отношений между входами и выходами конструкции. Таким образом, оно может быть использовано для имитации дизайна, но не синтезировать его. KARL включали разработку исчисление функций поддержки языка СБИС микросхема floorplanning и структурированного аппаратные разработки, который является также основой KARL интерактивных графических сестра ABL язык, принятый в начале 1980-х годах в качестве возможности графического редактора дизайн СБИС, в центре телекоммуникационных исследований CSELT в Турине, Италия. В середине 80-х, а дизайн СБИС рамках было осуществлено около KARL ABL и со стороны международного консорциума, финансируемого Комиссией Европейского Союза (глава в В 1983 году данные I / O представила ABEL. Оно было направлено для описания программируемых логических устройств, и в основном используется для разработки конечных автоматов.

Первый современный HDL, Verilog, был представлен Gateway автоматизации проектирования в 1985 году. Каденция Проектирование систем позднее приобрела права на Verilog-XL, в HDL-симулятор, который станет де-факто стандартом (в Verilog тренажеры) на ближайшие десятилетия. В 1987 году с просьбой от министерства обороны США привели к разработке VHDL (очень высокая скорость Integrated Circuit язык описания аппаратных средств.) Первоначально Verilog и VHDL были использованы для документирования и моделирования цепи конструкций уже захватили и описаны в другом виде ( такие, как схематический файл.) HDL-моделирования позволило инженерам работать на более высоком уровне абстракции, чем симуляция на схематическом уровне, и тем самым увеличить проектную мощность от сотен до тысяч транзисторов.

Введение в логику-синтез для HDLs толкаемых HDLs от фона в плане цифрового дизайна. Синтез инструменты скомпилированный HDL-исходные файлы (текст, написанный на сдерживается формат называют "RTL") в ворота manufacturable / транзисторно уровня netlist описание. Ввод synthesizeable RTL файлов, необходимых практики и дисциплины со стороны дизайнера; по сравнению с традиционными схематической-макета, синтезирован-RTL netlists были почти всегда больше по площади и медленнее в работе. Circuit Design путем квалифицированного инженера, с использованием труда интенсивно schematic-capture/hand-layout, будет почти всегда превосходят ее логически-синтезированных эквивалента, но синтез производительности преимущество скорее перемещенных цифровой схематической-захвата точно тех областях, которые являются проблематичными для RTL-синтез : чрезвычайно высокой скоростью, малой мощности, или асинхронный схемы. Короче говоря, логика синтез не только в движение HDLs в центральную роль для цифрового дизайна, это была революционная технология цифровой схемы дизайн-индустрии.

В течение нескольких лет, как VHDL и Verilog стала доминирующей HDLs в электронной промышленности, в то время как старые и менее способны HDLs постепенно исчез из использования. Но VHDL и Verilog разделяют многие из тех же ограничений: ни HDL подходит для аналогового / смешанных сигналов схемы моделирования. Ни владеет языком конструкций для описания рекурсивно генерируемые логические структуры. Специализированная HDLs (таких, как Слияние) были введены с четкой целью установления конкретных Verilog / VHDL ограничения, хотя и не было никогда, предназначенных для замены VHDL / Verilog.

За прошедшие годы много усилий прошла в улучшении HDLs. Последняя компьютерная помощь выездVerilog, официально известной как IEEE 1800-2005 SystemVerilog, вводит много новых функций (классов, случайные переменные, и свойства / утверждения) для удовлетворения растущих потребностей в более testbench рандомизация, разработка иерархии, и повторное использование. В будущем пересмотр VHDL также в разработке, и ожидается, что оно совпадает SystemVerilog в улучшениях. Оба VHDL и Verilog, их постоянное совершенствование, как ожидается, останутся в активное использование в течение многих лет в будущем.

29. Дизайн помощью HDL

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

Большинство образцов начаться как написано множество требований, и на высоком уровне архитектурного диаграмм. Процесс написания HDL описание в значительной степени зависит от дизайнера справочных и цепи природы. В HDL является лишь 'захвата language' часто начинаются с высоким уровнем алгоритмического описания, таких как MATLAB или C + + математической модели. Контроль и решение структурах зачастую прототип в схему приложения, либо вступили в государстве-редактор диаграмм. Дизайнеры даже использовать языки сценариев (например, Perl) для автоматической генерации цепь повторяющихся структур в HDL языка. Дополнительные текстовые редакторы (например, Emacs) предлагаем редактор шаблонов для автоматического вдавливанием, синтаксис, зависящие от окраски, а также макро-основываться расширение организации / архитектура / сигнал декларации.

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

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

30. Моделирование и отладки HDL кода

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

Для имитации одна модель HDL, инженер пишет верхнего уровня моделирования окружающей среды (так называемую testbench). Как минимум, один testbench содержит инстанцирования этой модели (так называемые устройства под испытания или DUT), PIN-код / сигнал заявлений для модели I / O, а также часы сигнала. В testbench код мероприятие по инициативе: инженер пишет HDL заявления по осуществлению (testbench генерируемые) сброса сигнала, в модели интерфейса сделок (например, хост-автобус чтения / записи), а также для контроля за DUT производства. В симулятор HDL-программа, которая выполняет testbench-ведение симулятор часов, что является хозяином для всех событий в testbench моделирования. События происходят только в моменты обусловлены testbench HDL (таких, как сброс-переключать закодировано в testbench), или в качестве реакции (по образцу) и стимулом для инициирования событий. Современные тренажеры HDL иметь полный набор функций графический пользовательский интерфейс, в комплекте с набором инструментов отладки. Они позволяют пользователю остановить и перезапустить моделирования в любой момент включить симулятор останова (независимые от кода HDL), а также контролировать и изменять любой элемент в HDL модель иерархии. Современные тренажеры также могут связать HDL среда для пользователей скомпилированные библиотеки, через определенное PLI / VHPI интерфейс. Компоновка системы зависит (Win32 / Linux / SPARC), как HDL симулятор и пользователей библиотек, обобщены и связаны за HDL среды.

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

31. Дизайн контролю со HDLs

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

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

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

32. HDL и языки программирования

А HDL аналогичного программного обеспечения язык программирования, но с основными различиями. Многие языки программирования, изначально процедурных (одна жила), с ограниченными синтаксического и семантического поддержку параллельной обработки. HDLs, с другой стороны, напоминают Параллельное программирование языков в их способности к модели нескольких параллельных процессов (таких, как flipflops, сумматоры и т.д.), которые автоматически выполнять независимо друг от друга. Любые изменения в процессе ввода автоматически триггеры обновление в тренажера в стеке процесса. Оба языков программирования и HDLs обрабатываются компилятор (обычно называемый синтезатор в случае HDL), но с разными целями. Для HDLs, 'компилятора "относится к синтезу, а процесс преобразования HDL кода в перечень физически реализуемы ворот netlist. В netlist производства может занять любое из многих формах: в "имитации" netlist ворота с задержкой информации, "handoff" netlist послепроектного синтеза и маршрут, и общий отраслевой стандарт EDIF формате (для последующего преобразования в JEDEC -- формат файла).

С другой стороны, программный компилятор преобразует исходный код перечисление в микропроцессор конкретного объекта-код для исполнения на целевой микропроцессора. Как HDLs и языки программирования заимствования концепций и возможностей друг от друга, граница между ними становится все меньше отличаются. Тем не менее, чистый HDLs непригодны для общих целей развития программных приложений, как и языками программирования общего назначения являются нежелательными для моделирования оборудования. Тем не менее, как электронные системы растут все более сложными, и reconfigurable системы становятся все более учету, растет стремление в промышленности для одного языка, который может выполнять некоторые задачи, как аппаратный дизайн и программирование. SystemC являет собой пример такой-встроенные аппаратные системы могут быть моделируемые как не подробный архитектурных блоков (blackboxes с моделируемого сигнала входов и выходов драйверов). Целью применения написан на C / C + +, а по родному составлены на хост-системе развития (в отличие от ориентации на встроенный процессор, который требует пребывания моделирования встроенного процессора). Высокий уровень абстракции SystemC модель хорошо подходит для ранней архитектуры разведке, как архитектурные изменения можно легко оценить с небольшим озабоченность сигнал уровне вопросов.

В попытке уменьшить сложность разработки в HDLs, которые были по сравнению с эквивалентным собраний языков, Есть движется поднять уровень абстракции при разработке. Такие компании, как Каденция, Synopsys и оперативности проектных решений способствуют SystemC как способ совместить высокий уровень языках с параллельным моделей, чтобы быстрее циклы разработки для FPGAs чем это возможно с использованием традиционных HDLs. Подходы, основанные на стандартных C или C + + (с библиотеками или другими расширениями позволило параллельного программирования) находятся в Catapult C средств из наставников графика, и в Импульсное C средств из Импульс Ускоренной технологий. Аннаполис Micro Systems, Inc 'S CoreFire Дизайн Suite и National Instruments LabView FPGA обеспечивают графическое Потоковые подход с высоким уровнем дизайна въезда. Языки, таких, как SystemVerilog, SystemVHDL и Handel-C стремиться достичь той же цели, а направлены на то, чтобы сделать существующие аппаратные инженеры более продуктивным в сравнении с FPGAs сделать более доступным для существующих программных инженеров. Таким образом SystemVerilog более быстро и широко, чем SystemC. Существует более подробную информацию о С до HDL и потока ЛПВП в своих статьях.

Языки

Цифровая схема разработки

Два наиболее широко используются и хорошо поддерживаются HDL сортов, используемых в отрасли являются:

• VHDL

• Verilog

Другие включают в себя:

• Расширенный булевых выражений языка (ABEL)

• AHDL (Altera HDL, вещное язык Altera)

• Atom (поведенческого синтеза и высокого уровня HDL основывается на Haskell)

• Bluespec (высокого уровня HDL изначально основаны на Haskell, теперь с SystemVerilog синтаксис)

• Слияние (функциональная HDL; была прекращена)

• CUPL (один закрытый язык из Логической Devices, Inc)

• Handel-C (С-дизайна, как язык)

• C до Verilog (Преобразует C до Verilog)

• Элла (не находится в общем пользовании)

• HDCaml (на основе цели Caml)

• Оборудование Join Java (на основе Java Join)

• HML (на основе SML)

• Гидра (по Haskell)

• Импульс C (C-другому, как язык)

• JHDL (на основе Java)

• Лава (по Haskell)

• Лола (простой язык, используемый для обучения)

• MyHDL (на Python)

• PALASM (для массива программируемой логики (PAL) устройства)

• Ruby (язык описания аппаратных средств)

• RHDL (на основе языка программирования Ruby)

• CoWareC, С-HDL основанные на CoWare. В настоящее время прекращены в пользу SystemC

• SystemVerilog, надмножество в Verilog, с аксессуарами для решения системного уровня проектирования и проверки

• SystemC, стандартизированный класс C + + библиотеки для высокопоставленных поведенческие и сделки моделирования цифровых аппаратных средств на более высоком уровне абстракции, т.е. на системном уровне

• SystemTCL, SDL основанных на Tcl.

33. Применение языков программирования общего назначения для описания аппаратного обеспечения.

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

1. Объект изучения дисциплины ИСРАПС. Определения аппаратно-программного средства и его жизненного цикла.

2. Модели жизненного цикла аппаратно-программного средства (АПС), их достоинства и недостатки. Процессы жизненного цикла АПС.

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

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

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

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

7. Анализ и оптимизация стоимости проектов разработки аппаратно-программных средств.

8. Анализ и оптимизация сроков проектов разработки аппаратно-программных средств.

9. Требования к аппаратно-программным средствам. Процесс управления требованиями, участники процесса управления требованиями.

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

11. Сложные аппаратно-программные системы.

12. Моделирование аппаратно-программных средств.

13. Методология IDEF. Виды IDEF-моделей.

14. Методология DATARUN.

15. Методология UML. UML-диаграммы.

16. CASE-технологии. Средства, реализующие CASE-технологии.

17. Функциональное моделирование. Методология IDEF0.

18. Средства разработки функциональных моделей.

19. Моделирование данных. Методология IDEF1X.

20. Средства разработки информационных моделей.

21. Разработка программного обеспечения (ПО). Языки разработки ПО, их особенности и классификация.

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

23. Интегрированные системы разработки программного обеспечения.

24. Структура программы на языке ассемблера. Процесс формирования программы.

25. Система команд и программная модель микропроцессора. Формат ассемблерных команд и директив.

26. Языки описания аппаратного обеспечения, их виды и сравнительные характеристики.

27. Языки синтезируемого описания аппаратного обеспечения.

28. Языки высокоуровневого описания аппаратного обеспечения.

29. Применение языков программирования общего назначения для описания аппаратного обеспечения.

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