Avalon ST custom IP component

G'day BadOmen,

Thank you for taking the time to respond in detail. Your advice is really useful for newbies like me!

Your clue later in this thread is vital: The Avalon-ST Video Protocol, detailed in Section 2 of the VIP Users Guide, is essential reading for implementers.

It looks like the simple solution below may be *too* simple. We need to avoid processing control packets as if they contain pixel data, and the first value of every packet never contains pixel data. So the core can't just process sink data on every src_valid cycle.

I'm working on a couple of cores with relatively deep pixel pipelines which, similar to this example, are insensitive to the content of the control packets. Is there a "right" way, in general, for managing control packets for such a core?

Hopeful thanks ...

--- Quote Start ---

If your transform is combinatorial what you could do is create a component that has a source and a sink with the sink data transformed and sent to the source. Then you would wire the ready and valid bits directly so that all your component does is transform the data. Then if that's too much combinational delay and you need it pipelined put that Qsys pipeline stage after your core.

Often when I'm building stuff like this I have FIFOs too which helps isolate the source and sink. Last but not least another thing you can do is pipeline the transformed data and the valid from the sink and use the ready from source to enable the registering of those two signals and specify in the component defining that it has a ready latency of 1. Something like this in Verilog:

always @ (posedge clk)
begin
  if ((snk_valid == 1) & (src_ready == 1)
  begin
    src_data <= transformed_snk_data;   // need to make sure data is held in cause the src_ready deasserts on the next clock cycle
  end
  src_valid <= snk_valid; 
end

That code above is only safe if the ready latency of the source port is declared as 1. What Qsys will do is resynchronize the data output from your core. So basically when your component is being fed valid data and the source is being told that the downstream is ready for data you capture your data. On the next clock cycle if the downstream IP is still ready for the data then it gets sent, and if it's not ready then the data is held. Since the ready latency of the source is 1 Qsys will put a timing adapter into the path that compensates for the fact that valid data takes an extra clock cycle to get through your core. You could build the same sort of compensation into your IP but then you are re-inventing the wheel. Hopefully you can now see why I put FIFOs in a lot of the streaming IP I build, it helps isolate the flow of data by decoupling the source from the sink.

--- Quote End ---