Использование FPGA в рабочем процессе гибкой разработки
OVHcloud недавно получил новое имя, чтобы подчеркнуть его направленность: облако, чтобы дать вам возможность легко выполнять свои рабочие нагрузки, не слишком заботясь о базовом оборудовании. Так зачем говорить о ПЛИС?
FPGA — это аппаратный ускоритель, реконфигурируемая микросхема, которая может вести себя как обычный кремний, разработанная для конкретного применения. Мы используем FPGA в качестве пользовательских сетевых устройств для нашей системы защиты от атак. Но разработка FPGA сильно отличается от разработки программного обеспечения: она требует специализированного проприетарного программного обеспечения и длительных циклов разработки.
В этой статье я хотел бы сосредоточиться на том, как мы интегрируем разработку FPGA в рабочий процесс гибкой разработки программного обеспечения, используемый всеми другими разработчиками в OVHcloud.
Зачем использовать?
ПЛИС являются чрезвычайно общими микросхемами, их можно использовать для построения схем для очень широкого спектра применений:
Для сетевых приложений преимуществами являются:
Чтобы узнать больше о FPGA, электронные книги FPGA For Dummies — это хороший ресурс.
Традиционный рабочий процесс разработки FPGA
Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков, все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на микросхеме. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:
Модули можно объединять, соединяя их входы и выходы для создания сложных систем.
Тестирование на симуляторе
Очень важным инструментом при разработке на ПЛИС является симулятор: он сложный и медленный для тестирования кода непосредственно на реальной ПЛИС. Чтобы ускорить процесс, симуляторы могут запускать код без специального оборудования. Они используются как для модульных тестов, для тестирования каждого модуля в отдельности, так и для функциональных тестов, имитирующих всю конструкцию, контролирующих его входы и проверяющих его выходы. Вот результат на счетчик модуля:
Симулятор модуля счетчика
Это волна, показывающая значение каждого сигнала в каждом тактовом цикле. Конечно, симулятор также может работать без головы, а тестовая среда может быть модифицирована для возврата результата «пройдено / не пройдено».
Базовый симулятор предоставлен Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти симуляторы являются коммерческими и требуют дорогих лицензий.
Сборка двоичного файла
После того, как все тесты пройдены, пришло время получить двоичный файл, который можно использовать для настройки FPGA. Крупнейшие поставщики FPGA, Intel и Xilinx, предоставляют собственные инструменты для этого процесса. Первый этап, синтез, преобразует исходный код в схему. Второй этап, «место и маршрут», представляет собой очень сложную задачу оптимизации, позволяющую приспособить схему к ресурсам, предоставляемым ПЛИС, при соблюдении временных ограничений, чтобы схема могла работать на требуемой частоте. Это может длиться несколько часов, даже до одного дня на очень сложных конструкциях. Этот процесс может завершиться ошибкой, если дизайн слишком ограничен, поэтому обычно приходится запускать несколько процессов с разными начальными значениями, чтобы в конце было больше шансов получить рабочий двоичный файл.
Наш текущий рабочий процесс разработки FPGA
Наш текущий процесс разработки очень близок к традиционному. Но обычно разработка FPGA намного медленнее, чем разработка программного обеспечения. В OVHcloud мы можем разработать и отправить небольшую функцию за один день. Мы достигаем этого, используя рабочий процесс, используемый разработчиками программного обеспечения, и используя нашу облачную инфраструктуру. Вот глобальный рабочий процесс:
Весь рабочий процесс контролируется CDS, нашей системой непрерывной доставки с открытым исходным кодом. Все тесты, а также задания по компиляции выполняются в Public Cloud, кроме тестов на борту, которые проводятся в нашей лаборатории.
Используя наше публичное облако
Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:
Сервер лицензий для симулятора и компиляторов
Сервер лицензий, а также блоки разработки — это долго работающие экземпляры Public Cloud. Сервер лицензий — это наименьший возможный экземпляр, блок разработки — это экземпляр с быстрым ЦП и большим объемом оперативной памяти. Симулятор и компиляторы установлены на блоке разработки. Полномочия на доступ к серверу лицензий управляются с помощью групп безопасности OpenStack.
Экземпляры, используемые для смоделированных тестов и для компиляции, запускаются с использованием API OpenStack, когда это необходимо. Это очень важно, потому что позволяет параллельно запускать несколько наборов тестов для разных разработчиков. Это также очень важно для компиляции. Мы компилируем наши проекты для нескольких целей (FPGA Stratix V для 10G и FPGA Ultrascale + для 100G), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы выполняем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку в наших проектах задания на сборку могут длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один работающий двоичный файл.
Запуск тестов
Функциональные тесты очень важны, потому что они проверяют каждую функцию, которую предоставляют наши разработки. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать с имитацией дизайна или с реальным дизайном на реальных платах ПЛИС. CDS может автоматически запускать тесты на реальных платах, бронируя лабораторные серверы и подключаясь к ним через SSH. Тот же процесс используется для тестирования производительности.
Результатом этой инфраструктуры является то, что разработчики могут добавить новую функцию в ветку нашего репозитория git, и они получат полные результаты модульных и функциональных тестов через 30 минут. Если все в порядке, они могут запустить компиляцию и проверить результат на борту на следующий день. Тогда им просто нужно пометить новую версию пакета, чтобы иметь доступ к новой версии. После этого команда, управляющая производством, может развернуть новую версию с помощью ansible.
Идти дальше
Мы максимально автоматизировали наш процесс и используем инфраструктуру публичного облака для ускорения рабочего процесса. Но в настоящее время мы все еще используем довольно традиционный процесс разработки FPGA. Существует множество различных подходов, и мы хотим продвинуть процесс разработки ПЛИС настолько близко к разработке программного обеспечения, насколько это возможно, мы рассмотрели многие из них.
HLS
Очень распространенным подходом является использование синтеза высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS возможно развитие на C ++. Также можно использовать OpenCL, который мы тестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы делаем обработку пакетов, наши алгоритмы чрезвычайно просты. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Поэтому мы не смогли эффективно использовать HLS, полученный нами код был на самом деле более сложным, чем та же функция в SystemVerilog.
SystemVerilog чрезвычайно низкоуровневый и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код использовался компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, в настоящее время работающий над проектом с открытым исходным кодом: Chisel.
Chisel — это язык аппаратного дизайна, основанный на Scala. Его основной интерес заключается в том, что он позволяет использовать весь уровень абстракции, предлагаемый Scala, для описания аппаратного обеспечения. Это также полностью открытый исходный код, что весьма необычно в мире разработки аппаратного обеспечения. Для тестирования он использует Verilator, симулятор с открытым исходным кодом. Это означает, что мы могли бы избавиться от проприетарных симуляторов и иметь полностью открытый набор инструментов, вплоть до компиляции.
В настоящее время не существует инструментов с открытым исходным кодом для этапа и маршрута, по крайней мере, для самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.
Мы планируем, чтобы наши первые модули, разработанные в долоте, использовались в производстве в ближайшее время. Это должно помочь нам иметь более многократно используемый код и легче писать код, а также постепенно избавляться от проприетарных инструментов.
Смена парадигмы
Сообщество открытого исходного кода чрезвычайно важно, чтобы продолжать делать разработку ПЛИС все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление бюджетных ПЛИС в проектах FabLabs и хобби-электроники. Мы надеемся, что Xilinx и Intel FPGA последуют этому примеру и что они однажды будут использовать открытые исходные коды для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут стать мощной альтернативой процессорам и графическим процессорам, но чтобы демократизировать их использование в облачных средах, сообщество открытого исходного кода должно стать намного сильнее.
FPGA — это аппаратный ускоритель, реконфигурируемая микросхема, которая может вести себя как обычный кремний, разработанная для конкретного применения. Мы используем FPGA в качестве пользовательских сетевых устройств для нашей системы защиты от атак. Но разработка FPGA сильно отличается от разработки программного обеспечения: она требует специализированного проприетарного программного обеспечения и длительных циклов разработки.
В этой статье я хотел бы сосредоточиться на том, как мы интегрируем разработку FPGA в рабочий процесс гибкой разработки программного обеспечения, используемый всеми другими разработчиками в OVHcloud.
Зачем использовать?
ПЛИС являются чрезвычайно общими микросхемами, их можно использовать для построения схем для очень широкого спектра применений:
- обработка сигналов
- финансы
- машинное обучение (классификация)
- сетей
Для сетевых приложений преимуществами являются:
- прямое подключение к каналам 100GbE: нет сетевой карты, нет канала PCIe, пакеты принимаются непосредственно на чипе
- доступ к памяти с чрезвычайно низкой задержкой и очень быстрым произвольным доступом (QDR SRAM: каждый банк обеспечивает около 250 миллионов операций чтения и записи в секунду)
- возможность строить собственные конвейеры обработки пакетов, максимально использовать ресурсы чипа.
Чтобы узнать больше о FPGA, электронные книги FPGA For Dummies — это хороший ресурс.
Традиционный рабочий процесс разработки FPGA
Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков, все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на микросхеме. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:
// Simple example module: a counter
// Will clear if clear is 1 during one clock cycle.
// Will increment at each clock cycle when enable is 1.
`timescale 1ns / 1ps
module counter
#(
// Number of bits of counter result
parameter WIDTH = 5
)
(
input clk,
// Control
input enable,
input clear,
// Result
output reg [WIDTH-1:0] count = '0
);
always_ff @(posedge clk) begin
if (clear) begin
count <= '0;
end else if (enable) begin
count <= count + 1;
end
end
endmoduleМодули можно объединять, соединяя их входы и выходы для создания сложных систем.
Тестирование на симуляторе
Очень важным инструментом при разработке на ПЛИС является симулятор: он сложный и медленный для тестирования кода непосредственно на реальной ПЛИС. Чтобы ускорить процесс, симуляторы могут запускать код без специального оборудования. Они используются как для модульных тестов, для тестирования каждого модуля в отдельности, так и для функциональных тестов, имитирующих всю конструкцию, контролирующих его входы и проверяющих его выходы. Вот результат на счетчик модуля:
Симулятор модуля счетчика
Это волна, показывающая значение каждого сигнала в каждом тактовом цикле. Конечно, симулятор также может работать без головы, а тестовая среда может быть модифицирована для возврата результата «пройдено / не пройдено».
Базовый симулятор предоставлен Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти симуляторы являются коммерческими и требуют дорогих лицензий.
Сборка двоичного файла
После того, как все тесты пройдены, пришло время получить двоичный файл, который можно использовать для настройки FPGA. Крупнейшие поставщики FPGA, Intel и Xilinx, предоставляют собственные инструменты для этого процесса. Первый этап, синтез, преобразует исходный код в схему. Второй этап, «место и маршрут», представляет собой очень сложную задачу оптимизации, позволяющую приспособить схему к ресурсам, предоставляемым ПЛИС, при соблюдении временных ограничений, чтобы схема могла работать на требуемой частоте. Это может длиться несколько часов, даже до одного дня на очень сложных конструкциях. Этот процесс может завершиться ошибкой, если дизайн слишком ограничен, поэтому обычно приходится запускать несколько процессов с разными начальными значениями, чтобы в конце было больше шансов получить рабочий двоичный файл.
Наш текущий рабочий процесс разработки FPGA
Наш текущий процесс разработки очень близок к традиционному. Но обычно разработка FPGA намного медленнее, чем разработка программного обеспечения. В OVHcloud мы можем разработать и отправить небольшую функцию за один день. Мы достигаем этого, используя рабочий процесс, используемый разработчиками программного обеспечения, и используя нашу облачную инфраструктуру. Вот глобальный рабочий процесс:
Весь рабочий процесс контролируется CDS, нашей системой непрерывной доставки с открытым исходным кодом. Все тесты, а также задания по компиляции выполняются в Public Cloud, кроме тестов на борту, которые проводятся в нашей лаборатории.
Используя наше публичное облако
Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:
- симулятор
- компилятор Xilinx, Vivado
- компилятор Intel Quartus
Сервер лицензий для симулятора и компиляторов
Сервер лицензий, а также блоки разработки — это долго работающие экземпляры Public Cloud. Сервер лицензий — это наименьший возможный экземпляр, блок разработки — это экземпляр с быстрым ЦП и большим объемом оперативной памяти. Симулятор и компиляторы установлены на блоке разработки. Полномочия на доступ к серверу лицензий управляются с помощью групп безопасности OpenStack.
Экземпляры, используемые для смоделированных тестов и для компиляции, запускаются с использованием API OpenStack, когда это необходимо. Это очень важно, потому что позволяет параллельно запускать несколько наборов тестов для разных разработчиков. Это также очень важно для компиляции. Мы компилируем наши проекты для нескольких целей (FPGA Stratix V для 10G и FPGA Ultrascale + для 100G), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы выполняем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку в наших проектах задания на сборку могут длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один работающий двоичный файл.
Запуск тестов
Функциональные тесты очень важны, потому что они проверяют каждую функцию, которую предоставляют наши разработки. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать с имитацией дизайна или с реальным дизайном на реальных платах ПЛИС. CDS может автоматически запускать тесты на реальных платах, бронируя лабораторные серверы и подключаясь к ним через SSH. Тот же процесс используется для тестирования производительности.
Результатом этой инфраструктуры является то, что разработчики могут добавить новую функцию в ветку нашего репозитория git, и они получат полные результаты модульных и функциональных тестов через 30 минут. Если все в порядке, они могут запустить компиляцию и проверить результат на борту на следующий день. Тогда им просто нужно пометить новую версию пакета, чтобы иметь доступ к новой версии. После этого команда, управляющая производством, может развернуть новую версию с помощью ansible.
Идти дальше
Мы максимально автоматизировали наш процесс и используем инфраструктуру публичного облака для ускорения рабочего процесса. Но в настоящее время мы все еще используем довольно традиционный процесс разработки FPGA. Существует множество различных подходов, и мы хотим продвинуть процесс разработки ПЛИС настолько близко к разработке программного обеспечения, насколько это возможно, мы рассмотрели многие из них.
HLS
Очень распространенным подходом является использование синтеза высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS возможно развитие на C ++. Также можно использовать OpenCL, который мы тестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы делаем обработку пакетов, наши алгоритмы чрезвычайно просты. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Поэтому мы не смогли эффективно использовать HLS, полученный нами код был на самом деле более сложным, чем та же функция в SystemVerilog.
SystemVerilog чрезвычайно низкоуровневый и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код использовался компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, в настоящее время работающий над проектом с открытым исходным кодом: Chisel.
Chisel — это язык аппаратного дизайна, основанный на Scala. Его основной интерес заключается в том, что он позволяет использовать весь уровень абстракции, предлагаемый Scala, для описания аппаратного обеспечения. Это также полностью открытый исходный код, что весьма необычно в мире разработки аппаратного обеспечения. Для тестирования он использует Verilator, симулятор с открытым исходным кодом. Это означает, что мы могли бы избавиться от проприетарных симуляторов и иметь полностью открытый набор инструментов, вплоть до компиляции.
В настоящее время не существует инструментов с открытым исходным кодом для этапа и маршрута, по крайней мере, для самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.
Мы планируем, чтобы наши первые модули, разработанные в долоте, использовались в производстве в ближайшее время. Это должно помочь нам иметь более многократно используемый код и легче писать код, а также постепенно избавляться от проприетарных инструментов.
Смена парадигмы
Сообщество открытого исходного кода чрезвычайно важно, чтобы продолжать делать разработку ПЛИС все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление бюджетных ПЛИС в проектах FabLabs и хобби-электроники. Мы надеемся, что Xilinx и Intel FPGA последуют этому примеру и что они однажды будут использовать открытые исходные коды для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут стать мощной альтернативой процессорам и графическим процессорам, но чтобы демократизировать их использование в облачных средах, сообщество открытого исходного кода должно стать намного сильнее.
0 комментариев
Вставка изображения
Оставить комментарий