flicker in CVO -> CVI -> MIXER -> CVO to output screen

[Altera_Forum]

hi,  

 In my VIP chain I'm mixing two video streams (one 800x600 and one 640x480) and then clocking out the mixer output to screen.   The two streams going into the mixer are setup such that:   1) tpg1 -> framebuffer -> mixer_din_1 (800x600)   2) tpg2 -> deinterlacer -> cvo -> cvi -> mixer_din_2 (640x480 overlay)   and the mixer output data is set such that:   mixer_dout -> cvo to output screen(800x600, using 40MHz clock)   Eventually I'm going to replace the tpg's and also I'm going to place a custom ip between the cvo -> cvi ip's, but for the timebeing they'r directly connected.    The problem is that the 640x480 testpattern flickers on the output screen when using this setup. When turning off the 640x480 layer I get an steady output 800x600 @ 60Hz.  I tryed removing the cvo -> cvi and connect the deinterlacer directly to the mixer_din2. This helped as the 640x480 flickering disappeared from the output screen.    Still I need help to figure out how to make the cvo -> cvi part work properly. I tryed increasing the size of the cvi fifo inorder to avoid overflow, but this did not remove the flickering.     Would really appreciate some help, thanks

[Altera_Forum]

hi again,  

 I have some update with regard to the cvo -> cvi issue.   It seem I was using a 40MHz clock for both the cvo and the cvi when clocking the 640x480 format, when infact the pixel clock for the 640x480 @ 60hz should be 25.175Mhz.    So now I'm using 25.175MHz for the cvo. For the cvi I'm using different clocks for the video input (25.175MHz) and the video output(40MHz).   Although the 640x480 overlay flickering is now almost gone, the 800x600 output flickers after a couple of seconds and also there is some distortion at the top of the video output (seems like a couple of the top lines have been shifted to the left).   If someone can help me out here, it would be greatly appreciated

[Altera_Forum]

Hello, 

 If I get this right, there are two CVOs in this system. The first one after the deinterlacer is configured for 640x480 @ 60Hz with a 25.175MHz clock. The second one for the output screen configured for 800x600 @ 60Hz with a 40 MHz clock.  There is no apparent mechanism in the second path (cvo -> cvi -> mixer_din_2 -> cvo) to do frame rate conversion. This means that you will get some flicker if the two clocks (25.175MHz and 40 MHz) are independent. If these clocks are not synchronized they will drift apart and you will get an overflow or an underflow at some point. Assuming this is the issue, it can be fixed by adding a triple buffer in front of mixer_din_2. Longer FIFOs will just delay the problem since you really need something that will drop or repeat a frame when the two clocks have diverged too much.  Hopefully the frame buffer in front of mixer_din_1 will not be needed in your final design so making this change will not be too expensive in terms of resources and memory bandwidth usage.  vgs

[Altera_Forum]

Hello again, 

 I noticed from your screenshots that you seem to be running the Video IP cores at the same clock rate as the input and/or output clock rates? This is fine most of the time because of the blanking periods in video streams. Nevertheless, it could help to run the Video IP datapath slightly faster to smooth the throughput. If you have a 50MHz clock available you could try to use it.

[Altera_Forum]

hi,  

 vgs, your right about there being two cvos in the system and your comment/solotion to the flickering seem reasonable to me. I'll try placing an tripple buffer in front of the mixer_din_2 and hopefully this will provide the neccessary framerate convertion in the system.    With regard to the video stream going into the framebuffer in front of mixer_din_1, the idea is that the cpu in the system is going to generate a 800x600 video stream.  Will it be sufficient to insert an "On-Chip FIFO memory" between the cpu (using avalon-mm interface) and the mixer_din_1(using avalon-st interface) in order to feed the clocked video output to the screen ??   regards saber890

[Altera_Forum]

> Will it be sufficient to insert an "On-Chip FIFO memory" between the cpu (using avalon-mm interface) and the mixer_din_1(using avalon-st interface) in order to feed the clocked video output to the screen ?? 

 You will probably not be able to get the data rate you need from the CPU so a triple buffer would be necessary.  Alternatively, I think what you are trying to do can also be done with the Frame Reader Video IP. You can prepare an image in one buffer in external memory by writing into it with the CPU and direct the Frame Reader to fetch the frame from it once it is done. You can then prepare the future frame into a second buffer and so on... This is probably a bit harder but this could be quite useful if you want to have an animated logo at a decent frame rate for instance because the CPU would just have to update a small portion of the output at a time.

[Altera_Forum]

--- Quote Start ---  I'm going to place a custom ip between the cvo -> cvi ip's  --- Quote End ---  Have you considered creating your own custom VIP component so that you don't need to use the extra cvo and cvi? This would probably make the clocking and throughput issues a lot simpler.

[Altera_Forum]

hi,  

 and thank you for your replies.   Kevin, the reason that I'm using "cvo -> custom_ip -> cvi" is that the cvo provides the sync signals on separate wires to the custom_ip. The custom_ip is also using separate sync signals.    Are you saying that I would'nt need tripple buffering infront of the mixer_din_2 if the "cvo -> custom_ip -> cvi" part is replaced with an custom VIP component using embedded sync signals ?   Regarding the clocking and flickering issue I was getting, I placed a tripple buffer infront of the mixer_din_2, as vgs suggested, and it worked out as the flickering on the screen dissappeared.    regards saber890

[Altera_Forum]

I can't say for sure, but I suspect if you removed the extra CVO/CVI and created a custom VIP component for your custom IP that you could get rid of the extra frame buffer. If you dropped the extra CVO/CVI you remove the need for the 25.175Mhz clock so you shouldn't have to worry about the two clocks being locked anymore. 

 If you already have your custom IP developed and the memory bandwidth and FPGA resources to spare, it may not be worth the work to convert it to a VIP component.