The user application signal, trn_rnp_ok_n, exists so that a customer can take advantage of the PCI Express ordering rules and stall Non-Posted packets while allowing Posted and Completion packets to proceed on the receive interface. However, if the user deasserts this signal to the point where 64 Completions or Posted packets bypass a stalled non-posted packet, this will cause the receive path to lock up.
It is not typical to deassert trn_rnp_ok_n for such long periods of time, but some applications may do this. If your application is susceptible to this, then follow this workaround:
The user can keep trn_rnp_ok_n deasserted as long as trn_rfc_nph_av is 8. If trn_rfc_nph_av goes below 8, the user must then start a counter to count received Posted packets. Note that trn_rfc_nph_av may fluctuate briefly between 8 and lower values as packets are drained into the wrapper. The wrapper will buffer some NP packets. During any type of fluctuation, each time trn_rfc_nph_av goes to 8 the count can be restarted. Once the count reaches 30, the user must assert trn_rnp_ok_n and drain all NP packets until trn_rfc_nph_av is 8 again. At that point trn_rnp_ok_n can be deasserted once more.
04/23/2010 - Updated for ISE 12.1 and v1.14
03/11/2010 - Initial Release for v1.13