[Flip-fl0p 4]

Но проблема в том, что сами данные с камеры еще до поступления в v_vid_in_axi4s_0 какие то неправильные. Почему то теряются такты. То есть вместо 752 - 751, 749 тактов. Причем это происходит когда подключена линия данных. когда ее нет - то сигнал LINE_VALID ровно 752 такта.

Скорее всего как раз дело в неправильном приёме данных.

Обратите внимание на страницу 35 даташита на камеру. Там Th и Ts всего по 14 нс. Велика вероятность того, что либо клок где-то в ПЛИС задерживается, либо данные. Нужны правильные входные констрейны.

 

[toshas 0]

Vivado ILA может работать некорректно если частота jtag сравнима с частотой на которой ведется захват.

https://forums.xilinx.com/t5/Simulation-and...p/760288#M18214

Кроме того, если сама по себе частота jtag высокая тоже может сбоить

https://forums.xilinx.com/t5/Welcome-Join/i...-p/425710#M8730

так что поставьте "с запасом" 3 или 6 МГц.

 

Когда вы отключили линии данных, проект заработал ? На экране по идее должен был быть просто черный квадрат.

[ilyaprok 0]

Скорее всего как раз дело в неправильном приёме данных.

Обратите внимание на страницу 35 даташита на камеру. Там Th и Ts всего по 14 нс. Велика вероятность того, что либо клок где-то в ПЛИС задерживается, либо данные. Нужны правильные входные констрейны.

Спасибо за подсказку, да я посмотрел. Но я так полагаю 14 нс - это для максимальной частоты тактирования 27 МГц, при частоте 13,3 МГц - минимальные Th и Ts около 30 нс. По идее входящие с камеры сигналы идут только в одно ядро на прием, то есть я хочу сказать, что этот клок привязан к узкой области внутри кристалла и не должен затрагивать много цепей и терять синхронизацию. Но я лишь могу на это надеятся.

Может входящий клок с камеры перемапить на другой пин, потому что Вивадо ругается без этой директивы set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets vid_io_in_clk_IBUF], а из-за нее возможно теряются такты? Может такое быть?

 

 

Vivado ILA может работать некорректно если частота jtag сравнима с частотой на которой ведется захват.

https://forums.xilinx.com/t5/Simulation-and...p/760288#M18214

Кроме того, если сама по себе частота jtag высокая тоже может сбоить

https://forums.xilinx.com/t5/Welcome-Join/i...-p/425710#M8730

так что поставьте "с запасом" 3 или 6 МГц.

Вот интересное замечание, спасибо. действительно частота JTAG 15 МГц. Частоту поменял - ILA перестал выдавать ошибки! Спасибо большое!!!

Когда вы отключили линии данных, проект заработал ? На экране по идее должен был быть просто черный квадрат.

Хм, надо проверить. Спасибо. Отпишусь попозже

Изменено 17 ноября, 2017 пользователем ilyaprok

[Flip-fl0p 4]

На сколько я смог разобраться, в Xilinx можно с IO пинов завести сигнал в клоковый буфер. Посмотрите, может будет толк.

[ilyaprok 0]

Когда вы отключили линии данных, проект заработал ? На экране по идее должен был быть просто черный квадрат.

 

LINE_VALID четко 752 такта. На линии данных FF. Подсоединяю 4 линии данных , такты теряются.

обратно убираю все линии данных. Но в программе после перегона 1-2 строк у DMA внутренняя ошибка. То есть DMA даже не может всю картинку в память перслать.

 

 

На сколько я смог разобраться, в Xilinx можно с IO пинов завести сигнал в клоковый буфер. Посмотрите, может будет толк.

А как это сделать? я вообще нуб.

[Flip-fl0p 4]

А как это сделать? я вообще нуб.

С xilinx не работаю. Не знаю. Попробуйте посмотреть: https://www.xilinx.com/support/documentatio...es_Clocking.pdf

[ilyaprok 0]

С xilinx не работаю. Не знаю. Попробуйте посмотреть: https://www.xilinx.com/support/documentatio...es_Clocking.pdf

Спасибо за ссылку, посмотрю.

 

ILA тактируется от FCLK1 - 13.33 МГЦ. JTAG - 6 МГЦ. Теперь лог анализатор работает без ошибок.

