Avoiding Head-of-Line Blocking for Posted Requests - 1.0 English

The core holds a Non-Posted request received on its requester request interface for lack of transmit credit or lack of available tags. This could potentially result in HOL blocking for Posted transactions. Such a condition can be prevented if the user logic has the ability to check the availability of transmit credit and tags for Non-Posted transactions. The core provides the following signals for this purpose:

• pcie_tfc_nph_av[3:0]: These outputs indicate the Header Credit currently available for Non-Posted requests (0000 = no credit available, 0001 = 1 credit available, 0010 = 2 credits, …, 1111 = 15 or more credits available).
• pcie_tfc_npd_av[3:0]: These outputs indicate the Data Credit currently available for Non-Posted requests (0000 = no credit available, 0001 = 1 credit available, 0010 = 2 credits, …, 1111 = 15 or more credits available).
• pcie_rq_tag_av[3:0]: These outputs indicate the number of free tags currently available for allocation to Non-Posted requests (0000 = no tags available, 0001 = 1 tag available, 0010 = 2 tags available, …, 1111 = 15 or more tags available).

The user logic are optionally check these outputs before transmitting Non-Posted requests. Because of internal pipeline delays, the information on these outputs is delayed by two user clock cycles from the cycle in which the last byte of the descriptor is transferred on the requester request interface, so the user logic must adjust these values taking into account any Non-Posted requests transmitted in the two previous clock cycles. The following figure illustrates the operation of these signals. In this example, the core initially had 7 Non-Posted Header Credits and 3 Non-Posted Data Credits, and had 5 free tags available for allocation. Request 1 from the user logic had a one-Dword payload, and therefore consumed 1 header and data credit each, and also one tag. Requests 2 and 3 (straddled) in the next clock cycle 3 consumed 1 header credit each, but no data credit. When the user logic presents Request 4 in clock cycle 4, it must adjust the available credit and available tag count by taking into account Requests 1, 2, and 3, presented in the two previous cycles. Request 4 consumes 1 header credit and one data credit. When the user logic presents Request 5 in clock cycle 5, it must adjust the available credit and available tag count by taking into account Requests 2, 3, and 4. If Request 5 consumes one header credit and one data credit the available data credit is 0 two cycles after, as also the number of available tags. Thus, Request 6 must wait for the availability of new credit.

Figure 1. Operation of Credit and Tag Availability Signals on the Requester Request Interface

Similar transmit credit information is also provided in the cfg_fc_npd and cfg_fc_nph interface when cfg_fc_sel is set to the Transmit credits available mode.