Часть 4. Быстрое прототипирование с использованием Zynq SDR и генерации кода Simulink
Introduction
В предыдущих частях этой серии статей мы рассказали о платформе быстрого прототипирования Zynq SDR1, представили этапы использования MATLAB и Simulink для разработки алгоритма, который может успешно обрабатывать и декодировать передачи ADS-B2, а также показали, как проверить алгоритм как в симуляторе, так и с помощью реальных данных, полученных с платформы SDR3. Конечная цель всех этапов — создать проверенную модель, которую можно преобразовать в код на языках C и HDL и интегрировать в программно-аппаратную инфраструктуру платформы SDR.
Модель Simulink, о которой шла речь во второй части серии статей («Обнаружение и декодирование Mode S с помощью MATLAB и Simulink»)2, представляет собой имитационную модель, достаточно точно воспроизводящую аппаратное обеспечение, чтобы убедиться, что система успешно декодирует сообщения ADS-B. В этой статье мы рассмотрим последние шаги, необходимые для создания работающего приёмника на платформе быстрого прототипирования Zynq SDR. Как и в предыдущих статьях этой серии, для разработки этого рабочего проекта необходимы следующие навыки: владение MATLAB и Simulink, знание радиооборудования Zynq, а также навыки интеграции программного и аппаратного обеспечения.
В этой статье описаны следующие шаги:
Разделите модель Simulink на функции, которые будут ориентированы на архитектуру FPGA и систему обработки ARM® на базе Zynq SoC.
Внесите изменения в модель Simulink, чтобы повысить производительность сгенерированного HDL-кода.
Сгенерируйте исходный HDL- и C-код для алгоритма приёмника ADS-B.
Интегрируйте сгенерированный исходный код в проект радиоплатформы Zynq.
Протестируйте встроенную конструкцию на целевом оборудовании с использованием реальных сигналов от самолёта.
По завершении этого процесса будет создана полностью протестированная система SDR, работающая на основе кода C и HDL, автоматически сгенерированного на основе модели ADS-B в Simulink, и способная принимать и декодировать сигналы коммерческих самолётов в режиме реального времени.
Разделение модели на аппаратные и программные компоненты
Первым шагом в процессе создания кода является разделение проекта на функциональные блоки, которые будут работать на программируемой логике и процессоре ARM в системе на кристалле Zynq.
Разделение обычно начинается с определения требований к обработке различных компонентов проекта, а также требуемой скорости и времени выполнения. Компоненты (например, алгоритмы модуляции/демодуляции данных), которые требуют больших вычислительных мощностей и должны работать в режиме реального времени с частотой дискретизации, лучше всего реализовывать на программируемой логике. Менее ресурсоёмкие задачи (например, декодирование и рендеринг данных, а также мониторинг и диагностика системы) лучше решать с помощью программного обеспечения. Также следует учитывать типы данных, сложность операций и точность входных и выходных данных. Все операции, выполняемые с помощью программируемой логики, работают с типами данных с фиксированной запятой, целыми числами или булевыми значениями. В случае более сложных операций, таких как тригонометрические функции или извлечение квадратного корня, для их эффективной реализации с использованием доступных аппаратных ресурсов применяются аппроксимации. Все эти ограничения приводят к потере точности, что может негативно сказаться на функциональности системы, если не уделить этому должного внимания. Однако компоненты, ориентированные на систему обработки данных, могут работать с числами с плавающей запятой и выполнять операции любой сложности с высочайшей точностью, но, как правило, благодаря снижению скорости выполнения.
Если исходить из этих ограничений, то разделение алгоритма декодирования ADS-B на части становится довольно очевидным. Функционал блока Detector в модели ModeS_Simulink_Decode.slx, который включает в себя предварительную обработку I/Q-семплов вплоть до вычисления контрольной суммы, хорошо подходит для реализации на программируемой логике системы на кристалле Zynq (рис. 1). Декодирование битов сообщения, реализованное в блоках Modified Buffer и Decode and Display, легко реализуется в системе обработки.

Читатели, которым интересно следить за работой модели Simulink, могут найти файлы в репозитории Analog Devices на GitHub.4
Генерация HDL-кода на основе модели Simulink
Блок «Детектор» в модели декодера Mode S (рис. 2) состоит из нескольких подсистем: CalcSyncCorr, CalcNF, SyncAndControl, BitProcess, CalcCRC и FameDetect. Для создания исходного HDL-кода для этой разработки используется HDL Coder от MathWorks5.

