Alpha blending mixer's alpha blending port.

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