Forum Discussion

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

VIP Control is Mutilating my Image!!!

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.

36 Replies

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

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

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

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

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

    --- 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?