I remember watching an interview with Jim Keller, where he explained that they had the front-end team doing RTL for the ARM64 ISA and the x86_64 ISA in parallel, and independently of the back-end team who were doing the core execution block.

I think this was talking about the K12, which as I understand was ultimately never released.

Perhaps the modern CPU design space looks a bit like what compilers look like today, with a core that's independent of the front end language/back end target architecture. In which case it might be a lot more modular than one would expect...

This?

>C: A few people consider you 'The Father of Zen', do you think you’d scribe to that position? Or should that go to somebody else?

JK: Perhaps one of the uncles. There were a lot of really great people on Zen. There was a methodology team that was worldwide, the SoC team was partly in Austin and partly in India, the floating-point cache was done in Colorado, the core execution front end was in Austin, the Arm front end was in Sunnyvale, and we had good technical leaders. I was in daily communication for a while with Suzanne Plummer and Steve Hale, who kind of built the front end of the Zen core, and the Colorado team. It was really good people. Mike Clark's a great architect, so we had a lot of fun, and success. Success has a lot of authors - failure has one. So that was a success. Then some teams stepped up - we moved Excavator to the Boston team, where they took over finishing the design and the physical stuff, Harry Fair and his guys did a great job on that. So there were some fairly stressful organizational changes that we did, going through that. The team all came together, so I think there was a lot of camaraderie in it. So I won't claim to be the ‘father’ - I was brought in, you know, as the instigator and the chief nudge, but part architect part transformational leader. That was fun.

_______

>Perhaps the modern CPU design space looks a bit like what compilers look like today, with a core that's independent of the front end language/back end target architecture. In which case it might be a lot more modular than one would expect...

Well, to be fair thats how you should design software (thus firmware too) stuff, those are good practices.

If you think of them as equals maybe, but it’s not uncommon for large SoCs. Maybe 30 cores in there, with probably two variants of arm, and possibly risc-v and multiple custom ISAs. But let’s say you’ve got a team of 50 hardware people and 100 software people. Most software people are concerned with the Linux kernel running on arm, and the rest of the cores are black boxes to them, might as well be hardware, they just (for example) load NN weights into dram and pop the address into a mailbox, it doesn’t matter to them that the NN accelerator is a mix of fma fabric and a small risc-v core with a team of 6 writing software for it. And the custom ISAs might be completely licensed, so it truly is a black box to everyone, but that IP for uh, usb maybe, also contains a processor and code, maybe.

But I’m not sure if the chiplet architecture adds a lot of complexity for software folks. Even more different power rails to bring up I bet.

There's already multiple ISAs on SoCs, think GPUs, DSPs and the like.

And the execution environment of each is different enough that they really have to be treated as different architectures anyway, even if they are all "Based on RISC-V" or similar.

Sharing parts of the toolchain and compiler backend may be of benefit to re-using similar architectures with tweaks for each application, but as someone who has worked on GPUs for a long time, generating working code is relatively easy. Generating performant code, however, is much harder, and the vast majority of the complexity in generating this performant code seems to have little in common with what makes serial CPU code fast, for example, so may be of less benefit than some people think.