Tutorials

Protocols

Learn More

Contents hide

1 Atomic Accesses

1.1 Single-copy atomicity size

1.2 Multi-copy write atomicity

1.3 Atomic transactions

1.3.1 Atomic transaction attributes

1.3.2 ID and response rules

1.3.3 Atomic support

Atomic Accesses

Atomicity is about what other agents are allowed to observe while data is being updated. A normal ordered transaction can still be non-atomic: it can complete in the correct order but still be observed as multiple smaller updates. Atomic behavior adds a stronger rule: observers must not see a partial update of the atomic element.

AXI uses three related ideas in this area:

Idea	Meaning
Single-copy atomicity size	The minimum update size that all relevant observers see as one indivisible update.
Multi-copy write atomicity	A write that becomes visible to one observer becomes visible consistently to all observers, and writes to the same location are seen in the same order.
Atomic transaction	A transaction that sends an operation to the data location, so the Subordinate performs the read-modify-write style operation atomically.

Atomic transactions are different from exclusive accesses. Exclusive accesses use a read-then-write monitor sequence and can fail if another write intervenes. Atomic transactions send the operation itself to the Subordinate and are described using AWATOP.

Single-copy atomicity size

The single-copy atomicity size is the minimum number of bytes that a transaction updates atomically. If a system supports 32-bit single-copy atomicity, no observer can see only half of a 32-bit update. If a system supports 64-bit single-copy atomicity, a naturally aligned 64-bit update can be observed as one indivisible update.

For a transaction larger than the single-copy atomicity size, memory must be updated in blocks of at least the supported atomicity size. Atomicity does not define the exact clock cycle when data is updated. It defines what other Managers are allowed to observe.

Example	Atomicity implication
32-bit linked-list pointer update	Other Managers must not observe only 16 bits updated.
64-bit counter update	Requires all communicating components to support 64-bit atomicity if software depends on 64-bit indivisibility.
Unaligned 64-bit access	Does not get a 64-bit single-copy atomic guarantee if the start address is not 8-byte aligned.
Byte-strobed write	Byte strobes do not reduce the single-copy atomicity size.

The AXI protocol does not require one universal single-copy atomicity size for every system. A system can define single-copy atomic groups. For example, a CPU, DSP, DMA, SRAM, DRAM controller, and interconnect might share 32-bit atomicity, while only the CPU, DSP, DRAM controller, and part of the interconnect share 64-bit atomicity.

Multi-copy write atomicity

A system is multi-copy atomic when writes to the same location are observed in the same order by all agents, and when a write that is observable by one agent is observable by all agents. The Multi_Copy_Atomicity property indicates support. For Issue G and later, the local specification requires this property to be True.

`Multi_Copy_Atomicity`	Default	Meaning
`True`	No	Multi-copy atomicity is supported.
`False`	Yes	Multi-copy atomicity is not supported.

Multi-copy atomicity is commonly achieved by using a single Point of Serialization for a given address, so all accesses to that address are ordered consistently. It can also require avoiding forwarding buffers that make a write visible to one observer before it is visible to all observers.

Atomic transactions

Atomic transactions send the operation to the data instead of pulling the data back to the Manager and later writing it again. This can reduce the time during which the location must be protected from other agents. Atomic transactions update the entire written location atomically, regardless of the single-copy atomicity size of the component.

AXI defines four atomic forms:

Atomic form	Channels used	Behavior	Data returned
`AtomicStore`	`AW`, `W`, `B`	Manager sends data and an operation. The Subordinate combines sent data with memory data and stores the result.	No read data.
`AtomicLoad`	`AW`, `W`, `B`, `R`	Manager sends data and an operation. The Subordinate returns the original memory value and stores the operation result.	Original memory value.
`AtomicSwap`	`AW`, `W`, `B`, `R`	Manager sends a replacement value. The Subordinate stores it and returns the original value.	Original memory value.
`AtomicCompare`	`AW`, `W`, `B`, `R`	Manager sends compare and swap values. The Subordinate writes the swap value only if the compare value matches memory.	Original memory value.

AtomicStore and AtomicLoad support these operation types:

Operation	Meaning
`ADD`	Add sent data to memory value and store the result.
`CLR`	Clear memory bits where sent data has bits set.
`EOR`	Bitwise exclusive OR.
`SET`	Set memory bits where sent data has bits set.
`SMAX` / `SMIN`	Signed maximum or minimum.
`UMAX` / `UMIN`	Unsigned maximum or minimum.

The operation and atomic form are encoded using AWATOP.

