|dma<n>_qsts_out_op[7:0]||O||Opcode This indicates the type of packet being issued. Encoding of
this field is as follows.
0x0: CMPT Marker Response
0x1: H2C-ST Marker Response
0x2: C2H-MM Marker Response
0x3: H2C-MM Marker Response
|dma<n>_qsts_out_data[63:0]||O||The data field for the individual opcodes are defined in the tables below.|
|dma<n>_qsts_out_vld||O||Queue status valid|
|dma<n>_qsts_out_rdy||I||Queue status ready. Ready must be tied to 1 so status output will not be blocked. Even if this interface is not used, the ready port must be tied to 1.|
|[1:0]||err||Error code reported by the CMPT Engine.
0: No error
1: SW gave bad Completion CIDX update
2: Descriptor error received while processing the C2H packet
3: Completion dropped by the C2H Engine because Completion Ring was full
|||retry_marker_req||An Interrupt could not be generated in spite of being enabled. This happens when an Interrupt is already outstanding on the queue when the marker request was received. The user logic must wait and retry the marker request again if an Interrupt is desired to be sent.|
|[26:3]||marker_cookie||When the CMPT Engine sends a marker to the
interface, it sends the lower 24b of the
CMPT as part of the marker response on the
interface. Thus the user logic can place a
24b value in the CMPT when making the marker request and it will
receive the same 24b with the marker response. When the marker is
generated as a result of an error that the CMPT Engine encountered
(as opposed to a marker request made by the user logic), then this
24b field is don't care.
Note: Even if the user has enabled stamping of error and/or color bits in the CMPT writes to the host, the marker_cookie does not contain them. It is exactly the lower 24-bits of the CMPT that the user logic provided to the QDMA when making the marker request.