6.1.3.1.3 WRR Arbitration

In this mode, the slave arbitration parameters, programmable weight (SW_WEIGHT_<master>), and eSRAM slave maximum latency (SW_MAX_LAT_ESRAM<0/1> of ESRAM_MAX_LAT) can be configured to operate as WRR arbitration. The slave arbiter operates on a round robin basis, with each master having a maximum of N consecutive access opportunities to the slave in each round of arbitration. The value of N is determined by the programmed weight for the master and eSRAM slave maximum latency. Programmable weight values can be changed dynamically. The following figure depicts the WRR slave arbitration scheme. At each stage, the arbiter checks whether that master is requesting access. If so, the master performs N transfers equal to its programmed weight and then has to re-arbitrate for the bus. For a WRR master, the WRR priority in the round robin sequence changes after the programmed number of transfers. Due to its highest priority, the Cortex-M3 processor DCode bus master is allowed to perform transfers as long as there are transfers to complete. However, if a locked transaction occurs, the master issuing the lock (HMASTLOCK = 1) maintains ownership of the slave until the locked transaction completes.

WRR with fixed priority arbitration allows more efficient usage of slave bandwidth in cases where the slaves have a penalty when transitioning from one master to another. When both the Ethernet MAC and Cortex-M3 processor ICode/DCode interfaces are performing write and read AHB bursts to eSRAM, this scheme groups together a maximum of N Ethernet MAC accesses followed by a maximum of M Cortex-M3 processor accesses (even if AHB bursts of greater than N or M transfers are in progress from the master’s point of view). Due to the fact that the eSRAM AHB controller inserts an IDLE cycle every time there is a write followed by a read, enabling WRR can increase the effective eSRAM bandwidth during this time from 66% to 94% of the theoretical maximum. If a sequence of locked transfers is in progress, the locked master remains selected by the slave arbiter until the lock sequence is finished, regardless of the number of transfers. For the case described, the values of N and M are SW_WEIGHT_MAC and SW_WEIGHT_HPDMA in the MASTER_WEIGHT0_CR control register.

Arbitration for Non-eSRAM Slaves

In non-eSRAM slaves, any WRR master getting access to the slave can perform uninterrupted transactions equal to its programmed weight before re-arbitrating for the slave. Thus, for example, if FIC_1 is programmed with a weight of 8, it can do 8 continuous transactions with the slave even if the high priority master is requesting access to the slave. Only after completing 8 transfers, the high priority master will gain access to the slave.

The following table gives an arbitration scenario for a non-eSRAM slave. In this scenario, master M5 (FIC_1) starts a burst of 12 transfers (reads typically for accesses to eNVM) to slave S2 (eNVM_0) in the first clock cycle. In the second clock, fixed priority master M1 (DCode bus) bus tries to access the same slave. Since the programmed weight of M5 master is 8, the M1 master does not gain access to the slave until M5 completes eight transfers. As listed in the table, the M1 master gains access to the slave only after the M5 master completes 8 transfers, which is in the 9th clock cycle. The M5 master has to re-arbitrate for the slave to complete the remaining transfers. So the maximum latency seen by the Cortex-M3 processor bus M1 is equal to the programmed weight of 8.