抽象化シェル デザイン フロー - 2023.2 日本語

抽象化シェル デザイン フローは、標準的な非プロジェクト Dynamic Function eXchange デザイン フローとほぼ同じです。異なるのは、スタティック デザイン チェックポイントは初期 (親) インプリメンテーションを書き込む段階と、スタティック デザインを開いて各 RP の 2 番目の RM (およびそれ以降) のインプリメンテーションを開始する段階のみです。

最初のコンフィギュレーションの合成とインプリメンテーションは、抽象化シェル フローでも DFX 標準フローと同じです。初期フル デザイン チェックポイントをインプリメントしたら、各 RP の抽象化シェルを作成できます。デザインに複数の RP が含まれる場合は、それぞれに独自の抽象化シェルがあります。これらの RP の RM は、どれも独立して処理されます。

UltraScale+ および Versal デバイスは抽象化シェル フローでサポートされますが、UltraScale+ しか非プロジェクト モードでサポートされません。このセクションのコマンドは、フローが実行される方法の詳細を説明するものですが、これらは Tcl から直接 UltraScale+ ターゲットに適用する必要があります。Versal デザインに対しては、Vivado プロジェクト フロー に説明している IP インテグレーター プロジェクト フローを使用します。

完全に配線された初期デザイン イメージをメモリ内で開き、各 RP に RM が存在する状態で、write_abstract_shell コマンドを使用してターゲット RP の抽象化シェルを作成します。デザインに複数の RP がある場合は、各 RP に対して個別にコマンドを実行する必要があります。このコマンドは、次を実行します。

• ターゲット RP をブラック ボックスにします (update_design -black_box を使用)。
• 残りのデザインをロックします (ほかの RM を含む、lock_design -level routing を使用)。
• ターゲット RP の抽象化シェルを生成します (write_checkpoint を使用)。
• pr_verify を実行してこのチェックポイントを元の完全に配線されたデザインと比較します。

write_abstract_shell  -cell <arg> [-force] [-quiet] [-verbose] <file>

抽象化シェル チェックポイントを見ると、フル デザインのスタティック チェックポイントよりも小さいことがわかります。ダイナミック領域が大きい単純なデザインでは、フロアプランおよびインプリメンテーションによって、サイズの 80 ～ 90% になることがあります。大型デザインでスタティック ロジックが大きいと、サイズの削減量が大きくなります。

抽象化シェルには、新しい RM をその RP にインプリメントするために必要なターゲット RP 周辺のロジックと配線のみが含まれます。これには、ターゲット RP Pblock だけでなく、拡張配線領域の配線も含まれます。拡張領域内のロジックを含む周辺のロジックの多くは削除され、このコンフィギュレーション情報は結果のパーシャル ビットストリームでスキップされます。タイミング制約および境界制約は、シェルに含まれます。これは、このコンテキストにインプリメントされた新しいモジュールはスタティック デザインからのこれらの目標を継承するからです。

抽象化シェルの使用を続行する前に、シェルが正常に生成されたことを確認するため、2 つのチェックを実行できます。まず、write_abstract_shell を実行したときに PR 検証が自動的に実行され、抽象化シェルが作成元のフル スタティック デザインと整合性があることが確認されます。PR 検証チェックは、ブラック ボックスを確立して lock_design を実行した後に、抽象化シェル チェックポイントとスタティックのみのデザインを比較するために手動で実行することもできます。

2 つ目のチェックでは、シェル自体の配線ステータスが検証されます。これには、抽象化シェルを開いて report_route_status を実行し、チェックポイントのステータスをチェックします。