VIP Control is Mutilating my Image!!!

[Altera_Forum]

Hello All, 

 I have an interesting problem. I've managed to put together a video processing path:  cvi->scaler->frame buf->cvo  Which works reasonably well scaling SXGA to SVGA for display on an LCD. Very simple. See 1st image below image.  i then add a nios2/e with the standard JTAG UART and sysid peripherals. For ease I'm using 4k of on chip ram. I've connected the control port to all the above blocks. For the result look at the 2nd image below.  This has only happened since upgrading my Quartus to 9.1. The sp1 upgrade did not fix the issue. It appears that instead of a line of 800 pixels arriving at the cvo, i'm getting 800 + n (where 5 > n > 10). This causes the square to be splayed diagonally. I've built this dozens of times with different size fifos on the cvo/cvi, and I think that my timing constraints are ok. See attached my sopc config.  If I reduce the incoming SXGA signal by a few pixels (never consistent between builds) then the image lines up again and looks normal. But resetting the sopc will cause the distortion again. It's like the sopc is auto-detecting x pixels each time it comes out of reset, and then outputting x + n.   Another note is that bit 10 of the cvi status register never sets - indicating that a valid resolution is never detected. My HS & VS signals are both logic +ve, and they only occur when the data_valid signal is 0 so they should be disturbing a frame. i've checked the data_valid window against the incoming pixel clock and it measures a perfect 1280px (or what ever I set the video to) and is stable with expected jitter and good amplitude.  Has anyone see this issue before? did any of the vip ip blocks change so significantly between 9.0 and 9.1 as to cause this issue?  All help greatly appreciated, thanks in advance. Cheers, Brent.

[Altera_Forum]

The frame buffer will write 4 pixels at a time. In other words, yes it performs efficient accesses. So right now I believe your pixels are 12 bits wide correct? The frame buffer would perform 5 pixels per transfer at 75MHz whereas right now you're only getting 2 at 150MHz. So you get 25% more pixels per access by using the half-rate controller. Again the tradeoff is the memory interface is twice as wide which means you use twice as many RAM blocks in the frame buffers for the FIFOs and your logic utilization will increase. 

 Also, your burst size of 256 seems excessive and can actually cause you problems in some cases. You don't want to starve the reader or writer because you've allocated too much time to each one.  Jake

[Altera_Forum]

Thanks for the info; I find timing issues to be far more scary than a few more ram blocks. I'll try 1/2 rate, and I'll reduce the bursting targets to 32. 

 I"ve just run a basic system that was generated on quartus 9.0sp2. It has CVI->Scaler->FB->CVO. There is nios2 control of the Scaler and it works fine! If I compare the SignalTap outputs from 9.1sp1 to the ones I've just made in 9.0sp2 I see that the former is reporting the pixel line length as 1273, and the latter is a perfect 1280. i now believe that even though 1273px are reported, 1280 are in fact being passed. this is causing elements downstream (mixer or cvo) to start a new line every 1273 pixels, but then a further 7 arrive before the real next line of pixels, causing a 7 pixels displacement for each successive line of pixels. Hence the 7 pixel skew.   I think there must be some significant changes to the CVI block in 9.1; it obviously doesn't like my input signals any more. But the scary thing is that they are completely vanilla - 1280x1024 60Hz with separate syncs! Nothing scary about that, hardly HD or anything exotic. My video decoder ASSP is the TI TVP7002, made by a bluechip company with a stellar reputation. I'd like to bring this to the attention of Altera, what is the best way to make a bug report?  I'll now add the rest of the blocks in the sopc and just get on with my application. I'll let you know if I re-introduce the bug. Thanks again for your help, I would be lost without it!

[Altera_Forum]

Brent, 

If you think you've found a bug, we need to report it up through the ranks. Actually, the CVI source code is accessible. Look in the "db" directory of your project. You should see a file named "alt_vip_Vid2IS.v". This is the source code for the CVI. Can you grab that file from both your 9.0 and 9.1 projects and send them to me? I can then see if I can find the problem and report it.  You can also file a service request if you think you've found something.  Jake

[Altera_Forum]

--- Quote Start ---  I think there must be some significant changes to the CVI block in 9.1; it obviously doesn't like my input signals any more.  --- Quote End ---    The change between 9.0 and 9.1 was that the Clocked Video Input (CVI) now checks the line lengths, both total and non-hblank, throughout the whole frame, not just during the active picture. I've seen DVI inputs where during the vertical blanking the timing on the hsyncs changes, this causes the CVI to detect a different resolution. The way to check if you have such a DVI input is to use signaltap to count the number of clock cycles between the falling and rising edges of the hsync signal during the vertical blanking.  The CVI needs changing to only check the active picture length during non-vertical blanking and the total line length during the whole frame. I'll take a look a what modifications you need to make to do this.

[Altera_Forum]

Brent, 

Gareth is the expert.  Jake

[Altera_Forum]

Hi Gareth, 

 Thanks for the help. I'll take a closer look at the hs width consistency both externally and with the SignalTap experiment that you've suggested first thing Monday.   I've seen a few industrial video cards that were design for CRT use that also act 'differently' during either the HS and VS blanking periods. One we saw a few weeks ago had a horizontal line frequency that varied greatly even on the active period of the frame. The monitor it was designed for had a very loose PLL that could track it, but when you try to put an LCD monitor in there a circle looks like an egg!   I think that these changes are not a great idea; a damn lot of PC video cards don't adhere to VESA standards and a lot of old industrial systems were made in pre-cambrian times and are all over the place. There is a lot of work in replacing obsolete monitors and video systems and I hope that I can use the VIP in these jobs to come.  Can I ask what benefits were Altera chasing in these CVI changes?

