12-18-2014 11:03 AM
I and my coleagues are having trouble with syncing an axi4s to video out after we added a VDMA for triple buffering in the system, in which we also have an OSD. I've been searching the forums for a while and I found this post which appears to be roughly the same issue, but we still haven't been able to make sense of it. So, to quote from that post:
- Clocks, resets, and clock enables - Checked, they appear to be connected properly
- Make sure to generate BOTH syncs and blanks out of VTC and connect them to AXI Stream to Video Out - They are being generated and properly connected.
- When VDMA or TPG in the path, use master mode for the AXIS to Video Out and do not connect the gen_clken to vtg_ce - We are in master mode and vtg_ce is tied to vcc
- Check for locked status of VTC and AXI Stream to Video Out - We can see VTC generating sync signals through chipscope (fsync, vsync, hsync and active_video, consistent with the set resolution (720p60), however AXI stream to video out generates no sync signals
- VTC generator should run at pixel clock that vid_io_clk is connected to on AXI Stream to Video Out - Checked
- Probe VTIMING, AXIS, and video out interfaces on the AXI Stream to Video out core to make sure you are getting properly formatted data on all interfaces
What we see on chipscope is that the OSD (that is getting data from the VDMA) is feeding data to the axi4s to video out, until the latter de-asserts the tready signal. We are using master mode and the FIFO size for the axi4s to video out is 2048. What we understood from the documentation is that in master mode, the axi4s will read from the FIFO until it receives a SOF and then waits for the VTC to send the corresponding signals so that it can start sending data. VTC generates the signals, but the axi4s video out never drives tready high again.
Any suggestions on how to debug this further? I'm also attaching the mhs file.
12-22-2014 01:42 AM
A short update: we managed to get the axi4s video out to consume the input data by applying datapath only constraints to the ucf file. Now the problem is that the vtc is set for 720p60 and correctly provides 60 fsyncs in one second, but the VDMA is only sending 30 SOFs in one second (we're in 422 mode). It also triggers sof_early_err on mm2s channel.
The next step is that we will disable s2mm channel and write a pattern to the frame buffer then use chipscope to analyze the data sequence.
We are still in fsync mode, why do you think it might help to be in freerun mode?
12-22-2014 03:53 AM
Ok, another update: The VDMA outputs the data correctly but after about two lines and a half (2851 pixels), it gets throttled by the OSD. The OSD however behaves oddly.
If the VDMA output (and consequenlty the OSD input on layer two) is:
p1, p2, p3, p4, ...
The OSD output is:
p1, p1, p1, p2, p2, p2, p3, p3, p4, p4, p4... (notice that the third pixel - and every third one afterwards - is repeated only twice)
The OSD is configured from software with three layers, from which only one is enabled, and the screen resolution is set to 1280x720.
12-22-2014 06:11 AM
For reference, this is how the OSD registers are written:
OSD Error register not 0: 0x00000060 OSD Register 0: 0x00000003 OSD Register 0x4: 0x00020003 OSD Register 0x20: 0x02D00500 OSD Register 0x28: 0x00000000
OSD Register 0x110: 0x00600202 OSD Register 0x114: 0x00000000 OSD Register 0x118: 0x02D00500
OSD Register 0x120: 0x00600003 OSD Register 0x124: 0x00000000 OSD Register 0x128: 0x02D00500
OSD Register 0x130: 0x00600102 OSD Register 0x134: 0x00000000 OSD Register 0x138: 0x02D00500
OSD Register 0x140: 0x00000000 OSD Register 0x144: 0x00000000 OSD Register 0x148: 0x00000000
OSD Register 0x150: 0x00000000 OSD Register 0x154: 0x00000000 OSD Register 0x158: 0x00000000
OSD Register 0x160: 0x00000000 OSD Register 0x164: 0x00000000 OSD Register 0x168: 0x00000000
OSD Register 0x170: 0x00000000 OSD Register 0x174: 0x00000000 OSD Register 0x178: 0x00000000
OSD Register 0x180: 0x00000000 OSD Register 0x184: 0x00000000 OSD Register 0x188: 0x00000000
12-30-2014 07:30 AM
I'm a colleague of @Anonymous. We managed to fix the problem by putting the VDMA in free running mode on the MM2S side. This is a solution @bwiec has been recommending all over the forums, and it is a necessary condition for locking the axis to video out module. However, it has never been explained exactly why this condition is necessary. Here is my take on it:
The axis to video out module is very particular in the way it does its synchronization between the timing signals from the VTC and the AXI Stream interface. From my simulations of it, it seems that the synchronization sequence goes something like this:
1) wait for a negedge on vsync or vblank, while not reading from the AXIS input
2) read and discard the contents of the AXIS input fifo, waiting to find a SOF on TUSER
3) once a SOF on TUSER has been found, wait for another vsync, and then declare lock
During this sequence the length of lines and the frame on the two interfaces are probably being checked agains each-other. The axis to video out module will block the axis interface for various lengths of time before achieving lock. Meanwhile, if the VDMA is in fsync mode on the MM2S interface, at every frame period it will restart frame transmission with a new SOF, even if the previous frame has only partially been pushed into the video pipeline. Therefore, the SOF signal will appear to the axis to video out module to occur more frequently than expected, preventing lock.
@bwiec Is my assessment of the causes of this problem correct? Given the frequency of this problem on the forums, could you have the documentation of the axis to video out module ammended to make it clear how the VDMA should be configured?
01-12-2015 12:25 PM
Yeah, your explanation of the behavior sounds about right to me.
How to handle synchronization to an external fsync signal is somewhat explained in PG044 where it actually shows the VTC sync'd to the external fsync and the VDMA still free-runs. This would be the recommended approach for this case.
Of course, if you don't need it to be sync'd externally, then just free-run is fine.
Sorry for the trouble this caused!
02-15-2016 08:29 AM
For what i remember, also the OSD like to work in free run, because when it finishes to process a frame, it asks the source to start again to buffer some pixels internally.
If the VDMA is in free run it's not a problem, but if it's in frame synch mode, no pixels can be retrieved from memory until a fsynch arrives...and it lose the lock.
The OSD cause also latency problems when the VDMA is free-run and slave: when it finishes to read a frame from memory, it starts again immediately because the OSD asks for new pixels and probably the VDMA will read the same frame again.
02-23-2016 04:36 AM
There is any chance that this OSD behavior will be corrected in future releases of Vivado?
It's very annoying to introduce latency because of some pixels buffered before needed....