Какое ОЗУ выбрать для обработки видео?, Динамическое, статическое и сколько микросхем? Опции

[Гвоздик]

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

[Flanker]

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

[dxp]

Не знаю как синхронная статическая ОЗУ, я в проекте совместно со 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 ножек.

[-Al-]

С асинхронной тоже имели дело - иначе не писали бы. Да, работает она - куда ей деться, но с синхронной работать, во-первых, удобнее, во-вторых, она быстрее. Я делал честный синхронный контроллер памяти (поскольку внутри ПЛИС весь дизайн синхронный), который формировал сигнал 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енные, а у одного из них противофазный такт:

Код

pulse[].clk =( clk, !clk );
pulse[].( t, ena, clrn ) = ( vcc, en, reset );

out = pulse[ 0 ] xor pulse[ 1 ];

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

[dxp]

PS тоже пришлось бороться за скорость...

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

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

Код

pulse[].clk =( clk, !clk );
pulse[].( t, ena, clrn ) = ( vcc, en, reset );

out = pulse[ 0 ] xor pulse[ 1 ];

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

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

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

[-Al-]

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

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

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

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

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

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

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