2.11 Read and write transaction scheduling

The bridge contains a transaction scheduler because the AXI5 to AHB5 bridge can receive an AXI read transaction and a write transaction in the same clk cycle.

To improve processor performance, the bridge contains arbiter logic that gives priority to read transactions but it also prevents back-to-back read transactions from stalling write transactions indefinitely.

When an incoming read transaction arrives, the arbiter logic can:

This 7:1 read-write accept policy can prevent a system livelock or starvation issue. The arbitration occurs after an AXI transaction completes or after a sparse write beat.

Note:

The arbitration logic is defined from the point of view of the bridge core and not the AXI slave interface. Therefore, the arbitration point is observable externally, when the input stage (AW, AR, W channel) register slices are configured as BYPASS.

Arbitration of a sparse write transaction

The following figure shows the arbitration of a sparse write transaction (awsparse is HIGH).

Figure 2-1 Arbitration of a sparse write transaction
To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


In the figure:

  • r{num} or w{num} represents the incoming, full AXI transactions.
  • b{num} represents a non-sparse AHB write beat, which is shown in orange, for the w1 write transaction.
  • b{num}_{piece} represents a sparse AHB write beat, which is shown in light orange, for the w1 write transaction.

In the figure, at time:

t7After 7 back-to-back reads, the bridge processes the w1 transaction.
t8-t10The bridge issues a non-sparse write beat, b1, and splits the b2 sparse write beat into the b2_1 and b2_2 transfers.
t10Arbitration occurs after the sparse beat. The bridge processes read transactions, since reads have a higher priority than writes.
t17After 7 back-to-back reads, the bridge processes the w1 transaction.
t18-t21The bridge issues non-sparse write beat, b3, and splits the b4 sparse write beat into the b4_1, b4_2, and b4_3 transfers.
t22

Arbitration occurs after sparse beat b4. The w1 transaction continues because there is no incoming read transaction that has priority.

Write transaction w1 completes with beat b5.

t23Arbitration occurs, read transaction r15 has priority over the write transaction, w2.
t24Arbitration occurs, the bridge processes the w2 transaction because there are no incoming read transactions.
t25-t26The bridge has no incoming transactions.

Arbitration when write transaction is either non-sparse or HWSTRB_ENABLE == ON

The bridge does not interrupt any non-sparse write transactions because it might translate into a non-interruptible fixed-length AHB burst such as INCR4. Incoming AXI non-sparse writes always complete before the next arbitration occurs.

The following figure shows the arbitration of a non-sparse write transaction (awsparse is LOW). The r{num} and w{num} identifiers represent full AXI transactions.

Figure 2-2 Arbitration of a non-sparse write transaction
To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Non-Confidential - BetaPDF file icon PDF version101375_0000_00_en
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.