4.3. Full-Raster TDATA Signal Layout
The full-raster protocol adds n bits of payload sideband signaling to each pixel into the TDATA bus. This timing markers sideband data is a full-raster stream. The size of a full raster stream requires the same number of bits as defined for a pixel with a single-color plane (bits per symbol). You define the full-raster stream data width to match a color plane per symbol. You treat the full-raster stream as an extra or fake color plane for each pixel, to calculate the total TDATA bus width. The full-raster protocol follows similar equations and rules proposed by the Intel FPGA streaming video protocol, which uses the number of pixels in parallel to determine the size of the TDATA bus.
Full-raster TDATA byte width = max(2, (ceil ((bps × (SYM + 1))/8)) × PIP))
Where:
- BPS is bits per symbol
- SYM is number of color planes
- PIP is pixels in parallel
Figure 49. Streaming Full Raster Code Snippet to Calculate TDATA bus widthThe figure shows an example code snippet to show you can calculate the full-raster TDATA bus width by increasing the original number of color planes by 1. The full-raster stream payload in the TDATA bus conveys full-raster timing markers information for each pixel.
module intel_vvp_axis_fr_generic_ip
#(
parameter PIP = 4, // Pixels in Parallel (PIP)
parameter SYM = 3, // Number Color plane per Symbols
parameter BPS = 12, // Bits Per Symbol
parameter AXIS_FR_WIDTH = (((((BPS*(SYM+1))+(7))/(8))*(8))*(PIP))
)
(
.
.
input logic [AXIS_FR_WIDTH -1 : 0] axi4s_fr_in_tdata,
output logic [AXIS_FR_WIDTH -1 : 0] axi4s_fr_out_tdata,
.
.
);
endmodule
Figure 50. Intel FPGA Streaming video lite-mode vs full-raster TDATA FormatsThe figure shows an example of the TDATA bus for both lite variants and full-raster protocols. Both carry the same video data information. The data packet carrying full-raster information has appended extra streams on the TDATA bus to include timing video information per pixel: FR 0 for pixel 0 and FR 1 for pixel 1.
Figure 51. Streaming Full Raster TDATA FormatThe figure shows the full-raster stream stacked on top of the pixel data such that FR 0 relates to Pixel 0 and FR 1 relates to Pixel 1. If the bus is wider, this algorithmic stacking of pixels and full-raster stream data continues.
The full-raster protocol encodes pixels and their associated timing information by stacking them across TDATA. The first pixel is placed in the lowest bit position. All pixels are byte-packed to comply with the byte granularity of AXI4-S specification. When needed, some padding bits in the full-raster stream ensure byte-alignment.
The table shows the internal structure of a full-raster stream packet, where:
- Bit (BPS-7) is an end of line bit to indicate streaming full-raster end of line, and its value should coincide with the TLAST signal.
- Bit (BPS-6) is a start of frame bit to indicate streaming full-raster start of frame, and its value should coincide with the TUSER[0] signal.
- Bit (BPS-5) is a sync mode bit to indicate which timing methods (sync-timing or blank-timing) are transported.
- Bit (BPS-4) contains data enable information.
- Bits (BPS-3) and (BPS-2) provide horizontal and vertical timing information, respectively. Bits (BPS-4) and (BPS-3) work with bit (BPS-5), as sync-timing and blank-timing modes are mutually exclusive.
- Bit (BPS-1) carries information about the field sync that defines the start of a field on a video frame. In case of interlaced format, Bit (BPS-1) indicates whether the incoming data belongs to either the first (F0) or second (F1) field. For progressive format, bit (BPS-1) is tied-off to logic-low all the time.
| Full-raster Bit | Name | Description |
| BPS-1 | Field | ‘0’ = first field (F0) for interlaced or Progressive format ‘1’ = second field (F1) for interlaced format |
| BPS-2 | V-sync or V-blank | Indicates vertical blanking. |
| BPS-3 | H-sync/ H-blank | Indicates horizontal blanking. |
| BPS-4
|
Data enable | Indicates active portion of video image. |
| BPS-5
|
Sync mode | ‘0’ = sync fields are valid ‘1’ = blank fields are valid |
| BPS-6 | Start of frame | Indicates full-raster true start of frame where video geometry counters are in coordinates (1,1), irrespective of where the actual leading edge of VSYNC occurs. The value of this field should coincide with TUSER[0] signal value. |
| BPS-7 | End of line | Indicates full-raster end of line, which is the last pixel on each full rater video line. The value of this field should coincide with TLAST signal value. |
| BPS-8:0 | Reserved | Reserved. |
The full-raster stream payload aligns with the most significant bit (MSB). Its data is always in the same place regardless of the number of bits per sample of the defined Intel FPGA streaming video pixels size. The MSB alignment also allows bits per sample conversion without affecting or breaking the internal structure of the full-raster stream payload. The rest of the bits in the full-raster stream payload are reserved, and you should ignore them as they do not carry meaningful information. You should pad them with logic-zero values.
The figures show how the full-raster stream looks when configured for a specific sync mode.
Figure 52. FR Stream with Sync-TimingThe figure shows valid fields for sync-timing.
Figure 53. FR Stream with Blank-Timing The figure shows valid fields for blank-timing.
Both blank and sync timing can exhibit dual polarities as defined by video standards. To support the different variants of sync-timing and blank-timing polarities, an optional processor register interface should allow user-control to define the polarity (active high or low) for the following video timing signals:
- Vsync or Vblank
- Hsync or Hblank