Чтобы успешно сгенерировать HDL-код с помощью HDL Coder, модель Simulink должна соответствовать нескольким условиям. Вот некоторые из наиболее важных требований:
Используйте блоки, поддерживающие генерацию HDL-кода. HDL Coder поддерживает генерацию кода примерно для 200 блоков Simulink.6 В проекте детектора все блоки, включая диаграмму Stateflow и блоки цифровых фильтров, поддерживают генерацию HDL-кода.
Используйте типы данных с фиксированной запятой. В конструкции детектора используются 12-битные, 24-битные и логические типы данных. 12-битный тип данных соответствует разрядности аналого-цифровых преобразователей приёмопередатчика Analog Devices AD9361.
Используйте скалярные или векторные сигналы. Векторные сигналы можно использовать для многоканальных сигналов или совместного использования ресурсов.
Избегайте алгебраических циклов в модели. Программа HDL Coder не поддерживает генерацию HDL-кода для моделей, в которых присутствуют условия алгебраических циклов.
Модель ModeS_Simulink_Decode.slx не соответствовала всем этим условиям, поэтому часть блока CalcCRC, которая сравнивает полученные биты с вычисленной контрольной суммой, была вынесена за пределы блока Detector и, в конце концов, реализована на языке C. Полученная модель ModeS_ADI_CodeGen.slx использовалась для генерации HDL-кода. В отличие от ручного кодирования, генерация нескольких тысяч строк HDL-кода занимает всего несколько минут. Исходный код, сгенерированный HDL Coder, представляет собой практически точную версию модели Simulink с точностью до такта. Это одно из главных преимуществ проектирования на основе моделей: сгенерированный код является точным переводом модели Simulink.
Кроме того, код разработан таким образом, чтобы его было легко читать и отслеживать, поэтому инженеры могут легко сопоставить сгенерированный код со своей проектной моделью. Это достигается несколькими способами (рис. 3):
Иерархия модели сохраняется в сгенерированных файлах HDL-кода. В этом примере блок верхнего уровня называется Detector.vhd, а подсистемы следующего уровня иерархии — CalcNF.vhd, Bit_Process.vhd и так далее.
В сгенерированном коде сохраняются названия блоков, портов, сигналов, типы данных и степень сложности, используемые в модели.

Связи между моделью и исходным кодом позволяют разработчику нажать на блок в модели Simulink и автоматически перейти к сгенерированному HDL-коду. Аналогичным образом в сгенерированном коде есть гиперссылки, которые открывают модель Simulink и выделяют блок, связанный с этим фрагментом кода.
Оптимизация модели ADS-B для создания HDL-кода с более высокой тактовой частотой
Несмотря на то что модель ModeS_ADI_CodeGen.slx успешно генерирует HDL-код, разработчики редко останавливаются на первоначальных результатах. Как правило, разработчикам необходимо соблюдать ограничения по скорости и занимаемой площади, что обычно предполагает оптимизацию исходной модели Simulink для достижения желаемых результатов. Главное преимущество Simulink и генерации кода заключается в том, что разработчик может внести эти изменения в модель, запустить симуляцию, чтобы убедиться, что изменения не нарушают работу алгоритма, а затем заново сгенерировать HDL-код. Обычно это гораздо проще и менее подвержено ошибкам, чем внесение изменений в исходный код HDL, которые могут нарушить работу алгоритма.
В этом случае HDL-код, сгенерированный на основе модели, легко помещался на имеющуюся ПЛИС, но работал с относительно низкой тактовой частотой. Такое часто встречается при первоначальном проектировании. Встроенный инструмент анализа в HDL Coder показывает, что критическая цепь в модели проходит от входа I/Q до первого регистра в подсистеме CalcCRC. Один из распространённых способов повысить тактовую частоту — добавить в схему конвейерные регистры (рис. 4). Конвейерная обработка сокращает время между сигнальными операциями благодаря увеличению общей задержки обработки. Такой компромисс обычно приемлем, поскольку небольшая задержка — это небольшая цена за более высокую тактовую частоту.

