Добрый, спасибо за ответ)
Сигналы AVInClk, AVInVS, AVInHS точно правильно назначил на физические ножки. С данными если и будет путанница, то потом разберусь.

Вот с клоковыми сигналами я не до конца понял. Мою камеру надо тактировать извне от 13-27 МГц. Соответственно этот клок надо вывести из Zynq. Я просто вывел тактовую FCLK1 - 13.333 МГц на физический пин. С этим проблем нет. Осциллографом глянул - такт есть.
Синтезатор ругается на физическую привязку к пину (vid_io_in_clk) сигнала AVInClk, то есть на входной клок от камеры. Я в констрейнах прописал set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets vid_io_in_clk_IBUF]. Он перестал ругаться. Но не притянет ли это дополнительные проблемы?
А как тогда в дебагере посмотреть как данные проходят, если не привязываться к клоковым сигналам?

Камера тактируется извне... Сигналы связанные с AXI Stream Master - будут зависеть от принимающего блока (у меня AXI DMA), я имею ввиду, что пока я не сконфигурирую DMA - он не будет принимать данные, и соответсвенно - шина будет статична? или данные независимо от DMA будут идти вникуда?
Второй вопрос - как мне поймать начало кадра? По сигналу TUSER - но если шина статична - то сигнал TUSER не появится, так ли это? В дебагере в предыдущем посте я вижу именно, что шина не работает, данные статичны.

Все правильно, значит пин не клоковый... Пока это не страшно.


Именно так!

Но Вы можете проанализировать поведение внутренних цепей ядра...

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

Спасибо за помощь)
Я так понял у меня обычные ila. так как нигде не видно приставки system. Но хотелось бы удостоверится, где посмотреть?

Да я еще слишком неопытен, чтобы писать свое ядро, поэтому использую обычный AXI DMA, возможно возьму AXI VDMA. По идее мне надо просто сложить данные с камеры в DRAM. Но надо как то поймать начало кадра, чтобы первые данные в DRAM были именно с первого пикселя, а не с середины кадра.

Сейчас работает на бареметалл, по мере усложнения проекта перейду на FreeRTOS, так как имел с ней опыт на STM32.

Да я думаю с пропускной способностью проблем не возникнет - камера 752*480 пикселей, монохромная, то есть один пиксел - 1 байт. всего 752*480*1 = 360 960 байт - один кадр. Хочу разогнать до 60 фпс. Итого 21 657 600 байт в секунду. Итого около 20 Мбайт/сек.


Вот спасибо еще раз, вы меня прям сильно выручаете!
Тогда у меня вопрос - как отследить начало кадра?
Есть такой вариант - сначала настроить DMA, чтобы он ожидал данных. А потом подать клок на камеру. тогда автоматом первые пиксел кадра будет первым в памяти DRAM?
А можно в DMA длину всего кадра заказать? а не одной строки?
И еще вопрос - лучше самому в регистры записывать или использовать готовые функции из BSP?

Ну тема такая - для бареметал все просто - у вас есть физический адрес буфера в памяти, его можно сделать кольцевым или несколько штук. Дальше передаете этот адрес ядру ДМА, он передает данные, дергает прерывание и вы ему адрес заменяете или он сам показывает адрес последней транзакции.
Если будут пингвины, то нужно маппировать физические адреса на виртуальные и гуглите nmap
НАсчет фриртос не знаю.
Сам делаю похожую задачу))

Мастер акси 4 не такой сложный, тем более что вам нужно только сделать запись. Начните с передачи слова, потом добавьте счетчик слов и все норм

Это нарушит стандарт AXI Stream for Video!

Можете отдельно ответвить от шины TUSER и завести его как прерывание. В софтварной части Вы должны распределить память под кадр, в начале работы указываете ДМА первый адрес и длину строки - он положит туда одну строку (не обязательно первую, но это не срашно - см. далее), по прерыванию от ДМА задаете ему новый адрес - смещенный на длину строки первый, опять запускаете его записью длины строки, опять прерывание и т.д.
НО!!!! По приходу прерывания от TUSER (прокинутого как прерывание) сбрасываете указатель на начало распределенной памяти - таким образом следующая запрошенная строка ОБЯЗАТЕЛЬНО будет первой в распределенной области (и естественно первой в кадре...) т.е. все совпадет!

Спасибо. Да TUSER завел как прерывание, тоже так хотел сделать. Теперь раз мысли совпали, так и сделаю

