Video and Vision Processing Suite Intel® FPGA IP User Guide

ID 683329
Date 12/31/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
1. About the Video and Vision Processing Suite 2. Getting Started with the Video and Vision Processing IPs 3. Video and Vision Processing IPs Functional Description 4. Video and Vision Processing IP Interfaces 5. Video and Vision Processing IP Registers 6. Video and Vision Processing IPs Software Programming Model 7. Protocol Converter Intel® FPGA IP 8. 1D LUT Intel® FPGA IP 9. 3D LUT Intel® FPGA IP 10. AXI-Stream Broadcaster Intel® FPGA IP 11. Bits per Color Sample Adapter Intel FPGA IP 12. Black Level Correction Intel® FPGA IP 13. Black Level Statistics Intel® FPGA IP 14. Chroma Key Intel® FPGA IP 15. Chroma Resampler Intel® FPGA IP 16. Clipper Intel® FPGA IP 17. Clocked Video Input Intel® FPGA IP 18. Clocked Video to Full-Raster Converter Intel® FPGA IP 19. Clocked Video Output Intel® FPGA IP 20. Color Space Converter Intel® FPGA IP 21. Defective Pixel Correction Intel® FPGA IP 22. Deinterlacer Intel® FPGA IP 23. Demosaic Intel® FPGA IP 24. FIR Filter Intel® FPGA IP 25. Frame Cleaner Intel® FPGA IP 26. Full-Raster to Clocked Video Converter Intel® FPGA IP 27. Full-Raster to Streaming Converter Intel® FPGA IP 28. Genlock Controller Intel® FPGA IP 29. Generic Crosspoint Intel® FPGA IP 30. Genlock Signal Router Intel® FPGA IP 31. Guard Bands Intel® FPGA IP 32. Histogram Statistics Intel® FPGA IP 33. Interlacer Intel® FPGA IP 34. Mixer Intel® FPGA IP 35. Pixels in Parallel Converter Intel® FPGA IP 36. Scaler Intel® FPGA IP 37. Stream Cleaner Intel® FPGA IP 38. Switch Intel® FPGA IP 39. Tone Mapping Operator Intel® FPGA IP 40. Test Pattern Generator Intel® FPGA IP 41. Unsharp Mask Intel® FPGA IP 42. Video and Vision Monitor Intel FPGA IP 43. Video Frame Buffer Intel® FPGA IP 44. Video Frame Reader Intel FPGA IP 45. Video Frame Writer Intel FPGA IP 46. Video Streaming FIFO Intel® FPGA IP 47. Video Timing Generator Intel® FPGA IP 48. Vignette Correction Intel® FPGA IP 49. Warp Intel® FPGA IP 50. White Balance Correction Intel® FPGA IP 51. White Balance Statistics Intel® FPGA IP 52. Design Security 53. Document Revision History for Video and Vision Processing Suite User Guide

38.3. Switch IP Functional Description

The IP receives incoming video fields from its Intel FPGA streaming video inputs and propagates them to its Intel FPGA streaming video outputs with control via an Avalon memory-mapped interface. The IP blocks, consumes, or routes input fields to outputs according to the control register settings. The IP does not perform a switch on interlaced fields in pairs. The switch occurs as soon as possible and so field pairs may separate during the switch. If crash switching is on, packets may be cut short during a switch. For full variants with crash switching, the IP may cut short output packets but it also makes them legal according to the Intel FPGA streaming video protocol .

Autoconsume Inputs

Autoconsume minimizes backpressure during switching. Turn on Autoconsume inputs if the switch inputs connect directly or indirectly to other IPs that are sensitive to backpressure, such as the video connectivity IPs. If the switch inputs connect directly or indirectly to sources such as a frame buffer, the frame buffer can tolerate backpressure and so you can turn off Autoconsume inputs to ensure that outputs switch promptly.

Figure 85. Autoconsume Example: 2 input, 3 output switch initial connectionsTo explain autoconsume, consider a 2 input, 3 output switch with two unsynchronized inputs (one HDMI and one DisplayPort)

In this example, input 0 (IP0) drives output 0 (OP0) and input 1 (IP1) drives both outputs 1 and 2 (OP1, OP2). 4k60 video drives both inputs but with the HDMI start-of-fields occurring before the DisplayPort start-of-fields.

Figure 86. Autoconsume Example: configuring new connections

The figure shows a new configuration with IP0 driving OP1 and IP1 driving OP0 , but keeping the OP2 from IP1 connection open. The Switch IP makes the new connections at the earliest opportunity after a write to the COMMIT register.

Figure 87. Autoconsume Example: 2 input, 3 output switch with new connections

The figure shows the IP receiving a write to the COMMIT register for the new configuration at a time marked by the dotted line.

OP0 is still completing the HDMI frame from IP0. OP0 must therefore create backpressure for this new connection request to IP1, which consequently creates backpressure to the DisplayPort input on completing its current field. This backpressure has the undesirable side effect of starving OP2 of video and stalling it. Incidentally, OP1 is changing its input source and so also stalls until the next HDMI field becomes available from IP0.

To prevent OP2 from starving, you must turn on Autoconsume in the GUI, so OP2 can continue uninterrupted while its current field completes.

Turn on Autoconsume inputs so that the IP defers the new connections until the end of the current HDMI field. Until that time OP0 and OP1 consume the IP1 DisplayPort input so the IP does not create backpressure for IP1 and new connections do not affect OP2.

Figure 88. Switch IP with Autoconsume Inputs

Broken field behavior

The switch has no sensitivity to broken fields. The IP performs switches on broken fields in the same way as unbroken fields.

Metapacket and auxiliary control packet support for full variants

For full variants, the switch supports all packet types and routes all the packets received on its inputs to the appropriate outputs. The IP defers the switch until it sees an end of field packet on an input, so that all packets between the image information packet and the end of field packet keep together. For more information, refer to the Intel FPGA Streaming Video Protocol specification.

Figure 89. Auxiliary Packet RulesThe figure shows aux1 and aux2 associate with field 1 and aux3 associates with field 2.

Pairs of image information and end-of-field packets mark one field of video. Any auxiliary control packets before the current field’s end-of-field packet are associated with that field. In addition, any auxiliary control packets that occur after the end-of-field packet of the preceding field are also associated with the current field.