From Transactions to Flits: The Journey Through UALink Transaction Layer

AI accelerators are getting faster, but their performance increasingly depends on how quickly they can exchange data. In a multi-accelerator system, one device may finish computing a tensor, gradient block, or intermediate result while another device is already waiting for it. When communication cannot keep pace with computation, expensive accelerator cycles are lost.

UALink is designed to remove that bottleneck inside the scale-up system. It gives accelerators a direct, high-bandwidth, low-latency path to peer memory using read, write, and atomic operations. Instead of treating communication as a separate networking task, UALink makes peer-memory access part of the accelerator’s memory-oriented transaction flow.

Consider one such transaction. A 256-byte result leaves accelerator A as one WriteFull request and four data beats. At accelerator B, the same request and data beats emerge. In between, however, the transaction is split, packed, routed, repacked, and reconstructed. The layer responsible for preserving its meaning throughout that journey is the UALink Transaction Layer (TL).

UALink TL transforms, transports, and reconstructs a 256-byte WriteFull.

TL Receives One Transaction

UPLI presents a WriteFull request and four associated 64-byte data beats on the originator data channel. TL must preserve the command, destination accelerator ID, transaction tag, and association between the request and all four data beats.

TL Builds the Flit Sequence

Tx TL places the WriteFull request in a control field and splits the 256-byte payload into eight 32-byte data half-flits. The control field tells Rx TL what transaction is coming and how much data belongs to it. Because WriteFull marks every byte as valid, no separate byte-enable half-flit is needed.

One possible mapping of a 256-byte WriteFull into TL control and data half-flits.

TL Preserves the Transaction Across the Fabric

At the switch, the ingress TL reconstructs the WriteFull request and its associated data beats. The switch core uses the destination accelerator ID to select the outgoing port, and the switch egress TL builds a new flit sequence for the next link. Flit packing may change, but the request and its associated data must remain correctly sequenced and associated.

Rx TL Reconstructs the Original UPLI Transaction

Rx TL decodes the WriteFull control field, knows that eight data half-flits belong to the transaction, and collects them in sequence. It then recreates the corresponding UPLI WriteFull request and four 64-byte data beats for accelerator B’s completer.

TL Carries Completion and Error Meaning

Completion: After completing the write, accelerator B returns a write response containing the completion status and original transaction tag. Accelerator B’s Tx TL encodes the write response, and accelerator A’s Rx TL reconstructs it so the originator can retire the correct request.

Corruption: If a 64-byte data beat is marked corrupted, its two corresponding 32-byte data half-flits are replaced with poisoned data TL message half-flits using message type 0x20. Rx TL then reconstructs the corresponding UPLI beat with OrigDataError asserted. The data is not trusted, but the transaction sequence remains intact.

Why TL Verification Gets Interesting

At the UPLI boundary, a WriteFull transaction appears simple: one request and four data beats. Within the transaction layer, however, the request may be compressed, its payload is divided into eight data half-flits, credits determine when it can advance, and switches may reconstruct and repack it for the next link.

Any of these steps can fail without stopping the protocol. The flit stream may remain valid while the reconstructed transaction is incorrect. This is what makes TL verification challenging, particularly in areas such as:

Credit-controlled progress. Command and data credits must be consumed and returned correctly on every link. When a transaction stalls, it can be difficult to tell expected backpressure from a credit-accounting error.

Compression and reconstruction. A request compressed to two sectors depends on a matching entry in the receiver’s address cache. If the Tx and Rx address caches fall out of sync, the reconstructed WriteFull can silently differ from the original.

Transaction association. Each data half-flit must remain associated with the correct request, including after switch repacking, and each completion must be matched to the correct outstanding request. With many transactions in flight, a broken association can still look like valid traffic.

Error propagation. A data beat marked corrupted must be reconstructed with OrigDataError asserted on the corresponding UPLI beat, without disrupting the transaction sequence. The poison indication must reach the correct beat, not just the correct transaction.

WriteFull is only one example; reads and atomics follow the same principle. A transaction may change form many times on its journey, but its meaning must not.

Cadence UALink VIP helps verify that this meaning is preserved. Built-in protocol checkers flag violations, while transaction-aware visibility across the UPLI and TL interfaces connects flit-level activity to transaction-level behavior, shortening the path from a valid-looking flit stream to the root cause of an incorrect transaction.

More information on Cadence UALink VIP is available at the Simulation VIP for UALink. You can also explore Cadence Simulation VIP solutions for other protocols. If you have any queries, feel free to contact us at talk_to_vip_expert@cadence.com