Изучение совместимости программного обеспечения с открытым исходным кодом с инструментами разработки Dsp процессоров

Растущая роль открытого исходного кода в развитии DSP

Цифровые сигнальные процессоры (DSP) питают бесчисленные современные системы — от аудиокодеков и радиолокационных приемников до базовых станций 5G и биомедицинских устройств. Их специализированные архитектуры требуют одинаково специализированных инструментов разработки: компиляторы, которые оптимизируют для трубопроводов Multiply-Accumulate (MAC), отладчики, которые обрабатывают ограничения в реальном времени, и симуляторы, которые моделируют точное поведение оборудования. В течение многих лет в этом пространстве доминировали проприетарные наборы инструментов от таких поставщиков, как Texas Instruments, Analog Devices и NXP. Сегодня альтернативы с открытым исходным кодом набирают серьезную тягу, предлагая гибкость, прозрачность и экономию затрат, которые могут трансформировать то, как инженеры выводят продукты на основе DSP на рынок.

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

Понимание архитектуры процессоров DSP и их потребностей в интегральной цепочке

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

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

Ключевые инструменты с открытым исходным кодом для разработки DSP

Компиляторы: GCC и LLVM

GNU Compiler Collection (GCC) остается наиболее широко используемым компилятором с открытым исходным кодом. Его бэкэнды поддерживают многие архитектуры DSP, включая Analog Devices Blackfin, CEVA-X и CEVA-TeakLite, а также некоторые конфигурации Tensilica. Более поздние вклады добавили поддержку Andes NDS32 и Cadence Vision DSP. Для многих разработчиков GCC предоставляет бесплатный, стабильный и проверяемый генератор кода, который может быть кросс-компилирован для встроенных целей.

Проект LLVM с его модульным дизайном и разрешительной лицензией стал привлекательной альтернативой. В то время как DSP-бэкенды LLVM менее многочисленны, чем GCC, его инфраструктура для пользовательских описаний целей облегчает добавление поддержки новых архитектур. Руководство по написанию бэкэнда LLVM является ценным ресурсом для разработчиков, которым необходимо создать свою собственную цель DSP. Кроме того, Clang (фронтенд LLVM C / C++) часто предоставляет лучшие сообщения об ошибках и диагностические возможности, чем GCC, что может ускорить разработку.

Отладчики: GDB и OpenOCD

GNU Debugger (GDB) является фактическим стандартом для отладки встроенных систем. При сопряжении с аппаратным отладчиком (например, JTAG-адаптером) и сервером отладки, таким как OpenOCD, GDB может выполнять низкоуровневые операции на DSP: устанавливать точки останова, проверять регистры, просматривать память на чипе и проходить через код сборки. OpenOCD поддерживает растущий список ядер DSP, в том числе из семейств Tensilica, CEVA и более старых ADI. Однако разработчикам часто приходится писать сценарии конфигурации цели для обработки причуд, таких как общие ресурсы точки останова или конкретные последовательности управления запуском.

Для отладки в реальном времени многие запатентованные инструментальные цепи предлагают маркерные буферы и расширенные триггеры, которые еще не доступны в решениях с открытым исходным кодом. Тем не менее, возможность сценариев GDB (с использованием Python или Tcl) позволяет создавать сложные стратегии шага, которые имитируют поведение в реальном времени во многих практических сценариях.

Симуляторы и эмуляторы: QEMU и варианты, ориентированные на архитектуру

Доступность оборудования может быть самым большим узким местом на ранней стадии разработки DSP. Симуляторы с открытым исходным кодом обеспечивают способ тестирования алгоритмов до прибытия кремниевых или оценочных плат. QEMU, в первую очередь известный эмуляцией ARM и x86, также поддерживает несколько машин, ориентированных на DSP, таких как ARM MPS2 FPGA-ориентированная плата разработки , которые могут размещать пользовательские периферийные устройства DSP. Для более специализированной работы эмуляторы, специфичные для архитектуры, такие как протокол моделирования Tensilica Xtensa (XTMP), доступны в форме с открытым исходным кодом через портал разработчика Tensilica. Эти симуляторы могут достигать точных по циклу результатов и необходимы для точной настройки мощности и производительности.

Построение систем и библиотек

