Dual SoCs?

[a.ginger.turtwig]

Forgive me if this question is too dumb but, would a dual SoC design be possible if space on the cpu board was not an issue? I have seen dual cpu systems with server hardware but I haven't seen it done with ARM. Would more then a few cores even be useful for something like the pyra?

 

[Ocean112]

Two SoCs is a completely different thing from two CPUs. SoCs have graphics, usb controllers, timers, storage controllers, etc. built into them along with the CPU. It is--possible--technically just like anything else, but there's no reason to do it when there are better SoCs to move to in the future.

 

[levi]

The OMAP5 chip already contains four cores; two A-15 and two M-4. As for separate chips, there have been the odd older project like the hydra project, and there are plenty of implementations where the ARM is combined with another type of processor - the Dreamcast contained an ARM chip just to handle the system sound for example.

But there are reasons not to use separate chips when you can have multiple cores on one die. A big one I can think of is caches; you can stick a coherent L2 cache across both cores if they're in the same die.

 

[Ocean112]

A big one I can think of is caches; you can stick a coherent L2 cache across both cores if they're in the same die.

You know, we could go back to the days before the pentium pro and slot 1/A and have the L2 cache on the motherboard again!

 

[slaeshjag]

For a dual chip solution to be feasable, they both need to have a bus that can connect the two. SoCs for mobile use will with 100% certianty not support a shared memory space, which is what you want for high performance client applications. The only alternative is messaging protocols over interaces like SDIO or ethernet, which won't really work for anything other than distributed computation.

 

[Exophase]

For a dual chip solution to be feasable, they both need to have a bus that can connect the two. SoCs for mobile use will with 100% certianty not support a shared memory space, which is what you want for high performance client applications. The only alternative is messaging protocols over interaces like SDIO or ethernet, which won't really work for anything other than distributed computation.

That and you really want that bus to facilitate cache coherency.

 

[sepulep]

maybe more interesting is adding something like the Epiphany chip (http://www.adapteva.com/parallella/), which can be regarded as a general accelerator chip, which may be programmed e.g. to be an open source GPU .. apart from physical size the thermal budget may
be a problem..

 

[ible]

rolling one's own GPU seems difficult. but sounds cool!

5 W doesn't seem too bad, but i wonder how much the omap5 sucks down typically.

 

[TrashyMG]

Well according to this, under full load about 5W, however this was on the EVM board, Also the OMAP5 Kernel drivers have gone along way since this review came out and this is using the crusty Ti default Image which was horrible. https://www.linux.com/news/omap5432-review-texas-instruments-dual-core-arm-a15

 

[Exophase]

Well according to this, under full load about 5W, however this was on the EVM board, Also the OMAP5 Kernel drivers have gone along way since this review came out and this is using the crusty Ti default Image which was horrible. https://www.linux.com/news/omap5432-review-texas-instruments-dual-core-arm-a15

Apparently this was also power measured at the wall, which would include overhead from regulators that may be less efficient than the PMIC running from a battery.

On the other hand, based on the followup article, it sounds like it was only running at 800MHz :/

 

[Plume]

rolling one's own GPU seems difficult. but sounds cool!

5 W doesn't seem too bad, but i wonder how much the omap5 sucks down typically.

As far as my knowledge concerning this goes, designing a GPU isn't hard. However, designing a powerful, efficient and OpenGL-compliant GPU is another story.

 

[Grench]

How about this - if we're going to consider a multi-SOC implementation...

Create an ATX sized motherboard that can take a dozen of the Pyra SoC modules. I.e. provide networking to/from each. Create a rack that can handle a dozen of those motherboards. Port Beowulf to ARM - if it hasn't been done yet.
https://wiki.debian.org/DebianBeowulf

One machine with 144 SoC modules for 288 cores each with local RAM and eMMC with a power footprint on the order of under 700W.

Might have some interesting applications?

 

[levi]

The OMAP5 isn't PoP, so I assume it exposes an external RAM interface. It should be possible to wire that up to a bus before more RAM, but to get it to work reliably you'd need some super oscilloscope and a hell of a lot of debugging.

 

[TrashyMG]

The OMAP5 isn't PoP, so I assume it exposes an external RAM interface. It should be possible to wire that up to a bus before more RAM, but to get it to work reliably you'd need some super oscilloscope and a hell of a lot of debugging.

Well the OMAP5432 is not PoP, the short lived OMAP5430 was.

 

[pmprog]

I wonder if something like the Cyclone V/ARM SoC could be an option. Having a ARM core with an FPGA next to it might be really handy for expanding the emulation side of the Pyra.
That said, my latest FPGA dev board hasn't even made it out of the box yet :-(

 

[slaeshjag]

While a re-definable co-processor is a fun idea, I doubt it's really that useful to justify the significant cost of it.

 

[pmprog]

Very true. I need to stop thinking about projects that I have no time to implement anyway

 

[rygD]

While a re-definable co-processor is a fun idea, I doubt it's really that useful to justify the significant cost of it.

ED likes them. This would be a perfect excuse for him, and a way for us to get them in our Pyras. The first modular handheld pocketable community driven Debian-based gaming and productivity computer with an FPGA, or something.

On the serious side, would most people consider the Cyclone V an upgrade over the OMAP 5? I didn't read much about it, I just know that many of us are interested in using the Pyra for things other than games.

 

[slaeshjag]

An FPGA will never replace the SoC for computing. An FPGA will never replace a general purpose GPU. An FPGA *might* do better than either on a very specific workload.

 

[rygD]

An FPGA will never replace the SoC for computing. An FPGA will never replace a general purpose GPU. An FPGA *might* do better than either on a very specific workload.

I think I used the wrong words. I meant will most people consider the above SoC as an upgrade, not for the reasons you mentioned (which are a very good argument), but because it is a dual core A9 with a lower max speed. There may also be concerns related to RAM. I doubt an FPGA will add enough perceived value when other things are lower, resulting in performance drops with software that will already be used on the OMAP5.