Регистры конвейера, расположенные между подсистемами, помогают повысить тактовую частоту проекта, но более высоких тактовых частот можно добиться за счёт выбора оптимальной архитектуры блоков цифрового фильтра. Многие блоки Simulink имеют несколько вариантов архитектуры, что позволяет разработчикам оптимизировать проект с точки зрения скорости или занимаемой площади. В случае с цифровыми фильтрами, используемыми для расчёта уровня собственных шумов и корреляции преамбулы (рис. 5), конвейерная обработка выходных умножителей может сократить критический путь в цифровом фильтре и повысить тактовую частоту проекта.

После внесения этих двух простых изменений в конвейер тактовая частота сгенерированного HDL-кода превысила 140 МГц. Это полезный урок для инженеров, использующих инструменты для генерации кода: даже небольшие знания о принципах проектирования аппаратного обеспечения могут существенно повлиять на результаты генерации кода. Дальнейшая оптимизация этой конструкции была возможна, но в ней не было необходимости, поскольку HDL-код легко соответствовал относительно простым требованиям к срокам и ресурсам для этой конструкции.
При традиционном подходе к разработке радиоаппаратуры значительная часть времени уходит на тестирование и отладку HDL-кода. При подходе к разработке на основе моделей, который используется в этом примере, больше времени тратится на разработку моделей для моделирования и генерации кода. Однако это позволяет значительно сократить время разработки, поскольку сгенерированный исходный код полностью соответствует проверенному поведению модели. На встроенном оборудовании требуется лишь минимальная отладка.
Генерация кода на языке C с помощью MATLAB Coder
Как и в случае с генерацией HDL-кода, для создания C-кода, реализующего функцию декодирования в этой схеме, необходимо выполнить несколько условий. Два самых важных требования:
Используйте функции, поддерживаемые MATLAB Coder. MATLAB Coder поддерживает большую часть языка MATLAB и широкий спектр наборов инструментов8, но вы можете неосознанно использовать функции, которые не поддерживаются для генерации кода. MATLAB Coder предоставляет такие инструменты, как Code Readiness Tool9, которые помогают найти неподдерживаемые функции.
Убедитесь, что после объявления переменной MATLAB её размер и тип не меняются. Это необходимо для корректного распределения памяти в сгенерированном коде.
Самый простой способ сгенерировать код на языке C из MATLAB — открыть новый проект MATLAB Coder, доступ к которому можно получить на вкладке «Приложения» на панели инструментов MATLAB. Окончательный результат работы проекта MATLAB Coder показан на рисунке 6.

В этом проекте функция верхнего уровня MATLAB называется DecodeBits_ADI.m. Пользователю необходимо указать типы данных и их размер, необходимые для этой функции, в качестве входных аргументов. На рисунке 6 показано, что входные аргументы этой функции — это 112 логических битов данных и два значения с двойной точностью (для определения текущей широты и долготы пользователя). Размер и тип выходных данных для DecodeBits_ADI.m (например, *nV для северной скорости, *eV для восточной скорости и *alt для высоты) автоматически определяются MATLAB Coder. MATLAB Coder находит все остальные функции, вызываемые файлом верхнего уровня DecodeBits_ADI.m, включая AltVelCalc_ADI.m и LatLongCalc_ADI.m, а затем генерирует исходный код на языке C для всего алгоритма декодирования.
Код на языке C, сгенерированный MATLAB Coder, представляет собой довольно простой перевод функций MATLAB на язык C. Как и в случае с генерацией HDL-кода, исходный код, созданный MATLAB Coder, легко читается и отслеживается, поэтому инженеры могут легко определить взаимосвязь между исходным кодом MATLAB и сгенерированным кодом на языке C. Код на языке C из этого примера можно сгенерировать в командной строке MATLAB и скомпилировать с помощью любого компилятора ANSI C.
Развёртывание платформы HDL-кода
После разделения проекта на функциональные блоки, которые будут работать на программируемой логике и системе обработки данных Zynq, оптимизации проекта для генерации HDL- и C-кода, а также проверки в ходе моделирования работоспособности оптимизированного проекта и соответствия критериям производительности, можно приступать к развёртыванию проекта на реальной аппаратной платформе SDR и проверке работоспособности системы в реальных условиях. Для этого используется платформа Analog Devices AD-FMCOMMS3-EBZ SDR10, подключённая к плате Xilinx ZC70611 под управлением дистрибутива Analog Devices Linux.
Плата AD-FMCOMMS3-EBZ поставляется с эталонным проектом Vivado HDL с открытым исходным кодом, предоставленным компанией Analog Devices.12 Этот эталонный проект содержит все IP-блоки, необходимые для настройки и передачи данных на приёмопередатчик AD9361 на плате AD-FMCOMMS3-EBZ и обратно. На рисунке 7 представлена блок-схема эталонного проекта HDL.

