Методология проектирования для ПЛИС Xilinx: организационные аспекты

PDF версия
Развитие аппаратной платформы программируемых логических интегральных схем делает все более актуальным освоение новых подходов проектирования, которые учитывали бы возросшую логическую емкость, уменьшение технологических норм и связанное с этим увеличение тактовой частоты, необходимость интеграции в проект аппаратных компонентов, что в совокупности и обеспечивает высокие технико-экономические характеристики проектируемых изделий. Созданная компанией Xilinx методология проектирования, названная UltraFast Design Methodology, позволяет повысить производительность труда разработчика и улучшить качество выполняемых проектов с учетом характеристик FPGA серий 7 и UltraScale. Материалы данной статьи не ограничиваются методиками, авторство которых принадлежит специалистам Xilinx, — они включают и рекомендации, специфичные для отечественных инженеров и сформированные в результате опыта преподавания в учебном центре Xilinx в России.

Введение

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

  • организационные вопросы, касающиеся выбора семейства ПЛИС, различий их архитектуры, оценки достижимых характеристик проекта, управления процессом разработки с учетом специфики ПЛИС;
  • приемы кодирования на языках описания аппаратуры, обеспечивающие формирование схем, оптимальных для архитектуры ПЛИС;
  • особенности разработки систем начального уровня, преимущественно на базе ПЛИС Spartan‑6;
  • особенности разработки систем на ПЛИС большого логического объема;
  • проектирование на системном уровне с применением процессорных ядер и модулей цифровой обработки сигналов;
  • эффективное использование САПР Vivado, описание схем с учетом аппаратной платформы, создание проектных ограничений, управление топологией кристалла и автоматизация процесса разработки.

 

Современные FPGA Xilinx

В настоящее время активными являются ПЛИС, выполняемые по технологическим процессам 45 (Spartan‑6) и 28 нм (серия 7). Также заявлено семейство UltraScale (рис. 1), которое будет производиться с нормами 20 нм, с последующим переходом к 16 нм. Появление инженерных образцов UltraScale запланировано на 2015 год, поэтому их применение в проектах следует отложить до официального открытия приема заказов.

Планы выпуска ПЛИС Xilinx

Рис. 1. Планы выпуска ПЛИС Xilinx

Характеристики современных ПЛИС Xilinx приведены в таблице 1.

Таблица 1. Характеристики современных ПЛИС Xilinx

Параметр

Spartan-6

Artix-7

Kintex-7

Virtex-7

Kintex UltraScale

Virtex UltraScale

Техпроцесс, нм

45

28

28

28

20

20

Логических ячеек

147 443

215 360

477 760

1 954 560

1 160 880

4 407 480

Блочной памяти, Мбайт

4,8

13

34

68

76

132,9

Секций DSP

180

740

1920

3600

5520

2880

Операций «умножение с накоплением» (с симметричными коэффициентами), GMAC/s

140

930

2845

5335

8180

4268

Количество приемопередатчиков

8

16

32

96

64

120

Максимальная скорость приемопередатчиков, Гбит/с

3,2

6,6

12,5

28,05

16,3

32,75

Суммарная пропускная способность приемопередатчиков, Гбит/с

50

211

800

2784

2086

5886

Скорость работы памяти DDR3

800

1066

1866

1866

2400

2400

PCI Express

×1 Gen1

×4 Gen2

×8 Gen2

×8 Gen3

×8 Gen3

×8 Gen3

Программируемых выводов

576

500

500

1200

832

1456

Напряжение питания программируемых выводов, В

1,2–3,3

1,2–3,3

1,2–3,3

1,2–3,3

1–3,3

1–3,3

Поддержка САПР

ISE

ISE

Vivado

ISE

Vivado

ISE

Vivado

Vivado

Vivado

Архитектура FPGA претерпела существенные изменения не только на протяжении существования данной технологии (с 1985 года), но и в течение последних 10 лет. Заметными вехами можно считать появление FPGA, выполненных по 90‑нм нормам технологического процесса (Virtex‑4 и Spartan‑3), а также 28‑нм серию 7. В первом случае в индустрии был остро поставлен вопрос о переходе к полностью синхронной методологии проектирования, поскольку реализация асинхронных схем на 90‑нм нормах перестала обеспечивать воспроизводимость характеристик проектов. Соответственно, большой пласт литературы по проектированию цифровых схем, в которой не делался специальный акцент на необходимость следования методологии синхронного проектирования, утратил свою актуальность. Разработчикам пришлось (и до сих пор приходится) уточнять предпочтительные шаблоны проектирования и осваивать схемотехнические решения, способные поддерживать надежную работу в цифровых микросхемах, выполненных по современным техпроцессам.

