手順 4: 抽象化シェル内への新規 RM のインプリメント - 2022.1 日本語

Vivado Design Suite チュートリアル: Dynamic Function eXchange (UG947)

Document ID
UG947
Release Date
2022-05-31
Version
2022.1 日本語

この時点で、残りのすべてのリコンフィギャラブル モジュールをこれらのシェル内にインプリメントできます。各 RP は個別に管理できるので、必要であれば、異なる Vivado® セッションで各 RM を並列にインプリメントできます。これは、u_count インスタンスなどの特定のシェルだけでなく、デザイン内のすべてのリコンフィギャラブル パーティションに対しても実行できます。すべてのデザイン コンフィギュレーションに焦点を置いたプロジェクト フローとは異なり、抽象化シェル アプローチの焦点はリコンフィギャラブル モジュールです。

  1. 初期 VCU118 サンプル デザイン プロジェクトとは個別に作業するため、新しい Vivado セッションを開始します。Tcl コンソールで、チュートリアル ディレクトリに移動します。
    重要: 抽象化シェルでも元のインプリメントを作成したのと同じ方法を使用します。Vivado プロジェクト モードでは、add_files/link_design を使用するので、ここではそれらを使用して説明します。open_checkpoint と read_checkpoint-cell を使用して初期デザインを構築した場合は、抽象化シェルのインプリメンテーションにも同じ方法を使用します。
  2. フル スタティック チェックポイントではなく、抽象化シェル チェックポイントを読み込みます。
    add_files ./abstract_shell/ab_sh_count.dcp
  3. 次に、count_down モジュールのみの合成後ネットリストを追加します。
    add_files ./project_dfxc_vcu118/project_dfxc_vcu118.runs/count_down_synth_1/count.dcp
    set_property SCOPED_TO_CELLS {u_count} [get_files ./project_dfxc_vcu118/project_dfxc_vcu118.runs/count_down_synth_1/count.dcp]
  4. デザインをリンクする場合、u_count RP のみを参照します。
    link_design -mode default -reconfig_partitions {u_count} -part xcvu9p-flga2104-2L-e -top top
  5. デザインを通常どおりインプリメントしてから、配線済みデザインを保存するときに、現在のイメージ全体 (抽象化シェルとリコンフィギャラブル モジュール) および RM のみのチェックポイントの両方を保存します。
    opt_design
    place_design
    route_design
    write_checkpoint -force ./abstract_shell/abs_count_down/abstract_shell_count_down_routed.dcp
    write_checkpoint -force -cell u_count ./abstract_shell/abs_count_down/rm_count_down_route_design.dcp
    shift_left モジュールでこれらの手順を繰り返し、ファイル名とコマンドを適宜変更します。count_down および shift_left 抽象化シェル インプリメンテーションの Tcl スクリプトは、これらの手順を自動化するチュートリアル ディレクトリにあります。スクリプト名は、次のとおりです。
    • abs_impl_count_down.tcl
    • abs_impl_shift_left.tcl

    次の図では、Count RP 抽象化シェル内の count_down RM と count_down RM のみのモジュール レベルのチェックポイントを比較しています。後者はダイナミック領域にスタティック デザイン情報を含まないため、パーシャル ビットストリーム生成には前者のみを使用してください。

    図 1. RP Count 抽象化シェル内の RM count_down
    図 2. 抽象化シェルなしの RM count_down

    これで、配線済みスタティック チェックポイントと RM チェックポイントのコレクションが作成され、すべての RM チェックポイントがスタティック デザインと同期します。

    注記: パーシャル ビットストリームを生成する前に、必ず PR 検証を実行してください。PR 検証では、RM が異なるがスタティックが同じである複数のデザイン イメージを比較して、すべての DFX 規則に従っていることを確認します。フル コンフィギュレーション アセンブリが完了している場合は、標準的な方法で PR 検証を実行し、各チェックポイント コンフィギュレーションのスタティック デザイン全体を比較できます。ただし、PR 検証は抽象化シェルのコンテキストでも実行でき、初期抽象化シェルと配線済みリコンフィギャラブル モジュールを含むシェルを比較できます。
  6. 現在開いているチェックポイントがなければ、上記で作成したチェックポイントを使用して、この検証チェックを実行できます。

    pr_verify ./abstract_shell/ab_sh_count.dcp ./abstract_shell/abs_count_down/abstract_shell_count_down_routed.dcp

    配線済みの抽象化シェルのチェックポイントが Vivado で開いている場合は、-in_memory オプションを使用して元のシェルと比較できます。たとえば、count_down がインプリメント u_count の抽象化シェルがまだ開いている場合は、次のコマンドを使用して PR 検証を実行します。

    pr_verify -in-memory -additional ./abstract_shell/ab_sh_count.dcp

    ここでの比較は、ブラック ボックスを含む u_shift 用の抽象化シェルと、ブラック ボックス内に shift_left または shift_right のいずれかがインプリメントされた抽象化シェルの間で実行されます。目標は、異なる RM インプリメンテーションをコマンド スタティック チェックポイントと比較することです。次の場合、PR 検証はエラーになります。

    • フル スタティック デザイン チェックポイントを抽象化シェルチェックポイントと比較した場合
    • RM チェックポイントが抽象化シェルなしで読み込まれた場合
    • 異なるリコンフィギャラブル パーティションの抽象化シェルが比較された場合