Video and Vision Processing Suite Intel® FPGA IP User Guide

ID 683329
Date 10/02/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. 3D LUT Intel® FPGA IP 9. AXI-Stream Broadcaster Intel® FPGA IP 10. Bits per Color Sample Adapter Intel FPGA IP 11. Chroma Key Intel® FPGA IP 12. Chroma Resampler Intel® FPGA IP 13. Clipper Intel® FPGA IP 14. Clocked Video Input Intel® FPGA IP 15. Clocked Video to Full-Raster Converter Intel® FPGA IP 16. Clocked Video Output Intel® FPGA IP 17. Color Space Converter Intel® FPGA IP 18. Deinterlacer Intel® FPGA IP 19. FIR Filter Intel® FPGA IP 20. Frame Cleaner Intel® FPGA IP 21. Full-Raster to Clocked Video Converter Intel® FPGA IP 22. Full-Raster to Streaming Converter Intel® FPGA IP 23. Genlock Controller Intel® FPGA IP 24. Generic Crosspoint Intel® FPGA IP 25. Genlock Signal Router Intel® FPGA IP 26. Guard Bands Intel® FPGA IP 27. Interlacer Intel® FPGA IP 28. Mixer Intel® FPGA IP 29. Pixels in Parallel Converter Intel® FPGA IP 30. Scaler Intel® FPGA IP 31. Stream Cleaner Intel® FPGA IP 32. Switch Intel® FPGA IP 33. Tone Mapping Operator Intel® FPGA IP 34. Test Pattern Generator Intel® FPGA IP 35. Video and Vision Monitor Intel FPGA IP 36. Video Frame Buffer Intel® FPGA IP 37. Video Frame Reader Intel FPGA IP 38. Video Frame Writer Intel FPGA IP 39. Video Streaming FIFO Intel® FPGA IP 40. Video Timing Generator Intel® FPGA IP 41. Warp Intel® FPGA IP 42. Design Security 43. Document Revision History for Video and Vision Processing Suite User Guide
Give Feedback

3.4. Stall Behavior and Error Recovery

The video and vision processing IPs do not continuously process data. They use flow-controlled streaming interfaces, which allow them to stall the data while they perform internal calculations.

During metapacket processing full variant IPs might stall frequently and read or write less than once per clock cycle. During data processing, the IPs generally process one input or output per clock cycle. The IPs have some stalling cycles. Typically, the stalling cycles are for internal calculations between data packets and between fields. When stalled, an IP drives tready low on its inputs to indicate that it is not ready to receive data. The time spent in the stalled state varies between IPs and their parameterizations. In general, it is a few cycles between data packets and a few more between frames.

If data is not available at the input when required, IPs stall and do not output data.

When IPs receive a tlast signal or TUSER[0] strobe unexpectedly (early or late), they recover from the error and prepare for the next valid packet (control or data).

Errors fall into one of three categories:

  • Low-level violations of the underlying AXI4-S protocol.
  • Violations of the Intel FPGA streaming video protocol
  • Higher-level violations of the Intel FPGA streaming video protocol.

Low-level protocol violations (such as TLAST stuck at zero or a TVALID or TREADY handshake fault) give system failure and possibly lockup. The IPs have no mechanism to protect against these violations.

Intel FPGA streaming video protocol violations include:

  • IPs receiving malformed control packets, which results in undefined behavior and likely result in system lock-up
  • Video packets with incorrect pixel-packing are processed by IPs successfully, but output data is likely to be incorrect or incorrectly packed.

Examples of high-level errors are:

  • Early or late TLAST signaling at the end of packets on data packets, where a line is shorter or longer than expected
  • Early or late TUSER[0] marking a start of frame, where a frame contains less or more lines than expected

You should expect these high-level errors sometimes in a running system. Therefore, IPs accept invalid video fields and they may also generate them without breaking the specification.