PlanAhead ツールで設定された制約が UCF ファイルの制約と一致しません。
気づいた点をいくつか挙げます。
なぜ制約は変更されるのですか。
UCF 制約を処理するのに PlanAhead の制約システムではどのプロセスが使用されるのですか。
UCF ファイルにワイルドカード文字が入力されるとどうなりますか。
PlanAhead プロジェクトに UCF ベースの制約ファイルが含まれている場合、この制約がまず PlanAhead ツールに読み込まれ、開いているデザインに適用されます。
合成 run または インプリメンテーション run が開始すると、PlanAhead ツールに読み込まれている制約が runs ディレクトリ (my_project_name/my_project_name.runs/synth_1 など) にある新しい制約ファイルに書き込まれます。
可能であれば runs ディレクトリの制約ファイルに書き込まれた制約は、元の制約ファイルのものと関連付けられます。runs の制約ファイルが元の制約ファイルと異なったものになる理由には、次のようなものがあります。
NET CLK_N LOC = "K22" | DIFF_TERM = "TRUE" | IOSTANDARD = "LVDS_25";
NET "CLK_N" DIFF_TERM = "TRUE";
NET "CLK_N" IOSTANDARD = LVDS_25;
NET "CLK_N" LOC = K22;
NET "my_net/module_1.*.new/last_module"
NET 属性名は、前のインスタンスと一致するようにすべて合成後に置き換えられます。
しかし、ワイルドカード文字がパターンの冒頭または末尾に含まれている場合は、この問題は発生しません。
NET "*my_net/module_1_new/last_module*"
上記のいくつかのケースに示したように、PlanAhead ツールで制約が正しく認識されない問題が多くあり、見つかるたびに修正されてきました。しかし、制約処理およびデザイン データベース構造に関して PlanAhead と ISE には根本的な違いがあるために起きている問題もあります。PlanAhead ツールで UCF 制約ファイルを初めて使用する際は、制約の DRC 警告、クリティカル警告、エラーをよく読んで、元の制約と、runs ディレクトリに書き込まれた制約ファイルとを比較する必要があります。
元の UCF 制約をただインプリメンテーション ツールに渡し、PlanAhead で制約をグラフィカルに表示させる必要がない場合は ([Pin Planning] または [Design] ビューでの制約の表示や変更など)、アクティブになっている制約セットで UCF ファイルを削除するか無効にし、[Implementations Project Settings] の [Translate] (NGDBuild) にある [more options] フィールドで -uc オプションを使用して NGDBuild に直接渡すことができます。
AR# 47831 | |
---|---|
日付 | 05/15/2013 |
ステータス | アーカイブ |
種類 | 一般 |
ツール |