Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

VIP 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

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    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.