While Nehalem packs in an awful lot of improvements, the reality is that not all market segments really need everything. Take the integrated memory controller – it is an absolute necessity for servers, but might not even make sense for a low-end desktop. This is where the extreme modularity of Nehalem comes into play. The Core 2 was really a take it or leave it proposition; Merom (mobile), Conroe (desktop) and Woodcrest (server) and even Tigerton (MP server) were all more or less the same. For Nehalem, there will be a variety of different proliferations that are specifically tuned across a wide range of parameters to fit each market segment, just as Intel’s chipsets were previously used to differentiate across the market.
Unsurprisingly then, most of the differentiation for proliferations of Nehalem will focus on changing the “un-core” features of Nehalem. Some of the un-core elements that are flexible are:
- Core count
- Simultaneous Multi-Threading
- L3 cache size
- Number of QPI links
- Advanced routing features like directories
- Integrated or discrete memory controller
- Type of memory
- Number of memory channels
- Integrated or discrete graphics
- Power and clocking
- Virtual and physical addressing
Of course, throughout this article, we have referred to Nehalem as if it was a single implementation, but that is not the case. Currently, there are six variants of Nehalem slated to be released in the future. Gainestown is a Xeon DP product that is more or less the baseline for all Nehalem implementations as described in this article. It is a quad-core, 8MB L3 cache design with 2 QPI links and a triple channel DDR3 integrated memory controller. Bloomfield is more or less the same device, but targeted at the high-end desktop market, rather than servers. Both Gainestown and Bloomfield will come out towards the end of this year, likely in Q4 – although Bloomfield may not have SMT enabled.
Next up are Auburndale, Havendale and Clarksfield, which are a dual-core desktop, a dual-core mobile and a quad-core mobile processor. These three products are where the bulk of the differentiation will be needed. Power and clocking features will be used to distinguish desktop and mobile processors, and may even be used within the mobile market to stratify ultra-mobile parts versus mainstream parts. In general, the dual-core products (note all dual-core codenames end in “dale”, while quad-cores end in “field” or “town”) will continue to be the mainstream for both desktop and especially notebook systems (for power reasons). These mainstream CPUs will ship with smaller caches, perhaps 2-4MB, fewer memory channels (probably 2) and SMT disabled. There will also be a lot of options with respect to the chipset and graphics. Intel will aggressively push options that integrate the chipset and graphics in the same package – but OEMs are very likely to want some CPUs to use with third party chipsets from NVIDIA, SiS and the like (although how NVIDIA’s QPI license plays out is unclear right now), as well as some with discrete graphics. The quad-core Clarksfield is a little harder to pin down, as that is probably aimed at mobile gaming or workstations – where integrated graphics makes little sense, but an integrated memory controller and large L3 cache would be a boon.
The last Nehalem based product to come to market will be Beckton (or Nehalem EX), the Xeon MP variant, which is slated for 2009. At this point in time, very little has been said publicly about the product. However, it is possible to speculate with some degree of accuracy. Considering Dunnington is a 6-core design, Beckton will be at least 6 cores, but more likely 8. Since Beckton will contain at least as many cores, it will probably need at least as much cache as Dunnington. Beckton will have at least 3 and a half QPI links, so that the CPUs in a four socket system will be fully connected, but they may very well include more links to encourage further scalability. Beckton may also raise the virtual and physical addressing limits, based upon DRAM density, DIMM capacity and market demand for large memory configurations.