Документация

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

Рассмотрите заявление, включающее непрерывную потоковую передачу видеоданных через FPGA. 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 позволяет обойти алгоритма коррекции гистограммы, направляя необработанный вывод от кадрового буфера внешней памяти до вывода.

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

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

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

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

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

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

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

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

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

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

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

На основе вычисления пропускной способности для нашего потока 1080p видео мы знаем, что дополнительный кадровый буфер потребует пропускной способности для одновременного доступа для чтения и доступа для записи.

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

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

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

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

где,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Откройте Разработчика SoC из меню Tools и выполните эти шаги:

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

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

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

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

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

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