Доброго времени суток!
Я совсем новенький в теме 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 или они независимые?
Очень много вопросов.
Надеюсь не нарушил никакие правила и не задал слишком нубских вопросов.
Принимаю любую критику, ссылки на учебники, уроки, советы, наставления. Ответы на любые вопросы, какие сможете или хотите ответить. Заранее спасибо.

Готов выполнить за вознаграждение!

Да, это так.

Посчитайте битрейт. Вероятно, будет сложно реализовать передачу на комп в несжатом виде. Например, через 100 Мбит/c гарантированно не пролезет. Зависит, конечно, от разрешения и частоты смены кадров.
Как правильно упаковать картинку. Зависит от того, чем вы её собираетесь на компьютере отображать. Если своими силами, то просто сложите картинку в пакеты, снабдив служебной информацией начала-конца кадра. Если сторонними плеерами, то есть и стандартные контейнеры. По FreeRTOS есть подфорум, там по сетевым протоколам можно найти массу информации. Мне представляется разумным сжать видеопоток в MJPEG (есть готовые ядра opensource) до разумного битрейта (50-80 Мбит/c). Для стрима по UDP тоже есть доступные ядра, но можно стримить процессором. Многие плееры (например, VLC) спокойно воспроизводят MJPEG по UDP.


Исходный битрейт: 752 * 480 * 60 * 8 = ~170 Мбит/c. В принципе немного. По 1G сетке спокойно можно переслать.

Выполнение не надо, надо самому обучиться, за сколько вы можете меня проконсультировать и обучить базе, конкретно на этой задаче?
x736C большое спасибо за ответ, уже какие то вопросы закрываются.
Пока самое узкое и непонятное место - это взаимодействие с DRAM, DMA, DCMI. Может вы можете меня послать на верный путь?

Может, это поможет? https://www.xilinx.com/support/documentatio...ver-IP-zynq.pdf
Сама сейчас грызу...

Лично с Вами (ТС) связаться можно?

Большое спасибо, почитаю на досуге. Сейчас кстати смотрю видео на ютубе https://www.youtube.com/user/mamsadegh2/videos.



Не знаю можно ли тут публиковать свои данные, личное сообщение послать не могу, ну лады. мой мейл ilya94prok@mail.ru

1) Проще всего подключить по параллельному интерфейсу... Если по LVDS, то придется городить десерилизатор (там скорее всего последовательно данные идти будут).
2) Готовые ядра есть, но лучше писать самому IP-ядро (на мой взгляд), оно должно принимать данные от матрицы и управлять ею, и на выход выдавать поток видео в AXI Stream.
3) Поток AXI Stream нудно подавать на настроенный контроллер DMA, не важно где он будет реализован. Настраивать его удобнее всего процессором, который выделяет память под буфферы в DDR и по прерыванию от IP-ядра управления матрицей сменяет их...

Остальное позже...

А как соединить IP ядро с конкретным портом, как его сконфигурировать? Есть документ или урок, где это делается?
Вот получается у меня есть справа порты, которым надо назначить конкретный физические выводы. Где об этом почитать?

правой кнопкой мыши create port
затем его соединить в констрейнах с физическим пином

Спасибо за последние ответы.
Вновь прошу помощи.
Данные не проходят блок "Video in to Axi 4 Stream".
Имею камеру MT9V034 данные идут по параллельной шине DATA(7:0), PXCLK, LINE_VALID (активный сигнал - 1), FRAME_VALID (активный сигнал - 1). На вход подаю тактирование я взял с FCLK1 - 13.3333 МГц.
У ядра "Video in to Axi 4 Stream" имеется входы vid_data(7:0), vid_active_video, vid_field_id, vid_hblak, vid_vblank, vid_hsync, vid_vsync, vid_io_in_clk, vid_io_in_ce, vid_io_in_reset.
В документации написано используйте сигналы sync или сигналы blank. Непонятно как из LINE_VALID, FRAME_VALID создать vid_hblak, vid_vblank или vid_hsync, vid_vsync. пробовал по-всякому. Частоту FCLK1 менял в большую и и меньшую сторону.
В Вивадо отладчике пытаюсь посмотреть что приходит на входы и что на выходе блока.
Но отладчик показывает вообще какую то чушь!!! смотрю на осциллограф, там нормальная картинка, как и должно быть.
Что я делаю не так? Кто посоветует.
Может влиять длина проводников на такой частоте (13,3333 МГц)? Около 10 см.
Прочел темы:
https://forums.xilinx.com/t5/DSP-and-Video/...ace/td-p/517557
https://forums.xilinx.com/t5/Zynq-All-Progr...ht/false#M15677
https://forums.xilinx.com/t5/Zynq-All-Progr...-IP/td-p/531275