При переходе к нормам 28 нм в серии 7 тенденции, существовавшие в микроэлектронной технике, привели к еще одному качественному переходу. Размеры полупровод-никового кристалла увеличились настолько, что задержки распространения сигналов стали оказывать определяющее влияние на характеристики схемы. Одновременно возрос и удельный вес выделенных аппаратных ресурсов FPGA — таких как блочная память, блоки DSP, высокоскоростные последовательные приемопередатчики. Иными словами, для достижения высокой частоты мало просто спроектировать схему в синхронном стиле. Не менее важно соответствующим образом поместить на кристалл компоненты проекта, чтобы связи между ними оказались достаточно короткими. Эта задача осложняется тем, что ключевыми для проекта могут быть именно аппаратные ресурсы, имеющие фиксированное положение. Размещение взаимодействующих компонентов на противоположных углах кристалла FPGA приведет к тому, что по совершенно объективным причинам не удастся достичь нужных параметров производительности.

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

 

Блоки XtremeDSP

Цифровая обработка сигналов — признанная область, в которой FPGA демонстрируют великолепные показатели как по абсолютной производительности, получаемой на одном кристалле, так и по относительной стоимости одной операции «умножение с накоплением». Это достигается размещением в FPGA большого количества блоков DSP48, которые благодаря аппаратной реализации работают на высокой тактовой частоте и потребляют умеренную мощность. В UltraScale хорошо зарекомендовавшая себя архитектура DSP48 обрела очередной набор модификаций, блок теперь называется DSP48E2. Его архитектура схематично показана на рис. 2.

Блок цифровой обработки сигналов DSP48E2

Рис. 2. Блок цифровой обработки сигналов DSP48E2

Основные особенности данного блока:

  • блоки объединены попарно в компонент DSP slice с добавлением выделенных аппаратных ресурсов, облегчающих построение некоторых часто применяемых схем;
  • умножитель 27×18 (вместо 25×18) бит;
  • 27‑битный предварительный сумматор;
  • добавлены возможные операнды для АЛУ (например, обратная связь по сигналу P), что расширяет функциональность блока при выполнении математических операций;
  • добавлен блок XOR в АЛУ;
  • введена возможность программируемой инверсии сигнала сброса.

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

Высокоскоростные последовательные приемопередатчики (MGT)

Высокоскоростные последовательные приемопередатчики (Multi-Gigabit Transceivers, MGT) — один из компонентов, определяющих современную сферу применения FPGA. Большое количество аппаратных ядер приемопередатчиков на одном кристалле обеспечивает высокую пропускную способность в коммуникационных приложениях. Размещение на том же кристалле достаточного количества программируемых ресурсов позволяет выполнять различные виды обработки передаваемых данных, что делает FPGA привлекательной аппаратной платформой для реализации высокотехнологичного коммуникационного оборудования. Семейство UltraScale нацелено на системы класса 100G и 400G. Структурная схема приемопередатчика показана на рис. 3.

Структурная схема приемопередатчика

Рис. 3. Структурная схема приемопередатчика

По сравнению с приемопередатчиками серии 7, UltraScale получила в целом аналогичные по функциональности модули с ожидаемым вследствие нового техпроцесса улучшением производительности. Краткая характеристика приемопередатчиков в FPGA UltraScale приведена в таблице 2.

Таблица 2. Краткая характеристика приемопередатчиков в FPGA UltraScale

 

Kintex UltraScale

Virtex UltraScale

Название

GTH

GTH

GTY

Количество

16–64

20–52

0–52

Максимальная скорость передачи, Гбит/с

16,3

16,3

32,75

Минимальная скорость передачи, Гбит/с

0,5

0,5

0,5

Пример приложения

Backplane, PCI Express Gen4

Backplane, PCI Express Gen4

