基本介紹
- 中文名：Nehalem
- 外文名：Nehalem
- 成立時間：2008年11月17日
- 基礎：Core微架構
- 分類：技術
Nehalem技術研究,總述,QPI匯流排技術,IMC,SMT,前端部分,亂序引擎和執行部分,快取結構,TLB，虛擬化性能,Nehalem的模組化設計,Nehalem微架構,Nehalem代號由來,
Nehalem技術研究
總述
下文中介紹的Nehalem的技術指標主要是以Nehalem-EP（Gainestown）為範例來介紹的，該核心將會用於Xeon DP，就是用於伺服器的雙路CPU。Nehalem是4核心、8執行緒、64bit、4超標量發射、亂序執行的CPU，有16級流水線、48bit虛擬定址和40bit物理定址。
比起從Pentium 4的NetBurst架構到Core 微架構的較大變化來說，從Core 微架到Nehalem架構的基本核心部分的變化則要小一些，因為Nehalem還是4指令寬度的解碼/重命名/撤銷。
Nehalem的核心部分比Core 微架構新增加的功能主要有以下幾方面：
New SSE4.2Instructions （新增加SSE4.2指令）
Improved Lock Support （改進的鎖定支持）
Additional Caching Hierarchy （新的快取層次體系）
Deeper Buffers （更深的緩衝）
Improved Loop Streaming （改進的循環流）
Simultaneous Multi-Threading （同步多執行緒）
Faster Virtualization （更快的虛擬化）
Better Branch Prediction （更好的分支預測）
QPI匯流排技術
Nehalem使用的QPI匯流排是基於數據包傳輸（packet-based）、高頻寬、低延遲的點到點互連技術（point to point interconnect），速度達到6.4GT/s（每秒可以傳輸6.4G次數據）。每一條連線（link）是20bit位寬的接口，使用高速的差分信號（differential signaling）和專用的時鐘通道（dedicated clock lane），這些時鐘通道具有失效備援（failover）。QPI數據包是80bit的長度，傳送需要用4個周期。儘管數據包是80bit，但只有64bit是用於數據，其它的數據位則是用於流量控制、CRC和其它一些目的。這樣，每條連線就一次傳輸16bit（2Byte）的數據，其餘的位寬則是用於CRC。由於QPI匯流排可以雙向傳輸，那么一條QPI匯流排連線理論最大值就可以達到25.6GB/s（2×2B×6.4GT/s）的數據傳送。單向則是12.8GB/s。
對於不同市場的Nehalem，可以具有不同的QPI匯流排條數。比如桌面市場的CPU，具有1條或者半條QPI匯流排（半條可能是用10bit位寬或單向）；DP伺服器（雙CPU插座）的CPU，每個具有2條QPI匯流排；而MP伺服器（4個或8個CPU插座）的，則每個具有4條或更多的QPI匯流排。
IMC
Nehalem的IMC（integrated memory controller，整合記憶體控制器），可以支持3通道的DDR3記憶體，運行在1.33GT/s（DDR3-1333），這樣總共的峰值頻寬就可以達到32GB/s（3×64bit×1.33GT/s÷8）。不過還並不支持FB-DIMM，要Nehalem EX（Beckton）才有可能會支持FB-DIMM（Fully Buffered-DIMM，全緩衝記憶體模組）。每通道的記憶體都能夠獨立操作，控制器需要亂序執行來降低（掩蓋）延遲。由於有了Core 2近4倍的記憶體頻寬，Nehalem的每個核心支持最大10個未解決的數據快取命中失敗（outstanding data cache miss）和總共16個命中失敗，而Core 2在運行中則只支持最大8個數據快取的和總共14個的命中失敗。
IMC能夠很顯著的降低記憶體延遲（尤其是對於採用FB-DIMM方案的系統）。下面的Nehalem與Harpertown，我不清楚是什麼頻率情況下的對比（來自於IDF上的表格，可能Nehalem是3.2GHz）。Nehalem的本地記憶體延遲大約是Harpertown的60%。Harpertown系統使用的是1.6GT/s的前端匯流排，所有記憶體都在一個位置，大約是略低於100ns（納秒）的延遲，這樣Nehalem的記憶體延遲就是約60ns。對於2個CPU插座的Nehalem來說，使用的是NUMA結構（Non Uniform Memory Access Achitecture，非均勻記憶體存取架構），遠方記憶體的延遲則要高一些，因為這時對記憶體的請求和回應需要通過QPI匯流排，其延遲大約是Harpertown的95%。所以，即使是最糟糕的情況，延遲還是得到了降低。一個有意思的問題是，當使用4個CPU插座的Nehalem時，延遲是否將會被增大？因為這種系統很有可能會使用FB-DIMM，而這意味著將遭受延遲損失，不過遠方記憶體的延遲還是將只會比本地記憶體慢個約30ns。
對於其它使用IMC和核心互連的多CPU系統（例如EV7、K8、K10），記憶體延遲也是非均勻的（NUMA）。為了最佳化性能，作業系統就必須知道延遲差異，並調度那些在同一個CPU上共享數據的進程。Windows Vista是Microsoft的第一個為NUMA進行最佳化的作業系統，而Linux等則已經很早就可以支持NUMA了。
Nehalem的遠方/本地延遲比是約1.5倍。衡量K8的NUMA係數（也就是遠方延遲除以本地延遲）在2 CPU系統時也差不多是1.5。而在4 CPU系統時，INTEL將具有優勢，因為所有的記憶體要么都是本地（當QPI匯流排上沒有hop時），或者所有記憶體都是遠方（QPI匯流排上有一個hop時）。因為使用對角線連線，每個CPU都有QPI匯流排連線，那么遠方記憶體最多就一跳（1個hop）。而現在的4插座的K8或K10系統，有的記憶體在HT匯流排上多達有2個hop。總之，具有更大的NUMA係數，就更需要軟體考慮其所使用的記憶體的位置。作為參考，其中最早一個具備IMC和核心互連的EV7，在其64 CPU的系統中，NUMA係數為1.86-5.21（1-8個hop的情況）。
SMT
為什麼Core 2沒有使用SMT？很顯然，它是可以做到的。SMT是在節省電力的基礎上增加了性能，而且軟體支持的基礎建設也早就有了。有2個可能的原因：一是Core 2可能沒有足夠的記憶體頻寬和CPU內部頻寬來利用SMT獲得優勢。通常，SMT能夠提升記憶體級並行（memory level parallelism，MLP），但是對於記憶體頻寬已經成為瓶頸的系統則是個麻煩。而更有可能的原因則是SMT的設計、生效等是很麻煩的，而當初設計SMT是由INTEL的Hillsboro小組主持，而並非是Haifa小組（Core 2是由這個小組負責的）。這樣Core 2不使用SMT就避免了冒險。
Nehalem的同步多執行緒（Simultaneous Multi-Threading，SMT）是2-way的，每核心可以同時執行2個執行緒。對於執行引擎來說，在多執行緒任務的情況下，就可以掩蓋單個執行緒的延遲。SMT功能的好處是只需要消耗很小的核心面積代價，就可以在多任務的情況下提供顯著的性能提升，比起完全再添加一個物理核心來說要划算得多。這個和以前P4的HT技術是一樣的，但比較起來，Nehalem的優勢是有更大的快取和更大的記憶體頻寬，這樣就更能夠有效的發揮。按照INTEL的說法，Nehalem的SMT可以在增加很少能耗的情況下，讓性能提升20-30%。
對於SMT的各執行緒間所採用的資源共享策略有許多種：
1、複製型—— 執行緒都可以複製使用
暫存器狀態
重命名RSB（重命名返回堆疊快取）
大頁表ITLB
2、靜態分配型—— 一般由執行緒平分
各種主要的緩衝：讀取、存儲、重排序
小頁表ITLB
3、競爭共享—— 由執行緒動態占有
保留站（RS）
快取（Cache）
數據TLB（DTLB），L2 TLB
4、不受影響
執行單元
Nehalem同時也降低了同步原語（起始同步），比如LOCK prefix、XCHG和CMPXCHG等指令的延遲。同步原語在多執行緒編程中是必需的，而多執行緒的擴展性被同步所限制，通過降低延遲，可以提高現在多執行緒軟體的性能。INTEL宣稱，Nehalem的LOCK CMPXCHG指令（其作用是使整個流水線串列化）的延遲是P4的約20%，Core 2的約60%。儘管降低了延遲，但行為仍然和以前的CPU還是一樣的，鎖定指令（Lock）並不是管道化的，即使後面的操作可以被提前到鎖定指令之前來執行。
前端部分
（指令拾取和解碼）
1、指令拾取（包括分支預測）
有兩種可能。一是兩個BTB使用同樣的預測算法，而一個存取更小一點的歷史檔案，包含最近時間內所使用的分支RIP和目標RIP。在這種情況下，它們的關係就象L1快取和L2快取一樣（因為分支目標也具有相當好的地址相關性）。舉個例子，比如L1 BTB有256-512項，而更大的L2 BTB則有2K-8K項。如果分支RIP在L1 BTB中沒有找到，然後就到L2 BTB中去找，以作出目標預測。
另一種可能（RWT認為這種可能性比較小）則是兩級BTB使用不同的預測算法和不同的歷史檔案。比如L1 BTB使用簡單而快速的算法和相對較小的歷史檔案，而L2 BTB則使用更慢但更準確的算法，而且被配置成是具有優先權的預測器。如果L2 BTB不同意L1 BTB的預測，則它可以撤消（override）L1 BTB的預測，去除掉流水線中錯誤拾取的指令，而從新預測的RIP處重新拾取指令。這種結構可能性不大，因為它的能效比較低下。對於這種預測器架構，通常的情況是L1和L2 BTB都獨立的得出正確的分支目標——這就意味著在大多數的時間裡，L2 BTB都是在浪費能源。而L1 BTB錯誤，L2 BTB是正確的情況，只占非常小的比例。
不過在更早一點的ANANDTECH的文章中有提到認為是第二種方式：通常會遇到這樣的情況，L1 BTB作出預測是基於分支的類型，但實際上它並沒有歷史數據，這樣準確度就很低。而L2 BTB有更多的歷史數據，就可以提高準確度，而且L2 BTB可以在執行過程中就糾正（L1 BTB所給出的）錯誤預測，而避免性能損失（這就正是override的情況）。
現在不清楚哪一種觀點更正確一些。
Nehalem另一個提升分支目標預測的機制是對返回堆疊緩衝（return stack buffer，RSB）進行了重命名。當發生程式調用時，RSB就記錄下地址，這樣當結束調用返回時，就從該地址繼續執行下去。但是當有很多程式遞歸調用時，RSB將會溢出，並且如果分支預測錯誤，那么也將會產生錯誤的返回地址。Nehalem通過重命名RSB，就避免了溢出。並且錯誤的分支預測也不會毀壞RSB，只要調用與返回地址是正確配對的，那么就可以從Nehalem的RSB中得到正確的數據。對於每一個執行緒都有一個專用的RSB，避免任何交叉弄髒數據。
拾取單元取得了每一個執行緒預測的下一個地址（通常情況下也就是正確的下一個地址），就到ITLB（指令旁路轉換緩衝）和L1 I（一級指令快取）去標註。ILTB由每個執行緒靜態分配（平分），有128項快取4KB的小頁表，是4路聯合方式的快取；另外，每個執行緒還有7項用於快取大頁表檔案（2MB/4MB），是全聯合方式。L1 I是32KB，4路聯合方式，由執行緒競爭共享。進入指令快取後，每周期16Byte（128bit）的指令傳送到預解碼和拾取緩衝（pre-decode and fetch buffer）。然後，每周期6條指令從預解碼和拾取緩衝傳送到有18個項目數的指令佇列（instruction queue）。在Core 2中，指令佇列被用做循環快取（Loop Stream Detector，LSD，循環流檢測器），這樣碰上小循環（指令數≤18）的時候，指令拾取單元就可以被關閉。而Nehalem的指令佇列則只是作為指令被解碼前的緩衝，因為它的循環快取在流水線級數中，被放到了解碼階段的後面。
2、解碼
當X86指令進入指令佇列後，它們就等著被解碼成微操作指令（uop），這是一種類似於RISC的指令。Core 2和Nehalem都有4個解碼器，一個複雜解碼器和3個簡單解碼器。簡單解碼器能夠處理可以解碼成一個uop的X86指令，現在絕大多數SSE指令都是這種。複雜解碼器能夠處理解碼成1-4個uop的X86指令，而比這還要複雜的指令，則由微代碼序列器（microcode sequencer）來處理。
Nehalem改進了宏操作融合（macro-op fusion）。Core 2可以在32bit模式下，把TEST/CMP（比較指令）和其後的Jcc（條件分支指令）給解碼融合成一個微操作（uop）：CMP+Jcc。這樣就增加了解碼頻寬，並減少了微運算元量。而Nehalem的宏操作融合則包括了更多的條件分支指令：JL/JNGE, JGE/JNL, JLE/JNG, JG/JNLE。TEST/CMP和這些條件分支指令都將被解碼成一個微操作：CMP+ Jcc。而且，Nehalem的宏操作融合可以是32bit和64bit模式。這是很重要的，因為現在大多數伺服器都運行的是64bit作業系統，即使是桌面電腦也開始更多的歡迎64bit作業系統了。
一旦X86指令解碼成微操作，就進入有28個項目數的微操作緩衝（uop buffer），Nehalem將其作為前面介紹到的LSD（Loop Stream Detector，循環流檢測器）。如果一個循環不大於28個微操作，則Nehalem就可以將其快取在LSD里，並傳送到亂序執行引擎去執行，而關閉指令拾取單元和解碼器。這樣通過關閉解碼器和使用更大的循環，就能夠比Core 2的LSD節省更多的能耗。Nehalem的28項的微操作緩衝，能夠保存相當於21-23條X86指令（根據在一些遊戲中的測試情況得出的估計）。X86指令轉換為微操作的比率取決於工作量的不同，不過總的來說，Nehalem具有比Core 2更大一些的LSD緩衝。
比較有趣的是，Nehalem的LSD緩衝看起來更象是指令追蹤快取（trace cache）。指令追蹤快取的目標是以動態程式的順序來存儲微操作，而不是象指令快取里那樣以靜態編譯順序存儲X86指令，因此可以從關鍵路徑（critical path，指需要時間最長的路徑）中去掉解碼器和分支預測器，而使得被堵塞的地方可以立刻取得指令。P4的指令追蹤快取的問題在於它太脆弱了，當其命中失敗時，就必須一個接一個地（重新）解碼指令。通常指令快取的命中率是在90%以上，而指令追蹤快取卻遠低於這個標準，很少時候超過80%，大多數時候是在50-60%。也就是說，在40-50%的時間裡，P4都表現得象是一個單發射微處理器，而不能夠完全利用上它的執行資源。而Nehalem的LSD緩衝取得了和指令追蹤快取幾乎同樣的目標，而且當它無法工作的時候（即當循環太大時），也沒有什麼要命的性能損失。
亂序引擎和執行部分
（Out-of-Order Engine and Execution Units）
Nehalem的亂序引擎顯著的擴大了，除了性能原因，還有就是為了提供SMT，因為SMT需要資源共享。
和Core 2一樣，Nehalem的暫存器重命名表（register alias table，RAT）指明每一個結構暫存器（architectural register）要么進入重排序緩衝（Re-Order Buffer，ROB），要么是進入撤銷暫存器檔案（Retirement Register File，RRF，或翻譯為引退暫存器檔案），並且保持有絕大多數最近的推測值狀態（speculative state）。而RRF則保持有絕大多數最近的非推測狀態（non-speculative state）。RAT可以每周期重命名4個微操作，給每一個微操作在ROB中一個目的地暫存器（destination register）。被重命名的指令就讀取它們的源運算元並被傳送到通用架構的保留站（unified Reservation Station，RS，可以被各種指令類型使用）。
Nehalem的ROB（重排序緩衝）從96項增加到128項，RS（保留站）從32項增加到36項，它們都由兩個執行緒所共享，但是使用不同的策略。ROB是靜態分配給2個執行緒，使得2個執行緒在指令流里都可以預測得一樣遠。而RS則是競爭共享，基於各執行緒的需求。這是因為許多時候一個執行緒可能會中止，從記憶體等待運算元，而使用到很少的RS項。這樣就不如讓另一個更活躍的執行緒儘可能多地使用RS項。在RS中的指令當其所有運算元都準備好時，就被分配到執行單元去。
Nehalem的執行單元與Core 2相比，基本沒有大的改變，而且並不受SMT的影響，除了使用率更高之外。
快取結構
幾乎Nehalem的所有方面都是略為改進並增強，但存儲子系統（memory subsystem，或翻譯為記憶體子系統）卻是非常激烈的大修理。
Nehalem可以同時運行的讀取和存儲量增加了50%，讀取緩衝由32項增加到了48項，而存儲緩衝由20項增加到了32項（增量還略多於50%）。增加的原因自然是為了讓兩個執行緒共享，這裡採用的是靜態分配，可能是由於關鍵路徑的限制。
從讀取緩衝和存儲緩衝，存儲操作就繼續訪問到快取架構。Nehalem的快取架構是完全革新了的。象P4一樣，所有的快取和數據TLB（Translation Lookaside Buffer，旁路轉換緩衝，或叫頁表緩衝）都是由2個執行緒動態共享（根據已經觀察到的行為）。Nehalem的L1 D（一級數據快取）保留了和Core 2一樣的大小和聯合度（associativity），但是延遲卻從3個周期增加到了4個周期，以適應時間限制（timing constraint）。另外前面已經說到，每一個核心可以支持更多的未解決的命中失敗（outstanding miss），最多到16個，可以利用更多的存儲頻寬。
Nehalem的每個核心有一個私有的通用型L2，是8路聯合的256KB，訪問速度相當快。其使用延遲時間還沒有完全披露，不過INTEL的工程師表明是小於12個周期的。Nehalem的L2相對於其L1D來說，既不是包含式（inclusive）也不是獨占式（exclusive），就象Core 2一樣，Nehalem可以在兩個核心的私有快取（L1D和L2）之間傳遞數據，儘管不能夠達到全速。
Nehalem的16路聯合、8MB的L3對於前兩級來說，是完全包含式的，並且由4個核心共享。儘管INTEL並沒有完全說明Nehalem的物理設計，但似乎L3快取是單獨使用電力，並運行在單獨的頻率上。這是從節省電力和可靠性這兩個方面推斷出來的，因為大的快取更容易在低電壓下產生軟錯誤（soft error）。這樣，L3使用延遲就取決於相對頻率、核心的相差（phase alignment）、L3自身，還有訪問L3的仲裁器的延遲。在最好的情況下，即操作相差和頻率差距是整數倍的情況下，Nehalem的L3使用延遲是在30-40周期（根據INTEL工程師的說法）。
使用包含式快取的好處是可以處理幾乎所有的一致性流量問題（coherency traffic），而不需要打攪到每個獨立核心的私有快取。如果在L3中發生命中失敗（cache miss），那么要訪問的數據就肯定也不在任何一個L2和L1中，不需要偵聽其它核心（而獨占式快取，則還要回頭去檢查其它核心）。
另一方面，Nehalem的L3對於快取命中成功（cache hit），也扮演著偵聽過濾器（snoop filter）的角色。獨占式快取命中成功時，不需要檢查其它核心，而包含式快取則一般需要檢查其它核心。但是在Nehalem的L3中的每一個快取行（cache line）里，有4 bit是用來做核心確認（core valid）的，表明是哪一個核心在它的私有快取里具有這個行的數據備份。如果一個核心確認位被設定成0，則那個核心就不具有該行的數據備份。Nehalem使用的是MESIF快取一致性協定（MESIF cache coherency protocol），如果兩個以上核心的確認位都有效（設定成1），那么該快取行就被確定是乾淨的（即未被修改的，任何一個核心的快取行都不能夠進入更改模式）。當L3快取命中，而4個核心確認位都是0時，就不需要對其它核心做偵聽；而只有1個位是有效時，則只需要偵聽那一個核心。這兩種技術的聯合使用，使得L3可以儘可能的讓每個核心避免數據一致性錯誤，這樣就給出更多的實際頻寬。
事實上，並非只有包含式快取這一種解決之道。對於非包含式快取來說，通過和最後一級快取一起複製所有私有快取的標誌檔案（tag file），並同時檢查所有的最後一級快取的訪問標誌和私有快取的訪問標誌，也可以達到同樣的性能好處，並避免數據一致性錯誤。而包含式快取則是設計得必須複製數據，這就能夠表明各級別之間大小的一定關係。Nehalem的每個核心有64KB L1D和256KB L2（有可能L1D的數據包含在L2中，也可能L1D的數據並沒有包含在L2中。因為L2並非包含式），這就意味著在8MB的L3中，有1-1.25MB的數據是前兩級快取中也有的數據。這就是包含式快取額外的開銷。
在Nehalem之前，處理對齊的指令更有優勢，而處理非對齊的指令則更慢、具有更低的數據吞吐量（即使其數據是在對齊的情況下），需要多個微操作。編譯器也總是避免後一種指令，儘量避免非對齊的讀取，象MOVSD+MOVHPD這樣的2條連續指令就會更快一些。
而Nehalem則對非對齊指令進行了最佳化：在存取對齊數據的時候，非對齊指令和對齊指令具有一樣的延遲和吞吐量。同時也提高了非對齊指令對於非對齊數據的訪問速度。這樣，不管是什麼類型的SSE操作，都具有相同的延遲。另外Nehalem對在存取數據時跨越了64-Byte快取行邊界的情況也進行了最佳化，比起Core 2具有更低的延遲和更高的吞吐量。這樣，編譯器就不會再懼怕使用非對齊的指令了。
TLB，虛擬化性能
除了改變快取架構，Nehalem還改變了TLB等級架構。TLB是用來快取虛擬地址和物理地址映射關係的。Core 2有著非常有趣的TLB安排，L1 DTLB（INTEL有時也叫做micro-TLB）非常的小，並且只用來讀取。它有16項小頁表（4KB page）和16項大頁表（2M/4M pages），每一個都是4路聯合。L2 DTLB更大一些，可以讀取和存儲（當在L1 DTLB中讀取失敗時，就到L2 DTLB中來讀取，並且L2 DTLB負責所有的存儲），它有256項小頁表和32項大頁表，也都是4路聯合。
Nehalem則建立起了真正意義上的兩級TLB體系，可以動態分配給SMT的活躍執行緒狀態（thread context）。Nehalem的L1 DTLB可以做所有的存儲訪問（可以讀取和存儲），它有64項小頁表和32項大頁表，也都是4路聯合。而新的L2 TLB是通用型的（可以用於指令和數據），它只有512項小頁表，也是4路聯合。
Nehalem和Core 2的TLB的一個明顯的差異是它們覆蓋快取的深度不同。Core 2（Penryn）有6MB L2，通過使用小頁表（絕大多數的套用都不使用大頁表），TLB可以轉換2176KB的記憶體（地址），這樣就覆蓋了1/3的L2。而Nehalem的一個核心有576項小頁表，整個CPU總共則是2304項，這樣TLB就可以轉換9216KB的記憶體，這已經超過8MB L3的容量了。
Nehalem的TLB項還通過使用虛擬處理器ID（Virtual Processor ID，VPID）而有所變化。每一個TLB項都快取一個記憶體頁的虛擬地址到物理地址的轉換。而這個轉換是特定於一個給定的進程或虛擬機（virtual machine，VM）。當處理器在虛擬客戶端和主機之間切換時，INTEL過去的CPU都要往TLB里填寫，以確保進程只能夠訪問到它們被允許訪問的記憶體。而VPID則跟蹤是哪一個VM的TLB項，這樣在該VM退出後又重新進入時，TLB就不用填寫也能夠確保全全。如果一個進程試圖訪問不是它自己的地址轉換，則就會直接在TLB中命中失敗，而不會是到頁表中去做非法訪問。VPID通過降低虛擬機地址轉換的開銷（overhead）而有助於提升虛擬化性能。INTEL估計，Nehalem的一個來回的VM地址轉換的延遲約是Conroe的40%，約比Penryn低1/3（即約是Penryn的66%）。
Nehalem的模組化設計
以適應不同的市場需求。
模組化組件有：
1、核心數量
2、SMT功能
3、L3快取容量
4、QPI連線數量
5、IMC數量
6、記憶體類型
7、記憶體通道數量
8、整合顯示卡
9、能耗和時鐘頻率
未來預定會發布的幾種Nehalem有：
Gainestown，用於Xeon DP
Bloomfield，定位於高端桌面市場
這兩種將於08年4季度上市。RWT認為可能Bloomfield將沒有SMT。
2009年發布：
Havendale，桌面雙核
Auburndale，移動雙核
Clarksfield，移動四核
Beckton，用於Xeon MP
Lynnfield，桌面主流四核
Nehalem的電路級技術，可能得等到秋季IDF才會公布。AMD的4核，其電路設計就發生了非常大的改變，從原來的1個變成具有5個時鐘分布網路（clock distribution network），有3個不同的電壓層（voltage plane），並在不同時鐘域（clock domain）之間使用動態FIFO。估計INTEL也將採用類似的手段來控制功耗和提升性能。現在比較有意思的問題是INTEL將採用何種動態時鐘技術（dynamic clocking technique）來提升單個執行緒的性能。現在的Penryn已經可以動態提升一個核心的頻率和電壓，當另一個核心是空閒的時候。而這項技術顯然對Nehalem是更有用的。
Nehalem微架構
Nehalem微架構分為兩個主要部分：計算核心與非計算核心
一. 計算核心的設計來源於之前的微架構，並對其進行了最佳化和加強，主要為以下幾個方面：
(3) 核心加速模式(Turbo Mode)----核心運行動態加速。可以根據需要開啟、關閉以及加速單個核心的運行。例如，在一個四核的Nehalem 微架構處理器中，如果一個任務只需要兩個核心，可以關閉另外兩個核心的運行，同時把工作的兩個核心的運行主頻提高。如果任務只需要一個核心，可以關閉其它三個核心，同時把工作的一個核心提高到更高的主頻運行。這樣動態的調整可以提高系統和CPU整體的能效比率。
(4) 新增的SSE 4.2指令集等等。
二. 非計算核心的設計改動令人矚目，主要的有：
(1) Cache的設計----採用三級全內含式Cache設計，L1的設計和Core 微架構一樣；L2採用超低延遲的設計，每個核心256KB；L3採用共享式設計，被片上所有核心共享。
(3) QPI----"快速通道互聯"，取代前端匯流排(FSB)的一種點到點連線技術，20位寬的QPI連線其頻寬可達驚人的每秒25.6GB，遠非FSB可比。QPI最初能夠發放異彩的是支持多個處理器的伺服器平台，QPI可以用於多處理器之間的互聯。
目前，基於Nehalem微架構的Bloomfield處理器(Bloomfield也是產品代碼)已經正式命名為"酷睿 i7"。酷睿是品牌，"i7"是系列編號。酷睿這一名稱現在和未來都將是英特爾公司PC處理器產品的旗艦品牌。
首款基於Nehalem微架構的處理器將是用於台式機的處理器酷睿 i7，支持的晶片組為x58。這款處理器有4個核心，計畫在今年第四季度上市。用於伺服器和筆記本電腦的Nehalem微架構處理器也會在將來陸續上市。
Nehalem代號由來
熟悉英特爾公司的人大概都知道每個英特爾的產品或者具有代表性的技術在開發的時候都有一個產品代碼或者項目代碼。這些代碼不會用於正式的產品上市，只會用於開發階段的溝通。
英特爾產品上市時使用的正式品牌和產品名的確定要遠遠晚於產品的立項和開發階段，產品的品牌和產品名涉及的方方面面太多，如法律方面的：商標註冊，使用範圍；人文方面的：用戶接受度等等。
因此，為了溝通方面，就先使用代碼溝通，英特爾公司把代碼的選擇權交給項目組或者項目的負責人，他們可以根據自己的喜好來給新產品和新技術取個代碼。不過，命名也不是天馬行空，有個前提，為了避免法律上潛在的風險，代碼名字的選用應該是地圖上可以找到的。
英特爾很多產品的開發部門都集中在加利福尼亞州(California)舊金山附近的矽谷以及俄勒岡州(Oregon)波特蘭市周邊，所以在這兩個地方工作的英特爾項目組都會以工作地周圍的地名，街道名，河流名，山名等等作為產品或者項目的代碼，它們在地圖上都可以找到。
當然，代碼的選用不限於這兩個州，項目的負責人也可以從自己家鄉的地圖或者其他地方地圖上可以找到的名字來作為代碼。在我印象中，中國團隊負責的一些項目就用過像Pearl River(珠江)，Yellow River(黃河), O'River(甌江)等等，因為項目是區域性的，也只是在內部溝通使用，所以眾多代碼並不為公眾知曉。
我特意查了一下，Nehalem其實是美國俄勒岡州波特蘭市的一個小小的衛星城。
