Intel X5-Z8300


vcoleiro1

vcoleiro1

Hardcore Member
Joined
Jan 23, 2011
Messages
4,685
This SOC looks good, perhaps a contender for a Pyra SOC upgrade board in the future.  Low TDP, uses 14nm , Cheap and available in low quantities  (1000).   

Looks like it will be much faster than the Z3735 in the dual boot tablet I use currently which in itself is good.

http://ark.intel.com/products/87383/Intel-Atom-x5-Z8300-Processor-2M-Cache-up-to-1_84-GHz

http://www.intel.com/content/www/us/en/embedded/products/braswell/atom-x5-processor-z8300-product-brief.html

http://linuxgizmos.com/intel-unveils-atom-x3-x5-and-x7-mobile-socs/

http://www.cpu-monkey.com/en/cpu-intel_atom_x5_z8300-538

Making it into products now:  http://liliputing.com/2015/08/meegopad-t04-is-a-cherry-trail-mini-pc-with-windows.html
 
Last edited by a moderator:
First thing I'm noticing is that it's one or two SDIO channels short. I can't find any reference to OTG support in the product breif. 
 
Last edited by a moderator:
slaeshjag said:
First thing I'm noticing is that it's one or two SDIO channels short
Click to expand...
The eMMC can be used as an SD so it's the same as the OMAP5.As a Pyra SoC replacement, I think it may have to make a choice though: second SD card or SDIO mounted wifi. Unless there's a way to rejigger the wifi chip on the mainboard to operate over I2S or UART but then your data speeds will be limited.

slaeshjag said:
I can't find any reference to OTG support in the product breif.
Click to expand...
It's in the datasheet: 3 super speed USB ports backwards compatible with 2.0 HS/FS/LS, and a single SS OTG port which I think is also backwards compatible.
 
vcoleiro said:
your better off going with the X5-Z8500
Click to expand...
The entire Z8x00 line seems to suffer from a lack of SD channels. I think that'd be the defeating feature, only being able to use one SD card. Although maybe it wouldn't be such a bad trade for some people.
 
I²S is designed for audio. It's not even a protocol for bidirectional data communication. UARTs are way way way too slow for WiFi (they don't go much higher than a couple megabits/s.)
 
WizardStan said:
slaeshjag said:
First thing I'm noticing is that it's one or two SDIO channels short
Click to expand...
The eMMC can be used as an SD so it's the same as the OMAP5.
As a Pyra SoC replacement, I think it may have to make a choice though: second SD card or SDIO mounted wifi. Unless there's a way to rejigger the wifi chip on the mainboard to operate over I2S or UART but then your data speeds will be limited.
Click to expand...
You said there were 3 integrated USB3 ports, perhaps integrate a USB3 based SD controller into the CPU PCB and use that for the second SD slot? (Edit: or for the wifi)


-Neelix
 
Last edited by a moderator:
Am I right into thinking that it's an x86 CPU ? Then it won't cut it. People want x86 because of Windows. It should never be.

There's a reason Macs were on PowerPC before. They only switched to Intel because no one were making better PPCs.

RISC is the only way to go. ARM is the future. I'm not against Intel (I use an i5 everyday), I'm against x86.

As soon as there's a viable option for ARM Windows, you'll see the performance increase.

ARM is becoming better and better everyday. Wait until 4+ cored 64-bit ARM CPUs get on your average computer.

The problem with x86 is that it still carries the slow instructions from its origins. If you open up a modern x86, you'll see something surprising :

The computing cores are pretty close to RISC processors. Only the interpreter allows for x86 instructions to run on it.

You can see a similarity with the NVIDIA K1 or X1. They use a RISC CPU, with an ARM interpreter for the microcode to be compatible.
 