100 G+, Chip to Chip, 25 G+ Backplane

 

PCI Express

Все FPGA UltraScale имеют по крайней мере один аппаратный контроллер PCI Express, соответствующий спецификации стандарта 3.0. Контроллеры PCI Express устанавливались и в предыдущих поколениях FPGA Xilinx, обеспечивая не столько экономию программируемых ресурсов (ядро контроллера PCI Express оценивается приблизительно в 5 тыс. ячеек), сколько гарантированные характеристики производительности, не зависящие от нюансов размещения проекта в кристалле. Обычно аппаратное ядро PCI Express может быть дополнено программируемыми ресурсами для создания условий совместимости с более поздним стандартом спецификации. Согласно текущей документации ядро поддерживает 1, 2, 4 или 8 линий и может работать со скоростями передачи 2,5, 5 и 8 Гбит/с.

 

Аппаратные блоки 100G Ethernet и Interlaken

В UltraScale впервые добавлены аппаратные контроллеры 100G Ethernet и Interlaken. Как и для PCI Express, эти контроллеры облегчают построение соответствующих интерфейсов, освобождая разработчика от необходимости выполнять настройку конфигурируемых решений и следить в процессе проектирования за соблюдением требований к относительному размещению компонентов. Блок 100G Ethernet поддерживает конфигурации 10×10,3125 Гбит/с или 4×25,78125 Гбит/с. Актуальность следующего поколения интерфейса Ethernet, по всей видимости, не подлежит сомнению.

Интерфейс Interlaken представляет собой масштабируемый протокол обмена chip-to-chip, работающий на скоростях 10–150 Гбит/с. Так же, как и 100G Ethernet, Interlaken основан на использовании нескольких линий связи для достижения высокой суммарной скорости. Поддерживаются режимы: 1–12 линий на 10,3125 Гбит/с, 1–12 линий на 12,5 Гбит/с и 1–6 линий на 25,78125 Гбит/с.

 

Организационно-экономические аспекты применения ПЛИС

Применение ПЛИС в системах низкой стоимости

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

  • CPLD CoolRunner-II малой степени интеграции (32, 64, возможно, 128 макроячеек);
  • FPGA Spartan‑6 LX4 и LX9 (важно, что эти FPGA единственные среди актуальных в настоящий момент ПЛИС имеют вариант исполнения в корпусе TQFP144, остальные микросхемы выпускаются только в корпусах BGA).

Хотя стоимость типичной FPGA выше, чем у недорогих микроконтроллеров, не всегда корректно полагать, будто разница в цене обеих микросхем представляет собой чистую прибыль разработчиков. Если предположить, что ПЛИС стоимостью 10 условных единиц сравнивается с МК стоимостью в 1 единицу, то можно сказать, что стоимость этих компонентов отличается в 10 раз. Однако будет ли себестоимость печатных плат также отличаться в 10 раз? Скорее всего, нет. Площадь печатной платы при установке ПЛИС вместо (или вдобавок к) МК изменится крайне несущественно. Примерно такой же останется и подсистема питания, сохранятся датчики, разъемы, силовые ключи и дополнительные компоненты (например, микросхемы интерфейсов, преобразователи уровней, трансформаторы и дроссели). А потому можно говорить скорее об увеличении стоимости компонентов на 9 единиц. Однако при этом применение ПЛИС способно привести к упрощению проекта и улучшению его характеристик, что компенсирует повышение стоимости компонентов.

Оправдывает ли себя добавление ПЛИС в изделие с предполагаемо низкой себестоимостью? Ответ на этот вопрос зависит от того, испытывает ли разработчик необходимость в решении специфических задач, к числу которых относятся:

  1. Замена микросхем малой и средней степени интеграции на CPLD (в ряде случаев — на FPGA).

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

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

Компания Xilinx выпустила специальную утилиту Discrete Logic Consolidator, представляющую собой лист MS Excel с встроенными макросами. Утилита (рис. 4) выполняет расчет стоимости дискретных компонентов в сравнении с CPLD, имеющей достаточно ресурсов для реализации выбранного списка микросхем.

Внешний вид утилиты Discrete Logic Consolidator

Рис. 4. Внешний вид утилиты Discrete Logic Consolidator

  1. Аппаратная реализация систем цифровой обработки сигналов.

