Video and Vision Processing Suite IP User Guide

ID 683329
Date 3/30/2025
Public

Visible to Intel only — GUID: kka1645537669085

Ixiasoft

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 IP 8. 1D LUT IP 9. 3D LUT IP 10. Adaptive Noise Reduction IP 11. Advanced Test Pattern Generator IP 12. AXI-Stream Broadcaster IP 13. Bits per Color Sample Adapter IP 14. Black Level Correction IP 15. Black Level Statistics IP 16. Chroma Key IP 17. Chroma Resampler IP 18. Clipper IP 19. Clocked Video Input IP 20. Clocked Video to Full-Raster Converter IP 21. Clocked Video Output IP 22. Color Plane Manager IP 23. Color Space Converter IP 24. Defective Pixel Correction IP 25. Deinterlacer IP 26. Demosaic IP 27. FIR Filter IP 28. Frame Cleaner IP 29. Full-Raster to Clocked Video Converter IP 30. Full-Raster to Streaming Converter IP 31. Genlock Controller IP 32. Generic Crosspoint IP 33. Genlock Signal Router IP 34. Guard Bands IP 35. Histogram Statistics IP 36. Interlacer IP 37. Mixer IP 38. Pixels in Parallel Converter IP 39. Scaler IP 40. Stream Cleaner IP 41. Switch IP 42. Text Box IP 43. Tone Mapping Operator IP 44. Test Pattern Generator IP 45. Unsharp Mask IP 46. Video and Vision Monitor Intel FPGA IP 47. Video Frame Buffer IP 48. Video Frame Reader Intel FPGA IP 49. Video Frame Writer Intel FPGA IP 50. Video Streaming FIFO IP 51. Video Timing Generator IP 52. Vignette Correction IP 53. Warp IP 54. White Balance Correction IP 55. White Balance Statistics IP 56. Design Security 57. Document Revision History for Video and Vision Processing Suite User Guide

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.