Could AMD A6-9220C be an SoC candidate?


Djhg2000

Very Active Member
Joined
Jul 22, 2014
Messages
213
Location
Sweden
While everyone else was waiting for Zen 2 and Navi, AMD got my attention by releasing two Chromebook oriented SoCs; the A4-9120C and the A6-9220C. Both are 6W TDP parts (OMAP5432 seems to be configurable as 3W or 6W?) and have full fledged x86 cores with GCN graphics. Linux support could potentially be top notch since AMD has a fairly good recent history of mainline Linux support.

I seem to remember that we do have some headroom in terms of thermals, and AMD would potentially have a self interest in showing their low power SoCs can take on the Intel counterpart in the GPD Win.

Am I onto something here or is this just one of my infamous late night ramblings?
 
Maybe, but I'm always suspicious of x64 TDPs. I have an atom in the netbook that's supposedly rated at 2.5W, but the little fan in this machine I can hear whining away trying to keep the thing cool just browsing these forums. I guess Intel didn't include a graphics core in their stats, or it's some other part of the chipset actually producing all of the heat it's trying to dissipate at present, which should be less of an issue with these AMD parts if they include graphics in the dies, but still, once bitten twice shy.
 
I guess Intel didn't include a graphics core in their stats, or it's some other part of the chipset actually producing all of the heat it's trying to dissipate at present
Some older Atoms indeed hat a fairly beefy dedicated chipset that was providing the GPU and totally destroyed the illusion of using an ultra low-power platform.

Zen on the other hand can be entirely autonomous, it already contains everything you'd need from a chipset on a small-scale platform.
 
Zen on the other hand can be entirely autonomous, it already contains everything you'd need from a chipset on a small-scale platform.

These are Excavator based cores, but from what I've read about them it seems they have been modified to be entirely self contained. I'd guess that's why they could only fit 2 cores into a 28nm package. Some more info here: https://www.anandtech.com/show/13771/amd-ces-2019-ryzen-mobile-3000-series-launched

So while it's not a Ryzen APU, it has a much lower TDP and being a 28nm part it should be a lot cheaper as well. My guess is they didn't want to upscale the 14nm Zen cores to 28nm for whatever reason.
 
You certainly can't keep the exact same design when going down in scale; certain gaps become targets for quantum tunneling and other small scale effects, so need to be beefed up. If you scale that back up, you've got redesigned chunks here and there that are bigger than they need to be, reducing yields and pushing up prices again. Whether that inefficiency is better or worse than using an older core that was actually designed for that process scale probably depends on the exact circumstances though.
 
You certainly can't keep the exact same design when going down in scale; certain gaps become targets for quantum tunneling and other small scale effects, so need to be beefed up.

Always enjoyable to see levi knowing more than me about an interesting topic, and crisply and succinctly sharing some information. :)
 
I guess the major problem with x86 chips is that they are too big (physically) for Pyra. Even when they fit thermal and power limitations. ED mentioned this at some point.

Notice that GPD devices have got a lot more space to fit the SOC.
 
Most efficiency for both power use and physical space wind up coming from lithography shrinks. Unless you're looking at significantly smaller scale lithography, do not expect any gains in processing/thermal efficiency.

The OMAP 5432 is a 28nm part.
The AMD A6-9220C is a 28nm part.

There is likely no major processing per watt advantage to that AMD part over the OMAP 5432 currently in the Pyra. To get significant advantages, we would need to be looking at something made in a 14nm (or sharper) lithographic process.
 
Don't forget the board also needs to be designed and created.
Currently the board is designed by a single person. Designing an X86 board is different from ARM. I think an X86 board also has more components and traces.
You need to to arrange all these components, probably also requires you to contact new suppliers and vendors.
While not unrealistic in practice it might just be a bit more difficult for ED to do.
 
Most efficiency for both power use and physical space wind up coming from lithography shrinks. Unless you're looking at significantly smaller scale lithography, do not expect any gains in processing/thermal efficiency.

The OMAP 5432 is a 28nm part.
The AMD A6-9220C is a 28nm part.

There is likely no major processing per watt advantage to that AMD part over the OMAP 5432 currently in the Pyra. To get significant advantages, we would need to be looking at something made in a 14nm (or sharper) lithographic process.

Yeah but for us non-engineers, theres no way to know how much more efficiency to expect, until a new processor is launched and tested.

The 7nm Radeon 7 is due out in a week or two, and is said to consume as much (~300W) as the (14nm?) gpu it replaces.
 
