VIP Suite Scaler; Bad Status Value and Strange Mixer Behaviour

[Altera_Forum]

Hello All, 

 I'm having trouble with my scaler. I'm using the SoPC builder in Quartus 9.1:  RGB(4:4:4) Progressive SXGA (1280x1024) 60Hz Parrallel TTL -> CVI -> Scaler (Nearest N.) -> FB (DDR2 w/Pipeline Bridge) -> Mixer -> CVO -> SVGA 24bit Parallel TTL.  The background layer for the Mixer is a Test Pattern Generator. The Scaler and Mixer have control ports enabled which are being controlled by a Nios executing from internal M9K RAM. The whole path is clocked with the pixel clock (110MHz) of the incoming video, but I run it through a PLL first (1:1) for some jitter correction - is this a good idea? (seems to look ok.)   I have had two problems: 1) on some builds the mixer appear to work, but the scaler status register reads 0xffff ffff. if i remove the control port from the scaler, the system works (mixer controllable). 2) on some builds i can't set the go bit of the mixer, this will typically be accompanied by a status read of 0xffff ffff from the scaler status register.  Note that without control (i.e. a mixer) the path works well; so I'm assuming that there is no buffer overflow from the CVI and that the fb is functional. I find the scaler register read disturbing; this makes me think that I'm not reading valid memory and that the scaler is not getting the GO command either. To that end I checked the memory address allocation, and I'm using:  0x0000 0000 - 0x01ff ffff - DDR2 0x0200 0000 - 0x03ff ffff - pipeline bridge 0x0400 0000 - everything else  Also note that when I use the SoPC builder command 'automatically assign base addresses' it tries to put 'everything else' starting at 0x0, i.e. over the top of the DDR2 range. Is that ok? I'd have thought that DDR2 is only accessible through the pipeline bridge... but I wouldn't be suprised...  I'd love to hear back from anyone with any perspective, my head is getting very sore and there's now a crack in the wall where I've been banging it... Thanks in advance, Brent.

[Altera_Forum]

Let me first say that so far most of the time people have trouble with the VIP suite it's due to how the overall video system is put together rather than how the individual blocks are being used. Usually the biggest problems people have are with choosing the right clock frequency for the VIP blocks, and buffering. 

 1 - Your pixel clock may not be high enough for the VIP components. You need to allow for delays within the blocks of a few clock cycles plus the overhead of the video control packets. 2 - How much line buffering is in your CVI and CVO blocks? 3 - How wide is your DDR2 interface and how fast is it running?  With regards to the odd register reads, can you post a bit of your C code so we can see how you're accessing the components?  Also note, if the DDR2 is behind the pipeline bridge, it's real address range with relationship to anything in front of the bridge is 0x0200_0000 to 0x03ff_ffff. If the DDR2 and VIP blocks were really overlapping that would definitely not be okay but SoPC builder "shouldn't" allow you to do that.  Jake

[Altera_Forum]

Hi Jakob, 

 Thanks for the reply.   1 - Your pixel clock may not be high enough for the VIP components. You need to allow for delays within the blocks of a few clock cycles plus the overhead of the video control packets.  The vip blocks are clocked at the pixel rate of the incoming video; approx 110MHz, but as there is no blanking/sync information in the Avalon packets I figure they should have an efficiency improvement, requiring a 10% to 20% lower clock. I have successfully run the video path at 100MHz before from a static clock source.   What do you think is the fastest I can clock the video path? My device is EP3C16F484C8N. The Altera docs seem pretty vague on this front.   2 - How much line buffering is in your CVI and CVO blocks?  I'm buffering 2048 pixels on the CVI, and 512 pixels on the output. I have experimented with many different values and this combination work (when no control ports are enabled.) I'll triple this buffering for the sake on investigation.   3 - How wide is your DDR2 interface and how fast is it running?  The DDR2 is running full rate, 150MHz, with a 16 bit physical, 32 bit effective interface. As above, bandwidth does not appear to be an issue when the control ports are disabled. I will up this rate to 167MHz for the sake of investigation.  I'll post code tomorrow when I'm at work, but it is very simple IOWR(x_BASE, 0x01, 0x01) type stuff. I'll drop some screen shots of my sopc build and frame buffer settings, etc, too.  Thanks for all your help, I really appreciate the time (I'm sure everyone else does too) that you spend helping newbies like me! Regards, Brent.

[Altera_Forum]

Is your frame buffer configured for double buffering or triple buffering? 

 Jake

[Altera_Forum]

Hi Jake, 

 It's a triple buffer setup as there will be subtle differences in the frame rates of the in and out video.   I'll post more info soon, I'm fighting with my PC at the moment and haven't even started Quartus yet.  Cheers, Brent.

[Altera_Forum]

