From pixelcontrol

R2026b

Convert pixelcontrol bus to AXI-Stream control signals

Since R2026b

• 

From 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 From pixelcontrol block accepts the pixelcontrol bus protocol used by Vision HDL Toolbox™ blocks and converts to AXI4-Stream control signals. Use this block and the To 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 pixelcontrol bus protocol and the output in AXI4-Stream protocol. Each data value represents a single pixel. The block converts the input pixelcontrol start-of-line (hStart), end-of-line (hEnd), start-of-frame (vStart), and end-of-frame (vEnd) signals to AXI4-Stream packets where each packet represents one video line. The TLAST signal indicates the end of each video line. The block buffers one line before making any AXI4-Stream transfers, so that the output line has continuous valid pixels. The block maintains inactive cycles between lines and frames, according to the specified Video format.

For more information on the pixelcontrol protocol, see Streaming Pixel Interface. For more information on the requirements for inactive cycles in the pixelcontrol protocol, see Configure Blanking Intervals.

Ports

Input

pixel — Packed pixel data

scalar | vector

Packed pixel data representing one or more pixels, with one or more components per pixel. You can pass a scalar pixel value from the Vision HDL Toolbox algorithm or you can repack numPixels-by-numComponents values into a scalar value.

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

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 sends AXI transfers. When this signal is set to false, the block stops sending transfers.

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

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

Data Types: Boolean

Output

TDATA — Packed pixel data

scalar | vector

Packed pixel data, returned as the same data type and dimensions as the input pixel port.

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

TVALID — Indicates valid transfer

scalar

Control signal indicating whether the TDATA transfer is valid.

Data Types: Boolean

TLAST — Indicates end of line

scalar

Control signal indicating when the TDATA transfer represents pixels at the end of a horizontal line. The last pixel in TDATA represents the end of the line.

Data Types: Boolean

ready — Backpressure control signal

scalar

Indicates whether the block can accept pixel stream data. The Vision HDL Toolbox blocks do not support backpressure, so connect this signal to the To pixelcontrol block upstream of your Vision HDL Toolbox algorithm. Because the Vision HDL Toolbox blocks do not support backpressure, set the Almost full threshold (lines) parameter to accommodate the in-flight lines from your Vision HDL Toolbox algorithm.

The block ignores any data that arrives while ready is set to false.

Data Types: Boolean

frameReset — Indicates unexpected start of a new frame

scalar

The block sets this output to true when an input vStart signal interrupts an in-progress frame. In this case, the block resets its counters and data in the pixel buffer is overwritten with the new frame data. The output frameReset signal indicates the end of an incomplete frame and the start of the next frame.

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 output 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 pixel value. The block uses this number to count pixels in lines.

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 lines to store

3 (default)

Number of 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 the Almost full threshold (lines) threshold, the block sets ready to false.

Almost full threshold (lines) — Lines available in the buffer at backpressure

2 (default)

Lines available in the buffer when the block asserts backpressure, specified as a positive integer. The block implements this threshold as a number of pixels, using the number of active-pixels-per-line.

The block sets the ready output to false when there are maxLines - almostFullLines stored in the buffer, where maxLines is the Maximum lines to buffer parameter value and almostFullLines is the Almost full threshold (lines) parameter value. Because the Vision HDL Toolbox blocks do not support backpressure, set this value to accommodate the in-flight lines from your Vision HDL Toolbox algorithm.

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