О документировании проектов для ПЛИС

Введение

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

• ГОСТ 2.102-68 ЕСКД. Виды и комплектность конструкторских документов.
• ГОСТ 2.114-95 ЕСКД. Технические условия.
• ГОСТ 15.101-98. Система разработки и постановки продукции на производство. Порядок выполнения научноисследовательских работ.
• ГОСТ Р 15.201-20-00. Система разработки и постановки продукции на производство. Продукция производственно-технического назначения. Порядок разработки и постановки продукции на производство.

Как правило, это были файл-прошивки и программа (описание цифрового устройства на VHDL/Verilog или набор цифровых схем, разработанных в схемотехническом редакторе с использованием библиотечных элементов цифровой логики, такие как триггеры, регистры, счетчики, дешифраторы и т. д.) на CD или DVD и инструкция по программированию. И все.

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

История вопроса проектирования для ПЛИС

В настоящее время рынок ПЛИС — один из наиболее динамично развивающихся. ПЛИС применяются во многих отраслях техники. На данный момент нет однозначной, удовлетворяющей всех разработчиков аппаратуры методологии получения конфигурации ПЛИС по функциональной модели устройства на системном уровне. Наиболее популярный подход по решению этой проблемы — применение технологии ІР-ядер (Intellectual Property Cores). IP-ядра — это готовые компоненты, позволяющие легко включать их в собственный проект для создания более сложной системы. У этого подхода есть один существенный недостаток — привязанность ІР-ядер к элементному базису. Каждое IP-ядро оптимизировано под конкретную серию микросхем конкретного производителя, что существенно ухудшает возможность переноса уже созданных устройств из одного элементного базиса в другой. Закрытость архитектур коммерческих САПР делает невозможным добавление собственных функциональных моделей устройств на системном уровне для получения на их основе моделей устройства на уровне регистровых передач (RTL). Разработка цифрового модуля осуществляется в виде цифровой схемы, нарисованной в схемном редакторе с помощью встроенной в САПР производителя библиотеки базовых схемных элементов, таких как триггеры, дешифраторы, счетчики, сумматоры и т. д.

Другой популярный подход, позволяющий осуществить переход от функциональной модели на системном уровне к модели устройства на уровне регистровых передач, — применение языков описания аппаратуры на системном уровне (system-level design languages, SLDLs). К таким языкам относятся SystemC, Handel-C, VHDL, Verilog, System Verilog. Основным плюсом является независимость от аппаратного базиса, в котором будет реализовано устройство.

Таким образом, с одной стороны, при применении технологии IP-ядер разработчик аппаратуры получает качественное решение, но жестко привязанное к аппаратному базису, в котором реализуется устройство. С другой стороны, при применении языков описания аппаратуры на системном уровне реализация устройства является аппаратно независимой. Из вышесказанного следует, что в настоящее время актуально совместное использование для ускорения процесса проектирования цифровых модулей на языке описания аппаратуры и ІР-ядер производителя (Xilinx, Altera, Actel и др.) и сторонних фирм-разработчиков. При использовании цифровых модулей сторонних производителей иногда возникает нехватка в информативности сопроводительной документации.

Предоставление информации о разработанном цифровом модуле для ПЛИС

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

• Software — разработанный цифровой модуль, передаваемый потребителю в виде описания на языке описания аппаратуры (VHDL, Verilog) или/и разработанный в схемотехническом редакторе Schematic Editor для дальнейшего использования в программах автоматизированного синтеза логических схем и оптимизированный по функциональным параметрам.
• Firmware — разработанный сторонней фирмой-разработчиком цифровой модуль, который называется IР-ядром, передаваемый потребителю в виде логической схемы (списка цепей — netlist) в базисе библиотеки логических элементов изготовителя ПЛИС и оптимизированный по функциональным и электрическим параметрам.

На этапе разработки документации, исходя из личного опыта, необходимо оформить в дополнение к обычным КД и ТУ, выполняемым в соответствии с ГОСТ 15.101, ГОСТ 15.201, ГОСТ 2.102, ГОСТ 2.114, документацию на все виды моделей (системных, логических, схемотехнических), создаваемых на этапах проектирования цифровых устройств на ПЛИС.

Другими словами, в комплект конструкторской документации цифрового устройства для ПЛИС, кроме файла-прошивки, инструкции по программированию и записанного проекта на CD/DVD, должна также входить сопроводительная документация.

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

• «О» — обязательно поставляемый раздел;
• «Р» — рекомендуемый для поставки раздел.

Рекомендуемые форматы файлов для передачи сопроводительной документации — MS Word, PDF (наилучший формат), HTML. Файлы описания на языке описания аппаратуры (VHDL, Verilog) или/и разработанные в схемотехническом редакторе Schematic Editor предоставляются в таком виде, как требует программное обеспечение САПР для разработки. Исключением может быть дополнительное предоставление в графическом формате (JPEG, BMP) файлов цифровых схем, разработанных в схемотехническом редакторе Schematic Editor.

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

Общие сведения

В этом разделе описываются общие сведения о разработанном цифровом модуле в виде описания:

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

Назначение и область применения

Определяется назначение цифрового модуля, области его применения.

Технические характеристики

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

Описание сигналов сброса

Приводится подробная информация о сигналах сброса:

• Перечень внешних и внутренних сигналов сброса.
• Временные параметры и временные диаграммы сигналов сброса.
• Схемы формирования внутренних сигналов сброса, если таковые входят в состав цифрового модуля.
• Соотношения с другими сигналами (особенно с сигналами синхронизации).
• Любая другая дополнительная информация.

Описание сигналов синхронизации

Приводится подробная информация о сигналах синхронизации:

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

