Article ID: 000076983 Content Type: Troubleshooting Last Reviewed: 12/13/2011

Potential for Loss of Order between Read and Write Transactions in RapidIO I/O Avalon-MM Master

Environment

    Quartus® II Subscription Edition
BUILT IN - ARTICLE INTRO SECOND COMPONENT

Critical Issue

Description

A RapidIO MegaCore function I/O Avalon-MM master’s read and write ports may present read and write transactions on the Avalon-MM interface in a different order than they appeared on the RapidIO link. More specifically, if the RapidIO IP core receives a read request packet on the RapidIO link soon after receiving several write request packets, the read transaction might complete before all of the write transactions complete.

The following figure illustrates an example of circumstances in which the problem can occur.

I/O Avalon-MM Master State From Which r5 Read Transaction Can Pass One or More Write Transactions

In the figure, the RapidIO IP core Avalon-MM master write port has a write request transaction w0 ready to send to Avalon-MM slave 0, and the RapidIO IP core Avalon-MM master read port has a read request transaction r5 ready to send to the same Avalon-MM slave, Avalon-MM slave 0. The transaction numbering indicates the order in which the transactions arrived from the Transport layer, which is the order in which the transactions should complete. However, transaction ordering is lost in the following example scenario:

  1. The master write port sends the w0 request to Avalon-MM slave 0.
  2. Avalon-MM slave 0 responds by asserting waitrequest.
  3. The master read port sends the r5 request to Avalon-MM slave 0.
  4. Avalon-MM slave 0 retrieves and transfers the data to the Avalon-MM master read port in response to the r5 request — before the w0 transaction completes.

The same scenario could occur with w1, w2, w3, or w4 being deferred. Similarly, w0 might be deferred but still complete before r5, but w1 not complete before r5, and so on. The same scenario could also theoretically occur with an r0 read transaction and w1 write transaction. However, the RapidIO specification does not preclude a write transaction from passing a read transaction.

Resolution

To prevent an NREAD transaction from passing any in a sequence of NWRITE transactions that precede it, ensure an adequate delay between the write transactions and the read transaction on the RapidIO link. For example, you could make the final NWRITE transaction an NWRITE_R transaction instead, and send the NREAD transaction on the link only after you receive the NWRITE_R response.

This issue will be fixed in a future version of the RapidIO MegaCore function.

Related Products

This article applies to 1 products

Intel® Programmable Devices

1