Сигналы vid_io_in_clk и clk_cam смаприровал на clock capable pins, теперь вивадо не ругется и директива CLOCK_DEDICATED_ROUTE FALSE не нужна.

Притянул все линии PULLDOWN.

После этих изменений ситуация чуть улучшилась (в основном из-за PULLDOWN).

Теперь если отключить всю линию данных - то DMA без ошибок передает FF. То есть теперь транзакции и длина пакетов правильные, В лог анализаторе - действительно ровно 752 такта. То есть черный экран должен быть, если бы я визуализировал картинку.

 

Как только подключаю от 4 и более линий данных - DMA останавливается с внутренней ошибкой на 1 - 1000 транзакции.

 

Решил проверить на что влияет подключение линии данных. На PIXCLK или SCLK.

Так как ILA теперь тактируется от FCLK1, я вообще отключаю от ZYNQ PIXCLK (сам провод) и смотрю сколько тактов длина LINE_VALID при подключенной линии данных. Такты гуляют. То есть получается, что поключение к ZYNQ линии данных влияет на выходящий из ZYNQ клок для тактирования камеры Либо подключение линии данных к ZYNQ как то влияют на процессы внутри камеры, из-за чего она выдает неправильные сигналы

Причем если бы были завалены фронты LINE_VALID, то в лог. анализаторе я бы видел, что линии данных и LINE_VALID сигналы где то остают, где то опережают друг друга - а они синхронны.

То есть либо идет влияние на SCLK, либо через линии данных ZYNQ портит процессы синхронизации в камере, но это невероятно.

 

Я в тупике, может кто то найдет ошибку в моих рассуждениях? Или кто то с таким сталкивался? Может длина проводов на таких частотах мешает?

Изменено 18 ноября, 2017 пользователем ilyaprok

[toshas 0]

Так как ILA теперь тактируется от FCLK1, я вообще отключаю от ZYNQ PIXCLK (сам провод)

 

Это неправильно, pclk для того и нужен, что имеет правильную фазу по отношению к данным,

хотите перейти на внутреннюю частоту - ставьте асинхронное фифо с записью по pclk и чтением по FCLK1.

 

Если проект полностью работает без линии данных вообще или при подключенных 2-3х, а при подключении 4-5 падает,

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

Модуль я так понимаю с ebay/aliexpress, так что только автору модуля известно, что там с терминированием на линиях данных, фильтрацией питания и прочим.

[Flip-fl0p 4]

А выводится картинка куда должна ? Через HDMI на монитор ?

[ilyaprok 0]

Это неправильно, pclk для того и нужен, что имеет правильную фазу по отношению к данным,

хотите перейти на внутреннюю частоту - ставьте асинхронное фифо с записью по pclk и чтением по FCLK1.

Да это так, но само ядро на которое идут данные с камеры тактируется PIXCLK, а ILA тактируется от FCLK1 и не привязано к PIXCLK. Я таким образом проверял потерю тактов. Сейчас верну тактирование ILA на PIXCLK.

Если проект полностью работает без линии данных вообще или при подключенных 2-3х, а при подключении 4-5 падает,

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

Модуль я так понимаю с ebay/aliexpress, так что только автору модуля известно, что там с терминированием на линиях данных, фильтрацией питания и прочим.

Плата с алиэксперсса это вы правильно подметили. Схему китайцы не дают. Если мне уже третий опытный человек говорит сделать нормальный монтаж - это я точно сделаю. Придет макетка - чуть лучше сделаю монтаж. Но как терминаторы поставить? Одной точкой на линию данных, другой - на землю? То есть 8 линий данных + 2 такта + 2 синка. на каждую линию по резистору? По сколько Ом? На камере и на плате ZYNQ? Я просто ни разу не видел терминаторы на параллельной шине, на дифференциальных видел.

Посмотрел еще несколько схем с этой камеры - нигде терминаторы не ставят. Фильтры по питанию есть, но это стандартный набор.

Извините за такие вопросы, если есть куда послать поучится - ткните пальцем.

А так бошльшущее спасибо форумачанам за помощь и советы. Особенно svedach, toshas, Flip-fl0p!

 

А выводится картинка куда должна ? Через HDMI на монитор ?

Пока никуда. Надо еще как то начало кадра словить. Сигнал TUSER - слишком малой длительности похоже - и АРМ его не успевает заметить.

