The Bay Trail Preview: Intel Atom Z3770 Tested
by Anand Lal Shimpi & Brian Klug on September 11, 2013 12:00 PM EST
Earlier this year Intel unveiled Silvermont, its first true architectural update to Atom since its introduction in 2008. I won’t rehash Silvermont’s architecture here, but it’s designed to be a true test of Intel’s performance in the ultra mobile space. Leveraging Intel’s first 22nm SoC process and a very low power/efficient microarchitecture, Silvermont aims squarely at the latest Krait cores from Qualcomm and ARM’s Cortex A15.
Today Intel takes the next step forward, introducing the first tablet SoC based on Silvermont: Bay Trail.
Bay Trail takes up to four Silvermont cores, and for the first time in an ultra mobile Intel SoC pairs them with Intel’s own graphics IP. That’s right, rather than using a GPU block from Imagination Technologies, Bay Trail leverages the same GPU architecture as Ivy Bridge.
The first Bay Trail tablets will be shipping by the end of the year, across both Android and Windows 8.1. Intel expects Bay Trail to show up in tablets and 2-in-1s priced below $599, with everything above $599 falling under Haswell’s jurisdiction.
Bay Trail & Branding
Bay Trail, like all Atom platforms before it, will be available in multiple form factors. Unlike the Atoms of yesterday however, the SoC will carry Pentium and Celeron branding when used in notebooks and desktops. Intel didn’t disclose too much about its Silvermont plans in other form factors other than some basic naming:
Basically notebooks ship under the Pentium N3000 & Celeron N2000 series, while desktops will carry Pentium J2000 & Celeron J1000 branding. All Pentium SKUs seem to be quad-core, while Celeron SKUs will be available in both dual and quad-core versions.
Thankfully Intel shied away from introducing the same complexity with its tablet focused Bay Trail parts. All Bay Trail tablet SKUs carry Atom branding. There’s the quad-core Z3700 series and the dual-core Z3600 series.
Although Intel offers both dual and quad-core Bay Trail SKUs, they are both based on the same single physical design. In other words, dual-core Bay Trail parts are just die harvested quad-core parts. Intel isn’t disclosing die size or transistor counts, which is ironic (and disappointing) given that Apple just disclosed both (or at least relative magnitude of one) for its A7 SoC.
Internally, the Bay Trail design is pretty nice. There are either two or four cores enabled, each pair with a shared 1MB L2 cache (2MB total for a quad-core part). Intel is following the unfortunate lead of everyone else in the mobile industry and advertising max turbo frequencies exclusively.
Thankfully Intel hasn’t yet decided to obfuscate max non-turbo frequencies:
| Bay Trail Turbo Speeds | ||||||||
| Z3770 | Z3770D | Z3740 | Z3740D | Z3680 | Z3680D | |||
| Max turbo frequency | 2.39GHz | 2.41GHz | 1.86GHz | 1.83GHz | 2.0GHz | 2.0GHz | ||
| Max non-turbo Frequency | 1.46GHz | 1.5GHz | 1.33GHz | 1.33GHz | 1.33GHz | 1.33GHz | ||
In general you’re looking at 1.33GHz - 1.46GHz max non-turbo frequencies, with Bay Trail being able to turbo up to anywhere between 1.83GHz and 2.40GHz depending on SKU.
Although the core architecture is 64-bit in design, there will be no OS support for 64-bit Bay Trail at launch. Windows 8.1 with Connected Standby appears to still be 32-bit only, and obviously Android is 32-bit only at this point as well.
The memory interface is fairly ridiculous by mobile standards. You either get two 64-bit LPDDR3 channels (128-bit total width) or a single 64-bit DDR3L channel. In the case of the former, that’s the same memory bus width as Apple’s A5X/A6X line of SoCs as well as the standard Core i3/i5/i7 parts. Max supported memory frequency is 1066MHz in dual-channel LPDDR3 mode, or 1333MHz in single-channel DDR3L mode. The only benefit to the latter is really cost, as Bay Trail will purportedly show up in some very cheap devices.
The GPU is Intel’s own Gen7 graphics core, a cut down implementation of what we first saw in Ivy Bridge. I suppose it’s premature to expect Merrifield, Bay Trail’s smartphone counterpart, to also use Intel’s own graphics core but it’s clear this is the direction Intel is headed in - and away from licensing IP from Imagination Technologies.
Rather than 16 EUs in the Ivy Bridge GT2 configuration (HD 4000), Bay Trail’s HD Graphics core ships with 4. The 4 EUs are otherwise effectively identical to what we found in Ivy Bridge. The GPU can dynamically scale frequency and share power between itself and the CPU cores. Minimum GPU frequency on Bay Trail is 311MHz and a max GPU frequency of 667MHz (or 688MHz for the DDR3L SKUs).
Intel is quick to point out that Bay Trail’s GPU supports DirectX 11 and OpenGL ES 3.0. Unfortunately this support list appears limited to Windows. Under Android, it’s unclear whether or not Bay Trail will ship with anything above OpenGL ES 2.0 support. The same goes for GPU accelerated Renderscript. Bay Trail supports up to 2560 x 1440 displays over eDP1.3/DP1.2, or 1080p over HDMI. Panel Self Refresh is also supported.
Video encode and decode blocks also shifted away from Imagination in Bay Trail. Both IP blocks are custom from Intel now. The ISP (Image Signal Processor) is from Silicon Hive (an Intel acquisition).
Facebook
Twitter
RSS
190 Comments
View All Comments
zeo - Saturday, September 14, 2013 - link
Sorry but nothing you just said changes anything I stated! The Smartphone market has no real use for HSA or hUMA and until it does then there will be no real push to adopt it.Problem is there's more widely accepted standards already available and what AMD is pushing only really benefits their hardware! Really, HSA is not limited to what AMD is trying to establish... they just want their solution to become the defacto standard but that's easier said than done!
AMD won't even add discrete GPU support until sometime next year. So you're stuck with limited APU's right now for example!
So this isn't even a finished standard they're trying to push!
Right now the main interest is in the server market, where custom software is common and it's a lot easier to push a new proprietary solution and that's the main reason why ARM and it's many partners are interested in it...
Problem is for this to really take off it needs to appeal to the general consumers but like CUDA, applications are few and far between right now...
Sure, there's potential but there's nothing to suggest yet it will succeed any more than CUDA did and that has been around a lot longer!
Though, it does benefit AMD in that they can easily swap out their x86 cores for ARM cores and still offer HSA, etc... So gives them some much needed diversity and flexibility as they continue to push their solutions to market...
teiglin - Wednesday, September 11, 2013 - link
One thing that would be nice to see in the charts is max turbo clocks as well as nominal clocks where relevant. You list all parts with nominal frequencies, which makes it hard to get a handle on per-clock performance. Off the top of my head, I know that the i7-3517U is going to have max turbo around ~3GHz and that the Pentium 2020M has no turbo, but I had to go look to see that the trinity part listed has a 3.2GHz turbo.Of course, that doesn't really get into the discussion of how much time each CPU really spends at those turbo clocks--that is obviously a more nuanced point, which I'd love to see you guys investigate as it changes with chassis/cooling design and probably other vendor-specific settings--but it'd still be helpful as a basis for comparison. And of course if you ever include ARM chips in those charts, which generally include unsustainable max clocks (and no listed TDP).
TheinsanegamerN - Wednesday, September 11, 2013 - link
this. the 4600m has some very interesting turbo issues, often dropping below base clocks when any power is sent to the gpu. and, was this atom boosting the whole time, or was it running at its base clocks?Shivansps - Wednesday, September 11, 2013 - link
What i whould like to see is the E-350/E450/E2-1800 being added in the games comparison, the HD63xx based may be more powerfull, but in games the IGP could not get the most of it because of crappy CPU performance and lack of memory bandwidth of Brazos.nitrousoxide - Wednesday, September 11, 2013 - link
Another design by Intel with an overpowered CPU and an underwhelming GPU? This thing should have at least 6EUs to be competitive. And those two extra cores aren't really necessary since you can't expect a tablet to be productive. Why don't they make it 2C+6EU?However Bay Trail is really going to put the last nail in the coffin on AMD's mobile strategy. AMD's only advantage here is a way faster GPU but only on 15W/25W Kabini parts. The 3.9W Temash is clocked at 225MHz which put it on the same level as HD6310 and thus the GPU is at best as slow as the 4EUs that Bay Trail has. AMD now has nothing competitive even though Kabini/Temash is a massive improvement over Brazos.
Shivansps - Wednesday, September 11, 2013 - link
I think we need to compare IGP performance in actual games, as i was saying, for example the HD6310 performs quite well in benchmarks, and yet still get beaten by HD2000 in some games because the slow cpu and memory bandwidth was not helping at all. Bay Trail Atoms need to be compared to Brazos, Temash and Kabini in games, benchmarks may lead to have a wrong impresions here, i think it may able to beat brazos in some games.jason404 - Wednesday, September 11, 2013 - link
Will Bay Trail have Intel WiDi support?Hopefully there will at least be Miracast support on the eventual Bay Trail powered ThinkPad Tablet 3. Can't wait!
zeo - Wednesday, September 11, 2013 - link
Yes, Bay Trail Support WiDi... Miracast, etc... It even support features they normally disable in low end GMA's like Quick Sync...It may still be low end performance but it's a significant upgrade from the previous ATOM in pretty much every respect...
Anders CT - Wednesday, September 11, 2013 - link
The performance looks really good. It was about time Intel entered the fray.That being said Bay Trail faces a number of obstacles to be accepted in mobile space.
1) Bay Trail executes the wrong instruction set. Android is the new Windows, and making it work on the Bay Trail is critical for the SoCs succes. And while porting the Android software stacks to x86 is doable it is not trivial. The user of a Bay Trail device might not be able to download every app from the Market. Why doesn't Intel just make it an ARM SoC?
2) Price. A Tegra 4 or Snapdragon 600 SoC can be had for less than 20$. Will Intel compete at this price-point? That would be very unlike the Intel we know.
3) Other parts of the SoC: Krait and Cortex cores can be combined with on-chip dsp processors, radios, various controllers and other stuff. The appeal of an Intel SoC will be lessened, if it requires one, two or tree external chips to be added to the design. Qualcomm SoC's are very succesful in part because they put so much in a single package, leading to a simpler and less expensive board.
zeo - Wednesday, September 11, 2013 - link
Actually, Google officially supports Android on x86... Intel devices have been getting the latest Android release for the past year!For Medfield and Clover Trail+ they just added a Binary Translation layer to ease compatibility with Native, ARM optimized, apps... which are mostly games... While Google support means they also updated all the SDKs so developers can easily develop for both platforms and support for Intel devices has improved significantly over the last year.
Just look up early reviews when Intel ATOM based Android devices first came out a year ago to more recent ones and you'll see most apps run fine now...
While Silvermont supports virtualization extensions and that can be used to accelerate some Binary Translation and similar operations for better performance for non-x86 optimized native apps... combined with the better performance should make for a much more comparable experience... Mind, with Android apps being mostly hardware agnostic, Intel started with over 90% compatibility and that has only improved as developer support has grown and will continue to improve if Intel keeps on gaining market share in the mobile market...
It also helps they're going to start pushing Android on traditional PC systems, many running Android on the Intel processors... So that'll help boost developer interest in x86 support...