Main Content

Configure Blanking Intervals

Streaming video protocols have two blanking intervals: horizontal and vertical. The horizontal blanking interval is the period of inactive cycles between the end of one line and the beginning of the next line. The vertical blanking interval is the period of inactive lines between the end of a frame and the beginning of the next frame.

In this frame diagram, the blue shaded areas to the left and right of the active frame indicate the horizontal blanking interval. The orange shaded areas above and below the active frame indicate the vertical blanking interval.

In the Frame To Pixels block, the horizontal blanking interval is equal to Total pixels per lineActive pixels per line or, equivalently, Front porch + Back porch. The vertical blanking interval is equal to Total video linesActive video lines or, equivalently, Starting active line + Ending active lineActive video lines.

For example, the Frame To Pixels block whose parameters are shown in this image has a horizontal blanking interval of 140 pixels and a vertical blanking interval of 80 lines.

Frame To Pixels block parameters.

A streaming video format must have a long enough blanking interval so that the operation on the previous line or frame completes before the next line or frame starts. An inadequate horizontal or vertical blanking interval results in corrupted output frames. Standard streaming video formats use a horizontal blanking interval of about 25% of the line width. This interval is much larger than the delay of a typical operation. However, when you use a custom video format, you must include blanking intervals that accommodate the length of the operations in your design.

In these waveform diagrams, the top signal shows the state of the pixel stream for two lines of a frame. The shaded area represents the horizontal blanking interval between lines. The bottom signal shows the state of the block performing an operation on the pixel stream. The busy state indicates when the block is processing a line, and the idle state indicates when the block is available to start working on a new line. The first pair of signals shows a scenario where the block finishes working on the first active line before the second line begins. This blanking interval is long enough to ensure correct output frames, because the block is available to start work on the second line when it arrives. The second pair of signals shows a scenario where the block is still working on the first active line when the second line begins. The output of the block is corrupted in the second case, because the block misses the beginning of the second line.

The time an operation takes to complete after the end of the line is often dependent on the kernel size of the operation. For instance, algorithms that use line buffers and apply padding pixels to the edge of the frame require at least Kw cycles between lines, where Kw is the width of the kernel. An algorithm might also have pipeline delays from the kernel operation after the buffer. These delays can be related or unrelated to the kernel size, and can be greater or smaller than the line buffer delays. The processing time of each operation depends on the line buffer pipelining and on the kernel operation pipelining. The blanking interval must be long enough to accommodate the longer of these two delays. When you use multiple blocks in a processing chain, the blanking interval must accommodate the block with the longest delay.

The recommended minimum horizontal blanking interval is 2×Kw when using padding or 12 cycles when you set the Padding method parameter to None. This interval includes some margin for longer kernel processing times on top of the line buffer delay.

The recommended vertical blanking interval is at least the height of the kernel, Kh lines. The line buffer requires this interval whether or not the operation uses padding.

Troubleshoot Blanking Interval Problems

When the blanking interval is too small, you might see:

  • Blank output frames

  • Partial output frames

  • Corrupted pixel stream control signal patterns (for instance, missing vEnd or hEnd signals, or duplicate End or Start signals)

  • That the algorithm works with continuous valid input pixels on each line, but not when gaps exist between valid pixels in a line

  • That the algorithm works in Simulink® but fails in HDL simulation

Vision HDL Toolbox™ library blocks model hardware pipeline stages as a latency applied at the output. In the corresponding HDL implementations, the pipeline stages are distributed across the calculation. This difference means that for a given cycle, a block can be in a busy state in HDL simulation but appear idle in Simulink. When the blanking period is too short, this difference can cause the generated HDL test bench to show mismatches between Simulink and HDL signals, especially on the output control signals.

If you see any of these symptoms, increase your horizontal and vertical blanking intervals to 25% of the active frame dimensions and rerun the simulation. If this step confirms that a too-small blanking interval is causing your symptoms, you can fine tune the intervals.

One way to diagnose blanking interval problems in Simulink is to use the Measure Timing block to observe the dimensions of the pixel stream before and after your operation. Inadequate blanking intervals cause the block to corrupt the control signals. In these cases, the output frames show different dimensions than the input frames.

This model shows an Image Filter block configured with a 12-by-12 filter kernel and edge padding enabled. The pixel stream format is a custom format that has only 8 horizontal blanking pixels, as shown by the Measure Timing block on the input stream. Because the horizontal blanking interval is smaller than the kernel width, the output frame is blank. The Measure Timing block on the output of the filter shows corruption of the format.

You can also see the corruption by looking at the output control signals in the Logic Analyzer app. The waveform shows the input and output signals of the Image Filter block. The red arrows indicate missing hStart signals and a different pattern on the output valid signal from the block.

This model shows an Edge Detector block configured to use the 3-by-3 Sobel filter kernel and with edge padding enabled. This pixel stream format has only two horizontal blanking pixels, as shown by the Measure Timing block on the input stream. In this case, the output frame includes only every second line. The Measure Timing block on the output of the filter shows the corruption of the format.

You can also see the corruption by looking at the output control signals in the Logic Analyzer app. The waveform shows the input and output signals of the Edge Detector block. The red circle indicates missing hStart and hEnd signals, and the red arrow indicates a different pattern on the output valid signal from the block.

If you modify the input format to have a horizontal blanking interval of 3 pixels, this model returns the correct output frames in Simulink. However, when you run the generated HDL test bench, the test bench reports mismatches between the signals captured in Simulink and the signal behavior in HDL. This image of the test bench log highlights the mismatch in the output hEnd and vEnd signals.

This waveform from the simulation of the HDL test bench shows that the hEnd and vEnd signals at the end of the first frame are missing. The blue signals are the expected output as captured from the Simulink simulation. The red signals are the output of the algorithm in the HDL simulation. The red arrows indicate where the expected control signal pulses are missing.

To fix the Image Filter model and the Edge Detector model, set the horizontal blanking interval to at least 2×Kw pixels, where Kw is the width of the filter kernel. For the Image Filter model, set this value to at least 24 pixels. For the Edge Detector model, set this value to at least 8 pixels.

See Also

|

Related Topics