Обработка видео на FPGA: архитектура современного видеотракта

Обработка видео на FPGA без обязательного хранения полного кадра

Обработка видео на FPGA позволяет построить значительную часть видеотракта как непрерывный аппаратный конвейер. Данные принимаются интерфейсом, проходят через буферизацию, преобразование формата, масштабирование и другие этапы и передаются дальше — причём для многих операций системе не требуется сначала сохранять полный кадр во внешней памяти.

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

Что такое FPGA

FPGA — Field-Programmable Gate Array, программируемая пользователем вентильная матрица. После изготовления микросхемы разработчик формирует внутри неё требуемую цифровую структуру: интерфейсные блоки, регистры, FIFO, счётчики, фильтры, математические узлы, управляющую логику и параллельные пути обработки данных.

Универсальный CPU выполняет программный поток команд, хотя современные процессоры также широко используют параллелизм и конвейеризацию. Особенность FPGA в другом: разработчик формирует сам аппаратный путь прохождения данных. Для видео он может выглядеть так:

вход → приём видеоданных → буферизация → обработка → преобразование → выход.

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

Регистры, FIFO, строки и кадры

Память в видеотракте можно условно разделить на несколько уровней.

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

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

Line buffer хранит одну или несколько строк изображения. Он необходим алгоритмам, которым для расчёта очередного результата нужны данные соседних строк.

Frame buffer хранит уже полный кадр — иногда несколько кадров. При высоких разрешениях для этого обычно используется внешняя DDR.

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

Зачем видеотракту FIFO

Хороший пример — передатчик SDI. В SDI_TX для PolarFire между источником видеоданных и внутренним трактом SDI используется CDC FIFO — Clock Domain Crossing FIFO. Его задача состоит в переходе между двумя тактовыми доменами: видеоданные могут поступать с одной частотой, а дальнейшая SDI-обработка работать с другой.

Такой FIFO способен хранить до 4K пикселей видеопотока. Это масштаб современной строки изображения, а не полного 4K-кадра. Здесь хорошо видно различие между двумя понятиями:

FIFO обеспечивает движение и временное согласование потока. Frame buffer превращает кадр в сохранённый массив данных, к которому можно обращаться позднее.

Само наличие буфера поэтому ещё не делает архитектуру кадровой.

Масштабирование 4K не обязательно требует внешней DDR

Особенно наглядно потоковый подход проявляется в Image Scaler Microchip. Актуальная версия IP поддерживает bilinear scaling и polyphase scaling на основе фильтра Lanczos. В polyphase-конфигурации обрабатываются четыре пикселя за такт и поддерживается разрешение до 4K при 60 кадрах в секунду.

Изменение разрешения может показаться задачей, для которой естественно сначала сохранить исходный кадр целиком. Но описанная Microchip архитектура устроена иначе. Входной FIFO рассчитывается на хранение одной строки входного изображения, выходной FIFO — одной строки результата. Внутри polyphase scaler используются дополнительные line buffers и RAM: сначала выполняется горизонтальная обработка, её результаты поступают в буферы для последующей вертикальной фильтрации.

Упрощённо тракт можно представить так:

входные пиксели → горизонтальный фильтр → промежуточные строки → вертикальный фильтр → выходные пиксели.

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

Microchip приводит и практический пример: HDMI RX принимает 1920 × 1080 при 60 кадрах в секунду, scaler увеличивает изображение до 4K60, после чего видеопоток передаётся дальше к HDMI TX. Это показывает общий принцип: если следующий результат можно вычислить по ограниченному набору соседних данных, полный кадр хранить незачем.

Даже deinterlacing может оставаться потоковым

Deinterlacing кажется более очевидным кандидатом на кадровую память: чересстрочное видео необходимо превратить в прогрессивное. Однако требования к памяти определяются не названием операции, а конкретным алгоритмом.

Deinterlacer Microchip использует BOB deinterlacing с интерполяцией строк. Поля обрабатываются независимо, а недостающие строки восстанавливаются по соседним данным. Поэтому IP использует внутренние line buffers и не требует внешнего DDR/frame buffer.

