04-02-2018 01:12 PM
I have a design that will buffer more than 32 video images, so I'd like to try to reprogram the VDMA S2MM for every image. According the pg020, as soon as the VDMA starts to write an image, I can reprogram the starting address and vsize for the next image. I'm not exactly sure how to know when that time is; I think that the IRQDelayCount might be the way to go, but the description seems awful vague to me. The counter begins counting when it receives frame sync, and resets with the subsequent s_axis_s2mm_tvalid. There is no mention of what we are counting - is it just clocks after fsync?
What I am hoping is that after fsync, it counts out IRQDelayCount clocks, then fires the interrupt. However, I never see an interrupt, so I think that I'm doing something wrong.
My S2MM CR value is 0x08002001 - IRQDelayCount 8, Delay count enabled. The S2MM is synchronized to tuser. I know that the interrupt output and S2MM are connected because I get transfer errors if I misprogram the registers.
Will IRQDelayCount generate the interrupt that I need, and if so, how do I get it to work?
04-04-2018 12:31 PM
I don't think the DlyCnt_IRQ is useful in 'fsync on tuser mode' because fsync event happens when tvalid=1 and tuser=1. So it resets immediately.
I would just use the FrmCnt_Irq (of course, set it up to issue an interrupt every frame).
In 'fsync on tuser mode,' FrmCnt_IRQ interrupts happen on tuser. By the time you service the interrupt, the VDMA will be happily transferring the current frame and you have the entire frame period for the software to calculate and re-configure for the next frame.
04-04-2018 12:58 PM
Can I use the frame count interrupt without setting frame count enable? When frame count enable is set, the transfer ends when the frame counter reaches 0.
" (FrameCntEn) Configures the S2MM channel to allow only IRQFrameCount number of transfers to occur. After the IRQFrameCount frames are completely transferred, the S2MM channel halts, DMACR.RS bit is deasserted, and the DMASR.Halted asserts when the channel has completely halted."
04-05-2018 05:08 AM
Thanks for all the suggestions. I will go back to look at the frame count interrupt without the halt. My original plan was to halt at the end of every image, then reprogram and restart before the next image started. But reading PG020, I saw that the VDMA could be reprogrammed as soon as it began processing the current image; that is a great feature!
When I was using the frame count interrupt with halt, the interrupt didn't occur until the fsync of the next image. Too late to reprogram for the second image.
I had considered using tuser directly, but I assume that there is some latency between when tuser && tvalid && tready is asserted and when the VDMA actually starts a cycle and is OK for reprogramming. It would be just my luck that I'd occasionally start programming at the wrong time.
My twist on your suggestion is to use the fsync_out signal. I use it to set a flip-flop which is monitored by a microBlaze through a GPIO. When the signal goes high, the microblaze reprograms the VDMA and uses a GPIO output bit to clear the signal. That whole transaction takes a little over one image line of time. Once I work out the kinks I can convert to being interrupt driven and try out the AXI interrupt controller.
However, if I can just work with the interrupt features of the VDMA, I'd prefer that.
I'll mark your last suggestion as the acceptable solution to close this case.
04-05-2018 08:34 AM
Okay, that sounds good. Let me know if you run into any other issues.
Right, many of our video IP take care to double-buffer config registers that would have detrimental effects if changed in the middle of the frame. They commit the new settings only on frame boundaries.
Yeah exactly. It's a little quirk of the VDMA that the interrupt happens on fsync event which is often start of frame instead of at the end of the frame (there's an AR on it somewhere). So that wouldn't work if you're parking the VDMA between frames.
I had considered using tuser directly, but I assume that there is some latency between when tuser
&& tvalid && tready is asserted and when the VDMA actually starts a cycle and is OK for reprogramming.
When using 'fsync on tuser mode,' the registers should be committed exactly when tuser && tvalid && tready == 1 so I wouldn't expect there to be a possibility of issue here.
05-30-2018 02:16 PM
I'm also not clear on the use and behavior of the vdma IRQDelayCount. As Jospeh asked above, what is being counted?
Is it counting clocks? pixels? lines? frames? Or something else? What is the intended use?
07-29-2020 01:47 AM - edited 07-29-2020 01:47 AM
"DlyCnt_IRQ is not useful in 'fsync on tuser mode' " , infomation lile this is strongly recommended to explicitly added in pg020.....
The time the intrp go out is a little bit vague.... in pg020. We took a lot to debug .