| Latest revision |
Your text |
| Line 6: |
Line 6: |
| | |manufacturer=Intel | | |manufacturer=Intel |
| | |introduction=2019 | | |introduction=2019 |
| − | |phase-out=2021
| |
| | |process=10 nm | | |process=10 nm |
| | |cores=2 | | |cores=2 |
| | |cores 2=4 | | |cores 2=4 |
| − | |cores 3=8
| |
| − | |cores 4=10
| |
| − | |cores 5=12
| |
| − | |cores 6=16
| |
| − | |cores 7=18
| |
| − | |cores 8=20
| |
| − | |cores 9=24
| |
| − | |cores 10=26
| |
| − | |cores 11=28
| |
| − | |cores 12=32
| |
| − | |cores 13=36
| |
| − | |cores 14=38
| |
| − | |cores 15=40
| |
| | |type=Superscalar | | |type=Superscalar |
| | |oooe=Yes | | |oooe=Yes |
| Line 73: |
Line 59: |
| | |l3 per=core | | |l3 per=core |
| | |l3 desc=16-way set associative | | |l3 desc=16-way set associative |
| − | |core name=Spring Hill
| |
| − | |core name 2=Lakefield
| |
| − | |core name 3=Ice Lake (Client)
| |
| − | |core name 4=Ice Lake (Server)
| |
| | |predecessor=Palm Cove | | |predecessor=Palm Cove |
| | |predecessor link=intel/microarchitectures/palm cove | | |predecessor link=intel/microarchitectures/palm cove |
| Line 82: |
Line 64: |
| | |successor link=intel/microarchitectures/willow cove | | |successor link=intel/microarchitectures/willow cove |
| | }} | | }} |
| − | '''Sunny Cove''' ('''SNC'''), the successor to {{\\|Palm Cove}}, is a high-performance [[10 nm]] [[x86]]-64 core microarchitecture designed by [[Intel]] for an array of server and client products, including {{\\|Ice Lake (Client)}}, {{\\|Ice Lake (Server)}}, {{\\|Lakefield}}, and the Nervana {{nervana|NNP-I}}. The microarchitecture was developed by Intel's R&D Center (IDC) in Haifa, Israel. | + | '''Sunny Cove''' ('''SNC''') is the successor to {{\\|Palm Cove}}, a high-performance [[10 nm]] [[x86]] core microarchitecture designed by [[Intel]] for an array of server and client products, including {{\\|Ice Lake (Client)}}, {{\\|Ice Lake (Server)}}, {{\\|Lakefield}}, and the Nervana {{nervana|NNP-I}}. The microarchitecture was developed by Intel's R&D Center (IDC) in Haifa, Israel. |
| | | | |
| | == History == | | == History == |
| − | [[File:sunny cove roadmap.png|thumb|right|200px|Intel Core roadmap]] | + | [[File:sunny cove roadmap.png|thumb|right|400px|Intel Core roadmap]] |
| − | Sunny Cove was originally unveiled by Intel at their 2018 architecture day. Intel originally intended for Sunny Cove to succeed {{\\|Palm Cove}} in late 2017 which was intended to be the first [[10 nm]]-based core and the proper successor to {{\\|Skylake (client)|Skylake}}. Prolonged delays and problems with their [[10 nm process]] resulted in a number of improvised derivatives of {{\\|Skylake (client)|Skylake}} including {{\\|Kaby Lake}}, {{\\|Coffee Lake}}, and {{\\|Comet Lake}}. For all practical purposes, {{\\|Palm Cove}} has been skipped and Intel has gone directly to Sunny Cove. Sunny Cove debuted in mid-2019. | + | Sunny Cove was originally unveiled by Intel at their 2018 architecture day. Intel originally intended for Sunny Cove to succeed {{\\|Palm Cove}} in late 2017 which was it was intended to be the first [[10 nm]]-based core and the proper successor to {{\\|Skylake (client)|Skylake}}. Prolong delays and problems with their [[10 nm process]] and resulted in a number of improvised derivatives of {{\\|Skylake (client)|Skylake}} including {{\\|Kaby Lake}}, {{\\|Coffee Lake}}, and {{\\|Comet Lake}}. For all practical purposes, {{\\|Palm Cove}} has been skipped and Intel has gone directly to Sunny Cove. Sunny Cove debuted in mid-2019. |
| | | | |
| | :[[File:14nm improv 10 delays.svg|500px]] | | :[[File:14nm improv 10 delays.svg|500px]] |
| | | | |
| | == Process Technology == | | == Process Technology == |
| − | Sunny Cove is designed to take advantage of [[intel 10nm|Intel's 10 nm process]]. | + | Sunny Cove is designed to take advantage of Intel's [[10 nm+ process]]. |
| − | | |
| − | == Implementations ==
| |
| − | The Sunny Cove core is integrated into a number of Intel designs.
| |
| − | | |
| − | {| class="wikitable" style="text-align: center;"
| |
| − | | colspan="3" | Chips with Intel Sunny Cove
| |
| − | |-
| |
| − | | Chip || Instances || Notes
| |
| − | |-
| |
| − | | {{\\|Lakefield}} || 1 || Heterogeneous [[pentacore]]
| |
| − | |-
| |
| − | | {{\\|Spring Hill}} || 2 || Used for {{nervana|NNP-I}} [[NPU]]s
| |
| − | |-
| |
| − | | {{\\|Ice Lake (Client)}} || 2-4 || Mobile/Desktop processors
| |
| − | |-
| |
| − | | {{\\|Ice Lake (Server)}} || 40 || Workstation/Server processors
| |
| − | |}
| |
| | | | |
| | == Architecture == | | == Architecture == |
| | === Key changes from {{\\|Palm Cove}}/{{\\|Skylake}}=== | | === Key changes from {{\\|Palm Cove}}/{{\\|Skylake}}=== |
| | [[File:skylake - sunny cove changes block.jpg|thumb|right|Skylake to Sunny Cove changes]][[File:sunny cove enhancements.jpg|thumb|right|Sunny Cove enhancements]][[File:sunny cove buffer capacities.png|thumb|right|Sunny Cove buffers]] | | [[File:skylake - sunny cove changes block.jpg|thumb|right|Skylake to Sunny Cove changes]][[File:sunny cove enhancements.jpg|thumb|right|Sunny Cove enhancements]][[File:sunny cove buffer capacities.png|thumb|right|Sunny Cove buffers]] |
| − | * Performance | + | * Significant [[IPC]] uplift ([[Intel]] self-reported average 18% IPC accross proxy benchmarks such as [[SPEC CPU2006]]/[[SPEC CPU2017]]) |
| − | ** [[IPC]] uplift ([[Intel]] self-reported average 18-20% IPC across proxy benchmarks such as [[SPEC CPU2006]]/[[SPEC CPU2017]])
| |
| − | | |
| | * Front-end | | * Front-end |
| − | ** 1.5x larger µOP cache (2.3K entries, up from 1536) | + | ** 1.5x larger µOP cache (2.25k entries, up from 1536) |
| − | ** Smarter [[prefetchers]]
| |
| − | ** Improved [[branch predictor]]
| |
| − | ** ITLB
| |
| − | *** 2x 2M page entries (16 entries, up from 8)
| |
| − | ** Larger IDQ (70 µOPs, up from 64)
| |
| − | ** LSD can detect up to 70 µOP loops (up from 64)
| |
| | * Back-end | | * Back-end |
| − | ** Wider allocation (6-way, up from 5-way in skylake and 4-way in broadwell) | + | ** Wider allocation (5-way, up from 4-way) |
| − | ** Delivery Throughout remain 6 uops, same as Skylake.
| |
| − | ** Wider decoding width with an additional simple decoder is added (from 3 simple + 1 complex in skylake’s 4 way wide decoder to 4 simple + 1 complex in Sunny cove 5 way wide decoder)
| |
| | ** 1.6x larger ROB (352, up from 224 entries) | | ** 1.6x larger ROB (352, up from 224 entries) |
| | ** Scheduler | | ** Scheduler |
| − | *** 1.65x larger scheduler (160-entry, up from 97 entries) | + | *** Larger scheduler (?, up from 97 entries) |
| | *** Larger dispatch (10-way, up from 8-way) | | *** Larger dispatch (10-way, up from 8-way) |
| − | ** 1.55x larger integer register file (280-entry, up from 180) | + | *** Execution ports rebalanced |
| − | ** 1.33x larger vector register file (224-entry, up from 168) | + | *** New store data port |
| − | ** Distributed scheduling queues (4 scheduling queues, up from 2)
| + | *** New store AGU port |
| − | *** New dedicated queue for store data | |
| − | *** Replaced 2 generic AGUs with two load AGUs
| |
| − | *** Load/Store pair have dedicated queues
| |
| − | **** New paired store capabilities
| |
| − | * Execution Engine
| |
| − | ** Execution ports rebalanced
| |
| − | ** 2x store data ports (up from 1)
| |
| − | ** 2x store address AGU (up from 1)
| |
| | * Memory subsystem | | * Memory subsystem |
| − | ** Data Cache
| |
| − | *** DTLB now split for load and stores
| |
| − | *** Store
| |
| − | **** DTLB 4 KiB TLB competitively shared (from fixed partitioning)
| |
| − | **** DTLB 2 MiB / 4 MiB TLB competitively shared (from fixed partitioning)
| |
| − | **** 2x larger DTLB 1 GiB page entries (8-entry, up from 4)
| |
| − | *** Load
| |
| − | **** New DTLB store
| |
| − | **** 16-entry, all page sizes
| |
| − | ** STLB
| |
| − | *** Single unified TLB for all pages (from 4 KiB+2/4 MiB and seperate 1 GiB)
| |
| − | *** STLB uses dynamic partitioning (from partition fixed partitioning)
| |
| | ** LSU | | ** LSU |
| | *** 1.8x more inflight loads (128, up from 72 entries) | | *** 1.8x more inflight loads (128, up from 72 entries) |
| | *** 1.3x more inflight stores (72, up from 56 entries) | | *** 1.3x more inflight stores (72, up from 56 entries) |
| − | ** 1.5x larger L1 data cache (48 KiB, up from 32 KiB) | + | ** Larger L1 data cache (48 KiB, up from 32 KiB) |
| − | ** 2x larger L2 cache (512 KiB, up from 256 KiB) | + | ** Larger L2 cache (512 KiB, up from 256 KiB) |
| | *** Larger STLBs | | *** Larger STLBs |
| − | **** 1.33x larger 4k table (2048 entries, up from 1536) | + | **** Larger 1G table (1024-entry, up from 16) |
| | + | **** Larger 4k table (2048 entries, up from 1536) |
| | + | **** New 1,024-entry 2M/4M table |
| | ** 5-Level Paging | | ** 5-Level Paging |
| | *** Large virtual address (57 bits, up from 48 bits) | | *** Large virtual address (57 bits, up from 48 bits) |
| Line 195: |
Line 132: |
| | | | |
| | === Block diagram === | | === Block diagram === |
| − | :[[File: Sunny_cove_block_diagram.png|950px]] | + | :[[File:sunny cove block diagram.svg|950px]] |
| − | | |
| − | === Memory Hierarchy ===
| |
| − | * Cache
| |
| − | ** L0 µOP cache:
| |
| − | *** 2,304 µOPs, 8-way set associative
| |
| − | **** 48 sets, 6-µOP line size
| |
| − | **** statically divided between threads, per core, inclusive with L1I
| |
| − | ** L1I Cache:
| |
| − | *** 32 [[KiB]], 8-way set associative
| |
| − | **** 64 sets, 64 B line size
| |
| − | **** shared by the two threads, per core
| |
| − | ** L1D Cache:
| |
| − | *** 48 KiB, 12-way set associative
| |
| − | *** 64 sets, 64 B line size
| |
| − | *** shared by the two threads, per core
| |
| − | *** 4 cycles for fastest load-to-use (simple pointer accesses)
| |
| − | **** 5 cycles for complex addresses
| |
| − | *** bandwidth
| |
| − | **** 2x 64 B/cycle load + 1x64 B/cycle store
| |
| − | **** OR 2x32 B/cycle store
| |
| − | *** Write-back policy
| |
| − | ** L2 Cache:
| |
| − | *** Client
| |
| − | **** Unified, 512 KiB, 8-way set associative
| |
| − | **** 1024 sets, 64 B line size
| |
| − | *** Server
| |
| − | **** Unified, 1,280 KiB, 20-way set associative
| |
| − | **** 1024 sets, 64 B line size
| |
| − | *** Non-inclusive
| |
| − | *** 13 cycles for fastest load-to-use
| |
| − | *** 64 B/cycle bandwidth to L1$
| |
| − | *** Write-back policy
| |
| − | | |
| − | Sunny Cove TLB consists of a dedicated L1 TLB for instruction cache (ITLB) and another one for data cache (DTLB). Additionally, there is a unified L2 TLB (STLB).
| |
| − | * TLBs:
| |
| − | ** ITLB
| |
| − | *** 4 KiB page translations:
| |
| − | **** 128 entries; 8-way set associative
| |
| − | **** dynamic partitioning
| |
| − | *** 2 MiB / 4 MiB page translations:
| |
| − | **** 16 entries per thread; fully associative
| |
| − | **** Duplicated for each thread
| |
| − | ** DTLB
| |
| − | *** Load
| |
| − | **** 4 KiB page translations:
| |
| − | ***** 64 entries; 4-way set associative
| |
| − | ***** competitively shared
| |
| − | **** 2 MiB / 4 MiB page translations:
| |
| − | ***** 32 entries; 4-way set associative
| |
| − | ***** competitively shared
| |
| − | **** 1G page translations:
| |
| − | ***** 8 entries; 8-way set associative
| |
| − | ***** competitively partition
| |
| − | *** Store
| |
| − | **** All pages:
| |
| − | ***** 16 entries; 16-way set associative
| |
| − | ***** competitively partition
| |
| − | ** STLB
| |
| − | *** All pages:
| |
| − | **** 2,048 entire; 16-way set associative
| |
| − | **** Parititoning:
| |
| − | ***** 4 KiB pages can use all 2,048 entries
| |
| − | ***** 2/4 MiB pages can use 1,024 entries (8-way sets), shared with 4 KiB
| |
| − | ***** 1 GiB pages can use 1,024 entries (8-way sets), shared with 4 KiB pages
| |
| | | | |
| | == Overview == | | == Overview == |
| − | Sunny Cove is Intel's microarchitecture for their [[big core|big CPU core]] which is incorporated into a number of client and server chips that succeed {{\\|Palm Cove}} (and effectively the {{\\|Skylake (client)|Skylake}} series of derivatives). Sunny Cove is a [[big core]] implemented which is incorporated into numerous chips made by Intel including {{\\|Lakefield}}, {{\\|Ice Lake (Client)}}, and {{\\|Ice Lake (Server)}}, as well as the [[Nervana]] {{nervana|NNP}} accelerator. Sunny Cove introduces a large set of enhancements that improves the performance of legacy code and new code through the extraction of parallelism as well as new features. Those include a deep [[out-of-window]] pipeline, a wider execution back-end, higher load-store bandwidth, lower effective access latencies, and bigger caches. | + | Sunny Cove is Intel's microarchitecture for the CPU core which is incorporated into a number of client and server chips that succeed {{\\|Palm Cove}} (and effectively the {{\\|Skylake (client)|Skylake}} series of derivatives). Sunny Cove is just the core which is implemented in a numerous chips made by Intel including {{\\|Lakefield}}, {{\\|Ice Lake (Client)}}, {{\\|Ice Lake (Server)}}, and the [[Nervana]] {{nervana|NNP}} accelerator. Sunny Cove introduces a large set of enhancements that significantly improves the performance of legacy code and new code through the extraction of parallelism as well as new features. Those include a significantly deep [[out-of-window]] pipeline, a wider execution back-end, higher load-store bandwidth, lower effective access latencies, and bigger caches. |
| | | | |
| | == Pipeline == | | == Pipeline == |
| Line 281: |
Line 154: |
| | {{clear}} | | {{clear}} |
| | | | |
| − | ==== Front-end ====
| + | === Front-end === |
| − | The front-end is tasked with the challenge of fetching the complex [[x86]] instructions from memory, decoding them, and delivering them to the execution units. In other words, the front end needs to be able to consistently deliver enough [[µOPs]] from the instruction code stream to keep the back-end busy. When the back-end is not being fully utilized, the core is not reaching its full performance. A poorly or under-performing front-end will translate directly to a poorly performing core. This challenge is further complicated by various redirection such as branches and the complex nature of the [[x86]] instructions themselves.
| + | {{empty section}} |
| − | | |
| − | ===== Fetch & pre-decoding =====
| |
| − | On their first pass, instructions should have already been prefetched from the [[L2 cache]] and into the [[L1 cache]]. The L1 is a 32 [[KiB]], 8-way set associative cache, identical in size and organization to {{intel|microarchitectures|previous generations}}. Sunny Cove fetching is done on a 16-byte fetch window. A window size that has not changed in a number of generations. Up to 16 bytes of code can be fetched each cycle. Note that the fetcher is shared evenly between the two threads so that each thread gets every other cycle. At this point they are still [[macro-ops]] (i.e. variable-length [[x86]] architectural instruction). Instructions are brought into the pre-decode buffer for initial preparation.
| |
| − | | |
| − | [[File:sunny cove fetch.svg|left|300px]]
| |
| − | | |
| − | [[x86]] instructions are complex, variable length, have inconsistent encoding, and may contain multiple operations. At the pre-decode buffer, the instructions boundaries get detected and marked. This is a fairly difficult task because each instruction can vary from a single byte all the way up to fifteen. Moreover, determining the length requires inspecting a couple of bytes of the instruction. In addition to boundary marking, prefixes are also decoded and checked for various properties such as branches. As with previous microarchitectures, the pre-decoder has a [[throughput]] of 6 [[macro-ops]] per cycle or until all 16 bytes are consumed, whichever happens first. Note that the predecoder will not load a new 16-byte block until the previous block has been fully exhausted. For example, suppose a new chunk was loaded, resulting in 7 instructions. In the first cycle, 6 instructions will be processed and a whole second cycle will be wasted for that last instruction. This will produce the much lower throughput of 3.5 instructions per cycle which is considerably less than optimal. Likewise, if the 16-byte block resulted in just 4 instructions with 1 byte of the 5th instruction received, the first 4 instructions will be processed in the first cycle and a second cycle will be required for the last instruction. This will produce an average throughput of 2.5 instructions per cycle. Note that there is a special case for {{x86|length-changing prefix}} (LCPs) which will incur additional pre-decoding costs. Real code is often less than 4 bytes which usually results in a good rate.
| |
| − | | |
| − | All of this works along with the branch prediction unit which attempts to guess the flow of instructions. In Sunny Cove, the [[branch predictor]] has also been improved. The intimate improvements done in the branch predictor were not further disclosed by Intel.
| |
| − | ====== Instruction Queue & MOP-Fusion ======
| |
| − | {| style="border: 1px solid gray; float: right; margin: 10px; padding: 5px"
| |
| − | | [[MOP-Fusion]] Example:
| |
| − | |-
| |
| − | |
| |
| − | <pre>cmp eax, [mem]
| |
| − | jne loop</pre>
| |
| − | | '''→'''
| |
| − | | <pre>cmpjne eax, [mem], loop</pre>
| |
| − | |}
| |
| − | {{see also|macro-operation fusion|l1=Macro-Operation Fusion}}
| |
| − | The pre-decoded instructions are delivered to the Instruction Queue (IQ). In {{\\|Broadwell}}, the Instruction Queue has been increased to 25 entries duplicated over for each thread (i.e. 50 total entries). It's unclear if that has changed with Sunny Cove. One key optimization the instruction queue does is [[macro-op fusion]]. Sunny Cove can fuse two [[macro-ops]] into a single complex one in a number of cases. In cases where a {{x86|test}} or {{x86|compare}} instruction with a subsequent conditional jump is detected, it will be converted into a single compare-and-branch instruction. Those fused instructions remain fused throughout the entire pipeline and get executed as a single operation by the branch unit thereby saving bandwidth everywhere. Only one such fusion can be performed during each cycle.
| |
| − | | |
| − | ===== Decoding =====
| |
| − | [[File:sunny cove decode.svg|right|425px]]
| |
| − | Up to five (3 + 2 fused or up to 5 unfused) pre-decoded instructions are sent to the decoders each cycle. Like the fetchers, the Decoders alternate between the two thread each cycle. Decoders read in [[macro-operations]] and emit regular, fixed length [[µOPs]]. The five decoders are asymmetric; the first one, Decoder 0, is a [[complex decoder]] while the other four are [[simple decoders]]. A simple decoder is capable of translating instructions that emit a single fused-[[µOP]]. By contrast, a [[complex decoder]] can decode anywhere from one to four fused-µOPs. Overall up to 5 simple instructions can be decoded each cycle with lesser amounts if the complex decoder needs to emit addition µOPs; i.e., for each additional µOP the complex decoder needs to emit, 1 less simple decoder can operate. In other words, for each additional µOP the complex decoder emits, one less decoder is active.
| |
| − | | |
| − | ====== MSROM & Stack Engine ======
| |
| − | There are more complex instructions that are not trivial to be decoded even by complex decoder. For instructions that transform into more than four µOPs, the instruction detours through the [[microcode sequencer]] (MS) ROM. When that happens, up to 4 µOPs/cycle are emitted until the microcode sequencer is done. During that time, the decoders are disabled.
| |
| − | | |
| − | [[x86]] has dedicated [[stack machine]] operations. Instructions such as <code>{{x86|PUSH}}</code>, <code>{{x86|POP}}</code>, as well as <code>{{x86|CALL}}</code>, and <code>{{x86|RET}}</code> all operate on the [[stack pointer]] (<code>{{x86|ESP}}</code>). Without any specialized hardware, such operations would need to be sent to the back-end for execution using the general purpose ALUs, using up some of the bandwidth and utilizing scheduler and execution units resources. Since {{\\|Pentium M}}, Intel has been making use of a [[Stack Engine]]. The Stack Engine has a set of three dedicated adders it uses to perform and eliminate the stack-updating µOPs (i.e. capable of handling three additions per cycle). Instruction such as <code>{{x86|PUSH}}</code> are translated into a store and a subtraction of 4 from <code>{{x86|ESP}}</code>. The subtraction in this case will be done by the Stack Engine. The Stack Engine sits after the [[instruction decode|decoders]] and monitors the µOPs stream as it passes by. Incoming stack-modifying operations are caught by the Stack Engine. This operation alleviate the burden of the pipeline from stack pointer-modifying µOPs. In other words, it's cheaper and faster to calculate stack pointer targets at the Stack Engine than it is to send those operations down the pipeline to be done by the execution units (i.e., general purpose ALUs).
| |
| − | | |
| − | ===== µOP cache =====
| |
| − | {{see also|intel/microarchitectures/sandy_bridge_(client)#New_.C2.B5OP_cache_.26_x86_tax|l1=Sandy Bridge § New µOP cache}}
| |
| − | [[File:sunny cove ucache.svg|right|400px]]
| |
| − | Decoding the variable-length, inconsistent, and complex [[x86]] instructions is a nontrivial task. It's also expensive in terms of performance and power. Therefore, the best way for the pipeline to avoid those things is to simply not decode the instructions. This is the job of the [[µOP cache]] or the Decoded Stream Buffer (DSB). Sunny Cove's µOP cache is organized similarly to all previous generations since its introduction in {{\\|Sandy Bridge}}, however, its size has increased. Sunny Cove increased the cache by 1.5x from 1.5K in {{\\|Skylake}} to over 2.3K. The cache is organized into 48 sets of 8 cache lines with each line holding up to 6 µOP for a total of 2,304 µOPs. As with {{\\|Skylake}}, the µOP cache operates on 64-byte fetch windows. The micro-operation cache is competitively shared between the two threads and can also hold pointers to the microcode. The µOP cache has an average hit rate of 80% or greater.
| |
| − | | |
| − | A hit in the µOP allows for up to 6 µOPs (i.e., entire line) per cycle to be sent directly to the Instruction Decode Queue (IDQ), bypassing all the pre-decoding and decoding that would otherwise have to be done. Whereas the legacy decode path works in 16-byte instruction fetch windows, the µOP cache has no such restriction and can deliver 6 µOPs/cycle corresponding to the much bigger 64-byte window. The higher bandwidth of µOPs greatly improves the numbers of µOP that the back-end can take advantage of in the [[out-of-order]] part of the machine. To better improve this area, Sunny cove increased the [[#Renaming & Allocation|rename and retire]] to 5 µOPs/cycle, one more than {{\\|Skylake}}, increasing the absolute ceiling rate of the out-of-order engine.
| |
| − | | |
| − | ===== Allocation Queue =====
| |
| − | The emitted µOPs from the decoders are sent directly to the Allocation Queue (AQ) or Instruction Decode Queue (IDQ). The Allocation Queue acts as the interface between the front-end ([[in-order]]) and the back-end ([[out-of-order]]). Like {{\\|Skylake}}, the IDQ is no longer competitively shared; it's partitioned between two active threads. Sunny Cove's Allocation Queue increased from 64-µOPs/thread to 70 for a total of 140 entries or roughly 10% more than {{\\|Skylake}}. The queue's purpose is effectively to help absorb [[bubbles]] which may be introduced in the front-end, ensuring that a steady stream of 6 µOPs are delivered each cycle.
| |
| | | | |
| − | ====== µOP-Fusion & LSD ======
| + | {{work-in-progress}} |
| − | The IDQ does a number of additional optimizations as it queues instructions. The Loop Stream Detector (LSD) is a mechanism inside the IDQ capable of detecting loops that fit in the IDQ and lock them down. That is, the LSD can stream the same sequence of µOPs directly from the IDQ continuously without any additional [[instruction fetch|fetching]], [[instruction decode|decoding]], or utilizing additional caches or resources. Streaming continues indefinitely until reaching a branch [[mis-prediction]]. Note that while the LSD is active, the rest of the front-end is effectively disabled.
| |
| | | | |
| − | The LSD in Sunny Cove can take advantage of the larger IDQ; capable of detecting loops up to 70 µOPs per thread. The LSD is particularly excellent in for many common algorithms that are found in many programs (e.g., tight loops, intensive calc loops, searches, etc..).
| + | === Back-end === |
| | + | {{empty section}} |
| | | | |
| − | ==== Execution engine ====
| + | {{work-in-progress}} |
| − | [[File:sunny cove rob.svg|right|450px]]
| |
| − | Sunny Cove's back-end or execution engine deals with the execution of [[out-of-order]] operations. Much of the design is inherited from previous architectures such as {{\\|Skylake}} but has been widened to explorer more [[instruction-level parallelism]] opportunities. From the allocation queue instructions are sent to the [[Reorder Buffer]] (ROB) at the rate of up to 6 fused-µOPs each cycle, similar to {{\\|Skylake}}'s.
| |
| − | | |
| − | ===== Renaming & Allocation =====
| |
| − | Like the front-end, the [[Reorder Buffer]] has been significantly enlarged by 60%, now having the capacity of 352 entries, 128 entries more than {{\\|Skylake}}. Since each ROB entry holds complete µOPs, in practice 352 entries might be equivalent to as much as 525 µOPs depending on the code being executed (e.g. fused load/stores). It is at this stage that [[architectural registers]] are mapped onto the underlying [[physical registers]]. Other additional bookkeeping tasks are also done at this point such as allocating resources for stores, loads, and determining all possible scheduler ports. Register renaming is also controlled by the [[Register Alias Table]] (RAT) which is used to mark where the data we depend on is coming from (after that value, too, came from an instruction that has previously been renamed). In {{intel|microarchitectures|previous microarchitectures}}, the RAT could handle 4 µOPs each cycle. In Sunny Cove this has been increased to five, A 25% increase in the OoO application capabilities. Sunny Cove can now rename any five registers per cycle. This includes the same register renamed five times in a single cycle. Note that the ROB still operates on fused µOPs, therefore 5 µOPs can effectively be as high as 10 µOPs.
| |
| − | | |
| − | It should be noted that there are no special costs involved in splitting up fused µOPs before execution or [[retirement]] and the two fused µOPs only occupy a single entry in the ROB.
| |
| − | | |
| − | Since Sunny Cove performs [[speculative execution]], it can speculate incorrectly. When this happens, the architectural state is invalidated and as such needs to be rolled back to the last known valid state. {{intel|microarchitectures|previous microarchitectures}} had a 48-entry [[Branch Order Buffer]] (BOB) that keeps tracks of those states for this very purpose. It's unknown if that has changed with Sunny Cove.
| |
| − | | |
| − | ===== Optimizations =====
| |
| − | Sunny Cove has a number of optimizations it performs prior to entering the out-of-order and renaming part. Three of those optimizations include [[Move Elimination]] and [[Zeroing Idioms]], and [[Ones Idioms]]. A Move Elimination is capable of eliminating register-to-register moves (including chained moves) prior to bookkeeping at the ROB, allowing those µOPs to save resources and eliminating them entirely. Eliminated moves are zero latency and are entirely removed from the pipeline. This optimization does not always succeed; when it fails, the operands were simply not ready. On average this optimization is almost always successful (upward of 85% in most cases). Move elimination works on all 32- and 64-bit GP integer registers as well as all 128- and 256-bit vector registers.
| |
| − | {| style="border: 1px solid gray; float: right; margin: 10px; padding: 5px; width: 350px;" | |
| − | | [[Zeroing Idiom]] Example:
| |
| − | |-
| |
| − | | <pre>xor eax, eax</pre>
| |
| − | |-
| |
| − | | Not only does this instruction get eliminated at the ROB, but it's actually encoded as just 2 bytes <code>31 C0</code> vs the 5 bytes for <code>{{x86|mov}} {{x86|eax}}, 0x0</code> which is encoded as <code>b8 00 00 00 00</code>.
| |
| − | |}
| |
| − | There are some exceptions that Sunny Cove will not optimize, most dealing with [[signedness]]. [[sign extension|sign-extended]] moves cannot be eliminated and neither can zero-extended from 16-bit to 32/64 big registers (note that 8-bit to 32/64 works). Likewise, in the other direction, no moves to 8/16-bit registers can be eliminated. A move of a register to itself is never eliminated.
| |
| − | | |
| − | When instructions use registers that are independent of their prior values, another optimization opportunity can be exploited. A second common optimization performed in Sunny Cove around the same time is [[Zeroing Idioms]] elimination. A number common zeroing idioms are recognized and consequently eliminated in much the same way as the move eliminations are performed. Sunny Cove recognizes instructions such as <code>{{x86|XOR}}</code>, <code>{{x86|PXOR}}</code>, and <code>{{x86|XORPS}}</code> as zeroing idioms when the [[source operand|source]] and [[destination operand|destination]] operands are the same. Those optimizations are done at the same rate as renaming during renaming (at 4 µOPs per cycle) and the register is simply set to zero.
| |
| − | | |
| − | The [[ones idioms]] is another dependency breaking idiom that can be optimized. In all the various {{x86|PCMPEQ|PCMPEQx}} instructions that perform packed comparison the same register with itself always set all bits to one. On those cases, while the µOP still has to be executed, the instructions may be scheduled as soon as possible because the current state of the register need not be known.
| |
| − | | |
| − | ===== Scheduler =====
| |
| − | [[File:sunny cove scheduler.svg|right|500px]]
| |
| − | The scheduler size itself has likely increased with Sunny cove, although its exact capacity was not disclosed. Intel increased the schedule by 50% from 64 to 97 entries in {{\\|Skylake}}, therefore it's reasonable to expect Sunny Cove to be greater than 125 entries. Those entries are competitively shared between the two threads. Sunny Cove continues with a unified design; this is in contrast to designs such as [[AMD]]'s {{amd|Zen|l=arch}} which uses a split design each one holding different types of µOPs. Scheduler includes the two register files for integers and vectors. It's in those [[register files]] that output operand data is stored. In Skylake, the [[integer]] [[register file]] was 180-entry deep. It's unknown if that has changed and by how much on Sunny Cove.
| |
| − | | |
| − | At this point µOPs are no longer fused and will be dispatched to the execution units independently. The scheduler holds the µOPs while they wait to be executed. A µOP could be waiting on an operand that has not arrived (e.g., fetched from memory or currently being calculated from another µOPs) or because the execution unit it needs is busy. Once the µOP is ready, it is dispatched through its designated port. The scheduler will send the oldest ready µOP to be executed on each of the eight ports each cycle.
| |
| − | | |
| − | The scheduler on Sunny Cove enlarged further with two additional ports that deal with memory operations, making it 25% wider than {{\\|Skylake}}. Up to 10 operations may be dispatched each cycle. On the arithmetic side of the execution engine, the four workhorse ports were augmented with more functionality. On the vector side, Sunny Cove retains the three FMAs and ALUs. One of the key changes here is the addition of a new shuffle unit on Port 1 for moving data within a register.
| |
| − | | |
| − | ====== Scheduler Ports & Execution Units ======
| |
| − | <table class="wikitable">
| |
| − | <tr><th colspan="2">Scheduler Ports Designation</th></tr>
| |
| − | <tr><th rowspan="5">Port 0</th><td>Integer/Vector Arithmetic, Multiplication, Logic, Shift, and String ops</td></tr>
| |
| − | <tr><td>[[FP]] Add, [[Multiply]], [[FMA]]</td></tr>
| |
| − | <tr><td>Integer/FP Division and [[Square Root]]</td></tr>
| |
| − | <tr><td>[[AES]] Encryption</td></tr>
| |
| − | <tr><td>Branch2</td></tr>
| |
| − | <tr><th rowspan="2">Port 1</th><td>Integer/Vector Arithmetic, Multiplication, Logic, Shift, and Bit Scanning</td></tr>
| |
| − | <tr><td>[[FP]] Add, [[Multiply]], [[FMA]]</td></tr>
| |
| − | <tr><th rowspan="3">Port 5</th><td>Integer/Vector Arithmetic, Logic</td></tr>
| |
| − | <tr><td>Vector Permute</td></tr>
| |
| − | <tr><td>[[x87]] FP Add, Composite Int, CLMUL</td></tr>
| |
| − | <tr><th rowspan="2">Port 6</th><td>Integer Arithmetic, Logic, Shift</td></tr>
| |
| − | <tr><td>Branch</td></tr>
| |
| − | <tr><th>Port 2</th><td>Load AGU</td></tr>
| |
| − | <tr><th>Port 3</th><td>Load AGU</td></tr>
| |
| − | <tr><th>Port 4</th><td>Store Data</td></tr>
| |
| − | <tr><th>Port 7</th><td>Store AGU</td></tr>
| |
| − | <tr><th>Port 8</th><td>Store AGU</td></tr>
| |
| − | <tr><th>Port 9</th><td>Store Data</td></tr>
| |
| − | </table>
| |
| − | | |
| − | {| class="wikitable collapsible collapsed"
| |
| − | |-
| |
| − | ! colspan="3" | Execution Units
| |
| − | |-
| |
| − | ! Execution Unit !! # of Units !! Instructions
| |
| − | |-
| |
| − | | ALU || 4 || add, and, cmp, or, test, xor, movzx, movsx, mov, (v)movdqu, (v)movdqa, (v)movap*, (v)movup*
| |
| − | |-
| |
| − | | SHFT || 2 || sal, shl, rol, adc, sarx, adcx, adox, etc.
| |
| − | |-
| |
| − | | Slow Int || 1 || mul, imul, bsr, rcl, shld, mulx, pdep, etc.
| |
| − | |-
| |
| − | | BM 2 andn, bextr, blsi, blsmsk, bzhi, etc.
| |
| − | |-
| |
| − | | Vec ALU || 3 || (v)pand, (v)por, (v)pxor, (v)movq, (v)movq, (v)movap*, (v)movup*, (v)andp*, (v)orp*, (v)paddb/w/d/q, (v)blendv*, (v)blendp*, (v)pblendd
| |
| − | |-
| |
| − | | Vec_Shft || 2 || (v)psllv*, (v)psrlv*, vector shift count in imm8
| |
| − | |-
| |
| − | | Vec Add || 2 || (v)addp*, (v)cmpp*, (v)max*, (v)min*, (v)padds*, (v)paddus*, (v)psign, (v)pabs, (v)pavgb, (v)pcmpeq*, (v)pmax, (v)cvtps2dq, (v)cvtdq2ps, (v)cvtsd2si, (v)cvtss2si
| |
| − | |-
| |
| − | | Shuffle || 2 || (v)shufp*, vperm*, (v)pack*, (v)unpck*, (v)punpck*, (v)pshuf*, (v)pslldq, (v)alignr, (v)pmovzx*, vbroadcast*, (v)pslldq, (v)psrldq, (v)pblendw
| |
| − | |-
| |
| − | | Vec Mul || 2 || (v)mul*, (v)pmul*, (v)pmadd*
| |
| − | |-
| |
| − | | SIMD Misc || 1 || STTNI, (v)pclmulqdq, (v)psadw, vector shift count in xmm
| |
| − | |-
| |
| − | | FP Mov || 1 || (v)movsd/ss, (v)movd gpr
| |
| − | |-
| |
| − | | DIVIDE || 1 || divp*, divs*, vdiv*, sqrt*, vsqrt*, rcp*, vrcp*, rsqrt*, idiv
| |
| − | |-
| |
| − | |-
| |
| − | |colspan="3" | This table was taken verbatim from the Intel manual. Execution unit mapping to {{x86|MMX|MMX instructions}} are not included.
| |
| − | |}
| |
| − | | |
| − | ===== Retirement =====
| |
| − | Once a µOP executes, or in the case of fused µOPs both µOPs have executed, they can be [[retired]]. Retirement happens [[in-order]] and releases any used resources such as those used to keep track in the [[reorder buffer]]. With retirement/allocation increasing from four to five in Sunny Cove, it's now possible to retire 5 instructions per cycle (5 unfused or 7 with fused ops).
| |
| | | | |
| | == Die == | | == Die == |
| | === Core === | | === Core === |
| − | * [[Intel 10 nm process]] | + | * [[10 nm process|10nm+ process]] |
| − | * Core from an {{\\|Ice Lake (client)}} SoC | + | * Core from an {{\\|Ice Lake (client)|Ice Lake}} SoC |
| | * ~6.91 mm² die size | | * ~6.91 mm² die size |
| | ** ~3.5 mm x ~1.97 mm | | ** ~3.5 mm x ~1.97 mm |
| Line 437: |
Line 178: |
| | | | |
| | :[[File:ice lake die core 2.png|500px]] | | :[[File:ice lake die core 2.png|500px]] |
| − |
| |
| − |
| |
| − |
| |
| − | * [[Intel 10 nm process]]
| |
| − | * Core from an {{\\|Ice Lake (server)}} SoC
| |
| − |
| |
| − | :[[File:ice lake core die.png|200px]]
| |
| | | | |
| | === Core group === | | === Core group === |
| − | * [[Intel 10 nm process]] | + | * [[10 nm process|10nm+ process]] |
| | * Quad-core from an {{\\|Ice Lake (client)|Ice Lake}} SoC | | * Quad-core from an {{\\|Ice Lake (client)|Ice Lake}} SoC |
| | * ~30.73 mm² die size | | * ~30.73 mm² die size |
