MIGで使用されている制約

MIGで生成したDDR2 SDRAMコントローラの制約ファイル（UCFファイル）を見ると知らなかった制約を使ったあったので、勉強してみることにする。制約ガイドを参照。（現在、Xilinx社の制約ガイドへのリンクが切れているようです）

まずは、RLOCとU_SET。MIGが生成したUCFファイルの一部を引用する。

INST "infrastructure_top0/cal_top0/tap_dly0/l0" RLOC=X0Y6;
INST "infrastructure_top0/cal_top0/tap_dly0/l0" U_SET = delay_calibration_chain;

RLOC（相対配置制約、原点に対して相対的に位置を指定する。RLOC_ORIGNで原点を指定する）は知っていたのだが、U_SETは知らなかった。U_SETは制約ガイドによると、

デザイン階層全体に分散されているデザインエレメントに RLOC 制約を設定し、1 つの集合にグループ化できるようにします。

ということなので、delay_calibration_chainというグループにグループ化していることになる。

次に、FROM TO制約の場合のDATAPATHONLY。下にMIGが生成したUCFファイルの一部を引用する。

TIMESPEC "TS_CLK" = FROM "clk0" TO "dqs_clk" 18 ns DATAPATHONLY;

ISE13.1のタイミング制約ユーザーガイドの115,116ページの一部を引用する。

FROM:TO (マルチサ イ ク ル) 制約の解析には、ソースと デステ ィネーション同期エレメント間のクロックスキューが含まれます。クロックスキーは、デスティネーション同期エレメントへのクロックパスからソース同期エレメントへのクロックパスの値を引いて計算されます。クロックスキー解析は、制約の付けられたすべてのクロック に対して自動的に実行されます。 解析には、すべてのデバイスファミリでセットアップ解析、 Virtex-5以降のデバ イ ス の場合はセットアップ とホールド解析の両方が含まれます。FROM:TO制約のクロックスキューを 無視す る 場合は、DATAPATHONLY キーワー ド を使用し ます。
DATAPATHONLY では、解析中にFROM:TO 制約でクロックスキューや位相情報が考慮されないように指定できます。こ のキーワードを使用すると 、データパスのみが解析されます。

DATAPATHONLYを付けると、クロックスキューなどを無視して、データパスのみを解析するそうだ。しかし、Virtex-5以下は新しいバージョンのISEでもホールドの解析はされていないんだったか？確認してみよう。

DIFF_SSTL18_IIという差動のSSTL18の制約があったのか？自分でもこれを指定しておけば良かった。

NET "cntrl0_ddr2_dqs[*]" IOSTANDARD = DIFF_SSTL18_II;
NET "cntrl0_ddr2_dqs_n[*]" IOSTANDARD = DIFF_SSTL18_II;

でも、Spartan-3A Starter Kitのユーザーガイドの117ページでは、DIFF_SSTL18_IIは使っていない。SSTL18_IIを使用している。

BEL、これは知っていたが、書いておく。

INST "top_00/data_path0/data_read_controller0/gen_delay[0].dqs_delay_col0/six" LOC = SLICE_X3Y6;
INST "top_00/data_path0/data_read_controller0/gen_delay[0].dqs_delay_col0/six" BEL = G;

Spartan-3Aでは、スライスに2つのFFが入っている。これをFとGと呼んでいる。これは、FPGA Editorでスライスをダブルクリックして、F=ボタンをクリックしてみるとよくわかると思う。下にその図を示す。


つまり上の制約は、"top_00/data_path0/data_read_controller0/gen_delay[0].dqs_delay_col0/six"というインスタンスがSLICE_X3Y6のスライスの下側のGのFFに割り当てられることを示している。

クロックネット同士のTIG制約

OV9655を使用したCMOSカメラ回路をインプリントしていると、タイミングエラーが出てしまった。


この内容を見てみる。下図参照。


VGA_Display_Controller用のクロックとDDR2 SDRAMコントローラのクロックにタイミング違反がある。VGA_Display_Controller用のクロックの違反の中身を見てみる。


Source はDDR2 SDRAMコントローラのinitialize_endで初期化が終わったという信号で、これは初期化が終了したらずーと1になる信号だ。Destination はreset_vga_node1でこの信号を生成するためにinitialize_endを使用している。このようなステーブルな信号では、タイミング違反があっても問題がないので、このパスはタイミングを無視するという制約を付加する。ほかのタイミングエラーも同様な箇所だった。
”UCFの書き方3”クロック出力ピンをグループ化して、それ同士のタイミング解析を無視する制約をかけた。今回は、クロックネットをグループ化してタイミング解析を無視する制約をかける。それが下の制約だ。（UCFファイルの一部）

