Spartan3A Starter KitのDDR2 SDRAMコントローラの途中経過６（DCMやBUFGの配置）

前回の”Spartan3A Starter KitのDDR2 SDRAMコントローラの途中経過５（ロジックセルの固定の微調整）”でデータパスの遅延調整は終了したので、今度はクロックパスの遅延を調整する。

クロックのIOB(Input Output Block) からBUFGへのネットの遅延はDQS0が3.141ns、DQS1が1.988ns。このSpartan3A-700には、８つのBUFG、４つのDCMがある。そのうちの1/2づつ、FPGAチップの上の真ん中と下の真ん中に配置されている。DQS0は下のBUFGに接続され、DQS1は上のBUFGに接続されている。下図参照。DQS1が見にくいけど青色の線、DQS0が赤色の線。


BUFGはDCM用に３つ、DQS0とDQS1で１つずつ使っているので、５個使用している。あと、BUFGを使う予定は、50MHzをDCMで４倍にして200MHzにする必要があるからCLK0とCLKFXにBUFGを入れる必要があるので、最低２個は必要だが、このFPGAには24個のBUFGがあるので、まだ余裕。
それにシステムクロックの位置をまだ固定していなかったので、固定しながら最適な位置を探ることにする。それにBUFGの位置をFPGAチップの左側に変更しようと思う。
まずは、BUFGの位置を固定しよう。今回はクロスプロービングしないので、Floorplan EditorでBUFGの位置を固定してみる。ProcessesウインドウのUser Constrainsを展開してFloorplan Area / IO / Logic - Post - Synthesis をダブルクリックして、Floorplan Editorを起動する。
左側の真ん中付近を"Zoom to Box"アイコンをクリックして矩形選択してズームすると、BUFG（BUFGMUX)が８個見える。一番上とその下のBUFGにDQS0とDQS1をアサインしてみる。
右上のSourcesウインドウのddr2_cont_iob_instを展開して下のほうを見るとDQS用のBUFGが２つ見える。


それを右側のウインドウにドラックアンドドロップする。


これでセーブした。そうすると下に書いた制約がUCFファイルに追加された。
I

NST "ddr2_cont_iob_inst/DQS_CLK_BUFG_INST[0].BUFG_inst" LOC = BUFGMUX_X0Y3;
INST "ddr2_cont_iob_inst/DQS_CLK_BUFG_INST[1].BUFG_inst" LOC = BUFGMUX_X0Y2;

後はシステムクロックの入力パッドの指定だが、スタータキットのユーザーズマニュアルにUCFがあるので、UCFファイルに直接記述した。

NET "sysclk" LOC = "E12"| IOSTANDARD = LVCMOS33 ;

これで再度インプリメント。
DQ0が1.145ns、DQ1が1.631nsとなった。Floorplan Editorで見てみると下図のようになった。


紫色の線がDQ1、赤の線がDQ0を表している。
これでデータ、クロックのネット双方ともOKになったので、IOBの遅延を加えることにする。
現在の遅延値を見てみる。まずはDQS0クロックのほうからDQ0のクロック遅延とデータ遅延を見てみると、


クロックの遅延が3.377ns、データの遅延が2.005nsとなり、その差が1.372nsとなっている。ここで下のタイミングチャートを参照するとわかるが、DQSとDQは同位相なので、この差はちょうど良い値になっている。このままでOKのようだ。


同じDQS0をクロックとして使用するDQ1～DQ7までの値を見ていくと、1.332ns、1.232ns程度だった。DQ7で1.232nsなので、遅延をはさまないで、このままで行くことにする。

次にDQS1クロックの方だが、DQ8のクロックの遅延が3.957ns、データの遅延が2.075nsなので、その差は1.882ns。ちょっと差が大きいか？
FPGA Editorを使用して、DQ8のIOBのIBUF_DELAYをDLY1にしてみた。（やり方は、”ISE10.1のFPGA EditorでIOBやSLICEのパラメータを変更”を参照）
そうするとDQ8のデータの遅延は3.032ns となった。その差は0.925ns。ちょっと差が少ないかと思うけど、大丈夫かな？
Spartan3Aのデータシートをみると、CLB分散RAMのスイッチ特性で一番大きいのはTws（分散RAMのCLK入力のアクティブエッジまでに、ライトイネーブル入力が安定していなければならない時間）で-4スピードグレードで0.59ns となっているので、大丈夫そう。しかもこれは、ライトイネーブルなので、データとは関係がなく、SD_LOOP_INからのライトイネーブルに関係している信号だ。
次に、今は暫定的にFPGA EditorでIBUF_DELAYをDLY1にしたが、今度はUCFファイルに制約を書いてDQ8～DQ15までのIBUF_DELAYをDLY1にすることにする。

NET "ddr2_dq<8>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<9>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<10>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<11>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<12>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<13>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<14>" IBUF_DELAY_VALUE = 1;
NET "ddr2_dq<15>" IBUF_DELAY_VALUE = 1;

これでインプリメントしてみると、ロジックだけで遅延が制約を超えているので、インプリメントできないというエラーが出てしまった。クロックとデータの位相が同じ状態なので、DQのタイミング制約を変更することにする
しかし、どうセットアップ時間を変えてもエラーが出てしまう。エラーを検索したところ、”19014 - 9.1i - 「ERROR:Pack: 1653 - PAR: At least one timing constraint is impossible to meet because component delays alone exceed the constraint.」というエラー メッセージが表示される”を見つけたので、それに従って、Mapのタイミング解析で解析。どうやらセットアップ時間でなくてホールド時間がだめのようなので、VALID時間も5nsに変更した。
実際の制約はこうすることにした。

NET "ddr2_dq<0>" OFFSET = IN 1.5 ns VALID 5 ns BEFORE "ddr2_dqs<0>" RISING;
NET "ddr2_dq<0>" OFFSET = IN 1.5 ns VALID 5 ns BEFORE "ddr2_dqs<0>" FALLING;

これでやっとPlace & Routeが通った。
DQ8～DQ15にIBUF_DELAY_VALUE=1を入れた結果は、最少のセットアップ時間がDQ14の0.855ns なので、大丈夫だと思う。DQとDQSの遅延関係については、このタイミングで行くことにする。