Final Words

Silvermont really is Intel’s Conroe for the mobile market, but not in the sense that many have been expecting. Given that success in mobile is so closely tied to device wins, Silvermont alone isn’t enough. Unlike Conroe, a very competitive Silvermont won’t change the world overnight. What Silvermont does however is offer a great foundation for Intel going forward. Conroe lead to Penryn, Nehalem, Westmere, Sandy Bridge, Ivy Bridge and soon, Haswell. It was the platform that Intel could build on regularly by executing on tick-tock. Conroe paved the way for the insane advantage Intel has held onto for the past few years. Silvermont is like Conroe in that it provides that same foundation.

The mobile market is far more competitive than the PC industry was back when Conroe hit. There isn’t just one AMD but many competitors in the SoC space that are already very lean and fast moving. There’s also the fact that Intel doesn’t have tremendous marketshare in ultra mobile. Silvermont may feel a lot like Conroe, but the market it’s competing in is very different. That’s not to say that Intel can’t be successful here; it’s just not going to be easy.

Architecturally Silvermont is very conservative, and that’s not a bad thing. A side effect of not wanting to make Haswell irrelevant by a far lower cost part is the benefit of maintaining power efficiency. Intel joins the ranks of Apple and Qualcomm in intelligently scaling performance while respecting power consumption. Intel’s 22nm process should give Silvermont a lot of runway to use. If it can quickly follow up with 14nm, Silvermont’s power advantage could end up being akin to Conroe’s performance advantage in the mid-2000s.

Even so, Silvermont is long overdue. It’s the first mobile architecture where Intel really prioritized smartphones and tablets, and on paper, it looks very good. Now it’s up to Intel to turn a great architecture into great design wins. From what I’m hearing, we may actually see that happen.

Tablet Expectations & Performance


View All Comments

  • xTRICKYxx - Tuesday, May 7, 2013 - link

    You're right. Intel has nothing to show at all.... Its not like they have the most powerful mobile and desktop consumer processors available. Reply
  • R0H1T - Tuesday, May 7, 2013 - link

    Yeah, now sit & watch that market(x86) die a slow death at the hands of mobile/tablets that are powered by "good enough" ARM which doesn't need teraflop level of performance to sell their stuff unlike Intel ! Reply
  • misaki - Monday, May 6, 2013 - link

    Wow, clearly you are a new reader. This is an architecture overview, not a performance article, which means the information HAS to come from Intel. They have done these type of articles with every architecture redesign since the 90's.

    When chips are available to test that is when the real world performance articles will come out.
  • Ortanon - Monday, May 6, 2013 - link

    SERIOUSLY. Reply
  • kyuu - Monday, May 6, 2013 - link

    Yes, but a lot of performance claims are being made in the article, and Anand really seemed to just be taking Intel's marketing speak for gospel. That's how it read, at least. Reply
  • xTRICKYxx - Tuesday, May 7, 2013 - link

    Not really. He clearly states to take the graphs cautiously. Also Intel may be slightly misleading, but nothing in the graphs are lies. They chose the best possible scenario for the greatest advantage. Reply
  • R0H1T - Tuesday, May 7, 2013 - link

    Like how they(AT) claimed Intel's "SDP" was superior after stress testing an Exynos Octa, yup loved that fairytale ! Reply
  • Kevin G - Monday, May 6, 2013 - link

    The article mentions that the IDI is similar to internal bus found on the Nehalem and later desktop processor. IDI here is mentioned as a point-to-point interconnect where as everything is linked via a ring bus in recent Core processors. Of course you can loop multipe point-to-point interfaces into a loop but the article's wording allows for other topologies.

    For example, each Silvermont module could have its down dedicated point-to-point link to the system agent. In Nehalem, the system against logically appears as another hop in the internal ring bus.
  • Exophase - Monday, May 6, 2013 - link

    Small correction:

    "Remember that with the first version of Atom, Intel enabled the fusion of load-op-store and load-op-execute instructions. Instead of these instruction combinations decoding into three and two micro-ops respectively, they would be fused post-fetch and treated like single operations throughout the entire pipeline."

    Atom (the current one anyway) doesn't have instruction (macro-op) fusion. It does handle load + op and load + op + store are one issue down the pipeline but they still came from single instructions that are a natural part of the x86 ISA. While these may be considered fused micro-ops in Intel's other CPUs that terminology doesn't fit Atom.

    These operations do need multiple instructions on most more RISCy ISAs like ARM. But the same is true the other way around (notably, 3 address arithmetic). I very much doubt you'll find typical x86 programs only need 2 instructions for every 3 ARM instructions on average, or at least any papers I've seen that measure micro-ops vs instructions on high-end CPUs are nowhere close to 1.5 (and a uop isn't generally more powerful than an ARM instruction, sometimes less when you consider two are needed for a store). But there are lots of other places that caused stalls on Atom that weren't related to decode, that it's easy to see how you could still gain a lot of perf/MHz without increasing it - as Bobcat and Jaguar have shown. All the details here do seem to point to a Bobcat-like design only with a much lower L2 cache latency and branch mispredict penalty which can only help more.
  • Anand Lal Shimpi - Monday, May 6, 2013 - link

    Er you're very correct. Atom doesn't break these instructions down further, they're treated like single ops throughout the pipeline. I've updated the section. Thank you! Reply

Log in

Don't have an account? Sign up now