SoC: Back and forth!


One thing that comes to my mind:

OMAP does not support POP.

Do Snapdragon, Allwinner and Bay Trail support it?

If so it might be a nice gain of board space I think.
 POP

TI: was planned (OMAP5430) but apparently not going into mass production

Snapdragon: most likely yes (and no non-PoP if I interpret the graphics on http://www.qualcomm.com/snapdragon/processors/800 correctly.

Allwinner A80: most likely no (from the photos of the announced eval board)

BayTrail: no (from the data sheet - package description)

It looks as if PoP is not available for tablet oriented SoCs and standard for Smartphone oriented SoCs (the OMAP5430 was originally developed in cooperation and for Nokia).

One thing to note is that we have more space constraints in the height (PoP is higher) than in the area since the SoC must sit right under the battery (which makes some problems to avoid overheating the battery). So having non-PoP might help with heat transport and is anyways much easier for production (although we have learned for the OpenPandora and GTA04 projects how to do it, so it is not a k.o. feature).
 
Last edited by a moderator:
One thing that comes to my mind:


OMAP does not support POP.


Do Snapdragon, Allwinner and Bay Trail support it?


If so it might be a nice gain of board space I think.
 
POP


TI: was planned (OMAP5430) but apparently not going into mass production


Snapdragon: most likely yes (and no non-PoP if I interpret the graphics on http://www.qualcomm.com/snapdragon/processors/800 correctly.


Allwinner A80: most likely no (from the photos of the announced eval board)


BayTrail: no (from the data sheet - package description)


It looks as if PoP is not available for tablet oriented SoCs and standard for Smartphone oriented SoCs (the OMAP5430 was originally developed in cooperation and for Nokia).


One thing to note is that we have more space constraints in the height (PoP is higher) than in the area since the SoC must sit right under the battery (which makes some problems to avoid overheating the battery). So having non-PoP might help with heat transport and is anyways much easier for production (although we have learned for the OpenPandora and GTA04 projects how to do it, so it is not a k.o. feature).
Interesting.

Thaks :) .
 
from the Allwinner wikipedia page - would this be a problem?

The A-Series; A10, A20 and A31 SoC's has a proprietary inhouse designed multimedia co-processing DSP (Digital Signal Processing) processor technology for hardware accelerated video, image, and audio decoding, called CedarX (with subprocssing called "CedarV" for video decoding and "CedarA" for audio decoding), able to decode 2160p 2D and 1080p 3D video. The main disadvantages with this CedarX technology and libraries is that Allwinner's own CedarX proprietary libraries have no clear usage license, so even if the source code for some versions is available the terms-of-use is unknown in open source software, and there is no glue code for any other multimedia frameworks on GNU/Linux systems that could be used as a middle-ware, like for example OpenMAX or VAAPI.
 
from the Allwinner wikipedia page - would this be a problem?

The A-Series; A10, A20 and A31 SoC's has a proprietary inhouse designed multimedia co-processing DSP (Digital Signal Processing) processor technology for hardware accelerated video, image, and audio decoding, called CedarX (with subprocssing called "CedarV" for video decoding and "CedarA" for audio decoding), able to decode 2160p 2D and 1080p 3D video. The main disadvantages with this CedarX technology and libraries is that Allwinner's own CedarX proprietary libraries have no clear usage license, so even if the source code for some versions is available the terms-of-use is unknown in open source software, and there is no glue code for any other multimedia frameworks on GNU/Linux systems that could be used as a middle-ware, like for example OpenMAX or VAAPI.
No,it's basically the same thing as with pandora DSP. It just won't be used, probably forever
 
Last edited by a moderator:
One thing that comes to my mind:


OMAP does not support POP.


Do Snapdragon, Allwinner and Bay Trail support it?


If so it might be a nice gain of board space I think.
 
POP


TI: was planned (OMAP5430) but apparently not going into mass production


Snapdragon: most likely yes (and no non-PoP if I interpret the graphics on http://www.qualcomm.com/snapdragon/processors/800 correctly.


Allwinner A80: most likely no (from the photos of the announced eval board)


BayTrail: no (from the data sheet - package description)


It looks as if PoP is not available for tablet oriented SoCs and standard for Smartphone oriented SoCs (the OMAP5430 was originally developed in cooperation and for Nokia).


One thing to note is that we have more space constraints in the height (PoP is higher) than in the area since the SoC must sit right under the battery (which makes some problems to avoid overheating the battery). So having non-PoP might help with heat transport and is anyways much easier for production (although we have learned for the OpenPandora and GTA04 projects how to do it, so it is not a k.o. feature).
Snapdragon 805 or Omap5432. Either is lovely.
 
Wont Snapdragon mean we lose binary compatibility for anything NEON optimized? I'd hate to lose all that work done for the PS1 emulator. OMAP should be able to run PS1 games with lower power usage than Snapdragon due to NEON right?
 
Wont Snapdragon mean we lose binary compatibility for anything NEON optimized? I'd hate to lose all that work done for the PS1 emulator. OMAP should be able to run PS1 games with lower power usage than Snapdragon due to NEON right?
No, it just means that the NEON code will probably not be executed as efficiently as on OMAP5 (at least when both are clocked to the same speed). But still much faster than on OMAP3 I guess.
 
Wont Snapdragon mean we lose binary compatibility for anything NEON optimized? I'd hate to lose all that work done for the PS1 emulator. OMAP should be able to run PS1 games with lower power usage than Snapdragon due to NEON right?
 No, it just means that the NEON code will probably not be executed as efficiently as on OMAP5 (at least when both are clocked to the same speed). But still much faster than on OMAP3 I guess.
At least for older Snapdragons NEON was slower for OMAP3, so we don't know that.
 
If Qualcomm can/will give real Linux drivers, Snapdragon might be worthy of consideration, but I really doubt that. Jolla's phone that is Linux based and uses Qualcomm chipset needs to use the Android drivers through libhybris "glue". So if they couldn't get Linux drivers (the original production batch was estimated 20-50k units), I really doubt ED can get them...

And even the drivers/binary blobs might be problematic based on this post about Jolla's firmware flashing. So although the Jolla device is nice, the SoC choice was problematic after their original choice of ST-Ericson NovaThor fell through after the companies split their cooperation.
 
At least for older Snapdragons NEON was slower for OMAP3, so we don't know that.
That link notaz gave doesn't give enough to broadly draw that conclusion. From the "ILP" numbers for A8 it looks like it's testing a 2-cycle latency simple ALU op (not float, not multiplication, not using shifts, narrows, widens, etc), but it still doesn't specify which. It probably doesn't check to see if the S4 can execute out of order or not.

It seems to show that latency is 3 cycles instead of 2 cycles for whatever NEON instruction is used, and it can only execute one of them at a time (same with the tested A8). Even simple OoO could negate the higher latency in a lot of real world code. And a lot of less simple NEON instructions have 3+ latency on Cortex-A8 too, so it depends a lot on the instruction mix for both cases. And we don't know what kind if NEON instructions were mixed. The conclusion they gave from the data that S4 can't execute more than 1 NEON instruction per cycle should also apply to Cortex-A8, yet we know this isn't totally true since it can dual-issue load/store/permute NEON instructions with other NEON instructions.

Plus it's just a perf/MHz test, doesn't take into consideration clock speed, an S4 can clock to at least 1.5GHz..
 
Last edited by a moderator:
Here, the board is based on EOMA68 'open standard' module with Allwiner A20. ...
Since mentioned allready, won't that be running some test with that improv Hadware (ok it's "just" an allwinner A20) ?

BTW: I REALLY like the disign: a PCMCIA sized card, wich carries the SoC, hdmi, micro sdCard and microUSB and an extensionboard (with open hardware design). Maybe it's worth thinking about to have that design in the Pyra. Maybe it's even possible to get different CPU/SoC by getting the output of the PCMCIA CPU card pin compatible to the daughterboard.

The ScO will be updateable, sinergy on the SoC part, the board for the Pyra could possibly be less expensive, because of fewer layers.

OK the above is more or less a "wild guess" on my side, since I'm no hardware designer at all and I'm aware this will make the Pyra possibly bigger in size. But perhaps it's worth thinking about? Even if it's just to show why this is a bad idea.
 
We hashed out the whole EOMA68 prospect on a thread once (since lkcl thought we should use it), personally I think that the 68 pin interface is way too limited to be useful for Pyra.
 
Here, the board is based on EOMA68 'open standard' module with Allwiner A20. ...
Since mentioned allready, won't that be running some test with that improv Hadware (ok it's "just" an allwinner A20) ?

