slaeshjag
¯\_(ツ)_/¯
Afaik, neither of those does.
SoC: Back and forth!
- Thread starter EvilDragon
- Start date
hns
Well-Known Member
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:
hitbyambulance
Active Member
from the Allwinner wikipedia page - would this be a problem?
No,it's basically the same thing as with pandora DSP. It just won't be used, probably forever
Last edited by a moderator:
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
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?
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.
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.
Exophase
Nothing good will ever come of Exophase.
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:
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.
Exophase
Nothing good will ever come of Exophase.
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.
hns
Well-Known Member
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.
Exophase
Nothing good will ever come of Exophase.
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..
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..
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
Wouldn't that make the board rather too big?
Better so sell a simple breakout board for it.
Neelix
Insecticidal Maniac
ShleeDragon
Pro-Catflip
- Joined
- Aug 28, 2010
- Messages
- 1,749
Is there a nice NEON benchmark we could run on a dev board to confirm this junk?
Are you trying to build a "modular" kind of design? seperate pcb for the buttons and the SOC?
Last edited by a moderator:
