Обзор технологии High Level Synthesis

Технология High Level Synthesis появилась в начале 2000-ых годов и активно продвигается компаниями-разработчиками аппаратных и программных решений, в том числе: Cadence (Stratus), Synopsis (SymphonyC), Altera (A++), Xilinx (VivadoHLS), Mentor Graphics (Catapult C) и другими (рис. 1 а, б).

High Level Synthesis (HLS) позволяет получать код RTL-уровня (RTL – Register Transmission Level, уровень регистровых передач) из исходного кода, написанного на языках высокого уровня (большинство инструментов, представленных на рынке, поддерживают языки C, C++, SystemC и SystemVerilog) [1].

Растущие объёмы логических ячеек в современных кристаллах ПЛИС снижают требования к оптимизации RTL-кода и открывают возможности для использования новых, более высокоуровневых инструментов. Увеличивающееся количество ячеек делает процесс разработки сложных проектов на уровне RTL весьма трудоёмким, поэтому рационально перейти на уровень выше – хоть это и приведёт к увеличению аппаратных затрат (так как высокоуровневые алгоритмы заведомо более ресурсоёмки) и потенциальной необходимости увеличения тактовой частоты, но с другой стороны позволит привлечь к разработке программистов, использующих языки высокого уровня, упростить использование готовых высокоуровневых алгоритмов без необходимости переписывать алгоритм под языки аппаратного описания, такие как Verilog или VHDL (так как HLS позволяет компилировать код, написанный на языке высокого уровня, в код RTL-уровня). Помимо RTL-кода, инструменты HLS позволяет синтезировать и так называемый «поведенческий» (в англоязычной литературе обозначается как “untimed”) код, то есть код не имеющий привязки ко времени (не содержит конструкций для остановки процесса, таких как функция wait).

Практическое использование ПЛИС и языков аппаратного описания (HDL) часто вызывает трудности для программистов, использующих языки высокого уровня, которые сталкиваются с целым рядом нетипичных для них задач: необходимостью помнить о правильном формировании тактовых сигналов, учитывать латентность, а также помнить, что операторы языков описания аппаратуры не вполне эквивалентны операторам языков программирования. Разные схемотехнические решения будут получены для случая, когда сложение выполняется в виде оператора непрерывного присваивания (в англоязычной литературе обозначается как “Continuous assignment”) и внутри синхронного процесса. В то же время, цифровая схемотехника по мере уменьшения норм технологического процесса всё больше тяготеет к синхронным схемам. В итоге оказывается, что множество усилий при проектировании на базе ПЛИС тратится на разработку конечного автомата, чьей задачей является изменение сигналов в определённые периоды времени [1].

В качестве исходных данных для HLS пакета выступают следующие сущности:

·     Исходный код на языке высокого уровня;

·     Временные ограничения (в англоязычной литературе обозначаются как “Timing constraints”), задают список тактовых сигналов и их период, а также задержки на внешних портах;

·     Спецификация микроархитектуры (конвейер, развёрнутый цикл и прочее);

·     Директивы компилятора, задающие как два вышеуказанных параметра, так и для указания параметров экспортирования (например, в виде IP-ядра).

Рисунок 1 (а). Маршрут проектирования в САПР Cadence Stratus HLS

Рисунок 1 (б). Маршрут проектирования в САПР Xilinx Vivado HLS

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

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

В целом существует несколько возможных векторов применения технологии:

1)  Унификация при разработке ПО. Применяется в случае, если разрабатывается ПО не только для ПЛИС, но и для систем на микроконтроллерах, ПК и т. д. В таком случае ускоряется время разработки, так как пропадает необходимость портирования под конкретную аппаратную платформу, эта задача решается средствами инструментов HLS.

2)  Перенос готовых алгоритмов, написанных на языках высокого уровня, без необходимости вручную портировать на HDL.

3)  Применение в системах на кристалле (SoC), где параллельно используется CPU и FPGA.

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

Компания Xilinx заявляет, что в связи с значительным увеличением логической ёмкости FPGA, старые методы программирования (на языках VHDL и Verilog) уже не справляются с современными задачами, и есть большая вероятность, что в будущем программирование на ПЛИС будет вестись исключительно на языках высокого уровня типа С и С++. Упор делается на то, что в представленном средстве проектирования Xilinx Vivado HLS разработка сводится к тому, что можно уйти от понятия «тактовая частота», и разрабатывать сложные алгоритмы без привязки к конкретной ПЛИС, а всю оптимизацию под ПЛИС уже делать на последней стадии проекта [2]. Действительно, разработка простых проектов также может быть ускорена и упрощена. К примеру, реализация простого фильтра с конечной импульсной характеристикой сведётся к предварительному расчёту коэффициентов, например в Matlab, и дальнейшем описании цикла со счётчиком типа «for» на языке C. После этого разработчику следует указать директивы компилятору HLS (для нахождения баланса между занимаемой площадью и скоростью работы схемы), и сгенерировать результат. В случае, если результат не удовлетворяет, используя директивы и незначительные правки исходного кода, можно изменить выходной RTL-код не прилагая значительных усилий, в отличие от классического метода проектирования.

В целом, разработчики, использующие ASIC и FPGA не слишком заинтересованы в данной технологии[3], в основном из-за проблем с производительностью и последовательностью кода. Помимо этого, играет роль психологический фактор – программисты, освоившие HDL-языки, не слишком стремятся полностью изменять методологию разработки, осваивать C++, изучать логику работы параметризированных классов и директивы HLS-компилятора, а впоследствии выявлять и устранять неявные программные ошибки, возникшие вследствие применения HLS. Высокоуровневые программисты же наоборот, не слишком стремятся вникать в аппаратные особенности и временные задержки. В среде HDL-разработчиков распространено мнение, что HLS – целиком и полностью малопопулярная технология, продвигаемая маркетологами крупных компаний-разработчиков ПЛИС [6]. Как показывает практика, на отечественных производствах технология была опробована, однако промышленного применения не нашла.

Стоит отметить направление, использующее промежуточный этап в виде LLVM (Low Level Virtual Machine — платформонезависимую виртуальную машину), так как такой подход позволяет производить промежуточную оптимизацию перед синтезом в HDL[5].

Интерес представляет подход с параллельным применением в системах на кристалле, так как он позволяет эффективно исполнять «быстрые» вычисления на ПЛИС параллельно работе CPU. Это может быть использовано для аппаратного кодирования-декодирования и прочих преобразований видео, а также крайне эффективно для систем распознавания образов[3]. Однако такие SoC-решения отличаются высокой стоимостью[7]. Помимо этого, можно комбинировать несколько подходов, то есть использовать уже готовые высокоуровневые алгоритмические модели в СнК («Система на кристалле»). Известен случай, когда компания Google применяла HLS-инструмент Catapult C для аппаратной реализации видеокодека VP9 на основе ранее имевшейся высокоуровневой программной реализации не изменяя язык разработки [4].