NET "clk_vga" TNM_NET = TMN_CLK_VGA;
NET "clk_ddr2" TNM_NET = TMN_CLK_DDR2;
TIMESPEC TS_CLK_DDR2_to_VGA = FROM "TMN_CLK_DDR2" TO "TMN_CLK_VGA" TIG;
TIMESPEC TS_CLK_VGA_to_DDR2 = FROM "TMN_CLK_VGA" TO "TMN_CLK_DDR2" TIG;

clk_vgaをTMN_CLK_VGAにグループ化、clk_ddr2をTMN_CLK_DDR2にグループ化してして、それぞれのグループ同士のタイミング解析を無視する（TIG制約）。

これでインプリントしてみた。タイミング違反は無くなった。


最後に、先ほどの制約に相当するPCFファイルの一部を下に示す。

PATH TS_CLK_DDR2_to_VGA_path = FROM TIMEGRP "TMN_CLK_DDR2" TO TIMEGRP
"TMN_CLK_VGA";
PATH "TS_CLK_DDR2_to_VGA_path" TIG;
PATH TS_CLK_VGA_to_DDR2_path = FROM TIMEGRP "TMN_CLK_VGA" TO TIMEGRP
"TMN_CLK_DDR2";
PATH "TS_CLK_VGA_to_DDR2_path" TIG;

TIMEGRP TMN_CLK_DDR2 = BEL "reset_ddr2_node1" BEL "reset_ddr2" BEL
"camc_afifo_uf" BEL "vgadc_afifo_of" BEL
"VGAD_Cntrller_inst/cs_rdg_FSM_FFd1" BEL
"VGAD_Cntrller_inst/read_count_1" BEL
"VGAD_Cntrller_inst/read_count_2" BEL
...

TIMEGRP TMN_CLK_VGA = BEL "reset_vga_node1" BEL "reset_vga" BEL
"VGAD_Cntrller_inst/RGBX_0" BEL "VGAD_Cntrller_inst/RGBX_1" BEL
"VGAD_Cntrller_inst/RGBX_3" BEL "VGAD_Cntrller_inst/RGBX_4" BEL
"VGAD_Cntrller_inst/RGBX_5" BEL "VGAD_Cntrller_inst/RGBX_6" BEL
"VGAD_Cntrller_inst/RGBX_9" BEL "VGAD_Cntrller_inst/RGBX_10" BEL
...

（追加）
reset_vga_node1の後ろの回路を追加しておきます。

    //reset_vga の処理
    always @(posedge clk_vga, posedge dcmv_out_reset) begin
        if (dcmv_out_reset) begin
            reset_vga_node1 <= 1'b1;
            reset_vga <= 1'b1;
        end else begin
            reset_vga_node1 <= ~dcm_vga_locked | ~ddr2_initialize_end; 
            reset_vga <= reset_vga_node1;
        end
    end

reset_vga_node1の入力は、DCMのロック信号とDDR2 SDRAMの初期化信号を反転しています。reset_vga_node1でclk_vgaで同期化して、それをもう一度clk_vgaで同期化してVGA_Display_Controller のリセット信号(reset_vga)として使っています。1クロック以上メタステーブル状態にならなければ大丈夫だと思います。
今までのところ問題ないです。

PERIOD制約のDCMでの伝搬

PERIOD制約を入力クロックに対して書いておくと、派生したクロックもその倍率によって制約がかかるというのは知っていたのだが、それぞれのクロックを使ったFF同士のデータ間の制約については確認したことがなかった。今回、ISE11の制約ガイドで確かめてみた。制約ガイドUG625(v11.4) 2009年12月2日の58ページの”関連するDCM/PLL/MMCM ドメイン(自動)”に書いてある。
その概要を下に引用する。

最もよくあるクロック回路では、入力クロックがDCM/PLL/MMCM に使用され、出力がデバイスの同期パスのクロックに
使用されています。この場合、DCM/PLL/MMCM への入力クロックにPERIOD 制約を定義することをお勧めします。
この入力クロックにPERIOD 制約を付けると、ザイリンクスツールは各DCM/PLL/MMCM 出力クロックに対して新しい
PERIOD 制約を自動的に作成し、出力クロックドメイン間のクロック関係を決定し、これらの同期ドメイン間のパスをす
べて解析します。

図も引用する。この図を見ると一目瞭然。


CLK1Xで動作するFFからCLK2Xで動作するFFのデータパスも、CLKINのPERIOD制約を与えておけば、解析されるはず。良かった。
さてそれでは実際の回路で検証してみることにする。
CMOSカメラからディスプレイ出力回路で、SRAMのWEは48MHzクロックで出力している。24MHzクロックのFFの出力を使用して48MHzのクロック動作のFFで受けている。24MHzクロックにPRIOD制約が掛けてあって、DCMのCLK2Xで48MHzを出力している。下がそのパスのセットアップ時間の解析結果。


