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 This Figure , 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.
This 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 This Figure .
• 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] in m_axis_cq_tuser .
° The Last Byte Enable bits last_be[3:0] in m_axis_cq_tuser .
° Signals carrying information on Transaction Processing Hint: tph_present , tph_type[1:0] , and tph_st_tag[7:0] in m_axis_cq_tuser .
• 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 .