Here is some C to start the vip blocks: 

  IOWR( LED_BASE, 0, 0x7 ); // All on   IOWR( SCALER_BASE, CONTROL, VIP_STOP );  IOWR( SCALER_BASE, SCALER_REG_SIZE_X, x_size );  IOWR( SCALER_BASE, SCALER_REG_SIZE_Y, y_size );  IOWR( SCALER_BASE, CONTROL, VIP_GO );   IOWR( TESTPAT_BASE, CONTROL, VIP_STOP );  IOWR( TESTPAT_BASE, TPG_REG_SIZE_X, x_size );  IOWR( TESTPAT_BASE, TPG_REG_SIZE_Y, y_size );  IOWR( TESTPAT_BASE, CONTROL, VIP_GO );   IOWR( MIXER_BASE, CONTROL, VIP_STOP );  IOWR( MIXER_BASE, MIXER_REG_LAYER1_X, x_pos );  IOWR( MIXER_BASE, MIXER_REG_LAYER1_Y, y_pos );  IOWR( MIXER_BASE, MIXER_REG_LAYER2_X, 0 );  IOWR( MIXER_BASE, MIXER_REG_LAYER2_Y, 0 );  IOWR( MIXER_BASE, MIXER_REG_LAYER1_ENABLE, VIP_CONSUME );  IOWR( MIXER_BASE, MIXER_REG_LAYER2_ENABLE, VIP_GO );  IOWR( MIXER_BASE, CONTROL, VIP_GO );  I'm using this code to read back the registers through the jtag uart:   alt_printf( "\nScaler Registers:\n" );  alt_printf( " Status: %x\n", IORD( SCALER_BASE, STATUS ) );  alt_printf( " Size X: %x\n", IORD( SCALER_BASE, SCALER_REG_SIZE_X ) );  alt_printf( " Size Y: %x\n", IORD( SCALER_BASE, SCALER_REG_SIZE_Y ) );   alt_printf( "\nMixer Registers:\n" );  alt_printf( " Status: %x\n", IORD( MIXER_BASE, MIXER_REG_STATUS ) );  alt_printf( " L1 X: %x\n", IORD( MIXER_BASE, MIXER_REG_LAYER1_X ) );  alt_printf( " L1 Y: %x\n", IORD( MIXER_BASE, MIXER_REG_LAYER1_Y ) );  alt_printf( " L1 Enable: %x\n", IORD( MIXER_BASE, MIXER_REG_LAYER1_ENABLE ) );  alt_printf( " L2 X: %x\n", IORD( MIXER_BASE, MIXER_REG_LAYER2_X ) );  alt_printf( " L2 Y: %x\n", IORD( MIXER_BASE, MIXER_REG_LAYER2_Y ) );  alt_printf( " L2 Enable: %x\n", IORD( MIXER_BASE, MIXER_REG_LAYER2_ENABLE ) );//

[Altera_Forum]

FYI, Mixer input one is a test pattern generator, input two is from the video input path.

[Altera_Forum]

Here is a screen grab of my SoPC.

[Altera_Forum]

Actually I don't know if you're in a position to do this but if you can send me your project (and software), I think I can duplicate it on a Stratix II board I've got here. Then I could better find out what's giving you grief. 

 Jake

[Altera_Forum]

Hey Jakob, 

 I’ve just finished upgrading to 9.1 sp1 and I wanted to re-try a few things before I send my project through; my strong feeling is that Quartus, and especially the jump from 9.0 to 9.1 has caused this problem. I actually have a 2nd pc of similar spec and I’ve put a fresh load of quartus 9.1 on it, and I’ve found that if each PC compiles the same software source (simple vip system, with no nios control), the .sof built on the 2nd machine doesn’t work, but the .sof built on machine 1 does. Hopefully sp1 corrects a few instabilities.  Once I feel I've got a stable set of tools I’m going to cut the project back and try to manipulate each of the VIP blocks piece wise until I can identify the one that is giving me grief. I'll probably send you my project at this stage; there is nothing proprietary in it fortunately - I'm not at that stage yet, I am yet to achieve a starting point for our application.  I'll work through the day here in Sydney and there'll probably be something in your inbox when you wake up in the morning.   Cheers, Brent.

[Altera_Forum]

You know one thing I never asked was if you had your timing properly constrained and were meeting timing requirements. 

 Jake

[Altera_Forum]

To be completely honest, I'm not sure how to! It wasn't a problem when I was developing in Quartus 9.0 - so I never bothered to learn. I just checked that my system clocks were below the Fmax specified in the compilation report. I've just fired up TimeQuest and I'm going to teach myself - any tips? 

 Cheers, Brent.

[Altera_Forum]

TimeQuest is extremely powerful. However it does have a learning curve associated with it. 

 Make this page your best friend: http://www.altera.com/support/software/timequest/sof-qts-timequest.html  I recommend this course: http://www.altera.com/education/training/courses/odsw1115  Jake

[Altera_Forum]

Looks like timing is an issue. Yesterday using the 'Classic Timing Analysis Wizard' I managed to get the video path working again without flicker or failure and even hooked up control to the CVO - it still doesn't look as good as the one I compiled under Quartus 9.0, but there could be other factors at play. 

 I'll do the coursework you've prescribed and try it again with TimeQuest.   Thanks again, Brent.

[Altera_Forum]

The problem appears to be resolved by adding timing constraints to the system.  

 I've still got an issue which causes the video to become 'skew'; it seems that not enough pixels are being clocked out (of one of the vip blocks, not sure which) so what should be a vertical line becomes diagonal left, etc.   Strangely enough, no timing constraints were needed in Quartus 9.0 to achieve the same result - guess there are considerable differences between 9.0 and 9.1.   Many thanks to Jake for going the extra mile! Guru status well deserved.

[Altera_Forum]

Let me know if you want me to look into anything further. 

 Jake