2.11.2. Regulation based on outstanding transactions

The CCI-400 offers an additional mechanism for regulating traffic flows for the benefit of overall performance. Each ACE-Lite slave interface has an optional, programmable mechanism for limiting the number of outstanding read and write transactions, where an Outstanding Transaction (OT) is a read request without read data, or a write request without a response. This can be used where QoS value regulation is not effective because the system is not sensitive to QoS value. The disadvantage of this form of regulation is that it might stall the master even when the system is idle and traffic from this master is not affecting the performance of other masters.

You can characterize a sequence of transactions, with periods when there are no outstanding transactions, by using a fractional outstanding transaction number. For example, if requests occur every 100 cycles, but it only takes 50 cycles for the last response to arrive, then this corresponds to 0.5 OTs. The sum of the integer and fractional values represents a maximum of the mean number of OTs in a sliding window and, consequently, also over all time. If the fractional part is 0, the number of OTs is never permitted to exceed the integer part. If the fractional part is not 0, the number of OTs is not permitted to exceed one more than the integer part. This mean value is only achieved if the attached master maintains the maximum number of transactions it is able to issue at all times. Therefore, if the integer part is 0 and the fractional part is 0.5, and transactions have a lifespan of 50 cycles, then a master can issue a transaction. It finishes after 50 cycles and it cannot issue the next transaction until 100 cycles, maintaining a mean number of outstanding transactions as 0.5.

If you enable regulation, the following programmable values set the permitted number of outstanding transactions:


  • Outstanding transaction regulation only counts transactions with a zero QoS value.

  • Outstanding transaction regulation does not count or override transactions that have no data associated with them. These transactions are:

    • CleanUnique.

    • MakeUnique.

    • CleanShared.

    • CleanInvalid.

    • MakeInvalid.

    • Evict.

    • Barriers.

    • DVM transactions.

Read Queue Slot Reservation

Each master interface of the CCI-400 has a queue that stores read requests. If this becomes full with low priority requests, higher priority requests are blocked. To avoid this, the CCI-400 reserves a number of slots for high priority requests and a number of slots for high or medium priority requests. Table 2.6 shows a summary of the possible configurations.

Table 2.6. Slots reserved for high and medium priority traffic in each master interface

Read tracker size, as determined by the Mlx_R_MAX parameterNumber of reserved slots for medium or high priority requestsNumber of reserved slots for only high priority requests

For example, assume the read tracker size is 32, implying that three slots are reserved for medium to high priority requests and one slot is reserved for high priority requests. In this case:

  • The maximum number of slots available for high priority requests is 32.

  • The maximum number of slots available for medium priority requests is 32 - 1 = 31.

  • The maximum number of slots available for low priority requests is 32 - 3 - 1 = 28.

You can configure the QoS values that are considered as high and medium priority at the design time using the R_THRESHOLD_UPPER and R_THRESHOLD_LOWER parameters.

Avoidance of Head-of-Line Blocking

Head-of-line blocking occurs when an interface is shared by transactions with different priorities and a high priority transaction is blocked by an earlier lower priority transaction. To prevent this for read transactions, CCI-400 has an input, ARQOSARB. You can use this signal to temporarily promote the priority of the earlier transaction until it enters the request queue. However, when the transaction is in the queue, higher priority transactions can overtake it.


ARQOSARB is a 4-bit QoS value that is sampled when ARVALID and ARREADY are both HIGH, but unlike other AR payload signals, it is permitted to change priority when ARVALID is HIGH and ARREADY is LOW.

Copyright © 2011-2014 ARM. All rights reserved.ARM DDI 0470J