Доброго времени суток!
Я совсем новенький в теме SoC. Есть плата Z-turn и JTAG отладчик, все подружил, попробовал hello world.
Пока читаю книгу ZynqBook.
Есть задача:
подключить камеру MT9V034 к плате Z-turn. Хочу подключить по параллельному интерфейсу (PIXCLK, DATA(9:0), HSYNC, VSYNC), но можно еще по LVDS последовательному интерфейсу. Камера имеет разрешение 752х480 60 фпс, монохромная.
1) Есть ли у кого опыт пользования этими интерфейсами, камера будет в сантиметрах от платы, поэтому скорее всего LVDS помехозащищенность не нужна. И проще всего подключить по параллельному интерфейсу. Так ли это?
2) Далее надо организовать некий контроллер-приемник на стороне PL. Есть ли готовые IP-ядра для этого? В STM32 есть DCMI контроллер, есть ли здесь что то похожее?
3) Надо, чтобы контроллер-приемник передавал принятые байты DMA контроллеру, а он складывал в видеобуфер на стороне DDR. Какой DMA контроллер использовать, который реализован аппаратно в PS или нужно IP ядро?
4) Как организовать связку DMA контроллера и DDR памяти, нужно ли доп ядро DDR контроллера? Какие параметры нужно устанавливать для совместной их работы и как их настроить? После заполнения видеобуфера, надо чтобы сработало прерывание для ядра, чтобы можно было производить обработку, то есть ядро никак не должно участвовать в приеме картинки, такое возможно? Стоит ли писать по байтово в DDR или лучше накопить некую пачку и только потом записать? Какова пропускная способность всей цепи от DCMI контроллера до ячеек DDR памяти, потянет ли реал-тайм запись или нудны промежуточные буферы?
5) Я так понимаю нужно 2 DDR буфера -пока один постепенно заполняется, с другим можно работать, потом они меняются местами, правильно ли думаю? Как организовать доступ ядра к DDR памяти или я просто обращаюсь под выделенное для DDR памяти адресное пространство и DDR контроллер понимает, что это орбащение к DDR памяти и все организовывает сам?
6) После получения кадра, надо отсылать картинку по UDP на комп, где она визуализируется. Хочу писать в FreeRTOS, есть ли готовые функции для приема/отправки UDP пакетов, как они реализованы (блокируемые или по прерываниям)? Как правильно упаковать картинку для передачи по UDP.
7) Еще не понятна схема работы в Vivado и SDK. То есть в Vivado нужно нарисовать саму архитектуру системы, далее сгенерировать некий BSP. А в SDK с помощью этого самого BSP настроить периферию, записью в различные регистры. Правильно я понимаю?
8) Если я использую аппаратный SPI в PS, нужно ли мне генерировать Bitstream? Ведь По идее ресурсы FGPA не используются
9) Как взаимодействовать с кэшем различного уровня? Как правильно с ним работать? Интересует именно в BareMetal и FreeRTOS варианте.
И вообще вопрос как правильно разрабатывать на таком устройстве? То есть как переключаться между SDK и Vivado, в какую память шить? Какие тесты делать? Как лучше отлаживать в SDK или внешними утилитами? Какие подводные камни есть? на что стоит обратить внимание? Очень много настроек в PS, что можно менять и как они повлияют друг на друга? Можно ли часть настроек менять в SDK вместо Vivado или они независимые?
Очень много вопросов.
Надеюсь не нарушил никакие правила и не задал слишком нубских вопросов.
Принимаю любую критику, ссылки на учебники, уроки, советы, наставления. Ответы на любые вопросы, какие сможете или хотите ответить. Заранее спасибо.

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

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 МГц.

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

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



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

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

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

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

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



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

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

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

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

Это неправильно, 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 фпс хватит, чтобы просто удостоверится что картинка годная.

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

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

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

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

Сигнал 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.


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