Alpha blending mixer's alpha blending port.

Hi,

I would suggest checking that you implemented the Avalon-ST specs (and Avalon-ST Video specs) correctly for all four inputs (din_* and alpha_*). There are independent ready signals for the sources and for the alpha sources and there is no guarantee that the inputs will be ready simultaneously. You should also avoid making any assumptions on their behaviour. For instance it could be possible, in theory, that the alpha channel is not ready until you have fed a dozen of pixels into the corresponding din input, It is easy to create a deadlock if trying to feed all inputs from a single source module.

One of the ready signal probably goes low at column 6 because there is a small FIFO at each input of the core and it can contain about that many samples. This is expected and the core will go ready again once it is actually processing the data it buffered.

One of the four ready signals going down at column 300 seems a bit unusual if you have valid data available on all four mixer inputs. It may be due to another core downstream applying back-pressure but this could also be the time when a spec violation has already happened.

vgs

hi,

regarding the Avalon-ST spec (see attached file), I'w placed a custom module infront of the VIP mixer module. The purpose of the custom module is to provide alpha values to the alpha blending mixer's alpha input port (only for the 640x480 stream).

The custom module receives the 800x600 stream from the VIP Frame Reader module and this steam is shifted "as is" straight through the custom module. The same goes for the 640x480 stream, which is received from an VIP Frame Buffer. Since the 800x600 stream is the background layer, it's alpha values are ignored, and all I'm actually doing is that I'm using row and column counter and providing alpha values for the 640x480 stream. Also, I'm providing the valid signal for the 640x480 alpha input port.

At the moment I'm not running into deadlocks, and I belive that the "ready" signal which is going down at column 300 is due to one of the components(not sure which one) in the 800x600 stream's chain.

Do you think that I should combine (and-ing) all 4 of the "ready" signals before providing the "valid" signal to the 640x480 alpha port ? In other words, should I stall the alpha values when any of the "ready" signals go low ? At the moment the "valid" signal is independant of the "ready" signals, I did try connecting the 640x480 source "ready" signal to it, but this distorted the video output.

At the moment my main concern is how to provide the alpha values durring the "valid" low periods

Hi,

I am not sure I understood fully how this custom module works but it would be way safer to generate the alpha stream independently and without dependencies to video_source_* and/or video_sink_*.

See the Avalon-ST spec for more details but you must not assert video_alpha_valid and send data to the core if video_alpha_ready was de-asserted the previous cycle.

Do not AND the video_source_ready and the video_alpha_ready signals because you may hit one of these deadlock cases I was talking about. There is no guarantee that the two inputs will be ready together and the mixer core could wait for a few valid video pixels before it starts accepting data on the alpha channel.

When generating an alpha frame, the first sample of each frame must be a 0 and have start of packet asserted. After the image packet header is sent, you may run your two counters each cycle to generate the alpha samples you require (but you must deassert valid and freeze each time the video_alpha_ready signal is deasserted as mentioned above). The last alpha sample of the frame must come with end-of-packet asserted.

I assume you will want to do something more complex in the future and that the alpha values may be dependent on the video data pixels. Consequently, another venue to explore would be to use the color plane sequencer. You may create a custom block that converts RGB to RGBA by just tacking the alpha value to the data wire and add a fourth color channel to the stream. This can easily be done without compromising the Avalon-ST Video protocol. You can then put Altera's color plane sequencer after your block to split RGBA back into two independent streams RGB and A. You can then connect RGB to the mixer video source and alpha to the mixer alpha source. It is possible that a small Avalon-ST FIFO will be required on either of these paths (once again this is to prevent a possible deadlock situation).

vgs

Hi,

the custom module was setup so that the 640x480 streams "startofpacket" (for the active video data) was used as an reference for when to set the "valid signal on the alpha port.

Also, I have been using the "startofpacket" and the "endofpacket" of the 640x480 video source as the "startofpacket" and "endofpacket" signal for the 640x480's alpha input.

I'll try providing the "valid", "startofpacet" and the "endofpacket" completely independant of the source signals, and follow the rest of the guide lines.

Appreciate your tips for "baking" the alpha into the RGB stream, splitting it up and delivering it to the mixer

regards

LightPhase1