С 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 портит процессы синхронизации в камере, но это невероятно.

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

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

Если проект полностью работает без линии данных вообще или при подключенных 2-3х, а при подключении 4-5 падает,
то это явно проблемы с помехозащищенностью, пока не сдалаете плату переходник ничего не получится.
Модуль я так понимаю с ebay/aliexpress, так что только автору модуля известно, что там с терминированием на линиях данных, фильтрацией питания и прочим.

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

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

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


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

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

Спасибо, да вы советовали до этого. Я им Воспользовался - стало получше! Это вы хорошо подметили! Спасибо еще раз
На текущий момент - ситуация такова. На плате камеры стоял кварцевый генератор, он тактировал камеру вместо SCLK. Но после покупки я генератор сразу выпаял.
После того как я выяснил, что наводки идут имеенно на SCLK. Я попробовал не тактировать камеру из ZYNQ. Припаял обратно кварцевый генератор. Теперь данные идут на частоте 26,6 МГЦ - 60 фпс. Без ошибок, DMA пересылает данные в память. В дальнейшем - я разведу плату получше и возможно верну линию SCLK, обратно выпаяю кварц, и буду тактировать ZYNQ'ом.
Сейчас пока данные идут без ошибок, хотелось бы получить картинку, НО прерывание по TUSER не вызывается. Я посмотрел в лог. анализторе - длительность в высоком состоянии сигнала TUSER всего 3-4 такта. Может стоит продлить сигнал - но ведь до вызова прерывания в DMA уже поступят первые несколько пикселей, то есть первые несколько пикселей в первой строке будут потеряны и вся синхронизацяи кадра тоже. Как стоит поступитть? как поймать начало кадра? Может все-таки VDMA?

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

Если все синхронно, то 1 такта должно хватать.
Выложите полную картину вашего Block Design (File - Export - Export Block Design - pdf)
Вы не теряете строки, по прерыванию начнется обработка кадра с самого начала,
просто тем самым вы вносите некоторую задержку, хотите ее избежать стройте проект вообще без буферизации в DDR.

В идеале он 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.


Это проект с ядром 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.

Как вариант посмотрите как настроить прерывание не по уровню, а по фронту.
Можно сделать или через отдельный контроллер GPIO или вроде бы даже напрямую в контроллере прерываний.

Да настроил,спасибо. С помощью функции XScuGic_SetPriorityTriggerType.
Теперь все правильно работает. Остается как то скачать дамп памяти в файл и посмотреть. Пытаюсь через XSCT консоль - но не понимаю. Использую вот такую команду - mrd -bin -file mem.bin 0x01000000 360960. Но не понимаю где этот файл найти, или нужно сначала его открыть, потом записать, потом закрыть. А что за команды?

В TCL консоли вы можете понять в какой рабочей директории находитесь командой dir.

Спасибо!
получил первое изображение:

Вам toshas и svedach Большое Спасибо!!!! Я прям рад!
Однако вопрос возник - если идет запрос к DRAM памяти сразу несколькими мастерами как будет происходит чтение или запись? Можно например обращаться к памяти в DRAM, пока идет чтение или запись в тот же регион с помощью DMA? А если несколько DMA использовать - как они будут делить доступ?
И еще вопрос по поводу глобальных переменных - где они создаются в кеше? какого уровня?
И что означает эта функция, зачем очищать кэш?
Xil_DCacheFlushRange
Я использую по совету svedach

И еще получается 480*60=28800 раз в секунду вызывается прерывание по DMA, это же съедает много процессорного времени?

Добрый день! Поздравляю!
Xil_DCacheFlushRange - это сброс кешированных данных из кеша в ДДР. Как я смог разобраться, несмотря на то, что память распределена в ДДР, Цинк перегоняет данные в кеш, а потом как будет время - в ДДР. Эта команда заставляет его скинуть последние принятые данные в ДДР.