Spartan3E+DDR2メモリで400Mbps
XILINXのSpartan3Eデータシートには、DDRメモリは333Mbpsまでと書かれていますが、400MHzでも安定して動作しました。
データシートに記載された333MHzという根拠がいまいちわかりません。
DDR2 SDRAM内(256Mbit)の全領域をLFSRで作った乱数で埋め、ユーザがボタンを押したときにそれを読み出して比較照合するというふうに検証しました。
DDR2を400MHzで動かすということは、FPGAは200MHzで動作しなければなりません。この速度はSpartan3Eには少々厳しいので、配置配線後のTiming Reportではいくつかタイミングエラーがいくつか起きています。しかしまあ、それでも運良く動作してしまうものなのですね。今回はインタフェースの速度を検証しているので、目をつむります。
次に、FPGAと外との最大インタフェース速度について考えてみます。
FPGAと基板上の部品と接続する際には、セットアップタイムやホールドタイムが必要になります。
Spratan3Eでは、外の信号に対しては合わせて最小で1.5ns～1.6nsくらい必要になります。クロックの位相はDCMを使えば自由自在にシフトできます。
したがって、FPGAに対して信号を送出しようとするICは、約1.6nsの間だけ有効なデータを出しておけば、あとはFPGAの中のサンプリングクロックの位相を合わせることで、正しく受信できてしまうはずです。
「1 I/O あたり 622+ Mbps のデータ転送速度」という根拠は、この1.6nsの逆数と思われます。
一方、FPGAの入力フリップフロップには遅延エレメントというのがあって、これを有効にすると、データ有効の窓が狭くなってしまいます。Spartan3Eの入力FF用遅延エレメントは、0～6までの7段階に調整することができます。
遅延の段数をいろいろ変えてみたところ、データ有効窓の幅はつぎのように変化しました。
IFD_DELAY_VALUE = 0; ・・・ 2.037ns
IFD_DELAY_VALUE = 1; ・・・ 2.209ns
IFD_DELAY_VALUE = 2; ・・・ 2.333ns
IFD_DELAY_VALUE = 3; ・・・ 2.822ns
IFD_DELAY_VALUE = 4; ・・・ 3.222ns
IFD_DELAY_VALUE = 5; ・・・ 3.984ns
IFD_DELAY_VALUE = 6; ・・・ 4.474ns
このように、遅延エレメントを増やすと、要求されるデータ有効窓が広くなります。それは最大受信可能データレートが下がることを意味します。遅延エレメントは単純に信号を遅らせるだけではないということが窺い知れます。
333MHzというのは、FPGAの内部クロック周波数の限界が166MHzあたりにあることに起因しているのではないかと思います。したがって、内部回路を工夫すれば、500MHzまではいけるのではないかと思っています。
どのように工夫をするかというと、
・FPGAの中の制御用ステートマシンは125MHzで動かします。
・制御信号(RAS、CAS、CS、WE、アドレス)は、ODDRを使って作ります。
・そのODDRは、表クロックでRASやCASなどの制御信号を出し、裏は常にNOPコマンドを出すようにODDRのD1入力を固定します。
・しがたって、コマンドはACT NOP NOP NOP RD NOP・・という具合に、2倍の周期で出ます。
・出力データはもちろんODDRを使って作りますが、このODDRは250MHzで動かし、しかもDCMを使って1/4クロック周期ほどタイミングを早めます。
・ODDRのD0とD1には、別々のブロックRAMからの出力をつないでおきます。なぜなら、D0とD1はサンプリングされるクロックの位相が180度違うので、それぞれ別のデータソースから出力することでクロックドメインの橋渡しをしなくて良くなり、高速動作が楽になると考えられるからです。
・ブロックRAM単体ならば250MHzで動かすのは難しくはないでしょう。
・IDDRも表と裏の2つの出力を別々のブロックRAMにつなぎ、入力したDQSを書き込み用クロックとするか、サンプリングポイントを決めうちにして取り込みます。
・バス幅の変換は、ブロックRAMの入出力ポートの幅を変えることで対処します。
というふうにすれば、FPGAの中の制御回路は125MHzで動き、データ信号だけは500MHzで動く、Spartan3E用のDDR2 SDRAMコントローラができるのではないかと思われます。ブロックRAMを4個も使ってしまうのがデメリットですが。
思いつきでアイデアだけを書いてみましたが、いつか暇ができたら試してみたいと思います。
| 固定リンク
コメント
IFD_DELAY_VALUEの値を見ると、Spartan3E Starter Kitよりも小さいので、スピードグレードは6ですか？
セットアップ＋ホールドの1.6nsに対して、200MHz動作だと、スルーレートを無視しても2.5nsですね。その狭いウインドウにIFD_DELAY_VALUEで調整されたのですね。もしかして、最初から配線遅延を計算されて、合わせ込んだのでしょうか？
記事のようにうまくいけばDDR2-500で行けるかもしれませんね。かなりFPGA内部の位置と配線遅延の考慮が重要となると思われます。
投稿: marsee | 2009.01.05 11:22
いいえ、スピードグレードは-4で、遅いほうです。
うっ・・でもISEでは-5で設計していました。
記事に書いたIFD_DELAY_VALUEの値は、セットアップ+ホールドタイムの値なので、それで少し違っているのかもしれません。
2.137nsの根拠はタイミングアナライザのレポートで、セットアップ+ホールド = 2.189 - 0.152nsと求めています。
Setup/Hold to clock xtalclk_ip
------------+------------+------------+------------------+--------+
| Setup to | Hold to | | Clock |
Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase |
------------+------------+------------+------------------+--------+
ddr2_d_bp<0>| 2.189(R)| -0.152(R)|clk | 0.000|
| 2.189(F)| -0.152(F)|clk | 0.000|
>狭いウインドウにIFD_DELAY_VALUEで調整されたのですね。もしかして、最初から配線遅延を計算されて、合わせ込んだのでしょうか？
400MHzの場合はIFD_DELAY_VALUE=0で、250MHzの場合はIFD_DELAY_VALUE=1でうまくいきました。
実は、両方とも偶然です。
後から計算してみたところ、この設定でぴったりと合っていたようです。
DDR2 SDRAMにおけるクロックエッジからデータ出力までの遅延はtACであらわされますが、今回使っている物は、MT47H32M8BP-37Eという533MHz物なので、最大で-500ps～+500psになります。したがって最悪の場合、データ有効窓が1nsも減ってしまいます。これが一番厳しいところではないかと思っています。
FPGAの種別を-4にして再度タイミングアナライザにかけてみたところ、有効窓の幅は2.410nsに減ってしまいました。
実際には、tACにこんなに誤差があるとは思えないので、有効窓のちょうど真ん中にあわせなくても動いてしまっているのだと思います。
タイミングチャートは次回の記事で書きます。
投稿: なひたふ | 2009.01.05 13:42
IFD_DELAY_VALUEの値はクロックからのセットアップ＋ホールドですね。了解しました。
tACもそうですが、DCMのジッタも結構あると思うので、DDR2-400が内部クロックで取れるとは、思ってませんでした。この後の情報を楽しみにしています。
投稿: marsee | 2009.01.05 21:18
仕様は保証値ですからある程度はCPUと同じようにメモリもオーバークロック出来るでしょうね
ただ個体差があるのですべてで400MHzで安定はしないと思います
投稿: 柊 | 2009.01.06 02:54
marseeさん
ジッタは考慮していませんでした。
よくよく計算してみると、若干オーバーしていました。
運良く動いているのかもしれませんね
柊さん
あけましておめでとうございます
今年もいろいろ試行錯誤していきたいと思います。
デバイスメーカーが言うタイミングの最大最小値は、個体差に加えて、規定の範囲での温度(0℃～85℃)で、電源電圧の変動(±1%とか)を加味した上での値だと思います。
電源や温度を安定させれば、動作中の変動は抑えられるかもしれません。
個々の個体差については、データ取り込みクロックの位相をDCMで動的に調整できるようにすれば、解決できそうです。
今回の400MHz動作は偶然なのかもしれませんが、個々のボードでキャリブレーションするという前提ならば、400MHzも不可能ではないかもしれませんね。
投稿: なひたふ | 2009.01.06 12:27