Video IP Cusom ST Block SOP, EOP

[Altera_Forum]

Hello, 

 I'm wondering if someone could help out in managing the packet signals for a custom Video-ST block.  For example, if I want to add a custom user type packet before the control packet, I would hook up the stream to a FIFO in my block, enable the FIFO when the startofpacket and data is type 15.  Then insert my packet at the output stream, but... then I've got to go back and re-generate the control packet, startofpacket and endofpacket signals for the video data.  I'm not sure how to handle this... I did find the packets to bytes converter core, but I have some question how this core works with Video-ST vs standard Avalon-ST protocol. Further, it seems the encoded stream tries to protect the data by xor'ing the data with 0x20, but I can see this encoding scheme failing by, for example, the data being 0x5A -- resulting in an encoded data of 0x7A, the code for start of packet.  Anyhow, this doesn't seem like it should be all that complicated as all of the video ip cores provided by Altera basically have to be doing the same thing.  Any help would be appreciated. Thanks

[Altera_Forum]

I think you're going to want to keep everything in the Video-ST protocol. All you really have to do is wait for the startofpacket from the upstream component, when you see it, hold off the input, insert your packet, then go back to passing the input from the upstream component to the output. Not that bad. 

 It doesn't sound like you have any need to extract the control packet right?  Jake

[Altera_Forum]

Not in that particular scenario, a hold-off would work in that case. However, I may have another scenario where, for example, I would need to buffer up some of the incoming data, do some processing, then send it out. For the sake of simplicity, lets say a custom frame buffer. On the output side, how would I know how to form the control packet and when to provide the startofpacket/endofpacket signals.

[Altera_Forum]

I have written the control packet extraction and control packet insertion logic. It's not that bad. About 100 lines of code for each one. 

The startofpacket signal occurs coincident with the packet type identifier. The endofpacket signal occurs coincident with the last byte of the control packet (the deinterlacing field I believe).  Also you can look at an example of how Altera did theirs. When you compile a design that has the "Clocked Video Input" and "Clocked Video Output" cores, the source code for those cores can be seen in your project's "db" directory. Look at the file "alt_vip_IS2Vid.v" file in the "db" directory. This is the code for the "Clocked Video Input" block. Somewhere down in there is the code they're using to insert the control packets.   Jake

[Altera_Forum]

So I guess what your saying, is you extract the control packets and store them somewhere else, then sync them up on the back end??? 

 After some more thinking, what I came up with was just to carry around a couple of extra bits and generate the output signals with that.  Ie. data_to_hold <= {SINK_data_in, startofpacket, endofpacket};  Then on the output side, just use the last two bits to drive the signals.  Any thoughts?  I'll peak at the Altera code in the meantime.