slaeshjag said:
I²S is designed for audio.
Click to expand...
I2C, not I2S. It's a standard inter-chip communication protocol that can hit several Mbit/s. It's how the Pandora communicates with the charge chip and the nubs.
slaeshjag said:
UARTs are way way way too slow for WiFi (they don't go much higher than a couple megabits/s.)
Click to expand...
Agreed, but the alternative is to continue using the SDIO and lose the second SD slot.
Kev2442 said:
People want x86 because of Windows
Click to expand...
There's actually a solid number of people on this board that are interested in an x86 Pyra with Linux. Part of that is, admittedly, running Windows apps via Wine, but that's not the whole story, and those in-the-know (as it were) accept that it would be very difficult (almost impossible) getting it to actually run Windows.That being said, what you say is actually one of the major reasons why EvilDragon was firm on ARM: putting an x86 in the Pyra would have been a support nightmare. All your points were debated ad nauseum for weeks to come to this conclusion.

However, as an add on, once the Pyra is complete and functioning with its ARM processor, providing an x86 CPU replacement for those that want it becomes a lot more viable.
 
Oh snap! I did too. Gah, so sorry. I really did mean I2C. I was reading the datasheet when I wrote it, it says I2C, my brain should have been firmly in I2C. I have no idea where the I2S came from. Sorry again.
 
WizardStan said:
slaeshjag said:
First thing I'm noticing is that it's one or two SDIO channels short
Click to expand...
The eMMC can be used as an SD so it's the same as the OMAP5.
As a Pyra SoC replacement, I think it may have to make a choice though: second SD card or SDIO mounted wifi. Unless there's a way to rejigger the wifi chip on the mainboard to operate over I2S or UART but then your data speeds will be limited.
Click to expand...
It can also run two PCI Express lanes - each one of which can handle multiple SDIO slots, SATA, networking and/or wireless of any/all sorts, etc...  They're revision 2.0 and can handle 500MB/s per lane for 1GB/s of data (theoretical).

So - how is it limited to only 2 SDIO channels again?
 
I suppose that's fair, put some kind of external SDIO controller on the CPU board and put it through the PCI-E. Makes the CPU board that much more complex but I suppose it's probably doable.
 
WizardStan said:
There's actually a solid number of people on this board that are interested in an x86 Pyra with Linux. Part of that is, admittedly, running Windows apps via Wine, but that's not the whole story,


...

...


However, as an add on, once the Pyra is complete and functioning with its ARM processor, providing an x86 CPU replacement for those that want it becomes a lot more viable.
Click to expand...
Hmmm... I'm hesitant to post my view on this as it could be all wrong and it might just be my incompetence and/or lack of enthusiasm, BUT here goes anyway:

After messing with the Pandora and specifically messing with the kind of software the Pandora runs to provide us our Fun, a lot of new thoughts and ideas have been running through my head with regards to ARM vs. x86.

I've had plenty of previous experience of both (doing C/C++) but the new "viewpoint" has been kind of revealing.

In a nutshell: an ARM SOC is cooler in many ways, not just with heat dissipation :)... unfortunately, at least with bog standard-running-on-the-Pandora-itself-GCC a lot of that cool gets frozen over by the sheer popularity of x86 in Linux world and resulting assumptions in code.

In x86 you take software, you set commonly agreed flags in the compiler to commonly agreed positions, you make and you end up with a result that is typically so optimal optimization is no longer worth the effort. If it runs quick enough, great. If not, there's nothing you can do unless it's "just on the edge of being fast enough" -  a rare occurence.

Even if something could be done that in itself is so rare you don't even bother to investigate :).

Not so in ARM, at least with the CortexA8 and gcc492 (version I've ended up with due to webkitgtk) in the Pandora. You get software that works. If it's fast enough, fine. But sometimes it's not fast enough not because the CPU is not fast, but because you should spend some time doing all kinds of inlining, NEON intrinsickymagic'nstuff and Guru'sOfARM only know what else... I never hit this stuff when I did actual work as it was boring code using plain integers for boring machines doing boring things on hardware sized suitably for a bored monkey like me to succeed in fitting the pieces in...

But the Pandora is different. You somehow feel "things could still be better if I could better utilize X". Even not counting the transistors used for a DSP that is rarely, if ever, utilized... I know people find stuff like that cool, at least I know I do, it's what I liked in Old Computers too... But as I'm now old I rather like it better when it's not me doing it, scavenging the web for wise men's words and trying to academically guess whether something "fits in the power envelope of this thing or I'm just wasting my time" :).

Maybe the Pandora devs, being Gurus of ARM one and all never suffer from this.

