Процесс проектирования плюс FPGA для разработчиков программного обеспечения:новая осязаемая реальность

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

Введение

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

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

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

Понимание методологии проектирования на системном уровне
Дизайн на уровне системы ориентирован на проблемы более высокого уровня абстракции. Хотя существует необходимость сконцентрироваться на более широкой картине, используются различные уровни абстракций для проверки, проверки, уточнения и интеграции различных частей системы, прежде чем она будет фактически разработана. Несмотря на то, что инженерное сообщество не соглашается с общим языком для использования, большинство инженеров-проектировщиков начинают с алгоритмического уровня. Разработчики проверяют нефункциональные и функциональные спецификации системы, создавая модели исполнения, написанные в средах C / C ++ / SystemC, MATLAB, Simulink и LabVIEW. Эти языки высокого уровня используются для моделирования поведения всей системы.

В рамках этого обсуждения мы сосредоточились на потоке проектирования на уровне системы, основанном на спецификациях C / C ++ (рисунок 1). Первый блок разделен на три этапа. Первый из этих шагов представляет собой профилирование приложения (т. Е. Аппаратно-программное разделение), при котором части кода C / C ++ (функции, циклы и т. Д.) Считаются перемещенными в аппаратное обеспечение (FPGA). Следующим шагом является спецификация платформы CPU / FPGA (например, ARM53 / FPGA, POWER8 / FPGA) и настройка элементов аппаратной платформы (системные часы, кэш процессора, соединения и т. Д.). Следующим шагом является сопоставление задач приложения (на основе профилированного приложения) между аппаратным и программным обеспечением (т. Е. Аппаратным и / или программным процессором) и - в самом конце - создание исполняемой архитектуры.

Рис. 1. Типичный процесс проектирования на уровне системы для ЦП / ПЛИС
(Источник:Space Codesign Systems, Inc.)

Второй блок на рисунке 1 включает оптимизацию архитектуры (также известную как исследование архитектуры или проверка производительности). Более подробно это изображено на рисунке 2.

Рис. 2. Процесс оптимизации архитектуры
(Источник:Space Codesign Systems, Inc.)

В процессе оптимизации архитектуры используются следующие оценщики:

• Оценка оборудования оценивает показатели аппаратного разделения (т. е. кода C / C ++, перенесенного на FPGA). Его можно разбить по ресурсам, производительности (например, задержке цикла) и оценкам мощности. Оценка оборудования осуществляется с помощью инструментов HLS (High-Level Synthesis).
• Оценка программного обеспечения оценивает метрики для кода раздела C / C ++, запущенного на ЦП (т. е. на аппаратном и / или программном ЦП). Этот процесс является дополнительным к этапу оценки оборудования. Примерами показателей производительности являются загрузка процессора, переключение задач и промахи в кэше.
• Оценка передачи данных состоит из моделирования интерфейсов (т. е. отображаемых в памяти и потоковых интерфейсов), посредством которых аппаратное и программное обеспечение обмениваются данными. Примерами собранных показателей являются производительность шины (например, задержка и пропускная способность), очередь и использование памяти.

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

Последний блок на рисунке 1 относится к реализации архитектуры, в которой системные архитектуры преобразуются в поток битов (для реализации FPGA) с использованием инструментов реализации, таких как Xilinx Vivado или Intel Quartus Prime, для окончательного и полного создания системы, которая будет выполняться на конкретной физической платформе. Этот шаг должен давать качественный код и быть прозрачным для разработчика программного обеспечения.

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

Чтобы проиллюстрировать эти проблемы, на рисунке 3 показан типичный процесс оптимизации на уровне системы во время исследования архитектуры приложения обработки изображений, состоящего из шести функций (фрагментов кода C / C ++), которые должны быть реализованы на платформе Zynq-7000. Здесь мы перечисляем восемь потенциальных архитектур, которые могут быть реализованы на платформе. Поскольку время выхода на рынок не позволяет реализовать каждую архитектуру, необходимо быстро определить лучшую для реализации. Эта последовательность оптимизаций может оказаться сложной задачей даже для опытных разработчиков оборудования.

Рис. 3. Исследование архитектуры с решениями на уровне системы, показанными синим
(Источник:Space Codesign Systems, Inc.)

Инструменты разработки программного обеспечения FPGA, такие как SDSoC / SDAccel (Xilinx), Merlin Compiler (Falcon Computing Solutions) и SpaceStudio (Space Codesign Systems), являются коммерческими решениями, которые помогают разработчикам программного обеспечения в проектировании систем FPGA / CPU при достижении оптимизации на системном уровне. Эти инструменты используют схему, аналогичную описанной на рисунках 1 и 2, и тем самым демонстрируют существование нового поколения инструментов системного уровня с различными подходами.

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

Компилятор Merlin предлагает преобразование исходного кода. Целью преобразования источника в источник является уменьшение или устранение разрыва в абстракции дизайна между разработкой программного обеспечения / алгоритма и существующими потоками проектирования HLS. Компилятор Merlin полагается на четыре прагмы для вывода конкретных проектов FPGA. В дополнение к четырем основным оптимизациям, запускаемым явными прагмами, компилятор Merlin также содержит различные неявные оптимизации (т. Е. Проходы преобразования компилятора), которые выполняются вместе с прагмами, чтобы помочь улучшить результаты конвейера и распараллеливания.

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

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

Рис. 4. Коммерческая экосистема для платформ CPU / FPGA
(Источник:Space Codesign Systems, Inc.)

Кроме того, в таблице 1 перечислены некоторые из основных коммерческих инструментов, используемых при проектировании платформы ЦП / ПЛИС.

Таблица 1. Инструменты коммерческой автоматизации (* Примечание:список предлагается в этом обзоре)

Заключение
Конечная цель - демократизировать разработку платформ ЦП и ПЛИС для более широкого круга пользователей, таких как сообщество разработчиков программного обеспечения. Если посмотреть на аналогию с языками программирования, ИТ-индустрии потребовалось более 50 лет, чтобы языки программирования превратились в дружественные языки, такие как Python или, в последнее время, Swift. Аналогичный процесс эволюции происходит в индустрии программирования FPGA. Принятие инструментов HLS потребовало некоторого времени, чтобы получить одобрение разработчиков системы. Сегодня, с появлением решений системного уровня для разработчиков программного обеспечения, мы вступаем в новую фазу. Коммерческие инструменты, такие как SpaceStudio, SDSoC и Merlin Compiler, свидетельствуют об этом процессе принятия. Тем не менее, еще предстоит проделать большую работу, чтобы получить полностью автоматизированный и оптимизированный процесс для компиляторов, ориентированных на платформы ЦП и ПЛИС.

Ги Буа, инж., доктор философии является основателем Space Codesign Systems и профессором кафедры программного обеспечения и компьютерной инженерии Политехнического института Монреаля. Гай участвовал во многих проектах НИОКР в сотрудничестве с такими лидерами отрасли, как STMicroelectronics, Grass Valley, PMC Sierra, Design Workshops Technologies и Cadabra Systems. Опыт Гая в области разработки программного и аппаратного обеспечения привел к коммерциализации решения и созданию SpaceStudio от Space Codesign Systems Inc.