Но этот пример нельзя переносить на любой deinterlacing. Motion-adaptive и особенно motion-compensated алгоритмам может требоваться анализ данных разных полей или кадров. Чем больше пространственного и временного контекста необходимо алгоритму, тем больше информации система должна сохранить.

Отсюда следует более общий принцип:

объём памяти определяется тем, какую часть предыдущих данных алгоритм должен видеть для вычисления следующего результата.

Когда появляется полный кадр в памяти

Противоположный пример даёт PolarFire 4K Dual Camera Video Kit. В этом референсном проекте используются две MIPI-камеры 4K30. Полученные кадры записываются в DDR, а затем передаются к display controller в соответствии с временными параметрами вывода.

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

Frame buffer полезен, когда требуется:

• временно сохранить изображение;
• развязать синхронизацию источника и выхода;
• повторно обращаться к данным кадра;
• сопоставлять несколько кадров;
• менять временную последовательность;
• выполнять обработку, зависящую от предыдущих изображений;
• организовать сложное взаимодействие нескольких видеопотоков.

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

В конкретном dual-camera проекте Microchip кадры действительно сохраняются во внешней памяти — и именно это делает его полезным контрпримером к потоковому scaler.

Потоковый и кадровый видеотракт

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

Например:

SDI RX → преобразование → scaler → deinterlacer → HDMI / DisplayPort / SDI TX.

Такой тракт способен выполнять достаточно сложную обработку, не превращая каждый проходящий кадр в объект, обязательно сохранённый во внешней памяти.

В кадровой архитектуре появляется дополнительный этап:

video input → frame buffer / DDR → processing / display → video output.

После записи в память система может обращаться к изображению существенно менее зависимо от текущего входного потока. На практике эти подходы часто сочетаются: критичные по задержке участки работают непосредственно с потоком, а DDR подключается там, где алгоритму действительно нужен произвольный доступ к изображению или временная независимость от источника.

Low latency определяется путём данных

FPGA часто связывают с low-latency video processing. Для этого есть основания, но сам тип вычислителя ещё ничего не гарантирует. Можно построить аппаратный конвейер из регистров, FIFO и line buffers, в котором результаты начинают формироваться ещё во время поступления текущего кадра. А можно взять ту же FPGA и построить систему, где каждый кадр сначала записывается во внешнюю DDR, а затем считывается для дальнейшей обработки.

Поэтому корректнее формулировать так:

FPGA позволяет проектировать архитектуру задержки, но сама задержка определяется алгоритмом и путём данных.

Если вычислению достаточно текущих пикселей и нескольких строк, полный кадр хранить не требуется. Если нужен предыдущий кадр, изменение временной последовательности или произвольный доступ к изображению, frame buffer появляется осознанно — вместе с дополнительными возможностями и затратами на передачу данных.

Единого значения задержки для абстрактного «FPGA-видеотракта» поэтому не существует.

SDI, HDMI и DisplayPort становятся границами одного тракта

Именно в этом контексте интересен технический анонс Microchip летом 2026 года. Компания развивает PolarFire Smart Embedded Vision как связанный видеотракт ingest → processing → conversion → display, объединяющий SDI, HDMI и DisplayPort. Для SDI заявлена поддержка от 270 Мбит/с до 12G, включая 4K60; среди доступных решений присутствуют преобразование интерфейсов, scaling и deinterlacing.

С инженерной точки зрения важнее не само количество поддерживаемых стандартов. SDI, HDMI и DisplayPort становятся границами программируемого пути данных:

12G-SDI → FPGA → обработка → HDMI

HDMI → FPGA → обработка → DisplayPort

камера → FPGA → обработка → SDI

Уже внутри этого пути разработчик определяет, где достаточно регистров и FIFO, где необходимы несколько строк внутренней памяти и где действительно оправдан переход к полноценному frame buffer в DDR.

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

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

Поэтому вопрос «какая FPGA здесь используется?» позволяет понять только часть архитектуры. Для видеосистемы не менее важно определить:

где движется непрерывный поток, какой объём изображения должен помнить каждый блок и в какой точке данные впервые превращаются в сохранённый кадр.

Именно путь данных показывает реальную архитектуру видеотракта — и характер возникающей в нём задержки.