I am running the same program with the same overlay on the zcu104 board (in both pynq 2.5.1 and pynq 2.6).
The system has a video mixer IP that takes the background picture from an outside video stream. It has an overlay video stream input that comes from ps via a vdma. The video mixer has a 60FPS 1080p output similar to the background input.
There is no jitter is observable in v2.6
But in v2.5.1 it is showing garbage:
By a capture tool, I have found that in v2.5.1 there are two pictures coming in (one is completely okay and another one is just noise):
Just to give an overview:
I created a buffer using allocate function. Then I changed it through some OpenCV functions (for text adding). Then write it to the video mixer through vdma.
I already have tried even reducing the speed of the stream, there is always 1 good and 1 bad picture.
It would be nice if someone can give me some clue on how to avoid it or what has been changed in the memory allocation function from v2.5.1 to v2.6.
Custom DVI output, but it doesn’t matter. It happens after the video mixer output.
If DP I will highly expect driver issue. Xilinx DP do got all kinds of unexpected things.
Can you do a bypass sanity test on the video incoming to the capture whatever you capture from?
input output through fmc. No storage is used except the vdma. The background stream doesn’t have any effect unless overlay is turned on in video mixer. It is already checked that, the error coming after videomixer through a ila.
Usually the VDMA will strip the main memory and make the part out of the CPU usage.
So if the memory allocation setup is wrongly define in the dtsi or the fsbl.
There will be unexpected overcrossing.
I have encounter this once when a custom Ubuntu image is build from ZYNQ and DDR3 is 512MB rather than 1G and ends up the CPU write to same video memory location.
I would have suspected that too. But in this case, v2.6 is working okay with same program so i suppose it is kinda related to the implementation of the libraries. I have seen a similar problem with v2.7 and unfortunately, there was no solution.
Nah, V2.6 V2.5 V2.7 all build from different environment. So dtsi or fsbl might modified. But usually this is not the case. So VDMA driver should always the one to be blame here. So from what you share, looks very much it is a XLNX driver bugs?
Or tricks can be made in the OPENCV.
I am not sure OPENCV is a HLS github generate IP? or a software OPENCV?
aka: Vitis_Libraries/vision at master · Xilinx/Vitis_Libraries · GitHub
If you use hard OPENCV HLS IP, make sure it is aligned with the Vitis version.
If you used soft OPENCV, make sure the Linux is aligned with the python version.
Other than that I have no clue to share much.
Ofcourse, all the versions has different environment. Also, i have modified the dtb through custom dtsi according to the need. Both v2.5 and v2.6 has been checked out. It has no effect.
The problem between v2.7 and v2.6 was moving to xrt (as far as I remember, because of that it was too slow that my program could not coping up). But I can’t figure out the difference between v2.5 and v2.6.
Software opencv, vision library yet not support adding text.
Gesss, software OPENCV, then better use alternative rather than stuck with OPENCV. Making things work on software level is much easier than finding the root cause on software.
Ha Ha may be @stf could help out.
Also it doesn’t related to opencv, because even there is nothing in the buffer, the effect is still there. I just tested.
This feel very very puzzle. This give me a strong feeling on the DDR memory eye is not open or open very small making signal integrity very bad.
Otherwise this will never happen.
Can you try back off the DDR4 memory speed?
I have tested the program on the default image for zcu104 v2.5.1 and v2.6 without changing anything. Just for your information. It behaves the same as building the image from scratch. In v2.5.1 this effect always appears whereas in v2.6 doesn’t.
Question could be why version 2.5.1. Because for yocto build there is no recipe for v2.6 or v3.0 yet . It also would be nice if someone could help me to transfer the recipe for v3.0.
I understand that. But if I were you, I will try slow down the DDR4 clock speed.
As I have no study on ZYNQ Ultra-scale DDR4 memory training cycle. So if the Linux do undergo that training procedure and this could be the case.
From the info you providing, looks like after 2.5 they fixed the DDR4 training producer to stabilize the main memory?
It looks like this is show a good explain here.