設計やデバッグテクニックのブログ

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

設計やデバッグテクニックのブログ

kurihara
Xilinx Employee
Xilinx Employee

このブログでは、Vivado ILA コアを使用して Versal™ ACAP CPM Mode for PCI Express デザインをデバッグする方法について説明します。

Read more...

more
2 0 484
kshimizu
Xilinx Employee
Xilinx Employee

概要:

本ブログは、Memory Interface Generator(MIG) のデバッグ手法について説明します。

 

 

メモリ インターフェイスの開発フロー:

評価、設計の段階に応じて行うべき開発手順を分けることができます。この記事では、デバッグについて説明します。

 

11.PNG

 

Read more...

more
1 0 424
karnanl
Xilinx Employee
Xilinx Employee

Zynq UltraScale + RFSoC 製品ファミリの第 3 世代のリリースでは、データ コンバーター クロッキングに柔軟性が加わりました。つまり、RF サンプリング クロックまたはタイル PLL 基準クロックの内部分配をサポートすることで、PCB 設計を簡易化にする機能が追加されました。

ZCU216 評価ボードには、CLK104 アドオン カードが付属されています。これにより、RFSoC ZU49DR クロッキング オプションを評価するための柔軟なクロッキング ソリューションが提供されます。このカードは、キットに含まれているシステム コントローラーの GUI でプログラムできます。ただし、このブログでは、RFSoC の APU で CLK104 モジュールをプログラムする方法を示し、RFSoC Gen3 の新しい内部クロック分配オプションのいくつかを示します。

Read more...

more
1 0 361
takayos
Xilinx Employee
Xilinx Employee

この記事はUsing the Methodology Report Part Six: Design is not consistently routable を翻訳したものですよー。

 

このブログ エントリの分析は、DFX デザインの一部を配線できず配線のオーバーラップが発生している実際のお客様の問題に基づいています。

このブログでは、根本的な原因を絞り込み、問題を修正するために使用したデバッグ手法の一部を紹介します。

このブログは、設計手法レポートの使用方法シリーズのパート 6 です。このシリーズのすべてのエントリについては、を参照してください。

 

問題について

この例では、DFX デザインで配線ができず、一部のネットが配線されないままになってしまうという問題が発生しました。

Tcl コマンド report_route_status を実行すると、未配線のネットが 165 個表示されました。

takayos_0-1622084782689.png

 

根本的な原因の解析:

デザインを見ると、次に示すように、クロック間のパスで約 4.6 ns の大きなホールド違反が発生していることがわかりました。

ただし、これらの違反は配線されたチェックポイントでは確認されませんでした。これらは、route_design の実行時にログに記録されました。

注記: 配線遅延の見積もり値を使用してタイミングを詳細に解析するには、Vivado GUI のタイミング サマリ レポートでインターコネクトに [estimated] オプションを使用します。

次のオプションを使用すると、デザインのタイミング サマリを確認できます。

  • Vivado GUI で、[Reports] タブ → [Timing] [Report Timing Summary] をクリックします。
  • 次の Tcl コマンドを実行します。

report_timing_summary -file <filepath>/timingreport.txt

このインターコネクト設定により、ネット遅延を最下位セル ピン間の見積もり配線距離に基づいて算出するか、実際に配線されたネットを使用して算出するか、またはタイミング解析から除外するかが制御されます。詳細は、 を参照してください。

takayos_1-1622084782701.png

 

 

または、次の Tcl コマンドを使用しても、配線遅延の見積もり値を使用してタイミングを解析できます。

set_delay_mode -interconnect estimated

 

takayos_2-1622084782711.png

 

 

 

クロック関連性レポートを使用すると、次に示すように、特定のクロック ドメインのクロック間のパス違反を検出できます。

(クロック関連性レポートは、Vivado GUI [Report] [Timing] [Report Clock Interaction] をクリックすると表示できます。)

takayos_3-1622084782725.png

 

 

これらの大きなホールド違反を見て、クロッキング トポロジに問題があるか、またはデザインが適切に制約されていないという結論に達しました。

その結果、両方の可能性を徹底的に解析する必要がありました。

次の図に示しているホールド違反が発生するクロック間のパスのクロック パス スキューが非常に大きく、疑わしいと思われました。

takayos_4-1622084782733.png

 

 

デフォルトでは、Vivado ですべてのクロックが同期と見なされます。その結果、これらの CDC 非同期クロック パスも同期と見なされ、パスに誤ったクロック スキューが追加されていました。この例では、約 4 ns です。

では。これらの非同期 CDC が適切に制約されていないことをどのようにして判断できたのでしょうか。

それは、次に示すクロック ペアの分類とクロック内制約の情報から判断できました。

この詳細は、このブログ エントリを参照してください。

takayos_5-1622084782739.png

 

 

これが原因で、大きなホールド違反が発生し、ルーターにより多数のホールド違反修正が実行されたため、配線が密集してしまいました。

ホールド タイミングがエラーになるデザインは機能しませんが、セットアップ タイミングがエラーになるデザインは低い周波数では機能するため、ルーターでは常にセットアップ タイミングよりもホールド タイミングの修正が優先されます。

配線の迂回による配線の密集によりタイミング エラーが発生する可能性もあれば、未配線になる可能性もあります。

密集が深刻な場合、ルーターでは配線に使用する使用可能なリソースを見つけることができません。この特定のケースではこの問題が発生していたと言えます。

これらの制約されない CDC パスが原因で発生するホールド違反を修正するためにルーターで使用された配線リソース量を確認できます。

最終的には、この特定のケースではこれが原因で密集および未配線のネットが発生していました。

次のスクリーン キャプチャでは、クロック スキューが 4 ns の場合のホールド違反を示しています。

takayos_6-1622084782773.png

 

次の図は、安全ではない CDC パスで使用されている配線リソースすべてが示されており、これらのリソースで、ホールド違反が発生しています。

takayos_7-1622084782840.png

 

また、解析のもう 1 つのポイントはリソース使用率で、しきい値を超えてはおらず、制限内でした。再度述べますが、根本的な原因は不適切な制約でした。

Vivado GUI で [Reports] タブ → [Timing] [Resource Utilization] をクリックすると、リソース使用率を確認できます。

または、Tcl コンソールで report_utilization コマンドを実行します。

takayos_8-1622084782849.png

 

このケースでは設計手法レポートはどのように役立ちましたか。

設計手法レポートを見ると、デザインに多くの設計手法の警告があることがわかりました。

デザインの QoR に影響を与え、優先度に基づいて解決する必要がある主な警告を次に説明します。

Vivado GUI で設計手法レポートを開くには、[Report] タブ → [Report Methodology] をクリックするか、または Tcl コンソールで「report_methodology」と入力します。

次のスクリーン キャプチャは、設計手法レポートの一部で TIMING 67815、および 35 の警告メッセージが含まれています。

takayos_9-1622084782856.png

 

TIMING-6、TIMING-7TIMING-8、および TIMING-35 の警告によると、デザインが正しく制約されておらず適切に制約する必要があります。

そのためには、クロック関連性レポートを参照して、クロック間パスのタイミングが安全に解析されるかどうかを確認する必要があります。クロック関連性レポートの詳細は、(UG906) を参照してください。

TIMING-15 の警告は、クロック間のパスに大きなホールド違反があることを示しており、この違反は、ビットストリームを生成する前に解決する必要があります。

解決しておかないと、ルーターは常にホールド違反を解決しようとするため、配線にも影響を与えるので、上記の警告メッセージに従い、デザインを適切に制約し、クロック間のパスの問題を解決することを推奨します。

タイミング サマリを確認することで、ホールド違反が多く、クロック間パスで約 -3 ns であることがわかりました。

これら 5 つのタイミング警告メッセージとその解決方法の詳細は、(UG906) の付録 A を参照してください。

まとめ:

解析結果に基づくと、お客様がデバッグの初期段階で設計手法レポートの警告を確認して解決していた場合、この未配線のネットの問題のデバッグにかかる時間が大幅に短縮されることがわかりました。

次のような制約を追加したら、これらのタイミング違反が解決されました。

set_max_delay -datapath_only -from [<valid start point >] -to [<valid end points >] <Minimum clock period>

適切なタイミング例外を追加する方法の詳細は、『Vivado Design Suite ユーザー ガイド: 制約の使用』 (UG903)このブログを参照してください。

最後に、これらの変更を加えたらリコンフィギャラブル モジュールの使用率を 55% FF に増やすことができました。

 

 

 

 

more
3 0 333
katsuki
Xilinx Employee
Xilinx Employee

このブログは、英語版のHow to leverage Versal CIPS IP from MicroBlazeを翻訳したものです。

 

Versal™ CIPS (Control, Interfaces and Processing System) には、CIPS 上の APU または RPU からアクセスできる IP コアが多数あります。

このブログでは、CIPSの代わりに、プログラマブルロジック内のソフトプロセッサから、これらのIPコアをどのように活用できるかについて説明します。

このブログでは、ソフトプロセッサにMicroBlazeを使用します。PS DDRからの実行方法と、CIPSでUARTを活用する方法について説明します。

Read more...

more
4 0 418
karnanl
Xilinx Employee
Xilinx Employee

こんにちは、

MIPI CSI-2 TX/RX Subsystemを使用されるお客様からMIPI CSI-2 TX/RX Subsystem に関する Pixel Encodingについて質問を頂いたことがあります。

つまり、MIPI CSI-2 RX Subsystemからどのようにピクセルデータが出力されているのか?赤/青/緑ピクセルはそれぞれどのビット割り当てるか?

MIPI CSI-2 TX SubsystemのTDATAのビットアサインはどうすれば良いか?

PG232/PG260/UG934の情報を補足する形でこのブログを作成しました。お役に立てれば幸いです。

Read more...

more
3 0 398
kshimizu
Xilinx Employee
Xilinx Employee

このブログは、英語版の Getting Started with Versal Memory Interfacesを翻訳したものです。

 

概要

このブログ エントリでは、Versal ACAP デバイスのメモリ インタフェースを使用して設計する前に理解しておく必要がある重要な情報について説明します。 

 また、このブログには、関連する資料、チュートリアル、およびサンプル デザインへのリンクも含まれています。

Versal に関連するブログは、こちらからご覧いただけます。

 

 

IP

Versal ACAP では、ハード化された Integrated DDR Memory Controller (DDRMC) がソフト メモリ インターフェイス IP オプションと共に提供されています。

さらに、Performance AXI Traffic Generator は、ハードウェア解析のためにシミュレーションおよび合成後の両方で Memory IP をスティミュレーションするために使用できます。

 

Versal Integrated DDRMC は、消費電力、リソース使用率、およびタイミング クロージャが抑えられているため、推奨されるソリューションです。

DDRMC にはプログラマブル ネットワーク オン チップ (NoC) インターフェイス ポートがあり、複数のトラフィック ストリームを処理するように設計されています。

さらに、サービス品質 (QoS) クラスがサポートされているので、コマンドの優先順位を適切に付けることができます。

 

NoC は、設定可能な AXI 接続ネットワークで、プログラマブル ロジック (PL)、プロセッシング システム (PS)、およびその他のハード ブロックの IP エンドポイント間でデータを共有するために使用されます。このデバイスのインフラストラクチャが、専用スイッチを持つ、高速で統合されたデータパスです。

Versal ソフト IP PL 内に配置されており、UltraScale/UltraScale+ デバイス ファミリのソフト メモリ インターフェイス IP に類似しています。

1: Versal IP

メモリ インターフェイス

 

DDRMC またはソフト IP

製品ガイド

ピン、バンク、クロッキング、およびリセット規則

PCB ガイドライン

リリース ノートおよび既知の問題

使用可能な IP デザイン フロー

ファブリック アクセス

DDR4

DDRMC

(PG313)

(PG313)

(UG863)

(Xilinx Answer 75764)

IP インテグレーターが必要

NoC

ソフト IP

(PG353)

(PG353)

(UG863)

近日リリース

IP インテグレーターまたは RTL のインスタンシエーション

PL に含まれている

LPDDR4/4X

DDRMC

(PG313)

(PG313)

(UG863)

(Xilinx Answer 75764)

IP インテグレーターが必要

NoC

RLDRAM3

ソフト IP

(PG354) 

(PG354) 

(UG863)

近日リリース

IP インテグレーターまたは RTL のインスタンシエーション

PL に含まれている

QDR-IV

ソフト IP

(PG355)

(PG355)

(UG863)

近日リリース

IP インテグレーターまたは RTL のインスタンシエーション

PL に含まれている

トラフィック ジェネレーター

ソフト IP

製品ガイド

クロッキングおよびリセット規則

PCB ガイドライン

リリース ノートおよび既知の問題

使用可能な IP デザイン フロー

ファブリック アクセス

Performance AXI Traffic Generator

ソフト IP

(PG381)

(PG381)

該当なし

(Xilinx Answer 75781)

IP インテグレーターまたは RTL インスタンシエーション

PL に含まれている

 

 

デザイン フロー

Versal ACAP をターゲットにする場合は、主に次の 2 つのデザイン ツールを使用できます。

  • 高位 FPGA デザインおよび検証をアクセラレーションする Vivado® ツール デザイン フロー
  • アクセラレーション アプリケーションをビルドする Vitis™ 環境デザイン フロー

NoC および DDRMC デザインには、Vivado IP インテグレーターが必要です。上記のソフト IP では、RTL インスタンシエーションと IP インテグレーターの両方がサポートされています。

IP インテグレーターの使用に関する情報は、Vivado デザイン ハブ - IP インテグレーターの使用」を参照してください。

 

デザインフローのベスト プラクティスおよび詳細なメモリ インターフェイス IP のウォークスルーについては、『Versal ACAP デザイン ガイド』 (UG1273) の第 4 章「デザインフロー」および上記の IP 製品ガイドを参照してください。

次に示すサンプル デザインも利用可能で、使い始めるときに役立つ優れた例が提供されています。

Versal ACAP デザインには、デバイスのブートに使用される PMC を含む CIPS IP が必要です。詳細は、『Control Interface and Processing System IP 製品ガイド』 (PG352) を参照してください。

 

 

NoC/DDRMC 入門

NoC および DDRMC を使用したデザインは、Versal ACAP が初なので、以前のザイリンクス デバイス ファミリとは異なります。

始めるのに役立つ情報は、次のとおりです。

  • NoC の概要を学ぶ: NoC の基本およびデザイン内で NoC を設定する方法を学ぶことができます。(PG313) の第 2 章と第 3 章で概要および製品仕様を確認できます。
    GitHub NOC DDRMC デザイン フローの概要に関するチュートリアルから学ぶことができます。このチュートリアルには、次のモジュールが含まれています。
    • NoC デザインの基本
    • NoC での Integrated Memory Controller の使用
    • ストリーミング トラフィックを使用したアイソクロナス クラス
    • 複数の NoC インスタンスを接続する NOC 間インターフェイス
    • デザインの合成およびインプリメンテーション

  • NoC IP を適切に設定する: IP に適切な数の AXI マスター、スレーブ、NoC 間インターフェイス、およびメモリ コントローラーを設定します。
    決定されたトラフィック モデルに基づいて (下記の「パフォーマンスを重視してデザインする」セクションを参照)、各 AXI チャネルの QoS を入力し、DDR アドレス マップを設定します。
    DDRMC でのメモリ インターフェイスの設定方法が、以前のデバイス ファミリとは異なります。DDR メモリ コントローラーは、NoC IP ウィザードを使用してインプリメントされます。このウィザードを使用すると、ドロップダウン リストからメモリ デバイスを選択する代わりに、メモリ集積度パラメーター、JEDEC タイミング パラメーター、およびモード レジスタ設定など、ターゲット メモリ デバイスのオプションを設定できます。
    さらに、このウィザードでは、ランクやスロットの追加、3DS デバイスへの移行など、将来のメモリ トポロジの拡張を考慮する際に、DDRMC のピン配置が十分あるように、将来のデバイス拡張に対応するオプションが提供されています。
    詳細は、(PG313) の第の「DDR メモリ コントローラー」を参照してください。

  • パフォーマンスを重視してデザインする: NoC および DDRMC を使用してデザインする場合、事前にパフォーマンスを重視したデザインを計画することが重要です。
    (PG313) の第「NoC のパフォーマンス調整」では、帯域幅、遅延、およびパフォーマンスに影響を与えるシステム デザインのトレードオフなど、パフォーマンスを測定するときに使用する主な基準と、NoC および統合 DDR メモリ コントローラーのパフォーマンスを最適化する方法が説明されています。
    パフォーマンスを重視してシステムをデザインする前に、GitHub チュートリアル「Versal ネットワーク オン チップ/DDR メモリ コントローラーのパフォーマンス調整」を参照して、パフォーマンス目標を達成するためにデザインを改善します。このチュートリアルでは、システムの DDR トラフィック仕様から始めて、次に NoCDDR メモリ コントローラー、および AXI トラフィック ジェネレーター (TG) を使用してこの仕様をモデル化する方法を学びます。

    準備ができたら、システムでパフォーマンスを重視してデザインします。

 

  1. トラフィック フローをモデル化します。コマンド パターンやアドレス パターンなど、システムのトラフィック要件を決定します。

  2. システムの集合体 (読み出しおよび書き込み) の帯域幅と各マスターの帯域幅を決定します。

  3. 理論上の最大帯域幅と NoC および DDRMC の実際のまたは達成可能な帯域幅を比較します。
    NoC の帯域幅については、(PG313) の「パフォーマンス メトリクス」セクションを参照してください。LPDDR4/DDR4 の帯域幅については、バスのターンアラウンド タイム、ページ ミス、メンテナンス コマンドなどの SDRAM オーバーヘッドを考慮してください。

  4. シミュレーションを実行して、チャネルで予測どおりにトラフィックが実行されていることを確認し、ボトルネックを特定し、パフォーマンスを調整します。
    • Performance AXI Traffic Generator は、Versal ACAP デザインのトラフィック マスターをモデリングし、ネットワーク オン チップ (NoC) に基づくソリューションのパフォーマンスを評価するものです。このコアには、シミュレーション専用で合成が実行できないバージョンと、シミュレーションとハードウェアでの実行の両方が可能な合成可能バージョンの 2 つのバージョンがあります。
      カスタム トラフィック パターンは、.cvs ファイルを使用すると IP に読み込むことができます。.csv ファイルの例は、(Xilinx Answer 75782) を参照してください。
    • 読み出し/書き込みレイテンシと帯域幅を表示するための AXI Performance Monitor IP を含めます。

  5. パフォーマンスを調整してシミュレーションを再実行します。
    • 要件を満たすために必要な数の NoC NMU DDRMC が設定されていることを確認します。
      オプションとして、メモリ インターリーブ、メモリの追加、データ幅の拡張、メモリの高速実行も考慮してください。
    • トラフィック要件を満たした DDR コンポーネントがあることを確認します。たとえば、DDR コンポーネントでバンクとバンク グループを増やすと、ページ ヒットとスイッチング ペナルティが減るため、最終的にはパフォーマンスが向上します。
    • シングル チャネルとデュアル チャネルの DDR 帯域幅を決定します。
    • DRAM コマンドおよびアドレス マッピングの効率を最大化して、ページ ヒットを含む DRAM ペナルティを削減します。
      DDR にアクセスするアドレス パターン、コマンド パターン、トランザクション サイズ、およびスレッド数を考慮してください。

  6. AXI Performance Traffic Generator をターゲット AXI エンドポイントに置き換えてシミュレーションします。インターフェイスの使用率を最大限にするようにカスタム AXI IP をデザインします。
    『Vivado Design Suite: AXI リファレンス ガイド』 (UG1037) (特に第 6 章の「AXI システムの最適化」) およびフォーラムの AXI 基本ブログ シリーズには役立つ情報が提供されています。

    簡単なヒント:
    • シミュレーションで確認できる Outstanding Read (未処理の読み出し) Outstanding Write (未処理の書き込み) が常にキューに入っていることを確認します。
    • axi_cache[1] がどのように設定されているかを確認します。変更可能としてマークされている場合、NoC でトランザクションをより効率的に動作させることができます。
    • データ幅変換を最小限に抑えます。

 

 

