cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
195 Views
Registered: ‎06-20-2019

AXI VDMA Latency

Hello,

I have a design where I utilized a VDMA IP. I have almost a nice output but I can see that some pixels are shifted. I have a doubt about the latency of the VDMA since I couldn't see a problem related to other IPs. Should I think about the latencies that is provided below during coding? I have chosen fsync as "s2mm_tuser" for write channel and "none" for read channel. Right now, I am writing to the VSIZE registers immediately and not waiting for these latencies. If I should consider these, I couldn't get how I am supposed to do that. Can you give a guidance? (at some point, I rewrite new values to the registers of VDMA since resolution changes)

 

Thank you for your time.

Selection_123.png
0 Kudos
3 Replies
Highlighted
Scholar
Scholar
177 Views
Registered: ‎03-28-2016

@yhy.xilinx 

In my experience, "shifted pixels" are not caused by VDMA latency.  It's more typically a result of a mismatch somewhere in the processing.  Make sure that your "Tuser" and "Tlast" signals are being handled correctly through out the processing pipeline.

As for the VDMA:

  • Make sure your linebuffers are large enough
  • Make sure the "M_AXI" bus data widths are wide.
  • If possible, use a faster clock for the "m_axi_*_aclk"s than for the "*_axis_*_aclk"s
Ted Booth | Tech. Lead FPGA Design Engineer | DesignLinx Solutions
https://www.designlinxhs.com
Highlighted
Adventurer
Adventurer
97 Views
Registered: ‎06-20-2019

Hello @tedbooth,

Thank you very much for your reply. I understood that the points you provided are related to the bandwidth. Right now, the design is working properly but I want to ask one more question. I am trying to implement dynamic resolution change using that vdma. As it is stated in the document, I am writing to stride and hsize registers first and then writing to vsize. When I let the design work on hardware, during transition, vdma is not giving data for almost 2 seconds. Then, it begins to give output at the new resolution value. Observing the new resolution output is great but that 1-2 sec. delay prevents me from finishing the project. If I do not write to the registers of vdma, it gives output at the current resolution value in a proper way, no problem. The issue arises when I lower/higher the resolution value. I don't know why. I believe I have a hint here. This ~2seconds duration does not happen all the time. It sometimes makes a smooth pass which I can ignore since a human eye almost cannot detect it. One other hint is that when I pass from 1280x720 to 180x320, it makes this smooth pass but not the other way around. I thought that the roi is being smaller but that is not the case. It doesn't make smooth pass from 1280x720 to 640x320(it rarely makes smooth pass in this case.) Do you have any idea about that?

Thank you very much.
0 Kudos
Highlighted
Scholar
Scholar
86 Views
Registered: ‎03-28-2016

@yhy.xilinx 

From you previous post, it sounds like you are using both Rd and Wr VDMA channels.  Are they "Gen-Locked"?  If so which one is the master?  When changing resolution sizes, do you have to change the resolution size in any other IP?  If so, do any of those IP have to "lock" to the new resolution?  The "Video_In_to_AXI4_Stream" IP has to relock when the resolution changes.  That "relock" can take several frames.  Do you have an external input source like a camera that has to change resolution?  Updating a camera can be hard to do quickly.

I would recommend just looking at the display section of the design first.  See if you can smoothly transition the display without the video input section running.  Once that works well, then look at doing the same with just the input section.  Once it works well then try both together.  There may be some kind of momentary memory contention that happens when the transition happens.

Ted Booth | Tech. Lead FPGA Design Engineer | DesignLinx Solutions
https://www.designlinxhs.com
0 Kudos