Re:Intel to license x86 CPU cores for use in custom processors
by lionkor on Wednesday April 19, 2023 @03:58AM
(#35625570)
> Brennan provided an example: customers will be able to build a chip with licensed Xeon cores and match them up with an AI accelerator that's based on the RISC-V specification or Arm IP. Intel has also created what it calls a chiplet chassis, in which dies of x86, Arm and RISC-V cores can be put together and packaged to form a coherent chip.
Re:Intel to license x86 CPU cores for use in custom processors
by lloydatkinson on Wednesday April 19, 2023 @04:22AM
(#35625729)
> 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.
Re:Intel to license x86 CPU cores for use in custom processors
by webdevver on Wednesday April 19, 2023 @05:32AM
(#35626163)
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...
Re:Intel to license x86 CPU cores for use in custom processors
by hardware2win on Wednesday April 19, 2023 @07:24AM
(#35626852)
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.
Re:Intel to license x86 CPU cores for use in custom processors
by uxp100 on Wednesday April 19, 2023 @09:15AM
(#35627744)
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.
Re:Intel to license x86 CPU cores for use in custom processors
by kimixa on Wednesday April 19, 2023 @05:33PM
(#35633580)
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.
Re:Intel to license x86 CPU cores for use in custom processors
by unwind on Wednesday April 19, 2023 @06:57AM
(#35626659)
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].
Re:Intel to license x86 CPU cores for use in custom processors
by bogantech on Wednesday April 19, 2023 @08:20AM
(#35627215)
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
Re:Intel to license x86 CPU cores for use in custom processors
by senttoschool on Wednesday April 19, 2023 @08:24AM
(#35627251)
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.
Re:Intel to license x86 CPU cores for use in custom processors
by snvzz on Wednesday April 19, 2023 @06:04PM
(#35633896)
>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.
Re:Intel to license x86 CPU cores for use in custom processors
by marssaxman on Wednesday April 19, 2023 @12:24PM
(#35630118)
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. 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 are common - and now Intel wants Xeon cores to be an option too.
> 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.
Thats the meat of it
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.
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...
>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.
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.
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.
Never again.
[1]: https://en.wikipedia.org/wiki/Intel_Edison
[2]: https://en.wikipedia.org/wiki/Intel_Quark
[1]: https://en.wikipedia.org/wiki/Intel_Galileo
It's a lot more work to use that than any Arm or AVR micro
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.
Hyperscaler?
If they're going to buy their own, wouldn't it make more sense to use ARM like AWS with Graviton?
Even a hardware-based x86 frontend. It could e.g. run usermode code uninterrupted, escaping to RISC-V on syscalls, interrupts, exceptions.
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
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.
> 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.