FPGA имеют в своем составе аппаратные блоки «умножение с накоплением» (DSP48), которые являются основой для построения таких широко распространенных блоков, как КИХ- и БИХ-фильтры, блоки быстрого преобразования Фурье, корреляторы и т. д. Поскольку блоки DSP48 представляют собой аппаратные компоненты, а не набор программируемых ячеек, это делает их характеристики приближенными к характеристикам аналогичных компонентов сигнальных процессоров — в Spartan‑6 блоки DSP48 могут работать на частоте до 325 МГц. Младшая ПЛИС в семействе, XC6SLX4, имеет 4 аппаратных блока, что дает в реальном проекте 800–1200 MMAC/s. Практически это означает, что в изделии появляется устройство цифровой обработки сигналов с производительностью около 1 GMAC/s, действующее независимо от МК.

  1. Аппаратная реализация подсистем, требующих реакции в реальном масштабе времени.

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

Применение ПЛИС в среднем ценовом сегменте

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

К рассматриваемым для решения подобных задач ПЛИС можно отнести:

  • Spartan‑6 среднего и верхнего уровня;
  • Artix‑7 (все микросхемы);
  • Kintex‑7 начального уровня, ориентировочно XC7K70 и XC7K160;
  • микросхемы Zynq‑7000 начального уровня (ZC7010, ZC7015, ZC7020).

Применение ПЛИС в проектах высокой стоимости

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

  • Прототипирование интегральных микросхем.
  • Аэрокосмические применения.
  • Магистральное коммуникационное оборудование.
  • Управление сложными промышленными системами и комплексами.
  • Исследовательские проекты в науке и технике.

В целом Xilinx рассматривает следующие основные сферы применения ПЛИС:

  • Аэрокосмические приложения.
  • Прототипирование интегральных микросхем.
  • Аудиосистемы.
  • Автомобильная электроника.
  • Широковещательные системы.
  • Бытовая электроника.
  • Центры обработки данных.
  • Суперкомпьютеры.
  • Промышленное оборудование.
  • Медицинское оборудование.
  • Системы безопасности.
  • Сетевое оборудование.
  • Обработка видео.
  • Проводные сети.
  • Беспроводные сети.

 

Оценка достижимых характеристик проекта и технических рисков

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

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

Для ПЛИС снижение производительности происходит из-за двух факторов:

  • увеличение периода тактового сигнала из-за сложности реализуемой схемы;
  • неполное использование ресурсов ПЛИС в конкретном проекте.

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

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

Эти условия для практических проектов бывают невыполнимыми по объективным причинам. Так, сложная обработка логических выражений может потребовать более одной LUT, что автоматически снизит тактовую частоту. Сигналы могут быть востребованы множеством получателей, распределенных по всему кристаллу, что удлинит трассировочные линии.

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

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

К распространенным архитектурным ошибкам можно отнести:

  • неверное распределение вычислительной нагрузки между FPGA и внешним процессором (для FPGA предпочтительны несложные потоковые операции, выполняемые независимыми параллельно работающими блоками);
  • использование малоэффективных подходов к реализации отдельных операций (в частности, применение процессоров MicroBlaze в задачах цифровой обработки сигналов вместо секций DSP, и наоборот — громоздких конечных автоматов вместо процессора MicroBlaze);
  • выбор неэффективной схемы синхронизации (при увеличении тактовой частоты интерфейсов для них становится предпочтительным использование source-synchronous-схем вместо system-synchronous, а рост объема схемы заставляет обращаться к архитектуре GALS — Globally Asynchronous, Locally Synchronous).

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

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

  1. Оценивается сложность схемы и определяется (либо устанавливается) допустимый параметр Logic_levels (количество уровней логики). Верхняя граница достижимой тактовой частоты может быть оценена как:

f = fsystem/Logic_levels.

  1. Делается поправка на сложность трассировки и интенсивность перекрестных связей между модулями.

