Who among you can resist an eight-core, 2.9GHz mini-PC or thin client that drives four displays? AMD’s taken the wraps off four Ryzen processors aimed at embedded applications, thin clients and mini-PCs. The new Ryzen Embedded V2000 Series microprocessors are all built on a 7nm TSMC process and offer Zen 2 cores that also feature in AMD’s Epyc server silicon. AMD suggests mini-PCs, thin clients, and kit living on the …
AMD are really turning up the heat. These look fantastic. With TSMC now looking at 5 and 3nm, capacity to deliver a huge number of chips is growing whilst Intel has zero capacity at any of these nodes. Intel now has to target 3nm or smaller to catch up, and there's no sign of them being able to do that.
It’s a little more complex than that. Intel 10nm is about as dense as TSMC 7nm, but they can’t get it to yield well, which is why they are stuck on 14nm for most large chips. Intel 7nm should compete with TSMC 5nm, if they can get it to work properly.
Intel are promising CPUs competitive to Zen 3 in early 2021 (abet only up to 8 core). It’s likely to be an uphill slog for them to regain the lead fully, especially if AMD keep executing at the same rate. It’s good for the industry though to have such competition in place.
My understanding was as 10nm was a bust for Intel they got a new VP in to drive 7nm which is basicly the same spec as the 10nm but with more realistic margines. The suggestion is it would be the same as TSMC's 7nm not TSMC's 5nm. From what I can understand this Intel 7nm 'less agressive node' has still run into delays and issues.
Still who knows, all we can say is TSMC is already delivering A14 & M1 chips in quanity for Apple at 5nm, AMD's chiplet design is not that much bigger than Apples chips, so the expectation is there should be no issue for AMD's Zen 4 ramping up and having a 'good' yeld. This puts Intel upto 2 years ahead of Intel, who still need to move to and bug fix there own chiplet designs, as I belive the design tools between Intel and TSMC are not fully compatable thus requiring some redesign on Intels side even if they licensced or paid TSMC to make chips.
Of course the one to watch is Apple, as they will most likely be the first on 3mn, probabley by the 3rd itteration of there 'desktop' arm chips. AMD do have Arm chip designs, and there graphics tech is what allowed Snapdragon to push ahead of its competion. So if there is a move from x86 @ home to Arm, I would expect AMD to enter the ring.
The Irony of Nvidia owning Arm with AMD licencing cpu's is most amusing (and worrying).
As always, it's complicated...
Start with the easy stuff - TSMC are currently on optimised 7+nm high performance (HP) silicon with a mix of EUV/SAQP process technologies and 5nm for low power (LP) using just EUV. The margins for components in LP is significantly larger than HP processes which means HP allows for higher frequencies, higher densities and higher power usage. In addition, LP tends to lead HP by 6-12 months.
For Intel, there failed 10nm process used SAQP only but was likely to have similar performance to TSMC 7+ HP processes based on published component sizes. It failed for a number of reasons, but it is best summed up by being too complicated for the available technology because they tried to incorporate 3 significant design changes into one process shrink and all 3 failed to work as intended initially (leaving Intel unsure what the cause of each fault was).
It's also worth stating that design rules are process dependent - movign a workign Intel design to TSMC/Samsung will likely take 6-12 months of redesign and a further 6-12 months to get production ready silicon to market. I would be very surprised if we see Intel x86 designs rolling off TSMC or another foundries processes unless Intel 5nm is a complete failure.
Stepping forward to TSMC 5nm HP on EUV and Intel 7nm on EUV - these should be equivalent in performance but TSMC have a significant lead in installed equipment and producing LP chips meaning Intel are likely 1+ years behind TSMC. This broadly lines up with guidence given by Intel.
Yields are down to the process used rather than the design unless you try to bend design rules - if its a new process (as 5nm HP will be) there are no guarantees you will have high yields. Historically, Intel was brilliant at process execution but very conservative with design rules with TSMC customers pushing design rules hard to try and compensate for poorer process execution but it looks like TSMC have addressed their process execution and yield issues in recent years.
The only thing missing from all this is Samsung - their EUV processes look promising and they have had some experience with EUV at 7nm already so they may become the surprise package if their 5nm process is competative. In addition, Samsung have similar EUV capacity to Intel at present so we will likely see some production moving away from TSMC to Samsung becuase TSMC doesn't have the capacity to serve everyone.
Comments around AMD and ARM are a little misleading - if Nvidia do end up purchasing ARM I suspect it will drive a significant move to RISC-V in the higher volume market segments. While AMD has some low-volume ARM products via a subsidary, it's unlikely to be affected by the buyout. As for Nvidia, I can't justify their current share price based on other tech stocks and I think Softbank maybe getting out of ARM at just the right time for them. Softbank take the money and run, Nvidia's bubble bursts and ARM moves to another new owner?
Different process nodes for Intel are different fabs and different teams and EUV is new for everybody.
The big advantage Intel has this time around is that they know the equipment they are using can be used to produce chips - that wasn't the case with the equipment that they used for first gen 10nm although it wasn't the only reason that they were unable to produce working chips.
That's certainly the case. And Intel, in a way, really need AMD to be successful at the moment. ARM is becoming more commonplace, Apple are headed that way, its growing in server land too. Without AMD carrying the x64 torch, there might not be an x64 market to come back to once Intel gets its silicon process sorted out.
nVidia has been forgotten in the last few days
... Not so much in the GPU space, but in the ARM CPU space where they're doing good things for severs, so I'm told. Apple's new Macs are likely to be good for bringing even more developers to all ARM platforms. Since nVidia own ARM, that kind of makes them allies of Apple for the time being.
We looked at AMD embedded processors as a replacement for our Intel processors.
While the cost and benchmarks looked attractive, it didn't really work out
What we found was that AMD achieve their performance with aggressive clock management. If the processor starts heating up, they slow the clock down, and unlike Intel processors there seemed no way to manage this.
On a PC, running windows, the user would not notice any difference, but on a hard real time system that relied on very low jitter in process cycles, it was pretty horrible. After working with our supplier for about 6 months, we gave up and went back to Intel
True. I agree that our requirements are on the harder side of real time, but it is not unusual in embedded systems.
I would argue that most embedded systems support some manner of RTOS, but I would agree that the majority require only soft realtime which the AMD processor would be eminately suitable, especially if they use the x86 architecture
I think the other point is that benchmarks do not give you the entire story and a lot of performance metrics are based on managing of the controller.
The fact was we were disappointed because the AMD processor looked great and we really wanted to use it
Probably the wrong class of processor to be looking at for real time work. ANY CPU that relies on large caches for main memory that runs at a fraction of its speed is going to have some degree of jitter. This is why ARM have their A series application processors, M series for microcontrollers and R series for real time work.
In my hard real time embedded apps, I don't expect the CPU that runs the "big analytic and user interface" stuff to be hard realtime.
I instead follow the long used model of using a dedicated CPU running a hard RTOS to do the low level stuff and buffer for the big guy - the little guy handles the a/d converters and actuators. This lets the big guy run some pre-emptive multitasking system and occasionally ... pre empt something without losing data or timely control. The simple stuff is all delegated to the little guy which is commanded by the big guy and ultimately the user. There are lots of cheap and fast teensy cpus out there to choose from.
This is how PC's work anyway - there're a lot of little CPUs in most modern ones. Disk drives all have one, even USB sticks. Sound cards have had to have some smarts and buffering forever. Then there are GPUs/video cards. All use some special processor "at the metal" to satisfy requirements you can't really do with a multitasking interrupt driven opsys whose glory is to -- pre-empt and go do some job of it's own now and then.
"Probably the wrong class of processor to be looking at for real time work. ANY CPU that relies on large caches for main memory that runs at a fraction of its speed is going to have some degree of jitter. This is why ARM have their A series application processors, M series for microcontrollers and R series for real time work."
It's all relative. The device we used was already on the Intel architecture, so we were comparing the AMD against the Intel offering (Partly because the Intel embedded roadmap was not great). Comparison like for like showed worse performance in some metrics than the AMD part, despite it being a newer chip
Generally jitter is guarded against in these situations by aggressive cache management i.e we ensure the minimum of cache swapping. However despite the cache being larger on the AMD part, jitter was higher.
When the margins are this tight, all processors require careful configuration. We would of been happy to run the AMD part at a lower speed, and disable the clock throttling, but AMD did nor provide that option
x86 and RTOS aren't words usually uttered in the same paragraph for a reason
Total rubbish. It is not perfect for every application, but x86 is perfectly usable for RTOS and its ubiquitous means it has very good performance if you want to do anything more complex than run a few control loops
"We looked at AMD embedded processors as a replacement for our Intel processors."
Is this with the latest designs or older units? AMD's embedded options have trailed the desktop/server CPU's in both core versions and process. 2020 embedded are the first ones that are likely to be competative with Intel (theres a similar story on the mobile side)
i.e.
2020 generation embedded: Zen 2 cores/5th gen GCN GPU/7 nm
2018 generation embedded: Zen+ cores/4th gen GCN GPU/14 nm
2015 generation embedded: Excavator cores/3rd gen GCN GPU/14 nm
Of those, it's only really the 2020 versions that are likely to be competative with Intel as they move to 7nm and start to outperform Intel 14nm+ or later chips.
And if you were testing against the 2015 generation chips, maybe AMD will give you a freebie 2020 version to make up for wasting your time.
If the workload benefits from several monitors, for sure... though perhaps the folk who run four monitors aren't always the types to be overly concerned about the size of their PC! The extruded aluminium cases that many fanless industrial PCs are built into would fit the bill.
If no extra monitors are required, and the workload is modest, a small ARM box is attractively cheap and quiet.
This post has been deleted by its author
...But based on what I have seen lately from AMD "embedded" products almost none of these will wind up in a consumer channel. For example, take the Epyc 3000 line of CPU's. I can buy an Epyc 3201 or Epyc 3251 based board. That's is it. There is nothing else in the channels that will make it to consumers.
According to a friend of mine that has some knowledge of the situation the development costs are higher on this sort of product because of the high cost per CPU even when going well beyond AMD's "minimum buy-in." They tell me it is still cheaper to wait in line for Intel chips. This means that unless an OEM can commit to a huge number of shipments (like Supermicro or ASROCK) any efforts will focus on specialty work where the customers insist on not using Intel parts. I have no way to verify that, but I also have no reason to doubt my friend.
ARM has run out of instruction codes and helper functions for crypto and graphics rendering. That is it is mature, bar the crippleware locks being added. RISC-V is interesting, plenty of time to add Arm instructions to make migration easy or plan B against sole supplier situations. Now imagine a 3nm Mega FGPA. It may be easier and cheaper to compile/burn your signage displays.
When this is called a "mini" I wonder if they are even close to what I do. My standard is to extend the ATOM and about $100 to do something simple, but used for one thing, because nothing runs. I have boxes from the 2007-2010 boxes which run motion, and with it let to a firewall which moved a lot of data on a pair of 4x NICs pushing and 8x1G using PERL to build a complex B+tree if IP tests changing to minimize the number of tests and keep the packets to a small test testing. New things came to dozens to one solution on a common ATOM getting bigger in the CPU at holding the same cost.
I can do so much more with just a slightly more CPU power, is this it, or is it (I bet) going for a low-cost game when I only need 4K screen at 120Hz and all it needs is icons and text (big enough to see).
What is AMD looking to do, the mini I buy a dozen at the time, or what changes all the time? The idea of running to 2030 is great, at a price of <$200 to justify the large solution.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