`AWATOP` pattern	Meaning
`0b000000`	Non-atomic operation.
`0b01exxx`	`AtomicStore`; `e` carries endianness for arithmetic operations and `xxx` selects the operation.
`0b10exxx`	`AtomicLoad`; `e` carries endianness for arithmetic operations and `xxx` selects the operation.
`0b110000`	`AtomicSwap`.
`0b110001`	`AtomicCompare`.

Atomic transaction attributes

Atomic transaction attributes are constrained so the Subordinate can perform the operation predictably.

Rule	Meaning
`AWLEN` and `AWSIZE` describe the write data bytes.	For `AtomicCompare`, this includes both compare and swap values.
If `AWLEN` is greater than zero, `AWSIZE` must be the full data channel width.	Multi-transfer atomic data uses full-width transfers.
Write strobes outside the legal data window must be LOW.	Atomic writes must not update bytes outside the requested atomic operand.
Write strobes inside the legal data window must be HIGH.	Atomic operands are complete; sparse updates are not allowed inside the operand.
Atomic transactions are Regular transactions.	They obey the Regular transaction subset.
`AWCACHE` and `AWDOMAIN` can use any legal combination for the interface type.	Atomic support is not limited to one memory type by this rule alone.
`AWSNOOP` must be all zeros.	If `AWSNOOP` is not zero, `AWATOP` must be all zeros.
`AWLOCK` must be deasserted.	Atomic transactions are not exclusive accesses.

For AtomicStore, AtomicLoad, and AtomicSwap, write data size is 1, 2, 4, or 8 bytes, and AWADDR must be aligned to the total write data size. AWBURST must be INCR.

For AtomicCompare, write data size is 2, 4, 8, 16, or 32 bytes because it contains both compare and swap values. The read data size is half the write data size because only the original memory value is returned. AWADDR is aligned to half the total write data size.

Figure A6.2 shows how compare and swap values are placed for AtomicCompare. If the address points to the lower half of the transaction, compare is sent first and AWBURST is INCR. If the address points to the upper half, swap is sent first and AWBURST is WRAP.

ID and response rules

A single AXI ID is used for an atomic transaction. The same ID is used for the request, the write response, and any returned read data. Therefore, the Manager must use an ID value that can be represented on both the write and read ID paths.

Atomic form	Unique-in-flight rule
`AtomicStore`	Can be issued only when there is no outstanding write-channel transaction using the same ID.
`AtomicLoad`, `AtomicSwap`, `AtomicCompare`	Can be issued only when there is no outstanding read-channel or write-channel transaction using the same ID.
Atomic transaction with read data and Unique ID signaling	If `AWIDUNQ` was asserted, `RIDUNQ` must be asserted on all response transfers.

For AtomicLoad, AtomicSwap, and AtomicCompare, the request is on AW, outbound data is on W, the original value returns on R, and the write response returns on B. The relative timing between the request and write data is not fixed. The Subordinate can wait for all write data before sending read data, and it can also send read data before accepting write data. A correct Manager must be able to handle both legal timings.

For AtomicStore, the request is on AW, outbound data is on W, and the transaction completes with a B response. There is no R response for AtomicStore.

Response point	Meaning
Write response for any atomic transaction	Indicates the transaction is visible to all required observers.
First read data for atomic transactions with read data	Also indicates visibility to all required observers.
`AtomicCompare` success or failure	Not encoded as a separate response outcome. Software must inspect the returned original value to determine whether the compare matched.
Unsupported atomic at a target	Can receive an appropriate error response.

For AtomicLoad, AtomicSwap, and AtomicCompare, the Subordinate must send the correct number of read data transfers even if the write response is DECERR or SLVERR. If there is an error with the write part, it is recommended that the error be visible on both read and write responses so a Manager does not miss it.

Atomic support

Atomic support is controlled by the Atomic_Transactions property.

`Atomic_Transactions`	Default	Meaning
`True`	No	Atomic transactions are supported.
`False`	Yes	Atomic transactions are not supported.

If a Subordinate or interconnect declares support for atomic transactions, it must support all operation types, sizes, and endianness. If atomic support is only valid for certain memory types or address regions, unsupported atomic requests must receive an appropriate error response.

Component	Support rule
Manager	Can include `BROADCASTATOMIC`; when present and LOW, the Manager must not issue atomic transactions.
Subordinate	Atomic support is optional. Unsupported atomic requests must complete with a legal response.
Interconnect	Atomic support is optional. If unsupported, attached Managers must be configured not to generate atomic transactions.
Device transaction	Must be passed to the endpoint Subordinate if supported; an atomic transaction must not be passed to a component that does not support atomics.

The number of bytes returned must still match the transaction described by ARLEN and ARSIZE. Chunking changes the order and grouping of returned chunks; it does not change the requested byte count.

AXI Protocol