PCI Express Compiler User Guide Does Not Clarify that Posted Requests and Completions May Be Blocked if rx_st_mask Is Asserted - PCI Express Compiler User Guide Does Not Clarify that Posted Requests and Completions May Be Blocked if rx_st_mask Is Asserted Description When the Application Layer asserts rx_st_mask to allow Posted Requests or Completions to bypass Non-Posted Requests in the PCIe hard IP RX Buffer, the Posted Requests and Completions may still be blocked by Non-Posted Configuration Space Requests. Asserting rx_st_mask does allow Posted Requests or Completions to bypass Non-Posted Memory Space or I/O Space requests that are routed to the Application Layer. As soon as a Non-Posted Configuration Space request (or a Non-Posted Memory or I/O space request that is being handled as an Unsupported Request) is encountered in the stream of requests in the RX Buffer while rx_st_mask is asserted, subsequent TLPs remain in the RX Buffer until all prior Non-Posted requests have been accepted by the Application Layer logic and rx_st_mask is deasserted. This issue affects the hard IP implementation of the PCI Express IP core in Arria II GX, Cyclone IV GX, and Stratix IV GX devices when the rx_st_mask is being used for performance enhancement or to block Non-Posted requests. Resolution Do not design your application layer logic so that rx_st_mask remains asserted until certain Posted Requests or Completions are received. As long as rx_st_mask is eventually deasserted without waiting for posted requests or completions, the blocking Non-Posted Configuration Requests will eventually complete. This issue is documented in version 11.0 of the IP Compiler for PCI Express User Guide . Custom Fields values: ['novalue'] Troubleshooting novalue True ['novalue'] ['FPGA Dev Tools Quartus II Software'] 11.0 10.0 ['Programmable Logic Devices'] ['novalue'] ['novalue'] ['novalue']