[Altera_Forum]

I've tapped the hsync input to the scaler and during the vblank period there is no change in the +ve or -ve duration of the hsync signal. I'm reading a +ve pulse width of 32px, and a -ve pulse width of 1666px - steady as a rock. From the outside, the signal is equally steady.

[Altera_Forum]

Jake, 

 Here are my two cvi sources, 9.1sp1 and 9.0sp2. I'm not very good with hdl, so I doubt I'll find much in there, but I'll give it a shot. Let me know if you find anything.  Thanks again. Brent.

[Altera_Forum]

--- Quote Start ---  I've tapped the hsync input to the scaler and during the vblank period there is no change in the +ve or -ve duration of the hsync signal. I'm reading a +ve pulse width of 32px, and a -ve pulse width of 1666px - steady as a rock. From the outside, the signal is equally steady.  --- Quote End ---    Do you mean the hsync input to the Clocked Video Input? The Scaler doesn't have an hsync input.  The difference I was referring to was the hsync timing in the vblank compared to the hsync timing in the non-vblank. If they are different the CVI detects a change in resolution and resets its counters e.g. if your non-vblank line length is 1650 and your vblank line length is 1698 (1666+32). It may be that this is not the issue that you are seeing but I thought it sounded similar.  The benefit of the changes is that you can know the total size of the frame so that you can distinguish between standards e.g. 720p60 has a total line length of 1650 and 720p50 has a total line length of 1980. Both have an active line length of 1280. The fact that the CVI resets its active line length if the vblank timings are different is a bug.

[Altera_Forum]

Hi Gareth, 

   --- Quote Start ---  Do you mean the hsync input to the Clocked Video Input? The Scaler doesn't have an hsync input.   --- Quote End ---    Yes, sorry - the CVI hsync input. I will have to re-check, as I only compared the length of the hsync pulse during the vblank period. Looking from outside the FPGA, the hsync period is consistent during vblank and non-vblank.   The changes are very very useful, and definately worth-while, I'm currently relying on polling the TVP7002 to detect a change in resolution, but with the new system it would be simpler. Being a know bug, do you know if this will be addressed in a future service pack?  Thanks for helping me out, it's great to have a good community to rely on.

[Altera_Forum]

--- Quote Start ---  Being a know bug, do you know if this will be addressed in a future service pack?  --- Quote End ---    I should be able to get a fix into SP2.

[Altera_Forum]

--- Quote Start ---  Looking from outside the FPGA, the hsync period is consistent during vblank and non-vblank.  --- Quote End ---    If this is also the case on the FPGA then I don't think you're seeing the issue that I was describing. If the vid_h_sync, vid_v_sync and vid_datavalid signals are consistent throughout the whole frame then there shouldn't be a problem using the 9.1 CVI.  The way to debug the problem is to look at the registers in the resolution_detection block within the CVI. The relevant HDL file is db/alt_vip_vid2is_resolution_detection.v. The registers that are of interest are:  next_active_sample_count[15:0] = next width active_sample_count[16:1] = current width active_sample_count[0] = current width valid update_active_sample  The way they work is that for every cycle your vid_datavalid signal is high next_active_sample_count has 1 added to it. At the end of every active picture line update_active_sample goes high and next_active_sample_count is compared with active_sample_count. If they are different active_sample_count is updated. The active_sample_count register is what drives the control packet width (after it's gone through some clock synchronization registers into the control block).

[Altera_Forum]

Hi Gareth, 

 I've finally burned down my list of things to implement, and i'm back where i started. I've tested the hs, vs, data_en and clk out of the video decoder and they are SOLID as a rock. there is no jitter or movement in the hs signal, neither within or outside a vs active period.   The issues I am seeing appear to be caused elsewhere. I'm chasing as many timing possibilities as I can; I'm only new to Timing Quest so it's slow progress. One interesting thing is that i've managed to introduce a bug where the vertical lines appear overlaid on the screen; while there is significant colour distortion (in Quartus 9.0sp2.) So I concede that there is definitely a problem with my video input, probably the same one I was seeing in Quartus 9.1sp1.   Also, I am now consistently reading these conditions from the CVI control port:  Status register = 0x9 - Running - Sample count valid - Line count NOT valid - Progressive - NOT stable  Used words: 0 or 1 only Sample count = 0x320 (correct for this test) Line count = 0   Does this give a fingerprint of a common issue? I'm going to pursue the internals though signal tap and will post more info later.

[Altera_Forum]

I seem to have fixed this issue by starting a new project and taking more care in importing my assignments. It looks like I was bringing in some undesirable detritus from an earlier and faulty project! I apologise to Altera for any insinuation of CVI bugs!

[Altera_Forum]

--- Quote Start ---  You're right. I appologize. I have a spreadsheet that I use for the memory bandwidth calculations but I had it set up for half-rate mode and you're running the controller in full-rate mode. Your bandwidth is 4.8Gbps which at 70% efficiency is 3.36Gbps. Sorry for the confusion.   --- Quote End ---    Hi, would it be possible for you to share this spreadsheet for calculating bandwidths?

[Altera_Forum]

The spreadsheet is already in the forum. It can be found on this thread: 

http://www.alteraforum.com/forum/showthread.php?t=6841&referrerid=2226  Specifically it can be found here: http://alterforum.com/forum/attachment.php?attachmentid=1446&d=1252512857&referrerid=2226  Jake