Идеальная схема должна содержать только одну LUT между каждой парой триггеров. В цепочке возможно включение модулей DSP48 и блочной памяти, однако никакая пара связанных компонентов не должна располагаться настолько далеко, чтобы не иметь возможности быть связанной локальными трассировочными линиями. С учетом того, что реальные схемы трудно привести к такому шаблону, частота проектов на базе ПЛИС становится заметно меньше той частоты, которая указывается Xilinx в качестве системной. Факторы, влияющие на тактовую частоту проекта, проиллюстрированы на рис. 5. На этом рисунке цветом выделены те диапазоны, в которых может ожидаться достигаемое значение тактовой частоты, учитывая, что верхняя граница определяется количеством уровней логики, однако трассировочные линии добавят собственную задержку. Вот почему следует обратить внимание на то, что для семейства UltraScale отмечается улучшение характеристик трассировочных ресурсов, а системная тактовая частота оставлена без изменений по сравнению с серией 7. Можно ожидать, что улучшение характеристик трассировочных ресурсов позволит получать более точные оценки тактовой частоты на ранних стадиях проекта, поскольку «уход вниз» от базового значения верхней границы частоты станет более предсказуемым.

Факторы снижения тактовой частоты проекта

Рис. 5. Факторы снижения тактовой частоты проекта

Если говорить о крайне осторожной и общей оценке тактовых частот, то следует указать величину в 200–250 МГц для ПЛИС Virtex‑7/Kintex‑7. Для цепочек ЦОС (то есть фрагментов на базе блоков DSP48 с управляющими схемами) и систем последовательной обработки пакетов данных можно ожидать некоторого повышения (скажем, до 300–400 МГц), а для сложных управляющих схем, работающих с сигналами большой разрядности, — снижения. Указанные величины отражают статистику по частному набору проектов и ни в коем случае не могут считаться основанием для формулирования технического задания. Скорее стоит говорить о соответствии некоторому абстрактному набору разработок, существующих в промышленности. Реальные задачи, особенно имеющие специфическую направленность, могут по объективным причинам изменять приведенные цифры.

 

Модели жизненного цикла и порядок их выбора применительно к разработке проектов на базе ПЛИС

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

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

  1. Исследование концепции.
  2. Исследование системы.
  3. Требования.
  4. Разработка проекта.
  5. Внедрение.
  6. Установка.
  7. Эксплуатация и поддержка.
  8. Сопровождение.
  9. Вывод из эксплуатации.

Для инженеров, выполняющих проектирование цифровой части, основной интерес представляет пункт 4 — «Разработка проекта». Он может восприниматься ими не только как преобладающий по важности, но и как единственный, имеющий реальное значение. С одной стороны, чрезмерное внимание к организационным вопросам может быть следствием недостаточной квалификации. С другой стороны — пренебрежение и даже игнорирование организационных аспектов приводит к затягиванию сроков получения работоспособного изделия и выпуска коммерчески успешного продукта на рынок.

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

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

Каскадная модель

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

Инкрементная модель

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

Спиральная модель

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

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

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

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

 

Инструменты описания проекта

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

Системный уровень

Системный уровень — описание проекта с помощью высокоуровневых инструментов, которые максимально абстрагируются от деталей реализации проекта. Сюда можно отнести языки высокого уровня, используемые в САПР класса High Level Synthesis, System Generator for DSP, генератор процессорных систем. Для системного уровня характерна возможность быстрого заполнения FPGA, однако гибкость описания иногда оказывается ограниченной. Так, использование System Generator for DSP обусловливает преимущественную работу с IP-ядрами для цифровой обработки сигналов, и применение этого инструмента для посторонних задач существенно усложняется.

Поведенческий уровень

Поведенческий уровень (behavioral) — уровень, на котором, как следует из названия, описывается желаемое поведение устройства. Здесь можно описать, например, многоканальное устройство в виде циклического повторения установки в проект однократно описанного компонента.

Уровень регистровых передач

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

Структурный уровень

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

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

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

