Intel to license x86 CPU cores for use in custom processors(theregister.com)
theregister.com
Intel to license x86 CPU cores for use in custom processors
https://www.theregister.com/2022/02/14/intel_x86_licensing/
25 comments
> in which dies of x86, Arm and RISC-V cores
There must be a point where not only multicore, not only multi chip, but multi architecture as well, simply must be a hindrance and massive hurdle to develop and design for.
There must be a point where not only multicore, not only multi chip, but multi architecture as well, simply must be a hindrance and massive hurdle to develop and design for.
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.
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.
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.
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...
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.
>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.
April 2023, https://www.anandtech.com/show/18811/intel-ifs-partners-up-w...
> Intel's recent agreement with Arm allows Intel to act as an impartial fabricator and manufacturer of chips outside of its Client Computing Group (CCG) and other arms, including its graphics (AXG) division. Not just Arm but Arm's current partners will also be able to take full advantage of Intel's open system foundry model, which includes packaging, software, and chiplets as part of the agreement.
> Intel's recent agreement with Arm allows Intel to act as an impartial fabricator and manufacturer of chips outside of its Client Computing Group (CCG) and other arms, including its graphics (AXG) division. Not just Arm but Arm's current partners will also be able to take full advantage of Intel's open system foundry model, which includes packaging, software, and chiplets as part of the agreement.
What would be the point of this?
Who actually wants to build custom processors with Intel x86 cores?
Obviously, Intel is not going to let you compete with their own products so they will have license limits or gimp the cores available for licensing some how.
Who actually wants to build custom processors with Intel x86 cores?
Obviously, Intel is not going to let you compete with their own products so they will have license limits or gimp the cores available for licensing some how.
Think "processor" in the sense of "coprocessor", not in the sense of "CPU". There are enormous numbers of chips which embed multiple processor cores, often with heterogeneous architectures; baseband processors, network switches, all kinds of SoCs. Consider Intel's own Movidius VPU, which includes two different LEON cores (SPARC) and 16 SHAVE cores (VLIW vector processors) all on the same die. There are many options for the cores used in such a device - ARM, RISC-V, MIPS, others - and now Intel wants Xeon cores to be an option too.
Microsoft and Windows laptop vendors.
A laptop with arm and x86 cores might allow Microsoft to speed up its transition from x86 to ARM in the laptop/mobile world.
No idea on viability but sounds fun :D
A laptop with arm and x86 cores might allow Microsoft to speed up its transition from x86 to ARM in the laptop/mobile world.
No idea on viability but sounds fun :D
>A laptop with arm and x86 cores might allow Microsoft to speed up its transition from x86 to ARM in the laptop/mobile world.
I simply don't see this transition happening. Microsoft is working on a RISC-V port (as per RISC-V CTO talks in the RISC-V Summit), and Qualcomm is unlikely to release many more generations of ARM-based SoCs (as per the lawsuit, and as per Qualcomm's own talks in the RISC-V Summit).
The only way forward is RISC-V.
x86 is finally going away, and RISC-V is its replacement.
I simply don't see this transition happening. Microsoft is working on a RISC-V port (as per RISC-V CTO talks in the RISC-V Summit), and Qualcomm is unlikely to release many more generations of ARM-based SoCs (as per the lawsuit, and as per Qualcomm's own talks in the RISC-V Summit).
The only way forward is RISC-V.
x86 is finally going away, and RISC-V is its replacement.
I also think that the corporate-strategy angle for this makes the concept useless. Intel will accidentally clobber you
Well you could add some x86 specific extensions to RISC-V to significantly speed up x86 emulation?
> Who actually wants to build custom processors with Intel x86 cores?
Hyperscaler?
Hyperscaler?
Why would they build their own over buying from AMD or Intel?
If they're going to buy their own, wouldn't it make more sense to use ARM like AWS with Graviton?
If they're going to buy their own, wouldn't it make more sense to use ARM like AWS with Graviton?
I’d like to see tiny Intel machines, like raspberry pi competition.
There was the Intel Edison [1] back in 2014-2017, it turned out to not be a great success. The initial version was based on a dual-core Intel Quark x86 clocked at 400 MHz [2].
[1]: https://en.wikipedia.org/wiki/Intel_Edison
[2]: https://en.wikipedia.org/wiki/Intel_Quark
[1]: https://en.wikipedia.org/wiki/Intel_Edison
[2]: https://en.wikipedia.org/wiki/Intel_Quark
As an electronics/(retro)computing hobbyist the biggest problem to me about Quark is that it starts in real mode and to do any bare metal stuff you would have to jump through the 10 thousand hoops to just run some code.
It's a lot more work to use that than any Arm or AVR micro
It's a lot more work to use that than any Arm or AVR micro
Intel Galileo [1] too.
[1]: https://en.wikipedia.org/wiki/Intel_Galileo
[1]: https://en.wikipedia.org/wiki/Intel_Galileo
Don't forget the Minnowboard.
Intel Joule?
Never again.
Never again.
[2022]
... but why?
Thats the meat of it