Потом когда нормальный поток видео будет транслироваться в DRAM - его уже по UDP буду передавать. А на компе визуализировать. Но это лишь для отладки 30 фпс хватит, чтобы просто удостоверится что картинка годная.

Изменено 18 ноября, 2017 пользователем ilyaprok

[svedach 0]

Извините, не было возможности писать...

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

 

 

[ilyaprok 0]

Извините, не было возможности писать...

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

Спасибо, да вы советовали до этого. Я им Воспользовался - стало получше! Это вы хорошо подметили! Спасибо еще раз :)

На текущий момент - ситуация такова. На плате камеры стоял кварцевый генератор, он тактировал камеру вместо SCLK. Но после покупки я генератор сразу выпаял.

После того как я выяснил, что наводки идут имеенно на SCLK. Я попробовал не тактировать камеру из ZYNQ. Припаял обратно кварцевый генератор. Теперь данные идут на частоте 26,6 МГЦ - 60 фпс. Без ошибок, DMA пересылает данные в память. В дальнейшем - я разведу плату получше и возможно верну линию SCLK, обратно выпаяю кварц, и буду тактировать ZYNQ'ом.

Сейчас пока данные идут без ошибок, хотелось бы получить картинку, НО прерывание по TUSER не вызывается. Я посмотрел в лог. анализторе - длительность в высоком состоянии сигнала TUSER всего 3-4 такта. Может стоит продлить сигнал - но ведь до вызова прерывания в DMA уже поступят первые несколько пикселей, то есть первые несколько пикселей в первой строке будут потеряны и вся синхронизацяи кадра тоже. Как стоит поступитть? как поймать начало кадра? Может все-таки VDMA?

Изменено 18 ноября, 2017 пользователем ilyaprok

[svedach 0]

Сигнал TUSER должен быть 1 такт! Если это не так - надо искать в логике обработки входных сигналов... Какое ядро для входа Вы используете сейчас? Посмотрите в даташите на него как оно формирует этот сигнал.

[toshas 0]

Если все синхронно, то 1 такта должно хватать.

Выложите полную картину вашего Block Design (File - Export - Export Block Design - pdf)

Вы не теряете строки, по прерыванию начнется обработка кадра с самого начала,

просто тем самым вы вносите некоторую задержку, хотите ее избежать стройте проект вообще без буферизации в DDR.

[ilyaprok 0]

Сигнал TUSER должен быть 1 такт! Если это не так - надо искать в логике обработки входных сигналов... Какое ядро для входа Вы используете сейчас? Посмотрите в даташите на него как оно формирует этот сигнал.

В идеале он 1 такт, но так как скорость поступления данных меньше, чем DMA их забирает. То длительность сигнала TUSER возрастает в 100,0МГЦ/26,6МГц - 3,75 раза. то есть 4 такта. Я сейчас использую Vide In To AXI4 Stream.

Вот его датаграмма (используется ILA тактируемое от FCLK0 - 100 Мгц):

На ней видно что сигнал прерывания от DMA около 30-60 тактов. Поэтому я сделал вывод, что может стоит продлить.

Есть проект с ядром AV2AXISV, но сигнал TUSER поймать у меня не получилось. DMA итакже работает без ошибок. Это ядро немного по-друггому генерирует сигналы AXI, я так понимаю логике работы шины это не противоречит и допускаются такие различия.

Вот датаграмма с ядром AV2AXISV:

Я полагаю надо поправить констанаты в файле AVInput.

 

Если все синхронно, то 1 такта должно хватать.

Выложите полную картину вашего Block Design (File - Export - Export Block Design - pdf)

Вы не теряете строки, по прерыванию начнется обработка кадра с самого начала,

просто тем самым вы вносите некоторую задержку, хотите ее избежать стройте проект вообще без буферизации в DDR.

Это проект с ядром Video In To AXI4 Stream.

Формировал сигналы hblank vblank исходя из даташита на камеру MT9V034 и документа "AXI4-Stream Video IP and System Design Guide" UG934 То есть hblank = ~LINE_VALID, vblank = ~FRAME_VALID, active_video = LINE_VALID&FRAME_VALID.

design_1.pdf

Изменено 19 ноября, 2017 пользователем ilyaprok