AR# 47831

説明

PlanAhead ツールで設定された制約が UCF ファイルの制約と一致しません。

気づいた点をいくつか挙げます。

• MAP、PAR、または BitGen 中に、制約が必要であるというエラーまたは警告が表示されます。UCF ファイルには、問題となっている制約が含まれています。
• 合成およびインプリメンテーションに使用された UCF ファイルのサイズがプロジェクトに追加されている UCF ファイルのものよりはるかに大きくなっています。
• オブジェクトに割り当てられている属性値が制約ファイルに渡されている値と一致しません。
• エラボレートされたデザイン、合成されたデザイン、またはインプリメントされたデザインを開くと、特定の制約に警告またはエラーが表示されます。しかし、制約は適用されているようです。
• デザインをインプリメントしていると、特定の制約に警告またはエラーが表示されます。しかし、Project Navigator または ISE のコマンド ライン フローでは、同じ UCF およびデザイン ファイルが問題なく完了します。
  

なぜ制約は変更されるのですか。

UCF 制約を処理するのに PlanAhead の制約システムではどのプロセスが使用されるのですか。

UCF ファイルにワイルドカード文字が入力されるとどうなりますか。

ソリューション

PlanAhead プロジェクトに UCF ベースの制約ファイルが含まれている場合、この制約がまず PlanAhead ツールに読み込まれ、開いているデザインに適用されます。

合成 run または インプリメンテーション run が開始すると、PlanAhead ツールに読み込まれている制約が runs ディレクトリ (my_project_name/my_project_name.runs/synth_1 など) にある新しい制約ファイルに書き込まれます。

可能であれば runs ディレクトリの制約ファイルに書き込まれた制約は、元の制約ファイルのものと関連付けられます。runs の制約ファイルが元の制約ファイルと異なったものになる理由には、次のようなものがあります。

• PlanAhead ツールは 1 行に 1 つの制約を書き出します。UCF フォーマットでは、パイプ文字で制約を区切り、1 行に 1 つのオブジェクトに複数の制約が割り当てることができます。PlanAhead ツールはその制約行を読みこみ、複数行に書き出します。
  
• 例 : 元の UCF 行 :

NET CLK_N LOC = "K22" | DIFF_TERM = "TRUE" | IOSTANDARD = "LVDS_25";

• PlanAhead でこれは次のように変更されます。

NET "CLK_N" DIFF_TERM = "TRUE";
NET "CLK_N" IOSTANDARD = LVDS_25;
NET "CLK_N" LOC = K22;

• ワイルドカードは PlanAhead ツールでは同じようには処理されません。
  
• ワイルドカード文字が 1 つの制約に含まれている場合、PlanAhead ツールは、そのワイルドカード名と一致する各ネット/インスタンスに制約を割り当てようとします。ワイルドカード文字が多数のネットやインスタンスを表すのに使用されている場合は、UCF ファイルのサイズが元の UCF よりもはるかに大きくなります。
  
• ワイルドカードが名前の真ん中に使用されている場合は、PlanAhead ツールはネット名を置き換えます。次はその例です。

NET "my_net/module_1.*.new/last_module"

NET 属性名は、前のインスタンスと一致するようにすべて合成後に置き換えられます。

しかし、ワイルドカード文字がパターンの冒頭または末尾に含まれている場合は、この問題は発生しません。

NET "*my_net/module_1_new/last_module*"

• PlanAhead ツールは ISE ツールほどには自由に制約をオブジェクトに伝搬しません。たとえば、ピン ロケーション制約は I/O ポートに配置する必要があります。ISE では、ピン ロケーション制約がバッファーに接続されているネットに配置されていて、そのバッファーが I/O ポートに接続されている別のネットを駆動する場合、マップで、目的の I/O ポートにバッファーを介して LOC 制約を伝搬することができます。PlanAhead ツールではこうなりません。
  
• なんらかの理由で、PlanAhead ツールでは制約が設定されているネットまたはオブジェクトが検出されず (ブラックボックス化されているモジュールや、暗号化されているモジュールなど)、制約は runs ディレクトリにある UCF からは消失します。
  
• PlanAhead ツールの DRC チェックは ISE Design Suite のものとは一致しません。たとえば、この問題は、差動ペアの I/O ポートに適用されているロケーションおよび I/O 規格制約が置き換えられる場合によく見られます。PlanAhead ツールは、一部の組み合わせが無効であると間違って判断し、制約をドロップします (これらの間違った DRC は修正されているか、間違いが検出されたときに修正される予定になっています)。
  
• 制約が認識されない場合は、そのまま runs ディレクトリの UCF ファイルに渡されるべきです。しかし、制約が認識されずにドロップされてしまっています。

上記のいくつかのケースに示したように、PlanAhead ツールで制約が正しく認識されない問題が多くあり、見つかるたびに修正されてきました。しかし、制約処理およびデザイン データベース構造に関して PlanAhead と ISE には根本的な違いがあるために起きている問題もあります。PlanAhead ツールで UCF 制約ファイルを初めて使用する際は、制約の DRC 警告、クリティカル警告、エラーをよく読んで、元の制約と、runs ディレクトリに書き込まれた制約ファイルとを比較する必要があります。

元の UCF 制約をただインプリメンテーション ツールに渡し、PlanAhead で制約をグラフィカルに表示させる必要がない場合は ([Pin Planning] または [Design] ビューでの制約の表示や変更など)、アクティブになっている制約セットで UCF ファイルを削除するか無効にし、[Implementations Project Settings] の [Translate] (NGDBuild) にある [more options] フィールドで -uc オプションを使用して NGDBuild に直接渡すことができます。