VIP Control is Mutilating my Image!!!

I didn't realise it but there is another control packet, not long after the 1st one, coming out of the scaler. The second one contains the a correct control packet with width and height that I can control through the Nios2. See attached image.

Could this be because the scaler can't keep up with the input? My cvi fifo is currently 1280px, or one line. This is sensible as there are about 400 px of sync/blanking period in which no pixels are clocked in, and in this time the fifo should drain down - perhaps not enough? I've got the scaler running off the pixel clock at the moment, I'm going to compile a design now where the video path is clocked 10% faster than the pixel clock, from a different base clock.

The behavior of the VIP cores is often to pass all control packets through. So for example, the deinterlacer will pass the original interlaced control packet followed by the new control packet. The scaler likely does the same thing. So it's passing the control packet that it received from upstream, then it's sending it's own control packet for the frame that it has just scaled. That is why you see two.

You're image is slanting down and to the left. Which indicates that you are dropping pixels. This points to overflowing the input FIFO. You ought to be able to probe with signaltap for this (or read the status register). Look at the image. Would you say your losing about 7 pixels per line? Doesn't the CVI have an overflow output that you can observe?

If you are overflowing the input FIFO, then yes the solution is to increase the processing of the video. Specifically, you need to get it out of the CVI, through the scaler, and into the frame buffer faster. It could very well be that adding the runtime control to the scaler pushed you over the edge because now the scaler has to decode the incoming control packets.

Jake

Hi Guys,

I think that the CVI is confused, but I don't think that this is causing the image distortion. The main reason why is that without the control of the scaler, the system works. Unfortunately, I do need control of the scaler for our applicaiton; it's the main reason why we are not using off the shelf equipment for our application.

Jake, the screen is upside down; the picture shows the top left of the screen, but the back of it. So there are extra pixels, pushing it to the right of the screen (from the front viewpoint). I should have put this note on the images, or flipped them for logical purposes.

I am getting both overflow on cvi and underflow on my video out, but it is inconsistent, here is the outputs from my cvi and cvo registers as they are most recently reported by nios2 code (some are derived):

Vid In Registers:

Running

Stable

OVERFLOW

Invalid Resolution

Used Words: 0

A. Sample Cnt: 400

A. Line Count: 2f7

T. Sample Cnt: 540

T. Line Count: 324

Vid Out Registers:

Control: 1

Status: 5

Interrupt: 0

Used Words: 4af

Video Mode M: 0

Mode 1 Control: 1

Running

UNDERFLOW

NOT Locked

Something strange is going on here. I have just upped the frequency of the vip path clock to 120MHz. The video coming in is at 110MHz pixel clock. This did not change the symptoms. I've tested with SVGA and XGA video at 50MHZ and 65MHz respectively and the problem is consistent.

Next actions:

1) I'm considering moving to embedded syncs to see if that improves the performance of the CVI.

2) I'm also considering moving my frame buffer: CVI-> FB -> Scaler ->CVO. This has memory bandwidth disadvantages for our application but will be useful diagnostically.

My bandwidth calculations indicate that you don't actually have enough memory bandwidth to buffer 1280x1024 through your frame buffer. Calculation comes out to 104% of your available bandwidth. So I don't think that's going to work for you.

Jake

Brent, I just noticed that you don't have bursts enabled on your pipeline bridge between your frame buffer and the memory. This is going to kill your memory performance. You need to enable burst support.

P.S. I've almost got this running on my board.

Jake

Hi Jake,

Thanks for the tip, I'll change and compile now. I was wondering how you did the memory calculation, here is mine - can you tell me where my mistake is?

BW available = 150MHz x 16bits physical wide x2 (DDR2) x 0.7 efficiency = 3.36GB/s

BW required = 1280x1024px x 60 frames/s x 16bits per pixel x 2 (read/write access) = 2.5GB/s

Also, I was wondering if you work for Altera?

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.

No I don't work for Altera.

Jake

Altera definitely should be paying you for all the help you've been giving their customers. Imagine how many chip sales you've enabled.

Can you quickly tell me why someone would want to use the half-rate memory mode?

FYI I've recompiled with the pipeline bridge bursting set to 256 (to match my fb burst targets) and it still exhibits the same behaviour. I've tested with SVGA and XGA resoltions too (much lower bandwidth requirements and easier timing requirements) and they are the same; always the skew to the right. I've regressed to Quartus 9.0sp2 and I'm compiling now.

The half rate DDR2 controller affords two benefits:

1 - It's capable of running the memory interface at higher frequencies.

2 - It cuts the local interface frequency in half (so in your case, the sysclk would be 75MHz instead of 150). This obviously enables you to meet timing more easily. However the tradeoff is that local interface width doubles (would be 64 in your case).

P.S. I've got your design compiled on my board and running but I'm trying to get anything at all to show up on my DVI output.

Jake

Does the frame buffer organise the memory writes/reads efficiently? If my pixels were 15 bits wide, (5bits per colour) would it write 4 pixels at a time with a local interface of 64 bits? Or will it write one pixel at at time, only using the LS 15 bits and padding the remaining MS bits with 0s?

If the former, then there may be a case for me using a half rate?

Thanks for running my design, my gratitude is endless!!