Категорически приветствую, тов. плисоводы!

Сабж: подружить кмос-камеру mt9d111 от Aptina со стандартным digital camera интерфейсом, тот что v_sync, h_sync, pix_clk и d0...d7 с плисиной типа MAX II или 4-м циклоном (что под рукой есть), чтоб оная швиденько закидывала 16-битные слова в 16-битную статическую память. Камера выдает 2 клок-такта на пиксель c периодом такта 12-13нс (~80МГц), за каждый клок она выдает 8 бит информации с параллельной шины. 10-наносекундная статика подключена по стандартноу 8080 интерфейсу. Т.к. плисы я пока раскуривал на уровне начальных шажков типа "помигать светодиодиком", и никак не могу привыкнуть к ее "параллельности" процессов после армов, встал вот такой вопрос:
Можно ли физически реализовать след. алгоритм работы сих девайсов:

Сначала камера выдает v_sync (начало кадра)+h_sync (начало строки) и далее 2 такта на пиксель. после выставления v_sync ставим А0...А19 линии памяти в начало (0х000), WE=1, CS=0, OE=1. Далее пока h_sync=1 (читаем строку) по 1му клоку p_clk кладем 1й байт в рег-защелку d0...d7 линии данных памяти, по 2-му клоку одновременно кладем 2й байт в рег d7...d15 и выставляем строб WE=0. Первый пиксель готов. Далее начиная со 2го цикла пикселя:
-по 1му клоку пикселя сбрасываем WE в 1,пишем 1й байт в рег-защелку d0...d7 линии данных памяти, инкриминируем адрес+0х01;
-по 2му клоку пикселя одновременно кладем 2й байт в рег d7...d15 и выставляем строб WE=0.
.... ну и так далее N раз до конца считывания. Т.е. по идее клок пикселей тактирует все процессы в ПЛИС (так ведь можно?)

Вопросы: 1. теоретически можно ли сделать алгоритм "проглатывания" 1го цикла чтения пикселя, чтобы плис не щелкала адресами? 2. Будет ли такая схема работоспособной?
Знаю что можно сделать на том же арме, но тогда скорости уже другие, да и физически в проекте у меня не получается, слишком заморочено.
P.S. SDRAM не предлагать, я с ней ни разу не работал

Заранее благодарю!

Привет.

По идее все правильно.
1. Тактирует клок из камеры.
2. По поводу не щелканья, не понял сути вопроса.
3. Должна работать.

Только один вопрос, а что потом с данными собираешься делать. Которые в статике.

Суть проста: каждый цикл чтения пикселя из камеры (2 тика) в первый тик инкрементирется адрес статики и убирается строб записи, во второй выставляем остатки данных (см. выше) и подаем строб записи. НО, в самый 1й цикл инкрементировать по 1му тику адрес статики не надо, т.к. стартуем с 0х000. В от и вопрос: как сделать так, чтобы 1й цикл чтения был уникальным, грубо говоря...

Потом вытаскиваю неторопясь данные и делаю DSP.

Зачем?
По кадру стартуйте с адреса 0xFFFFF и инкрементируйте всегда одинаково.

Ага, спасибо! Я правильно понимаю что после инкремента 0xffff на еденицу регистр в плиске автоматом сбросится в ноль?

100% сбросится если перед инкрементом установите его в максимально возможное значение.
В Вашем случае это 0xFFFFF, а не 0xffff.
А0...А19 это 20-ть линий адреса.

Тьфу, точно же!Сказывается пятница, мозги кипят Спасибо, буду пробовать!

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

На 4-ом циклоне умножителей достаточно, даже для Н264 кодирования на лету. Да и вообще ресурсов.

Вы это проверяли в "железе"?
Какие результаты получили?
Какие параметры кодера Н264 использовались?
Какое видео поток по разрешению кодировали?
Что действительно в реалтайме без задержек?
Наверно хоть какая-то статическая задержка на несколько тактов имеется или и ее нету?
Какую ПЛИС использовали и на какой частоте работала, сколько логики было "скушано" и какой?

Стоп, стоп, зачем допрос такой. VHDL корка, которая уже обсуждалась, заняла менее половина SmartFusion A2f500. Пиксель клок вышел 145 Мгц. Считаем, для означенной 2 мег. матрицы это порядка 70 фпс. Накладные расходы на NAL не считаю - их удобнее имхо реализовывать в процессорном ядре того же Смартфузена. Ну а на 4-ом циклоне НИОС. Пока все на стадии собранного макета и запущенной матрицы - синки идут, клоки,тестовая таблица. Копая Модельсим - надо наверстывать упущенное. Но в том, что означенные параметры достижимы на 2 мега - сомнений нет у меня. Про задержку не понял, там на несколько кадров задержка, а не тактов

Да, имеют, но у меня потребность быстро свалить кадр в ram, а потом его обработать, через DMA получится медленнее. Да и потом во-первых для самообразования, во-вторых под DSP я подразумеваю обработку изображений с выделением контуров, горизонтов и т.д.

это не допрос, просто любопытство


если задержка на несколько кадров, то уже не совсем реалтайм ("на лету")

PS Просто подумал, что Вы свою корку написали ...

Не, латентность и риалтайм в данном случае совершенно невзаимоисключающие вещи. Входной FPS ессно равен выходному.

это понятно
иначе ооочень много памяти надо или потери кадров будут ...

Вот кстати о памяти, не так много SRAMок, имеющих время доступа в 10-20 нс.
У ТС такая или более распространенная в 50-70 нс?
Во втором случае, боюсь ему не успеть записать данные.

у ТС

+++++++

Вот ВСЕ это тоже интересно. Если не сложно, поподробней...

Повторю. Код отсюда http://sourceforge.net/projects/h264vhdl/
Скомпилировал в Libero. Убедился, что ресурсов за уши. Собрал такой "стендик", это 5-мег сенсор, завел по командный канал по i2C, получил ответную синхру и поток YUV. Ну а дальше разборки с шиной AXI, ибо гонять такие объемы все же надо уметь, ну и с Modelsim. Не все сразу, по ка что на практике саму корку кодера я не запускал.
Это M2S050 http://www.microsemi.com/products/fpga-soc...#product-tables , 56,340 LUT , 72 умножителя + простенький Cortex M3 на 166 МГц

Прикольный у вас девайсик Я так понимаю это для потокового кодирования видео?

Ну да. Хотя пока что и jpeg достаточен. Все это работает на Ti Davinci , dm368, но есть желание таки загнать все в фпга.