FPGAの部屋

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

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。ご利用ください。 http://marsee101.web.fc2.com/index.html

2009年03月

”Spartan3A Starter KitのDDR2 SDRAMコントローラの途中経過4(ロジックセルを固定する)”でロジックセルを固定したが、微妙な遅延差が残った。今回は微妙な遅延差の解消を目指す。

まずはIOBから非同期FIFOまでのネットが約0.4ns のDQ0と同じく0.7ns のDQ1の違いを考察することにする。まずはDQ0から下の図にFPGA Editorで見たIOBから非同期FIFOまでのネットを示す。
c4aefcf8.png


DQ0はIOBと非同期FIFOのロジックが同じ行にある。IOBから最初につながっているスライス(フロアプランの位置で言うとX0Y62)と次のスライス(X2Y63)はX方向(行方向)が異なっているが、遅延の差は5ps だった(0.405ns と0.410ns)。
次にDQ1を見てみよう。下にDQ1のにFPGA Editorで見たIOBから非同期FIFOまでのネットを示す。
a4ad43c4.png


これはIOBとスライスの列方向の位置が違っている。この遅延はどちらのスライスも0.700ns と大きい。やはり列方向に配線するのに遅延が大きくなっているのだろうか?なるべく、列方向が異なる配置にならないようにもう一度Floorplannerで配置をやり直すことにする。
もう一度、Floorplannerを立ち上げてよく見てみると、IOBとスライスの間が2重線でつながれているところがある。そこが列が違うところのようだった。
Spa3A_DDR2_27_090325.png

2重線をネットがまたがないように位置を並べ替えた。そして、この状態でインプリメントし、Timinig Analyzerで見たところ、IOBから非同期FIFOまでのネットの遅延が0.7ns程度のものがある。どうやら区画の上側のIOパッドから、その区画のSLICEM(分散RAMになるのはSLICEMのみです)に行くネットの遅延が大きいようだ。下にDQ1のネットを示す。0.7ns程度の遅延だ(ピンクの四角の部分)。
854e0daf.png


これは困った。スイッチファブリックのスイッチルートが悪いのだろうか?
更に、区画内の上側のIOパッドから少ない遅延時間で接続できるSLICEM(非同期FIFOの入り口のロジックセル)を探してみることにした。その結果、上の区画のX0の位置の2つのSLICEMに接続すれば0.481ns の遅延で接続できることがわかった。
52c402c0.png


この結果、区画の下側のIOパッドは同じ区画のSLICEMに接続すれば遅延が少なく、区画の上側のIOパッドは上の区画のX0の2つのSLICEMに接続すればやはり遅延が少ないことがわかった。
上の法則にしたがって、さらにもう一度Floorplannerで配置をやり直す。
これでインプリメントしたら失敗してしまった。FPGA Editorで見たIOパッドの位置とFloorplannerで見た区画内のIOパッドの位置は逆のようだ。それを考慮して、Floorplannerで逆に配置する。
実際には下の図のように配置した。
Spa3A_DDR2_30_090330.png

これでIOパッド(IOB)から非同期FIFOまでのネットの遅延は0.401ns、0.411ns と0.481ns になったが、DQ7のネットのみ、ロングライン配線の通っている(横切っている)数が多いようで、間が広いようだった?そのため遅延が0.543ns と多くなってしまった。それでも、最大遅延と最小遅延の差は142ps になった。これはこの辺でいいだろうというか、これ以上改善は難しいと思う。

”Spartan3A Starter KitのDDR2 SDRAMコントローラの途中経過3(フロアプランを試す)”でフロアプランのエリア制約をかけてみたところ、IOパッドから分散RAM使用のFIFOの入り口までのネットの遅延がばらばらという問題があった。これを入り口のロジックセルを狙い撃ちして位置を固定することで遅延の短縮ならびに、平均化を図ることにする。

