Intel CEO: Clients Want Custom x86-Based SoCs(tomshardware.com)
tomshardware.com
Intel CEO: Clients Want Custom x86-Based SoCs
https://www.tomshardware.com/news/intel-pat-gelsinger-clients-want-custom-x86-socs
88 comments
Please can you customise this X86 CPU - I’d like it to be smaller, cooler, cheaper, more secure and more powerful please, and if it could use the ARM instruction set that’d be great. Thanks
No kidding, my thoughts exactly.
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.
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.
> Had Intel done that 20-25 years ago the story might be completely different.
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.
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.
Is there a good telling of why ARM won in the embedded space? I "assume" it is related to power consumption, but I didn't actually follow this very closely.
It is the same reason with everything Intel for the past 10-20 years. Profits. And I have been ranting on it for most part of the last decade. Far too focused on profits. I mean Intel is still making record profits quarter after quarter.
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.....
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.....
I recall a story about someone is arm's early days testing the chip and finding that it was workign normally was shocked when he saw the power wasn't actually going into it. excess power bleed going to it from other parts was providing all the energy it needed.
I've heard this, too. I don't know if it's true, but it is feasible.
I have not read anything but here's my understanding...
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.
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.
Intel loved big profits (note the lack of an under $300 market for much of the WinTel years), and MIPS was just a confusing mess with SGI.
ARM being fabless first and pretty liberal with the licenses helped alot. Nobody feared to help there competitors when developing on arm.. they were as neutral as the swiss before they were acquired, and thats a great thing for embedded development projects.
Probably cost too. Intel had a big profit margin on their chips.
>Had Intel done that 20-25 years ago the story might be completely different.
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.
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.
Of course, but it will cost you a gazillion dollars for this one chip.
This is what AMD has been doing for years under their CEO, Dr. Lisa Su: building custom solutions for their clients. See the CPUs in the past couple of generations of Playstation and Xbox as well as thr recently announced Valve Steam Deck – all feature custom X64 chips suited to the needs of those platforms. So, once again, Intel is playing catch up to AMD.
All true.
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&...
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&...
AMD was willing to accept margins that Intel wouldn't, and probably still won't. I doubt their custom business will target the same markets.
Thank you for the additional context, I didn't recall that it started even before Dr. Su's term.
And also the new Tesla Model S
"Of the 100+ customers, I'd say about a third of them are interested in that x86ish of our ecosystem," said Gelsinger.
Put another way two thirds are not interested in x86.
Sorry to say that this article reads like an Intel press release.
Put another way two thirds are not interested in x86.
Sorry to say that this article reads like an Intel press release.
A little more context here is needed I think
> 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.
> 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.
Eh I could still see a ton of application specific customers that would stick with x86. HFT for example: if they can get a chip with a few super fast cores and HBM2 on substrate. Perhaps mix the NIC in and turn the entire thing into an SOC.
Yeah - sounds like probably around 40 customers wanting stuff like that. No one's saying otherwise.
I think we have to apply an appropriate degree of scepticism to these statements. ‘Are interested’ could have a broad range of meanings from happy to receive a presentation from Intel sales upwards. ‘Want’ sounds like they are keen to have x86. Given x86 is supposed to be a key part of their offering I think they would have been more positive if they could.
> Put another way two thirds are not interested in x86.
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
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
It’s not an interview with Intel’s CEO. It’s an article about Intel seemingly informed by the CEO’s interview with a third party. It has lots of apparently TH commentary on Intel vs AMD vs Arm etc. So we should judge it on those terms and on those terms it’s incredibly one sided.
Tomshardware has a history of being basically that, a mouthpiece for Intel. Back in the days of AMDs thunderbird, opteron, etc., I remember tomshardware having some obvious bias that made other outlets like anandtech look super trustworthy by comparison.
Sources for this? I’ve followed Tom’s Hardware for a number of years and they’ve been blasting intel pretty hard lately for their failure to provide competitive offerings in the last gen or two of CPUs:
1. https://www.tomshardware.com/features/amd-vs-intel-cpus
2. https://www.tomshardware.com/reviews/best-performance-cpus,5...
1. https://www.tomshardware.com/features/amd-vs-intel-cpus
2. https://www.tomshardware.com/reviews/best-performance-cpus,5...
Not blasting Intel for their recent failures would lose them all credibility. Note my claim was just that historically they have a pro Intel bias. It's tough to dig up stuff from well over a decade ago.
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.
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.
Fair points, and thanks for the references--I'd rather know about bias than not.
Purch (TH's owner) talking about the relationship between Intel and TH:
http://archive.is/9oxp2
Plenty of people agreeing with me on various forums: https://www.google.com/search?q=tomshardware+biased+-inurl%3...
Plenty of people agreeing with me on various forums: https://www.google.com/search?q=tomshardware+biased+-inurl%3...
They also want them to have guaranteed availability for years. Anyone not making PCs isn't planning to redesign their boards every few months as some new chip/upgrade comes available, and they don't have the budget for it. Give me reason to think I'll be able to buy this CPU for the next 50 years at a reasonable price, in whatever quantity and I'll be interested.
Lower power consumption would be nice too. We don't always have mains power.
Lower power consumption would be nice too. We don't always have mains power.
I'm sort of curious what the "long-lived embeddable CPU" of this era will be.
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.
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.
50 years? Isn't it a little too much? Maybe 10? 20 even. But 50?
The 6502 will be 50 in 2025, so unless they stop making them between now and then we will have at least one example of a processor lasting that long commercially. If not, then the Z80 will be 50 in the following year.
But those are running lightweight embedded stuff with no or minimal OS. A modern intel x86 CPU is never used that way and a) is broadly compatible with other x86 cpus and b) is used in products that rely on a million software dependencies and a supported OS, along with all of the updates along the way to keep it working online which is a standard requirement these days. So unless the system is totally offline, all the mentioned stuff, plus the other spare parts are also supported for 50 years, there’s not much of a market there.
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.
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.
> But those are running lightweight embedded stuff with no or minimal OS. A modern intel x86 CPU is never used that way and a) is broadly compatible with other x86 cpus and b) is used in products that rely on a million software dependencies and a supported OS, along with all of the updates along the way to keep it working online which is a standard requirement these days
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.
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.
"Never" was too strong a word but I stand by the market being small. I know modern x86 CPUs are used in embedded and I even have a robot arm that uses a 486 with bare metal software for motor control.
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.
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.
Maybe the OS and everything we run today will be considered "lightweight" 50 years from now...
Maybe, but in that case it will be lightweight on current hardware, not on 50 year old hardware. I wouldn't be surprised if a midrange microcontroller used for a one-off application, in 50 years has the equivalent of docker (x2, one for the development environment and one for the microcontroller). That would hopefully work for another 50 years. On the other hand, look at any small microcontroller vs a complex CPU today. In laymen's terms, arduino vs raspberry pi. For controlling some devices, a small microcontroller is faster booting, faster to react, has fewer unnecessary states, is deterministic, testable, more reliable, uses less power. That will probably never change and in 50 years 8 bit micros will still be used for a lot of applications. Even after 50 years of development you probably don't want the brake controller in your self-driving car to run something in python 2.7.19 in docker in windows 39.
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.
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.
> 50 years? Isn't it a little too much? Maybe 10? 20 even. But 50?
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.
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.
I like this comment. It's an interesting question. It's understandable why we wouldn't want to use the same CPUs for 50 years or more given their history of rapid improvement, but on the other hand, engineering things to "heirloom quality" is important for sustained growth and for sustainability in general.
Depends on the use case but yes I'd agree, 50 might be a tad too long. I work in IoT and industrial computing and the specifications can be for 25+ years however, so it's not unheard of.
>I work in IoT and industrial computing and the specifications can be for 25+ years however, so it's not unheard of.
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.
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.
There's plenty of foundries cheaply fabbing chips in "obsolete" process nodes. If the original design from 25+ years ago is available, there's no reason why it couldn't be fabbed today in those quantities.
Also, while I wouldn't want to redesign (and, Heaven forbid, recertify it with the authorities) the board and software, I wouldn't mind having a part done in a more power efficient way, as long as it's pin-compatible with the old one and done in a way similar enough no recertification is needed.
This is doable, it is impossible right now, but given enough time, quite probable that one could take an old design, and move it to a new PDK and have it automatically adjusted to meet the same timing and power constraints. If only one could take the GDSII for an old process node and just make it smaller. Maybe someone will make a model that does that, just contracts images of polygons. :)
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.
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.
Rochester Electronics disagrees with you! You just have to have some deeeeep pockets for it.
Yes, AMD made. Nobody wants another Atom C2000 "System May Experience Inability to Boot or May Cease Operation," blown bus clock outputs situation with hundreds of $ millions in recalls.
Got a link to any details on that one? I'm not familiar with it.
Read about the Synology XX15 series. At least Synology worked hard to remedy the situation.
I _personally_ had to return (free of charge) my FreeNAS Mini to have them fix this (well-known) issue.
Yes, this is a very well known issue, left sour taste.
Yes, this is a very well known issue, left sour taste.
What the world really needs right now is a power efficient, server version of the NUC.
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.
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.
>> Intel has to become a bigger maker of chips to stay among the few companies that can develop and use leading-edge fabrication technologies....
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.
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.
Am I the only one that's worried this means the last hardware platform that was reasonably standards adhering is about to be broken up?
AMD has been doing custom x86 SoCs for a long time, mostly for game consoles. It hasn't had any real impact on the laptop/desktop/server market so far.
That was to be expected, PCs as phenomen only happened due to IBMs mistake of keeping them vertically integrated as all the remaining 16 bit platforms.
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.
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.
yes. Apple making their own processor. Google making their own processor, and so on. the generic x86 as we know, might be dead soon.
> in the coming years Intel will cease to buy back shares, but will invest in new manufacturing capacities instead.
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.
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.
Clients want CPUs that don't ship with known security bugs. I suggest they work on that first before they try mixing it up.
AMD didn't build Rome in a day.
AMD didn't build Rome in a day.
All CPUs ship with known and unknown security bugs. It’s a pipe dream to think otherwise.
Intel, however, is infamous for such things. AMD is not.
No, they built Naples first, then Rome. :P
And I'm still sad I can't buy a cheap 1L PC based on Ryzen 1606G, with two built-in 10GbE network cards...
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.
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.
I don't recall if any of them meet your specifications, but ServeTheHome has been reviewing a bunch of 1L PCs. Lenovo has a bunch that feature Ryzen CPUs. https://www.servethehome.com/tag/tinyminimicro/
Thanks for the aggregated link, I'll go through all those. <3
Please, add a common hardware interface, not the ARM clusterfuck. With BIOS and such.
U-Boot is a nightmare to handle in my wm8850 netbook, and it requieres custom kernels to boot and work.
It's either that, or a crappy and obscure community Android release from the community.
If intel doesn't consider ARM for its client devices (like Laptops) then their market is going to further erode by QC/Nuvia as selling a 300-500$ CPU is going to be a great market for QC to enter. Intel has already lost a considerable share to AMD and they might lose that further to QC because I just don't see an intel laptop offering ridiculous battery life and TDP like the M1 which QC can achieve in a couple of years hopefully. At this point I feel like intel is just being adamant which is not good for both business and customers because in the linux and Open-source space people would much rather prefer an Intel/AMD platform than QC.
Which embedded systems customer cares about the cpu architecture?
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.
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.
There are a non-trivial amount of embedded systems that are running Windows, so them.
ATMs seem an obvious choice - lots are running on Windows underneath, but might well want custom security elements in the silicon.
ATMs seem an obvious choice - lots are running on Windows underneath, but might well want custom security elements in the silicon.
Or OS2 (ATMs) or DOS (an unbelievable number of PoS devices and other 'business ops' uses as well as industrial). Now to be fair... most of that market is already served by a vendor that doesn't make desktop CPUs most notably DM&P https://en.wikipedia.org/wiki/Vortex86
ATMs are still using windows, because they are old. A lot of them have CRT screens.
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.
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.
[deleted]
I think what they actually want is: if it is x86, it needs to be a core. Currently most people are quite happy with 20 years of already having ARM as a core (SoC, FPGA, etc.)!
Intel should license out x86 like ARM for cheap. let fabless companies lead the custom x86 SoCs.
[deleted]
Not from Intel.
that's not true, i want ARM and soon RISCV boards
RISC-V sooner than later, the uncertainty around ARM the company due to the buyout and the whole thing with ARM China is just yuck. But honestly nothing the M1 does x86/RISC-V can't do. At this point ISA is just an ABI it's more about keeping execution pipes filled, as long as a frontend can do that it can absolutely clean up on the metrics.
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.
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.
That still feels suicidal for a desktop-PC CPU.
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.
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.
so you make choices based on how much profitable your portfolio will be?
china? you bring politics too?
who are you?
china? you bring politics too?
who are you?
It's not politics its just that there is a dispute between ARM China and its parent, this is well documented. This complicates IP licensing concerning the ARM ISA in the world's largest market. I personally wouldn't want to develop a product with uncertainty around the IP in a major market.
>Intel to completely drop a ton of legacy support
Like the 80386SX? 80376?
Like the 80386SX? 80376?
So right now when an x86-64 CPU boots it starts in 16bit real mode regardless of everything else. The UEFI then has to set up a x64 protected mode env then the OS picks up from there. If you drop that backwards compat (e.g. 16bit, virtual 8086 mode etc.) you can remove a lot of cruft that is mostly worked around. If nobody is setting Local Descriptor tables then why support it? Or the hardware task switching support that's not even supported in long mode etc.
I believe that individual cores must still be brought up via real mode, etc. even when the UEFI boot otherwise gives you a clean 64-bit environment. So the backward compatibility must still be present.
It's complicated and annoying but yes. There is also the question of 'downleveling' a core back to real mode when the others aren't. But if you require UEFI and secure boot then you could bypass that and go to a 64-bit linear reset vector anyway as that's how UEFI sets up the boot env. That would mean you'd only need to initialize that core and it'\s local APIC and associated envs in theory instead of playing mode hopscotch.
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.
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.
with good mainline (Linux) kernel/driver support... x86/64 has that unless they start to fragment it.