Современная разработка DSP выигрывает от систем сборки с открытым исходным кодом, таких как CMake и GNU Make, которые легко интегрируются с наборами инструментов кросс-компиляции. На фронте библиотеки библиотека CMSIS-DSP предлагает оптимизированные функции DSP для ядер Arm Cortex-M, которые включают расширения DSP. Хотя это не общая библиотека DSP, она демонстрирует, как инициативы с открытым исходным кодом могут обеспечить строительные блоки производственного качества. Для более традиционных DSP с фиксированной точкой библиотека KFR обеспечивает быстрые преобразования Фурье и реализации фильтров, которые могут быть адаптированы к пользовательским целям.

Проблемы совместимости и как их преодолевают разработчики

Архитектурно-специфическая инструкция Набор расширений

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

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

Ограничения и ограничения в реальном времени

Собственные отладчики часто предоставляют аппаратные контрольные точки, трассировку инструкций и счетчики производительности, к которым GDB не может полностью получить доступ без плагинов, специфичных для поставщиков. Обход включает использование встроенного DSP-регистрации с прерыванием (например, отправку данных о производительности по UART) или реализацию программных крючков профилирования. Для критически важных для времени циклов управления разработчики могут использовать осциллограф или логический анализатор в сочетании с переключателями GPIO - метод, не элегантный, но надежный и дружественный к открытому исходному коду.

Интеграция и удобство использования Toolchain

Собственные IDE (например, Code Composer Studio от TI или CrossCore от ADI) предлагают бесшовный опыт: нажмите кнопку для создания, загрузки и отладки. Настройки с открытым исходным кодом требуют ручной настройки Makefiles, скриптов линкеров и настроек сервера отладки. Однако появление кода VS с расширениями встроенной разработки и Eclipse для встроенной позволило преодолеть этот разрыв. Многие команды теперь создают общий контейнер Docker, который объединяет кросс-компилятор GCC, OpenOCD и GDB, позволяя каждому разработчику воспроизводить одну и ту же среду сборки.

Реальные истории успеха и тематические исследования

Обработка аудио на Tensilica HiFi Cores

Сообщество с открытым исходным кодом вокруг TENSIlica HiFi DSPs от Cadence (используется во многих смартфонах и интеллектуальных динамиках) создало бэкэнд GCC, который активно поддерживается. Несколько поставщиков аудио-промежуточного программного обеспечения распространяют свои кодеки, скомпилированные с GCC, демонстрируя, что инструменты с открытым исходным кодом могут обеспечить плотность кода и производительность, необходимую для устройств с батарейным питанием. Разработчики сообщают, что, хотя запатентованная IDE Xtensa Xplorer предлагает лучшую начальную оптимизацию, код, генерируемый GCC, можно настроить путем настройки флагов планирования инструкций и с помощью ручного развертывания цикла в ключевых ядрах.

Управление двигателем с помощью аналоговых устройств Blackfin

Процессор Blackfin от Analog Devices, хотя теперь и является унаследованной архитектурой, остается популярным выбором для управления двигателем и промышленной автоматизации. Бэкэнд Blackfin GCC является одним из самых зрелых компиляторов DSP с открытым исходным кодом, и к нему были портированы многие библиотеки управления двигателем с открытым исходным кодом (например, OpenLoop, SimpleFOC). Примечательным примером является контроллер 3D-принтера MKS BEETLE , который использует процессор ADSP на основе Blackfin и запускает прошивку, полностью построенную с GCC и GDB. Это показывает, что инструменты с открытым исходным кодом могут обрабатывать большинство реальных задач DSP, даже в продуктах, которые поставляются в больших объемах.

Программно-определяемое радио с QEMU и GNU Radio

Программно-определяемые радиоприложения (SDR) часто нацелены на гибриды FPGA-plus-DSP или многоядерные DSP. Проект GNU Radio, хотя в основном это фреймворк для хост-ПК, вдохновил потоки разработки, основанные на эмуляции. Команды используют QEMU для моделирования своей системы DSP (например, Zynq FPGA с Cortex-A9 и пользовательским сопроцессором DSP) и тестируют алгоритмы перед скотчем. Хотя скорость моделирования не является реальным временем, он позволяет раннюю валидацию поведения трубопровода и разночтений в памяти. Этот подход позволил сэкономить месяцы времени отладки в недавней работе по прототипированию базовой полосы 5G.

Будущий прогноз: преодоление разрыва между открытым исходным кодом и собственными экосистемами

RISC-V как катализатор