現在のISEのバージョンは10.1SP3。
まずはProject Navigater のProcessesウインドウのImplement Design -> Place & Route -> View/Edit Placed Design (Floorplanner) をダブルクリックする。
Spa3A_DDR2_16_090325.png

Floorplannerが立ち上がる。エラーの嵐。どうやらRISINGやFALLINGなどの新しいキーワードが入った制約はエラーになるようだ。どうもXilinxのツールはツール同士の互換性が取れていない場合が多い気がする。本当はこの辺は無料版でないISEにバンドルされているPlanAheadでやるという予定になっているのかもしれない?
576ee80b.png


とりあえずエラーをすべて無視すれば、Floorplannerが使えるようになった。
8971038f.png


Floorplannerはエラーがでるので、FPGA Ediotrとかでロジックセルを固定してもいいのだが、どのロジックセルがIOパッドからつながっているかが良くわからない。Timing Analyzerのインスタンス名とFPGA Editorのコンポーネント名が微妙に違っている見たいなので、エラーがでても、わかりやすいFloorplannerからやることにした。インプリメントが終了した時点でFloorplannerを起動すると、インプリメントされたロジックセルの位置を表示するウインドウ(上の図ですでに開いている右側のウインドウ)と、制約ファイルに反映させるためにロジックセルをフロアプランし固定するためのUCF Flowのウインドウが開く(いずれも右側のウインドウで、右側のウインドウの上にウインドウの上の部分だけが表示されている)
この辺は、私のブログの”Floorplannerの使い方”を参照。
昔のISEでは、Timing AnalyzerからFloorplannerを呼べて、選択したルートはFloorplanner上で選択され、どのように接続されているかがわかったのだけれど(Crossprobeができた)、しょうがない。あれれ、もしかしてTiming Analyzerを単体で立ち上げると、まだそれができたりするのかな?
やってみることにする。Floorplannerを閉じて、Windowsメニューから、Xilinx Design Suite 10.1 -> ISE-> Timing Analyzer を選択して、Timing Analyzer を立ち上げる。そうするとダイアログが出てくる。
Spa3A_DDR2_18_090325.png

ここで、一度、ISE project file に現在のプロジェクトを入力したらISEごともう1つ立ち上がってしまった。失敗。。。ダイアログの項目は何も入力しないでOKボタンをクリックすると、以前のTiming Analyzerが立ち上がる。
e628a32e.png


FileメニューからOpen Design... を選択して、Open Design ダイアログを開いて、Designファイルを選択するとPhysical Constraints Fileも選択されるはず。これでOKボタンをクリックしよう。
Spa3A_DDR2_20_090325.png

Analyze against Timing Constraints アイコンをクリックして、タイミング制約を解析する。
8ada3ef6.png


解析できたら、”Floorplannerの使い方覚書1”を参考にFloorplannerでCrossprobingしよう。CrossprobingするとFloorplannerが立ち上がる。パスを選択するとインスタンスとネットが選択された状態でFloorplannerで見えるんだけど、なぜか制約で位置を固定したIOBが見えないので、この方法は使えない。その代わり、分散RAMを使用したFIFOの入り口のインスタンスをTiming Analyzerでクリックし、Floorplanner上でも選択させて、UCF Flow にコピーする。
269b14f9.png


UCF Flow を見ると今選択したインスタンスがコピーされている。
acd8b61a.png


このロジックセルは近くに配置されていて、これで良いような気もするが、ドラックアンドドロップで更に近くに配置する。これをすべてのDQに対して行っていく。下がDQ15までに行った結果。
8c522d35.png


これでセーブしたところ、また大量にエラーが出てしまった。エラーがでたRISING, FALLINGなどのキーワードが入った制約はなくなってしまったので、あらかじめセーブしておいたバックアップを戻して、Floorplannerで書き加えた以下のような制約を追加した。

INST "rddata_afifo_inst/RDDATA_AFIFO_FALL[3].DQS2intclk_FIFO_FALL/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM8" LOC = "SLICE_X2Y78" ;


