Zynq 7000: камера MIPI-CSI-2, вывод видео и аппаратный JPEG

Подробности изложены в материале первоисточника. Продолжаем знакомство с аппаратной обработкой видеосигнала от камеры на базе сенсора OV5647 с интерфейсом MIPI-CSI-2 и форматом RAW10. В первой части мы успешно подключили этот сенсор к отладочной плате на базе Zynq-7020, подготовили базовый проект в среде Vivado и вывели живую картинку на дисплей через интерфейс HDMI, используя готовый битстрим производителя и отладочный интерфейс JTAG. Теперь настало время перейти к созданию собственной конфигурации, разобрать типичные ошибки пересборки, внедрить аппаратное сжатие MJPEG и настроить автономную загрузку Linux.

Особое внимание в материале уделено репозиторию с артефактами, где собраны все необходимые исходные коды и скрипты для повторения экспериментов. Мы пошагово разберем борьбу с искажениями изображения, устраним проблемы входных задержек MIPI, скорректируем конфигурацию оперативной памяти DDR, исправим цветовые перестановки и разберем механизмы кадровой синхронизации.

Разбор четырех главных дефектов «почти правильной» картинки

Переход на собственный битстрим таит в себе множество подводных камней. В отличие от откровенных сбоев на чужом коде, где потоки просто замирали, собственный дизайн часто выдает изображение сразу, но с едва заметными, однако критичными дефектами. Подобные симптомы обычно маскируются под банальный аппаратный шум, но требуют системного подхода к диагностике.

Первая болезнь: чистый поток и рваные полосы

Индикаторы состояния конвейера могут рапортовать об абсолютной исправности: кадры размечаются корректно, строки поступают с нужной частотой, а канал захвата работает без остановок. Тем не менее, на мониторе возникают горизонтальные разрывы, а тесты контрольной суммы фиксируют сбои в каждом десятке окон. Причиной такого поведения чаще всего становится отсутствие корректной калибровки входных задержек MIPI-приемника. Если оставить параметр в состоянии по умолчанию, точка выборки оказывается в случайном месте, что портит каждую сотую строку.

Вторая болезнь: фоновый шум из-за памяти

После настройки задержек интерфейс приема стабилизируется, однако на экране сохраняется мелкая клетка и постоянный цифровой шум. Проверка фазы цветового фильтра ничего не дает, так как проблема кроется глубже — в контроллере памяти DDR. Если в проекте используется неверный пресет микросхемы или теряется правильный скрипт инициализации, контроллер работает с чужими таймингами и некорректной геометрией байтовых трактов. Из-за этого примерно пятая часть слов в кадровом буфере записывается с искажениями.

Третья болезнь: ловушка цветовых перестановок

Когда память работает стабильно, а шум исчезает, мы можем столкнуться с перепутанными цветами. Попытка исправить это изменением фазы демозаика обычно приводит к противоречивым результатам, поскольку в системе присутствует вторая независимая перестановка — на уровне упаковщика пикселей в 32-битные слова. Чтобы разорвать этот круг взаимного маскирования, применяется специальный метод заливки отдельных цветовых компонент максимальным значением через гамма-таблицу. Это позволяет точно определить реальное соответствие байтов в памяти и исправить конфигурацию упаковщика.

Четвертая болезнь: горизонтальные разрывы кадров

Динамические разрывы изображения на движении возникают тогда, когда каналы захвата и вывода обращаются к общему буферу без надлежащего согласования. Поскольку сенсор работает на фиксированной частоте 30 Гц, а монитор требует 60 Гц, рассинхронизация неизбежна. Решением становится схема динамического генлока, где ведущий захват публикует индекс заполненного буфера, а ведомый вывод аккуратно следует за ним, исключая одновременную запись и чтение одной ячейки памяти.

Интеграция чужого JPEG-энкодера и сетевой экспорт

Следующим этапом становится добавление аппаратного модуля сжатия в логику ПЛИС. Поскольку кристалл не имеет встроенного аппаратного кодека H.264, оптимальным выбором становится стандарт MJPEG, обеспечивающий независимое сжатие каждого кадра без межкадрового предсказания. Интеграция стороннего ядра требует создания внешней обвязки для согласования интерфейсов, преобразования цветовых пространств из RGB в YUV и управления потоком данных.

Для отладки подобных сложных блоков незаменимы симуляционные стенды на Verilog, позволяющие обнаружить внутренние тупиковые состояния автоматов за считанные секунды вместо долгих циклов пересборки железа на плате. Настроенный конвейер успешно упаковывает кадры, передавая их в сеть по UDP/HTTP с контролируемой частотой кадров и минимальным процентом потерь.