ARM AMBA AHB Notes:

SITE HOME

The AHB bus has 2 phases, Address Phase and Data phase.

HREADY. Whats the fuss?

HREADY is an output signal from every slave, which is routed to every Master and every slave.
This means each slave will have 2 HREADY signals
HREADY_in and HREADY_out.

HREADY output signal from an AHB Slave is and indication by the slave to 'extend' the data phase of AHB transfer.
This can typically happen if the slave cannot respond immediately, and therefore this slave asserts the HREADY
signal output to a value of '0', to tell the Master to extend the data phase, so that the slave have enough time
to respond.
 
Address phase cannot be extended by definition, hence all slaves must sample the address during this time.

However it is important to remember that if the data phase which is being 'extended' by the Slave
coincides with the address phase, then this will have an side effect of this address phase being extended

HREADY signal is both, input and output from Slaves.

Q. Why HREADY an o/p from slave?
A. HREADY is an o/p from slave so that it can extend the data phases if it needs more time as said above.

Q. Why HREADY is an input to slave?
A. This is for all the slaves on the bus to know if any slave on the system has requested to 'extend' the data phase,
and if so, then any other slave may not start respond to any 'address' phase which may have coincided with the
data phase.
This corner case typically happens when a slave say S1 decides to extend the last data phase of an burst transfer.
The last  data phase of a burst transfer can happen while the address bus is indicating a new transfer to a new
slave say S2. If the slave S1 decides to pull the HREADY low, on the last 'data phase' then the
slave S2 must know that S1 has pulled down the HREADY low,  and it (S2) must not
respond to this address phase which occurs in the same cycle as the
last data phase of Slave S1, as a previous transfer to slave S1 has not yet concluded.
And the only way S2 can know if S1 has pulled the HREADY low, is route the
HREADY output from S1 to HREADY input to S2.
Infact the HREADY output from every slave is 'ANDed' together to give a system-wide HREADY signal,
which is fed to every slave as HREADY input.
So if any slave asserts the HREADY low, this system-wide HREADY signal, which is the AND of all
the HREADY outputs of all the Slaves, goes low. And since this ANDed HREADY signal goes to each slave
as in input, each slave waits for this ANDed HREADY to go '1', before they can respond.
Hence each AHB slave must have an HREADY output to be able to extend the data phase
and each AHB slave must have an HREADY input to know if any other Slave on the system is
requesting a data phase extension, and if the input HREADY to any slave is '0', then this slave must wait
for its HREADY input to go '1', before it can respond to any AHB request.

The figure below and following explanation makes it more clear.




A. The Arbiter Grants a Master the bus on the Last clock cycle of the data phase of the previous Master,
because the arbiter keeps track of the number of transfers and it knows the burst size and all characteristics.
Say an INCR4 burst is currently ongoing by Master1 to Slave2. The data phase will be 4 clock cycles,
if the HREADY from Slave2 is always high.
The Dataphase will however be 5 clock cycles if say for example the Slave2 extends the DP3 into two
clock cycles say DP3_0 and DP3_1, HREADY being '0' in DP3_0.
In absence of HREADY being an input to slave, another slave in the system say Slave3, will
see its HSEL go '1' in DP3_0, and it will start responding in DP3_1, which will result in data corruption.
But Since HREADY is also availsble to this Slave3, it will come to konw that even when it has its HSEL go to '1'



The recommended default value of HREADY is '1'.

Q. When would a master sample 'hready'
A. Since 'hready' is only related to data phase, the Master would sample 'hready' at the N+1th edge, where N is the clock edge, at which it issued the data.


When a master is granted the bus and is performing a fixed length burst it is not
necessary to continue to request the bus in order to complete the burst. The arbiter
observes the progress of the burst and uses the HBURST[2:0] signals to determine how
many transfers are required by the master.


For undefined length bursts the master should continue to assert the request until it has
started the last transfer. The arbiter cannot predict when to change the arbitration at the
end of an undefined length burst


Next -> (AHB Quick Reference)