Рост RISC-V — архитектуры с открытым набором команд — возможно, является самой сильной силой, стимулирующей совместимость инструментов DSP с открытым исходным кодом. Многие ядра RISC-V теперь включают в себя расширения, ориентированные на DSP (P-Extension, V-Extension для векторной обработки и пользовательские слоты для инструкций SIMD). Поскольку ISA открыта, у таких инструментальных цепочек, как GCC и LLVM, с самого начала есть первоклассная поддержка. Дизайнеру DSP, использующему RISC-V, больше не нужно создавать компилятор с нуля; они просто определяют свои пользовательские инструкции и публикуют соответствующий LLVM-бэкэнд. Это резко снижает барьер для принятия инструментов с открытым исходным кодом в новых проектах DSP. Мы ожидаем, что DSP на основе RISC-V станут доминирующей платформой для разработки с открытым исходным кодом в течение пяти лет.

Аппаратные абстракционные слои (HAL) и PlatformIO

Поставленные поставщиками HAL становятся все более доступными по лицензиям с открытым исходным кодом (например, Apache 2.0, MIT). В сочетании с таким инструментом сборки, как PlatformIO, который автоматизирует загрузку цепочек инструментов, управление библиотеками и поддержку плат, сложность настройки среды DSP с открытым исходным кодом значительно снижается. Несколько плат оценки DSP (от таких компаний, как Gowin и Anlogic) теперь поставляются с поддержкой PlatformIO. Эта тенденция будет продолжаться, поскольку все больше поставщиков понимают, что сильная экосистема с открытым исходным кодом увеличивает их продажи кремния.

Машинное обучение на DSP и роль открытого исходного кода

Современным DSP часто задают задачи по запуску легких нейронных сетей для обнаружения ключевых слов, распознавания жестов или обнаружения аномалий. Движение TinyML в значительной степени зависит от инструментов с открытым исходным кодом: компиляторы TensorFlow Lite для микроконтроллеров, Edge Impulse и LLVM, которые отображают графики ML на единицы SIMD DSP. Поскольку модели ML быстро развиваются, гибкость инструментальных цепочек с открытым исходным кодом позволяет исследователям экспериментировать с пользовательскими схемами квантования и оптимизацией оператора, не дожидаясь следующего обновления поставщика.

Практические рекомендации для разработчиков

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

  1. Аудит поддержки цепочки инструментов для вашей целевой архитектуры — Проверьте деревья источников GCC и LLVM для бэкэнда. Поиск списков рассылки и репозиториев (например, GitHub, SourceForge) для патчей или вилок, которые добавляют поддержку.
  2. Оцените варианты моделирования — Если для вашего чипа не существует симулятора с точным циклом, рассмотрите возможность использования QEMU для функциональной проверки и симулятора набора инструкций, поставляемого поставщиком (часто бесплатно для разработки) для анализа времени.
  3. Использовать внутренние заголовки поставщика, когда это возможно — Многие производители DSP распространяют файлы заголовков, которые объявляют внутренние для специальных инструкций. Эти заголовки часто работают как с GCC, так и с Clang. Избегайте записи встроенной сборки, если это абсолютно не необходимо; внутренние элементы более портативны и менее подвержены ошибкам.
  4. Преемственная интеграция с использованием рычагов (CI) — Настройка конвейера CI, который строится с помощью GCC и запускает ваши тестовые векторы в симуляции. Это улавливает регрессии на ранней стадии и намного дешевле, чем полагаться исключительно на циклы подведения оборудования.
  5. Взаимодействие с сообществом — Инструментарий DSP с открытым исходным кодом часто улучшается пользователями, которые вносят тестовые случаи, отчеты об ошибках и исправления. Если вашей цели не хватает функции, рассмотрите возможность найма консультанта или партнерства с университетом для расширения цепочки инструментов.

Заключение

Программное обеспечение с открытым исходным кодом перешло от пограничного эксперимента в разработке DSP к практическому, все более мощному выбору для реальных проектов. В то время как запатентованные инструментальные цепи будут продолжать предлагать превосходную оптимизацию и немедленную аппаратную поддержку нишевых архитектур, разрыв сокращается. GCC и LLVM теперь охватывают большинство основных ядер DSP, GDB и OpenOCD обеспечивают способную отладку, а симуляторы с открытым исходным кодом позволяют раннюю проверку алгоритмов. Инерция, стоящая за RISC-V и TinyML, только ускорит эти тенденции.

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