Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Вывод видео на монитор.
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
LAS9891
Здравствуйте! Прошу совета. Задача следующая. Требуется вывести видеоизображение с КМОП матрицы на стандартный монитор. Проект реализую на Cyclone IV. На плате также имеется SRAM 2 MB и SDRAM 64 MB. Пиксельная частота камеры 2 МГц, пиксельная частота монитора 40 МГц. Разрешение кадра 800х600. Матрица выдает кадры друг за другом без остановки. Поскольку частоты не совпадают необходимо использовать кадровый буфер. Предполагаю два варианта:

1) организовать кадровый буфер в SRAM на два кадра. При этом считывать данные из матрицы сначала в FIFO1 затем в SRAM. Когда первый кадр будет записан в SRAM начать выводить первый кадр SRAM->FIFO2->Монитор, при этом записывать второй кадр.

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

2) организовать кадровый буфер на два кадра в разных микросхемах: в SRAM первый кадр, в SDRAM второй кадр. В этом случае шины адреса и шины данных раздельные и можно одновременно писать второй кадр в SDRAM и считывать первый из SRAM.

При такой реализации возникают такие вопросы. В случае если кадр на монитор выведен, а новый еще не считался, можно будет повторить вывод старого кадра, после чего вывести новый кадр. Но вот в чем проблема, матрица выдает кадры друг за другом без остановки, и если новый кадр не считался (не успел) точно к моменту, когда старый закончил выводиться на монитор, то будет постоянно выводиться старый кадр. Как добиться этой синхронности? или необходимо считывать кадры с матрицы не постоянно, а только по требованию? типа считал первый кадр, начинаешь выводить первый и считывать второй, выводишь первый кадр несколько раз, до тех пор, пока не считается второй, когда считался второй, начинаем выводить второй и писать третий и так по кругу.
_pv
организовать кадровый буфер на один кадр где угодно, лишь бы туда скорость доступа была быстрее чем 42МГц.
ну или даже 80Мгц, так чтобы чтение запись вообще не мешали друг другу, и без дополнительного фифо на 20 отсчётов тогда обойтись.
Burenkov Sergey
У альтеры есть такая кора - frame buffer, один из ее вариантов использования как раз пересинхронизация fps. Вот алгоритм тройной буфферизации, как он онписан в доках:
For triple-buffering, the IP core uses three frame buffers in external RAM.
• The writer uses one buffer to store input pixels.
• The reader locks the second buffer that reads the output pixels from the memory.
• The third buffer is a spare buffer that allows the input and the output sides to swap buffers asynchronously. The spare buffer can be clean or dirty.
— Considered clean if it contains a fresh frame that has not been sent.
— Considered dirty if it contains an old frame that has already been sent by the reader component.

When the writer completes storing a frame in memory, it swaps its buffer with the spare buffer if the spare buffer is dirty.
• The buffer locked by the writer becomes the new spare buffer and is clean because it contains a fresh frame.
• If the spare buffer is already clean when the writer completes writing the current input frame:
— If dropping frames is allowed—the writer drops the newly received frame and overwrites its buffer with the next incoming frame.
— If dropping frames is not allowed—the writer stalls until the reader completes its frame and replaces the spare buffer with a dirty buffer.
When the reader completes reading and produces a frame from memory, it swaps its buffer with the spare buffer if the spare buffer is clean.
• The buffer locked by the reader becomes the new spare buffer; and is dirty because it contains an old frame that has been sent previously.
• If the spare buffer is already dirty when the reader completes the current output frame:
— If repeating frames is allowed—the reader immediately repeats the frame that has just been sent.
— If repeating frames is not allowed—the reader stalls until the writer completes its frame and replaces the spare buffer with a clean buffer.

Скорости SDRAM хватит чтобы делать такую пересинхронизацию, на плате с CycloneV и SDRAM 16bit у меня работало как раз с такими параметрами - 800 на 600, 40MГц pixel clock
LAS9891
Цитата(_pv @ Aug 11 2017, 16:18) *
и без дополнительного фифо на 20 отсчётов тогда обойтись.

