Zacas: atomic compare-and-swap

[davidharrishmc]

Implements the Zacas extension: amocas.w, amocas.d, amocas.q, and amocas.b/amocas.h where Zabha is enabled. Every form passes its architectural test and runs clean against ImperasDV in lockstep on both rv64gc and rv32gc.

The three problems worth explaining

amocas needs a third source operand. It reads rs1 for the address, rs2 for the swap value, and rd for the compare value, but the register file has two read ports. Rather than add a port, the instruction stalls one cycle in Decode and borrows the rs2 port to read rd. The borrowed cycle captures the compare value and the normal cycle reads the swap value, so both operands arrive through one port. This also handles the pair forms for free, since the two reads come off the same pair output on successive cycles.

A failed comparison still writes. The specification allows an unsuccessful amocas either to skip the memory write or to write back the value it loaded. Writing the old value back was the better fit here. The alternative, cancelling the write, needs a late signal into the cache state machine: unlike a failed store-conditional, whose outcome is known from the reservation registers before the access is issued, a compare-and-swap only resolves after the data comes back, by which point the read-modify-write is already in flight. Writing the old value back makes a failed amocas an ordinary AMO whose result happens to equal what was read, so the store path, byte masks, and fault logic are untouched. The cost is that a failed swap dirties the line; the comparison result is a named signal, so a cancel can be added later without restructuring.

The pair forms need a wide path, which already existed. amocas.d on RV32 and amocas.q on RV64 operate on twice XLEN. LLEN now widens to 2*XLEN when Zacas is enabled, exactly the way quad-precision floats widen it, so the pair forms reuse the load/store path that flq already exercises. The wide compare and select happen in the LSU where the read data is already LLEN wide, and the loaded high half writes rd+1 through the register file's pair write port.

Other changes

• Register file. The paired form holds registers as pairs and supports a pair write. Its array previously started at index 1, leaving the pair holding x0 and x1 without storage, so x1 read out of range; it now starts at 0 with x0 forced to read as zero. Half-register writes write only the addressed half rather than reading the pair back and merging, which drops a read port.
• Parameters. ZACAS_SUPPORTED and ZABHA_SUPPORTED, each with an assertion that it requires Zaamo. Enabled on rv64gc and rv32gc. The Zabha parameter and assertion text matches Zabha support #1877 verbatim so the two branches merge without conflict.
• Reserved encodings. The pair forms require even rd and rs2; odd encodings raise an illegal instruction.
• Width-masked comparison. amocas.w on RV64 compares only the low 32 bits of rd, so the comparison is masked to the access width.
• LSU floating-point write mux. Two branches assumed LLEN equalled the larger of XLEN and FLEN, which stops being true once Zacas widens it. Both operands are now extended to LLEN.
• Lockstep configs. cpu/Zabha=T and cpu/Zacas=T added to the rv64gc and rv32gc ImperasDV settings.
• Trace wrapper. It reaches the register file by hierarchical name, so it now selects the correct half of a pair, and it reports both registers of a pair write. Without the latter, a pair amocas left rd+1 invisible to lockstep even though the architectural state was correct.

Testing

form	rv64gc	rv32gc
amocas.b, amocas.h	arch test passes, lockstep clean	arch test passes
amocas.w	arch test passes, lockstep clean	arch test passes, lockstep clean
amocas.d	arch test passes, lockstep clean	pair form; arch test passes, lockstep clean
amocas.q	pair form; arch test passes, lockstep clean	n/a

Lint is clean on all configurations, and the regression shows no new failures. Note that enabling Zacas routes every register access through the paired register file, so the regression passing is also the evidence that it is a correct drop-in.

The matching arch-test configuration changes are on the zmop branch of the arch-test fork. They declare both extensions for the cvw cores and raise the memory region's atomic support from AMOArithmetic, which does not permit compare-and-swap, so Sail was rejecting every amocas on a platform-attribute check before it reached the core.

🤖 Generated with Claude Code