IBM put an Arm decoder in a mainframe core, and only half the consolidation pitch has a native path

The reused parts tell you how this was built. The branch prediction area is Telum II's design, carried over without changes ^[9], and the fetch engine leans on virtual cache tags to pull from cache without paying translation overhead ^[10]. The new work sits behind that: IBM wrote automation to consume Arm's XML machine description and work out how those instructions move through the core ^[11], and simultaneous multithreading is exposed to both instruction sets rather than reserved for the native one ^[12].

Generating a decoder from a machine-readable spec is also a maintenance decision. If v9.3 arrived through tooling ^[11][4], tracking later Arm revisions becomes a build problem rather than a design problem, which matters on a product line that ships new silicon every few years rather than every few quarters ^[2].

The reliability claim needs an editor. IBM puts availability at 99.999999 percent and says that equals 0.032 seconds of downtime a year ^[7]. Eight nines against a 365-day year is 0.315 seconds; 0.032 seconds is nine nines ^[2]. The two halves of the same sentence differ by a factor of ten, and the smaller number is the one that will end up on slides. IBM's stated intent is that broader software support must not cost mainframe reliability ^[7], so it is worth knowing which of the two figures the engineering was actually signed off against.

The generational numbers want the same care. Telum II, introduced in 2024, ran eight cores at up to 5.5 GHz ^[2], while the new part quotes 5.7 GHz as a base ^[1]. A peak and a base are not the same measurement, so treat the delta as indicative: at face value the socket moves from 44 to 62.7 core-GHz, about 43 percent more ^[1]. Private L2 stays at 36 MB per core, with virtual L3 at 432 MB and virtual L4 at 3.5 GB ^[13].

The accelerator is where the clearest trade sits. Up to 4 TB/s is described as 20x what LPDDR5 delivered ^[14], which puts the outgoing memory system at roughly 200 GB/s ^[3]. Capacity went down to buy that bandwidth ^[14], so what fits on a card becomes the constraint that bites before bandwidth does. That is the likeliest reason the 16 cores picked up FP4 and MXFP4 handling ^[15]: quantised weights are how a 96 GB budget stays useful ^[14].

So the practical question for a z-shop is not whether Arm binaries run. IBM says they run unmodified, and that Arm virtual machines behave as though they are on native Arm silicon because they are ^[5]. The question is how much of the estate is aarch64 today, and whether the AI portion of it fits in 96 GB per accelerator once it gets there ^[14].