Sandy Bridge: Outside the Core

With the growth of multi-core processors, managing how data flows between the cores and memory has been an important topic of late. We have seen a variety of different ways to move the data around a CPU, such as crossbars, rings, meshes, and in the future, completely separate central IO chips. The battle of the next decade (2020+), as mentioned previously here on AnandTech, is going to the battle of the interconnect, and how it develops moving forward.

What makes Sandy Bridge special in this instance is that it was the first consumer CPU from Intel to use a ring bus that connects all the cores, the memory, the last level cache, and the integrated graphics. This is still a similar design to the eight core Coffee Lake parts we see today.

The Ring Bus

With Nehalem/Westmere all of the cores had their own private path to the last level (L3) cache. That’s roughly 1000 wires per core, and more wires consume more power as well as being more difficult to implement the more you have. The problem with this approach is that it doesn’t work well as you scale up in things that need access to the L3 cache.

As Sandy Bridge adds a GPU and video transcoding engine on-die that share the L3 cache, rather than laying out more wires to the L3, Intel introduced a ring bus.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/ringbus.jpg

Architecturally, this is the same ring bus used in Nehalem EX and Westmere EX. Each core, each slice of L3 (LLC) cache, the on-die GPU, media engine and the system agent (fancy word for North Bridge) all have a stop on the ring bus. The bus is made up of four independent rings: a data ring, request ring, acknowledge ring and snoop ring. Each stop for each ring can accept 32-bytes of data per clock. As you increase core count and cache size, your cache bandwidth increases accordingly.

Per core you get the same amount of L3 cache bandwidth as in high end Westmere parts - 96GB/s. Aggregate bandwidth is 4x that in a quad-core system since you get a ring stop per core (384GB/s).

This means that L3 latency is significantly reduced from around 36 cycles in Westmere to 26 - 31 cycles in Sandy Bridge, with some variable cache latency as it depends on what core is accessing what slice of cache. Also unlike Westmere, the L3 cache now runs at the core clock speed - the concept of the un-core still exists but Intel calls it the “system agent” instead and it no longer includes the L3 cache. (The term ‘un-core’ is still in use today to describe interconnects.)

With the L3 cache running at the core clock you get the benefit of a much faster cache. The downside is the L3 underclocks itself in tandem with the processor cores as turbo and idle modes come into play. If the GPU needs the L3 while the CPUs are downclocked, the L3 cache won’t be running as fast as it could had it been independent, or the system has to power on the core and consume extra power.

The L3 cache is divided into slices, one associated with each core. As Sandy Bridge has a fully accessible L3 cache, each core can address the entire cache. Each slice gets its own stop and each slice has a full cache pipeline. In Westmere there was a single cache pipeline and queue that all cores forwarded requests to, but in Sandy Bridge it’s distributed per cache slice. The use of ring wire routing means that there is no big die area impact as more stops are added to the ring. Despite each of the consumers/producers on the ring get their own stop, the ring always takes the shortest path. Bus arbitration is distributed on the ring, each stop knows if there’s an empty slot on the ring one clock before.

The System Agent

For some reason Intel stopped using the term un-core in SB, and for Sandy Bridge it’s called the System Agent. (Again, un-core is now back in vogue for interconnects, IO, and memory controllers). The System Agent houses the traditional North Bridge. You get 16 PCIe 2.0 lanes that can be split into two x8s. There’s a redesigned dual-channel DDR3 memory controller that finally restores memory latency to around Lynnfield levels (Clarkdale moved the memory controller off the CPU die and onto the GPU).

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/systemagent.jpg

The SA also has the DMI interface, display engine and the PCU (Power Control Unit). The SA clock speed is lower than the rest of the core and it is on its own power plane.

Sandy Bridge Graphics

Another large performance improvement on Sandy Bridge vs. Westmere is in the graphics. While the CPU cores show a 10 - 30% improvement in performance, Sandy Bridge graphics performance is easily double what Intel delivered with pre-Westmere (Clarkdale/Arrandale). Despite the jump from 45nm to 32nm, SNB graphics improves through a significant increase in IPC.

The Sandy Bridge GPU is on-die built out of the same 32nm transistors as the CPU cores. The GPU is on its own power island and clock domain. The GPU can be powered down or clocked up independently of the CPU. Graphics turbo is available on both desktop and mobile parts, and you get more graphics turbo on Sandy Bridge.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/sharedL3.jpg

The GPU is treated like an equal citizen in the Sandy Bridge world, it gets equal access to the L3 cache. The graphics driver controls what gets into the L3 cache and you can even limit how much cache the GPU is able to use. Storing graphics data in the cache is particularly important as it saves trips to main memory which are costly from both a performance and power standpoint. Redesigning a GPU to make use of a cache isn’t a simple task.

SNB graphics (internally referred to as Gen 6 graphics) makes extensive use of fixed function hardware. The design mentality was anything that could be described by a fixed function should be implemented in fixed function hardware. The benefit is performance/power/die area efficiency, at the expense of flexibility.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/EUimprovement.jpg

The programmable shader hardware is composed of shaders/cores/execution units that Intel calls EUs. Each EU can dual issue picking instructions from multiple threads. The internal ISA maps one-to-one with most DirectX 10 API instructions resulting in a very CISC-like architecture. Moving to one-to-one API to instruction mapping increases IPC by effectively increasing the width of the EUs.

There are other improvements within the EU. Transcendental math is handled by hardware in the EU and its performance has been sped up considerably. Intel told us that sine and cosine operations are several orders of magnitude faster now than they were in pre-Westmere graphics.

In previous Intel graphics architectures, the register file was repartitioned on the fly. If a thread needed fewer registers, the remaining registers could be allocated to another thread. While this was a great approach for saving die area, it proved to be a limiter for performance. In many cases threads couldn’t be worked on as there were no registers available for use. Intel moved from 64 to 80 registers per thread and finally to 120 for Sandy Bridge. The register count limiting thread count scenarios were alleviated.