А можно подробнее?
_pv
если доступ к памяти быстрее 80МГц, значит в каждый цикл чтения данных для монитора можно ещё впихнуть цикл записи, если очередной пиксель с камеры пришёл.
даже если цикл доступа медленнее 80МГц, но быстрее чем 42, то в 21 цикл обращения к памяти можно впихнуть 20 чтений и одну запись, но так как чтение теперь не совпадает по частоте с частотой монитора, читать надо через небольшое фифо, откуда монитор с частотой 40МГц данные будет забирать.
Burenkov Sergey
У вас с матрицы идет 8 или 10 бит? И Bayer filter вы делаете сами или контроллер матрицы? Какая SDRAM на плате установлена, на какой частоте вы ее запускаете?
Volkov
Тут важна кадровая частота матрицы.
Вывод лучше сделать синхронным к частоте матрицы. Если кадровая частота матрицы кратна частоте монитора, тогда все прозаично -

Для буферов чтения / записи используйте одну микросхему.
Чтение / запись блоками, через фифо, по кадровому записи переключаете адреса буферов.

Таки образом, пока пишется буфер по адресу 1, вы выводите N кадров из буфера 2. Можно реализовать интерполяцию кадров. В этом случае, у вас три буфера, и вы выводите сумму предыдущего и текущего кадра с разными весами.

Если кадровые частоты не кратны - то у вас появится срез синхронизации, который будет проявляться при динамике.
Это можно решить по аналогии с 3:2 pull down - https://en.wikipedia.org/wiki/Three-two_pull_down









LAS9891
Цитата(Burenkov Sergey @ Aug 12 2017, 00:58) *
У вас с матрицы идет 8 или 10 бит? И Bayer filter вы делаете сами или контроллер матрицы? Какая SDRAM на плате установлена, на какой частоте вы ее запускаете?

C матрицы идёт 8 бит. На счёт Bayer filter - матрица монохромная. Пока пробую использовать асинхронную SRAM:
Нажмите для просмотра прикрепленного файла

Цитата(_pv @ Aug 11 2017, 17:37) *
если доступ к памяти быстрее 80МГц, значит в каждый цикл чтения данных для монитора можно ещё впихнуть цикл записи, если очередной пиксель с камеры пришёл.
даже если цикл доступа медленнее 80МГц, но быстрее чем 42, то в 21 цикл обращения к памяти можно впихнуть 20 чтений и одну запись, но так как чтение теперь не совпадает по частоте с частотой монитора, читать надо через небольшое фифо, откуда монитор с частотой 40МГц данные будет забирать.

Возможно ли использовать такой алгоритм с вот такой памятью:
Нажмите для просмотра прикрепленного файла
Burenkov Sergey
[quote name='LAS9891' date='Aug 14 2017, 08:12' post='1513239']
C матрицы идёт 8 бит. На счёт Bayer filter - матрица монохромная. Пока пробую использовать асинхронную SRAM:
Нажмите для просмотра прикрепленного файла[/quote ]

Можно конечно вручную высчитывать когда прочитать или записать байт в память, чтобы синхронизировать вход и выход, но по моему гораздо проще абстрагироваться от этого. Если вы работаете в Qsys, то общий доступ к памяти сделаем за вас avalon interconnect. Вам нужно взять готовые модули Avalon Master https://www.altera.com/support/support-reso...-avalon-mm.html , обернуть их в несложную логику, по алгоритму который я выше приводил. Вы просто будете запускать чтение и запись с нужных адресов выставлением всего нескольких сигналов(адрес и старт) а все остальное сделает за вас контроллер памяти и interconnect.
Размера и скорости SRAM хватит в вашем случае. Вам надо около 3,84мегабита для тройной буферизации, память у вас 16М, скорость нужна 336Мб/с, если у вас память имеет время доступа 20 ns, то ее пропускная способность 800Мб/с, так что все с запасом
novikovfb
Цитата(Volkov @ Aug 12 2017, 15:52) *
Для буферов чтения / записи используйте одну микросхему.
Чтение / запись блоками, через фифо, по кадровому записи переключаете адреса буферов.