上のピンクの四角がソースクロックとディスティネーション・クロック。cam_pclkが24MHzでclk48が48MHzクロックだ。下のClock Path Skewを見ると、1.789 - 5.266 = -3.477ns となっている。他の静的タイミングを見るとcam_pclk の遅延が5.266nsだった。多分、clk48のクロック遅延が1.789ns だと思う。これで、セットアップ時間にクロックスキューが換算されている事がわかった。

REFERENCE_PIN制約

ISE10.1SP3でConstraint Editorを使っていて、Clock to Padを設定しようとしていたら、


こんなダイアログが開いた。


REFERENCE_PINが設定できる。。。しかも自分でIOBのDDRレジスタで生成したTxClkからの制約ができるのか？これは、使えればとても良い。
REFERENCE_PINで検索すると”ISE Design Suite 10.1 の新機能 ”が見つかり、そこには”OFFSET OUT 制約で REFERENCE_PIN キーワードがサポートされるようになり、ソース同期インターフェイスのバス ベース出力スキューのレポートが向上しました。 ”と書いてあった。
早速、REFERENCE_PIN制約を書いてみた。

NET "sd_dq<0>" OFFSET = OUT AFTER "clk" REFERENCE_PIN "sd_ck_p" RISING;
NET "sd_dq<0>" OFFSET = OUT AFTER "clk" REFERENCE_PIN "sd_ck_p" FALLING;

これは、制約ガイドによると、” OFFSET OUT AFTER 値を指定し ないで、 レポー ト のみの制約を生成”するそうだ。
そして、インプリメントしてTiming Analyzerで見てみた。



なんか普通にタイミング解析しているみたい？別にREFERENCE_PINに対して、どの位ずれているとかのリポートがないようだ。
このREFERENCE_PIN制約に関して情報をお持ちの方はよろしければ教えてください。

UCFを書く方法はいろいろあります

アクセスログを見ていると”UCFの書き方”を見ていただいている方が多いようだ。
カテゴリの”UCFの書き方”はあくまでどのようにUCFファイルが書かれているかやConstraints Editorに着目しているのだが、他にもUCFを書き換えるツールはまだある。たとえばPACEやFloorplanner、FPGA EditorでもUCFを書くことができる。将来的にはFloorplan Editorに統一されていくようだ。
UCFを手で書くとすると結構大変だ。パッド位置の指定やIOBのDELAYの指定は手で書いても問題ない。しかし、”UCFの書き方3”のPINの指定はTiming Analyzer のAnalyze against Users Paths by defining Endpoint ダイアログを開いて Pins のところを展開してインスタンスを見ないと正確なパスの指定がよくわからない。


それでもPINを指定して制約をかけても無視されることもあるのが、よくわからないところだ。

UCFで配線を固定できるが、それはFPGA Editorを使わないとほとんど不可能だろう。手で配線を固定できる人はXilinx社のツールを作っている人のほかには、たぶんいないんじゃないだろうか？　その方法は”FPGA　Editorで配置と配線を割り当てる３”や”FPGA内の配線を固定する”で解説した。

ISE9およびISE8では、PACEとFloorplanner両方でエリア制約やパッド位置の指定ができるが、統一が取れていないので、片方で制約をかけた後にもう片方でもう一度制約すると２重に制約がかかれることがある。このへんが統一が取れていないところだ。ISE10ではまだ良く調べていないが、Floorplannerがあるので多分そうなのだろう。早く統一してもらいたいものだ。

というわけでUCF書きたい方は”UCFの書き方”だけではなく、”PACEの使い方”や”Floorplannerの使い方”、”FPGA Editorの使い方”も見てください。

ちょっと古めのものもあるのだが。。。DDR2 SDRAMコントローラが終了したら、ISE10.1iで書き直してみようかな。。。

VALID制約

きじばと日記のPV4／FPGA回路更新を予告で”ハイビジョンキャプチャカード「PV4」が主に Core 2 Duo 環境で認識されない問題について、FPGA回路更新を計画しているようです。”という記事があった。
これは、インプレスのAKIBA PC Hotline!の記事でもおなじみのカードらしい。
きじばと日記さんの有限会社アースソフトさんのリンクから飛ぶと、リリース番号:02というタイミングレポートがあった。これをみるとPCIバスのパリティ出力回路にバグがあったようだ。
これを精査してみると、いろいろ興味深いのだが、ここでいろいろ書くのはまずいと思われる。ただ、VALID制約を書いたことがなかったので、調べてみた。
その結果、制約ガイドの71ページに良く書いてあった。
それは入力用DDRレジスタを使った例で、RISINGエッジやFALLINGエッジをTIMEGRPでグループ化して制約をかけていた。下のように。（詳しくは制約ガイドを見てください）