デザイン プロセス ハブ

ザイリンクスの資料は、デザイン ニーズに関連する内容を見つけやすいように、デザイン プロセスに基づいて構成されています。
デザイン プロセスに関する詳細情報については、次のデザイン プロセス ハブを参照してください。

 

 

サンプル デザインおよびチュートリアル

 

 

その他のリソース

 

 

 

 

 

more
5 0 401
kurihara
Xilinx Employee
Xilinx Employee

このブログでは、ザイリンクス Integrated block for PCI Express IP ( endpoint mode)に付属の PIO デザインを、マスター動作させるシミュレーション実行方法を紹介します。

概要:

Integrated Block for PCI Express IPを生成し、Example Designを開くと、ユーザー デザインとして PIO が作成されているのが分かります。このユーザー デザインは、基本的にルート ポートのトランザクションに応答するものですが、マスターとしても動作できます。

kurihara_0-1619138610257.png

 

 

マスター イネーブル ビットの設定

PCI Express デバイスをマスター動作させるには、先ず、バス マスター イネーブル ビットを設定する必要があります。

バス マスター イネーブル ビットは、PCI コンフィギュレーションレジスター内のコマンド レジスターのビット2にあります。

kurihara_1-1619138610270.png

 

PCI Express Base Specification, Rev. 4.0 Version 1.0, September 27. 2017, PCI-SIG

 

Example Designでバス マスター イネーブル ビットを設定するには、ルート ポート モデルに含まれているpcie_exp_usrapp_txモジュールから、TSK_TX_TYPE0_CONFIGURATION_WRITEタスクを実行して、エンドポイントに対してコンフィギュレーション書き込みトランザクションを発生させます。

kurihara_2-1619138610274.png

 

上記の例では、3845行目を次の様に変更します。