IP-ядро AD9361 реализует интерфейсы приёма и передачи данных LVDS между приёмопередатчиком AD9361 и устройством Zynq, а также интерфейсы передачи данных с остальными компонентами системы. Блоки прямого доступа к памяти используются для высокоскоростной передачи данных между IP-ядром AD9361 и памятью DDR. Интерфейс передачи данных в IP-блоке AD9361 состоит из четырёх линий приёма и четырёх линий передачи данных, соответствующих данным I&Q для двух каналов приёма и двух каналов передачи AD9361. Каждая линия передачи данных имеет ширину 16 бит. Чтобы повысить эффективность передачи данных внутри системы, данные приёма и передачи упаковываются в 64-битные шины, которыми управляют блоки прямого доступа к памяти. Блоки упаковки и распаковки используются для подключения 16-битных параллельных линий передачи данных микросхемы AD9361 к блокам прямого доступа к памяти.
Для развёртывания HDL-кода модели ADS-B в существующей HDL-инфраструктуре SDR-платформы необходимо создать IP-ядро, которое можно будет подключить к тракту передачи данных. Это позволит обрабатывать полученные данные в режиме реального времени и передавать их на программный уровень. Процесс развёртывания может оказаться сложной и трудоёмкой задачей, поскольку требует глубокого понимания функциональности HDL-проекта, а также соответствующих навыков программирования на HDL. Чтобы упростить эти этапы, MathWorks включила в HDL Coder утилиту HDL Workflow Advisor, а компания Analog Devices предоставила пакет поддержки плат (BSP) для платформы SDR AD-FMCOMMS2-EBZ/AD-FMCOMMS3-EBZ и платы Xilinx ZC706.13
HDL Workflow Advisor помогает пользователю выполнить все необходимые действия для генерации HDL-кода на основе модели Simulink. Пользователь может выбрать один из нескольких целевых рабочих процессов, в том числе «ASIC/FPGA», FPGA-in-the-Loop и «Генерация IP-ядер». В качестве целевой платформы можно выбрать оценочные платы Xilinx, оценочные платы Altera или SDR-платформу FMCOMMS2/3 ZC706. Остальная часть процесса генерации кода и интеграции с целевой платформой может быть автоматизирована с помощью HDL Workflow Advisor.
BSP от Analog Devices — это набор описаний плат и эталонных проектов14, которые предоставляют Workflow Advisor необходимую информацию и инструменты для создания IP-блока, совместимого с существующим эталонным проектом HDL, а также для вставки сгенерированного IP-блока в эталонный проект HDL. На рисунке 8 показано, как настроить Workflow Advisor для создания IP-ядра для модели ADS-B. Обратите внимание, что необходимо выбрать рабочий процесс создания IP-ядра для платформы Analog Devices AD-FMCOMMS3-EBZ SDR и платы Xilinx ZC706.

Следующий шаг — настройка интерфейсов между IP-адресом и эталонной схемой. На входе модель принимает необработанные I&Q-сэмплы, то есть входные порты модели напрямую подключены к портам данных приёмника AD9361. Из всех выходных сигналов модели теперь нас интересуют только сигналы data, frame_valid и bit_clk. Сигналы data и frame_valid имеют ширину 16 бит и синхронизируются по сигналу bit_clk. Эти сигналы могут быть подключены к интерфейсам DUT Data x Out BSP, что означает, что они получат прямой доступ к блокам DMA; затем данные могут быть переданы в DDR, который доступен на программном уровне. Сигнал bit_clk подключается к интерфейсу BSP DUT Data Valid Out и управляет частотой дискретизации DMA. На рисунке 9 показано, как должен быть настроен интерфейс HDL.

После определения целевого интерфейса шаги 2 и 3 в HDL Workflow Advisor можно оставить в исходном состоянии, а процесс создания проекта запустить, выполнив шаг 4.1 (Create Project). В результате этого шага будет создан проект Vivado с ядром ADS-B IP, интегрированным в эталонную схему Analog Devices HDL. На рисунке 10 показаны соединения между ядром ADS-B IP и остальными блоками схемы.

