|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
|qsts_out_data[63:0]||O||The data field for the individual opcodes are defined in the tables below.|
|qsts_out_vld||O||Queue status valid|
|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.|
|[25:3]||marker_cookie||When the CMPT Engine sends a marker to the Queues status port interface, it sends the
lower 23 bits of the CMPT as part of the marker response on the Queues status port interface. Thus the
user logic can place a 23-bit value in the CMPT when making the
marker request and it will receive the same 23 bits 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 23-bit field is not valid.
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 23 bits of the CMPT that the user logic provided to the QDMA when making the marker request.
|||is_mrkr_rsp||This bit will be set to 1 if the marker response is based on marker request. If this bit is set to '0' marker response is based on errors.|