Forum Discussion

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

Using Avalon-ST with VIP

I'm developing various pieces of IP that act like video generators similar to the Test Pattern Generator block in the VIP suite. Right now I have a small test design to learn how to use the Avalon-ST bus in the VIP environment so we can run our custom video directly into another block, such as the Alpha Mixer.

What I've created so far appears to meet what I believe is the correct interface according to the documentation but it creates severe instability in the image. My test design includes my IP block, which produces a 640x480 block of flat data, and a TPG block of the same size both going into layers in the mixer. I have SignalTap monitoring both output Avalon-ST buses and I am looking differences.

So far there aren't many. Using SOP/EOP/ACTIVE to control a counter they both seem to be putting out the same size data packet. However I added a VIP control decoder block (downloaded from the Wiki) to each path and I'm seeing major differences in what gets captured. The block snooping my custom logic frequently reports incorrect height/width values. Digging into it further it appears that the decoder block assumes that the data in the control packet is contiguous. Once it gets an SOP it captures x clocks of data into it's registers disregarding READY/ACTIVE. However signal tap is showing that my control packets are frequently being broken up by READY from the sink. The same debug module snooping the TPG shows constant resolution values and I don't see any cases where the control packet is chopped up.

Should I expect my controls packets to be contiguous such that them getting chopped up is an indicator of where my problem might be or should I be looking somewhere else?

4 Replies

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

    there very well may be bugs in the decoder. i can try and take another look this week, by chance i have video equipment on the bench

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

    It sounds to me as though your VIP control decoder block is buggy. All Avalon ST sinks must ignore the data signals if valid is deasserted (or ready is deasserted for readyLatency 0).

    For a temporary fix can you send your data through a small FIFO (after the control decoder) to prevent small packets from being backpressured?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    buggy indeed

    it looks like the input data is only registered if the valid signal is asserted (good)

    however, in the control packet assembler it looks like the state machine stores data and advances to the next state even if valid was not asserted (bad)

    try changing all 3 instances of: 

    
if ctrl_pkt = '1' then

    to 

    
if ctrl_pkt = '1' and was_valid = '1' then

    i can probably test in hw tomorrow
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    It looks like the code to generate was_valid causes it to assert but never negate so I added an else to the if that sets that bit. That caused an issue lining up the data_count value with the incoming data when ready is only asserted for a single clock cycle. (Which happens frequently to my module according to SignalTap.)

    That got me wondering: why would the sink be asserting ready for only a single clock cycle? It negates it before it even gets a valid. My test system gets into a state where ready is asserted for a single clock every 8 clocks. I haven't been able to go back far enough to see how long it is in this state or what caused it. There's even a point in my source state machine where it pauses for a clock at the end of a data packet and the sink will assert ready for 1 clock, take it away with no valid at all, and then re-assert it 8 clocks later. Is that how it operates when the data pipe is starved or something? I don't ever see that behavior from TPG.