TSK_TX_TYPE0_CONFIGURATION_WRITE(DEFAULT_TAG, 12'h04, 32'h00000006, 4'h1);

*この時に、bit1 memory space enableを‘0’にしないように注意してください。

 

testnamepio_writeReadBack_test0 にする

pcie_exp_usrapp_txモジュールには、シミュレーションでのテストの種類を指定するtestname変数があります。この変数に pio_writeReadBack_test0 を指定します。

testname = "pio_writeReadBack_test0";

実際のテストのタスクは、 sample_tests.vh ファイル内に記載されています。

 

PIOをマスター動作させる

PIOをマスター動作させるには、BAR0のオフセット アドレス11’hEA8に32’hAAAA_BBBBを書き込むことで起動されます。sample_tests.vh を開き、 pio_writeReadBack_test0 以降のタスクに移動します:

kurihara_3-1619138610279.png

 

DATA_STORE変数に次のライト・データを指定します。

   board.RP.tx_usrapp.DATA_STORE[0] = 8'hBB;

    board.RP.tx_usrapp.DATA_STORE[1] = 8'hBB;

    board.RP.tx_usrapp.DATA_STORE[2] = 8'hAA;

    board.RP.tx_usrapp.DATA_STORE[3] = 8'hAA;

 

TSK_TX_MEMORY_WRITE_32タスクのターゲット アドレスを次のように変更します:

board.RP.tx_usrapp.TSK_TX_MEMORY_WRITE_32(board.RP.tx_usrapp.DEFAULT_TAG,                                                                 board.RP.tx_usrapp.DEFAULT_TC, 11'd1,                                                                    board.RP.tx_usrapp.BAR_INIT_P_BAR[board.RP.tx_usrapp.ii][31:0]+11'hEA8, 4'h0, 4'hF, 1'b0);

これで準備が整いましたので、シミュレーションを実行します。

kurihara_4-1619138610282.png

 

kurihara_5-1619138610286.png

 

1DWのメモリー 読み出しトランザクションが発行されます。

 

 

結果、32’h03020100のCompletionが返信されます。

kurihara_7-1619138654008.png

 

more
5 0 370
karnanl
Xilinx Employee
Xilinx Employee

Versal で複数のクワッドにトランシーバー設定を作成するには、まず Transceiver Bridge IP で設定を選択してから、Vivado でブロック オートメーションを実行してこの設定に必要なクワッドを作成することを推奨します。

Transceiver Bridge IP では、設定が 1 つのみ可能です。では、どのようにして同じトランシーバー内の TX RX に個別の設定を持たせることができるのでしょうか。この方法の例は本ブログで解説されます。

Read more...

more
0 0 380
kurihara
Xilinx Employee
Xilinx Employee

このブログは、英語版Debugging Versal ACAP Integrated Block for PCIe Express link issues using in-built "PCIe Link Debug" featureを翻訳したものです。

 

Versal™ ACAP Integrated Block for PCI Express® コアのカスタマイズでは、PCIe® のリンク デバッグをイネーブルにするオプションが提供されています。

このオプションをイネーブルにすると、Vivado ハードウェア マネージャーによって認識されるデバッグ コアが IP コアに挿入され、PCIe 固有のデバッグ情報とビューが提供されます。

デバッグ ビューには、現在のリンク速度、現在のリンク幅、および LTSSM ステート遷移に関する情報が表示されます。これにより、PCIe リンクに関する問題のデバッグが容易になります。

これは、Versal デバイスに追加された新機能です。UltraScale デバイスと UltraScale + デバイスでも同様の機能を使用できますが、これらの機能を使用するには追加の手順を実行する必要があります。これらの機能については、以前のブログ エントリを参照してください。

Vivado には、Versal デバイス用のビルトイン デバッグ コックピットがあり、Vivado GUI フレームワーク内で LTSSM 図およびその他のデバッグ関連情報が表示されます。

このブログは、『Versal ACAP Integrated Block for PCI Express 製品ガイド』 (PG343) に記載されている付録「PCIe Link Debug Enablement」を補うものです。このブログでは、この内容をわかりやすくするために、それぞれの手順にスクリーン ショットを含めて紹介します。

 

デザインの生成

 

VCK190 ボードを選択します。このブログで説明するデザインは、Vivado 2020.2 用です。

Vivado で選択したボード デバイスとボード上のデバイスが一致していることを確認してください。早期バージョンの VCK190 ボードには ES1 デバイスが含まれています。 

kurihara_66-1616463746504.png

IP カタログで [Versal ACAP Integrated Block for PCI Express (1.0)] を選択します。ビルトイン デバッグ機能を使用するには、次に示すように、[PCIe-Link Debug] および [Enable Debug AXI4 Stream Interfaces] を選択する必要があります。

[Link Parameters] には、次に示すように Gen3x8 を選択できます。リンク トレーニングに問題がある場合は、まず Gen1x1 設定を試してください。

kurihara_67-1616463786795.png

IP が生成されたら、[Sources] ウィンドウに次が表示されます。

kurihara_68-1616463816735.png

CIPS MIO 38 をリセット ソースとして使用するには、次の (PG343) のスクリーン キャプチャで説明されているように、サンプル デザインを開く前に insert_cips true に設定します。

これにより、MIO ピンから Versal ACAP Integrated Block for PCIe Express IP (PL PCIe) にリセットが転送されます。

mio_pl_38 ピンが pcie_phy および PL PCIe に接続されていることを確認します。これらの接続は、次の回路図でオレンジ色で示されています。

kurihara_69-1616463839768.png

kurihara_71-1616463894127.png

kurihara_72-1616463914610.png

上記のスクリーン キャプチャでは、IP と共に配布されるサンプル デザインを生成するオプションを示しています。
[Open IP Example Design]
をクリックすると、新しいプロジェクトが開き、[Sources] ウィンドウにファイル階層が表示されます。

kurihara_73-1616463959935.png

 

kurihara_74-1616463973651.png

 

kurihara_75-1616463989017.png

 

kurihara_76-1616464005251.png

 

REFCLK および GT LOC 制約が表示されていることを確認します。VCK190 ボードには、これらの制約が必要です。これらの制約は、VCK190 ボードを選択すると自動的に生成されます。

kurihara_77-1616464042556.png

 

ES1 デバイスを含む VCK190 ボードを使用している場合は、回避策を適用する必要があります。

次に示すように、PMC MIO 37 に該当するパラーメーターを設定します。

kurihara_78-1616464075299.png

 

上記の変更後に IP をアップデートする必要があります。 

kurihara_79-1616464105147.png

 

サンプル デザインをインプリメントした後、I/O ポートとクロックが次に示すピン ロケーションとクワッドにマップされていることを確認します。

VCK190 ボードには、次のピン ロケーションが必要です。 

kurihara_80-1616464131965.png

 

 

PCIe デバッガー

 

デバイス イメージの生成後、生成された PDI ファイルおよび LTX ファイルをダウンロードします。ダウンロード後には、次に示すような LTSSM 図が表示されます。

これが Versal デバイスに追加された新デバッグ機能です。この機能は UltraScale UltraScale+ など以前のデバイスではサポートされていません。UltraScale デバイスと UltraScale+ デバイスでは、同様のデバッグ機能を使用できますが、LTSSM 図を生成するための Tcl ファイルを個別に実行する必要があります。 

kurihara_81-1616464166685.png

•緑色 - キャプチャ ウィンドウ中の遷移ステート
•オレンジ色 – 最終ステート
•赤矢印– 最後の遷移ステート
•矢印の横の数字は 2 つのステート間で発生した遷移数を示します。

デバッグ コックピットには、ほかにもデバッグ機能があります。[PCIe Debug Core Properties] ウィンドウでは、レーン ステータスおよび PCIe Lane 0 を持つクアッド番号を確認できます。

kurihara_82-1616464201193.png

同様に、GT ステータスも [GT Group Status] ウィンドウで確認できます。 

kurihara_83-1616464227322.png

 

kurihara_85-1616464254977.png

 

Tcl コンソールでは、次に示すように report_hw_pcie コマンドを実行できます。

レポートには、一般的な PCIe ステータスが含まれることに加え、ltssm ステートのリストとこれらのステートがリンク トレーニング プロセス中にアクセスされたかどうかが表示されます。

kurihara_86-1616464276103.png

report_hw_pcie コマンドには適用できるオプションがいくつかあります。次に示すように、-help オプションを実行するとオプションの詳細を確認できます。

kurihara_87-1616464305004.png

 

その他の PCIe のコマンドは、次の通りです。

  • get_hw_pcies
  • reset_hw_pcie
  • refresh_hw_pcie

[PCIe Debugger] ウィンドウで LTSSM ステートを選択すると、対応する ltssm ビット デコードが [PCIe State Properties] ウィンドウに表示されます。

kurihara_88-1616464335811.png

ltssm ビット デコードのリストは、製品ガイドに記載されています。または、次に示すように report_hw_pcie コマンドを実行しても、リストを表示できます。

kurihara_89-1616464362814.png

 

In-System IBERT

 

デバッグ コックピットでは、アイ ダイアグラムを簡単に生成できます。まず、[Create links] をクリックします。後続のステップは、次に示すように、見ればわかるようなステップになっています。

kurihara_90-1616464403527.png

 

kurihara_91-1616464418088.png

 

kurihara_92-1616464433337.png

 

kurihara_94-1616464460271.png

 

kurihara_95-1616464480102.png

 

kurihara_96-1616464493796.png

 

kurihara_97-1616464506337.png

 

more
5 0 530
takayos
Xilinx Employee
Xilinx Employee

FPGA/ACAPの開発において、論理合成、インプリメンテーション、という工程が必要であり、各工程がおおよそどの様なものかはある程度ご理解頂いているかと思います。

 

ここでは論理合成が持つ最適化機能に焦点を当て、実機で予期せぬ動作を起こさない為に、知っておきたい要点を説明させて頂きたいと思います。

 

まず、論理合成とはHDLをターゲットアーキテクチャのCellに置き換え、ネットリストを生成する工程です。

当然ながらHDLとネットリスト間の論理の等価性は担保されます。

ただし、ASICの論理合成がHDLの記述通りのネットリストを生成するのに対し、FPGA/ACAPの論理合成では必ずしも全くHDLと同じネットリストが生成されるわけではありません。

FPGA/ACAP上の限られたリソースを最適に、効率よく使用するために“最適化”が行われるからです。

例えば、

信号Aを2つのFFが受け、それぞれが10FanoutするHDL場合、FPGA/ACAPの論理合成時には実際にはFFは1つとし、それが20Fanoutするネットリストになることもありえます。 

a.jpg

 

見ての通り、もちろん論理の等価性は保証されます。

しかしながら、論理の等価性の担保だけでは問題を引き押す可能性のある個所があります。

 

そもそも論理の等価性とはなんでしょうか?

それは入力論理に対する出力論理が同じである、というものです。

例えば、単純な掛け算を例にとれば、1と0を入力したら0と出力する、というものです。

入力論理(=入力信号)と出力論理(=出力信号)にはサンプルタイミングがあり、現在では同期設計が前提の為、同期のタイミングでのサンプリング結果において論理の等価性を保証しています。

逆に言えば、同期のタイミングでない箇所においては注意が必要ということで、これが前述の論理の等価性の担保だけでは問題を引き押す可能性のある個所にあたります。

具体的には、

 

  • センシティブな信号(非同期セット、非同期リセット、双方向端子の制御端子,etc
  • 非同期クロック間で受け渡される信号

 

です。

 

では次に、その注意が必要なFPGA/ACAPの論理合成で行われる最適化について述べます。

具体的には、

 

  • FSM encoding
  • Retiming
  • SLR extraction

 

です。

それぞれがどの様な機能なのか詳細に関してはUG901をご参照下さい。

今回は簡単に(乱暴に?)以下のように纏めます。

初めの2つは“HDL内のFFLogicの組み合わせが最適化され、FF出力の信号がロジック出力となる可能性がある“

最後の1つは“HDL内のFFのシフトレジスタが最適化され、SLRに変わる可能性がある“

です。

 

具体的に見ていきます。

HDL上のFFLogicの組み合わせを最適化する、それによりFF出力の信号がロジック出力となる可能性がある“とはつまり何でしょうか?

例えば以下のような回路があったとします、

 

入力信号=>FF1 => 論理ALUT=> FF2 => 出力信号

 

これが最適が行われた結果、

 

入力信号=>FF3 => 論理BLUT=> FF4 => 論理CLUT=>  出力信号

 

となる場合があります。

入力信号に対する出力信号は同じです(論理の等価性は保証)。違いはFFの出力だったものがLUTの出力なっている点です。 

それではなぜ注意が必要なのか?

それは、出力信号にグリッジが発生する可能があるからです。

 

グリッジはインプリメントの結果、各信号の配線遅延の差分によって生じる可能性あるものです。

例えば、以下の様な回路があったとします。

 

B.jpg

 

FFAFFBは同じタイミング(クロックエッジ)でそれぞれ0=>1、1=>0へ変化したとします。その結果、信号はあくまで0のままです。

 

c.jpg

ところが、これは信号に遅延のない理想的な世界の話です。

実際には(実機上では)各信号には遅延があるため、例えば以下の様なことが起こります。

 

d.jpg

 

配線遅延の差により信号Cにグリッジが発生しています。

ただし、タイミングがメットしているデザインであれば、次のアクティブクロック(図の青線のタイミング)までには収束するため問題にはなりません。

先述の通り、注意が必要となるのはそれらの信号が、

 

  • センシティブな信号(非同期セット、非同期リセット、双方向端子の制御端子,etc
  • 非同期クロック間で受け渡される信号

 

な場合です。

なぜなら、タイミングによりこのグリッジをサンプリングしてしまう可能性があるからです。

それでは予期せぬ動作を引き起こす可能性があります。

また、通常の機能検証は信号に遅延がない状態での検証なので、その様な状態は確認できません(配線遅延付き機能検証なら可能です)。

 

それでは、

 

  • センシティブな信号(非同期セット、非同期リセット、双方向端子の制御端子,etc
  • 非同期クロック間で受け渡される信号

 

があるデザインでは上記の最適化は無効とした方がいいのでしょうか?

答えは、いいえ、です。

これらの最適化がデザイン全体もたらすタイミング、リソース的な恩恵は少なくありません。

むしろ最適化が問題となるケースの方が非常に稀です。

その稀に問題となることを防ぐために、先の注意が必要な個所に適切な処置をしてあげればよいのです。

要するにFF出力のままである必要がある、

 

  • センシティブな信号(非同期セット、非同期リセット、双方向端子の制御端子,etc
  • 非同期クロック間で受け渡される信号

 

の、出力元には“DON’T_TOUCH”制約を与えてください。

DON’T_TOUCH”制約は付与された対象があらゆる最適化から除外され、HDLの設計のままネットリストとなります。

(なのでHDLの設計に問題があればもちろん問題は生じますが。。。)

 

次に、

 

HDL内のFFのシフトレジスタが最適化され、SLRに変わる可能性がある“

 

ですが、これは単純にFFで構成したシンクロナイザー(同期化回路)がSLRに置き換わってしまう、危険の事です。

それら同期化回路にはASYNC_REGプロパティを与えてください。

DON’T_TOUCHでもよさそうですが、ここはASYNC_REGにしてください。なぜならASYNC_REGが付与されたFFはなるべく近くに配置されるようインプリメント工程でもメリットがあるからです。

 

この2点は必須かと言えばデザイン上(設計構成上)不必要な場合もあると思います。

ただ、このような合成時の最適化のリスクを理解することで潜在的な問題の回避、および実機での問題発生時のデバック効率向上、など恩恵はあると思います。

 

問題を含んでいるか確認が大変だ、という方は report_cdc コマンド を使用してデザインをチェックしてみてください。

上記のような潜在的な問題のほとんどを検出することが可能です。

 

最後に、他にも有益な情報はUG949にも記載されているため併せてご参照ください。

ありがとうございました。

more
5 0 733
katsuki
Xilinx Employee
Xilinx Employee

このブログは、英語版のBringing Up a 1G Ethernet Interface on a Versal deviceを翻訳したものです。

 

Versal ACAP (Adaptive Compute Acceleration Platform) は、進化する多様なアルゴリズムに適用できる高度に統合されたマルチコア コンピューティング プラットフォームです。

VCK190 は、最初にリリースされたザイリンクス Versal AI コア評価ボードの 1 つです。

このブログ記事では、次の手順でそのデザインを作成する方法を示します。

 

1.Vivado での Versal ベースの IP インテグレーター デザインの構築

2.デバイス イメージの作成

3.Vitis でのプラットフォームとシステム プロジェクトの構築

4.VCK190 評価ボードでのアプリケーションの実行とデバッグ

Read more...

more
4 0 692
kshimizu
Xilinx Employee
Xilinx Employee

このブログは、英語版のVideo Blog - Implementing the UHD-SDI TX subsystem in a TX only design on a ZCU106 boardを翻訳したものです。

 

UHD-SDI サブシステム RX/TX IP コアには、現時点で数個のサンプル デザインがありますが、すべてパススルー デザインです。これらのデザインの詳細は、『SMPTE UHD-SDI Transceiver Subsystem LogiCORE IP 製品ガイド』 (PG289: 英語版日本語版) および『SMPTE UHD-SDI Receiver Subsystem 製品ガイド』 (PG290) を参照してください。

このブログでは、ZCU106 開発ボードをターゲットとする TX のみのデザインを作成して実行する方法を説明します。

 

samk_0-1604615662095.png

 

注記: このデザインは現状のまま提供されるもので、動作は保証されません。手順を説明する目的で、通常のリリース/テストフロー外で構築されています。

このデザインは、SR ポータルではサポートされません。このデザインで問題が発生した場合は、ザイリンクス ビデオ フォーラム ボードをご活用ください。

 

このデザインは、Vivado 2019.2 ツールセットを使用して、SDI TX システムを ZCU106 Rev 1.0 ボード上でビルドおよび実行する方法を示します。

このデザインは、製品ガイドでリリースされたパススルー デザインをベースに、TX のみ用の変更を加えて作成されています。UHD-SDI TX サブシステムと UHD-SDI GT を TX のみのモードでインプリメントする手順を示すことを目的としています。

次のものが含まれています。

  • リセット機能
  • IP コアを制御する Zynq サブシステム インスタンシエーション
  • ステータスを監視する GPIO (元のパススルー デザインからのもの)
  • ビデオ データを生成する TPG
  • TPG を 8 BPC から 10 BPC に変換するサブセット コンバーター
  • FIFO (元のパススルー デザインからのもの)
  • UHD-SDI TX サブシステム
  • UHD-SDI GT

Onmitek4K Ultra を使用して機能がテストされています。

 

2020-11-24 15_37_55-xcoapps63_6 (xcoapps63_6 (samk)) - VNC Viewer.png

 

提供されているスクリプトを使用したビットストリームの作成

1. コマンド ラインまたは Vivado ターミナルで、ディレクトリから Tcl スクリプトを実行します。

Vivado -source v_smpte_uhdsdi_rx_ss_0_ex.tcl

2. スクリプトが完了したら、Vivado を起動してビットストリームを生成します。
    これは、スクリプト モードで実行するか、Vivado GUI を開いて合成、インプリメンテーション、ビットストリーム生成フローで実行します。 

3. ビットストリームを生成したら、XSA ファイルをエクスポートします。

 

 

XSA からの ELF ファイルの作成

1. Vitis GUI を開きます。

2. 新規プラットフォームを作成し、Vivado プロジェクトからエクスポートした XSA を指定します。
samk_0-1604615769518.png

 

samk_1-1604615769527.png

3. ビルド ツールを使用して BSP をビルドします。

samk_2-1604615769534.png

 

4. BSP をビルドしたら、[Drivers] セクションの [Import Examples] リンクをクリックします。

samk_3-1604615769536.png

 

5. xsdi_example をインポートします。

samk_4-1604615769538.png

 

6. /src にあるxsdb_* ファイルを /SW にあるファイルに置き換えます。
    これらのファイルは、TX のみのハードウェア デザイン用に変更されています。

7. ビルドしてテストします。次の図に、UART コンソールを示します。
    注記: ビルドおよびテストの詳細は、『SMPTE UHD-SDI Transceiver Subsystem LogiCORE IP 製品ガイド』 (PG289: 英語版日本語版) および『SMPTE UHD-SDI Receiver Subsystem 製品ガイド』 (PG290) を参照してください。

samk_5-1604615769541.png

 

 

  • [Kudos] ボタン  をクリックして Kudos (拍手) しましょう。kudos.JPG
  • [Share] ボタン をクリックして、ソーシャル メディアで共有してください。share.JPG

     

  • このトピックにコメントしたり、新しいトピックをフォーラムで作成し質問してください。

 

 

more
5 0 565
takayos
Xilinx Employee
Xilinx Employee

このブログは、英語版の Using the Methodology Report Part Three: Timing is met but there are DDR4 calibration failures in hardware  を翻訳したものです。

このブログ エントリの解析は、DDR4 キャリブレーションでエラーが発生するというお客様の実際の問題に基づいています。このエラーが発生するかは、ボード、ビルドによって異なりました。このブログでは、根本的な原因を絞り込み、問題を修正するために使用したデバッグ手法の一部を紹介します。

最終的には、ユーザー制約の XDC set_false_path により MIG IP 制約がオーバーライドされたことによってこの問題が発生したことがわかりました。この結果から set_false_paths を正しく使用することが重要であることがわかります。

このブログは、設計手法レポートの使用方法シリーズのパート 3 です。シリーズのすべてのエントリについては、このページを参照してください。

問題について

ユーザーは Vivado フローと SDx フローの両方を使用したデザインを使用していました。このデザインには、2000 Mbps で動作する 2 つの DDR4 64 ビット インターフェイスが含まれていました。デザインのタイミングは満たされましたが、DDR4 インターフェイスの 1 つ、場合によっては両方で、キャリブレーション エラーが発生しました。

ハードウェアのエラーは、ビルドに依存していました。

  • エラーが発生しなかったビルドは、複数のボードで正しく動作しました。
  • エラーが発生したビルドは、複数のボードでエラーが発生しました。
  • 一方または両方のインターフェイスで、ほとんどの場合でエラーが発生しました。
  • エラーが発生したビットは、ビルドによって異なりました。

デバッグ方法:

エラー シグネチャにタイミング制約または CDC の問題が示されているため、次の手順に従いデバッグします。

1) ILA を追加してデザインをインプリメントし直します。

これでエラーが発生しなくなるか、または別のビットに移動します。

インクリメンタル インプリメンテーション フローを使用してエラー シグネチャを保持します。

3) タイミング クロージャを容易にするためにILA にパイプライン段を追加します。

このテストの目的は、エラーが発生している段階で予期パターンを見つけ、エラーが発生しているビットを絞り込むことです。

4) MIG IP の配置距離間をなるべく縮めるように p ブロックを使用します。

この場合、エラー シグネチャは変更されません。

  • タイミングを満たしているインターフェイスがハードウェアでエラーになる
  • タイミングが満たされていないインターフェイスがハードウェアでエラーにならない

上記に基づくと、一部の MIG 制約がユーザーまたは Vivado フローによってオーバーライドされていることに問題があるように見えます。

次に、XDC 制約を確認します。

クロック間の多くのフォルス パス制約がユーザーによって設定されていることがわかります。

次に、推奨されるレポートを実行します。このうち重要なのは report_methodology report_cdc レポートです。

  • Report CDC
  • Report methodology
  • Report exception
  • Report MIG set_max_delay (これらの制約が無視されたかを確認するため)

根本的な原因の解析:

MIG set_max_delay パスが無視されていませんでした。

最大遅延が report_timing によってレポートされています。

一部の MIG パス (ファブリックから PHY) でクリティカル CDC 警告がレポートされています。

次に、これらのパスを、IP integrator フローを使用して作成した、安全にタイミング解析される MIG デザインの例と比較します。

takayos_2-1614212643954.png

 

これらの結果に基づいて、ユーザーが追加したすべてのフォルス パス制約を削除し、フル デザインをインプリメンテーションし直さずにタイミングを再度レポートします。

このレポートには、ワースト ケースで DDR4_rx/tx の両方のタイミング エラーが 3 ns を超えることが示されています。

タイミング サマリ レポートの適用範囲限定のメカニズムを活用して、MIG インターフェイスのみに焦点を絞って解析を実行します。

 

takayos_3-1614212644015.png

 

ここでは、ユーザーが追加したフォルス パス制約により、ファブリックから PHY へのパスが無視されることがわかります。

解決策:

  • 上記のフォルス パスをターゲット XDC から削除し、デザインをインプリメンテーションし直します。
  • デザインは、以前と同様にタイミングに問題がありません。
  • CDC レポートには、以前に無視されたパスが安全にタイミング解析されることが示されます。
  • ハードウェアでビット ファイルをテストすると、両方の DDR4 インターフェイスのキャリブレーションが正しく実行されました。

まとめ:

set_false_path 制約を使用するときは細心の注意を払ってください。

この制約によりタイミング解析が必要なパスが無視されてしまう可能性があります。このような制約でワイルドカードを使用したり、クロック ドメイン全体にフォルス パスを設定する場合は、それらの間のパスにタイミング解析が必要ないことを必ず確認する必要があります。確認を怠った場合、ハードウェア エラーが発生し、その後のデバッグ プロセスが困難で時間がかかる可能性があります。

タイミングが満たされているデザインでハードウェア エラーが発生する状況に直面した場合、Vivado で実行できるチェックが多数あります。これらのチェックは、特に配置配線後には、常に実行する必要があります。タイミングが満たされているだけでは十分ではなく、これらチェックを必ず完了する必要があります。

1) クロック関連性レポート:

デザインに含まれるすべてのクロックの情報がレポートされます。

2) 設計手法レポート

安全ではないパスまたはユーザーが無視したパスが検出された場合は、設計手法レポートを使用して、クリティカル警告に注目します。

3) CDC レポート

この例では、レポート CDC レポートを使用してユーザーの制約が原因で無視されたクリティカル パスを特定しました。

これらの結果を MIG のデザイン例と比較することで、設計に存在する数百万のパスから疑わしいパスを見つけることができました。

このレポートを使用すると、適用範囲限定のメカニズムを使用して、選択したモジュールに分析を絞り込むことができます。

4) 例外レポート

このレポートでは、set_false_paths set_clock_groups などのタイミング例外が存在する場合、これらによって無視されたパスに関する情報を確認できます。

その他のヒント:

非常に大規模なデザインでは、数百万のパスを解析するのは非常に困難で時間がかかります。

迅速なターンアラウンドを実現するには、次のコマンドを使用してレポートの範囲を絞り込みます。

[Schematic] ウィンドウでインスタンスをハイライトするには、次を実行します。

report_cdc -cells [get_selected_objects] -details -name <cdc_report_xyz>
report_timing_summary -cells [get_selected_objects] -name <report_xyx>

set_max delay が無視されているかどうかを確認するには、次を実行します。

report_timing -from [get_pins */*/*/*/slave_rdy_cptd_sclk_reg/C] -to [get_pins */*/*/*/u_slave_rdy_cptd_sync/SYNC[*].sync_reg_reg[0]/D] -name t3

上記のタイミング パスは、MIG XDC に含まれています。

-name オプションを使用すると、GUI にレポートを表示できます。

 

more
4 0 459
katsuki
Xilinx Employee
Xilinx Employee

本ブログでは、

  • Linuxの git diff コマンドで生成されたPatchファイルを、Petalinuxツールで使用する事例
  • Petalinuxツールを使ったPatchファイルの作成事例

を紹介します。ツールバージョンは2020.2、評価ボードVCK190-ES1を使用します。

Read more...

more
5 0 1,199
kurihara
Xilinx Employee
Xilinx Employee

このブログは、英語版のDebugging PCIe Issues Using Pythonを翻訳したものです。

 

このブログでは、ザイリンクス PCIe デザインのデバッグに Python スクリプトを使用する例を紹介します。このブログに添付されているスクリプトは、コミュニティ メンバーのご協力の元、作成されています。

ここで説明する方法と同じような方法を既に使用している場合、または提供されたスクリプトをさらに改良する場合、当社と共有していただければ、このフォーラムの PCIe コミュニティ メンバーと共有させていただきます。

提供されている手法はすべてのデザインに適用できるようになっています。PCIe のみに適用できるわけではありません。

Read more...

more
6 0 704
kshimizu
Xilinx Employee
Xilinx Employee

概要:

本ブログは、Memory Interface Generator(MIG) をインプリメンテーションするための PCB 設計のガイドラインについて説明します。具体的には、サンプルデザインの動作確認の方法について説明します。

 

 

メモリ インターフェイスの開発フロー:

評価、設計の段階に応じて行うべき開発手順をわけることができます。この記事ではPCB設計の中のサンプルデザインインプリメンテーションに該当します。

01.PNG

今までのブログも参考にしてください。

 

 

サンプルデザインのインプリメンテーション:

PCB基板完成後に、MIGのサンプルデザインのみをインプリメンテーションして動作確認を行います。ユーザ回路を省くことにより、ユーザ起因の不具合を省くことが目的です。

  • サンプルデザインの作成方法は、メモリ インターフェイスのデバッグ テクニック2 – MIG サンプル デザインの生成 に記載されていますので参照してください。PCBの配線設計前にサンプルデザインでビットストリームを生成できることを確認しています。このビットストリームを使用して完成したPCB基板にサンプルデザインをインプリメンテーションします。
  • MIGsys_rstがアサートされるとキャリブレーションを開始します。キャリブレーションが正常に実施された場合は、init_calib_done信号をHighにアサートします。キャリブレーションの成功可否に関する信号であるため、必ず観測できるようにしてください。可能な限り複数枚のPCB基板で確認して、状況把握することを推奨します。

2.PNG

  • MIGのサンプルデザインには、アドバンスド トラフィックジェネレータを接続することができます。PRBSHammerwalkingパターンを選択してPCB基板の評価をできます。詳細および手順はPG150(英語日本語)Section VIIに記載がありますので、参照してください。

