When responding to a request received on the completer request interface with an Unsupported Request (UR) or Completion Abort (CA) status, the user application must send a three-Dword completion descriptor in the format of Figure 1, followed by five additional Dwords containing information on the request that generated the Completion. These five Dwords are necessary for the integrated block to log information about the request in its AER header log registers.
The following figure shows the sequence of information transferred when sending a Completion with UR or CA status. The information is formatted as an AXI4-Stream packet with a total of 8 Dwords, which are organized as follows:
- The first three Dwords contain the completion descriptor in the format of Figure 1.
- The fourth Dword contains the state of the following
signals in
m_axis_cq_tuser, copied from the request:- The First Byte Enable bits
first_be[3:0]inm_axis_cq_tuser. - The Last Byte Enable bits
last_be[3:0]inm_axis_cq_tuser. - Signals carrying information on Transaction Processing Hint:
tph_present,tph_type[1:0], andtph_st_tag[7:0]inm_axis_cq_tuser.
- The First Byte Enable bits
- The four Dwords of the request descriptor received from the integrated block with the request.
The entire packet takes four beats on the 64-bit interface, two
beats on the 128-bit interface, and a single beat on the 256-bit interface. The packet is
transferred in an identical manner in both the Dword-aligned mode and the address-aligned
mode, with the Dwords packed together. The user application must keep the
s_axis_cc_tvalid signal asserted over the duration of the packet. It must
also assert the s_axis_cc_tlast signal in the last beat of the packet. The integrated block
can deassert s_axis_cc_tready in any cycle if it is not ready to accept. The
user application must not change the values on the CC interface in any cycle that the
integrated block has deasserted s_axis_cc_tready.