Описание интерфейсов

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

Временные диаграммы

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

Описание регистров управления

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

Структурная (функциональная) схема

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

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

Типовое описание внутреннего блока содержит:

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

Руководство по программированию

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

Модель или семейство ПЛИС, фирма-производитель

Для Firmware цифрового модуля указывается фирма-производитель ПЛИС, модель или семейство ПЛИС и ее скоростные характеристики. Для Software цифрового модуля приводится информация о количестве занимаемых ресурсов, требования к применяемой ПЛИС.

Представление цифрового модуля для логического проектирования

В статье [1] были рассмотрены трудности в использовании «чужого» проекта на VHDL — нехватка подходящих указаний по именованию и правилам написания программ. Также были даны общие указания по именам, правилам «хорошего тона» для написания программ и руководства для синтеза. Эти вопросы как можно более подробно стоит оговаривать с разработчиком, если в дальнейшем вы планируете продолжить разработку или модернизацию своими силами, прежде чем он приступит к разработке RTL-модели цифрового модуля на ПЛИС. Особенно это относится к виду Software цифрового модуля на ПЛИС. В этой же части статьи описываются общие требования ко всему проекту разработанного цифрового модуля на ПЛИС. Здесь приведены вопросы, на которые следует обратить внимание при составлении технического задания на разработку цифрового модуля на ПЛИС, и особенно это касается передачи результатов работы.

RTL-модель

Цифровой модуль, описанный на синтезируемом подмножестве языка Verilog или VHDL или/и разработанный в схемотехническом редакторе Schematic Editor, предназначен для использования на этапе логического синтеза ПЛИС. Поставляется для Software в виде собранного проекта цифрового модуля в САПР производителя ПЛИС. Для цифрового модуля Firmware RTL-модель предоставляется по отдельному соглашению.

Помимо файлов RTL-модели, передаются:

• Инструкция по использованию модели.
• Описание блоков памяти, входящих в состав модели, включающее тип памяти, размер, число блоков памяти, иерархическое имя блока памяти.
• Описание процесса создания готовых ядер при использовании программ для их создания (например, CoreGenerator для Xilinx ISE). При отсутствии описаний могут возникнуть ограничения для повторного проектирования и применения из-за зависимости от технологии и производителя.
• В случае использования микропроцессора от производителя (например, от фирмы Altera — процессор Nios; от фирмы Xilinx — микропроцессоры Microblaze, PowerPC) требуется описание процесса конфигурирования ядра процессора и его периферии.
• Набор тестов (Test Bench файлов) для проведения верификации и моделирования цифрового модуля, написанных на языке Verilog или/и на VHDL, или/и на System Verilog.
• Руководство по работе с набором тестов для проведения моделирования и верификации цифрового модуля.
• Любая другая дополнительная информация.

Логическая модель

Модель является списком цепей, описанным с помощью языков Verilog или VHDL в базисе библиотеки изготовителя ПЛИС, и поставляется для Firmware цифрового модуля.

Помимо файлов логической модели, передаются:

• Инструкция по использованию этой модели.
• Набор тестов (Test Bench файлов) для проведения верификации и моделирования цифрового модуля, написанных на языке Verilog или/и на VHDL, или/и на System Verilog.
• Руководство по работе с набором тестов для проведения моделирования и верификации цифрового модуля.
• Любая другая дополнительная информация.

Проектные ограничения

Проектные ограничения предоставляются в виде файла с описанием набора ограничений, накладываемых на цифровой модуль при его включении в логическую модель системы на кристалле. В этот набор входят ограничения для сигналов синхронизации (clock constrains), временные ограничения (timing constrains), ограничения на взаимодействие цифрового модуля с другими модулями и условия работы цифрового модуля. Предпочтителен формат описания проектных ограничений Synopsis Design Constraints (SDC) или формат для САПР производителя ПЛИС.

Примерный список ограничений для сигналов синхронизации:

• временная диаграмма (Clock waveform);
• нестабильность тактовой частоты (Jitter);
• изменение фазы тактовой частоты;
• длительность времен переключения (Transition times);
• временные диаграммы производных синхросигналов (Generated clock waveforms);
• любая другая дополнительная информация.

Набор ограничений для сигналов синхронизации обязателен для Software и Firmware цифровых модулей.

Примерный список временных ограничений:

• время появления сигналов на входах (Arrival times at inputs);
• время появления сигналов на выходах (Required times at outputs);
• многотактовые пути (Multi-cycle paths);
• ложные пути (False paths);
• длительность времен переключения сигналов данных (Data signal transition times);
• любая другая дополнительная информация.

Заключение

Приведенный состав сопроводительной документации на разработанные цифровые модули для ПЛИС предоставляется по договоренности между потребителем и разработчиком. Чаще всего разработчик предоставляет просто цифровой модуль, описанный на языке VHDL, Verilog, System Verilog и/или разработанный в схемотехническом редакторе. По поводу дополнительной документации ответ у разработчика чаще всего бывает следующим: «Цифровой модуль работает, так берите и пользуйтесь. В описании схемы на языке аппаратуры ничего сложного нет: разберетесь сами».

На взгляд автора, разобраться можно в чем угодно, все зависит от желания и потраченного времени, а время, потраченное на то, чтобы разобраться в «чужом» проекте на уже разработанный цифровой модуль, прямо пропорционально опыту описания аппаратуры на языках VHDL, Verilog и знаниям цифровой и микропроцессорной схемотехники. Этого можно избежать, если изначально договориться с разработчиком о составе сопроводительной документации, тогда использование цифрового модуля в своем проекте становится проще, и быстрее произойдет его внедрение.

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