TIMEGRP DATA_IN OFFSET = IN 1 VALID 3 BEFORE CLK TIMEGRP FF_RISING;
TIMEGRP DATA_IN OFFSET = IN -4 VALID 3 BEFORE CLK TIMEGRP FF_FALLING;

上がRISINGエッジで、1 nsのセットアップ時間以内に抑えて、データが有効な時間がVALIDの後の3 nsという制約だ。下がFALLINGエッジで、セットアップ時間-クロックサイクル/2 = 1(ns) - 10(ns)/2 = -4 ns がセットアップ時間で、データが有効な時間がVALIDの後の3 nsという制約だ。データが有効な時間が付加されているので、ホールド時間を考慮して、Place & Routeしてくれるのだと思う。ただし、VALID制約が効くのは入力だけだそうだ。

私のPCI-Xモジュールのセットアップ時間の制約も、

NET "pcix_ad(0)" OFFSET = IN 1.2 ns BEFORE "pcix_clk" ;

から、ホールド時間を含めて

NET "pcix_ad(0)" OFFSET = IN 1.2 ns VALID 1.7 ns BEFORE "pcix_clk" ;

に変更した。
インプリメントして、P&Rのレポートを見てみると、下のようになった。あまり変換がないように思えるが、ホールド時間も考慮してくれるのだろう。

Timing constraint: COMP "pcix_ad(0)" OFFSET = IN 1.2 ns VALID 1.7 ns BEFORE COMP "pcix_clk";

1 item analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors)
Minimum allowable offset is 1.175ns.

Xilinxのアンサーデータベースを漁ったら、”8.1i Timing Analyzer/TRACE/制約 - OFFSET/IN 制約で、以前のバージョンでは発生しなかったホールド タイム違反が発生する”が見つかった。
これによると、ホールドタイム違反が出るのを回避するために、指定したオフセットの後にデータが有効である時間を定義するそうだ。逆の発想か！　データが後まで有効ならばホールドタイムも伸びても大丈夫だね。

UCF設定での失敗例

この前、”仕事では、どうもわけがわからないことがある。IOBのDDRレジスタを使ってクロックを出していて、前のIOBのDDRレジスタを駆動するクロックを使用したIOBのFFでデータを出しているのだが、どうもIOBの出力レジスタから出力パッドまでの遅延がそれぞれ違うのだ。なぜかはまだわからないが、なぜなんだろう？　解明中。”と書いたのだが、私のミス？でUCFが間違っていた。
LVDSのICへはクロックとデータを出力している。クロックはIOBのDDRレジスタを使って、D0に'0'、D1に'1'を入れることによって、クロックを出力している。下の図でフィードバックループが外になくて、FPGA内部に設定してある感じである。(つながっているデバイスもSDRAMではなくてLVDSの送信用ICだけど)


データは最後をFF出力にしてIOB内のFFを使うように設定してある。こうすれば、グローバルクロック配線遅延は大体同一なので、クロック出力時間と、データ出力時間が等しくなり、データとクロックの位相関係が保証できるはずだ。
ところがクロックとデータの出力時間が2ns程度違っている。
クロックのタイミングアナライザでの解析値とFPGA Editorでの回路構成を下に示す。


Tiockpは2.720nsだった。データのタイミングアナライザでの解析値とFPGA Editorでの回路構成を下に示す。


データのTiockpは4.766nsだった。この差は約2nsある。これが何で生じているかをXilinxのアンサー・サーチなどで調べてみたが、無いようだった。更にデータがDDRじゃないからだめなのかな？と思いデータもわざわざDDRにしてみたが、やはりTiockpは変化がなかった。
これで2、3日くらい悩んでしまったが、ふとUCFを見るとクロック出力のほうは、IOBのスルーレートがFASTで8mA出力になっていた。データのほうのUCFは位置の固定だけでデフォルトだったので、スルーレートはSLOWで12mA出力だ。ここがおかしかった。。。
データをクロックの設定にあわせたらTiockpも同じになった。
あ～あ、時間が無駄になってしまった。その前の固めてあるインプリを見るとデータもちゃんと設定してあるので、いつの時点かでUCFがなくなってしまったようだ。
1つ考えられるのは、UCFをPACEで設定するようになってから、 floorplanner や Constraints Editor で作ったUCFと互換が取れにくくなってしまったことがある。両方を使用していると、制約が2重になることもあったし、その時に修正したときに間違って消してしまったのかもしれない。新しいツールを出す時は互換性を完全に取ってもらいたい。（かなり八つ当たりモードです。反省）