BTW: I REALLY like the disign: a PCMCIA sized card, wich carries the SoC, hdmi, micro sdCard and microUSB and an extensionboard (with open hardware design). Maybe it's worth thinking about to have that design in the Pyra. Maybe it's even possible to get different CPU/SoC by getting the output of the PCMCIA CPU card pin compatible to the daughterboard.

The ScO will be updateable, sinergy on the SoC part, the board for the Pyra could possibly be less expensive, because of fewer layers.

OK the above is more or less a "wild guess" on my side, since I'm no hardware designer at all and I'm aware this will make the Pyra possibly bigger in size. But perhaps it's worth thinking about? Even if it's just to show why this is a bad idea.
EOMA68 has not enough contact pins for what we need (HDMI, MIPI, I2C, multiple USB, multiple SD, Audio). We need ~150 signals.

And PCMCIA is not the best form factor for swappable CPU modules inside the Pyra dimensions. So we better invent our own "standard".

The potentially lower cost of the Pyra main board (the demonstrator is just 2 layers instead of 8 compared to the OpenPandora) is the reason why I favour this as well. If it can finally be done depends on other factors like thickness and thermal energy distribution. And if it is really cheaper (depends on several factors like production batch size, cost of connectors). But it would improve serviceability.
 
Glad to see I wasn't the only one who thought a daughter board has benefits ;)