At the time, all of these enhancements resulted in 2x the instruction throughput per EU.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/SC2.jpg
Sandy Bridge vs. NVIDIA GeForce 310M Playing Starcraft 2

At launch there were two versions of Sandy Bridge graphics: one with 6 EUs and one with 12 EUs. All mobile parts (at launch) will use 12 EUs, while desktop SKUs may either use 6 or 12 depending on the model. Sandy Bridge was a step in the right direction for Intel, where integrated graphics were starting to become a requirement in anything consumer related, and Intel would slowly start to push the percentage of die area dedicated to GPU. Modern day equivalent desktop processors (2019) have 24 EUs (Gen 9.5), while future 10nm CPUs will have ~64 EUs (Gen11).

Sandy Bridge Media Engine

Sitting alongside the GPU is Sandy Bridge’s Media processor. Media processing in SNB is composed of two major components: video decode, and video encode.

The hardware accelerated decode engine is improved from the current generation: the entire video pipeline is now decoded via fixed function units. This is contrast to Intel’s pre-SNB design that uses the EU array for some video decode stages. As a result, Intel claims that SNB processor power is cut in half for HD video playback.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/decoder.jpg

The video encode engine was a brand new addition to Sandy Bridge. Intel took a ~3 minute 1080p 30Mbps source video and transcoded it to a 640 x 360 iPhone video format. The total process took 14 seconds and completed at a rate of roughly 400 frames per second.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/encoder.jpg

The fixed function encode/decode mentality is now pervasive in any graphics hardware for desktops and even smartphones. At the time, Sandy Bridge was using 3mm2 of the die for this basic encode/decode structure.

New, More Aggressive Turbo

Lynnfield was the first Intel CPU to aggressively pursue the idea of dynamically increasing the core clock of active CPU cores while powering down idle cores. The idea is that if you have a 95W TDP for a quad-core CPU, but three of those four cores are idle, then you can increase the clock speed of the one active core until you hit a turbo limit.

In all current generation processors the assumption is that the CPU reaches a turbo power limit immediately upon enabling turbo. In reality however, the CPU doesn’t heat up immediately - there’s a period of time where the CPU isn’t dissipating its full power consumption - there’s a ramp.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/nextgenturbo.jpg

Sandy Bridge takes advantage of this by allowing the PCU to turbo up active cores above TDP for short periods of time (up to 25 seconds). The PCU keeps track of available thermal budget while idle and spends it when CPU demand goes up. The longer the CPU remains idle, the more potential it has to ramp up above TDP later on. When a workload comes around, the CPU can turbo above its TDP and step down as the processor heats up, eventually settling down at its TDP. While SNB can turbo up beyond its TDP, the PCU won’t allow the chip to exceed any reliability limits.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/corengpupower.jpg

Both CPU and GPU turbo can work in tandem. Workloads that are more GPU bound running on SNB can result in the CPU cores clocking down and the GPU clocking up, while CPU bound tasks can drop the GPU frequency and increase CPU frequency. Sandy Bridge as a whole was a much more dynamic of a beast than anything that’s come before it.

Sandy Bridge: Inside the Core Microarchitecture Test Bed and Setup
Comments Locked

213 Comments

View All Comments

  • Ironchef3500 - Friday, May 10, 2019 - link

    Still running one of these...
  • warreo - Friday, May 10, 2019 - link

    same here, it's still running great
  • Netmsm - Friday, May 10, 2019 - link

    No! It dose not run great, this is 9700k that runs very disappointing.
  • flyingpants265 - Saturday, May 11, 2019 - link

    Hah, I get your point. But as of this moment, 9700k is one of the best desktop CPUs out there.
  • Netmsm - Saturday, May 11, 2019 - link

    :)
    It'd be better to say 9700k is one of the best Intel's desktop blah, blah, blah.
  • jgraham11 - Monday, May 13, 2019 - link

    9700k can pump out the most frames per second but it is not the best by any means, its utilization it typically more than %80. Just like a few years ago when all those quad cores were doing so great compared to AMDs more cores and more thread approach. Now those quad cores that put out all those frames are struggling to keep up in modern titles, those AMD processors are still putting out descent frame rates! Another example of AMD's fine wine technology.

    With that said, is the frames per second really a good metric to determine longevity of a processor?? Or should be looking at CPU utilization as well.
  • lmcd - Thursday, January 21, 2021 - link

    This article is old but "fine wine" about AMD's old processors is pure delusion. 2600k-age AMD looks horrible. Bulldozer was always horrible, and Piledriver has looked worse with age. Even Excavator gets absolutely smoked by most old Intel CPUs. While obviously not identical and much higher power, an Intel 3960X still went even with nearly every Ryzen 1 CPU. Fine wine my ass.
  • yankeeDDL - Sunday, May 12, 2019 - link

    Actually, this is a pretty fair summary. The 9700K, 9 years later, offers about 40% advantage over the 2600 (except in gaming, where more cores don't matter, today), which is quite abysmal.
  • Vayra - Monday, May 13, 2019 - link

    More cores don't matter? What results have you been looking at for gaming? 4K ultra?
  • yankeeDDL - Monday, May 13, 2019 - link

    Obviously, I was referring at the article. "More cores" meant going from 4 of the 2600 to 8 of the 9700. And no, they don't matter, unless you see a benefit of running at 300fps instead of 250fps. At high res, when the fps start coming close to 60fps, the 2600 and the 9700k are basically equivalent.
    A different story would be going from 2 to 4, but this would have nothing to do with the article...
    Is it clear now?

Log in

Don't have an account? Sign up now