Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorVIP Suite Scaler; Bad Status Value and Strange Mixer Behaviour
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.
15 Replies
Altera_ForumHere 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
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
Is your frame buffer configured for double buffering or triple buffering?
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
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