Опять нужна помощь(
Данные c ядра AV2AXISV_0 дальше не идут. DMA не дает сигнал tready. Я так понимаю в этом проблема.
Но почему он не дает сигнал готовности принять?
Читал несколько раз даташит на DMA AXI ядро. Написал в ручную регистры, которые надо заполнять. проверил - заполняются правильно. DMA стартует и останавливается (биты в нужных регистрах устанавливаются и сбрасываются). Но по факту ничего не происходит, в прерывание не заходит. Ни в DMA, ни в TUSER. То есть мое подозрение, что слабое место в связке между AV2AXISV_0 и DMA.
Вот дебаггер:

Вот код


Сообщение отредактировал ilyaprok - Nov 15 2017, 15:42

Для быстрой проверки: отключите TREADY от DMA и подайте на него "1". Посмотрите как работает шина!
Я дал Вам ядро, что бы разобраться, возможно сходу с Вашей камерой оно и не будет работать...
Обратите внимание на модуль AVInput внутри ядра - там есть константы, они для видеодекодеров, для Вашей камерв могут не подойти.
Обратите внимание на то, как используются и комбинируются входные сигналы.
Будет не понятно - спрашивайте.




Инициализация DMA



Установка прерывания (контроллер прерываний должен быть уже настроен)



Разрешение прерывания от DMA





Обработка прерывания с запросом очередной порции данных

Попробовал tready подтянуть к 1. Вот скрин дебагера:

TUSER - вообще странно появляется, не привязан ни к чему.
Если я поменяю константы в файле AVInput.v на нужные, заработает ли правильно ядро? Не понятно что за параметры F1_START_LN, F2_START_LN, F1_END_LN, F2_END_LN ? никак не могу понять, у меня есть сигналы FRAME_VALID, LINE_VALID - их подключать к сигналам AVInVS и AVInHS соответсвенно? или они не связаны?
Внутри даташита на MT9V034 есть такая таблица:

Есть датаграмма снятая с физических портов камеры:

Если я перепишу параметры в AVInput, заработает ядро? Или тут надо логику переписывать? Может тогда проще по LVDS линии соединится?

Вообщем вернулся к первоначальному варианту с VideoIn To AXI4 Stream.
сигналы с камеры завел так:
hblank = ~LINE_VALID
vblank = ~FARME_VALID
active_video = LINE_VALID&FARME_VALID
tready на AXI шине поставил в 1.
Снял датаграммы:
Это то что на входе ядра - сигналы с камеры

Это то что на выходе ядра на AXI шине

Кажется что работает.
Теперь соединил tready к DMA.
Сигналы с камеры по прежнему идут.
А на АКСИ шине ничего нет, сигнал tready из DMA все блокирует.

Сообщение отредактировал ilyaprok - Nov 16 2017, 08:04

tvalid очень странно себя ведет..

Если ДМА блокирует - значит количество принятых данных не совпадает с запрошенным! Посмотрите статус ДМА - там в этом случае должна быть выставлена ошибка.

Добился того, что DMA делает несколько транзакций - всегда разное кол-во от 1 до 11 примерно и возникает внутренняя ошибка DMA Internal Error. This error occurs if the buffer length specified in the fetched descriptor is set to 0. Also, when in Scatter Gather Mode and using the status app length field, this error occurs when the Status AXI4-Stream packet RxLength field does not match the S2MM packet being received by the S_AXIS_S2MM interface. Я так понимаю из-за того, что размер пакета измеряемый сигналом TLAST не соответсвует (больше/меньше) длине в регистре 0х58.
Я делаю так:

То есть в прерывания заходит, но потом спустя несколько транзакций происходит эта ошибка. Я использую обычный AXI DMA. Сейчас попробую AXI VDMA.

AXI VDMA можете не пробовать - не тратьте время....
Разберитесь с сигналами - они явно не в порядке...

хорошо, спасибо. А что не так с сигналами? Как должно выглядеть?

Если запустить лог анализатор в вивадо на по фронту TREADY и при этом запустить прогу в SDK, то пооучается вот это:

В SDK при этом DMA совершает 1-11 транзакций по 752 байта, и останавливается по внутренней ошибке.
То что я совершаю транзакции по 752 байта - эта одна линия, это нормально? TUSER вообще никогда не появляется. Изменяя 752 байта в большую сторону, ошибок не возникает, но в лог анализаторе такая же картина.

Сообщение отредактировал ilyaprok - Nov 16 2017, 10:41

Я давал Вам свое ядро, что бы Вы могли там сигнальчики посмотреть и если что - обсудить... Вы уверены, что длительность строки у Вас правильная (а не плавает из-за каких-либо факторов)?
Все-таки рекомендую Вам сначала удостовериться, что все сигналы от камеры правильные и Вы четко понимаете их длительности и соотношения!
Нужно было бы добавить счетчик по стробу данных в строке и посмотреть, сколько их реально приходит - не плавает ли... Как соотносятся стробы кадра и строки и т.д.