The AXI4-Stream video interface supports dual or quad pixels per clock with 8 bits, 10 bits, 12 bits and 16 bits per component for RGB, YUV444, and YUV420 color spaces. The color depth in YUV422 color space is always 12-bits per pixel.
When the parameter, Max Bits Per Component, is set to 16, the following figure shows the data format for quad pixels per clock to be fully compliant with the AXI4-Stream video protocol.
A data format for a fully compliant AXI4-Stream video protocol dual pixels per clock is illustrated in the following figure.
When the parameter, Max Bits Per Component, is set to 12, video formats with actual bits per component larger than 12 is truncated to the Max Bits Per Component. The remaining least significant bits are discarded. If the actual bits per component is smaller than Max Bits Per Component set in the Vivado IDE, all bits are transported with the MSB aligned and the remaining LSB bits are padded with 0. This applies to all Max Bits Per Component settings.
|Max Bits Per Component||Actual Bits Per Component||Bits Transported by Hardware|
As an illustration, when Max Bits Per Component is set to 12, the following figure shows the data format for quad pixels per clock to be fully compliant with the AXI4-Stream video protocol.
A data format for a fully compliant AXI4-Stream video protocol with dual pixels per clock is illustrated in the following figure.
The video interface can also transport quad and dual pixels in the YUV420 color space. The following figures show the data format for quad and dual pixels formats, respectively.
Similarly, for YUV 4:2:0 deep color (10, 12, or 16 bits), the data representation is the same as shown in the previous two figures. The only difference is that each component carries more bits (10, 12, and 16). However the current data format is not compliant with the AXI4-Stream video protocol. Therefore, a remapping feature is added to the HDMI Receiver Subsystem to convert HDMI native video into AXI4-Stream video. This feature can be enabled from the HDMI Receiver Subsystem GUI. To illustrate how the data remapping feature works for YUV 4:2:0 video from Native Video into AXI4-Stream, the previous figure is extended and represented in the following figure to show native video data associated with the clock and control signals.
When transporting using AXI4-Stream, the data representation must be compliant with the protocol defined in the AXI4-Stream Video IP and System Design Guide (UG934). With the remapping feature, the same native video data is converted into AXI4-Stream formats, shown in the following figure. As stated in AXI4-Stream Video IP and System Design Guide (UG934), the 4:2:0 format adds vertical sub-sampling to the 4:2:2 format, which is implemented in Video over AXI4-Stream by omitting the chroma data on every other line.
However, in the native HDMI video interface, the video data representation must be as shown in the following figure.
The subsystem provides full flexibility to construct a system using the configuration parameters, maximum bits per component and number of pixels per clock. Set these parameters so that the video clock and link clock are supported by the targeted device. For example, when dual pixels per clock is selected, the AXI4-Stream video need to run at higher clock rate comparing with quad pixels per clock design. In this case, it is more difficult for the system to meet timing requirements. Therefore the quad pixels per clock data mapping is recommended for designs intended to send higher video resolutions.
Some video resolutions (for example, 720p60) have horizontal timing parameters (1650) which are not a multiple of 4. In this case the dual pixels per clock data mapping must be chosen. For more information on supported video timing for different PPC, see Table 2.
For more information on the video AXI4-Stream interface and video data format, see the AXI4-Stream Video IP and System Design Guide (UG934).