In a way I now see this is exactly what the intrusion of PCs as "home computers" took away from us already in the early 90s: the feeling of "pushing the envelope" was replaced with buying bigger envelopes and paying someone else for doing the packing :).

So, I guess that's what I find appealing in a x86 cpu: It's boring as *ell!-)

And "the thing" in an x86 CPU would not be Windows, or Wine... I still don't believe the interface would work for most precompiled binaries anyway. What x86 has going for it is boredom.

I don't, however, think the Pyra needs an x86 CPU board: it needs one less and less with time. ARM gains popularity: who knows, maybe GCC gets smarter. In any case software will be optimized for the Pyra (sauce please when it does...) and so before an x86 board even gets planned, there's no need for such boredom anymore.

I'd keep the ARM board if a x86 version popped up simply to "stick to my guns". This Pandora runs ARM so the gun has been chosen. I'm not dead set against x86 either, but somehow I prefer buying it in the 100 euro trash without changeable batteries... stuff you know you dispose of within a year or two because it's obsolete by then. That's not how I see the Pandora or the Pyra. They are neither cheap or boring :).

So, anyway, thanks to vcoleiro - I seriously considered getting a 7 inch cheapo supermarket tablet this week from a sale... Will skip now - I think I'll wait and see whether this next iteration of Intel could finally hit the 8-10 hours of battery time I'd prefer...

Whoops... did the wall of text thing again... well... at least it was General talk this time...
 
vcoleiro said:
This SOC looks good, perhaps a contender for a Pyra SOC upgrade board in the future.  Low TDP, uses 14nm , Cheap and available in low quantities  (1000).   

Looks like it will be much faster than the Z3735 in the dual boot tablet I use currently which in itself is good.

http://ark.intel.com/products/87383/Intel-Atom-x5-Z8300-Processor-2M-Cache-up-to-1_84-GHz

http://www.intel.com/content/www/us/en/embedded/products/braswell/atom-x5-processor-z8300-product-brief.html

http://linuxgizmos.com/intel-unveils-atom-x3-x5-and-x7-mobile-socs/

http://www.cpu-monkey.com/en/cpu-intel_atom_x5_z8300-538

Making it into products now:  http://liliputing.com/2015/08/meegopad-t04-is-a-cherry-trail-mini-pc-with-windows.html
Click to expand...
Wow, all that for ~ $25? I'm a little bit impressed. I guess the OMAP5 for the Pandora is more expensive. However, some real life benchmarks would be nice. But of course it is always hard to compare ARM and x86 in that way. I am also interested in the comparable power consumption in relation to the OMAP55. :)

MrConfusion said:
In a nutshell: an ARM SOC is cooler in many ways, not just with heat dissipation :)... unfortunately, at least with bog standard-running-on-the-Pandora-itself-GCC a lot of that cool gets frozen over by the sheer popularity of x86 in Linux world and resulting assumptions in code.
Click to expand...
Now that you mention this, I also doubt such an Atom CPU would ever fit into the Pyra. I guess Atom CPUs need at least a  decent passive cooling like an head spreader. There is just no space for this. ^^"
 
Last edited by a moderator:
There are instruction set agnostic tests like dhrystone and whetstone, but those can be distorted by caching strategies, and may not be representative of real-world tasks any more.  I'm not sure what the relevant bodies have done to counter that issue, but presumably something's out there.

Power consumption is a tightly guarded property though, and getting real-world numbers on that can be hard with spin being prevalent.  I got burned buying into atom early due to dodgy figures on that front.
 
Grench said:
It can also run two PCI Express lanes - each one of which can handle multiple SDIO slots, SATA, networking and/or wireless of any/all sorts, etc...  They're revision 2.0 and can handle 500MB/s per lane for 1GB/s of data (theoretical).   So - how is it limited to only 2 SDIO channels again?
Click to expand...
WizardStan said:
I suppose that's fair, put some kind of external SDIO controller on the CPU board and put it through the PCI-E. Makes the CPU board that much more complex but I suppose it's probably doable.
Click to expand...


Assuming that the extra circuitry needed to pull any of that off can fit on the small CPU daughterboard...
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top