4.PNG

 

3.PNG

5_2.PNG

 

 

 電源確認:

  • MIG PCB ガイドラインは、UltraScale アーキテクチャ PCB デザイン(UG583 : 英語版日本語版) に記載されています。厳密に満たすように設計してください。メモリ インターフェイスのデバッグ テクニック3 – PCB ガイドラインも参照してください。
  • VCCINTVCCAUXVCCOVrefVddを測定し、規定を満たしていることを確認してください。上書きモードによるノイズレベル評価、閾値値トリガーによるイベント評価方法があります。
  • 電源測定のタイミングは、以下の3つの場合があります。製品段階では、3.ユーザ回路を含んだデザインで電源測定を実施するようにしてください。
    1. サンプルデザインのキャリブレーション中の電源測定
    2. サンプルデザインのトラフィックジェネレータ実行中の電源測定
    3. ユーザ回路を含んだデザインでの電源測定

 

 

システムクロックの信号品質の確認

  • sys_clkの入力 ク ロ ッ ク周期ジ ッ ター ≤ 50ps Peak-to-Peak 値であることを確認してください。
  • 入力クロックは、MMCMに接続されます。デューティサイクル等は、各FPGAデバイスのDC特定およびACスイッチ特性のMMCMスイッチ特性を参照してください。Kintex UltraScaleの場合は、DS892MMCM Switching Characteristicsに該当します。

5.PNG

 

 

信号品質の確認

メモリ インターフェイスのデバッグ テクニック3 PCB ガイドラインに記載している通り、PCB基板設計の時に、メモリインターフェイスの信号品質を確認できるように設計をしています。

  • 制御信号とメモリクロック間の測定
    • 制御信号の振幅およびセットアップタイム / ホールドタイムの確認をします。
  • ストローブ信号とデータ間の測定
    • データ信号の振幅、データとDQSの位相関係を確認します。
    • ストローブ信号の振幅、反射を確認します。
  • IBISシミュレーションと実機測定の結果を比較して、予測どおりの値になっていることを確認してください。

 

 

XSDBマージン確認:

  • MIG IPには、XSDBデバッグサポートが含まれます。MIG IPはキャリブレーション、コンフィグレーションやデータウィンドウに関する情報を内部ブロックRAMに格納します。XSDBを使用すると、それらの情報をブロックRAMから読み出して重要な統計情報を出力することができます。

6.PNG

  • MIGのキャリブレーションが完了すると、XSDBでマージンを確認することができます。一般的な目安として、安定したシステムではUIサイズの30%以上のウィンドウサイズを確保することを推奨しています。

7.PNG

 

more
5 0 632
karnanl
Xilinx Employee
Xilinx Employee

このブログは、英語版の Versal GTY Simulation: Initialization, Reset and Rate Change を翻訳したものです。


このブログでは、Versal™ GTYシミュレーションの例を取り上げ手数料、GTYがリセットから抜け出し、ラインレート変更の実行する方法を示します。

Versal ACAP GTYトランシーバーには、マスターリセットコントローラー(Master Reset Controller)が導入されています。

マスターリセットコントローラーは、LCPLL、RPLL、ILO、TXプログラマブル分周器、RXプログラマブル分周器、TXチャネル、およびRXチャネルのリセットを自動的に実施します。

詳細な説明は、AM002のトランシーバーマスターリセットセクションで確認できます。 GTY内の新しいマスターリセットコントローラーは、前世代のUltraScale / UltraScale +トランシーバーのGTウィザードに含まれていたリセットコントローラーヘルパーブロックに置き換わるものです。

以下のサンプルシミュレーションでは、Versal GTYは次のように構成されています。

  • チャネル2(ch2)の単一チャネル
  • 2つのラインレート設定、10G / 25GがCONFIG0 / CONFIG1にプログラムされています
  • 両方のラインレートで、REFCLKは156.25MHzであり、同じ基準クロックポートから供給されます。

本IPサンプルデザインは、FPGAデザインを完成させ、シミュレーションテストベンチを提供するために使用されます。


ブロック図
サンプルデザインのブロック図を下図に示され、
ブロックデザインTclスクリプト(run.tcl)が本ブログで添付されています。

PIC1.png

Vivadoの生成手順

gt_quad_base IPを作成し、IPサンプルデザインを開きます

1. gt_quad_baseIPを作成します。この場合、チャネル2でシングルレーン構成を使用しています。

2. Transceiver Configs Protocol 0をクリックして、トランシーバーをカスタマイズします。

PIC2.png

3. CONFIG0は10.3125Gbpsを設定します

PIC3.png

4. CONFIG1は25.78125Gbpsを設定します。

PIC4.png

5. IP Integratorキャンバスで、gt_quad_baseを右クリックし、[Open IP Example Design]を選択します。

PIC5.png

これにより、新しいVivadoプロジェクトにサンプルデザインが作成されます。

 

シミュレーションの実行

サンプルデザインは、クロックとリセットに必要な接続がすべて確立されて、トップレベルのシミュレーションテストベンチ(gt_quad_base_exdes_tb.sv)も生成されます。

サンプルデザインプロジェクトで、[Run Simulation]をクリックしてシミュレーションを開始します。

  PIC6.png

観測したい重要な信号を含んだシミュレーション波形は次の図で示します。

SIM_WAVEFORM.png

リセットのシーケンス

Versal GTYに含まれているマスターリセットコントローラーはbridge_ipのリセットシーケンスに使用します。詳細については、(AM002) のトランシーバーマスターリセットのセクションを参照してください。

1.T = 0.8nsで、gt_reset_ip0がアサートされ、リセットシーケンスが開始されます。
2.リセットコントローラーステートマシンは、リセットシーケンスを開始する前に、最初に
 gtpowergoodがアサートされることを待ちます。 (gtpowergoodはT = 34usでアサートします)
3. マスターリセットシーケンスを開始するためのtxmstresetおよびrxmstresetディアサートされます
 (1->0)
4. tx / rxmstresetデアサートされた後に、* resetdoneは1->0に変化します。
5. T = 50usで、lcplllockがアサートされます。
6. T = 52usで、txpmaresetdoneがアサートされた後、txuserrdyがhighとなり、txresetdoneが
 アサートされた。その後txmstresetdoneがアサートされます。 bridge_iptx_resetdone_out_ip0も
 アサートします。これでTXリセットシーケンスは完了です。
7. T = 53usで、rxpmaresetdoneがアサートされ、次にrxuserrdy、rxresetdone、rxmstresetdone、
 最後にrx_resetdone_out_ip0が続きます。これでRXリセットシーケンスは完了です。
8.これで、GTYはデフォルト(CONFIG0)のレート(rate_sel_ip0 = 0)で稼働しています。

 

レート変更

レート変更シーケンスは、rate_selポートを目的のレートに変更することによって開始されます。必要なリセット、クロック切り替え、および属性の更新が自動的に実行されます。ユーザーは、現在のレート変更プロセスと必要なリセットシーケンスが完了したことを示すものとして、txresetdonerxresetdoneを待つ必要があります。

  1. T = 65usで、rate_sel_ip00→1に変更されます。これにより、レート変更シーケンスが開始され、GUIのCONFIG1(この場合は25Gbps)で設定された新しいラインレートがターゲットになります。
  2. T = 86usで、txresetdoneがアサートします。 89usで、rxresetdoneがアサートします。これでレート変更シーケンスは完了です。
  3. これで、GTYCONFIG1レート(rate_sel_ip0 = 1)で稼働しています。

以上です。

more
3 0 679
takayos
Xilinx Employee
Xilinx Employee

このブログ エントリの解析は、別の OS と比較したときに QoR の品質が低下していた実際のお客様の問題に基づいています。ザイリンクスでは、(Xilinx Answer 61599) に記載されているように異なる OS 間の再現性は保証されていませんが、このケースでの違いの大きさはさらに調査する必要があります。

Windows では最初は良い結果が得られましたが、後に Linux の方でより良い結果が得られました。最終的には、この問題はデザインで見つかったスーパー クリティカルな設計手法違反に関連していることがわかりました。

 

問題について

同一のデザインで Linux Windows のタイミングに大きな違いが見られました。

OS で同一のデザインを実行したときに、Linux では WNS = -0.439 nsWindows では WNS = +26 ps でした。

ビルドを複数回異なるマシンで実行しましたが、どの OS でも同じ結果になりました。

次の [Design Timing Summary] のスクリーン ショットは、Linux でデザインを実行した場合のタイミング違反を示しています。Windows で実行したときはタイミング違反は見つかりませんでした。

注記: 次のオプションを使用すると、デザインのタイミング サマリを確認できます。

  • Vivado GUI で [Reports] タブ → [Timing] [Report Timing Summary] をクリックします。
  • 次の Tcl コマンドを実行します。

report_timing_summary -file <filepath>/timingreport.txt

 

Linux で実行した場合:

takayos_0-1608591914243.png

 

Windows で実行した場合:

takayos_1-1608591914260.png

 

根本的な原因の解析:

最初に、すべてのデザイン ソース、制約セット、合成およびインプリメンテーション指示子、および Vivado ツール設定が 2 つの OS 間で同一であることを確認します。また、一方の OSのみで Vivado パッチが使用されていたり、Vivado_Init.tcl ファイルでツール パラメータ-が設定されていないか確認します。

さらに、配置配線後に Tcl コンソールから write_xdc を実行することにより、両方のビルドに同じ制約が適用されていることを確認できます。

クロッキング/アーキテクチャ/CDC などに関連する警告/クリティカル警告を確認するには、設計手法レポートを開きます。

Vivado GUI で設計手法レポートを開くには、[Report] タブ → [Report Methodology] をクリックするか、または Tcl コンソールに「report_methodology」と入力します。

レポートが開くと、デザインに関連するいくつかの警告とクリティカル警告が表示される場合があります。

次に示すように、デザインのクロックの関係性に関する不適切な手法 (TIMING-6 および TIMING-7) が見つかりました。

takayos_2-1608591914283.png

 

Timing-6 クリティカル警告は、Vivado でタイミング解析が一緒に実行される 2 つのクロックが検出されたが、共通のプライマリ クロックがないことを示しています。

これらの 2 つのクロックは、共通のプライマリ クロックから派生しておらず、既知の位相関係がない場合でも、デフォルトでは関連性があり同期しているものとみなされ、タイミング解析が実行されます。この DRC 警告では、タイミング エンジンによりこれらのクロックを同期させることができない可能性があることがレポートされています。

Timing-7 クリティカル警告は、Vivado でタイミング解析が一緒に実行される 2 つのクロックが検出されたが、共通ノードがないことを示しています。この DRC では、2 つのクロック ツリー間の共通ノードが判断できないため、タイミング エンジンによりハードウェアでこれらのクロックを同期させることができない可能性があることがレポートされています。

設計手法のクリティカル警告は、場合によってデザインの QoR に影響する可能性があります。つまり、このようなクリティカル警告がデザインにあると複数回デザインを実行した場合に結果が同じにならない可能性があるということです。スーパー クリティカルとして処理する必要がある設計手法のクリティカル警告は、次のとおりです。

  • TIMING-6
  • TIMING-7
  • TIMING-8
  • TIMING-14
  • TIMING-35

デザインにこれらの違反があると QoR に影響を与える可能性があるため、できるだけ早く違反を解決する必要があります。

TIMING-6 および TIMING-7 - これらの警告およびクリティカル警告の解決方法:

解決方法は、2 つのクロック ドメインが非同期であるか、同期であるかによって異なります。クロックが非同期の場合、2 つのドメイン間のパスにタイミング例外 (set_max_delay -datapath_onlyset_clock_groupsset_false_path など) を使用する必要があります。

デザインを解析した結果、この DRC には set_false_path 制約を使用する必要があることがわかりました。

これらのクロック間のタイミング パスを検索するには、次のコマンドを実行します。

report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>].

TIMING-6、TIMING-7、および report_methodology のその他すべてのクリティカル警告と警告の詳細は、『Vivado Design Suite ユーザー ガイド: デザイン解析およびクロージャ テクニック』 (UG906) を参照してください。

 

解決方法と結論:

TIMING-6 および TIMING-7 違反を修正すると、Windows Linux の両方でデザインが同じ結果になりました。

ザイリンクスでは異なる OS 間での再現性は保証していませんが、上記のいずれかのスーパー クリティカル警告がデザインで見つかった場合は、QoR が低下する可能性があります。このケースでは、これらの違反が原因で、一方の OS が他方の OS よりも悪い結果になりました。

 

more
3 0 608
karnanl
Xilinx Employee
Xilinx Employee

こんにちは、

MIPI CSI-2 RX Subsystem, MIPI D-PHY RX IPを使用されるお客様から

IPが期待通り動作しない場合、何を確認すれば良いか分からないと連絡を受けております。

まずはMIPI IPの各ドキュメントに実機デバッグに関する情報があります。

PG232には “Appendix B” のHardware Debug
PG202には “Appendix B” のHardware Debug

PICT00.png

に基本確認項目が記載されており、最初の問題切り分けには役立つと思います。

せひ一度はご確認ください。

上記のドキュメント (PG232/PG202) “Appendix B”の補足するために、今回のブログを作成致しました。

3つのカテゴリーに分けてデバッグ確認項目を紹介したいと思います。

  (A) 初期化の問題
  (B) 物理的接続の問題
  (C) 設定/互換性の問題

 

(A) 初期化の問題

初期化時の問題はまずは以下の3つの信号のステータスを確認して頂きたいです。

PICT02.png

PLL_LOCK = 1 になっていますか?

PLL_LOCK = 1の場合は、内部PLLがロックしている状態なので問題はありません。
PLL_LOCK = 0の場合は dphy_clk_200M周波数が200MHzでない可能性があり、デザイン上のクロック設定や外部PLL ICが出力するクロック周波数をを再度確認してください。

Clocking.png

INIT_DONE = 1 になっていますか?

INIT_DONE = 1の場合初期化シーケンスが正しく実行されたことを意味しています。
INIT_DONE = 0の場合はMIPI IP初期化時、dphy_clk_200Mが不安定状態になっていないか?周波数が200MHzでない可能性があり?また初期化される際にクロック信号が停止していないか?

 

SYSTEM_RST_OUT = 0 になっていますか?

SYSTEM_RST_OUT=1の場合 MIPI D-PHY IPの初期化が完了していない可能性があります。
MIPI IPはリセットされたままでしょうか? または PG232/PG202に記載されたリセットシーケンスを実施されていますか?
RESET.png

MIPI IPのレジスタインターフェース
MIPI IPのレジスタ値を読み出すことで様々な情報を得ることができ、基板デバッグする際に各MIPI IPのレジスタ値の情報を把握することは欠かせません。
以下の図面で示したように、GUIでMIPI CSI-2 RX IP生成する際にまずは “Register Interface”をenableにすることを推奨致します。(基板上で MIPI IPが期待通りに動作したと確認されてから, “Register Interface” をdisableしても問題ありません)

Register.png

video_out_tvalid=0
MIPI CSI-2 RX IPが正しくリセットされない場合、video_out_tvalidの出力がlowのままになっている可能性もあります。MIPI CSI-2 RX IPが正しくリセットされても、video_out_tvalidの出力がlowのままの場合は、MIPI D-PHY RXがHS(High-speed)モードに入らないと考えらえます。
MIPI D-PHY RX レジスタを確認すると良いでしょう。CL_STATUS/DL_STATUSレジスタを何回かサ読み出しして頂き、クロックレーンと各データレーンの STOP_STATEとMODEを確認することでHSモードに入ったかを確認することができます。
STOP_STATE_MODE.png

また、PKT_CNT(=Packet Counter)というDL_STATUSレジスタのビット[31:16]を確認することで、MIPI TX対向側から送信されたHS packetが正しく受信することが確認できます。
MIPI RX IPが複数のデータレーン構成の場合、全データレーンのPKT_CNTを確認することが重要です。あるデータレーンのPKT_CNTの数値だけ、他のデータレーンの数値よりも小さい場合、そのデータレーンに不具合が発生する可能性があります。
PKT_CNT.png

RESETに関する注意

 UltraScale+ デバイスをご使用の場合、同じHP IO bankに複数のMIPI IPを実装されている場合があるかと思います。その際、すべてのMIPI IPに対して同時にリセット解除して頂く必要があります。詳細内容に関してはAR#71374の説明をご確認ください。

(B) 物理的な接続の問題

1. MIPI D-PHY RX IPでは差動信号のP/N swap機能がないため、ハードウェア上で MIPI D-PHYのクロックレーンとデータレーンの差動信号を正しく接続することが不可欠です。
P/N信号が逆に接続されてしまうと、MIPI D-PHY RX IPがLP mode⇒HS modeへの移行シーケンスを検出することが出来ないので、常にLPモードに入っており、HSモードに移行することができません。

CLOCK_DATA_LP_to_HS.png

2. データレーンのスワップ(Data Lane Swap)
データレーンのスワップ発生した時、 MIPI D-PHY RXのPKT_CNT(packet counterレジスタ)とMIPI CSI-2 RXのISR(Interrupt Status Register)の挙動を観測することで確認できます。

ISR.png

MIPI D-PHY RXのすべてのデータレーンのpacket counterが正常に動作しているものの、
MIPI CSI-2 RXのISR(Interrupt Status Register)で以下のビットがhighにアサートされる可能性があります。
   Bit[11] : ECC 2-bit error
   Bit[10] : ECC 1-bit error
   Bit[8]  : Unsupported Data Type

