Will Power Chips Get A Converged Arm Instruction Set Like Z Mainframe CPUs?

August 31, 2026 Timothy Prickett Morgan

One a decade for the past six decades, Big Blue launches an effort to converge its diverse system architectures. It almost never works, with the exception of the launch of the System/360 mainframes in April 1964 and the AS/400 minicomputers in June 1988. And to be fair, the AS/400 was itself based in part on technologies created in a failed convergence effort.

Back in 1986, the “Fort Knox” project sought to converge the System/4300 air-cooled, entry mainframe lines with the System/38 (from 1978) and the System/36 (from 1983), and it failed. But in the failure, the Rochester Labs took some of the bits of Fort Knox, dusted them off, and created the “Silverlake” project, delivering the truly innovative Application System/400. This machine had all the benefits of the System/38 – single level storage, integrated relational database as a file system as well as a database, asymmetric multiprocessing architecture, and advanced CISC processor, memory, and disk designs all integrated. And, it cost about half as much per unit of relational database work than an IBM mainframe of the time.

Back in 1995, through the PowerPC consortium set up between IBM, Motorola, and Apple, which sought to span computing devices from embedded systems to game consoles to PCs to datacenter servers in 1991, Big Blue and Motorola tag teamed on a converged processor called the Power 615, which not only included a Power core with an added X86 decode unit, allowing operating systems to context shift between the two, supporting applications running on the same platform at the same time. IBM had an X86 license from Intel at the time, and in fact was one of the manufacturers of X86 chips for a time, and other than AMD is still the only other company that has such a license that we know of. Interestingly the Power 615 chip plugged directly into the Intel Pentium sockets of the time The Power 615 never saw the light of day, of course, and that was apparently because the context switching between the Power decoders and the X86 decoders was painfully slow. But the Power 615 did prove a point, and one that is now relevant, that one can make a dual ISA processor.

You will also no doubt remember that IBM tried to converge the mainframe and minicomputer lines with Project ECLipz with the Power6 processor in the mid-2000s. The ECLipz plan – the ipz is for System i, System p, and System z – was apparently to emulate mainframe microcode on the Power6 RISC processor and have a single family of proprietary servers from Big Blue for the first time in its history since the System/360 was launched. That didn’t pan out, and instead ECLipz was positioned to the outside world as IBM sharing chip design components and methodologies between the z CPUs in mainframes and the Power CPUs in Power Systems. The ambition was larger, and yet unfulfilled.

Which brings us all the way forward to April of this year, when IBM and Arm made this vague announcement that had me scratching my head a little. The first sentence of the release tells you exactly what IBM is up to, but everyone, including me, read this as some sort of virtualization announcement, not a dual ISA chip announcement. And that is because IBM and Arm were being deliberately vague. Anyway, the release said the two companies were engaged in “a strategic collaboration with Arm to develop new dual‑architecture hardware that helps enterprises run future AI and data intensive workloads with greater flexibility, reliability, and security.” Again, we all read two chips in the system, not two ISAs in a chip. And that set me off down a road of thinking about Arm-based IOPs in both Power and z machines and what that might mean. But I was also in the hospital that week and had other intense things on my mind and forgot to return to this idea and chase down what the heck was going on.

Well, at Hot Chips last week, Christian Zoellin, a distinguished engineer who worked on the Power11 processor and who was previously the chief architect of the Z CPUs for the past four years, let the cat out of the bag that the future Z processor, which we presume is called “Telum III,” would support both Z and Arm instruction sets at the same time. Apparently, the context switching now happens in nanoseconds, so this dual ISA idea finally works. And what this means is that the eleven-core Telum III running at a stunning 5.7 GHz peak clock speed will not only be the world’s fastest mainframe processor, but also the world’s fastest Arm v9.3 architecture processor.

The current z17 “Telum II” chip was implemented in Samsung’s 5 nanometer processes and packed eight z17 cores, an integrated DPU, and a baby version of the Spyre matrix math accelerator (rated at 24 teraops) onto a single die. Telum II ran at 5.5 GHz, and had 36 MB of L2 cache per core plus two spares, which could be ganged up to a 360 MB virtual L3 cache.

Here’s how the Tellum III looks:

The Tellum III core has separate Z and Arm decoders, just like the Power 615 had separate Power and X86 decoders. Arm instructions are not being emulated, but explicitly run. In fact, the Tellum III core includes 2,792 AArch64 instructions and 239 AArch64 registers. The Telum III core has the full Arm v9.3 specification supported, including the SVE and SVE2 vector math units. It is not clear if there is a single vector unit that can be run in z vector or Arm SVE2 mode or if there are two unique vector engines. I strongly suspect that the SVE2 vectors are being mapped onto the 128-bit Z vector units. The implementation has the little endian Arm execution running within the CISC big endian microarchitecture of the Z cores.

Here are the architecture changes that were made to the Z core to have that second Arm ISA running side-by-side:

Zoellin did not provide that overall transistor count of the Telum III processor, and did not provide the overhead of adding the Arm v9.3 ISA to the cores, and said he needed to go count them up and added that “it’s a little bit here, and a little bit there.” He said that the decoders were most of it, which is what you would expect.

The z18 processor, as this will no doubt be called, has a pair of on-chip Spyre accelerator matrix units as well as the single DPU from the Telum II processor. The Arm ISA can access both of these units, and they can access the Linux applications running natively on the Arm part of the chip.

Logically, here is how the application stacks run on top of the Telum III z18 chip:

There is nothing surprising about the layers of hardware and software virtualization and runtimes shown above.

With that all said, let’s bring this all home to the Power Systems base and the IBM i and AIX platforms that drive that business. First of all, Power12 had damned well better have this sale Arm v9.3 architecture fusion. If running the Arm Linux stack naively is good for the Z mainframes, then it is also equally good for Power Systems – and absolutely technically not a stretch.

Moreover, if the Spyre matrix unit is the future, then the Power12 core had better use it on the chip package like the Telum processors have. The Power cores can keep their vectors and map SVE2 vectors on top of them to provide vector and tensor math for native AI applications on a future Power12 chip. But it is time to get the Z and P parts of the system house pulling in the same direction.

For the Power13 and z19 chip generations, I would argue that maybe full convergence is in order. IBM can add three decoders to a converged chip and sell one platform. . . . thereby saving a ton of money on hardware development. This might be tricky, but if Arm can be moved onto Z, then Power can as well. And frankly, this should have been done more than a decade ago.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search