[ilyaprok 0]

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

Все-таки рекомендую Вам сначала удостовериться, что все сигналы от камеры правильные и Вы четко понимаете их длительности и соотношения!

Нужно было бы добавить счетчик по стробу данных в строке и посмотреть, сколько их реально приходит - не плавает ли... Как соотносятся стробы кадра и строки и т.д.

Понял.

Сейчас еще раз проверил в лог. анализаторе в Вивадо. Длительность строки проверил ровно 752 такта. Как проверял - 1 варинат: по тригеру FRAME_VALID запускал лог. анализатор. по маркерам точно выставлял границы фронтов сигнала LINE_VALID, в этой же датаграмме проверил 4 пачки. 2 вариант - также по тригеру FRAME_VALID запускал лог. анализатор выставил маркеры на гранциах фронтов сигнала LINE_VALID и раз 10 перезапускал лог. анализатор, смотрел, чтобы границы фронтов не съезжали от маркеров. Теперь я уверен, что LINE_VALID четко 752 такта. Также проверил промежуток от начала фронта FRAME_VALID до первого фронта LINE_VALID - четко 71 такт. Все как по даташиту на камеру.

Вот скрины лог анализатора

1

2

В прошлом посте я показывал картинку из даташита на камеру, там расписаны все тайминги, продублирую:

То есть сигналы с камеры четкие.

какие сигналы посоветуете еще посмотреть?

 

 

Еще такой вопрос, какое из ядер надо использовать? И не повлияют ли внутренние параметры, которые вы упоминали?

[svedach 0]

Используйте AV2AXISV.

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

[ilyaprok 0]

Хотя еще раз проверил, в лог анализаторе, некоторые строки разной длины, где то в середине кадра... буду проверять

 

Используйте AV2AXISV.

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

Спасибо, вот эти пареметры тоже надо поправить?

parameter ACT_VID_LEN = 11'd1723,

parameter H_BLANK = 11'd283,

parameter F1_START_LN = 10'd25,

parameter F2_START_LN = 10'd337,

parameter F1_END_LN = 10'd313,

parameter F2_END_LN = 10'd625

 

 

А что означают последние 4 параметра?

always @(posedge AVOutClk)

begin

ValuesCounter <= (AVInHSReg) ? (ValuesCounter + 1) : 0;

InBuff1WrE <= (InBuffSel == 0) && (ValuesCounter > 282-12) && (ValuesCounter < 1722-12) && YVld;

InBuff2WrE <= (InBuffSel == 1) && (ValuesCounter > 282-12) && (ValuesCounter < 1722-12) && YVld;

end

Это тоже надо поправить?

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

 

[ilyaprok 0]

Действительно примерно 1 из 5 случаев в лог. анализаторе Вивадо кол-во тактов линии LINE_VALID не 752, бывает 751, 749 и т.д. Это Связано с железом? или это глюки Вивадо? камеру менял, провода сократил, частоту менял 13,33 и 26,6 Мгц пропобовал, все одинаково.

[svedach 0]

Тут сложнее: это может быть проблема дебаггера, если Вы тактируете захват сигнала одной тактовой (например AXI), а сигнал передается на другой (частоте камеры), могут быть не правильно настроены входные пины (напряжения, подтяжки, терминаторы), может быть проблема железа - плохо пропаяно, или еще что-то такое. Можете выложить фото связи камеры с платой?

В любом случае надо сначала решить эту проблему, а потом двигаться дальше.

[ilyaprok 0]

У меня получается два отладочный ядра. Одно тактируется от AXI 100 Мгц. Для отладки АКСИ шины. Второе ядро тактируется от входящего с камеры клока 13,333 Мгц. Заметил, что никогда не бывает больше чем 752 такта, всегда либо ровно, либо чуть меньше. Доходило даже до 740 тактов вместо 752. Может физические пины не подходят, надо другие брать. Осциллограф у меня простой от USB, такие частоты на грани видит. А какие подтяжки нужны, может токоограничивающий резистор поставить на такт камеры?

