Эквализация гистограммы Используя буфер видеокадра

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

Поддерживаемая аппаратная платформа

  • Оценочный комплект Xilinx® Zynq® ZC706 + дополнительная плата FMC-HDMI-CAM

Спроектируйте задачу и системные требования

Рассмотрите заявление, включающее непрерывную потоковую передачу видеоданных через FPGA. В топ-модели soc_histogram_equalization_top FPGA вычисляет гистограмму входящего видеопотока, в подсистеме 'FPGA', при потоковой передаче того же видеопотока к внешней памяти для устройства хранения данных. Если гистограмма была вычислена и накоплена через целый видеокадр, сигнал синхронизации переключается, чтобы инициировать чтение назад сохраненной системы координат от внешней памяти. Накопленный вектор гистограммы затем применяется к чтению видеопотока назад от внешней памяти, чтобы выполнить алгоритм эквализации. Кадровый буфер внешней памяти моделируется с помощью блока 'Memory Channel' в AXI4-Stream Video Frame Buffer режим.

Блок 'HDMI Input' читает видеофайл и обеспечивает видеоданные и управляющие сигналы с нисходящими блоками обработки FPGA. Видеоданные находятся в формате YCbCr 4:2:2, и управляющие сигналы находятся в pixel control bus формат. Блок 'HDMI Output' читает видеоданные и управляющие сигналы, в том же формате, как выведено блоком 'HDMI Input', и обеспечивает визуальный выход с помощью блока Video Display.

Блок Push Button позволяет обойти алгоритма эквализации гистограммы, направляя необработанный выход от кадрового буфера внешней памяти до выхода.

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

  • Пропускная способность: Каков уровень, которому необходимо передать данные удовлетворить требованиям алгоритма? Специально для приложений видения, каковы формат кадра и частота кадров, которую необходимо смочь обеспечить?

  • Задержка: Каково максимальное количество времени, которое ваш алгоритм может терпеть между запросом и получением данных? Для приложений видения вам нужен непрерывный поток данных без разрывов? Могут вы, чтобы буферизовать выборки, внутренние к вашему алгоритму для того, чтобы предотвратить потерю данных, когда доступ к памяти блокирован?

Для этого примера эквализации гистограммы мы задали следующие требования:

  • Пропускная способность должна быть достаточной, чтобы обеспечить 1920x1080p видеопоток на уровне 60 кадров в секунду.

  • Задержка должна быть достаточно низкой, чтобы не пропустить системы координат.

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

$$1920\times1080\times60 = 124.416\,\mathrm{Msps}$$

Когда формат видео является YCbCr 4:2:2, мы требуем 2 байт на пиксель (бит/пкс), это приравнивается к требованию пропускной способности

$$2\times124.416 = 248.832\,\mathrm{MB/s}$$

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

$$2\times248.832 = 497.664\,\mathrm{MB/s}$$

Проект Используя SoC Blockset

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

  • Какова общая доступная пропускная способность памяти в системе SoC?

  • Как ваш алгоритм адаптируется к пропускной способности общей памяти?

  • Ваш алгоритм может терпеть увеличенную задержку чтения-записи?

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

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

Моделирование дополнительных потребителей памяти

Когда реализовано на оборудовании, HDMI выход требует дополнительного кадрового буфера для синхронизации данных о видеопотоке между областями часов и вводит дополнительного потребителя памяти в полной системе. Можно смоделировать это использование Memory Traffic Generator блоки, чтобы симулировать дополнительное потребление памяти. Когда мы моделируем и чтение и транзакции записи, мы будем использовать два Memory Traffic Generator блоки - один каждый для чтения и записи.

На основе вычисления пропускной способности для нашего потока 1080p видео мы знаем, что дополнительный кадровый буфер потребует$497.664\,\mathrm{MB/s}$ пропускной способности для одновременного доступа для чтения и доступа для записи.

Транзакции записи моделируются HDMI Buffer Write и транзакции чтения моделируются HDMI Buffer Read. Маску блока для обоих показывают ниже.

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

Пакетный размер задан как 192, который является 1/10-м из пикселей на строку. Когда пакетный размер задан в байтах, это эквивалентно одной десятой одной строки одного компонента выходного видеопотока, i.e. одна строка Y-компонента видеопотока YCbCr 4:2:2.

Время между пакетом задано как 1/1296000. Это может быть расширено как

$$\frac{192}{1080\times1920\times60\times2}$$

где,

192 количество байтов на пакет,

1080 количество линий в видеопотоке,

1920 количество пикселей на строку в видеопотоке,

60 количество кадров в секунду и,

2 количество компонентов в нашем видеопотоке.

Помещая вышеупомянутые параметры вместе, мы можем вычислить нашу требуемую пропускную способность можно следующим образом:

