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

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

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

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

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

Когда формат видео является 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-м из пикселей на строку. Когда пакетный размер задан в байтах, это эквивалентно одной десятой одной строки одного компонента выходного видеопотока, i.e. одна строка 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' и 'Конкуренция' блокируются.

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

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

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

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

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

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

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