Details

Published: Thursday, 02 April 2020 02:21

Hits: 3020

AHB:

ARM microcontrollers have proprietery AMBA AHB  Lite bus. It's simply called AHB (advanced high performance bus). It connects ARM processor Bus signals to peripherals connected to ARM processor. These include peripherals like Memory (Flash, SRAM, ROM), devices (keyboard, mouse, etc) or devices communicating via I2C, SPI, etc. AHB is the backbone of ARM microcontrollers. Other ARM bus i/f are merely some modification or extension of AHB spec, so it's important to understand this protocol.

A typical AHB design consists of:

One AHB Master: This is usually ARM processor that is the master. It initiates read and write operations.

Multiple AHB slaves: These slaves respond to read and write operations depending on their addr range.

AHB decoder: This decoder decodes add, and provides select signal for various slaves, so that appr slave can be chosen to respond.

AHB Signals:

Any bus would need to have a clock, reset and data /control signals. For AHB, these are the signals:

A. Clock/Reset signals: Below signals are driven by neither master nor slave, but by independent controller. This controller usually sits on the master side, but may be anywhere.

1. HCLK = This clk times all bus transfers. All signal timings are related to rising edge of HCLK. HCLK can be generated by any clk source and used to fire flops on both master and slave.

2. HRESETn = This active low signal is used to reset system and the bus. HRESETn can be generated by any Reset controller, and used to reset flops on both master and slave. Many other bus i/f do not have Reset signal as part of Bus i/f as reset signal is generated locally to devices and ued to reset the bus.

B. Write signals: Below signals are driven by the master:

3. HADDR[31:0] = 32 bit system addr bus. It's driven by the master, and indicates which addr to read/write.

4. HWDATA[31:0] = This is write data to be written to slaves. It can be any number of bits, but is usually 32 bits.

5. HWRITE = This indicates whether xfer is read or write. When high, it indicates irt's a write, and when low, it's a read.

Below signals are optional, and needed for burst xfers or slaves which need additional info. None of the below signals are supported by slaves in simple microcontrollers.

6. HSIZE[2:0] = Indicates size of xfer, from 8 bits (1 byte) to 1024 bits (128 bytes). This signal is used in conjunction of HBURST[2:0] to determine addr boundary for wwrapping bursts.

7. HBURST[2:0] = Indicates if the transfer forms part of a burst. 000= single xfer or no burst, while others rep incrementing or wrapping burst

8. HPROT[3:0] = The protection control signals provide additional protection information about a bus access to the slaves. HPROT[3]=cacheable, HPROT[2]=bufferable, HPROT[1]=provileged, HPROT[0]=data/opcode

9. HTRANS[1:0] = Indicates the type of current xfer, which can be: 00=Idle, 01=busy, 10=Non-sequential, 11=sequential. Single xfer as well as 1st xfer of burst are non-seq, while all remaining xfers of burst are seq. Idle and busy are used by master to indicate to slave that it's busy, and hence not sening anything valid, so slave should just ignore this xfer. 10 or non-seq is the most commonly used xfer type.

C. Read signals: Below signals are driven by Slave:

10. HRDATA[31:0] = This is read data read from slaves. It can be any number of bits, but is usually 32 bits.

11. HREADY = This signal is driven low by slave to extend a xfer. This is the only ack signal provided by slave to indicate to master if it's finished with the transaction. Most of the simpler bus protocols don't have any ack signal from slave, and master transfers data sequentially and just expects the slave to consume it correctly. If the slave is busy, there is no way for master to know it. This limits the flexibility of such protocols. So, ARM AMBA protocols include this ack signal, so that Master can serve slaves of all kind (i.e it the slave is running slow or it's internal fifo is filled, it can keep pulling HREADY low until it's ready for next xfer)

12. HRESP[1:0] = This provides additional info on status of xfer. 00=OKAY, 01=ERROR, 10=RETRY, 11=SPLIT

D. Decode signals: Below signal is driven by addr decoder:

13. HSELx = This signal is driven by central addr decoder for each slave on the bus, where x indicates the slave number (So, HSEL0 is driven to slave 0, while HSEL15 is driven to slave 15)

Multiple Masters:

Though typical ARM microcontrollers have only 1 master, which is the ARM processor, there are cases where maore than 1 Master is needed. To take care of this, AHB protocol allows multiple bus masters. To support this, an arbiter is needed, and few extra control signals are required. Upto 16 Bus Masters are supported from Number 0 to Number 15.

HBUSREQx = This is signal from Bus Master "x" to aribter requesting that this bus master requires the bus. Each of the Masters has HBUSREQx signal (signals HBUSREQ0 to HBUSREQ15)

HLOCKx = This is to indicate Locked xfer, i.e master pulls this high, if it wants locked access to the bus (i.e no other master should be granted the bus, until this signal goes low)

HGRANTx = This is the ack signal from arbiter to the master, indicating that master x is currently the highest priority master.

HMASTER[3:0] = This is the signal from aribiter to slaves, to indicate which master is currently performing a xfer. It is used by slaves which support SPLIT transactions

HMASTLOCK = This signal is from arbiter to Masters?? to indicate that the current master is performing a locked seq of xfer.

HSPLITx[15:0] = This 16 bit signal is from each slave to arbiter  to indicate which bus master should be allowed to reattempt a split transaction. 16 bits are for 16 bus masters. This is needed only for SPLIT capable slaves.

Data Transfer Phases:

Master and slave transfer data each of which consist of 2 phases:

1. Addr phase: 1 cycle phase where Addr (HADDR) and control signals are put on Bus. HWRITE signal being high indicates write operation, while low indicates read. It's fixed 1 cycle operation, so slaves need to be able to capture the addr/ctl signlas within a cycle.

2. Data phase: multi cycle phase where Data (HWDATA/HRDATA) is put on bus. Thus data phase follows addr phase. We put addr and read/write signal in 1st cycle and then in 2nd cycle we either read or write data. What if data cannot be provided on next cycle by slave, just because it's too slow. HREADY signal solves this problem, by working as a feedback signal from slave. As long as the HREADY signal is high, master assumes that slave has finsihed the operation, and master can proceed with next xfer. However, if the slave is not ready, then it can pull it low. This signals to the master that it should keep driving the write data or keep waiting for read data until HREADY is taken HIGH again by the slave. HRESP is another signal driven by slave, which when low indicates sucess. Usually, HRESP signal is permanently tied to low, since it's of not much use for simpler designs.

One obvious differerence that we see between read and write is that verything needed for read tran is provided in 1st cycle, and by end of next cycle, read data is returned back. Memory is busing doing read during 2nd cycle. However for write, write data is not provided in 1st cycle. Though Addr and control signals are provided in 1st cycle, in absence of write data, memory cannot process write during 2nd cycle. write data is latched on input flop of memory at end of 2nd cycle, and then in 3rd cycle, internal write of memory takes place. So, for read, memory is busy during 2nd cycle, but for write it's busy during 3rd cycle. If write data would have been provided on AHB during 1st cycle (along with Addr and control signal), then write of memory would have taken in 2nd cycle (similar to read). However, that's a protocol that AHB chose for read and write. Since memory expects all signals to be available at the same time, we have to locally buffer Addr and control signals for write for 1 cycle, and then it pass it on to memory when write data arrives in next cycle. This also creates collision in memory when there is read followed by a write, and it has to be handled in sram controller. ARM IP already includes code in sram controller to take care of this situation