(C) 設定/互換性の問題
MIPI CSI-2 RX/MIPI D-PHY RXのIP設定は TXデバイス (またはセンサやカメラ)設定に合わせて使用して頂く必要がございます。
GUI.png

  1. LINE RATE設定

 弊社推奨として、 Sensor (TX側)のline-rateに合わせて、MIPI RX GUIを設定して頂きたいです。以下のARではMIPI D-PHY RXのラインレート設定に対して、どのぐらいのTX信号のラインレートを受信できるか、いわゆるRXラインレート設定のマージンという説明が記載されております。
https://japan.xilinx.com/support/answers/69530.html

2.データレーン数の設定

MIPI RX側のデータレーン数の設定も TX側の設定に合わせて使用して頂く必要がございます。
例えば、センサー側のデータレーンが2レーンでMIPI信号を出力した場合、MIPI RX側が4レーン設定でIP受信されても、MIPIデータ信号が正しく受信できません。
動的にTX側のレーン数を変更しながら、MIPI CSI-2 RXを使用したい場合、GUI上のEnable Active lanesオプションを有効に設定した上でIPを生成してください。
    Enable_Active_Lanes.png

PG232 Chapter3では Active lane設定の変更方法について記載されています。
ここも合わせて確認して頂きたいです。

Enable_Active_Lanes_PG.png

3.video_aclkの設定

多くのユーザーデザインではCPUのAXI4 streamクロックをそのまま MIPI CSI-2 RXのvideo_aclkに接続される場合が多いといです。 適切なvideo_aclk周波数選定も重要なIP設定となります。PG232 Chapter4では詳細なガイダンスが記載されているのでご確認ください。

video_aclk_freq.png

上記で記載されたvideo_aclkの最低周波数よりも遅い周波数を使用された場合,
MIPI CSI-2 RX内部のline bufferがoverflowする可能性があり、IPが出力するビデオデータに異常が見られます( 例えば、ビデオデータのpixel数が足りなかったり、Frame-Endフラグが出力されなかったりする場合もあります)。

4.CSI-2 規格の互換性

TX側がMIPI CSI-2 standard V2.0を対応したデバイスで、VCX(Virtual Channel Extention)やRAW16/RAW20のオプションが必要な場合のみ, “Support CSI spec V2_0” オプションを有効にしてIPを生成してください。
VCX_support.png

MIPI CSI-2 standard V1.2とV2.0では Packet HeaderのECC情報が変わってしまうので、MIPI TX側がV1.2の場合は “Support CSI spec V2_0” オプションを無効のままでIPをご使用ください。
Packet_Header_V2.0.png

5.DATA TYPEのサポート

MIPI CSI-2 RX Subsystem中にはVideo Format Bridge (VFB)モジュールが含まれており、受信したMIPI CSI-2規格のpacked dataをUG934に記載されているのAXI4-stream形式のpixelデータの変換してくれます。
VFB_overview.png

但し、VFBを使用する場合 GUI上で設定されたData TypeとRAW8以外のData Type
フィルタリングされるため、RAW8以外に複数のData Typeを使用される場合VFBオプションを無効にしてIPを生成してください。

VFB.png

以上となりますが、MIPI CSI-2 RX/MIPI D-PHY RXご使用の際、今回の記事がお役に立てれば幸いです。また次回別のMIPI IPのお話も書こうと考えています。それでは。

more
4 0 1,562
katsuki
Xilinx Employee
Xilinx Employee

このブログは、英語版の PetaLinux Image Debug Series: Debugging the Linux Kernel in Vitis を翻訳したものです。

概要

 

このブログでは、Vitisで、Zynq® UltraScale+ MPSoC の、Linuxカーネルイメージをデバッグする方法について説明します。

このブログでは、PetaLinux 2020.1を使用して、Zynq® UltraScale+ デバイス用の、Linuxイメージを作成する方法を紹介します。

このブログは、PetaLinux イメージのさまざまなコンポーネントをデバッグする方法を説明するシリーズの一部です。

 

その他のブログは、次のリンクから参照してください。

PetaLinux Image Debug Series: Debugging the Device Tree Generator ※翻訳予定

PetaLinux Image Debug Series: Debugging ARM Trusted Firmware and U-boot in Vitis ※翻訳予定

 

このデモには、ZCU104ボードを使用しましたが、どのZynq® UltraScale+ デバイスでも手順は同じです。

Read more...

more
4 0 881
kshimizu
Xilinx Employee
Xilinx Employee

本ブログは英語版のVideo Series 30 – Understanding Interlaced Videoを翻訳したものです。

 

インターレース ビデオとプログレッシブ ビデオの違いについて

以前にビデオ シリーズを読んだことがあるなら、「ビデオ初心者シリーズ 16: VTC IP を使用したビデオ タイミングについて」の記事で、プログレッシブ ビデオとインターレース ビデオについて触れたことを覚えていてくださるかもしれません。違いについては後ほどのビデオ シリーズにて説明すると述べたので、今回はこの違いについて説明します。

それでは、プログレッシブ ビデオとインターレース ビデオについて説明します。

プログレッシブ ビデオ (またはノンインターレース) は、ビデオのデフォルト設定です。プログレッシブ ビデオでは、フレームごとにすべてのライン (走行線) のすべてのピクセル値が送信されます。

帯域幅を抑えたい場合は、インターレース ビデオを使用できます。インターレース ビデオでは、半分のラインだけが送信されます。たとえば、あるフレームの奇数ラインのみが転送された後、次のフレームの偶数ラインのみが送信されます。

1.png

2.png

インターレース ビデオでは、ラインの半分を含んだフレームをフィールドと呼びます。

インターレースのフィールドを作成するために各フレームの半分のラインを送信することを、走査線の間引きと呼びます。ただし、この方法では、色または強度に垂直方向の急激な遷移がある場合にちらつきが発生することがあります。

より優れた方法とされる垂直フィルターでは、複数のプログレッシブ フレームを使用してインターレース フィールドが作成されます。

たとえば、2 つの連続するフレームの最初のラインの平均値を使用して、フィールドの最初のラインを作成できます。

 

 

AXI4-Stream でインターレース コンテンツを転送する方法

AXI4-Stream インターフェイスでは、インターレース コンテンツの送信はプログレッシブ コンテンツの送信と類似しています。tuser 信号はフィールドの最初のピクセルに対してアサートされ、tLast 信号はフィールドの最後のピクセルに対してアサートされます。

唯一の違いは fid 信号です。この信号はプログレッシブ ビデオには必要ありません。プログレッシブ ビデオでは 0 に接続する必要があります。fid 信号は、奇数または偶数のフィールドが現在送信されているかどうかを示すために使用されます。このため、この信号はフィールドごとに切り替わります。

3.jpg

 

 

インターレース コンテンツをプログレッシブ コンテンツに変換

一部のアプリケーションでは、インターレース ビデオ データをプログレッシブ ビデオに変換する必要があります。この操作は、デインターレースと呼ばれます。

ザイリンクス デバイスでは、Video Processing Subsystem (VPSS) IP を使用してインターレース ビデオをプログレッシブ ビデオに変換できます。

 

 

ザイリンクス VPSS IP を使用したデインターレースの例

添付のサンプル デザインでは、Video Processing Subsystem IP がスケーラー専用として設定されています。

このデザインは、「ビデオ シリーズ 28: カラー スペース コンバーター モードでの VPSS IP の使用」に基づいています。

Vivado 2019.1 では、ザイリンクスの Test Pattern Generator を使用してインターレース コンテンツを生成できます。これをインターレース ソースとして使用しています。

 

ビデオ シリーズ 28 デザインと比較した際のハードウェアの変更

この例では、VPSS をデインターレース専用に設定するために若干の変更を加えただけです (ビデオ シリーズ 28 の例では、カラースペース コンバーターが設定されていました)

  • VPSS [Video Processing Functionality] 設定を [Deinterlacing Only] (デインターレース専用) に変更しました。

4.jpg

  • [Deinterlacer] タブで [Enable Motion Adaptative Deinterlacing] オプションをオンのままにしました。このオプションがオンのときは、VPSS でフレーム バッファーが使用され、メモリへのアクセスには AXI Memory Mapper インターフェイスが使用されます。

5.jpg

  • AXI4 メモリ マップド インターフェイスを PS DDR に接続しました。

6.jpg

  • 最後に、ストリームがインターレースされるで、TPG の fid 信号を VPSS に接続しました。

7.jpg

 

ビデオ シリーズ 28 のアプリケーションと比較した際のソフトウェアの変更

ビデオ シリーズ 28 のアプリケーションと比較したとき、若干の変更をアプリケーションに加える必要があります。

  • VPSS ではカラー変換を実行しないので、入力と出力の両方でカラー スペースを YUV422 に固定します。

XVidC_ColorFormat colorFmtIn = XVIDC_CSF_YCRCB_422;

  • TPG を設定する場合、高さは入力の高さを 2 で割った値にします。

app_hdmi_conf_tpg(&tpg_inst, Height/2, Width, colorFmtIn, XTPG_BKGND_COLOR_BARS);

  • TPG で出力をインターレースに設定します。

app_hdmi_conf_tpg_interlaced(&tpg_inst, 1);

  • 入力ストリームはインターレースとして設定します。

StreamIn.IsInterlaced   = 1;

  • VPSS 内の DMA エンジンで使用されるベース アドレスを定義する必要があります。この設定は PSS を初期化する (XVprocSs_CfgInitialize) 前に実行する必要があります。

XVprocSs_SetFrameBufBaseaddr(&VprocInst,0x10600000);

 

デザインの生成

  1. チュートリアル ファイルをダウンロードし、フォルダーを解凍します。
  2. Vivado 2019.1 を開きます。
  3. [Tcl Console] ウィンドウで、cd コマンドを使用して (cd XVES_0030/hw)、ZIP 解凍ディレクトリに移動します。
  4. [Tcl Console] ウィンドウで、source コマンドを使用してスクリプト tcl (source ./create_proj.tcl) を実行します
  5. BD 出力ファイルを生成し、合成、インプリメンテーションを実行し、ビットストリームを生成します。
  6. ビットストリームを含むハードウェアを XVES_0030/sw/sdk_export にエクスポートします。
  7. Windows メニューまたはコマンド ラインから Xilinx Software Command Line Tools (XSCT) 2019.1 を起動します。

・Windows メニューで次を実行します。

[スタート] → [すべてのプログラム] → [Xilinx Design Tools] → [Xilinx Software Command Line Tool 2019.1] をクリックします。

・コマンド ラインで次を実行します。

xsct コマンドを使用します (SDK 2019.1 用の環境変数を設定する必要があります。)

8. xsct で cd コマンドを使用して XVES_0030/sw に移動します。

9. source create_SW_proj.tcl コマンドを使用します。

10. SDK を開き、XVES_0030/sw/sdk_workspace をワークスペースとして選択します。

 

 

このビデオ シリーズ エントリはいかがでしたか?

  • [Kudos] ボタン  をクリックして Kudos (拍手) しましょう。kudos.JPG

     

  • [Share] ボタン をクリックして、ソーシャル メディアで共有してください。share.JPG

     

 

  • このトピックにコメントしたり、新しいトピックをフォーラムで作成し質問してください。

 

 

ビデオ シリーズについて

 

 

 

more
3 0 714
takayos
Xilinx Employee
Xilinx Employee

このブログ エントリの解析は、タイミングが満たされているにもかかわらず、ハードウェアの機能が正しくないというお客様の実際の問題に基づいています。この問題はクロック乗せ換えに関連していたため、このエントリの最後でこのような問題をデバッグする手順について説明します。

 

問題について

このデザインでは、ユーザーによりビットストリームが生成され、それを使用してデバイスがプログラムされています。ハードウェアでテストしたところ、少数のクロック ドメインでは必要な機能が得られなかったことがわかりました。

ビヘイビアー シミュレーションとインプリメンテーション後のシミュレーションをテストし、信号の結果が正しいことを確認しました。

また、タイミング違反も見つからず、次の [Design Timing Summary] に示すように、すべての値が正の値になりました。

takayos_1-1606191218659.png

 

注記: 次のオプションを使用して、デザインのタイミング サマリを確認できます。

  • Vivado GUI で、[Reports] タブ [Timing] [Report Timing Summary] をクリックします。
  • 次の Tcl コマンドを実行します。

report_timing_summary -file <filepath>/timingreport.txt

 

根本的な原因の解析:

ハードウェアの機能の問題には、さまざまな原因が考えられます。これらには、クロック乗せ換え (CDC) シンクロナイザーの欠落、最適でないクロッキング トポロジ、クロッキング構造での組み合わせロジックの使用、メタスタビリティー、および従来の制約のないパスが含まれます。

クロッキング/アーキテクチャ/CDC などに関連する警告/クリティカル警告を確認するには、設計手法レポートを使用します。

Vivado GUI で設計手法レポートを開くには、[Report] タブ → [Report Methodology] をクリックするか、または Tcl コンソールで「report_methodology」と入力します。

レポートを開くと、デザインに関連する警告とクリティカル警告が表示されることがあります。これらを確認する必要があります。

この例では、CDC に関連する不適切な手法 (Bad Practice) がレポートに含まれており、次の図の Timing-9 および Timing-10 がこれに該当します。

 

 

 

takayos_2-1606191218708.png

 

これらの警告メッセージは、2 つのクロック ドメイン間に set_false_path や set_clock_groups などの制約が設定された非同期クロック乗せ換えパスが 1 つ以上検出されたことを示しています。

しかし、デスティネーション クロック側にダブル レジスタ ロジック シンクロナイザーが見つからなかったため、report_CDC を実行してこれらの CDC パスをさらに解析することを推奨しています。

Vivado GUI で CDC レポートを開くには、[Reports] タブ → [Timing] → [Report CDC] をクリックします。または、Tcl コンソールで report_cdc コマンドを実行します。

CDC レポートの詳細は、『Vivado Design Suite ユーザー ガイド: デザイン解析およびクロージャ テクニック』 (UG906) を参照してください。

CDC レポートには、次に示すように正しくないハードウェア機能が発生するのと同じクロック ドメイン内に危険で不明の CDC エンドポイントが存在することが示されています。レポートに含まれる用語については、(UG906) を参照してください。

 

takayos_3-1606191218728.png

 

 

これらの警告/クリティカル警告を解決する方法:

1) (UG906) には、これらの警告の詳細な説明と、その他のタイミング設計手法チェックが含まれています。例を見て、各警告とその原因を詳細に理解します。RTL を変更するかパラメーター指定マクロ (XPM) を使用して適切な同期回路を追加することで、デザインを改善できます。

2) また、それに応じて制約を追加または変更したり RTL ソース コードの CDC エンドポイントに ASYNC_REG プロパティを追加したりする必要がある場合もあります。CDC のトポロジの詳細は、(UG906) を参照してください。

3) 擬似スタティック レジスタ インターフェイスの場合、CDC インターフェイスを過剰にデザインする代わりに、除外することをお勧めします。

除外の詳細および作成方法は、(UG906) を参照してください。

注記: 擬似スタティック CDC レジスタ インタフェースは、事実上スタティック コンフィギュレーション レジスタである CDC パスです。これらは初期化後に変更されることはありません。また、変更されるのは一度だけなので、スタティックと見なすことができます。

 

まとめ:

CDC パスに必要な変更を加えた後、お客様はハードウェアの機能テストに合格できました。

more
3 0 587
kurihara
Xilinx Employee
Xilinx Employee

概要:本Blogでは、PS GEMの簡略化したプログラミング・シーケンス例を紹介します

 

プログラミング・モデル

ここに記載されている手順は、テクニカルリファレンスマニュアルに記載されている手順とは少し異なります。 PHYI / O、および割り込み設定はスキップされます。 例を簡略化するために、一部の構成が変更されています。

 

RAWイーサネットフレームとして32バイトを送受信します。

 

ここで使用されるプログラミング手順は、以下の通りです:

1.コントローラーを初期化

2.コントローラーの設定

3.バッファー・ディスクリプターの設定

4.コントローラーを有効にする

5.フレームの送信と受信

 

1.コントローラーの初期化

  • ネットワーク・コントロール・レジスタをクリアし、統計レジスタビット[5]をクリアします。

 

アドレス

0xFF0C0000

0x00000000

0xFF0C0000

0x00000020

 

image.png

image.png

統計レジスタをクリアします-このビットは書き込み専用です。 1を書き込むと、統計レジスタがクリアされます。 セルフ・クリアリング・レジスタです。

 

  • TXとRXステータス・レジスタをクリア。レジスタ・タイプはwtcです。

 

アドレス

0xFF0C0020

0x0000000F

0xFF0C0014

0x000001FF

 

image.png

このレジスタは、読み取られると、受信のステータスの詳細を提供します。 一度読み取られると、個々のビットに1を書き込むことでクリアできます。 レジスタに書き込んでビットを1に設定することはできません。

image.png

このレジスタは、読み取られると、送信のステータスの詳細を提供します。 一度読み取られると、個々のビットに1を書き込むことでクリアできます。 レジスタへの書き込みでビットを1に設定することはできません。

 

  • TX/RXバッファー・キュー・ポインターをクリア。GEMは2つのバッファー・キュー・ポインター・レジスタを持ち、未使用のレジスタ・キューは、ダミー・ディスクリプターで設定される。

 

