Potential ARM (Non X86) SoC alternatives


I'm quite sure that was the same false rumor from the forums. dsplink has little dependencies on kernel version, and a version of dspbridge existed for 2.6.27.
Hey, since you're in the discussion... If I recall, you've stated before that you have a dislike for X86, but I don't recall you stating which ARM SoCs you actually like. What are your favorites? Why?
 
I would take OMAP5 for P2 because with all current OMAP knowledge, I feel I could make best use of it with limited time I can spend working on system bringup. It would also be best choice for achieving near perfect P1 backward compatibility. That of course ignores all red flags Exophase raised (nothing using OMAP5, no support from TI, etc.), and those can't be ignored.

On paper MediaTek's big.little offering looks good too. The GPU driver situation could be overcome with various android compatibility layers (libhybris) and perhaps some custom glue, but is unclear if it would work out, so would be risky. Other drivers should be ok since they have to open all kernel drivers due to GPL.

I don't like all those quad code SoCs, I see them as waste of resources as you have to design for higher possible maximum power usage/heat dissipation that actually needed. But if ED gets good conditions on such soc, I would have no problem working on it.

In unrealistic dream world, I'd really love Apple A7. New, clean, more efficient arm64 instruction set to play with (with full armv7 support for backward compat), very good performance and power characteristics. It would make P2 really capable device, real shame it will never happen.
 
Dear Samsung, I really like your stuff. please give me 5000 SOCs.. love Shlee

Does ED want to make friends with the HiSilicon K3V3 and give us a op2 with Chinese backdoors? ^_^
 
Last edited by a moderator:
Hum, hadn't even heard of that one. Should be added to the list of to-look-into too.
 
EDIT#4 / update 13Oct2013:

I wouldn't even count on the DSP being compatible, since TI calls it "mini-C64x." I don't have details but I heard that OMAP4's only had half the execution resources, and if that was the case maybe this carried over to OMAP5
I just took a look at the OMAP 4430 TRM and what you've heard is correct.

In the OMAP4 "IVA-HD" (and most likely OMAP5 as well since it is also called IVA HD there), TI removed everything that was fun about the OMAP3 DSP (IVA2).

To quote the TRM:

Known restrictions on the C64x+ DSP core:
• 4-issue VLIW central processing unit (CPU) instead of 8-issue
• SPLOOP not supported
• L1 and L2 flat static random access memory (SRAM) not supported
• No EFI port
No more memory latency hiding tricks with eDMA and L1DSRAM..and without software pipelined loops and only half the number of instructions per cycle the performance is probably disastrous.

This decision either was the brainchild of some penny counting idiot, or TI thought this kind of low power / high throughput military grade technology was simply too good for the consumer market.

On the upside, I am glad that the Pandora still has the real thing.

original post:


What about the Freescale i.MX6 platform ?  http://cache.freescale.com/files/32bit/doc/fact_sheet/IMX6SRSFS.pdf

  • 1.2Ghz quad core Cortex-A9
  • Vivante GC2000 (3D), GC320 (2D), and GC355 (VG) GPUs
  • eSATA 3.0
  • USB2 (1x OTG + 3x host-only)
  • PCIe (e.g. for adding WiFi support)
  • HDMI (up to 2048×1536 @ 60Hz)
  • h264/mpeg4/vc-1/h263/mpeg1+2/VP8,.. video acceleration
  • 10/100/1000 Mbps ethernet
  • uSDHC (SD/SDIO 3.0, MMC 4.x)
  • up to 64 (?) GBytes of onboard NAND flash
Vivante's GPU drivers are closed source, except for the kernel module which is GPL, but open source drivers are being worked on according to http://www.phoronix.com/scan.php?page=news_item&px=MTI3MjU, sources are here: https://github.com/laanwj/etna_viv

EDIT: This link http://www.cnx-software.com/2013/01/19/gpus-comparison-arm-mali-vs-vivante-gcxxx-vs-powervr-sgx-vs-nvidia-geforce-ulp/ is also interesting (Mali vs SGX vs GC)

EDIT#2: Here are the datasheets: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&nodeId=018rH3ZrDRB24A&fpsp=1&tab=Documentation_Tab (only took a sneak peek but the documentation looks very good / detailed)

EDIT#3: don't quote me on this but this platform seems to be ~8 times faster than the Pandora and it looks like a pretty good tradeoff between performance and price. A "P2" retail price of ~200-250$ should be feasible. (although, from a technical point of view, my first choice would still be OMAP5 .. I wonder what the price/unit would be for low volume orders ..)

Side note: There's a cool product based on that one coming out soon: http://www.solid-run.com/ (in the NVidia shield thread I wished for something like this (desktop replacement the size of a Rubik's cube). turns out these guys are actually building it!)

