To pixelcontrol

R2026b

Convert AXI4-Stream control signals to pixelcontrol bus

Since R2026b

• 

To pixelcontrol block

To add a block to a model, double-click the canvas and start typing the block name. Then, select the block from the list.

Libraries:
Vision HDL Toolbox / I/O Interfaces

Description

The To pixelcontrol block accepts AXI4-Stream control signals and converts them to the pixelcontrol bus protocol used by Vision HDL Toolbox™ blocks. Use this block and the From pixelcontrol block when your model contains Vision HDL Toolbox blocks and algorithms that use AXI interfaces.

This diagram shows the dataflow using these conversion blocks. The To pixelcontrol block converts input AXI4-Stream signals to the pixelcontrol protocol. If you send more than one pixel, or more than one component per pixel, in each AXI4-Stream transfer, you must unpack the data output and create a numPixels-by-numComponents matrix for the pixel input to the Vision HDL Toolbox algorithm. At the output of the Vision HDL Toolbox algorithm, you can pass a scalar pixel value to the From pixelcontrol block, or repack numPixels-by-numComponents values into the data input.

The waveform shows a 2-line-by-3-pixel frame arriving at the input in AXI4-Stream protocol and the output in pixelcontrol bus protocol. Each AXI4-Stream transfer represents a single pixel. Each AXI4-Stream packet represents one video line. The TLAST signal indicates the end of each video line. The block buffers one line before returning any output, so that the output line has continuous valid pixels. There is no end-of-frame signal, so the block counts lines to determine the end of frame. The block adds the specified inactive pixel regions to the output stream between lines and frames and generates the pixelcontrol start-of-line (hStart), end-of-line (hEnd), start-of-frame (vStart), and end-of-frame (vEnd) signals according to the specified Video format. For more information on the pixelcontrol protocol, see Streaming Pixel Interface.

Ports

Input

TDATA — Packed pixel data

scalar | vector

Packed pixel data representing one or more pixels, with one or more components per pixel. If you send more than one pixel and/or more than one component per pixel in each TDATA, you must unpack the data output and create a numPixels-by-numComponents matrix for the pixel input of Vision HDL Toolbox blocks.

To generate HDL code with floating point data types, see Generate Target-Independent HDL Code with Native Floating-Point (HDL Coder).

Data Types: uint | int | fixed point | double | single

TVALID — Indicates valid pixel

scalar

Control signal indicating whether the TDATA input is valid. The pixels in TDATA must be either all valid or all invalid.

Data Types: Boolean

TLAST — Indicates end of video line

scalar

Control signal indicating when the TDATA value represents pixel(s) at the end of a horizontal line of a video frame. The last pixel in TDATA represents the end of the line.

Data Types: Boolean

ready — Backpressure control signal

scalar

Indicator from downstream blocks that they can accept pixel stream data. Vision HDL Toolbox blocks do not support backpressure, so connect this signal to the From pixelcontrol block downstream of your Vision HDL Toolbox algorithm.

The behavior of the block in reaction to this input signal depends on the Control protocol parameter.

When you select the Simplified AXI4-Stream protocol, the block may send one extra cycle of data after ready is set to false.

When you select the AXI4-Stream protocol, while ready is false, the block sends no output data.

Data Types: Boolean

reset — Clears internal states

scalar

Control signal that clears internal states. When reset is 1 (true), the block internally ends the frame and clears internal states.

Data Types: Boolean

Output

data — Packed pixel data

scalar | vector

Output pixel stream, returned as the same data type and dimensions as the input TDATA port. If you send more than one pixel and/or more than one component per pixel in each TDATA transfer, you must unpack the data output and create a numPixels-by-numComponents matrix for the pixel input of Vision HDL Toolbox blocks. For details about Vision HDL Toolbox non-scalar pixelcontrol interfaces, see Multipixel and Multicomponent Support.

Data Types: uint | int | fixed point | double | single

ctrl — Control signals associated with pixel stream

pixelcontrol bus

The pixelcontrol bus contains five signals. The signals describe the validity of the pixel and its location in the frame. For more information, see Pixel Control Bus.

