●高速化で問題となるDRAMのチャネル容量 サーバーやPCなどのシステムに搭載できる最大メモリ量はこれまで増え続けてきた。1メモリチャネルに接続できるメモリチップ数は一定だが、DRAM 1チップ当たりの容量が増え続けて来たからだ。つまり、DRAMチップ容量が2年で2倍になるたびに、DRAMのチャネル容量(Channel Density)も2倍になってきた。だから、32bitのメモリアドレッシングでは足りないという議論も浮上してきたわけだ。 しかし、ここへ来て、そのトレンドに変化が見え始めた。システムに搭載できるメモリ容量が横ばいになるか、最悪の場合には減る可能性が出てきたのだ。それは、DRAMが高速化するにつれて、1チャネルに接続できるチップ数が減り始めたからだ。Unbuffered DIMMだけでなく、Address/CommandをバッファリングしているRegistered DIMMであってもこうした問題が生じる。現在のペースでDRAMが高速化して行くと、サーバーに搭載できるメモリ容量は来年以降に頭打ちとなってしまう。デスクトップPCも同様で、デュアルチャネル構成でも4GB以上は搭載できなくなる可能性がある。 下が、エルピーダメモリが今年2月にPlatform Conferenceで行なった、サーバー向けメモリのチャネル当たりのスロットとバンク数のプレゼンテーションのスライドだ。これを見ると、フルの1チャネル4スロット構成である「4Slots/2Ranks」で、問題なく使えるのはDDR266までとなっている。つまり、2バンク(rankとも言う)構成のDIMM(x8なら両面で16~18チップ、x4なら32~36チップ)を4枚装着できるのはDDR266まで。DDR333になるとと理論上も4スロット(4Slots/2Ranks)は限界域で、400Mtps(Mega transfer per second)、つまりDDR400以上になると完全にNGとなっている。
そして、400Mtpsの場合は2スロット(2Slots/2Ranks)までは可能だが、3スロット(3Slots/2Ranks)は難しい。そして、問題は、2スロット(2Slots/2Ranks)は667Mtpsまでが可能で、800Mtpsになるとこれも難しく、1,067MtpsだとNGになってしまうことだ。そのため、このままのアーキテクチャでDDR3世代に入ると、ついにメモリのトポロジは1Slot/2Ranks、つまり1スロットだけの構成になってしまうと見られる。そして、最終的には1バンクのDIMM 1枚が限界の1Slot/1Rank=ポイントツーポイント接続になってしまうと予測されている。 ●システムのメモリ容量の増加が止まってしまう? こうして見ると、今後は約2年毎に1チャネルに接続できるDIMM枚数とDRAMチップ数が半減して行ってしまうのがわかる。面白いことに、この2年毎のスケールダウンは、2年に2倍のDRAMチップの容量増大を完全に相殺してしまう。そのため、システムの搭載メモリ容量は横ばいとなってしまう。もし大容量化がもたつくか、高速化が加速されれば、メモリ容量は逆に減ってしまう。 下が、それを図式化したチャートで、サーバー部分はIntelのIDFでのプレゼンテーションなどをベースにしている。サーバーの搭載メモリ容量はデュアルチャネルメモリインターフェイスで、大容量品のDRAMチップでx4の構成のDIMM(2RanksでECC含めて36 DRAMチップ)を想定してある。デスクトップは普及価格帯のDRAMチップでx8の構成のDIMM(2Ranksで16 DRAMチップ)を想定しているが、UnbufferedではAddress/Commandもバッファされていないため、もっと早く制約が来るのかもしれない。
いずれにせよ、これを見ると問題点は一目瞭然だ。DRAMが高速化するにつれて、本来の2年で2倍の大容量化からは、どんどんかけ離れて行ってしまう。 こうした問題が発生する根本的な原因は、現在のDRAMがStub型バスアーキテクチャ、つまりひとつのバスに複数の分岐があるトポロジーを採っているところにあるという。Stubからの反射によって高速化が難しくなるからだ。Stubバスで高速化して行くには、メモリスロット数とDIMM当たりのバンク(またはrank)数を減らさなければならなくなる。 ところが、今のDDR系列のメモリバスアーキテクチャでは、そうなるとシステムのメモリ容量が減ってしまう。つまり容量と帯域を両立させることができないという問題を抱えている。もちろん、4チャネルメモリとか8チャネルメモリとか、どんどんインターフェイス幅を増やせれば問題はないのだが、1チャネル64bit幅のインターフェイスだと、そうした場合にはピン数が多く実装面積が広くなってしまい現実的ではない。 ●根本解決に必要なのは非Stub型バスを前提としたメモリ この問題を根本から解決するには、本当はStubがないまたはStubがほとんどないDRAMバスアーキテクチャを導入するのがいい。Intelが一時RDRAMを導入した理由はそこにある。RDRAMは、Stubの影響を最小に抑えており、また、16bitと狭インターフェイス幅を取っている。16bit幅のRDRAMなら、デスクトップPCでも4チャネルの実装が可能になる。実際、SiSのPentium 4向けチップセット「SiS R659」は4チャネルRDRAMインターフェイスを実装している。 さらに、数Gtpsクラスの転送レート向けには、完全にStubのないポイントツーポイント型あるいはデイジーチェーン型の接続のメモリのアイデアがすでに出ている。Rambusが昨日発表した次世代メモリ「XDR DRAM(Yellowstone:イエローストーン)」がそうしたテクノロジーを取る。また、Samsung Electronicsも、2年前のIntel Developer Forum(IDF)で、ポイントツーポイント型のアーキテクチャ構想を示したことがある。DRAMのバスアーキテクチャを根本から変えなければ、数Gtpsは難しいというのは、DRAM業界の共通認識と言ってもいい。 ところが、そうなると今のDRAMの技術的な流れをいったんご破算にしなければならない。例えば、同じコントローラでDDR2と新種メモリの両方に対応するといったことが難しくなる。開発のハードルも高くなり、DRAMベンダーの開発力の差も鮮明になってしまう。そうした状況で、“DDR”がつくメモリ規格は、広インターフェイス幅でStubのあるバスでこれまで策定が進められてきた。そこで、当然のように行き詰まりが近づいてきてしまったわけだ。 こうした手詰まり状況を短期的に打開する手段として出てきたのが、先週レポートした「Hub on DIMM(HoD)」や「Fully buffered DIMM」といったアイデアだ。Hub on DIMMはDDR3のモジュール案のアイデアのひとつとして3月のJEDEXなどで公式に紹介されたもの。Fully buffered DIMMも似たようなアイデアだが、こちらはIntelからの提案だという。いずれも、基本的な考え方はある程度似ていて、address/command/dataのすべてをバッファするHubチップをDIMM上に設置する。チップセットやCPUのメモリコントローラは、Hubチップにまずアクセスして、Hubチップが実際のDRAMにアクセスする。 そして、この新DIMMソリューションで、激しく対立しているのがIntelとAMDだと言われている。
●AMDにとって問題となるDRAMトレンドの変化 じつは、AMDにとって、チャネル当たりのメモリ容量の減少の問題はかなり頭が痛い。というのは、Intelよりも、この問題が大きく影響してしまうからだ。 例えば、AMDのAthlon 64はシングルチャネルDDRメモリインターフェイスしか備えていないため、パフォーマンスデスクトップをデュアルチャネルメモリへと移行しつつあるIntelの方が理論上は2倍のメモリ量を確保できる。また、デスクトップPCのメモリ容量が上がって行かないと、4GBを越えるメモリ量をリニアに扱うことができるAthlon 64の64bitアーキテクチャの利点が薄れてしまう。そうした背景を考えると、Athlon 64はデュアルチャネルメモリへと向かうのが自然の流れとなる。 また、Athlon 64/Opteron系アーキテクチャの場合、DRAMメモリインターフェイスをCPUに統合している。Intelはメモリインターフェイスをチップセット側に持たせているので、メモリインターフェイス技術の変化にも対応がしやすい。それに対して、AMDは新メモリインターフェイスに対応するには、CPUの設計変更が必要になるので、仕様確定から市場導入まで、より長いリードタイムが必要となる。 だから、この問題を解決するためにHub on DIMMをやろうという話が本当に決まると、AMDとしてはCPUの設計変更に取りかからなければならなくなる。まして、その新しいHubインターフェイス規格がIntel主導で決まってしまったら、これはさらにやっかいな話になってしまう。AMDが対抗するのも当然というわけだ。 しかし、Hub on DIMM化がもし実現すると、それは、AMDにとってもチャンスにもなる。それは、AMDのアーキテクチャの利点がより活きてくるからだ。 □関連記事【7月4日】【海外】高速化するDRAM、次々世代のDDR3は最高1.6GHzへ http://pc.watch.impress.co.jp/docs/2003/0704/kaigai001.htm (2003年7月11日) [Reported by 後藤 弘茂(Hiroshige Goto)]
【PC Watchホームページ】
|
|