Forum Discussion

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

VIP Frame Buffer Locks

Periodically, especially immediately following a Reset to my VIP system, one or the other of the 2 independent frame-buffers hangs up. I have SignalTap on the DoutValid and DoutReady signals throughout the QSys system. When I see the issue occurring (characterized by no video output to monitor) this shows that the doutready signal driving back into the framebuffer is always high, but the doutvalid from the framebuffer never toggles. My only option here is to reset the whole system. Normally, this solves the issue, but it is not a viable workaround.

Do you have any thoughts on what I could be doing wrong and how to resolve this?

My system includes no Ctrl Syncs. Might the solution to this issue involve the use of Ctrl Syncs? I guess my understanding about where/when to place a Ctrl Sync into my system is a little confusing to me.

Could incorrect reset connectivity cause a problem?

How should I be debugging it?

Thanks

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Do you mean VIP control packets?

    I insert my control packets between each VIP frame.

    This might be your problem.

    It might also be possible that your video pipeline is not completely resetting correctly.

    You could write a little VIP "watchdog" block on the input or output of the framebuffer that

    could assert a system wide reset if doutValid is not asserted for a long time.

    You might also want to signal tap the guts of the framebuffer and see if there is anything that

    is obviously locking up.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    No. By "Ctrl Sync", I do not mean Control Packets. I mean Control Synchronizer blocks. These VIP blocks are "normally" used in conjunction with VIP Alpha Blender and Switch blocks in order to facilitate synchronization of control data to the switch with frame-boundaries for all inputs on the Switch, although documentation on the use of these blocks is sketchy at best!

    Some guidelines which almost match my use-case are included in the VIP document under the "Switch" section. Apparently without using Ctrl Syncs, the system may deadlock. However, I do not use the Switch in my system, although I DO include Alpha Blenders, which may also take multiple unsynchronized streams as inputs. Hence, it was not clear to me if Ctrl Sync blocks were required.

    I have already considered the usage of a "watchdog" such as the one you suggest. I agree I will need something like this as a last resort, but I was hoping to avoid it!

    I'm not particularly happy with the idea of probing the obfuscated guts of a piece of IP I have no working knowledge of....:-)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Yeah, probing the guts of the VIP framebuffer is kind of a pain.

    You could write your own frame buffer.

    It just needs a memory mapped master read port,

    mapped master write port,

    streaming VIP in,

    streaming VIP out,

    and a simple state machine to control the read and write pointers as video comes into the block.

    It should only take a couple of days to write and test if you are familiar with VIP and Avalon.

    Then you wouldn't have to use the Altera one anymore.

    I have written my own versions of a lot of blocks in the VIP family

    because of the same problem that you are having now.

    There is no good way to debug them when they don't work as advertised.

    Also I have found that when I wrote my own VIP block, it used

    substantially fewer resources compared to the Altera one.