これでもう一度インプリメントしてみた。Timing Analyzerの結果を見ると、IOBから分散RAM使用、非同期FIFOまでのネットの遅延は0.401ns ~ 0.969ns となった。その差、0.568ns と少なくなったが、もう少し調整する必要がありそうだ。もう少し追い込んでみたい。

2009/03/30 追記:
3つのロジックセルを配置するのを忘れていた。全部配置したら、IOBから非同期FIFOまでのネットが0.4ns ~ 0.7ns に収まった。約300ps 位の差、もう少し調整してみたい。

ニコニコ動画でNT京都の撮影できますPさんとアルテラマスターPさんのプレゼンの動画があった。
撮影できますPさんのほうはFPGAでオールハードウェアの実装。アルテラマスターPさんのほうはNiosで動画用の命令をカスタマイズしての実装。どちらもすばらしい。。。
私も静止画だけど、画像関係をやるので、参考にさせていただこうと思う。
アルテラマスターPさんの”FPGAは己を映す鏡”という言葉が印象に残った。確かにFPGAは真っ白なキャンバスに自分の考えを描いていくので、自分を写しているのかもしれない。(IPとかはありますけどね。。。)
私はあまり何を作りたいという強い欲求がない。。。年を取ったということかな???
まあ、FPGAを良く知りたいという欲求が強いし、FPGA1チップでマイコンシステムを作ってみたいという欲求もある。
FPGAを知って、いろんなものをFPGAで作る仲間が増えてくれれば良いな?と思っている。今回の動画のように自分の知らないことを教えて欲しい。その代わりといっては何だが、細々とFPGAの情報を発信して行こうと思う。





撮影できますPさんのブログには、今回のプレゼンのスライドへのリンクもあった。

しかし、ブログを書きながらやっているので、なかなかSpartan3A Starter KitのDDR2 SDRAMコントローラも進まないが、記録を残しておくことに意義があると思っている。

前回、”Spartan3A Starter KitのDDR2 SDRAMコントローラの途中経過2(DQSからBUFGをまわしたクロック)”で、お任せでインプリメントをしてみたが、遅延がばらついてしまった。それで今回はFloorplan Editorでエリア制約を試してみることにした。
まずは”ISE10.1iのFloorplan Editorでエリア制約”を参考にPrpcessesウインドウのUser Constrains -> Floorplan Area / IO / Logic - Post-Synthesis をダブルクリックしてフロアプランする。下図の赤いエリアにrddata_afifo_instを配置した。その下のRDDATA_AFIFO_FALL[2].DQS2intclk_FIFO_FALLなどを配置しようとしたが配置できなかった。
32e213cf.png


フロアプランをセーブすると、制約(UCF)ファイルに以下のフロアプラン(エリア制約)が追加された。
I

INST "rddata_afifo_inst" AREA_GROUP = "AG_rddata_afifo_inst";
AREA_GROUP "AG_rddata_afifo_inst" RANGE = SLICE_X9Y48:SLICE_X0Y79;


これで、もう一度インプリメントして、Timing Analyzerの結果を見てみよう。下がDQ0の入力の結果だ。
c6619356.png


その結果、FIFOに行くまでのデータのネット(dq_data<0>) は、7.774ns から0.761ns となり劇的に短くなった。下がそのFloorplan Editorでの配線ルートの図だ。
c9f7a568.png


緑の始点から赤の終点まで配線が非常に短いことがわかる。更に、上でフロアプランされた範囲にロジックが配置されていることがわかる。
次にDQSのクロックのパスだが、上のTiming Analyzer の画面を見ると、3.139ns から2.223ns に短縮されている。クロックのパスを同様にFloorplan Editorでの配線ルートの図を下に示す。
d9b15410.png


チップの上側のBUFGを使っている。こちらの方がBUFGに入るまでの遅延が少ないようだ。DQの上半分のBUFGに入るまでのクロックパスの遅延は1.998ns なので、DQの下半分のBUFGに入るまでのクロックパスの遅延との差は0.225nsとなった。この辺でBUFGは固定したほうが良さそうだ。

