Задача следующая: требуется на лету хватать потоковое видео (700 * 500, YUV) и делать вычитание попиксельно предыдущего из текущего кадра изображения. Какова будет принципиальная схема устройства, я думаю, что входной видеосигнал надо раскодировать (выхватить данные), считать пикселы с теми же координатами из предыдущего кадра из ОЗУ, произвести вычитание и сразу же выдать на выход (или писать в ОЗУ сначала?). Верна ли схема или будут задержки, из-за которых она не сработает? От чего это будет зависеть? Какую микросхему ОЗУ выбирать для этих целей, может подойдет статическое или надо динамическое? ПЛИС - Xilinx Spartan 3 или Virtex 4 (пока побольше возьмем с запасом). Возможно я задаю глупые вопросы, прошу указать на неточности, если что не так. Более точными характеристиками видеосигнала пока не владею, будут уточняться. Спасибо.

Если все так, как Вы описали, задача - халявная. Тип используемого ОЗУ здесь роли не играет и определяется причинами, к обработке видео напрямую не относящимися. Если потребление не критично - используйте статическое ОЗУ - упростите себе жизнь за счет работы с памятью.

Никаких считываний с координат не нужно. Данные в ПЛИС поступают построчно - заведите инкрементный счетчик адреса. На каждый вновь принятый пиксель:
-считайте из ОЗУ по текущему состоянию счетчика;
-вычтите прочитанное значение из принятого пикселя и выдайте его наружу;
-запишите принятый пиксель в озу по текущему состоянию счетчика адреса;
-увеличте счетчик.
В конце кадра счетчик сбросьте и начните сначала....

Ух-ты, как все классно! Тогда получается, что весь кадр не нужно хранить, только несколько обрабатываемых одновременно пикселей? Спасибо огромное, буду смотреть потребление статических ОЗУ

Поторопился на радостях, все верно - нужно хранить кадр целиком. Отлично

А с какой целью производится вычитание?

Кадр нужно хранить целиком. Учтите, что у указанных Вами ПЛИС есть встроенные блоки ОЗУ. имеет смысл использовать их. на весь кадр (700х500) пикселей их, скорее всего, не хватит, но объем внешней памяти они помогут сократить.

Просмотрите внимательно структуру входного видеопотока. Может оказаться, что Вам передаются все три канала YUV, без прореживания. А это уже потребует объем памяти больше мегабайта.

действительно - а зачем вам вычитать два кадра? обычно их складывают и тогда получают много интересного
не могли бы расскрыть секрет вашей задачи?

а память берите статическую - тогда неикаких проблем у вас не будет
тем более чейчас памяти с 10 нс как грязи

Сообщение отредактировал net - Aug 16 2006, 17:16

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

Fast SRAM: K6R4016 - 2 штуки должно хватить, стоят ~100р в розницу за штуку. Чудные микросхемки от самсунга

В паре с ПЛИС лучче применять синхронную память - не нужно возиться с задержками при формировании сигналов (WE например). Все по такту делается, который тот же самый, что и системный клок внутриплисового дизайна.

Встроенных блоков всего ничего, на несколько строк (если говорить о спартане), так что помоему не стоит и заморачиваться, лучше на встронной памяти сделать фильтры какие нибудь или еще что.
Входной поток скорее всего либо YUV422, либо YUV420 - врядли поток совсем без прореживания.


Еще обратите внимание на тип потока (интерлэйс, прогрессив).

Полностью поддреживаю.И как пример - вот вам память от кипариса CY7C1380C. На сайте даже модель на VHDL есть.

Не знаю как синхронная статическая ОЗУ, я в проекте совместно со Spartan II использую асинхронную статическую ОЗУ 512Kx32. Читаю данные с LCD порта - формат видео режима TFT 800x600x16 бит. Тактовая частота 40 Мгц. Сохраняю текущий кадр, а предыдущий после обработки выдаю дальше. Все работает замечательно и линий управления у ОЗУ меньше по-сравнению с синхронной.

С асинхронной тоже имели дело - иначе не писали бы. Да, работает она - куда ей деться, но с синхронной работать, во-первых, удобнее, во-вторых, она быстрее. Я делал честный синхронный контроллер памяти (поскольку внутри ПЛИС весь дизайн синхронный), который формировал сигнал nWE строго по тактам. Итого на цикл обращения приходится три системных такта. Мне вот скорость была важна и пришлось задирать системную тактовую аж до 200 МГц, хотя сам дизайн этого не требовал - вполне хватило бы сотни. В итоге, на 200 МГц не уложился по скорости, пришлось опуститься на 160 МГц и еще наворотить тучу констрейнов, чтобы синтез шел как надо - мультициклы всякие, конвейеры вводить, в общем, боролся за скорость из-за одного узла.

Конечно, можно было бы сформировать задержку на ячейках (там допуск приличный) и зафиксировать их, чтобы времянка хотя бы от разводки не плавала, хотя это, имхо, грязный хак, так делать не хотел и не стал. Можно было бы завести два клоковых домена - один на 100 МГц, основной, другой на 200 МГц - для контроллера памяти. Наверное, это был бы самый правильный путь, но когда понимание пришло, уже было поздно, а дивайс и так работал. К тому же и тут даже на 200 МГц обращение составляет 3*5 нс 15 нс, а с синхронной - на 100 МГц за 10 нс. Более того, как показала практика, за 15 нс из Cyclone (спидгрейд 7) в 10 нс память слазить за 15 нс не удается - к 10 нс еще добавляются задержка от выходного триггера до пина, tCO, задержка от пина до входного триггера (при чтении) плюс tSU. Все это в сумме выходит за 15 нс, реально там минимально необходимое время было что-то около 16 нс. В итоге, сделано было на 160 МГц - 3*6.25 нс = 18.75 нс. Т.е. почти вдвое медленнее, чем в случае со 100 МГц синхронной памятью.

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

Тогда же четко осознал, что надо было применять просто синхронную память (с pipeline для скорости), с ней никаких проблем нет - на 100 МГц все работает без вопросов.

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

Конечно, на 40 МГц все гораздо проще, но и тут возни с задежками не избежать. Реализация по-любому сложнее выходит.

Что касается количества ножек на интрефейс с памятью, то оно где-то одинаковое что в случае с синхронной статикой, что в случае с асинхронной статикой, что в случае со SDRAM, и сооставляет примерно 40 ножек.

У меня K6R4016V1D-TI10 (256kx16bit, 10нс) тоже работает в синхронной схеме, цикл чтения/записи составляет 1 такт (и никаких фокусов на задержках тут нет!, все чисто) линий управления - 2 (WE и CS), работает все дело на 48МГц...

PS тоже пришлось бороться за скорость...
PPS сигнал WE формируется на двух T-триггерах у которых выходы проXORенные, а у одного из них противофазный такт:


Сообщение отредактировал -Al- - Aug 17 2006, 11:15