ARM AMBA AHB Notes:
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
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
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
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
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