For multipixel streaming, each vector of pixel values has one set of control signals. Because the vector has only one valid signal, the pixels in the vector must be either all valid or all invalid. The hStart and vStart signals apply to the pixel with the lowest index in the vector. The hEnd and vEnd signals apply to the pixel with the highest index in the vector.

Data Types: bus

TREADY — Indicates when to send a transfer

scalar

Control signal indicating when downstream blocks can accept transfers. When this signal is set to true, the block accepts AXI transfers. When this signal is set to false, the block stops accepting transfers.

When you select the Simplified AXI4-Stream protocol, the block can accept one extra transfer the cycle after it sets TREADY to false. This extra transfer allows for the case where the upstream part of your design has multiple data samples available and synchronously reacts to the block setting TREADY low, such as the HDL FIFO (HDL Coder) block in Classic mode.

When you select the AXI4-Stream protocol, while TREADY is false the block accepts no input transfers.

Data Types: Boolean

Parameters

To edit block parameters interactively, use the Property Inspector. From the Simulink^® Toolstrip, on the Simulation tab, in the Prepare gallery, select Property Inspector.

Control protocol — Type of AXI interface

Simplified AXI4-Stream (default) | AXI4-Stream

Select the input control protocol. Both options implement the basics of an AXI4-Stream protocol where each packet represents one video line. The TLAST signal indicates the end of each video line. TDATA contains packed pixel data and TVALID qualifies the data transfer.

• Use the Simplified AXI4-Stream protocol when you model AXI4-Stream interfaces with MathWorks^® library blocks and use the HDL Coder™ IP core workflow. For more information on modeling an AXI4-Stream interface, see Model Design for AXI4-Stream Interface Generation (HDL Coder).

• Use the AXI4-Stream protocol if you model the AXI4-Stream interface yourself, or use external IP blocks.

Number of pixels — Number of pixels represented in the packed input and output data

1 (default) | 2 | 4 | 8

Specify the number of pixels represented in each TDATA value. The block uses this number to count pixels in lines. For details about Vision HDL Toolbox multipixel support, see Multipixel and Multicomponent Support.

Video format — Dimensions of active and inactive regions in video frame

1080p (default) | 240p | 480p | 480pH | 576p | 720p | 768p | 1024p | 1200p | 2KCinema | 4KUHDTV | 8KUHDTV | Custom

Dimensions of active and inactive regions in a video frame. To select a predefined format, select from the Video format list. The actual frame dimensions are displayed in the Video Format Parameters section. For a custom format, select Custom, and then specify the dimensions as integers.

The dimensions are defined in the diagram.

Note

The sample time of your video source must match the total number of pixels in the frame of your Frame To Pixels block. The total number of pixels is Total pixels per line × Total video lines, so set the sample time to this value.

If your frame size is large, you may reach the fixed-step solver step size limit for sample times in Simulink, and receive an error like this.

The computed fixed step size (1.0) is 1000000.0 times smaller than all
the discrete sample times in the model. 

You can avoid this error by choosing the variable-step solver.

Video Format	Supported for NumPixels	Active Pixels Per Line	Active Video Lines	Total Pixels Per Line	Total Video Lines	Starting Active Line	Ending Active Line	Front Porch	Back Porch
240p	2	320	240	402	324	1	240	44	38
480p	2, 4, or 8	640	480	800	525	36	515	16	144
480pH	2	720	480	858	525	33	512	16	122
576p	2 or 4	720	576	864	625	47	622	12	132
720p	2	1280	720	1650	750	25	744	110	260
768p	2, 4, or 8	1024	768	1344	806	10	777	24	296
1024p	2, 4, or 8	1280	1024	1688	1066	42	1065	48	360
1080p (default)	2, 4, or 8	1920	1080	2200	1125	42	1121	88	192
1200p	2, 4, or 8	1600	1200	2160	1250	50	1249	64	496
2KCinema	-	2048	1080	2750	1125	42	1121	639	63
4KUHDTV	2, 4, or 8	3840	2160	4400	2250	42	2201	88	472
8KUHDTV	2, 4, or 8	7680	4320	8800	4500	42	4361	88	1032
Custom	If all horizontal dimensions are divisible by NumPixels.	User- defined	User- defined	User- defined	User- defined	User- defined	User- defined	User- defined	User- defined

