Every AXI transaction carries an ID: AWID or ARID on the address, BID or RID on the response. The ID is how AXI lets transactions complete out of order. Transactions with the same ID must complete in the order they were issued; transactions with different IDs may complete in any order. This article explains the ordering rules, shows a slave that returns a fast read before a slow one, and covers how an interconnect extends IDs.
9 min read | Intermediate
What You'll Learn
- State the AXI ordering rules for reads, writes and between them
- Use IDs to let fast transactions overtake slow ones
- Explain what an interconnect does to transaction IDs
- Decide when a master must wait for a response before issuing more
The Ordering Rules
- Transactions from different masters have no ordering restrictions.
- Transactions from the same master with different IDs have no ordering restrictions: they can complete in any order.
- Read data for transactions with the same ARID must return in the order the addresses were issued.
- Writes with the same AWID must complete in the order the addresses were issued.
- There is no ordering between reads and writes, even when
ARIDequalsAWID.
A useful way to think about it: one AXI port with IDs behaves like several logical ports, one per ID, each of which is in order. A slave that does not care can process everything in order and simply copy the ID from the address to the response; that is always legal. What every slave must do is return the right ID: RID must match the ARID of the data, and BID the AWID.
Read Data Out of Order
The example slave has two read slots and two regions: addresses from 0x800 upwards are slow (8 cycles), lower addresses are fast (2 cycles). Each beat returns its own address as data, so the log shows where every beat came from. A slot may send its data when the data is ready and no older slot holds the same ID:
// A slot may send when its data is ready and no older slot holds the same ID
wire ready0 = s_busy[0] && cycle >= s_time[0] && !(s_busy[1] && s_id[1] == s_id[0] && s_seq[1] < s_seq[0]);
wire ready1 = s_busy[1] && cycle >= s_time[1] && !(s_busy[0] && s_id[0] == s_id[1] && s_seq[0] < s_seq[1]);
wire pick = (ready0 && ready1) ? (s_seq[1] < s_seq[0]) : ready1; // the older one if both are ready
The master issues a slow read with ID 1, then a fast read with ID 2, and later a slow and a fast read that both use ID 3:
read(1, 12'h800, 3, WORD, INCR, 0, 0); // slow region
read(2, 12'h100, 3, WORD, INCR, 0, 0); // fast region
read(3, 12'h900, 3, WORD, INCR, 0, 12); // slow region
read(3, 12'h200, 3, WORD, INCR, 0, 0); // fast region, same ID
35 AR id=1 addr=0x800 len=3 size=4 INCR 45 AR id=2 addr=0x100 len=3 size=4 INCR 75 R id=2 data=0x00000100 OKAY 85 R id=2 data=0x00000104 OKAY 95 R id=2 data=0x00000108 OKAY 105 R id=2 data=0x0000010c OKAY last 125 R id=1 data=0x00000800 OKAY 135 R id=1 data=0x00000804 OKAY 145 R id=1 data=0x00000808 OKAY 155 R id=1 data=0x0000080c OKAY last 175 AR id=3 addr=0x900 len=3 size=4 INCR 185 AR id=3 addr=0x200 len=3 size=4 INCR 255 R id=3 data=0x00000900 OKAY 265 R id=3 data=0x00000904 OKAY 275 R id=3 data=0x00000908 OKAY 285 R id=3 data=0x0000090c OKAY last 305 R id=3 data=0x00000200 OKAY 315 R id=3 data=0x00000204 OKAY 325 R id=3 data=0x00000208 OKAY 335 R id=3 data=0x0000020c OKAY last
With different IDs, the fast read finishes before the slow read has sent a single beat. With the same ID, the fast read waits behind the slow one even though its data was ready long before, because same-ID data must return in order. That is the trade-off a master makes when it chooses IDs: the same ID buys ordering, different IDs buy speed.
Quick Check
Q: A processor fetches instructions and loads data through the same AXI port. Why might it use different IDs for the two?
Show Answer
So that a data load from a slow peripheral does not hold up instruction fetches from fast memory. The two streams have no ordering requirement between them, so different IDs let each complete as soon as possible.
Interleaving
Read data of transactions with different IDs may also be interleaved: a slave could send a beat of ID 1, then a beat of ID 2, and so on. The example slave sends each burst complete, which is simpler and common, but a master must be able to accept interleaved read data. Write data, in contrast, is never interleaved in AXI4: the beats of each write burst are consecutive on W, and bursts arrive in address order. That is why AXI4 dropped the AXI3 WID signal.
Reads and Writes Are Not Ordered
Even with the same ID, AXI does not order a read against a write. If a master writes a location and then reads it, the read may overtake the write and return the old value. When a read depends on a write, or a write on a read, the master must wait until the first transaction has completed: for a write, until it receives the response on B; for a read, until it receives the last data beat. Sending all the write data is not enough.
Quick Check
Q: A master writes a value to address A with ID 1 and then reads A with ID 1. Is it guaranteed to read the new value?
Show Answer
No. The same ID orders reads among reads and writes among writes, but never a read against a write. The master must wait for the write response before issuing the read.
IDs in an Interconnect
When several masters share an interconnect, their IDs could collide: two masters might both use ID 0. The interconnect solves this by appending the master's port number to the ID on the way to the slave. On the way back, it uses those extra bits to route RID or BID to the right master, and removes them. Two consequences:
- a master never needs to know which IDs other masters use;
- the ID at a slave interface is wider than at a master interface. The specification recommends up to 4 ID bits at masters, up to 4 more for the interconnect, and support for 8 bits at slaves.
A master that needs no reordering may tie its IDs to a constant, such as zero.
Running It in ChipVerify Lab
The example contains the out-of-order slave and these reads. Change the IDs and predict the order of the data before you run it.
Common Mistakes
Mistake #1: Returning the wrong ID
A slave must copy ARID to RID and AWID to BID exactly. A slave with a narrower ID field than the interconnect drives breaks the routing of responses.
Mistake #2: Expecting a read to see an earlier write
Reads and writes are not ordered, even with the same ID. Wait for the write response before reading the location back.
Mistake #3: Reordering same-ID transactions
A slave may reorder only across different IDs. Returning same-ID data out of order breaks the master's assumptions silently.
Practice Exercise
Challenge: Same ID
Change the ID of the fast read from 2 to 1, so both of the first two reads use ID 1. Predict the order of the data, then run it.
Hint
Same-ID data must come back in the order of the addresses, however fast the second one is.
Solution
35 AR id=1 addr=0x800 len=3 size=4 INCR 45 AR id=1 addr=0x100 len=3 size=4 INCR 115 R id=1 data=0x00000800 OKAY 125 R id=1 data=0x00000804 OKAY 135 R id=1 data=0x00000808 OKAY 145 R id=1 data=0x0000080c OKAY last 165 R id=1 data=0x00000100 OKAY 175 R id=1 data=0x00000104 OKAY 185 R id=1 data=0x00000108 OKAY 195 R id=1 data=0x0000010c OKAY last
Now the slow read comes first and the fast read follows it. The fast data was ready at about 75 ns but waited until 165 ns: the cost of asking for order.
Open the ready-made example in the lab and run the simulation.
Summary
- Same-ID transactions complete in issue order; different-ID transactions may complete in any order.
- A slave must return the matching ID on
RIDandBID; processing everything in order is always legal. - Read data of different IDs may be interleaved; AXI4 write data never is.
- Reads and writes are never ordered against each other; wait for the response when one depends on the other.
- An interconnect widens IDs with the master port number to route responses back.
