Intel CEO: Clients Want Custom x86-Based SoCs
tomshardware.com
tomshardware.com
Nowadays embedded development is revolving around ARM pretty heavily. Maybe RISC-V in the future, but for now, it's ARM, definitely not x86.
Had Intel done that 20-25 years ago the story might be completely different.
Hot off their success in the 80s with the desktop market, in the 90s Intel decided to go up market and target workstations, datacenter, and mainframes. They launched the P6 architecture with HPC in mind and eschewed power efficiency.
By the mid/late 90s they didn't have an x86 product that could work well in the mobile space let alone the embedded space. The recognized that the laptop market was poised to explode and started work on Pentium M which eschewed their P6 derived Netburst architecture for something closer to the P5.
ARM wisely chose not to compete with Intel and instead went for markets Intel wasn't in. This included mobile and embedded. At the time Intel was trying to optimize x86 for Laptops (Pentium M / Core), ARM was working down market from embedded to microcontrollers (ARM M).
When Smartphones started to take off, ARM was positioned to be the processor of choice due to it's focus on low power and efficiency AND the fact that anyone could design their own SoC around it. Intel on the other hand was still trying to scale down x86 from the laptop space and chose to develop their SoCs entirely themselves.
Intel also has this on going problem of eschewing SoCs for discrete chips because they want to sell you as many chips as possible.
Fast forward to today and Intel's Atom line is comparable to ARM's high performance line (ignore Apple) in terms of performance and battery but it lacks the SoC integration you see in products from Qualcomm, Mediatek, and Samsung.
Embedded space are high volume low margin business, why waste their Wafer capacity for that?
4G Modem is a loss leader, why use latest node on it when they could be used for Server CPU at 100x the revenue and profits.
Mobile SoC is also a high volume and low margin business, we cant use our most advance, industry leading fab for that. Let's partner with a Chinese companies and use contra revenue to gain market share. And oh, let's use TSMC because they are cheaper.
ARM also has business model that doesn't make sense from Intel's perspective. Earning a measly xx cents per unit on IP? ( Yes Intel actually laughed about it in 00s era )
Did I mention XScale?
And I could go on and rant about it for hours.....
One of the fundamental challenges for x86 at that time would have been the CISC ISA and decoder complexity overhead. The overhead of the full CISC ISA was just unacceptable for an embedded application. That's probably why Intel was fiddling around with XScale around that time.
With the P6 lineage, the x86 instructions were decomposed into micro-ops, RISC like instructions, that were executed by the CPU. I've read that decoders at the time accounted for up to 10% of power consumed. Intel really didn't start to address this problem until Pentium M and later Core.
Had Intel launched something alongside P6 in the early 90s they might be relevant in that space but they were targeting the datacenter and mainframe space at that time so they were thinking big, not small.
Someone at Intel must've thought the same thing and even executed it - they bought StrongARM in 1997!
But then they put it to the torch in 2003 and EOL'd everything so that you could see Windows bluescreens in your ATM and kiosks later that decade.
To add some history - AMD's semi-custom segment dates back prior to Su's CEO seat. It was initiated in 2012-2013 under CEO Rory Read [1], although Su was heavily involved in it back then too (as SVP, and eventually as COO, before taking over as CEO in 2014). It ended up primarily targeting game consoles, though it claimed residual wins in other markets too.
It turned out to be an excellent move at the time, as it proved to be a bit of a lifeline during AMD's rough years. And modern-day AMD continues executing on it well.
I also agree w/your general point - given AMD's history doing this kind of thing, it's tough to see what Intel could do in this segment that AMD couldn't do better.
[1] https://www.anandtech.com/Show/Index/7281?cPage=4&all=False&...
Put another way two thirds are not interested in x86.
Sorry to say that this article reads like an Intel press release.
> One of the key elements of Intel's IDM 2.0 strategy is the company's newly created Intel Foundry Services (IFS) group that will manufacture chips for others. This group can operate as a classic foundry making any chips its clients want: Arm-based system-on-chips, RISC-V-based controllers, tensor processing units (TPUs), or graphics processing units (GPUs), just to name a few options.
> But Intel can naturally add a unique sauce to its IFS offering: highly competitive general-purpose x86 cores as well as an extremely broad portfolio of its silicon-proven IPs. Earlier this year Intel said that it was in discussion with over 100 of potential IFS customers and recently it revealed that about 1/3 of them were interested in custom x86-based SoCs.
> "Of the 100+ customers, I'd say about a third of them are interested in that x86ish of our ecosystem," said Gelsinger.
1/3 of _potential Intel foundry clients_ want x86. Of course there are plenty of companies investigating the new foundry option coming onboard with Samsung/TSMC lead times being what they are that have no interest in porting their products to x86.
1. https://www.tomshardware.com/features/amd-vs-intel-cpus
2. https://www.tomshardware.com/reviews/best-performance-cpus,5...
Here's a passing reference to what I think is the same scandal I was thinking of, at least:
https://hardforum.com/threads/warm-dual-core-opteron-165-new...
It's not hard to find discussion of other cases of bias:
https://forums.overclockers.co.uk/posts/32078480
https://www.youtube.com/watch?v=a87Iy7avG7o
Unfortunately I don't have a lot of time to find better sources. You can make up your own mind, but I don't trust them to be impartial.
Plenty of people agreeing with me on various forums: https://www.google.com/search?q=tomshardware+biased+-inurl%3...
We aren't talking about Intel's customers in general, but those who are using or planning to use Intel's new fab services. In other words, 1/3 of those interested in creating their own chip are also interested in custom x86 design.
> Sorry to say that this article reads like an Intel press release.
This isn't an article but an interview with Intel's CEO. As Intel officially as it gets
Lower power consumption would be nice too. We don't always have mains power.
25+ years isn't unheard of, but "in any capacity" absolutely is. There's no foundry on this planet that is continuing to produce you CPUs 25 years from now if your batch size is an order of 50 units.
It would require not only the tooling but also past test runs of all of the verification passes to confirm that the new design doesn't have a flaw.
There are a lot of products that don't change on tech industry timescales (e.g. all those stories of organizations scavenging replacement chips from eBay). It could be really compelling to have the option to use components that are likely be available for 50 years.
But by all means the embedded stuff, motor controllers, instruments and so on should have simple interfaces and either last 50 years or be easily replaced 50 years in the future. This is largely true for industrial stuff. In industrial plants you rarely even have a serial connection to instruments. Instead you will have something like a 4-20mA analogue signal.
I also wouldn't be surprised (and hope) it goes the other way and in 50 years development using FPGAs is as easy banging stuff out in an IDE and making ASICs is as easy compiling and dollars per chip in small quantities.
Modern x86 processors are used in embedded. While there are security concerns if connected to the internet, not all are. These processors don't drive the low level controls, but they do drive the UI - customers want touch screens and other modern UI controls for their equipment. They absolutely do buy equipment expecting it to last for more than 50 years, my company makes a lot of money supplying parts for machines we made in the 1950s - modern machines make us more money, but those old ones are still doing the job for customers who couldn't afford to buy new.
My comment is a reply to the parent but also to the article which I could have clarified. In retrospect I am probably replying to the wrong comment to give my opinion. I think a few CPU part numbers per generation guaranteed to be available for decades is a good idea (and I think it's true already). I also think custom SOCs is a good idea. I just don't think there is feasibility for both custom and long life in the same part.
Then, to reply to you, are you using x86 CPUs in a part of a system that will actually last 50 years? I used to work in automation and perhaps I have a bias based on what I saw in my projects. I was generally paid to automate old machines (oldest was about 60 years old) or upgrade the automation of machines. Sometimes we would keep ancient PLCs running for decades, and sometimes replace them (with a newer PLC that can certainly run for decades). For worn-out mechanical parts we would usually find an old drawing, or reverse engineer an old part and make a new identical one.
But for HMIs, dataloggers and webservers, everyone seemed to be trending towards using industrial products built around x86. These would always be secondary systems and interface to the PLC, but not actually be critical components (well, maybe 1 out of several HMIs is required). But, these tended to be replaced every 5-15 years if they stopped working or a new feature was required, and not maintained with spare parts. It doesn't seem that the manufacturers of these things keep them available for a long time either.
Out of interest, I just looked up the current product line of Beijers HMI panels (I used to mainly use them in my projects), and they seem to be built around Atom, Celeron and iMX6 (great CPU btw) CPUs. Having seen inside the older products, I doubt these have standardized sockets to drop in a new CPU 30 years from now. In fact, the models I used to buy 15 years ago are no longer available and the only option is to buy a newer model and translate the old UI screens to the UI model (either manually or automatically). They do still work with ancient PLCs though.
My thesis is for these, or one of the x86-based "soft PLCs", or in general, for the most part it makes sense to use available commodity parts and keep the product line inexpensive and compatible at the software level rather than select a CPU with 50 year availability. And especially not ask for a custom SoC and then pay for 50 year availability. And not use an off the shelf OS and libraries and hope they work for 50 years. Much better to standardize some interfaces and maintain only those for 50 years.
As a final comment, there are absolutely cases with huge qualification costs or human safety requirements where it makes sense to pay big money to keep using old, proven parts even if they are obsolete, like aerospace or nuclear.
I can go to Mouser right now and buy a pin-compatible 80186 right now in quantity of 1. You can even order a new 8088 from Renesas, but it says they're back-ordered til next February.
I've seen 386s and 486s manufactured recently enough to have the "newer" Intel logo (the one without the dropped "e") which implies well into the 21st century.
With modern product lines, I'm not so sure. The Atom-class products that seem most appealing for embedded use tend to have a very short shelf life (in those terms). I wonder if they're saddled by a dual market obligation-- I suspect Intel wants to sell to both "quantities of 100" embedded markets, and "quantities of 100,000" $199 laptops/tablets, but they're really only viable use of production capacity as long as the quantities-of-100,000 orders last.
I'm not sure the ARM ecosystem is better, because of the tendency to highly-integrated SoCs. Even if some manufacturer says "here's a vault with 50 years worth of chips", it's unlikely they'll have the one particular part you want in that vault..
I wonder if, of all things, it would end up being something like the RP2040/RPi Pico. Third party designs are going to leave a lot of inertia to keep it available as-is, and at the same time, there's not really a single market-dominating customer who makes the product uneconomical if he leaves.
Yes, this is a very well known issue, left sour taste.
An SoC board that carries a solid GbE NIC with LoM (or perhaps SFP+), a console port, supports ECC SDRAM, no sound hardware, and either no video, or very limited-scope 2D-only GPU. Maybe a couple USB 3.1 ports.
I would buy these in lots of 100, if available.
They are not currently in that category. Nowhere in the article was any mention of EUV lithography, which is really where Intel fell behind. When they get it figured out I'm sure they'll make some rapid progress, but until then they simply aren't on the leading edge. Aside from capacity I'd say they're about equivalent to Global Foundries, except GloFo has some specialty processes too.
Modern laptops and mobile devices reflect a return to the vertical integratio of those computing devices (Atari, Amiga, Macintosh), with PC towers becoming a niche market and businesses coming back to timesharing.
So yeah, it will happen.
This is critical for Intel's turnaround. Good to have a CEO that wants to put money into process engineering and capacity than financial engineering to pump up the stock price to meet his personal compensation goals.
AMD didn't build Rome in a day.
Whatever happened with that excellent small-factor platform, anybody knows?
Sure there are several online stores out there that offer some such PCs but they're all pretty expensive and definitely don't reflect the real price (IMO anyway).
I wonder if I'll be able to buy something like that for a home server or whether AMD will release next-gen small-factor PC platform.
You need x86 when you need Windows Software. Or still for some macOS software.
But if you develop a set driving car for example, you just compile your code for the architecture of your SoC. And if you switch architecture you invest a few weeks to port it.
ATMs seem an obvious choice - lots are running on Windows underneath, but might well want custom security elements in the silicon.
If they would switch to a new hardware platform, I’m quite sure nobody would ever pick Windows again.
So maybe they will still do clones of the existing ones (on standard x86 hardware). But then they don‘t need new chips.
Another thing although speculative: Windows 11's move to require UEFI/x64/SecureBoot could be prep for AMD and Intel to completely drop a ton of legacy support (16bit etc.) in the chips. I'd give it about 20% chance of happening, but I definitely wouldn't rule it out given you can emulate a 386 easier than you virtualize one.
Like the 80386SX? 80376?
On the topic of downleveling... based on the research I've done (think writing a UEFI capable kernel for FreeDOS) it's dubious at best to do that because the real mode core wouldn't know about the local APIC and would mess with the IO APIC when you really really don't want it to. So is it possible? Potentially? Would anyone with any shred of sanity recommend it? No not in my opinion. There is no valid reason to do that.
china? you bring politics too?
who are you?
The whole selling point of x86-64 was that it was an extension. You didn't need to use the extra registers, the long address space, etc. except where it actually was useful. I'd be unsurprised if a lot of x86-64 binaries have plenty of traditional 32- and 16-bit instructions. Maybe there's a handful of "can never sensibly be executed in a 64-bit OS running normal well-behaved software" flows you can nibble off at the edges (stuff related to long-abandoned 286 protected modes?)
If you go much further, you sacrifice the key selling point of buying an x86-64 CPU: the ability to run your closed-source line of business software and propriatery games. Then you've basically got the software value proposition of one of those arcane POWER or RISC-V desktops, or an ARM Chromebook, without the unique selling points of either.
I'd expect the portion of the die responsible for decoding 16- and 32-bit instructions has more or less stabilized over the years, and just gets copy-pasted-shrunk across generations. MOV AX,[1234:5678] is pretty much unchanged in 40 years, so I doubt there's a hot breakthrough in how to decompose it to micro-ops.
The transition I could imagine would be a big-little style thing: a CPU that was, say, eight x86-64 cores and eight RISC-V or ARM. Over time, the ratio skews, until the x86-64 cores are a co-processor you can install seperately if you still need them.