EDIT#5: (cross post from another thread) Freescale recently announced their (28 nm) i.MX7 and 8 platforms: https://community.fr...ions-processors (i.MX8 could be interesting)

EDIT#6: "i.MX 6Dual/6Quad Power Consumption Measurement"http://cache.freescale.com/files/32bit/doc/app_note/AN4509.pdf (different use cases)
 
Last edited by a moderator:
Not so surprising, any company can use ARM's Intellectual Property for a price..

Were I work at IBM, our ASIC/Custom Logic division often manufacture chips with ARM cores, hell we have some that have a PowerPC and ARM core in same chip.

IBM could make a fantastic custom chip for the Pandora and even for small quantities.. too bad it would be horrendously expensive as the development costs would be rolled in.
 
Last edited by a moderator:
It's not an SoC, it's an FPGA, and consider:

1) We've known for a long time Intel was going to manufacture some FPGAs for third parties. This shows Intel is moving into the foundry business, and FPGAs are a good test part to try this with since they're low volume/high cost. They're also good to use as pipecleaner parts for testing new processes since they contain a lot of redundant/easily replicated areas.

2) High-end FPGAs these days tend to embed a bunch of special purpose "hard fabric" stuff in addition to the normal reprogrammable part because some things are very commonly used but aren't that efficient in FPGA logic. Like memory blocks or MADD units.

3) Including whole CPUs as part of this special fabric has been normal for years, and it makes a lot of sense when you consider that FPGAs without them are often compared with microcontrollers to help perform management tasks that are an inefficient use of the FPGA's logic arrays.

So there was a high probability that Intel would do this once we knew they'd be manufacturing FPGAs from big players like Altera. Of course, if it was Intel themselves designing the FPGA it'd probably have an x86 microcontroller on it instead. But for a third party ARM is a good choice, and there's no reason why Intel should avoid this except to block a tiny amount of profit to ARM out of corporate spite. This isn't enabling a competitor in any real capacity.
 
(

In addition to what Exophase already said, don't forget that:

http://en.wikipedia.org/wiki/XScale

They've actually not been just building ARM chips for someone else (like they intend to now), but actually there was a time when they did design them.

So at least for me, even Intel designing an ARM chip would not be a "pigs fly" moment, but more of a "so what are they up to now" kind of thing...

)
 
(

In addition to what Exophase already said, don't forget that:

http://en.wikipedia.org/wiki/XScale

They've actually not been just building ARM chips for someone else (like they intend to now), but actually there was a time when they did design them.

So at least for me, even Intel designing an ARM chip would not be a "pigs fly" moment, but more of a "so what are they up to now" kind of thing...

)
I don't know how much Intel's x86 everywhere philosophy grew from then to now, but I bet they would have never done anything with XScale had they not acquired StrongARM as part of their spoils of war over DEC lawsuits. I bet XScale was already at least partially designed when they made the acquisition, although some things that happened to it were definitely very Intel (like WMMX). Still, they seemed pretty eager to sell it off to Marvell..
 
I don't know how much Intel's x86 everywhere philosophy grew from then to now, but I bet they would have never done anything with XScale had they not acquired StrongARM as part of their spoils of war over DEC lawsuits.
Yeah, it was definitely a "what are they up to now?"-moment for me already back then too, even though, to my "knowledge" *, Intel was not really even pushing to the mobile space with x86 back in those days? Even their back then so far most visible product, the Nokia 9000, switched to an AMD chip in the next iteration, then to ARM... though, actually, I think back then I somehow thought that moving the Communicator line of phones away from x86 was smart because Intel had also decided to bet on ARM instead and x86 in mobile space is going to die soon... hmmm... :wacko: ...

Maybe I wasn't the only one drawing this dumb conclusion, so I'm not surprised they wanted to get rid of XScale...

* (very limited and vague recollections, as I followed the space most of the late 90's purely as a more-interested-than-average-consumer)
 
If Intel were betting on ARM they wouldn't have sold the XScale division to Marvell when they did. Although to my recollection by then the XScale implementation was mostly focussing on SCSI controllers and the likes, and less suited as a general purpose CPU for mobile usage, so it strikes me they were never that serious about getting into the mobile space with external IP.


Intel has been publicly crowing about their x86 power reductions for a number of years now, albeit only after ARM became the de-facto choice on mobile IIRC (which was well after the last 9000 series communicator, the 9210 as I recall). They've been focussing on it for a while now, but it would appear that for various reasons they're not there yet.
 
I guess intel cant stop it or are in charge of running the train, but want to get onboard? Very nice that they offer their production process, seems like that was their last stronghold in what was always a losing battle. Expect them to start implementing artificial restrictions if it competes with their server gear though.
 
Last edited by a moderator:
Back
Top