アドレス

0xFF0C0018

0x00000000

0xFF0C001C

0x00000000

0xFF0C0440

0x00000000

0xFF0C0480

0x00000000

 

image.png

受信バッファー・キューの開始アドレス(受信バッファー・ディスクリプター・リスト)。 ネットワーク制御レジスタのビット2を介して受信を有効にする前に、受信バッファキューのベースアドレスを初期化する必要があります。 受信が有効になると、受信バッファー・キューのベースアドレスレジスタへの書き込みはすべて無視されます。 このレジスタを読み取ると、現在アクセスされている記述子の場所が返されます。 この値は、バッファーが使用されるにつれて増加します。 新しいフレームが受信されると常に変化するため、ソフトウェアは、受信したフレームをキューから削除する場所を決定するためにこのレジスタを使用しないでください。 代わりに、ソフトウェアはバッファー・ディスクリプタ・キューを通して、使用されているビットをチェックする必要があります。 システムバスの動作に関しては、受信ディスクリプタは、各32ビットディスクリプタのペアに対して64ビット境界で整列する必要があります。

 

送信バッファー・キューの開始アドレス(送信バッファ・ディスクリプター・リスト)。 送信バッファー・キューのベースアドレスレジスタは、ネットワーク制御レジスタのビット9を介して送信を開始する前に初期化する必要があります。 一旦送信が開始されると、送信バッファー・キューのベースアドレスレジスタへの書き込みは不正になるため、無視されます。 この期間に送信バッファキューのベースアドレスレジスタに書き込むと、予期しない結果が生じる可能性があります。 このレジスタを読み取ると、現在アクセスされているディスクリプターの場所が返されます。 DMAは一度に2つのフレームを処理するため、これは必ずしも送信中の現在のフレームを指しているとは限りません。 システムバスの動作に関しては、送信記述子は各32ビット・ディスクリプター・ペアに対して64ビット境界で整列する必要があります。

image.png

送信バッファー・キューの開始アドレス(送信バッファー・ディスクリプター・リスト)。 送信バッファー・キューのベースアドレスレジスタは、ネットワーク制御レジスタのビット9を介して送信を開始する前に初期化する必要があります。 送信が開始されると、送信バッファー・キューのベースアドレスレジスタへの書き込みは不正になるため、無視されます。 この期間に送信バッファキューのベースアドレスレジスタに書き込むと、予期しない結果が生じる可能性があります。 このレジスタを読み取ると、現在アクセスされているディスクリプタの場所が返されます。 DMAは一度に2つのフレームを処理するため、これは必ずしも送信中の現在のフレームを指しているとは限りません。 システムバスの動作に関しては、32ビット記述子の各ペアが単一のバスアクセスを使用してメモリから読み取られるため、送信記述子は64ビット境界で整列する必要があります。

image.png

受信バッファー・キューの開始アドレス(受信バッファー・ディスクリプター・リスト)。 ネットワーク制御レジスタのビット2を介して受信を有効にする前に、受信バッファー・キューのベースアドレスを初期化する必要があります。 受信が有効になると、受信バッファー・キューのベースアドレスレジスタへの書き込みはすべて無視されます。 このレジスタを読み取ると、現在アクセスされている記述子の場所が返されます。 この値は、バッファーが使用されるにつれて増加します。 新しいフレームが受信されると常に変化するため、ソフトウェアは、受信したフレームをキューから削除する場所を決定するためにこのレジスタを使用しないでください。 代わりに、ソフトウェアはバッファー・ディスクリプター・キューを通して、使用されているビットをチェックする必要があります。 システムバスの動作に関しては、受信記述子を64ビット境界に揃える必要があり、各32ビット・ディスクリプターのペアは単一の64ビットバスアクセスを使用して書き込まれます。

 

2.コントローラーの設定

1. 以下のオプションでネットワーク・コンフィギュレーション・レジスタをプログラムします。

 

アドレス

0xFF0C0004

0x013F2492

 

image.png

bits

Field Name

Description

24

Receive_checksum_offload_enable

Receive checksum engine is enabled

22:21

Data Bus width

64-bit AMBA AXI data bus.

20:18

MDC clock division

MDC clock division

17

Fcs remove

FCS remove

16

Length field error frame discard

Length field error frame discard

13

Pause_enable

Pause enable

10

Gigbit_mode_enable

1000 Mbps operation

7

Unicast_hash_enable

Unicast hash enable

4

Copy_all_frames

All valid frames will be accepted

1

Full duplex

Full duplex

 

2. MACアドレスを[0x00,0x0a, 0x35, 0x01,0x02, 0x03]にセットします。Spec_add1_bottom/topレジスタに値を書き込みます。

 

アドレス

0xFF0C0088

0x01350A00

0xFF0C008C

0x00000302

 

image.png

特定のアドレスレジスタに格納されているアドレスは、リセット時、または対応する特定のアドレスレジスタの下部に書き込まれるときに非アクティブ化されます。 特定のアドレスレジスタトップが書き込まれるとアクティブになります。

 

3. 以下のオプションでDMAレジスタを設定します。

アドレス

0xFF0C0010

0x40180F10

 

bits

Field Name

Description

30

Dma_addr_bus_width_1

DMA アドレス bus width 64

2316

Rx_buf_size

DMA receive buffer size in external AMBA (AHB/AXI) system memory.1536B

11

Tx_pbuf_tcp_en

Transmitter checksum generation is enabled

10

Tx_pbuf_size

Maximum configured memory size of 4KB

9:8

Rx_pbuf_size

Receive packet buffer memory size 8kB

4:0

Amba_burst_length

16 burst

 

3.バッファー・ディスクリプターを設定

gem.receive_q {、1} _ptrにはTXバッファー・ディスクリプター・リストのベースアドレスが含まれ、gem.receive_q {1} _ptrにはRXバッファー・ディスクリプター・リストのベースアドレスが含まれます。 TX / RXバッファー・ディスクリプター・リストワード[0]は、システムメモリ内のTX / RXバッファーのアドレスを指します。 N個のバッファーに対してN個のディスクリプターを構成できます。GEMコントローラには、2つのTX / RXバッファー・キューポインタ・レジスタがあります。 TX / RXの動作に使用されるTX / RXの組み合わせは1つだけです。 ダミーのディスクリプター値を使用して未使用のキューをプログラムすることが重要です。

 

次のアドレスと値は、q_ptrレジスタを構成します。

アドレス

0xFF0C0018

0x00600000

0xFF0C001C

0x00700000

0xFF0C0440

0x00610000

0xFF0C0480

0x00710000

0xFF0C04C8

0x00000000

0xFF0C04D4

0x00000000

 

アドレス

説明

0x610000

TXバッファ・ディスクリプタ・リストのベース・アドレス

0x600000

RXバッファ・ディスクリプタ・リストのベース・アドレス

0x700000

TXバッファ・ディスクリプタ・リストのダミー・アドレス

0x710000

RXバッファ・ディスクリプタ・リストのダミー・アドレス

 

0xFF0C0018

Receive_q_ptrレジスタ

0xFF0C001C

Transmit_q_ptrレジスタ

0xFF0C0440

Transmit_q1_ptrレジスタ

0xFF0C0480

Receive_q1_ptrレジスタ

0xFF0C04C8

TXバッファ・ディスクリプタ・キュー・ベース・アドレスの上位32ビット

0xFF0C04D4

RXバッファ・ディスクリプタ・キュー・ベース・アドレスの上位32ビット

 

  ダミーバッファー・ディスクリプター・リスト

以下は、ダミー・ディスクリプターを設定します。

 

アドレス

TX Qポインター・ダミー・ディスクリプター

0x00700000

0x00000000

0x00700004

0xC0000000

0x00700008

0x00000000

0x0070000C

0x00000000

RX Qポインター・ダミー・ディスクリプター

0x00710000

0x00000003

0x00710004

0x00000000

0x00710008

0x00000000

0x0071000C

0x00000000

 

TXバッファー・ディスクリプター・リスト

 

次設定は、TXバッファー・ディスクリプター・リストを構成します。 4つのバッファー・ディスクリプターが構成されます。 ただし、ここでは1つのバッファーのみが使用されます。 ここでは、DMAバス幅を64ビットに構成したため、1つのバッファー・ディスクリプターの長さは16バイトです。

 

シングル・バッファー・イーサネット・フレームの場合、ワード0のビット15)を設定する必要があります。 これが現在のフレームの最後のバッファであることを示します。 バッファーの長さはワード0ビット0:13で設定する必要があります。 割り当てられたバッファーの使用済みビットは、送信のためにビット31)をクリアする必要があります。

 

アドレス

Tx バッファーのディスクリプター1

0x00610000

0x00400000

0x00610004

0x0000802E

0x00610008

0x00000000

0x0061000c

0x00000000

Tx バッファーのディスクリプター2

0x00610010

0x00000000

0x00610014

0x80000000

0x00610018

0x00000000

0x0061001C

0x00000000

Tx バッファーのディスクリプター3

0x00610020

0x00000000

0x00610024

0x80000000

0x00610028

0x00000000

0x0061002C

0x00000000

Tx バッファーのディスクリプター4

0x00610030

0x00000000

0x00610034

0xC0000000

0x00610038

0x00000000

0x0061003C

0x00000000

 

RXバッファー・ディスクリプター・リスト

次の設定は、RXバッファー・ディスクリプター・リストを構成します。 0x600000は、RXバッファー・ディスクリプター・リストのベースアドレスです。 システムメモリ内のRXバッファの先頭のアドレスは0x500000として設定されます。 コントローラが受信したデータは、このアドレスで利用できます。

 

ここでも、4つの受信バッファーを構成しました。 ただし、32バイトしか送受信しないため、1つだけが使用されます。 最後のディスクリプターには、ラップビットが設定されています。

 

アドレス

Rx バッファーのディスクリプター1

0x00600000

0x00500000

0x00600004

0x00000000

0x00600008

0x00000000

0x0060000c

0x00000000

Rx バッファーのディスクリプター2

0x00600010

0x00000000

0x00600014

0x00000000

0x00600018

0x00000000

0x0060001C

0x00000000

Rx バッファーのディスクリプター3

0x00600020

0x00000000

0x00600024

0x00000000

0x00600028

0x00000000

0x0060002C

0x00000000

Rx バッファーのディスクリプター4

0x00600030

0x00000002

0x00600034

0x00000000

0x00600038

0x00000000

0x0060003C

0x00000000

 

 

4.コントローラーを有効にする

割り当てられたバッファーにイーサネット・フレーム・データを書き込みます。 フレームフォーマットは: <Destination MAC addr, Source MAC addr, length/type, data>

アドレス

TX データのフレーミング

0x00400000

0x01350A00

0x00400004

0x0A000302

0x00400008

0x03020135

0x0040000C

0x02012000

0x00400010

0x06050403

0x00400014

0x0A090807

0x00400018

0x0E0D0C0B

0x0040001C

0x1211100F

0x00400020

0x16151413

0x00400024

0x1A191817

0x00400028

0x1E1D1C1B

0x0040002C

0x0000201F

 

MACループバックを有効にするには、最初に送受信を無効にし、ループバックビットセットを設定して、ネットワーク制御レジスタで送受信を有効にします。

 

アドレス

ループバック・イネーブル

0xFF0C0000

0x00000000

0xFF0C0000

0x00000002

0xFF0C0000

0x0000000E

 

5.フレームの送信と受信

ネットワーク・コントロール・レジスタのビット9を設定して送信を開始します。

 

アドレス

送信開始

0xFF0C0000

0x0000020E

 

送信後、送信ステータスは送信ステータス・レジスタで読み取ることができます。 ビット5は正常な送信を表します。 バッファーに関連する送信のステータスも、TXバッファー・ディスクリプターのワード(ワード1)で更新されます。

 

TXステータス読み出し

0xFF0C0014

 

 

受信したデータは、送信が成功したため、RXバッファー(0x500000)に存在する必要があります。 バッファー・ディスクリプター・ステータス・ワード(ワード1)は、受信ステータスに基づいて更新されます。

 

RXデータ読み出し    

0x00500000

 

 

 

参考文献

Zynq UltraScale+ MPSoCテクニカルリファレンスマニュアル”, Xilinx, 2nd Feb.2017

more
3 0 616
yukah
Community Manager
Community Manager

問題を解決するのにフォーラムを使用することは、主に2つのメリットがあります。

1つ目は、回答を得るまでの時間が早まる可能性があることです。

フォーラムでは、さまざまな時間帯のユーザーが質問を閲覧し回答するのに加え、場合によっては、同じ問題がすでに別のユーザーにより投稿されており、その解決事例や参考情報が得られる可能性もあります。

2つ目は、各ボードの管理および回答には、専門知識を持ったザイリンクス社員も貢献しているので、速やかな問題解決につながることです。

この記事では、フォーラムで回答を得るための、基本的な使い方をご紹介します。

 

  •  ソリューションを検索する

  • 質問をする

  • 質問に返信をする

 

 

ソリューションを検索する

 

ソリューションを検索するには、2の方法があります。

 

1. サーチボックスに検索する語句を入力

 

 

1_サーチボックスに検索する語句を入力する.png

 

 

 

 

2. ナビゲーションを使用して、カテゴリーやボードへ移動

 

フォーラムには次のカテゴリに各ボードが存在します。

 

  • Hardware Development
  • Software Development
  • Embedded Software Development
  • Vivado RTL Development
  • About Our Community

 

下記のいずれのナビゲーションから進んでも閲覧できる内容に違いはありません。

 

  • フォーラム トップページ左上のナビゲーションを使用

キャプチャ.JPG

  • フォーラム トップページ右のナビゲーションを使用

 キャプチャ2.JPG

 

 

 

 

 

 

 

 

 

 

 

質問をする

 

1. [Post a Question] をクリック

5.png

2. フォームに入力する

  • 英語での投稿をお願いいたします。
  • [Select Location]では、ご質問の内容に適したボードを選択してください。
    各ボードはそれぞれのボードに対する専門知識を持ったエキスパートに管理されていますので、速やかな問題解決に繋がります。
  •  投稿には必要な情報をすべて含めてください。
    • ソフトウェアバージョン、デバイスモデル/型番、使用するIP/基板名、XCIファイル、参考にした資料など
    • 上記に加え、ILAの波形、IBERT EyeScan結果、Vivado/Petalinuxの実行ログなどのデバッグ情報も加えると、回答が得られやすくなります。

6.png

 

 

 

 

 

 

 

 

 

3. 質問を投稿

すべて入力が完了したら[Post] をクリック

7.png

 

 

 

 

 

 

 

 

 

質問に返信する

 

