BetaONE will rise again!


Reply
  #1  
Old 19th Apr 04, 04:41 AM
Alpine's Avatar
Alpine Alpine is offline
Retired Crew
 
Join Date: Feb 2002
Location: Run Forest, RUN!!
Posts: 3,601
Alpine is on a distinguished road
Send a message via ICQ to Alpine Send a message via AIM to Alpine
AS YOU CAN read on our site, Intel FB (Fully Buffered) DIMM modules are a very interesting twist on the changes in memory technology and the problems that higher DRAM clocks bring to the memory expandability and overall reliability.
Of course, DDR400 can barely operate well with two DIMMs per channel, and, if you go to the current DDR1 "overclockers" maximum, the DDR550 or 566 (PC4400 or PC4500), well it is pretty much one DIMM per channel, provided that even that works.

DDR2 is slightly better at the cost of higher latency (two DIMMs per channel at DDR2 533 or 667, and one DIMM per channel expected for DDR2 800) but again, that's nothing compared to the FB DIMMs immense expandability.

However, expandability for large memory capacity in future 64-bit iAMD64 desktops and coming 64-bit iAMD64 workstations and servers is just a tip of the iceberg. It is that nice low pin count (one-third per channel compared to DDR) and relative independence on actual memory technology that makes it so interesting. After all, the buffer chip is constant, but the DIMM memory behind it, which the CPU or chipset don't necessarily need to see, could be DDR1, or DDR2, or one day DDR3 or Rambus XDR?

Remember when, some time ago, Intel supposedly dismissed the notion of integrated memory controller a la AMD Athlon64 or Opteron, despite the obvious memory performance advantages and better SMP scalability? The alleged response was that, besides adding many more pins for the memory, CPUs with integrated memory controllers are stuck with that one memory type that the integrated controller supports. So, if you change from say DDR1 to DDR2 (put aside that I don't see any value in that change right now), you're stuck as your CPU's integrated controller only supports DDR1. So, Intel didn't take the integrated memory controller route because of this - till now...

The FB DIMM approach fits nicely, solving both problems - the pin count, and memory technology dependence. Now, with FB DIMM path, two channel can be had for far less pins that one current DDR channel requires, and the actual type of the DRAM chip with its specific signals is, well, handled by the DIMM and its buffer chip. Therefore, with FB DIMM channels, you could possibly use few different generations of memory technology without changing the CPU memory controller.

So, Intel could finally integrate the memory controllers on all of its future CPUs, and even use this on any future surviving Itanics (no, I didn't mean shipwreck survivors) to give them what Alpha EV7 has since 2001 - integrated compact, low pin-count, high-bandwidth 8-channel Rambus memory controller, where a single EV7 chip has more memory bandwidth than a quad-CPU Itanium 2. So, now, any Tukwillas or whatever comes out provided HP still rides this ship, could have, say, 8 FB-DIMM channels per CPU? Hey, even the per-channel pin counts are similar!

In fact, let's play with the calculator a bit - let's say we look at an Athlon64 (the normal, not FX, variety) 754 pin package, for instance, remove say 30 pins from the integrated memory controller to account for a difference (gain) between single-channel DDR and dual-channel FB memory, and then, say, add an extra 50 pins for more power and grounding to supply, say, a much hotter, hungry core like say Prescott? Oh my, the number comes out to be (almost) 775 - what a coincidence... and no, I didn't say LGA775.



Source:


The INQ!
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 10:49 PM.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.