Генерация битового потока из проекта Vivado завершает процесс интеграции HDL, но конечная цель — запустить Linux на системе. Для этого после генерации битового потока можно создать загрузочный файл Linux, следуя стандартной процедуре создания первого загрузочного загрузчика (fsbl) Xilinx SDK и загрузочного файла Linux. Дерево устройств Linux и файлы образов, соответствующие вновь созданному проекту HDL, распространяются вместе с BSP AD-FMCOMMS3-EBZ. Все файлы необходимо скопировать вместе с загрузочным файлом Linux в загрузочный раздел SD-карты. Там хранятся все файлы, необходимые для запуска дистрибутива Analog Devices Linux на плате Xilinx ZC706.
C Code Platform Deployment
Теперь, когда IP-модуль ADS-B HDL интегрирован в HDL-проект SDR-платформы и создана SD-карта Linux, пришло время реализовать программное приложение для декодирования данных ADS-B. Это приложение основано на коде на языке C, сгенерированном в разделе 5, и выполняет следующие задачи:
Настройка AD9361 на приём сигналов ADS-B.
Считывание данных с IP-ядра ADS-B.
Определение корректных кадров ADS-B в считаных данных.
Расшифровка и отображение информации ADS-B.
Самый простой способ выполнить задачи 1 и 2 — использовать возможности библиотеки libiio.15 Эта библиотека предоставляет интерфейсные функции, которые позволяют пользователям легко настраивать AD9361, а также получать и передавать данные. В процессе настройки задаются следующие параметры системы:
LO frequency—1.09 GHz
Sampling rate—12.5 MHz
Analog bandwidth—4.0 MHz
AGC—fast attack mode
Помимо упомянутых выше параметров, в AD9361 встроен цифровой КИХ-фильтр с частотой дискретизации 12,5 млн выборок в секунду, полосой пропускания 3,25 МГц и полосой задерживания 4 МГц, который гарантирует, что принимаемые данные будут содержать только нужный диапазон. Параметры системы и методика проектирования этого КИХ-фильтра описаны в третьей части этой серии статей.3
Выходные данные ADS-B IP передаются в системную память DDR с помощью блока прямого доступа к памяти. Библиотека libiio предоставляет следующие функции: размещение данных, полученных от ADS-B IP, в буфере памяти заданного размера; ожидание заполнения буфера; получение доступа к буферу через указатели. После заполнения буфера данные могут быть обработаны с помощью алгоритма декодирования ADS-B. IP-ядро ADS-B имеет два выходных канала: один канал соответствует битовому потоку ADS-B, а другой указывает на конец действительного фрейма данных в битовом потоке. Оба канала имеют одинаковую скорость передачи данных и синхронизированы друг с другом. Значение «1» в канале подтверждения обозначает последний бит действительного кадра в канале данных. Анализируя оба канала, программное обеспечение может извлекать из битового потока действительные кадры данных ADS-B и передавать их в функцию декодирования, созданную с помощью MATLAB Coder. Функция декодирования использует кадр данных ADS-B, а также широту и долготу текущего местоположения в качестве входных данных для вычисления координат воздушного судна. Текущие широта и долгота задаются в качестве параметров приложения. Расшифрованные данные ADS-B отображаются так же, как в модели Simulink.
Приложение для декодирования данных ADS-B собрано под Linux с использованием make-файла. Исходный код приложения и make-файл можно найти в репозитории Analog Devices на github.16
На этом этапе завершается развёртывание платформы для HDL- и C-кода, сгенерированного на основе модели ADS-B с помощью HDL Coder и MATLAB Coder от MathWorks. Следующий шаг — проверка работоспособности системы и оценка результатов.
System Validation
Чтобы проверить работоспособность системы, сначала создайте петлевое соединение между одним приёмным и одним передающим портом платы AD-FMCOMMS3-EBZ и передайте тот же сигнал ADS-B, который использовался при моделировании. Приняв и декодировав эти данные, вы сможете убедиться, что результат работы алгоритма на платформе SDR соответствует результатам моделирования. На рисунке 11 показан результат работы приложения для декодирования данных ADS-B. Результаты идентичны тем, что были показаны в третьей части серии статей о моделировании HIL с использованием предварительно собранных данных. Это позволяет убедиться, что система работает должным образом и готова к использованию с реальными данными.

