Языки описания аппаратуры
Любой проект всегда начинается, сопровождается и заканчивается «ворохом» всевозможных описаний. Это ТЗ, уравнения, схемы, временные диаграммы, таблицы, спецификации, карты «прошивки», эскизы печатных плат и прочая техническая документация. Каждое такое описание создаётся по определённым правилам с использованием дозволенных символов и операций. Другими словами, работа выполняется с привлечением конкретного языка описания проекта или его фрагмента.
Рассмотрим возможные способы описания объекта и попытаемся выяснить, что конкретно необходимо описывать в процессе разработки цифровой аппаратуры. Для примера в качестве объекта проектирования возьмём двухканальный мультиплексор MUX2, графическое изображение которого показано на рис.1, а.
Мы уже знаем (лекция 2), что существуют два подхода к описанию объекта: детерминистский и системный. Первый предлагает рассматривать объект как чёрный ящик, и, значит, мы можем описать только его внешний образ, поведение (функцию) и параметры. При системном подходе появляется возможность к названным описаниям добавить ещё и структурное описание.
Схемный образ, так называемое условное графическое обозначение (УГО) показано на рис. 1, а. Рядом на рис.1, б приведено конструкторское описание мультиплексора. Это примеры графических форм описания объекта.
Для описания функции объекта традиционно используется словесное описание, называемое содержательной моделью. Для мультиплексора MUX2 оно может «звучать» так (рис.1, в): MUX2, аналог механического переключателя, коммутирует сигнал с одного из двух информационных входов D0 или D1 на выход Y. Конкретный канал выбирается сигналом на селекторном входе A. При A=0 на выход Y передаётся двоичный сигнал D0, при A=1 – сигнал D1. Это текстовая форма описания объекта.
Понятно, что для автоматизированного проектирования такое описание выглядит не очень привлекательно. Но мы можем формализовать его, используя булевское уравнение. Оно записано в формате языка VHDL и выглядит так (рис.1, г):
Y <= (D0 and (not A)) or (D1 and A);
Здесь ключевые слова not, and и or означают логические операции отрицания, конъюнкции и дизъюнкции. Такая запись, как известно, представляет собой аналитическую модель мультиплексора. Это тоже текстовое описание, но не словами, а формулами.
Вместо аналитического описания мы можем использовать алгоритмическое описание, заменив уравнение набором последовательно выполняемых действий. Например, поведение мультиплексора MUX2 легко представить в виде блок-схемы алгоритма (рис. 1, д). Это графическая форма записи алгоритма, но её всегда можно преобразовать в текстовую. На рис.1, е показано, как будет выглядеть алгоритмическое описание работы мультиплексора MUX2, записанное на языке VHDL пакета OrCAD 9 (фрагмент).
Наконец, функцию (поведение) объекта можно представить в табличной форме. Для мультиплексора – это любимая студентами таблица истинности, показанная на рис.1, ж. Рядом изображена сокращённая таблица (рис.1, з). Табличное описание легко конвертировать в текстовую форму. Именно по сокращённой таблице написана DSL-модель мультиплексора (рис. 1, и).
Рис.1. Возможные способы описания объекта, его функции и параметров
(детерминистский подход)
Кроме описания внешнего вида (схемного или конструкторского) и функции объекта, на языки описания аппаратуры нередко возлагается ещё одна задача – описать выходные параметры объекта, характеризующие его качество. Для мультиплексора MUX2 такими параметрами могут быть задержка распространения сигнала и нагрузочная способность выхода.
На рис.1, к, л показана возможная реализация. Фраза «after 30ns» указывает на то, что выход Y должен изменить своё состояние не в текущий момент времени, когда выполняется данный оператор, а спустя время задержки в 30ns.
Последний оператор (рис.1, л) записан в формате языка PML пакета PCAD 4.5. Здесь описана та же самая задержка в 30ns, и дополнительно указана логическая сила выхода “D”. В САПР PCAD 4.5 определены четыре значения логической силы: S, D, R и Z. Z – высокоомный выход, он формирует самый слабый сигнал. Такого весьма примитивного описания нагрузочной способности цифровых компонентов вполне достаточно, чтобы при моделировании разрешать конфликты на шинах.
Таким образом, мы можем подвести промежуточный итог. Существуют три формы описания объекта, его функции (поведения) и параметров:
· графическая (рис.1, а, б, д);
· текстовая (рис.1, в, г, е, и, к, л);
· табличная (рис.1, ж, з).
А саму функцию (работу, поведение) объекта можно описать словами, уравнениями или алгоритмом.
Структурное описание объекта (системный подход) тоже может быть представлено в тех же формах: графической, текстовой и табличной. Напомним, что под структурой понимается множество элементов, из которых построен объект, и связей между ними. Элементы описываются как чёрные ящики (детерминистский подход) и называются структурными примитивами. Всё ранее сказанное об объекте как чёрном ящике при системном подходе можно перенести на его структурные примитивы. Ну а сам объект теперь имеет не одно, а два описания: внешнее – чёрный ящик, и внутреннее - структуру.
Наиболее привычной для инженера выглядит графическая форма описания структуры объекта, например, его принципиальная электрическая схема. Для мультиплексора MUX2 она изображена на рис.2, а.
Графическое описание легко конвертируется в текстовое описание, то есть в список элементов и соединений. Это можно проделать двумя разными способами.
В первом случае синтаксис структурного описания базируется на элементах схемы. Они (элементы) являются предметом особого внимания и находятся на переднем плане. Соединения имеют второстепенное значение, являются «фоном» и в описании присутствуют неявно.
Описанная ситуация показана на рис.2, б, а текстовая форма такого представления изображена на рис.2, в. В данном примере использован SPICE-формат пакета DesignLab 8.
Как видим, текстовое описание схемы представляет собой список элементов: X_DD1… X_DD4. Сколько элементов в схеме – столько и строк в описании. Префикс «X_» перед позиционным обозначением элемента является особенностью данного формата, и мы проясним этот факт позднее. Вслед за именем элемента следует перечень цепей, к которым подключены его входы и выходы. Например, входы элемента DD1 подсоединены к цепям D0 и F1, а его выход – к цепи с именем F2. Имена цепей обычно ассоциируются с именами сигналов, проходящих по этим цепям. На последней позиции стоит тип элемента (в примере AND2), по которому моделятор распознаёт выполняемую элементом функцию и находит соответствующую поведенческую модель.
Рис.2. Возможные способы описания структуры объекта (системный подход)
Списка цепей в данном описании как будто и вовсе нет (рис.2 , б). Действительно, на рисунке они отсутствуют. Явно цепи не задаются и в текстовом описании (рис.2, в). Однако косвенно, по одинаковым именам на выводах элементов, мы можем судить о соединениях в схеме. Например, по имени F2, которое встречается в двух первых строках описания (оно выделено цветом), можно утверждать, что выход элемента DD1 соединён с верхним входом элемента DD2.
Рассмотренный способ описания структуры, ориентированный на элементы и их модели, удобен, прежде всего, для имитационного моделирования. Для трассировки печатных плат он не пригоден из-за отсутствия конструкторской информации (не определены типы корпусов, питание и земля, «цоколёвка», упаковочная информация).
Другой способ описания структуры базируется на соединениях. Здесь всё «с точностью до наоборот»: основное внимание сосредоточено на цепях, а элементы, соединяемые этими цепями, оказываются как бы на заднем плане. На рис.2, г они вообще отсутствуют, мы видим лишь ссылки на них: это те точки, к которым подключены явно описанные цепи. Например, цепь с именем F2 соединяет контакт 3 элемента DD1 (DD1.3) с контактом 1 элемента DD2 (DD2.1).
На рис.2, д показан фрагмент такого описания, подготовленный для редактора печатных плат PCBoards пакета DesignLab 8. Цепь, о которой только что шла речь, выделена заливкой. Формат описания цепи весьма прост: после ключевого слова net (цепь) следует её имя, а затем перечень всех выводов (контактов) элементов, подсоединённых к данной цепи. Для точной адресации к контакту дополнительно используется его номер (см. рис.2, а).
Описанный формат не несёт информации о функциональном назначении соединяемых контактов: мы не знаем, какой вывод элемента является входным, а какой – выходным. В принципе для трассировки печатных плат такая информация и не требуется.
Однако в некоторых случаях, например, для контроля схемных ошибок, желательно знать о направлении передачи сигнала по цепи. Некоторые языки описания такую возможность предоставляют. Посмотрите, как это делается, например, в языке HSL:
F2 = FROM (DD1.3) TO (DD2.1);
Здесь вслед за ключевым словом FROM называется выходной контакт (SOURSE – источник сигнала F2), а после слова TO приводится список входных контактов (SINK –приёмников сигнала F2). Их может быть несколько.
В принципе этот язык позволяет описывать и цепи с одним входным или выходным контактом, например:
D0 = TO (DD1.1);
Y = FROM (DD2.3);
Табличное описание особенно легко получается из текстового формата, достаточно лишь разбить его на отдельные столбцы и, возможно, перегруппировать их (рис.2, е). Напомню, что в таком представлении табличное описание не даёт никакого преимущества перед текстовым описанием (ну разве что большую наглядность). Преимущества табличного описания проявляются только при использовании в них системы ссылок (лекция 9), благодаря которым появляется возможность осуществлять направленный поиск требуемых в текущий момент данных (например, элементов-приёмников какого-либо сигнала).
Мы рассмотрели возможные способы описания структуры цифрового объекта. Все они дают информацию об одном и том же – об элементах и соединениях. Отсюда напрашивается вывод, что один вид описания должен конвертироваться в другой. Например, по схемному описанию можно сгенерировать списки элементов и цепей, а, имея табличное представление объекта, восстановить по нему принципиальную схему.
В действительности ситуация не столь радужная, так как при взаимном преобразовании описаний часть информации теряется или умышленно опускается. Например, преобразование схемы в текстовый формат зависит от того, для каких целей предполагается использовать получаемый список цепей. Если список готовится для моделирования, то в него не включается информация о аппаратурных образах компонентов, и, наоборот, список, предназначенный для трассировки печатных плат, может не содержать функциональную информацию.
Несколько слов о графическом представлении объекта, точнее о его принципиальной электрической схеме (СхЭ). Большинство современных САПР имеют графический редактор, позволяющий нарисовать такую схему в качестве исходных данных. СхЭ является удобным, привычным, наглядным и понятным разработчику аппаратуры способом описания проекта.
Но ведь принципиальная схема – это не начало проектирования. Ею завершается функционально-логический и с неё начинается конструкторский этап проектирования. Она вполне уместна в процедурах автоматизированной разработки аппаратуры, которые фактически имитируют отлаженные десятилетиями технологии «ручного» проектирования.
Однако в сквозном цикле автоматического проектирования (кремниевые компиляторы) синтез СхЭ оказывается ненужным звеном. Именно из-за неё возникает структурный разрыв между функциональным и конструкторским этапами проектирования, нарушается непрерывность в иерархии описаний, появляются проблемы технической реализации []. Ну а если нет СхЭ, то и моделировать вроде бы нечего, во всяком случае, на низком уровне.
Надеюсь, что высказанная здесь несколько неожиданная и, возможно, сомнительная перспектива не охладит ваш интерес к таким серьёзным дисциплинам, как «Схемотехника» и «Моделирование».
Знание структуры объекта открывает перед разработчиком ещё одну возможность – описать его функцию на основании структурных данных. Эта уникальная возможность порождает так называемое потоковое описание, при котором структура представляется не списком элементов и цепей, а функциями этих элементов. На рис.3, а показана потоковая модель мультиплексора, записанная в формате языка DSL.
Здесь просматривается аналогия между двумя способами описания структуры – в виде списков элементов и в виде списков цепей (см. рис.2, б и в). При потоковом описании на переднем плане оказываются функции, выполняемые элементами, а не сами элементы. Структурные связи задаются неявно, не «афишируются», хотя и присутствуют в описании.
Рис.3. Потоковая модель мультиплексора MUX2
Фактически мы наблюдаем здесь попытку, описать структуру функциями, точнее использовать структурные данные не по прямому назначению, а косвенно - для описания функции объекта. При этом ненужные детали структурного описания опускаются, например мы можем не знать, что в нашей схеме четыре элемента и что их имена DD1…DD4. Для функционального моделирования такая информация и не требуется. Более того, здесь допускаются логические преобразования и подстановки, которые в конечном итоге превращают систему уравнений в одно булевское уравнение:
Y = D0*/A+D1*A; (сравните с рис.1, г),
а потоковую модель трансформируют в аналитическую (строго функциональную) модель.
С другой стороны, мы можем добавлять в потоковое описание чисто структурные данные, например в качестве меток использовать имена элементов (точнее их позиционные обозначения), и/или «спрятать» функциональные описания элементов, оформив их в виде подпрограммам – функций или процедур (рис.3, б). Сравните рис.3, б с рис. 2, е и станет ясно, что мы вплотную приблизились к структурному описанию.
Таким образом, потоковое описание занимает промежуточную нишу между строго функциональным и чисто структурным описаниями. Оно даёт нам возможность объединить с помощью структурных данных поведенческие модели отдельных элементов в потоковую модель всего объекта и промоделировать его на структурном уровне. Можно утверждать, что потоковое описание – это некий симбиоз структурных и функциональных представлений проекта.
Оно показывает, как «поток» внешних воздействий распространяется по структуре проекта от внешних входов до внешних выходов. Отсюда, вероятно и проистекает его название.
В соответствии с рассмотренными видами описаний различают языки функционального описания (языки моделирования) и структурного описания. Первые используются на этапах функционального проектирования (например, верификация проекта путём имитационного моделирования), вторые - на этапах технического проектирования (например, разводка печатных плат). Между тем названные задачи встречаются в рамках одного проекта, и потому желательно иметь язык, который бы умел делать и то и другое. Такие языки называют универсальными языками описания аппаратуры (ЯОА). Порой используется и другое название: ЯОО – языки описания объекта. В зарубежной литературе они называются Hardware Description Language или сокращённо HDL.
Первые языки описания аппаратуры появились в начале 60-х годов, и к настоящему времени их число достигает нескольких сотен. Однако всерьёз можно говорить лишь о нескольких десятках более или менее удачных ЯОА, для которых были разработаны компиляторы и которые поддерживались в прошлом или поддерживаются сейчас соответствующими системами моделирования или САПР. В этот перечень можно включить такие языки: CDL, DDL, HSL, PML, DSL, Verilog, Digital SimCode, VHDL. О некоторых из них и пойдёт дальнейший разговор.