1. 投稿の右下にある [Reply」 をクリック

8.png

2. 返信を入力したら [Post] をクリック

返信時に@を入力すると、その投稿に関係のあるユーザー名一覧が出てきます。

選択した相手をメンションすることができます。

9.png

3.  12を繰り返して、問題を解決

4.  問題が解決したら、最も参考になった返信の [Accept as Solutionをクリック

10.png

 

 

 

 

5. Kudosを付与

ソリューションとなった返信を含め、ほかにも解決に役立った、重要だと感じた返信にはKudosを付与してください。

フォーラムユーザーのモチベーション向上に繋がります。

11.png

 

 

 

 

 

 

 

 

以上が、フォーラムの基本的な使用方法です。

更に詳しい使用方法は、次のページで紹介されています。

Community Forums Guidelines

Community Forum Help

more
7 0 774
karnanl
Xilinx Employee
Xilinx Employee

本ブログは英語版のRF Data Converter IP Example Simulation Walkthroughを翻訳したものです。

 

皆さん、こんにちは。RF データ コンバーター ブログ シリーズの最新記事へようこそ。

今回は、RF データ コンバーター IP のサンプル デザインのシミュレーション テストベンチについて説明します。

このブログでは、テストベンチのビルド方法と IP を実行する際に使用されるメカニズムについて説明します。テストベンチについてよく理解していれば、RF データ コンバーター IP をユーザー自身のシミュレーション設定に組み込む際のテンプレートとして使用するのに役立ちます。

ここでは、すべての詳細を説明するわけではなく、シミュレーションのメカニズムについてのみ説明します。テストベンチの RTL の詳細については、ご自身で自由にお調べください。

IP サンプル デザインにはすでに完成済みのテストベンチが含まれます。このテストベンチには、ADC DAC 両方を使用するためのスティミュラス生成およびシミュレーションでのキャプチャが含まれます。シミュレーションには、IP 設定を検証するのに使用可能なビルトイン セルフチェック機能があります。

では、サンプル デザイン テストベンチの概要を見てみましょう。

P00.png

IP サンプル デザインでは、RF データ コンバーター IP と、スティミュラス ブロック、キャプチャ ブロックが 1 つの大きなブロック RAM 配列内に含まれています。

SmartConnect ブロックも含まれ、IP AXI4-Lite ポートに接続されています。

テストベンチから必要なものは、次のとおりです。

  • デザイン内のすべてのクロックに対するクロック生成。ADC DAC タイル入力、AXI ストリーミング インターフェイス、AXI4-Lite インターフェイス。
  • スティミュラス ブロックとソース ブロックを読み込む手段。
  • 実際の信号をアナログ入力に適用する手段と、DAC からの実際の信号をデジタル バスに変換してチェックできるようにする手段。
  • シミュレーションの管理にはシーケンサーが必要 (最も重要)
  • キャプチャ ブロックまたはシンク ブロックを調査する手段。

では、テストベンチを少し見てみましょう。テストベンチのソース ファイルはすべてサンプル デザイン プロジェクトの imports ディレクトリに含まれます。

最上位テストベンチは、demo_tb.sv (SystemVerilog ファイル) に含まれます。ここでは、各行について説明はしません。この段階では、単にメイン ブロックに接続だけします。では、シミュレーション機能で最も重要な部分を見てみましょう。

 

クロック生成

このブロックは、シミュレーションに必要なクロックすべてを作成するかなりシンプルなブロックです。ご覧のように、ユーザーがクロックの高時間と低時間を設定できるようにする _phase が末尾に付いた入力があります。これは、各タイルとストリーム クロックに必要な周波数を作成するのに使用されます。

P01.png

P02.png

希望どおりになったかどうかをシミュレーションでチェックします。

この場合、DAC サンプル クロックが 6.4 Gsps で実行され、ストリーム クロックがこのレートの 16 分周で実行されています。

P03.png

スティミュラス生成

シミュレーションでは ADC および DAC が別々に処理されます。この場合、loopback done はありません。

DAC および ADC にはソースがあります。

ADC の場合、demo_tb_rfadc_tile_source.sv を含む demo_tb_rfadc_data_source.sv です。タイル ソースの方には、正弦ルックアップ テーブル (LUT) が含まれます。この場合、この LUT を繰り返し、出力正弦波を生成します。

P04.png

この正弦波がテストベンチの最上位に出力されます。これを実数に変換すると、demo_tb のタイルの UNISIM モデル レベルで ADC のアナログ入力に使用できます。

P05.png

DAC の場合、データを AXI インターフェイスを使用してサンプル デザインの DAC ソース ブロックに書き込むだけです。demo_tb レベルでは、DAC アナログ信号を実数からビットに変換して、DAC シンク入力に適用します。

P06.png

テストベンチ シーケンサー

ここまでで、クロックがシミュレーションで実行されており、データ ソースについて説明したので、次はテストベンチの主な部分について説明します。

demo_tb_axi4l_nano_seq.sv というファイルを見てみると、どのようにシミュレーションが設定および制御されているかがわかります。このファイルは、SystemVerilog タスクをいくつか使用して、RF タイルにアクセスしてタイルの設定をできるようにするためのものです。ほかにも、シミュレーションを制御するタスクがあります。これらについては、シミュレーションを実行しながら、必要に応じて説明していきます。

このファイルを見てみると、パラメーター化されたアドレス指定を使用して、AXI4-Lite を介してテストベンチのさまざまなサブブロックを設定できるようになっていることがわかります。これらは、シミュレーションを制御するさまざまなタスクで使用されます。

B0.png

シーケンサーは、まずテストベンチのすべてにリセットを適用します。そのあと、タイルに書き込みをして、シミュレーションのスピードアップをイネーブルにします。これにより、電源トリム時間と ADC キャリブレーション時間が削減されるので、タイルのスタートアップが短縮されます。シミュレーションでは、タイルが IP のスタートアップ ステート マシンでステート 1 になるようにするだけです。

B1.png

このあと、タイルが設定されて、テストベンチでソースとシンクをオンにし始めます。DAC ソース メモリの読み込みも開始されます。

B2.png

シミュレーション時間は各段階で定期的に表示させるようにすることをお勧めします。こうしておくと、必要に応じて波形をチェックできます。

ご覧のように、IP の設定が終了し、DAC スティミュラス ブロックを約 169us に書き込み始めました。DAC ソース メモリはベース アドレス 0x300000000 にあります。

B3.png

次に、タイルへのクロックを開始し、ADC DAC がクロック検出ステップまで実行されるようにします。

B4.png

B5.png

このステップが終了したら、DAC ソースを開始して、DAC を最後まで (スタートアップ FSM の終了まで) 実行します。

B6.png

波形を見てみると、送信されてきたトーンと DAC 出力バスが実行されていることがわかります。

ここでは、25Mhz/50Mhz/100Mhz/200Mhz が表示されています。

B7.png

 

この後、ADC に対して上記プロセスを繰り返します。

B8.png

すべて実行したら、これを波形で確認します。この場合、vout_00 および vout02 バスがシミュレーションの ADC ソースの出力です。

次は、毎 AXI ストリーム 8 サンプルの 1 つのスクリーン キャプチャで、ADC がトーンを正しく変換しているところを示しています。 

B9.png

データ シンクおよびチェッカー

ADC および DAC には demo_tb にシンク ブロックのセットが含まれています。

これらのブロック内でデータがスケーリングされ、FFT 変換を実行できます。これで、トーンが正しく変換されたことがわかります。

B10.png

これらのブロックは、エラー カウンターを管理します。すべてが正しければ、シーケンサーはシミュレーションを停止します。

B11.png

B12.png

このブログでは、IP サンプル シミュレーションについて簡単に説明しました。ほかにも詳細はありますが、まずこのブログからシミュレーションがどのように機能するかについて理解し、これらの手法をご自身のシミュレーション テストベンチに使用してみてください。

 

more
3 0 717
kshimizu
Xilinx Employee
Xilinx Employee

本ブログは英語版のVideo Series 31 – Debugging a Video System using an ILAを翻訳したものです。

 

概要

ビデオ システムのデバッグで最も重要なのは、ビデオ システムのどの箇所でエラーが発生しているかを理解することです。これがわかれば、どこに焦点を置いてデバッグするかが決めやすくなります。

FPGA のエラーを見つけるには、デザインに含まれているさまざまな IP コアの入力および出力を見てみるのが最善の方法です。これには ILA (Integrated Logic Analyzer) を使用できます。

ザイリンクス ILA については、『PG172 Integrated Logic Analyzer v6.2 製品ガイド』 (PG172) に記載されており、チュートリアルは『Vivado Design Suite チュートリアル: プログラムおよびデバッグ』 (UG936) で提供されています。

このビデオ シリーズの記事では、2 つの ILA 挿入方法 (ネットリスト挿入および IP インテグレーターを使用したインスタンシエーション) を説明し、挿入した ILA を使用してどのようにビデオ システムをデバッグするかを説明します。

 

ビデオ システムをデバッグするときには、ILA で次の配置方法を推奨します。

  • 新しいビデオ プロジェクトの場合は、ILA をビデオ パイプラインのソース (開始地点) またはシンク (終了地点) に追加します。通常はソースから開始します。
  • 既に作業中のビデオ デザインがあり IP 1 個のみ追加している場合は、この IP の入力および出力を最初に確認します。

 

主に確認する必要があるのは、この IP AXI4-Stream インターフェイスで、さらに言えば次の信号を確認してください。

  • tvalid: tvalid 信号が low のままの場合、アップストリーム (ソース) IP がデータを送信していないことを意味するので、この IP を調べる必要があります。

場合によっては、ソース先のさらにソース先に問題がある、という可能性もあることを念頭に置いてください。この場合は、ビデオ パイプラインの開始地点でない限り、アップストリーム IP に別の ILA を配置する必要がある可能性もあります。

  • tready: tready 信号が low のままの場合、ダウンストリーム (シンク) IP でデータが受信できないことを意味しますので、この IP を調べる必要があります。

場合によっては、シンク先のさらにシンク先に問題がある、という可能性もあることを念頭に置いてください。

  • tdatatuser、および tlast: tready および tvalid が正しく動作しているように見える場合は、不具合がある可能性があるので、これらの信号を確認します。または出力があるがモニターの内容がよくない場合はこれらの信号を確認します。

 

次の 2 つの演習では、この記事に添付されているデザイン ファイルを使用する必要があります。

 

 

演習 1 - ネットリストへの ILA の挿入 – 合成結果に [Mark Debug] を追加

注記: このチュートリアルは、Vivado 2019.1 Zynq®-7000 SoC ZC702 評価キットのみで使用してください。

デザインの生成

1. Vivado 2019.1 を開きます。

2. [Tcl Console] ウィンドウで、cd コマンドを使用して ZIP 解凍ディレクトリ (cd XVES_0031/lab1) に移動します。

3. [Tcl Console] ウィンドウで、source コマンドを使用してスクリプト tcl (source ./create_proj.tcl) を実行します。

4. BD 出力ファイルを生成して合成を実行します。

ネットリストに ILA を追加

6. Flow Navigator [Synthesis] ドロップダウン リストから [Open Synthesized Design] をクリックします。

1.jpg

7. [Netlist] ウィンドウで ZC702_ILA_DEBUG_wrapper ZC702_ILA_DEBUG_i にある TPG IP および VPSS IP を選択します (Ctrl + クリック)

2.jpg

8. F4 を押して回路図を表示します。2 つの IP コア間の接続が表示されます。

3.jpg

9. 両 IP tlast 信号のネット接続を右クリックして、[Mark Debug] をクリックします。

4.jpg

10. tusertdata、および tvalid 信号でも同じ操作を繰り返します。

11. Ctrl + S キーを押してデザインを保存します。

12. [OK] をクリックします。

5.jpg

13. デフォルト設定 (ZC702.xdc に制約を保存) を保持して [OK] をクリックします。

6.jpg

14. ZC702.xdc 制約ファイルを開くと、Vivado により set_property MARK_DEBUG 行が追加されていることがわかります。

7.jpg

15. [Window] [Debug] をクリックします。[Debug] ウィンドウが開いたら、ウィンドウがまだ選択されていない場合は、そのウィンドウをクリックします。

16. [Debug] ウィンドウで [Set up Debug] ボタンをクリックします。

8.jpg

17. [Set Up Debug] ウィザードが開いたら、[Next] をクリックします。

18. [Nets to Debug] ページで、デバッグするネット数が 28 個表示されています。[Next] をクリックします。

9.jpg

19. 次の 2 つのページで [Next][Finish] をクリックします。

20. デザインの回路図を見ると、ILA がデザインに追加されていることがわかります。

10.jpg

21. Ctrl + S キーを押してデザインを保存します。

22. インプリメンテーションを実行してビットストリームを生成します。

Vivado は閉じないでください。演習 3 では、このデザインでどのように ILA を使用するかを紹介します。

 

 

演習 2- IP インスタンシエーション

注記: このチュートリアルは、Vivado 2019.1 と Zynq®-7000 SoC ZC702 評価キットのみで使用してください。

演習 1 では IP のネットに ILA を接続する方法を紹介しましたが、演習 2 で紹介する方法の方が簡単で早く実行できるのでお勧めです。

デザインの生成

1. Vivado 2019.1 を開きます。

2. [Tcl Console] ウィンドウで、cd コマンドを使用して ZIP 解凍ディレクトリ (cd XVES_0031/lab2) に移動します。

3. [Tcl Console] ウィンドウで、source コマンドを使用してスクリプト tcl (source ./create_proj.tcl) を実行します。

ブロック デザイン (BD) に ILA を追加

5. BD を右クリックして [Add] をクリックします。

6. System ILA IP を追加します。

7. System ILA IP をダブルクリックして、設定 GUI を開きます。

8. [Interface Options] タブでインターフェイス タイプを com:interface:axis rtl:1.0 に変更して [OK] をクリックします。これで ILA 入力が AXI4-Stream に設定されます。

11.jpg

9. ILA 入力 SLOT_0_AXIS TPG 出力に接続します。

12.jpg

10. [Run Connection Automation] をクリックしてツールによりクロックおよびリセット信号を接続させます。

11. BD を検証します。エラーやクリティカル警告メッセージは表示されないはずです。

12. ILA を追加したら、次に BD 出力ファイルを生成し、合成およびインプリメンテーションを実行して、ビットストリームを生成します。

Vivado は閉じないでください。演習 3 では、このデザインでどのように ILA を使用するかを紹介します。

 

 

演習 3 - ハードウェアでの ILA の設定

注記: このチュートリアルは、Vivado 2019.1 と Zynq®-7000 SoC ZC702 評価キットのみで使用してください。

1. Vivado で演習 1 および演習 2 で生成した HDF を XVES_0031/lab3/sw/sdk_export にエクスポートします。

2.ザイリンクス ソフトウェア コマンド ライン ツール (XSCT) を起動します。

・Windows メニューから起動する場合:

[スタート] → [すべてのプログラム] → [Xilinx Design Tools] → [Xilinx Software Command Line Tool 2019.1] をクリックします。

・コマンド ラインから起動する場合:

xsct コマンドを使用します (SDK 2019.1 用の環境変数を設定する必要があります。)

3. xsct で cd コマンドを使用して XVES_0031/lab3 に移動します。

4. source create_SW_proj.tcl を実行します。

5. SDL を開いて XVES_0031/lab3/sdk_workspace をワークスペースに選択します。

6. Vivado に戻り、ZC702 ボードの PL をプログラムします。

1. [Hardware Manager] → [Open Target] → [Auto Connect] をクリックします。

2. [Program Device] → [xc7v020_1]

3. [Program]

[Program Device] ウィンドウには次の 2 つのファイルが表示されます。

  • FPGA をプログラムするためのビットストリーム ファイル (.bit)
  • ILA でキャプチャされる信号の情報を Vitado に渡すためのデバッグ プローブ ファイル (.ltx)

13.jpg

 

次のエラー メッセージが表示されます。

WARNING: [Labtools 27-3361] The debug hub core was not detected.

Resolution:
Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device. To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.

For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).

WARNING: [Labtools 27-3413] Dropping logic core with cellname:'u_ila_0' at location 'uuid_23E7D65A79BC59F7BC47406C1714DFAE' from probes file, since it cannot be found on the programmed device.

このメッセージは、ILA PL でプログラムされなかったために表示されたわけではなく、ILA Vivado により検出されなかったために表示されます。

これは、Zynq 上で操作を実行しようとしていて、ILA のクロックが Zynq プロセッサのクロックから供給されているためです。

Zynq プロセッサは初期化されていないため、このクロックが動作しておらず、この結果 ILA が検出されません。

Zynq を初期化するには、ps7_init を呼び出し Zynq プロセッサをコンフィギュレーションするアプリケーションを SDK で実行する必要があります。

 

7. SDK に戻ります。

8. アプリケーションをビルドし ([Project] [Build All])FPGA をプログラムし ([Xilinx] > [Program FPGA])、デバッグ モードでアプリケーションを起動します (アプリケーションを右クリックして [Debug As] [Launch on Hardware (System Debugger)] をクリック)

デバッグはメイン エントリで停止するはずですが、Zynq プロセッサのコンフィギュレーションにはこれで十分です。

9. Vivado でデバイスを更新します。これで Vivado ILA が表示されます。

10. ILA のウィンドウで、[Run Immediate Trigger] ボタン14.jpg をクリックします。

これでこのインターフェイスの現在のステートを確認できます。

15.jpg

トランジションがなにも発生しておらず、tready 信号が High になっていますが tvalid 信号は High になっていません。これは、アプリケーションの TPG を開始する必要があるためです。TPG を開始する前に、最初のフレームをキャプチャするためのトリガーを追加します。

11. [Trigger Setup] ウィンドウで TUSER 1 のときに TUSER 信号にトリガーを追加します。

16.jpg

12. 波形ウィンドウで、[Run Trigger] ボタンをクリックします。

17.jpg

13. SDK [Resume] または F8 キーを押してフル アプリケーションを実行します。

18.jpg

注記: ZC702 ボードに HDMI モニターが接続されていることを確認してください。

HDMI モニターで生成されるパターンを確認します。

14. Vivado の波形ウィンドウで最初のトランザクションが発生していることがわかります。TUSER の立ち上がりエッジはフレーム開始を意味します。

19.jpg

tready 信号が Low になるのを確認します。これは、おそらく VPSS で最初のフレーム データを受信する準備が完全にできていなかったためです。トリガーを再実行すると、トランザクションが発生することがわかります。

 

 

このビデオ シリーズ エントリはいかがでしたか?

  • [Kudos] ボタン  をクリックして Kudos (拍手) しましょう。kudos.JPG
  • [Share] ボタン をクリックして、ソーシャル メディアで共有してください。share.JPG

 

  • このトピックにコメントしたり、新しいトピックをフォーラムで作成し質問してください。

 

 

ビデオ シリーズについて

more
3 0 800
karnanl
Xilinx Employee
Xilinx Employee

こんにちは、

ザイリンクスでは、プロトコルエンコーディングのオーバーヘッドを最小限に抑えるために、ラインレートが6.6Gbpsを超える場合はAurora 64B66Bを使用することをお勧めしているため、ザイリンクスAurora 8B10Bは公式にGTYをサポートしていません。

64b / 66bエンコーディングのオーバーヘッドは、64ペイロードビットごとに2ビット、つまり3.125%です。これは、8ペイロードビットごとに2ビットを追加した8b / 10bエンコーディングスキームの25%オーバーヘッドを大幅に改善したものです。

 

このブログは、新しいFPGAデザインをGTYとAurora 8B10B I / Fを使用するレガシーシステムに接続する必要があるユーザーに非公式のアイデアを提供することを目的としています

手順フローの概要

Q00.png

 

1. “Generate Aurora 8B10B IP without GT”でIPを生成する.

 

ターゲットデバイスにGTHトランシーバーがない場合は、GTHトランシーバーを備えたデバイスを使用するようにVivadoプロジェクトを設定する必要があることに注意してください。そうでない場合、Aurora 8B10Bはグレー表示になり、IPカタログで選択できません。 (下記参照)

 

 

現在のプロジェクトデバイスにGTHトランシーバーがあることを確認できたら、Aurora 8B10B GUIを開き、システム要件に一致する構成を設定してください。IPを生成する前に、[Generate Aurora without GT]オプションが有効になっていることを確認してください。

Q02.png

2. Aurora 8B10B Example Designを開く

Q03.png

[Sources]ウィンドウで、IPを右クリックして[Open IP Example Design]を選択します

ヒント: 2つのサンプルデザインを2つの異なるディレクトリに生成してください。 GTの変更プロセスがはるかに簡単になります。

 

3.トランシーバー設定の変更(1) – Wizard編

これら2つのサンプルデザインを別のVivadoウィンドウで開いてください。
Q04.png

トランシーバー設定を変更してGTYをターゲットにし、以前にGTHに設定したすべてのトランシーバー設定と一致させます

GUIでIPを生成する前に、以下の設定が間違っていないかを再確認した上で、IPを生成してください。

  • Encoding, Data Width
  • Free-running and DRP clock frequency
  • Lane number設定
  • RX comma/channel bonding 設定
  • Optional ports

すべてのトランシーバー設定が問題ないことを確認した上で、GTYとして

を再生成してください。

Q05.png

4.トランシーバー設定の変更 (2) – RTL編

Linuxの「diff」コマンドなどのツールを使用してGTHとGTYのトップモジュールRTLを比較すると、RTLで何を変更する必要があるかがわかります。

例えば以下の図面では、私が生成したRTLの比較結果となります。
Q06.png

<component_name> _gtインスタンシエーションの次のポートを更新してgtyを反映します

      gthtxp    ⇒ gtytxp

      gthtxn    ⇒ gtytxn

      gthrxp    ⇒ gtyrxp

      gthrxn    ⇒ gtyrxn

Q07.png

既に気づいた方もいらっしゃると思いますが、DRP アドレスのビット幅はGTH (9 bit) と GTY (10 bit)は異なります。 このDRPアドレスの変更もお願いします。

Q08.png

5. IP変更の検証 (Verification of IP modification)

サンプルデザインを使用してクイックチェックを実行し、IPの変更が正しく行われたかどうかを確認してください。

(a) サンプルデザインのシミュレーション実行 :
Q09.png

lane_upとchannel_upの両方がアサートされていることを確認してください.
Q10.png

(b) Vivado Synthesisを実行する:

Q11.png

合成中にエラーや重大な警告が生成されていないことを確認します。

Q12.png

さて、ここまで作業を進めることができたら、変更したAurora 8B10B IPをプロジェクトに含める準備ができています。但し、このソリューションを設計に正式に適用する前に、十分な検証とテストを確実にするというユーザーの責任があります。ぜひお試しください。

more
5 0 576
karnanl
Xilinx Employee
Xilinx Employee

本ブログは英語版のGetting in Synch with RF Data Convertersを翻訳したものです。

皆さん、こんにちは。RF データ コンバーター ブログの最新記事へようこそ。

ここまでで、RF データ コンバーター ソフトウェア ドライバー (ブログ記事) について学び、どのボードのどのデバイスでも RF-ADC および RF-DAC をデバッグできる RF アナライザー (パート 1 およびパート 2) について学びました。

ここでは、RFSoC を使用する多くのカスタマーにとって重要なトピック、「単一デバイスまたは複数デバイスの複数タイルでレイテンシ アライメントを達成するための要件」について説明します。この要件は、「マルチタイル同期」と呼びます。

マルチタイル同期は、大規模 MIMO、ビーム形成、およびフェーズド アレイ レーダーなどのアプリケーションをイネーブルにする際に重要です。

たとえば、ビーム形成では、エネルギーを全方向に送信するのではなく、アンテナの配列を使用して、特定の方向に無線信号を送信するように誘導可能なアンテナの配列を使用できます。この手法では、各アンテナ要素が送信される信号に別々に接続されます。この後、エネルギーを狭いビームまたはローブに集約するように、この信号の各コピーの位相と振幅が増加的および相殺的に追加されます。

このため、配列をビルドするためにデータ コンバーターを多く使用する必要があり、アンテナ配列のすべてのチャネルでレイテンシ アライメントが必要になります。

z00.png

では、この場合に適用するレイテンシ アライメントについて説明します。ここでは、レイテンシ アライメントとデターミニスティックという用語を使用します。

レイテンシ アライメントとはすべてのチャネルの相対的レイテンシが同じであることで、デターミニスティックはすべてのチャネルのレイテンシ合計がどのスタートアップでも一貫していることです。デターミニスティックとアライメントの両方が必要な場合もあります。

Z01.jpg

RF データ コンバーターのスタートアップでは、単一タイル内のコンバーターが常にアライメントされますが、デターミニスティック レイテンシは確実ではありません。マルチタイル システムの場合、デターミニスティック レイテンシが確実でないだけでなく、レイテンシ アライメントですらタイル間にないことがあります。このような場合、これらのタイルをアライメントするメカニズムを提供する必要があります。このメカニズムは、IP 内にインプリメントされ、ソフトウェア ドライバーの API 呼び出しで管理されます。

マルチタイル同期がどのようにアライメントを達成するかを理解するには、まず取り除く必要のあるアライメントのばらつきの原因を理解することです。  これについては後で説明しますが、進める前に次の点についてご理解ください。

IP でこの機能を有効にし、ソフトウェア API を使用してタイルをアライメントするのはもちろん必須ですが、実際にこのメカニズムで実行されるのは、タイル間にデジタル アライメントを提供することだけです。PCB およびクロッキング規則に従う必要もあります。これについては、『PCB デザイン ユーザー ガイド』を参照してくだいさい。

上記を念頭に置いて、レイテンシのばらつきの主な原因について説明します。次の図を見てください。

タイル間でのレイテンシ不一致の原因に番号を振りました。
z02.png

1.サンプル クロック スキュー:

RF-ADC または RF-DAC タイル クロック入力はアライメントする必要があります。不一致があると、コンバーターが同じ瞬間にサンプリングしません。これは、内部で修正できません。このため、トレースは PCB で遅延一致させる必要があります。

2.タイル PLL の分周器フェーズ:

サンプル クロックを作成するのにタイル PLL が使用される場合、2 つのタイル間で PLL の出力分周器が必ずしも同じ位相になるわけではありません。これは、スタートアップ時にリセットが解除されるタイミングを制御しないからです。このため、タイル間のこれらの分周器のすべてを同期リセットして、アライメントされるようにする手段が必要です。

3. DUC/DDC デジタル クロックの分周器フェーズ:

同様に、RF-ADC および RF-DAC タイルのデジタル部分はコンバーターのサンプル クロックの分周されたバージョンで実行されます。タイル間でこれらの分周器が同じ位相でリセットから解除される保証はありません。これらの分周器は、共通のリセット ステートにする必要があります。

4. デュアルクロック FIFO の読み出し/書き込みポインター リリース:

タイルと PL ファブリック間のデータを安全に渡す FIFO の読み出しサイクルは、読み出しイネーブルがアサートされるか、書き込みがアサートされるかによって、レイテンシの M または M+1 サイクルのいずれかにできます。これには、タイル同期を達成するための修正手段が必要となります。

タイル間の同期をイネーブルにするソリューションを使用すると、上記の考慮事項を解決できます。これは IP に実装されており、それを制御するための独自の API 呼び出しセットも RFDC ドライバーに含まれています。このスキームのポイントは、JESD204B で使用される SYSREF の概念を借りることにあります。この場合、SYSREF をシステムの共通タイミング基準として使用します。SYSREF にはいくつか規則があり、それらはすべて PG269 UG583 で説明されています。これらについては、この後の同期手順で説明します。SYSREF をタイルと PL ファブリックの両方に提供する必要があります (それぞれアナログ SYSREF および PL SYSREF と呼ばれます)。どうしてこの呼び方にったのかは、この後すぐにわかります。

とりあえず開始してみましょう。ソリューションを見てみる前に、PCB の注意事項について説明します。

ADC および DAC タイルのサンプル クロックは、すべて位相がアライメントされた状態で、同時にタイルのクロック入力に到着する必要があります。また、DAC 出力パスと ADC 入力パスは遅延一致する必要があります。前述のように、ソリューションはここではデジタル アライメントを提供するだけなので、クロックまたはデータ ラインの不一致がタイル同期の終了後に未処理のスキューとして表示されます。

アナログ SYSREF および PL SYSREF 信号は、どちらも同時に各入力に到着するように RFSoC に配線される必要があります  (重要ポイントです。これについても後で説明します)

IP で同期するタイルの MTS をイネーブルにする必要があります。

 

以前に記述したように、一番小さい番号の DAC および ADC タイルは常に同期グループに含める必要があります。

z04.png

ソフトウェア アプリケーションには、マルチタイル同期をランタイムで実行する API 呼び出しを含める必要があります。

z05.png

また、セットアップで MTS をテストする際にメタル ログのログ レベルを DEBUG に設定するのも良い方法です。メタル ログには、MTS 中に何が発生しているかの詳細が示されるので、MTS の問題をデバッグする際の貴重な情報源となります。

z06.png

ソフトウェア アプリケーションでは、ADC および DAC 同期グループの構造を宣言する必要があります。

MTS を実行するには、これらの構造を初期化して設定する必要があります。

最も単純な場合、同期する必要のあるタイルを指定して、マルチタイル同期関数 (XRFdc_MultiConverter_Sync) を呼び出して、タイルをアライメントする IP を取得するだけですみます。

z07.png

では、この API が実行される場合、実際には何が起こっているのでしょうか。

こういう場合に、メタル ログの情報が役立ちます。

まず、SysRef が同期されるすべてのタイルに分散されます。  次に、タイル内のアナログ サンプル クロックで遅延タップ チェーン (DTC) を使用して SYSREF を取り込みます。タイルで PLL をイネーブルにしている場合は、PLL VCO も使用して取り込みます。

ログからは、遅延タップ チェーンの真ん中のタップ 64 で開始し、SysRef がサンプル クロック周期の中央にくるような理想的なタップを見つけるためにスイープしていることがわかります。

metal: info:      DTC Scan T1

metal: debug:     Target 64, DTC Code 7, Diff 57, Min 57

metal: debug:     Target 64, DTC Code 44, Diff 20, Min 20

metal: debug:     Target 64, DTC Code 93, Diff 29, Min 20

metal: debug:     RefTile (0): DTC Code Target 64, Picked 44

metal: info:      ADC0: 00000000000000011113222220000000000000000000*0000000000000000000#111322222200000000000000000000000000000000000000111122222000000

metal: debug:     Tile (1): Max/Min 44/44, Range 0

metal: debug:     Tile (1): Code 9, New-Range: 35, Min-Range: 35

metal: debug:     Tile (1): Code 47, New-Range: 3, Min-Range: 3

metal: debug:     Tile (1): Code 96, New-Range: 52, Min-Range: 3

metal: debug:     Tile (1): Code 47, Range Prev 0, New 3

metal: info:      ADC1: 00000000000000000001111322222000000000000000#00*00000000000000000001111322222000000000000000000000000000000000000000111132222200

 

DTC スイープを見てみると、0 が並んでいます。これは、クロック周期の安定部分で、遷移を表す 1/2/3 で囲まれています。スキャンで # * が含まれたことがわかります。この # は開始箇所を、* DTC コードの安定した部分を示しています。選択されたコードが使用され、次のタイルの DTC に渡されます。タイル 0 ではタップ 44 で理想的なコードが検出され、タイル 1 ではコード 44 から開始され、いくつかのコードを試してコード 47 に決定されています。

SYSREF 信号が高品質なフリーランニングの低ジッター短形波である必要があるのはこのためです。ノイズが多い場合は、取り込んだ箇所で不一致になり、タイル間のアライメントがずれることがあります。

タイルに取り込むのが安全になれば、SYSREF を使用して、タイルのデジタル部分のドライバーすべてを同期リセットします。SYSREF 周波数をグローバル クロック分周器の整数の約数 (GCD(DAC_Sample_Rate/16, ADC_Sample_Rate/16)) にする必要があるのはこのためです。また、それをサンプリングする PL 側のクロックの周波数も約数にするようにしてください。

この分周器のリセットが発生したら、すべてのタイル間に共通のクロッキングができます。タイル内部すべてがアライメントされます。レイテンシ不一致の原因を示す上記の図に戻ってみてください。ここでは 2 番と 3 番を処理しました。

デュアル クロック FIFO からのタイル間に内在する不一致はまだ処理していないので、まだ終わりではありません。どうすればこの問題を解決できるでしょうか。

まず PL ユーザー SYSREF PL クロック ドメインに取り込みます。違っている場合は AXI-Stream クロック ドメインに取り込む必要があります。これも、SYSREF がすべての PL クロックの整数の約数である必要がある理由です。これで SYSREF PL クロック ドメインに安全に取り込まれます。

z08.png

では、先ほど記述したように、アナログ タイル側の SYSREF PL ユーザー SYSREF が必要となる理由を説明し、それらが同時にそれぞれの入力に到着する必要があるのかについて説明します。

MTS の次の段階では、PL ユーザー SYSREF とタイル SYSREF のタイル間のそれぞれのフライト タイムが比較されます。

これらはデバイス パッケージ ボールでアライメントされるので、安全に取り込まれ、FIFO のいずれかの側に同時に到着します。このため、フライト タイムやタイル間の相対的レイテンシの不一致の原因は、FIFO からのみです。この場合、IP を使用してマーカー ビットを FIFO に挿入します。これは、マーカー カウンターを FIFO の読み出し側で停止するために使用されます。この後、マーカー カウンターが比較されます。これで、すべての FIFO が一致するように FIFO の読み出しポインターを調整できます。

メタル ログには、マーカー カウンターの読み出しとその調整が表示されます。

metal: debug: Marker Read Tile 0, FIFO 0 - 00006000 = 0000: count=41, loc=0, done=1

metal: info: DAC0: Marker: - 41, 0

metal: debug: Marker Read Tile 1, FIFO 0 - 0000A000 = 0000: count=41, loc=0, done=1

metal: info: DAC1: Marker: - 41, 0

metal: info: SysRef period in terms of DAC T1s = 1024

metal: info: DAC target latency = 656

metal: debug: Tile 0, latency 656, max 656

metal: debug: Tile 1, latency 640, max 656

metal: debug: Target 656, Tile 0, delta 0, i/f_part 0/0, offset 0

metal: debug: Target 656, Tile 1, delta 0, i/f_part 0/0, offset 0

 

最後に MTS 調整に関するレポートを作成できます。

Z09.png

=== Multi-Tile Sync Report ===

DAC0: Latency(T1) =656, Adjusted DelayOffset(T8) =  0

DAC1: Latency(T1) =656, Adjusted DelayOffset(T8) =  0

DAC2: Latency(T1) =656, Adjusted DelayOffset(T8) =  0

DAC3: Latency(T1) =656, Adjusted DelayOffset(T8) =  0

 

タイル同期が実行されたら、ハードウェアでレイテンシ アライメントを確認できます。

次は、MTS の実行後の 28DR 8 個の ADC すべてへの単一のトーン入力の結果を示しています。

Z11.png

すべてのガイドラインに従っていれば、+/-1 T1 クロック周期の仕様内でアライメントが達成できます。

実際には、下位の T1 範囲で未処理の不一致が残ったままになります。前述のように、この不一致は本当にアナログ I/O およびタイル入力クロックの PCB トレースが原因であることがわかります。

 デターミニスティック レイテンシはどうなりますか。

最初に、パワーアップ間でアライメントとデターミニスティックの両方が必要な場合もあると書きました。この機能は、MTS API にビルトインされています。

MTS のデータ構造メンバーの 1 つに Target_Latency があります。これにターゲットを設定すると、常に FIFO で同じレイテンシになるように IP が調整されます。

これには、ターゲット レイテンシを 0 に設定し、最大レイテンシ測定を使用して FIFO を観察し、マージンを追加して、この値をその新しいターゲットに設定します。

このマージンは、サンプル クロック数として表記されます。RF-ADC タイルの場合は、この値が FIFO 読み出しワード数 X 間引き係数の乗算結果である必要があります。RF-DAC タイルの場合は定数 16 (かなり安定) が表示されます。

MTS はデフォルトでタイルをアライメントするので、ターゲットが低すぎると、達成できないのでタイルの同期だけ実行することがメタル ログに示されます。

まとめ:

このブログでは、MTS がどのように機能するかと、それがメタル ログでどのように表示されるかについて説明しました。また、マルチタイル同期ソリューションについて説明し、IP 製品ガイド、PCB ガイド、この機能の使用経験からの情報をまとめ、メタル ログからのメッセージについて説明しました。

メタル ログには、エラー レポートに関してはほかにも多くの機能があるので、今後機会があれば、MTS エラーのデバッグ方法に関する別のブログを記述する予定です。

 

 

 

more
4 0 390
katsuki
Xilinx Employee
Xilinx Employee

概要

Zynq MPSoC デバイスのイーサネット アプリケーションを実行する際に、PL ロジックを使用するのではなく PS の Ethernet MAC (GEM) コアを使用することを考慮している場合は、このブログに示されるガイダンスおよびデバッグに関するヒントを参考にしてください。 

尚、本ブログは、Debugging Tips when using GEM on Zynq MPSoC devicesを翻訳したものです。

Read more...

more
7 0 1,173