Visible to Intel only — GUID: kka1645537669085
Ixiasoft
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. Chroma Resampler Intel® FPGA IP
10. Clipper Intel® FPGA IP
11. Clocked Video to Full Raster Converter Intel® FPGA IP
12. Color Space Converter Intel® FPGA IP
13. Full Raster to Clocked Video Converter Intel® FPGA IP
14. Full Raster to Streaming Converter Intel® FPGA IP
15. Guard Bands Intel® FPGA IP
16. Mixer Intel® FPGA IP
17. Pixels in Parallel Converter Intel® FPGA IP
18. Scaler Intel® FPGA IP
19. Tone Mapping Operator Intel® FPGA IP
20. Test Pattern Generator Intel® FPGA IP
21. Video Frame Buffer Intel® FPGA IP
22. Video Streaming FIFO Intel® FPGA IP
23. Warp Intel® FPGA IP
24. Design Security
25. Document Revision History for Video and Vision Processing Suite User Guide
Visible to Intel only — GUID: kka1645537669085
Ixiasoft
3.4. Stall Behavior and Error Recovery
The video and vision processing IPs do not continuously process data. They use the 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.