A newer version of this document is available. Customers should click here to go to the newest version.
3.4. Stall Behavior and Error Recovery
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 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 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.
Did you find the information on this page useful?