制約は、制約のタイプによって複数のファイルに分割する必要があります。AMDでは、Dynamic Function eXchange ではデザイン制約を次の 3 つのタイプに分割することをお勧めします。
- スタティック
- スタティック オブジェクト (セル、ピン、ネット、ポート) のみを参照する物理またはタイミング制約で、RP 内のオブジェクトは参照しません。これらはグローバル制約で、スタティック合成にまたは初期コンフィギュレーションのインプリメンテーションで適用されます。スタティック部分がインポートされる 2 つ目以降のコンフィギュレーションにこれらの制約を再適用することはお勧めしません。これらの制約はスタティック DCP に既に存在しており、再適用すると意図しない制約の相互作用が発生する可能性があります。
- 境界
- スタティック部分および RP の両方の参照オブジェクトを参照するタイミング制約 (
set_false_pathなど)。これらの制約は RP ピン オブジェクトを参照して記述し、RM 内のオブジェクトは参照しないでください。たとえば、次のような 2 つの制約があるとします。set_false_path -from [get_pins static_reset/C] -through [get_pins rp_inst/rst] set_false_path -from [get_pins static_reset/C] -to [get_pins rp_inst/*foo*/D]最初の制約は、初期コンフィギュレーション後に RM がブラック ボックスに変換されたときに失われることはないので、こちらの制約が推奨されます。RM がブラック ボックスに指定された後も RP インターフェイスはスタティック デザインに存在し、制約で参照される
rp_inst/rstピンもデザインに存在します。2 番目の制約のように制約が RM 内のオブジェクトを使用して定義されている場合、制約は無効となり、RM がブラック ボックスに指定された後にデザインから破棄されます。この構文を使用する場合、これらの制約を各コンフィギュレーションで適用し直す必要があります。 - RM
- RM ロジックのみを参照する物理またはタイミング制約。これらの制約はすべて範囲が RM に限定されるべきですが、どのように適用されるかは制約のタイプによって異なります。
- 汎用 RM 制約
- RM の各インスタンスに適用されます。フォルス パス、マルチサイクル例外、ローカル RM クロックの
create_clockなどのタイミング制約がその例です。これらの制約は、その物理的なロケーションにかかわらず、すべての RM に適用されます。 - RP 特定の RM 制約
- RM がインプリメントされるロケーション (Pblock) に特定の制約。特定のブロック RAM の配置、エンベデッド I/O の PACKAGE_PIN 制約などの物理制約がその例です。
- エンベデッド IO 制約
- 特定の IP 階層内にインスタンシエートされた I/O バッファーは、DFX デザイン フローではエンベデッド IOB と言われます。DDR などの IP では、GT にエンベデッド IOB を含めて、I/O バッファーを最上位に追加する必要がないようにできます。これらの IP が特定の RM コンパイルで未使用の場合、ツールでその IP 用の I/O バッファーが最上位に挿入されないようにする必要があります。これは、最上位 RTL でこれらのポートの IO_BUFFER_TYPE 属性を NONE に設定すると指定できます。特定のエンベデッド IOB が特定の RM コンパイルで未使用の場合、それらの I/O パッドはネットリスト内のリコンフィギャラブル モジュール階層まで接続しておき、その特定の RM 内では未接続にしておく必要があります。
また、I/O 配置のため、これらのポートに該当する PACKAGE_PIN 制約を、これらの I/O パッドを使用しないコンパイル内であっても維持しておく必要があります。
重要: RP にエンベデッド I/O が含まれる場合、I/O ピンがすべての RM で同一である場合でも、各コンフィギュレーションで I/O 制約 (PACKAGE_PIN、IOSTANDARD、方向) を適用し直す必要があります。Vivado データベースではポートは最上位オブジェクトですが、ポートに関連付けられている I/O バッファーが RP の一部である場合は、RM が削除されるときにそのポートの I/O 制約情報も削除されます。
また、物理制約 (Pblock、LOC、PACKAGE_PIN など) とタイミング制約を別の XDC ファイルに分けることをお勧めします。このようにすると、制約をいつ適用するか (合成またはインプリメンテーション) を制御しやすくなり、制約の変更が必要な場合に制約ファイルの管理が簡単になります。