Для реальных полевых испытаний SDR-приёмник был установлен за пределами штаб-квартиры MathWorks в Натике, штат Массачусетс, и его работу сравнивали с данными ADS-B, декодированными системой, и данными с сайтов, отслеживающих самолёты в режиме реального времени (например, flightradar24.com). Было отмечено, что система способна декодировать данные, полученные от самолётов, находящихся в зоне прямой видимости антенны. На рисунке 12 показано сравнение данных о воздушном судне, полученных системой, с данными онлайн-отслеживания самолётов. Алгоритм декодирования отображает правильный идентификатор воздушного судна, высоту, скорость и координаты по широте и долготе.


Заключение
Эта статья завершает серию из четырёх материалов, демонстрирующих, как с помощью проектирования на основе моделей можно пройти весь путь от моделирования до внедрения SDR-системы. В серии статей рассматривались все этапы разработки «готовой к использованию в аппаратном обеспечении» модели ADS-B в Simulink. Мы разработали имитационную модель, чтобы доказать, что можем декодировать записанные сообщения ADS-B, а затем проверили модель на реальных данных, полученных с аппаратной платформы SDR. Это позволило проверить не только модель, но и настройки SDR-платформы для аналогового входного каскада и цифровой цепи приёмника, а также убедиться, что платформа правильно настроена для приёма сигналов ADS-B. Затем мы разделили модель на функциональные блоки, которые работают на системе обработки Zynq и программируемой логике, и оптимизировали модель для автоматической генерации кода на языках C и HDL. Наконец, мы интегрировали код на языках C и HDL в проект SDR и проверили работоспособность системы в условиях реального коммерческого воздушного движения. В результате мы получили процесс проектирования, в котором используются инструменты моделирования и генерации кода от MathWorks, а также платформа Zynq SDR для создания полнофункциональной SDR-системы.
Этот пример системы показывает, что процесс проектирования на основе моделей в сочетании с интегрированным программируемым радиооборудованием Analog Devices AD9361/AD9364 RF Agile Transceiver™ может помочь проектным группам создавать рабочие прототипы радиоустройств быстрее и с меньшими затратами, чем при использовании традиционных методологий проектирования. Этот прототип был создан авторами за относительно короткий срок с минимальными трудностями, с использованием следующих ресурсов:
Возможность создать в MATLAB и Simulink модель приёмника ADS-B, которая может генерировать исходный код на языках C и HDL.
Функции HDL Workflow Advisor позволяют автоматизировать многие этапы интеграции аппаратного и программного обеспечения.
Библиотеки (например, libiio), которые помогают выполнить оставшиеся этапы интеграции для развёртывания прототипа SDR.
Помощь в работе с продуктами и техническая поддержка от MathWorks и Analog Devices.
ADS-B — относительно простой стандарт, который хорошо подходит для демонстрации этого подхода к созданию прототипа программно-определяемого радиоприёмника. Инженеры, использующие проектный подход на основе моделей и платформу Zynq SDR, смогут следовать рекомендациям, представленным в этой серии статей, для разработки гораздо более сложных и мощных программно-определяемых радиосистем на основе QPSK, QAM и LTE.
Ссылки
1 Di Pu, Andrei Cozma, and Tom Hill. "Four Quick Steps to Production: Using Model-Based Design for Software-Defined Radio. Part 1—the Analog Devices/Xilinx SDR Rapid Prototyping Platform: Its Capabilities, Benefits, and Tools." Analog Dialogue, Volume 49, Number 3.
2 Mike Donovan, Andrei Cozma, and Di Pu. "Four Quick Steps to Production Using Model-Based Design for Software-Defined Radio. Part 2—Mode S Detection and Decoding Using MATLAB and Simulink." Analog Dialogue, Volume 49, Number 4.
3 Di Pu, Andrei Cozma. "Four Quick Steps to Production Using Model-Based Design for Software-Defined Radio. Part 3—Mode S Signals Decoding Algorithm Validation Using Hardware in the Loop." Analog Dialogue, Volume 49, Number 4.
4 Analog Devices GitHub repository.
5 HDL Coder.
9 MATLAB Code Generation Readiness Tool.
10 AD-FMCOMMS3-EBZ User Guide.
11 Xilinx Zynq-7000 All Programmable SoC ZC706 Evaluation Kit.
12 AD-FMCOMMS2-EBZ/AD-FMCOMMS3-EBZ/ AD-FMCOMMS4-EBZ HDL/AD-FMCOMMS5-EBZ HDL Reference Design.
13 Analog Devices BSP for MathWorks HDL Workflow Advisor.
14 Board and Reference Design Registration System.
15 What Is Libiio?