[Flip-fl0p 4]

Ну хоть бы трубки термоусадочные на контакты надели, ну нельзя же так работать ! А если отвалится и замкнет что-то ?

Я вот всё смотрю и не могу понять, а куда данные с камеры выводятся потом ? На монитор через HDMI ?

[svedach 0]

Дааа, с таким монтажем далеко не уедем... Можете резисторы на землю (PULLDOWN) в настройках пинов ПЛИС выставить попробовать...

Напряжения согласованы (какие напряжения на пинах камеры и каким напряжением питается банк ПЛИС)?

[ilyaprok 0]

Каюсь монтаж ужасен, это временный вариант, пока нужный разъем не пришел, чтобы нормально плату развести.

Данные с камеры не выводятся, смотрю в отладчике в DDR и в отладчике в Вивадо, пока нормальные сигналы не получу, нечего выводить.

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[7]}]

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[3]}]

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[5]}]

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[1]}]

 

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[6]}]

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[2]}]

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[4]}]

set_property IOSTANDARD LVCMOS33 [get_ports {vid_data[0]}]

 

set_property IOSTANDARD LVCMOS33 [get_ports vid_line]

set_property IOSTANDARD LVCMOS33 [get_ports vid_frame]

set_property IOSTANDARD LVCMOS33 [get_ports vid_io_in_clk]

set_property IOSTANDARD LVCMOS33 [get_ports clk_cam]

 

set_property PACKAGE_PIN T11 [get_ports {vid_data[0]}]

set_property PACKAGE_PIN T10 [get_ports {vid_data[1]}]

set_property PACKAGE_PIN T12 [get_ports {vid_data[4]}]

set_property PACKAGE_PIN U12 [get_ports {vid_data[5]}]

set_property PACKAGE_PIN U13 [get_ports {vid_data[2]}]

set_property PACKAGE_PIN V13 [get_ports {vid_data[3]}]

set_property PACKAGE_PIN V12 [get_ports {vid_data[6]}]

set_property PACKAGE_PIN W13 [get_ports {vid_data[7]}]

 

set_property PACKAGE_PIN T14 [get_ports vid_line]

set_property PACKAGE_PIN T15 [get_ports vid_frame]

set_property PACKAGE_PIN P14 [get_ports vid_io_in_clk]

set_property PACKAGE_PIN Y14 [get_ports clk_cam]

 

set_property CFGBVS VCCO [current_design]

set_property CONFIG_VOLTAGE 3.3 [current_design]

Осциллографом уровни около 3,3 В, насколько позволяет посмотреть осцил.

Еще заметил, что если оставить только линии питания, LINE_VALID, FRAME_VALID, PXCLK, SCLK, и убрать все линии данных - то тактов ровно 752, если добавить еще 4 линии данных - то такты опять срываются.

PullDown в constraint сделать? А что за команда, не подскажите? set_property PULLDOWN TRUE [get_ports {vid_data[0]}] ?

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

[Flip-fl0p 4]

Тогда вопрос. А так ли необходимо применять процессор для приёма данных ?

[ilyaprok 0]

Тогда вопрос. А так ли необходимо применять процессор для приёма данных ?

В идеале вообще не применять проц, в идеале надо, чтобы данные автоматом складывались в DRAM. Но мне проще чтобы частично проц участвовал. Но суть не в этом же, я так понял, чт осигналы с камеры почему то не очень качественные...

[Flip-fl0p 4]

В идеале вообще не применять проц, в идеале надо, чтобы данные автоматом складывались в DRAM. Но мне проще чтобы частично проц участвовал. Но суть не в этом же, я так понял, чт осигналы с камеры почему то не очень качественные...

Для начала сделать нормальный монтаж.

Я бы вообще всё принимал при помощи ПЛИС. Организовал мост между ПЛИС и памятью на стороне CPU, которую бы использовал как кадровый буфер.

