The RCB_FC method allocates and de-allocates blocks of credit in RCB
granularity. Credit is freed on a per-RCB basis. As with PACKET_FC, start with two
registers, CPLH_PENDING and CPLD_PENDING (loaded with zero at reset).
- Calculate the number of data credits per RCB:
- CplD_PER_RCB = RCB / 16 bytes
- When the user application needs to send an non-posted request, determine the
potential number of CplH credits it might require. Use this to allocate CplD
credits with RCB granularity:
- NP_CplH = ceiling[((Start_Address mod RCB) + Request_Size) / RCB]
- NP_CplD = NP_CplH × CplD_PER_RCB
- Check these:
- CPLH_PENDING + NP_CplH < Total_CplH
- CPLD_PENDING + NP_CplD < Total_CplD
- If both inequalities are true, transmit the non-posted request, increase CPLH_PENDING by NP_CplH and CPLD_PENDING by NP_CplD.
- At the start of each incoming completion, or when that completion begins at
or crosses an RCB without ending at that RCB, decrease CPLH_PENDING by 1 and
CPLD_PENDING by CplD_PER_RCB. Any completion could cross more than one RCB. The
number of RCB crossings can be calculated by:
- RCB_CROSSED = ceiling[((Lower_Address mod RCB) + Length) / RCB]
Lower_Address and Length are fields that can be parsed from the Completion header. Alternatively, you can load a register CUR_ADDR with Lower_Address at the start of each incoming completion, increment per DW or QW as appropriate, then count an RCB whenever CUR_ADDR rolls over.
This method is less wasteful than PACKET_FC but still gives an RCB granularity. If a user application transmits I/O requests, the user application could adopt a policy of only allocating one CplD credit for each I/O read and zero CplD credits for each I/O write. The user application would have to match each tag for incoming completions with the type (Memory Write, I/O Read, I/O Write) of the original non-posted request.