В этом примере показано, как спроектировать фильтры, которые работают с мультипиксельным входным видеопотоком. Используйте мультипиксельную потоковую передачу, чтобы обработать видео или высокой частоты кадров с высоким разрешением с той же синтезируемой тактовой частотой как интерфейс потоковой передачи одно пикселя. Мультипиксель, передающий потоком также, улучшает скорость симуляции и пропускную способность, потому что меньше итераций требуется, чтобы обрабатывать каждый кадр при поддержании аппаратных преимуществ интерфейса потоковой передачи.
Модель в качестве примера имеет три подсистемы, которые каждый выполняет тот же алгоритм:
SinglePixelGaussianEdge: Использует блоки Детектора Фильтра и Ребра Изображений, чтобы работать с потоком одно пикселя. Эта подсистема показывает, как уровни и интерфейсы для потоковой передачи одно пикселя соответствуют мультипиксельным проектам.
MultiPixelGaussianEdge: Использует блоки Детектора Фильтра и Ребра Изображений, чтобы работать с мультипиксельным потоком. Эта подсистема показывает, как использовать мультипиксельный интерфейс с библиотечными блоками.
MultiPixelCustomGaussianEdge: Использует блок Line Buffer, чтобы создать Гауссов фильтр и обнаружение ребра Sobel для мультипиксельного потока. Эта подсистема показывает, как использовать Line Buffer выход для мультипиксельного проекта.
Обработка мультипиксельных видеопотоков позволяет, чтобы более высокая частота кадров была достигнута без соответствующего увеличения к тактовой частоте. Каждая из подсистем может достигнуть тактовой частоты на 200 МГц на плате Xilinx ZC706. Видеопоток на 480 пунктов имеет Общие пиксели на строку x Общие видео линии = 800*525 циклов на систему координат. С одним пиксельным потоком можно обработать 200M / (800*525) = 475 кадров в секунду. В мультипиксельной подсистеме 4 пикселя обрабатываются на каждом цикле, который сокращает количество циклов на строку к 200. Это означает, что с мультипиксельным потоком, работающим с 4 пикселями за один раз, на уровне 200 МГц, на потоке на 480 пунктов, 1900 кадров могут быть обработаны в секунду. Если разрешение увеличено с 480 пунктов до 1 080 пунктов, 80 кадров в секунду могут быть достигнуты в одном пиксельном случае по сравнению с 323 кадрами в секунду для 4 пикселей за один раз или 646 кадрами в секунду для 8 пикселей за один раз.
Сгенерируйте мультипиксельный поток от блока Frame to Pixels установкой Number пикселей к 4 или 8. Значение по умолчанию 1 возвращает скалярный пиксельный поток с частотой дискретизации Общих пикселей на строку * Общие видео линии быстрее, чем частота кадров. Этот уровень показывает красный в модели в качестве примера. Подсистемы на два мультипикселя используют мультипиксельный поток с Количеством пиксельного набора к 4. Эта настройка возвращает 4 пикселя на каждом такте и имеет частоту дискретизации (Общие пиксели на линию/4) * Общие видео линии. Более низкая норма выработки, которая является зеленой в модели, показывает, что можно увеличить или уровень входного кадра или разрешение на коэффициент 4 и поэтому процесс в 4 раза больше пикселей в тот же период системы координат с помощью той же тактовой частоты, чем один пиксельный случай.
Подсистемы SinglePixelGaussianEdge и MultiPixelGaussianEdge вычисляют тот же результат с помощью блоков Детектора Фильтра и Ребра Изображений.
В MultiPixelGaussianEdge блоки принимают и возвращают четыре пикселя на каждом такте. Вы не должны конфигурировать блоки для мультипиксельной потоковой передачи, они обнаруживают входной размер на порте. pixelcontrol шина указывает на валидность и местоположение в системе координат каждого набора четырех пикселей. Блоки буферизуют [4x1] поток, чтобы сформироваться четыре [KernelHeight x KernelWidth] ядра и вычислить четыре свертки параллельно, чтобы дать [4x1] выход.
Подсистема MultiPixelCustomGaussianEdge использует блок Line Buffer, чтобы реализовать пользовательский алгоритм фильтрации. Эта подсистема похожа на то, как библиотечные блоки внутренне реализуют мультипиксельные операции ядра. Блоки Детектора Фильтра и Ребра Изображений используют более подробную оптимизацию, чем показано здесь. Эта реализация показывает начальную точку для создания пользовательских мультипиксельных алгоритмов с помощью выхода блока Line Buffer.
Пользовательский фильтр и пользовательский детектор ребра используют блок Line Buffer, чтобы возвратиться последовательный [KernelHeight x NumberofPixels] области. Каждая область передается подсистеме KernelIndexer, которая использует буферизацию и индексацию логики, чтобы сформировать Количество Пикселей * [KernelHeight x KernelWidth] ядра фильтра. Затем каждое ядро передается отдельной подсистеме FilterKernel, чтобы выполнить свертки параллельно.
Подсистема KernelIndexer формируется 4 [5x5] ядра фильтра от 2D выхода блока Line Buffer.
Схема показывает, как ядро фильтра извлечено из [5x4] поток вывода для ядра, которое сосредоточено на первом пикселе в [4x1] выход. Это первое ядро включает пиксели от 2 смежных [5x4] Line Buffer выходные параметры.
Ядро, сосредоточенное на последнем пикселе в [4x1] выход также, включает третье смежное [5x4] выход. Так, чтобы сформироваться четыре [5x5] ядра, подсистема должна получить доступ к столбцам от три [5x4] матрицы.
Подсистема KernelIndexer использует ток [5x4] вход и хранит еще два [5x4] матрицы с помощью регистров, включенных shiftEnable. Этот проект похож на коснувшуюся линию задержки, используемую с Буфером Линии использование одной пиксельной потоковой передачи. Подсистема затем пиксельные данные доступов через столбцы, чтобы сформировать четыре [5x5] ядра. Блок Image Filter использует эту ту же логику внутренне, когда блоку вводили мультипиксель. Блок автоматически проектирует эту логику во время компиляции для любого поддерживаемого размера ядра.
Поскольку входной мультипиксельный поток [4x1] вектор, фильтры должны выполнить четыре свертки на каждом цикле, чтобы идти в ногу с входящими данными. Существует четыре параллельных подсистемы FilterKernel, что каждый выполняет ту же операцию. [5x5] умножение матриц, реализован как [25x1], вектор умножается путем выравнивания входной матрицы и использования Для Каждой подсистемы, содержащей конвейерный множитель. Выход передается дереву сумматора. Дерево сумматора является также конвейерным, и конвейерная задержка применяется к pixelcontrol предупредите, чтобы соответствовать. Результаты четырех подсистем FilterKernel затем конкатенированы в [4x1] выходной вектор.
Чтобы совпадать с алгоритмом блока Edge Detector, этот пользовательский детектор ребра использует [3x3] размер ядра. Сравните эту подсистему KernelIndexer для [3x3] обнаружение ребра с [5x5] ядро, описанное выше. Алгоритм все еще должен получить доступ к трем последовательным матрицам от выхода блока Line Buffer (включая дополнение по обе стороны от ядра). Однако алгоритм сохраняет меньше столбцов, чтобы сформировать меньшее ядро фильтра.
Для [4x1] мультипиксельный поток, логика KernelIndexer будет выглядеть подобной до [11x11] размер ядра. В том размере, количестве дополнения пикселей, (floor(11/2)) = 5, перекроется на два [11x4] матрицы, возвращенные в Буфер Линии. Это перекрытие означает, что алгоритм должен был бы сохранить пять [5x4] матрицы от Буфера Линии, чтобы сформироваться четыре [11x11] ядра на каждом цикле.
В настройке в качестве примера по умолчанию, одном пикселе, мультипикселе и пользовательских мультипиксельных подсистемах весь запуск параллельно. Скорость симуляции ограничивается временем, обрабатывая путь одно пикселя, потому что это требует, чтобы больше итераций обработало тот же размер системы координат. Чтобы наблюдать улучшение скорости симуляции для мультипиксельной потоковой передачи, закомментируйте путь одно пиксельных данных.
HDL был сгенерирован и от подсистемы MultiPixelGaussianEdge и от подсистемы MultiPixelCustomGaussianEdge и проведен через Место и Маршрут на плате Xilinx™ ZC706. Подсистема MultiPixelCustomGaussianEdge, которая не пытается оптимизировать коэффициенты, имела следующие результаты -
T =
4x2 table
Resource Usage
_________ _____
DSP48 108
Flip Flop 4195
LUT 4655
BRAM 12
Подсистема MultiPixelGaussianEdge, которая использует оптимизированные блоки Детектора Фильтра и Ребра Изображений, использует меньше ресурсов, как показано в приведенной ниже таблице. Это сравнение показывает сбережения ресурса, достигнутые, потому что блоки анализируют структуру фильтра и предварительно добавляют повторенные коэффициенты.
T =
4x2 table
Resource Usage
_________ _____
DSP48 16
Flip Flop 3959
LUT 1797
BRAM 10
Edge Detector | Frame To Pixels | Image Filter | Pixels To Frame