Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,515 Views

Duplicating Avalon ST Video Stream - Color Plane Sequencer or Avalon-ST Splitter?

I have a design right now that duplicates Avalon-ST video streams using a string of color plane sequencers and I was wondering whether there is an advantage to using the CPS over the dedicated Avalon-ST Splitter IP core. The obvious advantage is that I can split the stream enough times as I need to using one IP component rather than multiple, but I don't know if I will be missing out on some other functionality that the CPS provides. 

 

Anyone have any light they can shed on this? 

 

Thanks!
0 Kudos
7 Replies
Altera_Forum
Honored Contributor I
49 Views

That all depends on your needs. If you need multiple duplicates of one stream (and depending e.g. on the strategy for prioritization of some streams) you may just write your own splitter. Should not be that hard and will potentially safe a lot of resources. 

 

Otherwise with the CPS you have the possibility to cut some colorplanes away or change the order, or switch from sequential to parallel transfer. 

 

As introduced, all depends on your needs.
Altera_Forum
Honored Contributor I
49 Views

The Avalon-ST splitter could work but you may incur extra costs if it only support Avalon-ST ready latency 0. You may also have issues because the Video IP cores don't use the empty signal when color planes are transmitted in parallel and I am not sure whether the default Avalon-ST splitter handles this well. 

 

The CPS should work as long as you are not developing for Arria 10. 

 

If you are using acds 16.0, you may consider using the Switch II from the Video IP suite. It seems to be the best choice considering your requirement to split the stream more than once.
Altera_Forum
Honored Contributor I
49 Views

Thank you vgs, that is very helpful info. 

 

I thought the Switch II could only route streams 1:1? I didn't know it could also duplicate. I might be thinking of Switch I however...
Altera_Forum
Honored Contributor I
49 Views

Hello, 

 

I have video system (CVI ->.. ->FrB-> .. CVO) with NIOS on Cyclone V 

and need to grab single frames to HPS memory from live video stream for processing. 

 

Do I need to add Avalon-ST splitter + SGDMA modules (to capture frames)  

or there are better solution ? (Images should be post processed by HPS) 

 

 

Thanks!
Altera_Forum
Honored Contributor I
49 Views

You have a few options, really: 

 

1. Pause the video stream for a little bit and do a memcpy() from the frame buffer's memory location, retaining your current video path structure (have seen this done successfully) 

2. Split the stream and add a DMA that writes frames to memory, using the splitter and (M)SGDMA 

3. Implement your own frame buffer using the (M)SGDMA which can "steal" a live frame while continuing to operate (you'll have to repeat one frame to make up the difference)
Altera_Forum
Honored Contributor I
49 Views

1. Do you mean just pause CVI and simply steal bytes from any of triple buff mem area of FB ? that was first that came to my mind )) Not so quality solution, but straight and simple, and believe if use DMA, it almost cant see the difference in CVO live stream. 

2. The solution I like more and tried to implement, but got ”The source has a startofpacket signal of 1 bits, but the sink does not" error when connected AvST splitter into video path. I guess there some adapters are required, and to splitter's output too ? 

3. Do you mean build an alternative (triple buffering) FB, with function to make frame shot (to 4th buffer to elsewhere) per CPU request ? Very attractive solution, but I have no HDL sources of original FB to study and rewrite it later. 

 

4. I think also there should exist a solution with Avalon-ST video monitor IP, when trace system input replaced by CPU. 

 

(Sorry for offtop discussion)
Altera_Forum
Honored Contributor I
49 Views

 

--- Quote Start ---  

1. Do you mean just pause CVI and simply steal bytes from any of triple buff mem area of FB ? that was first that came to my mind )) Not so quality solution, but straight and simple, and believe if use DMA, it almost cant see the difference in CVO live stream. 

--- Quote End ---  

 

 

Yep! Exactly that. I think its the fastest solution to implement, of those discussed. 

 

 

--- Quote Start ---  

2. The solution I like more and tried to implement, but got ”The source has a startofpacket signal of 1 bits, but the sink does not" error when connected AvST splitter into video path. I guess there some adapters are required, and to splitter's output too ? 

--- Quote End ---  

 

 

I haven't actually used the splitter, but it could be that either it requires you to check some configuration box for packets (seems odd, but maybe), or you need an adapter for it. There's an Avalon-ST generic adapter block that may work. 

 

3. Do you mean build an alternative (triple buffering) FB, with function to make frame shot (to 4th buffer to elsewhere) per CPU request ?  

 

Yeah something to that effect. You could design your own buffering algorithm that allows you to do something like this. 

 

 

--- Quote Start ---  

Very attractive solution, but I have no HDL sources of original FB to study and rewrite it later. 

--- Quote End ---  

 

 

You should be able to implement this sort of thing without touching HDL at all - I think if you used two mSGDMAs configured with one ST-to-MM and the other MM-to-ST, with the appropriate interrupts and software code, you could make it work. If you wanted an "unmanaged' solution (like the current frame buffer requiring no CPU interaction) you would likely have to design a state machine connected to the mSGDMAs' configuration/dispatch ports and interrupt lines. Definitely possible, but could be tedious. 

 

 

--- Quote Start ---  

4. I think also there should exist a solution with Avalon-ST video monitor IP, when trace system input replaced by CPU. 

--- Quote End ---  

 

 

I haven't actually used the video monitor IP, so I can't comment on this possibility.
Reply