The recent update of the AMBA® 5 ACE/AXI specification introduces a number of significant performance improvements which help to align the protocol to the more recent AMBA® 5 CHI (Coherent Hub Interface) specification. One of the most prominent features is introduction of atomic transactions. Before we take a close look at this new class of transactions, let’s look back in time. Previous generations of AMBA ACE/AXI protocols have included support of exclusive accesses which relied on the semaphore-type operations. A typical exclusive access had the following steps: 1) A master performs an exclusive read from a remote address 2) Master locally modifies the data obtained via exclusive read transaction 3) Sometime later, the master attempts to complete the exclusive operation by performing an exclusive write to the same address with modified data 4) If no other master has written to that location since the exclusive read access, the exclusive access is considered successful and the memory update takes place. If another master has written to that location since the exclusive read access, the exclusive access is considered failed and the memory location is not updated. Essentially, it means that data had to be pulled from a remote location towards the master which performed the required modification of data, and then pushed the update back to the previous location. This mechanism has worked quite well but suffered from an intrinsic malady – a non-deterministic latency. This was especially pronounced when the data resided at a significant distance from the agent which wished to modify it. The new class of atomic transactions solves the non-deterministic latency problem in the most elegant way. Instead of pulling the data towards the agent for modification, atomic transactions provide modification instructions to the location where the data resides. Let’s consider the following case. A CPU (Master) wants to update a memory location by adding a certain numerical value to the original data residing at the location. All the master needs to do is to provide data to be added to the original one, as well as clear instructions to the target where the original data resides. This is easily achieved by the new AtomicStore transaction which sends a single data value with an address and operation type to be performed at the target location. Upon receiving the AtomicStore transaction, the target locally updates the memory location adding the newly supplied data to the original one. Once the operation is performed, the target signals response back to the master, notifying it about success or failure of the operation. Voila! A single atomic transaction replaced what previously required two exclusive access transactions. What’s more, by moving modification to the data location, it makes the entire operation more efficient and deterministic. Obviously, the new class of atomic transactions is not limited to the AtomicStore transaction with ADD operation. We will explore other atomic transactions and use cases in the next installment of the blog. Stay tuned!![]()
↧