FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6355 Discussions

VIP build to build CVI stability

Honored Contributor II

I'm building a VIP system that includes four video pipes that run simultaneously. Each pipe is displayed in a quadrant of the output display but one or more of the images is unstable. Each build produces a different result with the artifact changing which quadrant(s) it effects and how severe it is. Typically it's only one pipe but we have seen it show up on two. Using the IP in v11.0 we narrowed this down to an overrun in the CVIs FIFO. The youtube link below demonstrates a more severe version of the defect. 




We updated to v12.1 in order to take advantage of the video monitor tool and the artifact changed. As you can see in the video we are losing pixels causing the image to slowly shift left. (This makes sense if you're getting a FIFO overrun. Pixels come in but have no place to go so they get lost.) In v12.1 the shift goes to the right implying too many pixels are coming in. We instantiated the monitoring tool and it agreed that the CVI is producing a larger data packet than it's supposed to. (Control packets are fine.) How much longer varies per build. Looking at the status bits in the CVI indicates that the video coming in is stable so we aren't feeding it the wrong number of pixels. 


In both the v11.0 and v12.1 projects I can use a video switch, positioned immediately after the four CVIs, to move the input to a different pipe and the artifact follows the CVI indicating that it isn't a problem with the block providing back pressure but the CVI itself. Also of note is that we're using the CVI in dual-clock mode. The input clock varies depending on the source but the output clock is a fixed 160MHz. (We've increased it to 200MHz as well but the speed has no effect.) Doing a diff between the v11.0 and v12.1 CVI source it appears there was a change to how FIFO overflows are handled so it could be the same defect manifested in a different way due to the slight changes in the code. 


The artifact is also temperature dependent. That, coupled with the build to build variation, leads me to believe there's a timing problem but I'm not seeing anything in the tools to indicate as such. We're pretty much out of ideas at this point. Any assistance would be greatly appreciated.
0 Kudos
1 Reply
Honored Contributor II

It's tough to diagnose a tricky problem like this one. 

It definitely sounds timing related. 


Have you read through this nice timequest tutorial 



You might want to go though it and make sure your SDC file 

fully constrains all your clock domains and I/O. 


Other than that, maybe you can try signal tapping your fifos 

for your video quadrants and try and determine if they 

are under / overflowing and ferret out the cause of this 

if for some strange reason it is not timing related.
0 Kudos