To support these additional formats, select Custom and set the parameters as shown in this table.

Video Format	Active Pixels Per Line	Active Video Lines	Total Pixels Per Line	Total Video Lines	Starting Active Line	Ending Active Line	Front Porch	Back Porch
480p SDTV	720	480	858	525	37	516	16	122
576p HDTV	720	576	864	625	45	620	12	132
720p HDTV	1280	720	1650	750	26	745	110	260
768p HDTV	1024	768	1344	806	36	803	24	296

When using a custom format, the values you enter for the active and inactive dimensions of the image must add up to the total frame dimensions. If you specify a format that does not conform to these rules, the block reports an error.

• For the horizontal direction, Total pixels per line must be greater than or equal to Front porch + Active pixels per line. The block calculates Back porch = Total pixels per line − Front porch − Active pixels per line.

• For the vertical direction, Total video lines must be greater than or equal to Starting active line + Active video lines − 1. The block calculates Ending active line = Starting active line + Active video lines − 1.

When using the Line Buffer block, or blocks that use an internal line buffer, with a custom video format, further requirements apply:

• The horizontal blanking interval, or Back porch + Front porch, must meet these guidelines:

  • The total of Back porch + Front porch must be at least 2 times the largest kernel size of the algorithm in the blocks following the Frame To Pixel block.

  • If the kernel size is less than 4, and you are using edge padding, the total porch must be at least 8 pixels.

  • If you disable padding, the total porch must be at least 12 pixels.

  • The Back porch must be at least 6 pixels. This parameter is the number of inactive pixels before the first valid pixel in a frame.

  For more information on blanking intervals, see Configure Blanking Intervals.

When using multipixel streaming (Number of pixels > 1), these requirements apply.

• The video format must have horizontal dimensions divisible by the Number of pixels parameter value. The horizontal dimensions are set by these parameters: Active pixels per line, Total pixels per line, Front porch, and Back porch. Standard video protocols 480p, 768p, 1024p, 1080p, 1200p, 4k UHD, and 8k UHD support Number of pixels equal to 4 or 8.

• The minimum input frame size for multipixel streaming is 18 rows by 32 columns.

• Choose your kernel size and Active pixels per line such that (Active pixels per line)/(Number of pixels) is at least the kernel width.

Maximum lines to buffer — Number of video lines to store

3 (default)

Number of video lines to store, specified as a positive integer. The block implements a FIFO sized for the number of active pixels in a horizontal line specified by the Video format parameter. For example when you set Video format to 240p (240 lines with 320 pixels per line), and Maximum lines to buffer is 3, the FIFO can store 2^nextpow2(320*3)=1024 pixels. When the buffer reaches this threshold, the block sets TREADY to false.

Extended Capabilities

C/C++ Code Generation

Generate C and C++ code using Simulink® Coder™.

This block supports C/C++ code generation for Simulink accelerator and rapid accelerator modes and for DPI component generation.

HDL Code Generation

Generate VHDL, Verilog and SystemVerilog code for FPGA and ASIC designs using HDL Coder™.

HDL Coder provides additional configuration options that affect HDL implementation and synthesized logic.

HDL Architecture

This block has one default HDL architecture.

HDL Block Properties

ConstrainedOutputPipeline	Number of registers to place at the outputs by moving existing delays in the design. Distributed pipelining does not redistribute these registers. The default value is 0. For more details, see ConstrainedOutputPipeline (HDL Coder).
InputPipeline	Number of input pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default value is 0. For more details, see InputPipeline (HDL Coder).
OutputPipeline	Number of output pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default value is 0. For more details, see OutputPipeline (HDL Coder).
SynthesisAttributes	Specifies the synthesis attributes for the blocks and block output signals in the model. The generated HDL code contains these attributes. For more information, see SynthesisAttributes (HDL Coder).

Version History

Introduced in R2026b