VIP suite - how can I make my Y channel into 3xY in parallel in SOPC ?

Question

hi,

In my design I want to mix two streams with the alpha blending mixer.

One stream, the background layer is 800x600 represented in RGB, three color planes in parallel.

The other stream, which is comming from a camera source (which is clipped and scaled downto 640x480) is represented by a 8 bit Y (luminance) value.

Since the background layer is using three color planes is parallel, the Y values from the 640x480 stream also need to be presented as 3 * Y in parallel for the alpha blending mixer.

In what fashion should I duplicate the Y values in SOPC builder, so that the mixer receives the correct stream ?

I tryed using the color plane sequencer, but it says that the number of occurances of channel Y on din0 and dout0 must be the same.

altera_forum · Answer

Hi,

The easy hack would be to install a custom block on the sequential stream to triplicate each luma sample inside image packets.

...,Y_10, Y_11, Y_12,... -> ...,Y_10, Y_10, Y_10, Y_11, Y_11, Y_11, Y_12, Y_12, Y_12,...

You can then use the color plane sequencer to do the transformation:

Ya, Yb, Yc in sequence -> Ya:Yb:Yc in parallel

The reason I am suggesting to do it this way is to save you the trouble of switching the format of the control packet from sequence to parallel and to let the color plane sequencer handle that for you.

The main issue with this suggestion is that it is only applicable if the input pixel rate is less than a third of the clock rate. If not, your custom block will have to apply too much back-pressure and will overflow the input. If this is the case then writing your own custom color plane sequencer may be the easiest route.

altera_forum · Answer

hi again,

I'm clocking the camera stream into the SOPC system with a 27MHz clock while the system itself is using a 40MHz clock for the VIP chain,

so I probable wont be able to solve this using your initial suggestion of triplication.

Also, woudn't I have to change the control data packet information if I was to change the width of the VIP frame from 640 pixels to 640 X 3 pixels inorder to get the Y_10, Y_10, Y_10, Y_11, Y_11, Y_11..sequence ?

I'm not sure if this is the right solution, but what would happen if I create a custom module that receives the camera stream from a source(deinterlacer) and place the 8bit Y values in a 24 bit signal(23..16)(15..8)(7..0) which is then streamed along with the valid, sop, eop signals to the alpha blending mixer (sink) ? Would this create an missmatch in the control data packet ?

altera_forum · Answer

&gt; Also, woudn't I have to change the control data packet information if I was to change the width of the VIP frame from 640 pixels to 640 X 3 pixels inorder to get the Y_10, Y_10, Y_10, Y_11, Y_11, Y_11..sequence ?   No, the width in the control packets would still be 640 since the number of pixels would still be the same. The transformation brings you from 1 channel in sequence to 3 channels in sequence but this information is not carried over in control packets. It is a compile time parameter for most VIP cores.  &gt; I'm not sure if this is the right solution, but what would happen if I create a custom module that receives the camera stream from a source(deinterlacer) and place the 8bit Y values in a 24 bit signal(23..16)(15..8)(7..0) which is then streamed along with the valid, sop, eop signals to the alpha blending mixer (sink) ?  I am not sure I understood what your source is but if you have control over the source and you are already generating control packets yourself then yes this is by far the easiest solution. If your source is the deinterlacer VIP core working with 1 color sample per pixel (1 channel in parallel and 1 channel in sequence) then you have to modify the control packet on the fly as described in: http://www.altera.com/literature/ug/ug_vip.pdf (Figure 4.10 to Figure 4.8). The data contained in the control packet would still be the same but it is transmitted differently.

altera_forum · Answer

hi again,   &gt;I am not sure I understood what your source is but if you have control over the source and you are already generating control packets yourself then yes this is by far the easiest solution. If your source is the deinterlacer VIP core working with 1 color sample per pixel (1 channel in parallel and 1 channel in sequence) then you have to modify the control packet on the fly as described in: http://www.altera.com/literature/ug/ug_vip.pdf (http://www.altera.com/literature/ug/ug_vip.pdf) (Figure 4.10 to Figure 4.8). The data contained in the control packet would still be the same but it is transmitted differently.    My video source(8bit Y) is provided from a camera, this source is clocked into my system, clipped, scaled and then deinterlaced using VIP cores.    Your right about the deinterlacer using a single color plane. I placed a custom module between the deinterlacer and the alpha blending mixer and I tried changing the control data packet from the single color plane in sequence into matching 3 color planes in parallel. When the "startofpacket" signal is received and the "data" signal indicates an control data packet, I deassert the "valid" signal going to the alpha blending mixer, I then take three samples from the control data payload(which is received in sequence from the deinterlacer). After that I assert "valid" and send the control packet payload as three color planes in parallel to the mixer. I do this three times, to shift all the control data out to the mixer. For the last control data payload I assert "endofpacket", and after that I provide "startofpacket" for the video data and start shifting out the video data received from the deinterlacer as 3 colorplanes in parallel.    What's happening now is that the output from the alpha blending mixer, which is clocked out to screen, is switching from on to off after every 1-2 second and also the sync signals seem to be going down with the video data. Also, I sometimes get some sort of sparkling noise (often green in color) spread across the output video data. This noise seem light sensitive as it moved across the camera videodata on my output screen. I would appreciate your thoughts on these matters

altera_forum · Answer

Hi,  &gt;What's happening now is that the output from the alpha blending mixer, which is clocked out to screen, is switching from on to off after every 1-2 second and also the sync signals seem to be going down with the video data This looks like a thoughput issue. Your source may provide either too many data or not enough data for the sink. You may have all your sources and sinks running at the same rate (eg, 60Hz) but this does not means that they are perfectly in sync since you could be using slightly different clocks. This kind of problem is typically fixed by adding a triple buffer at a strategic position in the system. Perhaps you can simply switch triple buffering on in the deinterlacer but it is hard to say without seeing the full system. The mixer could also be the cause of this throughput issue but once again it is hard to say without a complete description of the system.  &gt; Also, I sometimes get some sort of sparkling noise (often green in color) spread across the output video data If the "noise" is consistent and stays with the light then it could be a range issue. The VIP cores tend to use the full range available for color samples from 0 to 2^(bits_per_samples) - 1. Some video sinks require a constrained range.

Forum Discussion

VIP suite - how can I make my Y channel into 3xY in parallel in SOPC ?

7 Replies

Recent Discussions

Where is High Speed Transceiver Demo Design in FPGA Wiki ?

ALT PLL GUI MESSDED UP ON INVOCATION

Transceiver data corruption

MAX10 TSE reference design

Can't generate F-Tile Ethernet Hard IP Design Example