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

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

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

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

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

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

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

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

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

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

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

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енные, а у одного из них противофазный такт:

Насколько я помню 4016 - это 256Кх16.


Каким образом формируете сигнал nWE? В цикле записи он должен как минимум два раза сменить уровень - сначала уйти в 0, потом вернуться в 1. Итого, два транзишна, т.е. при синхронном дизайне надо два такта.

Или по обоим фронтам клока работаете? Если так, то для этого надо, чтобы ПЛИС это умела. Умеют это далеко не все, Cyclone не умеет. Про Спартанцев не помню. В любом случае это уже дополнителные нюансы.


Это еще одна причина, почему удается. Попробуйте перейти хотя бы на 100 МГц, результат будет другой.

Да, ошибся, это 256Кх16.

По обоим фронтам клока работаю, это проходит по крайней мере на ACEX 1K и MAX II. Как формирую - в предыдущем посте в PPS (добавил)

Большие частоты не нужны, по крайней мере пока. С асинхронной памятью с 10нс циклом предел - 50МГц.

Даже на 48 МГц? Ну, это может разве от того, что ACEX - помедленнее он Cyclone. Хотя 48 МГц совсем уж небольшая частота даже для ACEX.


Т.е. триггеры эти располагаются в ядре, не в IOE? Тогда еще добавляется дополнительная задержка на разводку от логики, где out до соответствующего элемента IOE. Это еще скорость придавливает. И еще дополнительная нехорошесть - задержка эта может весьма меняться от сборки к сборке (как трассы лягут). Хотя тут уже можно законстрейнить. Я всегда скоростные синхронные сигналы пропускаю через триггер в IOE, так наружу они выходят с минимальным перекосом.

Кстати, тут еще одно просматривается - в сигнале out могут быть (и обязательно бывают) "иголки". Память, видимо, это спокойно переносит, но все равно это нехорошо, имхо.

В общем, с синхронной памятью никаких этих вопросов нет, работать с ней проще и скорости значительно выше. О чем и говорилось исходно. Единственный ее минус - потребляет она почему-то заметно больше, мне это зачастую критично - есть дивайсы с автономным питанием. Иногда ее можно заменить на SDRAM (которая потребляет заметно меньше), но, к сожалению, не всегда.

вообще то насколько мне кажется по моему скромному мнениЮ - направление движения и скорость определяется по суммированию двух кадров - у вас вычитание - не могли бы дать ссылку на алгоритм по вычитанию кадров - или вам просто нужно изменение в кадре зафиксировать?

48МГц потому, что для CY7C68013A это предельная частота работы, ну и вся остальная схема на этойже частоте крутится.

Триггеры не в IOE да и как их оба туда запихнешь? Перекос и иголки не важны для асинхронной памяти.

Потребляет больше, а мне нужно чтоб было как можно меньше, девайс от линии (USB) питается. К томуже синхронная память подороже будет....

Хм, иголки на сигнале WE вполне могут быть важны. Это зависит скорее от конкретной микрухи - Ваши, очевидно, нормально терпели. В доке есть спецификация времянок, ее нарушать нельзя, иначе микросхема находится не в режиме. А раз не в режиме, то производитель ничего не гарантирует (вплоть до сгорания с дымом ). Лучче так не делать.


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

На SDRAM нужно контроллер городить, а места в ПЛИС и так под завязку. Да и не нужны такие объемы памяти.

Для K6R4016 иголки не важны ;) тем более эти иголки могут быть только рядом с переходами ( 0->1, 1->0 ) и микросхема на них никак не реагирует, главное чтоб на WE потенциал держался не менее 10нс (для данной конктретной микросхемы), а это условие выполняется.

Не вижу причин не использовать SDRAM ... А по поводу "огород городить" - пара десятков строк кода VHDL и несколько процентов ресурсов самого маленького чипа SPARTAN - на мой взгляд. (поскольку выборка попиксельно-построчно без всяких наворотов) Зато память существенно дешевле и есть возможность для дальнейшего развития обработки и для хранения кадров - ведь объемы у СДРАМ не маленькие...

2Flanker:
А что за память конкретно используете, и в каких корпусах?

Микросхема WS512K32V-15G2UMA. Есть и BGA и CQFP68. Для асинхронной памяти объем 512К, шина 32р, быстродействие 15 нс и расширенный температурный диапазон -55...+125 довольно большая редкость. Нашли только у одной фирмы WEDC (White Electronic Design) www.wedc.com. Цена конечно кусачая - больше 13 тысяч рублей за корпус, но игра на тот момент стоила свечь. Правда в новом проекте собираюсь ставить SDRAM.

неееее.... это уж слишком.....

А может кто присоветовать память с минимальным потреблением, тактовой частотой не менее 120 МГц, объёмом 128 Mb или больше, индустриальным диапазоном температур (от -40) и легко доставаемую в малых количествах? Я нашёл только мобильные SDRAM от Micron, хочется какой-то подстраховки.
И почему у всех творческая мысль остановилась на SDRAM? Сейчас же всякие DDR и прочее.

Samsung?

Не-а, они от -25. Хотя очень симатично, цоколёвка та же, и есть чипы чуть пошустрее, чем у Micron.

К вопросу об объеме памяти - а разве есть постребность "видеть" отдельно каждый пиксел? Если задача сводиться только к определению - есть ли изменение в кадре или нет, то в общем случае надо определиться с:
1. допустимый уровень шума (если это не синтезируемая в цифре картинка, то он обязательно будет);
2. разрешающая способность "наблюдателя" (например, меняющиеся объекты менее 32х32 не воспринимаются).
Как вариант, можно было бы предложить следующее:
захватывать несколько строк во внутреннее ОЗУ, вычислять по ним некую функцию (некое подобие сжатия по алгоритму JPEG) и во внутреннее же ОЗУ писать результат этой функции.
На следующем кадре - та же история и сравнение не попиксельно, а результатов функции.
Может оказаться, что внутреннего ОЗУ будет вполне достаточно.

Ну, это просто. Контроллер для SDR SDRAM несколько проще, SDR SDRAM требует только одного питания и DDR SDRAM экономит только пины на устройстве, ничего по скорости она не добавляет.

IMHO, DDR память получит широкое распространение тогда, когда появится достаточное количество 2.5В периферии. На данный момент это самая большая проблема, поскольку надо разделять банки на ПЛИС, городить дополнительные источники питания и т.п. В наших реалиях, когда за минимальные деньги надо слепить устройство с максимальными характеристиками - это не допустимо.