That's a fair point. I can't find much out about this FT4 socket just now, but the previous FT3 socket was a BGA socket with 769 balls on it, each requiring a trace to come from it. I don't know what the pitch and pinout of the OMAP5 is for reference*, but if it's anything like the same size the square root of 769 is a little under 28 along each edge of a presumably square pinout.

* I just added up all of the things labelled OMAP5/U2201 on the schematic for the cpu board and got 405, which as you might have guessed is a smidge over 20 when square rooted. Either the package is 40% bigger in each dimension, or the pitch is 40% higher, or a little from column a and a little from column b.
 
Don't forget the board also needs to be designed and created.
Currently the board is designed by a single person. Designing an X86 board is different from ARM. I think an X86 board also has more components and traces.
You need to to arrange all these components, probably also requires you to contact new suppliers and vendors.
While not unrealistic in practice it might just be a bit more difficult for ED to do.

Sure, but I wouldn't expect any SoC to be a drop in replacement of the existing board. I do however understand that an SoC more similar to the OMAP5432 would have similar space constraints and passive support components.

As to how much an A6-9220C differs from say an Atom X5-8350, or for contrast an Allwinner H6, in terms of required implementation effort remains to be seen. Maybe AMD would lend a hand to speed up adoption and take market share away from Intel in the oddball computer area. Or maybe they'll just expect any potential customers to buy a bag of chips and reverse engineer whatever isn't in the datasheets.

Either way I'd be interested to hear if and how an AMD representative would sell us their chips.

Edit: Inserted missing keyword in the second paragraph.
 
Either way I'd be interested to hear if and how an AMD representative would sell us their chips.

The Pyra's biggest constraints are dimensions XYZ and total SoC Watts <~5 with ability to throttle DOWN from there.

Without a die shrink though, both the existing and your proposed would have the same 28nm lithography. This means that their performance per Watt is likely to be within 10s of %s of each other. It is unlikely to be a dramatic performance boost.

From another angle, though, if ever the Pyra were to be outfitted with an x86 CPU, for that you're looking along the right lines. However, Linux support might be better with the Intel all-in-one x86 SoC, and with Intel's die shrinks to 14nm in the products that succeeded the Atom line, the perf/W would likely be on the order of triple to quadruple what the OMAP 5432 and the above listed AMD 28nm part.

Example:
Intel J5005. CPUbench: 2904 at 10W.
https://ark.intel.com/products/128984/Intel-Pentium-Silver-J5005-Processor-4M-Cache-up-to-2-80-GHz-
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+Silver+J5005+@+1.50GHz&id=3144

AMD A6-9220. CPUbench: 2174 at 15W.
https://www.amd.com/en/products/apu/7th-gen-a6-9220c-apu
https://www.cpubenchmark.net/cpu.php?cpu=AMD+A6-9220&id=3072

How to compare to the Pyra's OMAP?
https://pyra-handheld.com/boards/th...yra-vs-raspberry-pi3-vs-core2duo-vs-i7.82614/

Intel i7-4720HQ. CPUbench: 8001 at 47W. Combined make j1,j2,j4,j8: 38.449 (lower is better)
https://ark.intel.com/products/78934/Intel-Core-i7-4720HQ-Processor-6M-Cache-up-to-3-60-GHz-
https://www.cpubenchmark.net/cpu.php?cpu=intel+core+i7-4720hq+@+2.60ghz


TI OMAP5432.
Combined make j1,j2,j4,j8: 271.426 (lower is better)
CPUbench linear ESTIMATE based on Pyra taking 7x longer to complete the comparative benchmark: 1143 at ~4W.

So - then we'll make the broadly wrong assumption that everything scales linearly to power usage and bring the above units down to the Pyra's thermal envelope.
OMAP 5432 est 4W ~ 1143
J5005 scaled to 4W ~ 1161
AMD A6-9220 est 4W ~ 579
Intel i7-4720HQ ext 4W ~ 680

No, none of that is exact - it winds up being estimates after all. They're not going to be exact. However, they -should- be within magnitude and reason. The piece that bothers me is how HIGH the OMAP 5432 is showing up in the list. It feels anomalous - unless it's pulling more than 4W of power at 28nm. I had, frankly, expected it to come out far closer in that mix to the AMD part. Maybe I missed a decimal somewhere in the analysis or estimate or maybe the OMAP is using more power than I understand it to?
 
It feels anomalous - unless it's pulling more than 4W of power at 28nm.
I guess the part you're missing in that estimation is that there are multiple silicon libraries for different targets, which do have a mayor influence on power consumption. A low power 28nm process is actually able to consume less power than e.g. a 22nm high performance process.
 