Приведенные на рис. 6 инструменты разработки ориентированы на решение следующих задач:

  1. Vivado HLS — среда разработки синтезируемых модулей и их системного моделирования с помощью языков С/С++/SystemC.
  2. System Generator for DSP — расширение для ПО Matlab, позволяющее моделировать подсистемы цифровой обработки сигналов в инструменте Simulink. Смоделированные узлы могут быть автоматически экспортированы в САПР ISE/Vivado с сохранением основных характеристик производительности. System Generator — специализированный инструмент, поэтому его применение ограничено разработкой подсистем ЦОС. Добавление новых компонентов значительно сложнее, чем работа в Simulink с графическим представлением проекта, а потому использовать System Generator для построения устройств общего назначения неэффективно.
  3. IP Integrator — библиотека IP-ядер, созданных Xilinx. В текущих версиях имеется более 200 ядер, сгруппированных по назначению и необходимых для решения частных задач. Преимущество IP-ядер заключается в том, что они сопровождаются проектными ограничениями, описывающими взаимное расположение отдельных компонентов. В результате характеристики ядер оказываются хорошо воспроизводимыми и не зависят от квалификации разработчика, который выполняет их подключение.
Маршрут проектирования с применением инструментов разработки Xilinx

Рис. 6. Маршрут проектирования с применением инструментов разработки Xilinx

 

Оценка сроков выполнения проекта

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

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

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

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

С оценкой времени на выполнение проекта тесно связана оценка технических рисков. В качестве утрированного примера (технически он корректен, но вряд ли будет полезен на практике) можно рассмотреть преобразователь PCI-Express — UART. Для данного проекта необходимо выполнить следующие работы:

  • Настройку аппаратного ядра PCI Express.
  • Разработку контроллера UART.
  • Проектирование печатной платы с соблюдением жестких требований по трассировке печатных проводников.

Если выполнять работы в порядке их упоминания, то выяснится, что настройка ядра PCI Express реализуется с помощью стандартного приложения Core Generator, а контроллер UART представляет собой простой конечный автомат. На этом можно посчитать проект завершенным на 66%. Однако последним пунктом указана разработка печатной платы для сопряжения высокоскоростных последовательных приемопередатчиков с краевым печатным разъемом PCI Express. Данный пункт требует существенно большего внимания и в указанном списке может смело считаться основным источником ошибок, приводящих к неработоспособности устройства. Поэтому при начале работы над проектом следует выявить потенциально проблемные места, которые вызовут дополнительные сложности при реализации проекта, потребуют дополнительного времени, применения сложного контрольно-измерительного оборудования, привлечения дополнительных специалистов и т. п. Можно указать некоторые возможные причины появления технических рисков, способных существенно ухудшить показатели проекта по сравнению с ожидаемыми:

  1. Жесткие требования к печатной плате для высокоскоростных интерфейсов. Данный источник рисков был рассмотрен выше в качестве примера сопряжения аппаратного ядра FPGA (не требующего сложной настройки) и внешнего компонента. Подобные же проблемы может вызвать память DDR2/3, дифференциальные интерфейсы и вообще внешние линии, работающие на частоте свыше 50–100 МГц (цифра весьма размытая, поскольку невозможно указать точное значение частоты, после которого проблемы качественной трассировки печатной платы выйдут на первый план).
  2. Ориентация разработчиков на пиковые характеристики FPGA, электрических интерфейсов и САПР. При взгляде на таблицу характеристик FPGA возникает естественное желание перемножить количество блоков (секций DSP, приемопередатчиков), интересующих разработчика, на их пиковую частоту/пропускную способность. Однако при этом необходимо делать поправки как на объективные технические параметры ПЛИС и особенности протоколов, так и на возможность достижения желаемых результатов за разумное время. Многие электрические интерфейсы заявляют скорости передачи данных без учета накладных расходов (скажем, на организацию пакетов). Интерфейсы Ethernet, USB и PCI Express становятся в этом плане хорошим примером сильного несоответствия реальной пропускной способности и пиковых характеристик. Так, для Ethernet лишь часть передаваемого пакета представляет собой пользовательские данные, причем существует минимальный размер пакета и минимально требуемый интервал между пакетами. Для USB предусмотрено техническое ограничение в 1000 пакетов в секунду. В конечном итоге при реализации устройства разработчик может обнаружить, что его фактические характеристики серьезно отстают от ожидаемых.
  3. Занижение сроков отладки и тестирования, «магия бренда». Бытует мнение о том, что популярные ОС, протоколы обмена и программные технологии просты для освоения в силу своей распространенности. Для ПЛИС Xilinx действительно существуют успешные реализации изделий на базе ОС Linux и Android, поддерживающие большое количество широко применяемых интерфейсов (Ethernet, Wi-Fi, HDMI, PCI Express и т. д.). Однако необходимо четко представлять сроки реализации и трудоемкость создания собственного изделия, способного функционировать под управлением Linux или Android, поддерживать упомянутые технологии и отвечать требованиям стандартов, чтобы иметь возможность работать не только в лабораторных условиях, но и взаимодействовать с другими устройствами. В этом случае «магия бренда» проявляется в откладывании на поздние сроки реализации широко распространенных технологий. Причем разработчики необоснованно полагают, что если эти технологии используются в широко распространенных потребительских устройствах, то и они не встретят в этих областях серьезных препятствий.

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

 

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

