Hi,
1) ARBAR/AWBAR
These two signals are mentioned : ARBAR, AWBAR but in the AMBA5 spec F2.1 Signal Matrix, these signals are listed as "N" (must not be present), page 419 and 420 of 440 pages.
So are these signals used on the ACE5 interface or there is a mistake in this Table F2.2 Signal Matrix table and the "N" should be "Y"?
Please confirm if the Table F2.2 is correct or incorrect for ARBAR and AWBAR.
2) AWSTASHNID, AWSTASHNIDEN, AWSTASHLPID, AWSTASHLPIDEN
These are Optional signals for ACE5-Lite.
There are NO ARSTASH* signals. Please confirm.
3) Table F2.2 AC, CR, CD channel signals are ONLY used for ACE5 (not ACE5-Lite).
Please confirm.
4) Table F2.2 BROADCAST* signals are defined to be OM (optional MASTER).
From the description it seems like these are inputs to the MASTER to define some functional settings
and do not form part of the ACE5 or AXI5 interface/protocol.
Thanks,
David
armchronos said:1) ARBAR/AWBAR
The table is correct. Section E1.2 states -
"Barrier transactions are not supported in ACE5 and ACE5-Lite variant interfaces. ACE5 and ACE5-Lite masters that require specific ordering or observability must delay the issue of dependent requests until earlier transactions are complete."
armchronos said:2) AWSTASHNID, AWSTASHNIDEN, AWSTASHLPID, AWSTASHLPIDEN
Correct. As E2.2.2 states - " A stash transaction is sent using the AW channel, with or without an associated transfer on the W channel. The permitted combinations of control signals for stash requests is shown in Table E2-4."
armchronos said:3) Table F2.2 AC, CR, CD channel signals are ONLY used for ACE5 (not ACE5-Lite).
Technically not quite true. AC and CR are used for ACE5-LiteDVM interfaces.
ACE-Lite masters do not have caches, and so do not need to be snooped, meaning they don't need these snoop signals. However, the DVM flow uses the AC and CR channels, and so these are required if DVMs are supported.
armchronos said:4) Table F2.2 BROADCAST* signals are defined to be OM (optional MASTER).
Correct - see D12.1 for more information.
Thanks for your previous reply. It's helping me to clarify the AMBA5 signals.
For ARBAR, AWBAR, it's quite confusing
On one hand, it mentions barrier transactions and then the next sentence it says they are not supported in ACE5 and ACE5-Lite.
Then when are these used ?
The ACE protocol also provides:• Barrier transactions that guarantee transaction ordering within a system, see Barriers on page D1-164.Barrier transactions are not supported in ACE5 and ACE5-Lite variant interfaces.
So it looks like ARBAR/AWBAR is used as an extension of AXI4 to support cache.
It's not too clear to me. See D1.3.1 Changes to existing AXI4 channels.
Are these new signals ARDOMAIN/ARSNOOP/ARBAR , AWDOMAIN/AWSNOOP/AWBAR/AWUNIQUE/RRESP[3:2]
only used with an existing AXI4 channel and adding cache support without the full ACE5 protocol support?
Please clarify for me when to use the ARBAR/AWBAR, looks like its for this special AXI4 case and ACE-Lite usage only.
Table E2-4 shows AWBAR[0] / AWLOCK in the middle column and the E2.2.2 Stash transaction signaling mentioned ACE5-Lite.
So that's why I get this AWBAR confused as ACE5.
Need your clarfication on proper usage of ARBAR/AWBAR.
Barriers are described because they can be used in AMBA4 ACE (see D8). They have been removed from ACE5.
Barriers are not exactly about enabling cache usage - its about guaranteeing that a transaction is complete (and so visible to other masters) up to a certain point within the system.
For example, in most systems seeing the B response guarantees that a write is visible to other masters. However, systems with devices that give an early write response can mean a B response does not give this guarantee. Barriers could then be used to provide this guarantee - i.e. when the barrier completes, this write is now visible.
ACE5 requires systems to be multi-copy atomic, meaning that the B response always guarantees that a write is visible to all other masters (amongst other guarantees).
D1.3.1 is describing the ACE signals that were added to AXI4 channels to enable hardware. Effectively, Section D is describing ACE. Section E describes ACE5, which is an evolution of ACE.
I'm not sure why Table E2-4 describes AWBAR. That appears to be superfluous information.