I guess the part you're missing in that estimation is that there are multiple silicon libraries for different targets, which do have a mayor influence on power consumption. A low power 28nm process is actually able to consume less power than e.g. a 22nm high performance process.
That would throw it by 10s of % maybe, but not a factor of 2. The only way this makes sense to me is if the Pyra was actually consuming something in the range of 7 to 9 W during the Askarus benchmarks. The 14nm J5005 -should- be walking away from the rest of that pack in perf/W.
 
The Pyra's biggest constraints are dimensions XYZ and total SoC Watts <~5 with ability to throttle DOWN from there.

Without a die shrink though, both the existing and your proposed would have the same 28nm lithography. This means that their performance per Watt is likely to be within 10s of %s of each other. It is unlikely to be a dramatic performance boost.

From another angle, though, if ever the Pyra were to be outfitted with an x86 CPU, for that you're looking along the right lines. However, Linux support might be better with the Intel all-in-one x86 SoC, and with Intel's die shrinks to 14nm in the products that succeeded the Atom line, the perf/W would likely be on the order of triple to quadruple what the OMAP 5432 and the above listed AMD 28nm part.

Example:
Intel J5005. CPUbench: 2904 at 10W.
https://ark.intel.com/products/128984/Intel-Pentium-Silver-J5005-Processor-4M-Cache-up-to-2-80-GHz-
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+Silver+J5005+@+1.50GHz&id=3144

AMD A6-9220. CPUbench: 2174 at 15W.
https://www.amd.com/en/products/apu/7th-gen-a6-9220c-apu
https://www.cpubenchmark.net/cpu.php?cpu=AMD+A6-9220&id=3072

How to compare to the Pyra's OMAP?
https://pyra-handheld.com/boards/th...yra-vs-raspberry-pi3-vs-core2duo-vs-i7.82614/

Intel i7-4720HQ. CPUbench: 8001 at 47W. Combined make j1,j2,j4,j8: 38.449 (lower is better)
https://ark.intel.com/products/78934/Intel-Core-i7-4720HQ-Processor-6M-Cache-up-to-3-60-GHz-
https://www.cpubenchmark.net/cpu.php?cpu=intel+core+i7-4720hq+@+2.60ghz


TI OMAP5432.
Combined make j1,j2,j4,j8: 271.426 (lower is better)
CPUbench linear ESTIMATE based on Pyra taking 7x longer to complete the comparative benchmark: 1143 at ~4W.

So - then we'll make the broadly wrong assumption that everything scales linearly to power usage and bring the above units down to the Pyra's thermal envelope.
OMAP 5432 est 4W ~ 1143
J5005 scaled to 4W ~ 1161
AMD A6-9220 est 4W ~ 579
Intel i7-4720HQ ext 4W ~ 680

No, none of that is exact - it winds up being estimates after all. They're not going to be exact. However, they -should- be within magnitude and reason. The piece that bothers me is how HIGH the OMAP 5432 is showing up in the list. It feels anomalous - unless it's pulling more than 4W of power at 28nm. I had, frankly, expected it to come out far closer in that mix to the AMD part. Maybe I missed a decimal somewhere in the analysis or estimate or maybe the OMAP is using more power than I understand it to?

A very well written analysis, but there are two minor errors.

First of all, the A6-9220C is a different part to the A6-9220. I fell into this trap as well when I did my pre-thread-creation research. They have different CPU specs (different clock speeds and TDP) and entirely different GPU specs (R4 vs R5). The GPU might be of a different architecture as well, but details are sparse so far.

The second one is that OMAP5432 seems to be a 6W SoC configurable to 3W, not 4W. The 7-9W estimate is probably closer than you think.
 
apart from the thermal restraints there are physical space restraints. here is a link to a post from hns detailing the space that is available. https://pyra-handheld.com/boards/th...-rk3399-sounds-good.83004/page-2#post-1438378
If you are expecting to run some form of x86 windows on this then there is an additional requirement that ED also brought up in one of the many threads on a windows SOC.... windows requires a BIOS. someone would have to write it . would it need another chip for it? if so how big is the chip and where does it go?
whatever new SOC is used the CPU board has to fit in the space available. the 2 connectors to the main PCB are in fixed position.
A new CPU board will not be a trivial thing to design.
 
windows requires a BIOS
Wrong - UEFI is supported since Win 7, booting with GOP instead of the legacy VESA extension works since Win 8. OVMF / TianoCore, the sort-of reference implementation of UEFI, is already open source and can be paired with SeaBIOS if you are really in the need for legacy BIOS compatibility. The only thing left is some code to bring the hardware up, which is basically what has to be done with uboot on the OMAP as well.

coreboot can be paired with SeaBIOS and OVMF as well.
 
Back
Top