Промежуточные контрольные точки

При повышении сложности проекта все более важную роль начинают играть грамотно выбранные контрольные точки. Только проекты небольшого размера могут быть выполнены «от начала и до конца». Для сложных проектов контрольные точки следует выбирать таким образом, чтобы они помогали выявить вероятные проблемы на ранних этапах проектирования. В приведенном выше примере с высокоскоростным интерфейсом контрольные точки нужно определять с учетом именно его реализации. В частности, обеспечение передачи пакетов по PCI Express является хорошей контрольной точкой, поскольку в этом случае становится понятно, что печатная плата реализована качественно и ядро настроено правильно. Эта точка делает возможным переход к отладке протоколов обмена. В то же время реализация модуля UART или регистров для вывода статуса на светодиоды не отвечает на вопросы о критических компонентах проекта.

Управление версиями и резервное копирование

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

Стиль оформления кода

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

Комментарии

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

  1. «Внешние» комментарии (в терминологии Xilinx) — отдельные документы в форматах pdf, html, doc, статьи, книги (в случае особенно сложных компонентов). Такие комментарии, являющиеся по сути техническими описаниями, призваны разъяснять разработчикам основы функционирования модулей.
  2. Комментарии уровня модуля обычно представляются в виде заголовочной части модуля, в которой приводится информация о его названии, версии, компании-разработчике и авторе модуля, краткое техническое описание и т. д. Размещение такого фрагмента в начале файла способствует единообразию в описаниях отдельных модулей, что помогает быстрому анализу состояния проекта.
  3. Комментарии уровня группы строк описывают планируемое действие отдельного фрагмента. В данном случае было бы излишним дублировать информацию, которую можно легко получить при изучении фрагмента. К примеру, для счетчика на VHDL комментарий, утверждающий, что это счетчик, очевиден и не несет полезной информации:
-- счетчик (пример малополезного комментария)
process(clk)
begin
    if rising_edge(clk) then
        if count = 99 then
           count <= 0; else count <= count + 1;
        end if;
    end if;
end process;

Гораздо полезнее была бы информация о том, какую роль в проекте играет этот счетчик и почему он считает от 0 до 99. Так, следующий комментарий не только разъясняет назначение реализованного счетчика, но и помогает отследить, действительно ли приведенный после комментария блок текста выполняет функцию, запланированную разработчиком:

-- формирование управляющего сигнала для контроллера SPI
-- входная частота 200 МГц, получаемый стробирующий сигнал 2 МГц

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

  1. Комментарии уровня строки служат аналогичной цели. Точно так же комментарий, дублирующий информацию, явно видную из RTL-представления, излишен. Важнее поместить пояснение, почему выполняется именно это действие или почему выбрана именно эта константа. Полезно отметить и параметры или выражения, которые потребуют коррекции при изменении каких-либо условий — например, разрядности сигналов, размеров буфера и т. п.
  2. Встроенные комментарии. К ним относятся выразительные имена переменных, сигналов и других объектов модуля, способствующие пониманию выполняемых действий. Например, следующее выражение выглядит очевидным:
Final_value <= initial_value + delta;

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

Sdfqa <= er(2).df + cl1o0;

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

Тестирование и устранение ошибок

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

Моделирование

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

Стендовые испытания

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

Интеграционные тесты

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

Испытания в полевых условиях

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

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

Планирование длительных процессов САПР

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

