Hi All,
I have a question on AMBA5 AHB feature : Stable_between_Clock property
The AMBA5 AHB Specification describes:
Signals that are described as being stable are required to remain at the same value when sampled at different rising clock edges in an extended transfer. However, it is possible that these signals can glitch after clock edges, returning to the same value as previously driven.
AHB5 defines the Stable_Between_Clock property to determine if an interface guarantees that signals that are required to be stable remain stable between rising clock edges.
If this property is True, it is guaranteed that signals that are required to be stable remain stable and glitch free between rising clock edges.
If this property is False, or is not defined, signals can glitch between rising clock edges.
Also the Specification says during waited transfer the transfer type(htrans) can change from IDLE -> NONSEQ, BUSY -> SEQ (for fixed length burst), BUSY -> any other transfer type (for undefined length burst).
My question here is,
1.What are the AHB5 signals that needs to remain stable between the clock during an extended transfer (waited transfer) other than HWDATA.?
2. Does AHB5 support multi master, as the AHB5 spec does not provide information about Arbiter signals ?
Thanks !!
Swetha,
1. HWDATA is the only signal that must remain stable during extended transfers.
As you have observed, HTRANS can change under some circumstances, and when HTRANS is allowed to change, all other address phase control signals can also change to signal the new transfer required. As well as the sequences you listed when HTRANS can change, the other time HTRANS can change during a waited transfer is when the slave returns an ERROR response, when the master can change HTRANS to IDLE, meaning all the other address phase controls can also change.
For the data phase signals, HRDATA and HEXOKAY are only required to be at their final value when HREADY is driven high by the slave, so could in theory change while HREADY is low. HRESP needs to be able to change while HREADY is low when returning an ERROR response. So none of the data phase signals (other than HWDATA) must remain stable during extended transfers.
2. AHB5 is really an update to the AMBA 3 AHB-lite protocol, so only one master is supported on the bus, and no arbitration signals like you would have seen in AMBA 2 AHB. Where a system has multiple masters using AHB5 (or AHB-lite), the expectation would be that you would use a multi-layer interconnect to access shared slaves, this way supporting all masters active at the same time, something you couldn't have in an AHB system where all masters share one bus.
Hope that helps,
JD
Thanks a lot JD !!!
As you said AHB5 is an update of AMBA3 AHB-lite and supports only one master, I have a doubt in the explanation provided for Exclusive transfers in the AHB5 Spec .
As per the Spec:
• If no other master has written to that location since the Exclusive Read transfer, the Exclusive Write transfer is successful and updates memory.
• If another master has written to that location since the Exclusive Read transfer, the Exclusive Write transfer is failed and the memory location is not updated.
The Exclusive Access Monitor must be capable of concurrently monitoring at least one address location for each Exclusive access capable master in the system.
Here, does another master mean more than 1 master is supported.? I am bit confused in this part. Can you please explain me this?
Thanks in Advance !!
Swetha
The old AMBA 2 AHB protocol, with support for multiple masters on the same bus using HBUSREQ and HGRANT signals to control which master was granted at any one time, meant that most masters on that single bus were sitting IDLE waiting to be granted, so not good for performance where more than one master had transfers to perform at the same time.
To get round that performance issue, designers started using multi-layer AHB interconnects (sometimes referred to as busmatrix components), where each AHB master (or a small group of masters not wanting to use the bus at the same time) would be connected to a "layer" of this busmatrix. This allowed multiple masters to be active at the same time on different layers, so much better system performance, and only when they tried to access the same shared system slave would there be any arbitration logic to decide which master layer was stalled, and which got access to the slave. This arbitration logic stalling would be done using wait states on the HREADY signal, rather than HGRANT.
As this multi-layer approach usually didn't require the AMBA 2 AHB HBUSREQ and HGRANT controls because most system implementations had a single master on each layer, this lead to the AMBA 3 AHB-lite protocol, where only a single master is supported on the bus, but you can still have multiple masters accessing shared slaves via a multi-layer busmatrix.
So as AMBA 5 AHB is essentially AMBA 3 AHB-lite with new added features, it still only has one master on the bus, but you can have multiple masters in a multi-layer (multi-bus) busmatrix system, each then possibly using exclusive accesses to control access to a shared slave.
Does that clarify things ?