AMD Zen Microarchiture Part 2: Extracting Instruction-Level Parallelism
by Ian Cutress on August 23, 2016 8:45 PM EST- Posted in
- CPUs
- AMD
- x86
- Zen
- Microarchitecture
Fetch
For Zen, AMD has implemented a decoupled branch predictor. This allows support to speculate on incoming instruction pointers to fill a queue, as well as look for direct and indirect targets. The branch target buffer (BTB) for Zen is described as ‘large’ but with no numbers as of yet, however there is an L1/L2 hierarchical arrangement for the BTB. For comparison, Bulldozer afforded a 512-entry, 4-way L1 BTB with a single cycle latency, and a 5120 entry, 5-way L2 BTB with additional latency; AMD doesn’t state that Zen is larger, just that it is large and supports dual branches. The 32 entry return stack for indirect targets is also devoid of entry numbers at this point as well.
The decoupled branch predictor also allows it to run ahead of instruction fetches and fill the queues based on the internal algorithms. Going too far into a specific branch that fails will obviously incur a power penalty, but successes will help with latency and memory parallelism.
The Translation Lookaside Buffer (TLB) in the branch prediction looks for recent virtual memory translations of physical addresses to reduce load latency, and operates in three levels: L0 with 8 entries of any page size, L1 with 64 entries of any page size, and L2 with 512 entries and support for 4K and 256K pages only. The L2 won’t support 1G pages as the L1 can already support 64 of them, and implementing 1G support at the L2 level is a more complex addition (there may also be power/die area benefits).
When the instruction comes through as a recently used one, it acquires a micro-tag and is set via the op-cache, otherwise it is placed into the instruction cache for decode. The L1-Instruction Cache can also accept 32 Bytes/cycle from the L2 cache as other instructions are placed through the load/store unit for another cycle around for execution.
Decode
The instruction cache will then send the data through the decoder, which can decode four instructions per cycle. As mentioned previously, the decoder can fuse operations together in a fast-path, such that a single micro-op will go through to the micro-op queue but still represent two instructions, but these will be split when hitting the schedulers. The purpose of this allows the system to fit more into the micro-op queue and afford a higher throughput when possible.
The new Stack Engine comes into play between the queue and the dispatch, allowing for a low-power address generation when it is already known from previous cycles. This allows the system to save power from going through the AGU and cycling back around to the caches.
Finally, the dispatch can apply six instructions per cycle, at a maximum rate of 6/cycle to the INT scheduler or 4/cycle to the FP scheduler. We confirmed with AMD that the dispatch unit can simultaneously dispatch to both INT and FP inside the same cycle, which can maximize throughput (the alternative would be to alternate each cycle, which reduces efficiency). We are told that the operations used in Zen for the uOp cache are ‘pretty dense’, and equivalent to x86 operations in most cases.
Facebook
Twitter
RSS
106 Comments
View All Comments
tipoo - Wednesday, August 31, 2016 - link
Bulldozers engineering samples were 2.5GHz and that shipped stupid high clocked. Zen ESs being 3GHz doesn't worry me.Cooe - Thursday, May 6, 2021 - link
Holy CRAP did history ever make you look like an absolute freaking idiot! xDextide - Monday, August 29, 2016 - link
Well, they have already shown an 8-core Zen running at full load at 3Ghz with their regular OEM heatsink/fans, and those are rated at 125W TDP max, so we do already know that's possible.defter - Wednesday, August 24, 2016 - link
It's 40% IPC improvement, not 40% overall improvement. If you improve IPC by 40% and achieve 85% of the clock speed, the total improvement will be only 20%.Since AMD hasn't talked about clock speed we can assume that it will be lower than Bulldozer.
euskalzabe - Wednesday, August 24, 2016 - link
Let me fix that for you: "Since AMD hasn't talked about clock speed we can assume..." absolutely nothing and can only wait until the final product is released.retrospooty - Wednesday, August 24, 2016 - link
Actually he is right and probably understating it. If AMD says it qill have 40% IPC improvement, it is probably not true, or true only in a few select benchmarks. If AMD left out the clockspeed it is almost definitely going to lower. AMD has zero credibility with pre-release performance claims. Nothing AMD says can be takes at its word until retail units (not engineering samples) are independently tested.Azix - Wednesday, August 24, 2016 - link
why the flying fork would the clock speed be lower? I hope you dont mean lower than they have shown, that would make no sense.Bulldozer engineering samples were maybe 2.5Ghz or 3Ghz. Additionally, talking about actual clock speeds would be to give away sku information. How they plan to structure the product line etc.
Outlander_04 - Thursday, August 25, 2016 - link
Both intel Broadwell-e and Zen were at 3 Ghz for the comparison .Broadwell-e maxes out at 3.6 Ghz , but most models are at 3.2 Ghz .
Dont let your prejudices cause you to jump to conclusions.
Zen could easily be released running at higher clock rates
silverblue - Wednesday, August 24, 2016 - link
Imagine for a second that Zen was clocked like the FX-8320E, that is a 3.2GHz base with 4.0GHz boost. Would a 40 to 50% average IPC boost make Zen competitive?For all we know, Zen could be conservatively clocked, paving the way for Zen+ with moderate tweaks and increased clocks; a bit like Piledriver vs. Bulldozer, as opposed to Phenom II vs. Phenom.
looncraz - Wednesday, August 24, 2016 - link
Zen will clock very close to 4Ghz out of the box - AMD kept most of the speed-demon elements of Bulldozer, such as the long pipelines. They also used dedicated, simple, schedulers - which is where frequency limits are frequently found... and they also put the L3 cache on a different clock bus, meaning it might operate at a different frequency from the cores... again.The engineering samples are always clocked low, so if they are running at 3Ghz for a demo, then they will be able to achieve at least 3.4~3.6Ghz, with 4Ghz boost clocks on eight-core CPUs. Quad core units will obviously go higher, still. That is why half the cores still has 70% of the power draw - it's operating higher up the frequency curve. 3.8Ghz base, 4.2Ghz boost for the top quad core SKU seems very likely given what is known.