Программируемые пользователем вентильные матрицы, или FPGA, стали повсеместными в высокоскоростных, работающих в реальном времени цифровых системах. Их можно использовать для критически важных приложений, цифровой обработки сигналов или даже майнинга криптовалют. Высокая скорость и энергоэффективность делают их идеальными для многократного использования в высокоскоростных приложениях. Скорость работы FPGA продолжает расти ошеломляющими темпами, но их интеграция в конвейеры непрерывной интеграции (CI) пока не столь распространена. В этой статье мы рассмотрим концепцию CI-конвейеров, их применение к FPGA, а также примеры настройки CI-конвейеров для FPGA.
Если вы еще не заметили, я буквально «ем, сплю и дышу» непрерывной интеграцией. Будь то CI для разработки печатных плат или CI для встраиваемых систем, я всегда ищу способы улучшить и автоматизировать сборку для любого типа системы. Недавняя обратная связь от пользователей показала, что в отношении FPGA и CI пока не сделано значительных шагов. Основная идея CI и FPGA такая же, как и у других CI-систем: создать воспроизводимую среду сборки, которая выполняет всю сложную работу за нас. CI-система для FPGA обычно состоит из трех этапов:
Рисунок 1: Этапы CI-конвейера для FPGA
Каждый этап важен сам по себе и требует своей настройки. Давайте рассмотрим каждый этап, чтобы понять, что он собой представляет и как его реализовать.
Симуляция является неотъемлемой частью разработки FPGA. Создание образа FPGA для загрузки на целевое устройство может занять много времени. Вместо того чтобы писать код, собирать его и тестировать на оборудовании, симуляция позволяет быстро протестировать наш код или уровень передачи регистров (RTL) в среде, которая симулирует поведение FPGA. Обычно это делается на уровне пользователя, но становится все более популярным интегрировать симуляцию FPGA в CI-конвейеры. Это означает, что кто-то отправляет свой код в репозиторий, и конвейер запускает (самопроверяющую) симуляцию в облаке. Чтобы действительно выполнить это «где-то в облаке», необходимо создать самодостаточную среду, которая может быть инкапсулирована или контейнеризирована. Для этого мы используем контейнеры Docker, которые работают почти как виртуальные машины. Этот Docker-контейнер, например, создает контейнеризированную среду, которая позволяет пользователю запускать Icarus Verilog в любой Linux-системе. Мы затем используем этот контейнер для создания конвейера симуляции FPGA. В этом примере показан простой конвейер «Hello World», выполняемый в облаке с использованием Icarus Verilog. Обратите внимание, что это можно сделать с любым инструментом симуляции FPGA.
Рисунок 2: Запуск конвейера симуляции FPGA с использованием Gitlab CI
Второй, также очень важный этап в конвейере FPGA — это этап сборки. Мы хотим иметь возможность синтезировать, размещать и маршрутизировать, а также генерировать битстрим для нашего FPGA-дизайна. Обычно это делается пользователями с помощью инструмента, предоставленного поставщиком (например, Xilinx, Intel, Microchip и т.д.). Вместо локальной сборки мы бы предпочли выполнять её где-то ещё. Это может быть непросто, поскольку инструменты FPGA обычно имеют очень большой размер. Один из подходов, который используют многие, — это наличие выделенной «сборочной машины», которая выполняет все конвейеры сборки. Такой подход неплох, но он не масштабируется и может стать единой точкой отказа. Другие пытались контейнеризировать инструменты FPGA, но размер таких образов может превышать 100 ГБ, что делает их практически непригодными для облачных приложений. Удачным решением является метод сетевой установки. В качестве примера я создал контейнер, который запускает Vivado 2019.1, но сам инструмент не установлен в образе (поэтому его размер меньше 300 МБ). Я установил Vivado на сетевой диск (в данном случае EFS в AWS) и затем подключил его к контейнеру Docker. Поскольку я запускаю свой конвейер в AWS, задержка между EFS и EC2 (узлом Kubernetes) минимальна.
В этом примере я использую устройство Arty A7 от Digilent для создания цифрового фильтра. Я использую автоматизированный скрипт сборки, чтобы генерировать битстрим-файл для устройства при каждом коммите в репозиторий. Как видно в выводе, мне удается вызвать Vivado, хотя он не установлен в Docker-контейнере (т.е. подключен как внешний диск).
Рисунок 3: Запуск конвейера сборки FPGA с использованием Gitlab CI
Этап тестирования сильно зависит от проекта и индивидуальных требований. Цель тестирования в CI-конвейере — автоматизировать процесс насколько это возможно. Так же, как я автоматизировал пример DSP для Arduino с помощью Analog Discovery 2, я мог бы сделать то же самое здесь. Охватить решение для автоматизированного тестирования FPGA было бы немного за рамками этой статьи. Основной принцип заключается в обеспечении повторяемости и возможности выполнения в инкапсулированной или контейнеризированной среде. Важно помнить, что тестирование — это важная часть CI-конвейера и должно быть реализовано на доступном уровне.
В этой статье мы рассмотрели концепцию CI-конвейеров для FPGA. Мы изучили три критических этапа, составляющие FPGA-конвейеры: симуляцию, сборку и тестирование. Мы рассмотрели примеры конвейеров симуляции и сборки и обсудили важность тестирования. После прочтения этой статьи и ознакомления с примерами пользователь должен понимать основные принципы создания CI-конвейера для FPGA.
Когда вы будете готовы создать собственную FPGA-плату для поддержки встроенной системы, используйте полный набор функций проектирования и трассировки печатных плат в Altium Designer®. После завершения работы с платой и готовности к обмену проектом с коллегами или производителем, вы можете поделиться своими проектами через платформу Altium 365™. Всё, что вам нужно для проектирования и производства передовой электроники, собрано в одном программном пакете.
Мы только коснулись того, что можно сделать с Altium Designer на Altium 365. Начните бесплатную пробную версию Altium Designer + Altium 365 сегодня.