Поэтому при выявлении чрезмерно возросшей длительности создания проекта необходимо принять решение о систематизации процессов запуска САПР, чтобы получить новый вариант конфигурационного файла. Недостаток для разработчиков заключается в том, что появляющиеся предположения о способах коррекции исходных текстов проекта уже не могут быть проверены немедленно. Действительно, бессистемные правки исходных текстов в данной ситуации станут непроизводительной потерей времени, поскольку каждое редактирование, выполняющееся за 5–10 минут, будет сопровождаться многочасовым процессом обновления файла конфигурации. Число итераций отладки сократится до одного-двух в течение рабочего дня. В такой ситуации совершенно необходимо, чтобы разработчики потратили дополнительное время на проверку внесенных изменений и определили, что именно они ожидают получить в результате. Ситуация с бессистемной и длительной компиляцией отражена в популярной серии комиксов xkcd, на одном из которых руководитель интересуется, почему его программисты не работают. Их ответ «Компилируется!» его полностью удовлетворяет, однако следует признать, что таким образом программисты, скорее всего, искусственно создают перерыв в работе, ссылаясь на необходимость дождаться завершения необоснованно запущенного ими длительного процесса компиляции. Для ПЛИС ситуация резко усугубляется, поскольку создание конфигурации ПЛИС обычно занимает больше времени, чем компиляция сопоставимого по сложности программного продукта.

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

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

 

Порядок разработки

Для проектной деятельности применимы два взаимодополняющих подхода к разработке: «снизу вверх» (также bottom up) и «сверху вниз» (top down). В первом случае модули проекта последовательно создаются и отлаживаются, после чего производится их сборка и проверка корректности совместной работы. Процесс продолжается до тех пор, пока в результате объединения не будет получен верхний уровень схемы. При построении проекта «сверху вниз» спроектированный верхний уровень разбивается на субмодули до тех пор, пока не будет получен набор компонентов, каждый из которых достаточно прост для реализации.

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

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

Для больших коллективов (граница довольно размыта, в [1] упоминается размер в 20–30 технических специалистов) оптимальной будет функциональная специализация. В этом случае в организации существуют выделенные сотрудники, занятые решением частных задач. Преимуществом данного подхода является возможность углубленного освоения сложных технологий — например, построения интерфейсов PCI Express, памяти DDR или процессорных систем на базе MicroBlaze/ARM. Выделенные специалисты могут сосредоточиться на изучении конкретного инструмента, выполняя настройку соответствующих модулей для всех проектов в организации. Однако таких разработчиков вряд ли следует отвлекать для выполнения рутинных работ, скажем, по доводке приборов и отладке прикладного программного обеспечения. Именно поэтому углубленная специализация рекомендуется при наличии достаточно большого коллектива, способного позволить определенное уменьшение количества параллельно выполняемых проектов.

На практике следует ожидать использования смешанного подхода, когда сложные технологии осваиваются специально назначаемыми инженерами, которые, сохраняя собственный пакет проектов, выполняют какие-то работы для всего коллектива. В оптимальном варианте стоит выбрать такие технологии и узлы, чья реализация не занимает слишком много времени, однако имеет множество нюансов, подлежащих длительному изучению. Можно рекомендовать включить в данный список уже упомянутые PCI Express, контроллеры памяти DDR, высокоскоростные интерфейсы как таковые и, возможно, настройку процессорных подсистем. Конкретный список технологий и узлов, которые будут выполняться в организации специально подготовленными сотрудниками, должен формироваться в индивидуальном порядке и не должен рассматриваться как окончательный.

 

Заключение

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

Литература
  1. Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. Парал. тит. англ. Пер. с англ. — М.: Издательский дом «Вильямс», 2004.
  2. Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. — М.: Издательство «Русская редакция», 2013.
  3. UltraScale Architecture Configurable Logic Block. Advance Specification User Guide 
  4. UltraScale Architecture DSP Slice. Advance Specification User Guide
  5. http://www.xilinx.com/support/documentation/user_guides/ug579‑ultrascale-dsp.pdf
  6. UltraScale Architecture Memory Resources. Advance Specification User Guide
  7. http://www.xilinx.com/support/documentation/user_guides/ug573‑ultrascale-memory-resources.pdf
  8. UltraScale Architecture GTH Transceivers. Advance Specification User Guide http://www.xilinx.com/support/documentation/user_guides/ug576‑ultrascale-gth-transceivers.pdf

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *