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

Используйте 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

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

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]

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

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

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

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

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

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

[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