FC2カウンター FPGAの部屋 DQSをクロックとしてDQをリードするDDR2 SDRAMコントローラの再検討
FC2ブログ

FPGAやCPLDの話題やFPGA用のツールの話題などです。 マニアックです。 日記も書きます。

FPGAの部屋

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。Xilinx ISEの初心者の方には、FPGAリテラシーおよびチュートリアルのページをお勧めいたします。

DQSをクロックとしてDQをリードするDDR2 SDRAMコントローラの再検討

DQSをクロックとしてDQをリードするDDR2 SDRAMコントローラの初期化時に、トレーニング・シーケンスを行って、うまくリードデータが受かる遅延を探る方法を検討している。
今の計算では、FPGA内部や配線遅延を含めた総合的な遅延が6nsを超えるくらいなので、遅延を加えていっても、条件が悪くなるばかりのような気がする。
上のリンクの記事”DQSをクロックとしてDQをリードするDDR2 SDRAMコントローラの遅延の検討”から引用すると、
”これをFPGA動作クロックの270度で受けようとすると2クロック目で8.75ns となり、DQSクロックから270度クロックの乗せ変えのためのセットアップ時間として、8.75ns - 6.986ns = 1.764ns 見込めることになる。”
DQとDQSに遅延を加えていくと、この1.764nsの余裕がどんどんすくなるなるはず。。。

それから、このところ一番参考にしているXilinx社のアプリケーションノートXAPP721J、”ISERDES とOSERDESを使用した高性能DDR2 SDRAMインターフェイスのデー タキャプチャ”の9ページの遅延キャリブレーションフロー図の最初でDQSを2タップしか遅延していないがこれで大丈夫なのだろうか?
その前のページに”BUFIOとクロックリソースの伝搬遅延により 、 DQの遅延よりもDQS の遅延の方が大き く な り ます。”と書いてある。しかし、ISEのTiming AnalyzerでDQとDQSの.IOBDELAY_TYPE("FIXED"), .IOBDELAY_VALUE(0),のときの遅延値の比較は下の図のようになる。
DDR2_inquest_1_080905.png
これを見る限り、DQSのBUFIOの出力とDQ入力の遅延差は0.199ns、約200ps だ。それほど遅延差はないと思われる。
よって、Xilinx社のアプリケーションノートXAPP721JでDQより2タップしかDQSを遅延しないでうまく受かるのだろうか?ちょっと疑問?なぜだろう?
後はデータ・キャプチャ・ウインドウに入るようにDQとDQSの遅延タップを一緒に遅延させている。
しかしここまでやらないとスイートスポットが見つけられないのか?
ilinx社のアプリケーションノートXAPP721Jをみると、300MHz動作でジッタなどの不確定値が1.378ns もあり、ワーストケースのウインドウはたった289ps だそうだ。本当にこれで大丈夫なのだろうか?
それでトレーニングシーケンスでいろいろDQとDQSを一緒に細かく遅延させて受かるかどうかを確認しているようだ。
そういえばISERDESの内部のレジスタのセットアップ時間などのデータがデータシートに載っていない。clkはDQSが入っているし、OCLKとCLKDIVにはclk270度が入っているので、Timing Analyzerで解析できないはずなんだが、データシートに載っていないのでわからない。
とりあえず、今の状況でDQの遅延を加えていくと、ウインドウに入らない方向にいってしまうことが考えられる。実際に遅延値を変えながら、ちょっとやってみたんだが受からなかった。これを根本的に変えるには、ISERDESのOCLKとCLKDIVにクロック位相0度のclk を入れる必要がありそう。そうなると必然的にOSERDESの出力クロックもclk となるので、tDQSSをMAXに戻す必要が出てくる。
どうしようと思っていたが、お手軽にDQの入力遅延を約740ps 少なくできそうな方法を見つけた。

ここで、Virtex-4 FPGA Data Sheet:DC and Switching Characteristicsの28ページの表を見てみる。下にその一部を転載する。
DDR2_inquest_2_080905.png
上の表はISERDES Switching Characteristics の1部だ。データラインのセットアップとホールド時間をして示しているが、今はDDRモードを使用しているので、下のピンクで囲った部部になる。
現在は、緑で囲った部分を使用している。緑の部分の表で、最初の列が-12スピードグレードの遅延値、次の列が-11、最後の列が-10スピードグレードの遅延値だ。今使用しているVirtex4は-10 スピードグレードなので、右端の遅延値ということになる。これをみると.IOBDELAY_TYPE("FIXED") の時のセットアップタイムは1.08ns になる。これはTiming Analyzerのデータ遅延の一番下の値と符合している。
よって、.IOBDELAY_TYPE("NONE") にすれば約740ps 遅延が短くなるはず。。。(実際には.IOBDELAY("IFD"), を.IOBDELAY("NONE"), にしました)
そこでやってみたのが下の図。
DDR2_inquest_3_080905.png
DQをサンプルする入力用FFのセットアップタイムが1.08ns から0.335ns へ短縮されている。これは入力用遅延素子をバイパスしているためだろう。
これで、DQSクロックの遅延(3.107ns) - DQの遅延(2.163ns) = 0.994ns。DQとDQSの遅延の差はクロック周期(5ns)の1/4 (1.25ns) にしてみるとして(DDRで両エッジでデータをサンプルするから)、(1250- 994)/75 = 3.4 よって、3タップ遅延を入れることとする。
これでインプリメントしてどうなるか見てみることにした。

2008/09/07:追記:手動で確かめたところ動作しました。ですが、チップスコープの試用期限が過ぎたので、その後が確かめられません。
  1. 2008年09月06日 06:24 |
  2. DDR SDRAMコントローラ
  3. | トラックバック:0
  4. | コメント:0

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック URL
https://marsee101.blog.fc2.com/tb.php/876-715aec9c
この記事にトラックバックする(FC2ブログユーザー)