If there's any tangible risk of SoC failures (eg with an Allwinner purchase, insert horror stories about Chinese parts here) it'd be even more prudent..
 
EOMA68 has not enough contact pins for what we need (HDMI, MIPI, I2C, multiple USB, multiple SD, Audio). We need ~150 signals.

And PCMCIA is not the best form factor for swappable CPU modules inside the Pyra dimensions. So we better invent our own "standard".

The potentially lower cost of the Pyra main board (the demonstrator is just 2 layers instead of 8 compared to the OpenPandora) is the reason why I favour this as well. If it can finally be done depends on other factors like thickness and thermal energy distribution. And if it is really cheaper (depends on several factors like production batch size, cost of connectors). But it would improve serviceability.
Sorry for overreading the "too few signals" part.

What I like about the "2 Boards" Design even more is, that this could end in even more interesting devices, because it will be a hell more hardwarehackable :)

1) an old Notebook case with a cluster of several "Pyra cores"

2) an ultra small Pocket device (as a non-phone, non-NSA-spying minicomputer)

...

I like the idea of the improv module to have 1USB, 1HDMI and one microSD slot on the coredevice, though
 
I like the idea of the improv module to have 1USB, 1HDMI and one microSD slot on the coredevice, though
Wouldn't that make the board rather too big?

Better so sell a simple breakout board for it.
 
It irks me that we don't have any (hopefully good) replies yet.   
 
Last edited by a moderator:
Is there a nice NEON benchmark we could run on a dev board to confirm this junk?

The potentially lower cost of the Pyra main board (the demonstrator is just 2 layers instead of 8 compared to the OpenPandora) is the reason why I favour this as well. If it can finally be done depends on other factors like thickness and thermal energy distribution. And if it is really cheaper (depends on several factors like production batch size, cost of connectors). But it would improve serviceability.
Are you trying to build a "modular" kind of design? seperate pcb for the buttons and the SOC?
 
Last edited by a moderator:
Back
Top