Вот запись с лог. анализатора
1

2


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

Оставляю для Вас личное IP-ядро с исходниками, которое работает с видео-декодерами (правда только с компонентой яркости).



Сигналы DE и HS в Вашем случае можно объединить. Отдаю с исходниками - разберетесь, будут вопросы - буду отвечать...

Огромное спасибо! Сейчас буду пробовать.

С вашим ядром уже какие то данные идут!
Это то что на входе:

Это то что на выходе:

Данные все время меняются, то есть что то идет!
Вот только я не понял - почему сигналы тактирования в нуле? ila2 - это то что на входе тактируется PXCLK - 13.3333 МГц. А ila1 - это то что на выходе тактируется FCLK0 - 100 Мгц.
В этом самом дебагере не получилось запуститься по тригеру никаким сигналом (пробовал по переднему фронту TVALID, TREADY, TLAST). Нормально ли это? То есть я так понимаю эти сигналы зависят от следующего ядра (у меня AXI DMA)
Еще не получалось долго проивезти имплементацию, ругался на vid_io_in_clk (это который PXCLK - 13.333 МГЦ), я в Constraint прописал set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets vid_io_in_clk_IBUF].
Может ли это как то помешать?
А так большое спасибо за помощь!
Еще вопрос - как определять начало кадра и иницировать транзакцию DMA? Я пока вижу так - подключить сигнал tuser к прерыванию - в обработчике прерывания иницировать передачу DMA - в первый раз. А далее иницировать уже в прерывании по DMA. Как посоветуете?

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

Добрый день. Вы уверены, что правильно назначили сигналы на пины? Может ошибка где-то закралась... Тактовые частоты на сигналы дебаггера не заводят - это плохая практика... У них цепи распространения разные и в Вашем случае синтезатору приходится перекидывать клоковую цепь на сигнальную - от этого и может ругаться.
Посмотрите осциллом - выходит ли тактовая на камеру... посмотрите, не нужно ли разрешать работу камеры где-нибудь в ее настройках... Камера скорее всего имеет встроенный PLL - посмотрите, какие настройки ему выставлены.
Начало кадра (в соответствии с AXSI Stream for Video) - один строб на сигнале TUSER. Я работаю с DMA так: процессором сконфигурировал его для приема линии, ядро отдало линию - получаю прерывание от DMA о том, что линия уложена в память, даю команду ждать следующую и т.д. Но тут как кому удобнее. Дело в том, что DMA определяет конец данных по сигналу TLAST - а это (по AXSI Stream for Video) сигнал окончания строки, по этому мне так удобнее.

Еще такая тема с чушью лог.анализатора - там в списке ядер их 2 штуки - system ila и обычные. У меня были глюки с системным. Попробуйте заменить.

Я весь дизайн не смотрел - но есть 2 пути инициализации транзакции - первый это самописный мастер, который передает данные в область памяти DDR и дергает прерывание процессору.
Второй это ядро по-моему AXI VDMA - с ним не работал, надо курить.

А процессор работает на бареметал, пингвинах или фриртос или что?

Пропускная способность AXI от PL до DDR через AXI_HP порт составляет 1200 МБайт в секунду - это частота 150 МГц при ширине шины в 8 байт. У себя делал такое, правда на 100 МГц у меня получилось грубо говоря на 1000 слов 1100 тактов передачи - т.е. на 10% ниже. Таких портов 4 штуки...