次にDQ9の結果を見ていこう。同様にTiming Analyzerの結果を見てみると、
66c2d469.png


FIFOに行くまでのデータのネット(dq_data<9>) は、5.544ns から1.761ns と大きく低減された。BUFGに入るまでのクロックパスの遅延dq_clk_node<1>は1.998nsで変わらない。FIFOに行くまでのデータのネットをFloorplan Editorで見てみよう。
1cf192ed.png


だいぶ短いが、DQ0との差が大きい。
今回はRISINGしか見ていないが、FALLINGがわもあるし、更にばらついている可能性もある。すべてのDQを見てみたところ、FIFOに行くまでのデータのネット(dq_data)は最長がDQ12のRISINGで3.086ns、最短がDQ5のFALLINGで0.436nsだった。遅延の差は2.65nsもある。最長のDQ12のRISINGのFloorplan Editorのルート図を下に示す。
9d0d8c2d.png


これだけ差があっては使えないので、今度はFloorplannerでFIFOの入力素子の位置を固定することにする。

”Spartan3A Starter KitのDDR2 SDRAMコントローラの途中経過1”でエラーが解消できたのでDQSをクロックとして使用してグローバルクロックバッファ (BUFG) にまわして、そのクロックをLUTをFIFOとして使った分散RAMを使用した非同期FIFOのクロックとして使ってみた。
たぶん問題としては、DQSはBUFGの専用入力を使用していないので、BUFGに行くまでのネットの遅延が大きくなることが予想される。DQSは2本あるので、DQが8本ごとに1本のDQSをクロックとして使用してデータをサンプルする予定だ。ここで問題なのは、BUFGの位置が決まっているためにDQSごとにBUFGに行く遅延が異なるのではという懸念がある。

さて実際にやってみた結果を検証してみよう。はじめに制約はまだいい加減で、必要な制約もまだまだ足りない。その状態で、どのようなインプリメントになるのかを見ていこう。
下がDQ0のタイミング解析結果だ。ピンクの枠で囲ったのが、DQS0のIOパッドからBUFGまでのネットの遅延で、3.139nsかかっている。かなり遅延している。黄色の枠で囲ったDQ0のIOパッドから分散RAMを使用した非同期FIFOに入る部分の遅延が7.774nsとかなり遅延がある。
7b347600.png


次に、DQS0のIOパッドからBUFGまでのネットをFPGA Editorで見てみよう。FPGA Editorで表示したDQS0のIOパッドからBUFGまでのネットを下に示す。
eb3428f4.png


次にDQ9のTiming Analyzerの解析結果を見てみよう。DQ9のクロックリソースはDQS1であるので、DQ0とは違っているはずだ。
下の図で、ピンクの枠で囲ったのが、DQS0のIOパッドからBUFGまでのネットの遅延で、1.988nsかかっている。かなり遅延している。DQ0のIOパッドから分散RAM使用FIFOに入る部分の遅延が5.544nsだった。DQ0と比べるとDQSのIOパッドからBUFGまでのネットの遅延は1.988ns - 3.139ns = -1.151nsの差があり、DQのIOパッドから分散RAM使用FIFOに入る部分の遅延は5.544ns - 7.774ns = -2.230ns の差がある。かなり大きな差となっていると思う。
b1f01a62.png


FPGA Editorで表示したDQS1のIOパッドからBUFGまでのネットを下に示す。
55b5e900.png


DQS0はFPGAチップの下のBUFGを使っているが、DQS1は上のBUFGを使っている。このようなところにBUFGまでにネットの遅延時間の差が出ていると思う。
とりあえずこれでは使えないので、2つのBUFGがどちらもチップの上の配線遅延が少ないBUFGを使うように位置を固定しようと思う。次に”ISE10.1iのFloorplan Editorでエリア制約”を参考にフロアプランをすることにしようと思う。

↑このページのトップヘ