4.2.1. Description

The arbiter is described in the following sections:

Arbitration process

The arbitration process consists of four stages, as shown in Figure 4.6:

  1. The master requests access to the bus using HBUSREQx.

  2. The HGRANTx signal is asserted, showing that the master is granted the bus when the current transfer completes.

  3. The master owns the address/control signals.

  4. The master owns the data bus.

Figure 4.6. Arbitration process

Burst operation

When a master is performing a fixed length burst (WRAP4, INCR4, WRAP8, INCR8, WRAP16, or INCR16), the master can lower its request signal when the burst has started. Therefore, the arbiter must include a counter which counts the transfer in the burst, enabling it to efficiently hand over ownership of the bus when the burst completes.

Locked operation

A master can assert the HLOCK signal so that the next transfers it performs on the bus is considered as a part of a locked sequence of transfers. This means that no other bus master is given access to the bus until the locked sequence has completed.

The master must deassert the HLOCK signal when the address phase of the last transfer in the locked sequence has started.

The arbiter asserts the HMASTLOCK signal during the address phase of all the transfers in the locked sequence. It is important that any slave which can issue either a SPLIT or RETRY response deals with a locked transfer as soon as possible, because no other master is given access to the bus until the locked transfer has completed.

At the end of a locked sequence of transfers the arbiter keeps the master granted on the bus until the data phase of the final locked transfer has completed. The arbiter can assert the HGRANT signal to another master when the final data phase is in progress. However, if the arbiter detects that the final data phase is going to complete with either a SPLIT or RETRY response, it must change HGRANT back to ensure that either the dummy master (in the case of a SPLIT) or the locked master (in the case of a RETRY) remains granted the bus.

Split responses

The arbiter has a special function that it must perform for transfers which receive a SPLIT response. The arbiter must ensure that the master which received the SPLIT response is not granted again until the slave has indicated that it is ready to complete the transfer (using the HSPLITx signals).

Default bus master

When no masters are requesting the bus, it can be granted to a default bus master. The default master has the advantage that, when it is granted the bus by default, it does not have to go through the Request/Grant stages before it can access the bus. It is recommended that the master which is most likely to use the bus is made the default master.

Dummy bus master

The dummy bus master is a concept which enables the bus to remain synchronized when no real masters are granted the bus. The dummy master, when granted, simply drives the transfer type to IDLE, ensuring that the bus continues to operate. By convention, the dummy master is master number 0.

Locked operation and split responses

The desired operation of the arbiter when a locked bus master receives a SPLIT response is to grant the dummy bus master (which only performs IDLE transfers) until the master is unsplit and can return to the bus to complete the locked transfer. A dedicated section of the arbiter is used to detect a SPLIT response on a locked bus master. This forces the HGRANT and HMASTER outputs to grant the dummy bus master until the master is unsplit.

Additional information

The following is applicable during the arbitration process:

  • It is possible to be granted the bus without requesting it. This occurs if the master is the default master, which is granted the bus when no other master is requesting.

  • The above point also means that it is possible to be granted the bus in the same cycle that it is requested. This can occur if the master is coincidentally granted the bus in the same cycle that it asserts its request signal.

  • It is possible that the Grant signal is asserted and then removed before the current transfer completes. This can happen during a transfer with a large number of wait states, where only a low priority master is requesting the bus during the early stages of the transfer, but a higher priority master then asserts its request before the current transfer has completed. This process is acceptable because the Grant signal is only sampled by masters when HREADY is HIGH.

  • At the end of an undefined length burst, the master can drop its request signal when it has been granted the bus to start the last transfer in the burst. If the penultimate transfer in the burst is zero wait state, the master remains granted the bus for an additional transfer at the end of the sequence.

Copyright © 2001 ARM Limited. All rights reserved.ARM DDI 0226A
Non-Confidential