$$ 192\times1296000 = 248.832 \, \mathrm{MB/s}$$

И, когда у нас есть два генератора трафика, чтобы симулировать и чтение и транзакции записи, общее потребление пропускной способности будет $$497.664\, \mathrm{MB/s} $$

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

Здесь, ведущие устройства памяти следующие:

  1. Ведущее устройство 1: запись Кадрового буфера

  2. Ведущее устройство 2: чтение Кадрового буфера

  3. Ведущее устройство 3: буферная запись HDMI (генератор трафика памяти)

  4. Ведущее устройство 4: буферное чтение HDMI (генератор трафика памяти

  5. Ведущее устройство 5: Конкуренция (Генератор Трафика Памяти) (прокомментированный)

Вы видите, что все 4 активных ведущих устройства используют 248,8 Мбайт/с пропускной способности памяти.

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

Например, примите, что вам предоставляют следующие требования к памяти для вторичного алгоритма:

  • Пропускная способность: 650 Мбайт/с

Учитывая, что мы знаем в любое время, первичный алгоритм, плюс HDMI кадровый буфер выхода, использует ~995 Мбайт/с пропускной способности памяти, и наша общая доступная пропускная способность памяти составляет 1 600 Мбайт/с, мы знаем, что с общим требованием пропускной способности для нашей системы превышает общую доступную пропускную способность на ~50 Мбайт/с.

Чтобы включить моделирование вторичного доступа к памяти алгоритма, не прокомментируйте Contention Блок Memory Traffic Generator. Настройки маски блока показывают ниже.

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

Как вы видите, объединенная необходимая пропускная способность памяти превышает доступную пропускную способность приблизительно в 0,03 с - когда вторичный алгоритм начинает запросы доступа к памяти, приводящие к другим ведущим устройствам, не достигающим их необходимой пропускной способности. Смотря на форму волны анализатора логики, мы видим, что это проявило как пропущенные буферы для ведущего устройства записи Кадрового буфера, означая, что входной видеокадр не будет записан в память.

Реализуйте и работавший оборудование

Следующие продукты требуются для этого раздела:

  • HDL Coder™

Чтобы реализовать модель на поддерживаемой плате SoC используют Разработчика SoC приложение. Откройте маску подсистемы 'FPGA' и установите вариант модели на 'Основанную на пикселе обработку'.

Прокомментируйте 'Буферную Запись HDMI', 'Буферное Чтение HDMI' и 'Конкуренция' блокируются.

Нажатие кнопки, кнопка 'Configure, Build, & Deploy' в панели инструментов открытому Разработчику SoC

  • Выберите экран 'Build Model ' on ' Setup'. Нажмите 'Next'.

  • Нажмите 'View/Edit Memory Map', чтобы просмотреть карту распределения памяти на экране 'Review Memory Map'. Нажмите 'Next'.

  • Задайте папку проекта на экране 'Select Project Folder'. Нажмите 'Next'.

  • Выберите экран 'Build, load and run ' on ' Select Build Action'. Нажмите 'Next'.

  • Нажмите 'Validate', чтобы проверять совместимость модели для реализации на экране 'Validate Model'. Нажмите 'Next'.

  • Нажмите 'Build', чтобы начать создавать из модели на экране 'Build Model'. Внешний интерпретатор откроется, когда синтез FPGA начнется. Нажмите 'Next'.

  • Нажмите 'Next' на экран 'Load Bitstream'.

Синтез FPGA может занять больше чем 30 минут, чтобы завершиться. Чтобы сэкономить время, можно хотеть использовать обеспеченный предсгенерированный поток битов путем выполнения этих шагов:

  • Закройте внешний интерпретатор, чтобы отключить синтез.

  • Скопируйте предварительно сгенерированный поток битов в свою папку проекта путем выполнения команды ниже и затем,

  • Нажмите кнопку 'Load and Run', чтобы загрузить предварительно сгенерированный поток битов и запустить модель на плате SoC

copyfile(fullfile(matlabroot,'toolbox','soc','socexamples','bitstreams','soc_histogram_equalization_top-zc706.bit'), './soc_prj');

Теперь модель работает на оборудовании. Чтобы получить использование пропускной способности памяти в оборудовании, выполните следующий aximaster испытательный стенд для soc_histogram_equalization_top_aximaster.

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

Сводные данные

Вы спроектировали видео приложение с оперативным вводом-выводом HDMI и буферизацией системы координат во внешней памяти. Вы исследовали эффекты других потребителей памяти на полной пропускной способности. Вы использовали Разработчика SoC, чтобы реализовать модель на оборудовании и проверить проект.

Для просмотра документации необходимо авторизоваться на сайте