А если осциллографом глянуть фронты сигналов, они не слишком пологие ?

Изменено 16 ноября, 2017 пользователем Flip-fl0p

[ilyaprok 0]

Для начала сделать нормальный монтаж.

Я бы вообще всё принимал при помощи ПЛИС. Организовал мост между ПЛИС и памятью на стороне CPU, которую бы использовал как кадровый буфер.

Так и есть у меня проц участвует только в настройке DMA и в прерываниях настраивает следующую транзакцию. Вы это имеете ввиду?

Осциллографом не могу посмортеть - я бы и рад , но мой осилл слишком слабый, не видит он такие частоты адекватно.

 

Еще вопрос насчет отладки. Что нибудь меняю, в блок диаграмме или в контстрейнах. Далее прохожу всю цепочку - синтез, имплементация, битсрим. Если до этого лог. анализатор работал, то после новой комплиляции и заливки. Дебагер либо показывает ошибки, типа invalid <T> vector что то такое, либо No content в окне дебагера, либо ядер вообще не видет. Что я делаю не так? Если что то менять, как правильно проходить всю цепочку, чтобы отладчик не рушился?

[Flip-fl0p 4]

Так и есть у меня проц участвует только в настройке DMA и в прерываниях настраивает следующую транзакцию. Вы это имеете ввиду?

Осциллографом не могу посмортеть - я бы и рад , но мой осилл слишком слабый, не видит он такие частоты адекватно.

 

Еще вопрос насчет отладки. Что нибудь меняю, в блок диаграмме или в контстрейнах. Далее прохожу всю цепочку - синтез, имплементация, битсрим. Если до этого лог. анализатор работал, то после новой комплиляции и заливки. Дебагер либо показывает ошибки, типа invalid <T> vector что то такое, либо No content в окне дебагера, либо ядер вообще не видет. Что я делаю не так? Если что то менять, как правильно проходить всю цепочку, чтобы отладчик не рушился?

Я правильно понимаю что модуль v_vid_in_axi4s_0 находится на стороне FPGA ?

Если да, то каким образом обеспечивается правильный приём внешних данных ? Иными словами есть немалое подозрение, что проблема с метастабильностью из-за неправильного приёма/синхронизации внешних данных, асинхронных по своей природе с FPGA.

[ilyaprok 0]

Я правильно понимаю что модуль v_vid_in_axi4s_0 находится на стороне FPGA ?

Если да, то каким образом обеспечивается правильный приём внешних данных ? Иными словами есть немалое подозрение, что проблема с метастабильностью из-за неправильного приёма/синхронизации внешних данных, асинхронных по своей природе с FPGA.

Да правильно. У этого ядра есть два входных клока - один для внешнего интерфейса, как раз с камеры PIXCLK - 13,333 МГц. Есть тактирование для AXI шины - в моем случае 100 МГц. Этот блок расчитан для такой работы. Я так понимаю, что то типа асинхронного FIFO. Поэтому с этим проблем не должно быть.

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

Я еще раз проверю - попробую тактировать камеру от кварца, попробую тактирвать модуль от FPGA напрямую, без прослойки камеры, надо понять - где теряются такты, на линии SCLK (это линия от ZYNQ для тактирования камеры), на линии PIXCLK(это линия от камеры, это просто инвертирванный SCLK) или сам сигнал LINE_VALID - где то завален фронт.

Попробую у знакомых попросить осцилл и посмотреть.

Отпишусь сюда.

А сам лог. анализатор Vivado - может глотать такты?

Есть еще такая строчка у меня set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets vid_io_in_clk_IBUF] Без нее вивадо ругается на этапе имплементации:

[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.

< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets vid_io_in_clk_IBUF] >

 

vid_io_in_clk_IBUF_inst (IBUF.O) is locked to IOB_X1Y88

and vid_io_in_clk_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31

Может из-за этого такты теряются?

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