Таки образом, пока пишется буфер по адресу 1, вы выводите N кадров из буфера 2. Можно реализовать интерполяцию кадров. В этом случае, у вас три буфера, и вы выводите сумму предыдущего и текущего кадра с разными весами.

В чем смысл двух буферов, если источник видео - камера, т.е. идет монотонная запись в буфер без всяких предварительных стираний, обработки и т.п., свойственных процессорной обработке?
Что даст интерполяция кроме дополнительной задержки?
Volkov
Цитата(novikovfb @ Aug 14 2017, 11:51) *
В чем смысл двух буферов, если источник видео - камера, т.е. идет монотонная запись в буфер без всяких предварительных стираний, обработки и т.п., свойственных процессорной обработке?
Что даст интерполяция кроме дополнительной задержки?


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

Интерполяция даст плавное изменение кадров.
LAS9891
Использую мегафункцию DCFIFO. Возник вопрос. Возможна ли одновременная запись и чтение данных в/из DCFIFO?
Flip-fl0p
Цитата(LAS9891 @ Aug 15 2017, 09:09) *
Использую мегафункцию DCFIFO. Возник вопрос. Возможна ли одновременная запись и чтение данных в/из DCFIFO?

Да, поскольку у Altera FIFO строится на двухпортовой памяти.
Maverick
Цитата(Flip-fl0p @ Aug 15 2017, 09:10) *
Да, поскольку у Altera FIFO строится на двухпортовой памяти.

Дополню:
не желательно работать одновременно с одной и той же ячейкой памяти в одно и тоже время - тогда желательно процесс чтения и записи нужно разнести во времени....
Flip-fl0p
Цитата(Maverick @ Aug 15 2017, 09:13) *
Дополню:
не желательно работать одновременно с одной и той же ячейкой памяти в одно и тоже время - тогда желательно процесс чтения и записи нужно разнести во времени....

А разве в DСFIFO это не автоматически делается ?
andrewkrot
https://od.lk/fl/NDVfMzU4NzA1Xw качаете здесь файл 24_verilog_4 там примеры для различных матриц для платы AX309/ Может поможет)
Flip-fl0p
Цитата
Здравствуйте! Прошу совета. Задача следующая. Требуется вывести видеоизображение с КМОП матрицы на стандартный монитор. Проект реализую на Cyclone IV. На плате также имеется SRAM 2 MB и SDRAM 64 MB. Пиксельная частота камеры 2 МГц, пиксельная частота монитора 40 МГц. Разрешение кадра 800х600. Матрица выдает кадры друг за другом без остановки. Поскольку частоты не совпадают необходимо использовать кадровый буфер.

Я бы кадровый буфер организовал в SDRAM в разных банках. В один банк пишите. Из другого читаете, и их чередуете. Хотя можно и в одном банке. По одним адресам пишите, по другим читаете, и так-же чередовать их.
Читал и записывал в SDRAM через FIFO, чтобы можно было "отвлекаться" на чтение из памяти для записи новых данных. Т.е в одно FIFO пишу данные с камеры, потом из этого FIFO пишу в SDRAM. А в другое FIFO читаю данные из SDRAM и из него вывожу данные на монитор. Всем этим делом бы управлял простенький автомат, который следил за наполнением\опустошением FIFO буферов и переключался на чтение или запись, в зависимости о того в каком состоянии находиться тот или иной буфер. Тут главный критерий, организовать чтение запись так, чтобы данные не успели деградировать. Иначе придётся вводить регенерацию памяти.
Кадр менял бы тогда, когда идет обратный ход луча (если в старой терминологии), т.е когда мы полностью отрисовали предыдущий кадр.
Посмотрите ещё размер ячейки памяти, влезут ли в неё все биты цвета.
Как мне кажется самая сложная задача здесь - написать SDRAM контроллер. Ну или взять готовый...
_pv
со статической памятью конечно всё гораздо проще, но за те 20$ что стоит 2МБ памяти, можно взять одноплатный ПК с хоть с гигабайтом памяти и любым видеовыходом, а картинку с камеры ему любым образом через какой-нибудь, например USB загнать, а то и вообще с параллельным входом под камеру найти.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.