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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Xilinx Employee
Xilinx Employee

概要:

Memory Interface Generator (MIG) IPは、サンプル デザインを生成することができます。このサンプル デザインを使用してバンクやピン配置を設定して確認できます。またシミュレーションを実行して必要な帯域を確認できます。

このブログは、UltraScale アーキテクチャの MIG IP に関するデバッグ テクニックの中で、 サンプルデザイン に関してまとめたものです。

 

 

Memory Interface の開発フロー:

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

flow.PNG

 

サンプル デザインの生成:

PG150 には、サンプル デザインの生成について記載されています。MIG IP を作成後、右クリックで [Open IP Example Design] をクリックすると、自動でサンプル デザインが生成されます。

example.PNG

 

サンプル デザインの利点:

  • バンク選定、ピン配置
  1. ピン配置の決定には、サンプル デザインを使用できます。ピン配置を決定したサンプル デザインでエラーが発生せずにビットストリームを生成できる場合は、そのピン配置に問題がないことがわかります。
  2. PG150(英語版、日本語版)の各メモリのチャプターにおいて、「Designing with the Core」にクロック、リセット、およびピンおよびバンク規則が示されています。このガイドラインを満たすようにしてください。clock.PNG

 

 

注意事項として、sys_clk はMIG IP と同じカラムから入力する必要があります。別カラムからの入力、MMCM 経由で供給することはできません。

下図は、Zynq UltraScale+(ZCZU7) の例です。MIG IP Bank 63 Bank  68に配置する場合は、sys_clk は同じカラムの Bank 63 Bank 68から入力できます。異なるカラムのBank 27Bank 28から入力することはできません。カラムの確認は、次のユーザー ガイドから確認できます。

・UltraScale and UltraScale+ FPGAs パッケージおよびピン配置ユーザー ガイド(UG575:英語版日本語版v1.14

・UG1075 : Zynq UltraScale+ デバイス パッケージおよびピン配置ユーザー ガイド(UG1075:英語版日本語版v1.8

col_bank.PNG

 

  • シミュレーション
  1. MIG IPは、入力するアドレス マッピングによって帯域が異なります。PG150のセクションⅡ、第2章の効率およびレイテンシの測定において、DDRバスの効率の例が示されています。DDRバスの場合は、バースト読み出し/書き込み、および連続読み出し/書き込みは効率が良く、ランダムなアドレス読み出し/書き込みは効率が下がっていることが分かります。efficiency.PNG

     

  2. PG150のセクションⅡ、第4章にMIG IPのパフォーマンスの記載があります。perfomance.PNG

    MIG IPは、DRAMへのアクセスを最適化するようにグループFSMに基づいたスケジューリングを行っています。グループFSMは、入力されるアドレスのbitの並びから決められます。PG150のTable 4-83の例においてグループFSMは、ROW_BANK_COLUMNの時は12bitと13bitを、ROW_COLUMN_BANKの時は3bitと4bitを使用して決められていることが分かります。

    fsm.PNG

    一般的にMIG IPは、PG150のTable 4-84に示すようにグループFSMを3、2、1、0のように数字を変化させる方が帯域を確保しやすい傾向にあります。お客様で検討されているアドレス マッピングをシミュレーションして、帯域を確保できることを事前に確認してください。

    fsm_change.PNG

     

Read more
1 0 131
Xilinx Employee
Xilinx Employee

本ブログは英語版のAnalyze This: Unboxing the RF Analyzer Tool Part Oneを翻訳したものです。

 

RF データ コンバーターに関する前回のブログ記事では、ソフトウェア ドライバーについてと、それを使用してどのように RF Data Converter IP のステータスおよび制御を管理できるかを確認しました。

単純なスタンドアロンのアプリケーションを記述すると、システムの RF-ADC および RF-DAC の動作をデバッグできることについても説明しました。

この前回のブログ記事の中で、ザイリンクスが RF アナライザーを使用して、あらゆるボードのあらゆるデバイスで RF データ コンバーター デバッグをイネーブルにしていることを紹介しました。今回と次回の 2 つのブログ記事では、RF アナライザーをアンボックスし、その主な機能と、RF アナライザーを使用して RF-ADC および RF-DAC タイルを管理する方法を説明します。また、RF アナライザーを使用して RF-DAC スティミュラスを生成したり、RF-ADC で受信したデータを表示および解析したりする方法も紹介します。

RF アナライザー GUI をダウンロードするには、RFSoC リソース ページを参照してください。

アナライザー GUI の使用方法は、『RF データ コンバーター インターフェイス ユーザー ガイド』 (UG1309) を確認してください。

また、バージョン 2018.3.1における制限のいくつかを理解するために、、(Xilinx Answer 71746) を参照してください。バージョン 2019.1 に改善点がいくつか含まれる予定のため、乞うご期待ください。


RF アナライザーに特化したブログ記事は 2 部構成になっており、パート 1 の今回は、RF アナライザーの構築ブロックをいくつか見てみることにします。RF アナライザーを構成する主要素は 3 つあると、私は考えています。

まず、プログラマブル ロジック (PL) デザインがあります。これは、Zynq® UltraScale+® RF Data Converter IP のサンプル デザイン、RF サブシステムのステータスと制御をイネーブルにするための MicroBlaze™、および GUI へのデータパスと GUI からのデータパス用の JTAG to AXI Master IP で構成されます。このデザインには、クロック生成もいくつか含まれます。

 

これの最も大きな利点は、自分のデザインに一致する IP 設定を持つことができる点です。これで自分のデザインとRF データ コンバーターを切り離せるという意味です。これにより、自分のデザインから切り離し、システムのデータ コンバーター パフォーマンスを検証し、RX データをキャプチャして、RF アナライザー GUI でデータを解析できます。

この自己完結型で柔軟性の優れたデザインには代償があり、オンチップ ブロック RAM を使用して再生/キャプチャ用のストレージが構築されるようにするために DDR メモリを管理する方法がないことを理解する必要があります (任意のデバイス/任意のボードでブート可能にするため)。使いやすさのため、RF アナライザー パッケージで使用可能な各デバイスにビルド済みビットストリームも提供されます。

PL ビットストリームに続いて、MicroBlaze アプリケーションがあります。このアプリケーションにより、PL デザインの制御パスが管理されます。大まかに説明すると、MicroBlaze アプリケーションでは、RF アナライザー GUI からコマンドを受信して解析し、ドライバー API を使用してタイルから要求されたものをリードバックしたり、タイル設定を変更したりします。これは、RF アナライザー デザインを含む ELF ファイルとして提供されます。

最上位には、データ キャプチャとスティミュラス生成/再生用に RF-ADC および RF-DAC タイルと通信できるようにする LabVIEW GUI があります。この GUI は、ZCU111 RFSoC 評価 GUI と同じスタイルになっています。

 

次の図に、 RF アナライザーの概要を示します。
RF1.jpg

これで RF アナライザーの概要は理解できたかと思いますので、もう少し詳しく掘り下げていきましょう。まずは、カスタム IP の設定から開始し、RF アナライザー環境でそれを使用するために必要なステップをすべて実行してみましょう。

ここでは、ZCU1275 特性評価ボードを使用することにします。これには 16x16 ZU29DR デバイスが含まれています。このボードについては、それほど理解する必要はありません。次のことだけを確実にしてください。

  • コンバーターのクロッキングが設定されている
  • 特定の IP 設定に一致するように Bulls Eye コネクタがセットアップで正しく接続されている

残りは RF アナライザーによって管理されます。これについては、プロセスの後半で説明します。

最初のステップは、IP の設定です。これは、RF アナライザー PL デザインを構築する開始点です。IP は、IP カタログから選択可能か、IP インテグレーターのブロック デザインに含まれています。

一部の CW (Continuous Wave = 連続波) トーンを確認する RF-ADC および RF-DAC 設定をお見せするとわかりやすいのではないかと思います。

次に、RF-DAC からアップ コンバージョンした QAM16 ベクターを送信して RF-ADC でそれを受信できるループバックを有効にするために、2 つのタイルを設定します。

ここでは、RF-ADC はサンプル レートの 1966.08 MHz で、RF-DAC はサンプル レートの 3932.16 MHz でそれぞれ設定します。
RF2.jpg

すると、ここに示すような IP になります。2 つの DAC タイルがアクティブで、2 つの ADC タイルが使用されています。
RF3.jpg

[OK] をクリックし、IP のアウト オブ コンテキスト合成をスキップできます。

サンプル デザインの作成時に RF アナライザーをイネーブルにすることをツールに指示する必要があります。これを実行するには、Vivado Tcl コンソールで次のコマンドを入力する必要があります。

set_property -dict [list CONFIG.RF_Analyzer {1}] [get_ips]

次に、IP を右クリックし、[Open IP Example Design] をクリックします。これで、サンプル デザインとアナライザーの基盤を含む新しいプロジェクトが生成されます。

このデザインの最上位で STARTUPE3 ブロックを活用し、AXI4-Lite クロックおよび外部リセットをデザインに提供します。デザインの最上位 HDL ラッパー内にこれがインスタンシエートされているのがわかるでしょう。

ビットストリームが読み込まれると、EOS (End of Startup = スタートアップの終了) 信号が PL ファブリックにアサートされます。これにより、リセットが管理され、デザインおよび実行中のアプリケーションが開始されます。

RF4.jpg

先ほど述べたように、デザインには MicroBlaze が含まれています。

これにより、RF データ コンバーターのステータスと制御およびクロッキングが管理されます。ここで右クリックすると、関連付けられている ELF ファイルがあることを確認できます。

RF5.jpg

これにより、デザインとアナライザー GUI 間の通信を管理するアプリケーションがビットストリームに埋め込まれます。


このブロック デザインには JTAG To AXI Master があるのもわかります。これにより、ソースおよびシンク IP へのデータパスがそれぞれ管理されます。


AXI SmartConnect を活用して、MicroBlaze/JTAG2AXI Master とデザインの残りの部分との間のインターフェイスを管理します。


IP サンプル デザイン AXI4-Lite インターフェイスへの接続があるのがわかります。

RF6.jpg

クロッキング ブロックもあります。このモジュールで、タイル出力クロックを取り込み、MMCM を使用して AXI4-Stream クロックをタイルへ駆動します。各 MMCM では、AXI DRP ポートがイネーブルになっています。これにより、データ コンバーター クロッキングでの変更と、その延長線上として AXI4-Stream クロックをランタイムに管理するための柔軟性が提供されます。

RF7.jpg

それでは、IP サンプル デザインを含む階層レベルまで掘り下げていきましょう。

メイン プロジェクトで設定したとおりの RF Data Converter IP と、DAC ソースおよび ADC シンクがここに含まれているのがわかるはずです。これらのブロックはレジスタ トランスファー レベル (RTL) で、右クリックして [Go to Source] をクリックすると詳細を確認できます。

RF8.jpg

RF-DAC データ スティミュラス ブロックは、RF Data Converter コアで有効にされた RF-DAC チャネルに送信されるサンプルを読み込むことができる 128 KB ブロック RAM で構成されています。

実際のところ、DAC ソースは、新しいスティミュラスで書き込まれるブロック RAM または DAC にコンテンツをストリームするブロック RAM を構築するザイリンクス パラメーター指定マクロ (XPM) にすぎません。

スティミュラス ブロックの各チャネルでは、Zynq® UltraScale+® RF Data Converter IP コアの AXI4-Stream を駆動します。各コンバーターでは最大 4 つの AXI4-Stream インターフェイスを持つことができるため、DAC ソース ブロックには最大で 16 個のチャネルがあります。イネーブルになっている各 AXI4-Stream インターフェイスは、DAC0 で開始する連続したチャネルにマップされます。

DAC スティミュラス ブロックのレジスタ マップは、『Zynq UltraScale+ RFSoC RF Data Converter IP 製品ガイド』 (PG269) の表58に記載されています。同様に、ADC ストリーム データはシンク ブロックでキャプチャしてリードバックできます。  

Zynq® UltraScale+® RF Data Converter でイネーブルになっている各 AXI4-Stream 出力のデータは、データ キャプチャ ブロックの個別のチャネルに格納されます。各コンバーターでは最大 4 つの AXI4-Stream インターフェイスを持つことができるため、データ キャプチャ ブロックには最大で 16 個のチャネルがあります。

有効にされた各 AXI4-Stream インターフェイスは、ADC0 で開始する連続したチャネルにマップされます。

各チャネルのストレージは、128 KB のブロック RAM で構成されます。キャプチャ ブロックのアドレス マップは、『Zynq UltraScale+ RFSoC RF Data Converter IP 製品ガイド』 (PG269) の表 58 に記載されています。

これをインプリメントしてビットストリームを生成する前に、デザインの制約を次のファイルで確認できます。

usp_rf_data_converter_0_example_design.xdc

これらの制約により、プライマリ クロックが作成され、デザインをフロアプランするために物理ブロック (Pblock) がいくつか追加され、スティミュラスおよびキャプチャ メモリがデータ コンバーター タイルに隣接するようになります。

ドメインと AXI4-Stream クロック ドメイン間のクロック ドメインをまたぐ静的制御信号を管理するために追加されるタイミング例外がいくつかあります。

たとえば、num_samples_reg では、RF-ADC から取得または RF-DAC タイルに送信するサンプルの数をサンプル デザインのデータ スティミュラスおよびキャプチャ ブロックに指示します。これは制御パス上にあるため、axi_aclk に同期します。この設定は、AXI4-Stream クロックで実行されるスティミュラスおよびキャプチャ ブロックのアドレス カウンター ロジックによって使用されます。信号は頻繁に遷移するべきではありませんが、たとえそうだとしても、インプリメンテーション中のタイミング パスとしてこれを無視しても問題ありません。 

この時点で、write_bitstream までデザインを実行できます。

これで、タイミングが満たされるのがわかるでしょう。Pblock は、関連タイルに隣接するキャプチャおよびスティミュラス メモリをロックするために使用されます。

RF9.jpg

ビットストリームは、次のようなパスに生成されます。

<example_design_path>\ip_name\ip_name.runs\impl_1

これで、このビットストリームをダウンロードする準備が整い、アナライザーを使用するために必要なものがすべて揃ったので、ボードのデータ コンバーターを動作確認できます。

次回は、ZCU1275 特性評価ボードを使用してこのビットストリームをブートし、RF アナライザー GUI の機能を見てみることにします。 

それでは、またお会いしましょう。

Read more
3 0 338
Xilinx Employee
Xilinx Employee

概要

FPGA デザインでパフォーマンス ターゲットを満たすのに苦労することがよくあります。さまざまな理由がありますが、次のようなものが挙げられます。

  • UltraFast 設計手法に従っていない
  • タイミング制約が正しく設定されていない
  • リソースを使い過ぎている
  • 制御セットが多すぎる
  • クロッキングが最適ではない
  • ターゲット パフォーマンスに対してロジック段数が多すぎる
  • フロアプランが誤っている
  • 配線が密集している
  • 制約が原因でツールによる最適化が制限されている

このような問題を検出して最小限のエフォートで修正できる方法はありますか。

QoR (結果の品質) 推奨項目レポート (RQS)

QoR 推奨項目レポート (RQS) では、デザインの問題を検出して、ツールのオプションやセルでのツールの動作に影響するプロパティをソリューションとして提供したり、ソリューションを自動化できない箇所でのテキスト変更を推奨します。

Vivado 2019.1 では、RQS で推奨項目が出力されるようになりました。これにより、推奨項目を監視して、これらのインプリメンテーションを自動化し、各推奨項目の検証を向上し、さらに複雑な推奨項目を出力できるようになります。ここでは、このフローでの新しいコマンドとフローの調整について見ていきます。

1.png

 

  1. report_qor_suggestions コマンドを実行すると、新しい推奨項目が生成され、既存の推奨項目がレポートされます。次の図に示すように、このコマンドはインプリメンテーション プロセスのどの段階の後でも実行できます。
  2. 推奨項目のレビュー後に write_qor_suggestions コマンドを使用すると、選択した推奨項目を含む RQS ファイルを書き出すことができます。推奨項目は、このプロセスの間自動的に ENABLED (表示される推奨項目のプロパティ) になっています。
  3. 次に RQS ファイルは、通常 synth_design コマンドおよび opt_design コマンドを実行する前に推奨項目 run に読み込まれます。このフローでは、APPLICABLE_FOR フロー段階を通過した後に AUTOMATIC 推奨項目が適用されます。

AUTOMATIC 推奨項目が APPLIED (適用) されるには、APPLICABLE_FOR 段階が推奨項目 run に呼び出されるときに ENABLED になっている必要があります。次の図に 1 つの推奨項目が APPLICABLE_FOR 段階を通過するときにどう処理されるかを示します。

2.png

推奨項目 run では、report_qor_suggestions コマンドを再度実行できます。このプロセス全体を繰り返すことが可能で、1 つ前の run の推奨項目と現在の run の推奨項目を 1 つのファイルにまとめ、最新の推奨 run に入力できます。

推奨項目の一部が不要の場合は、次のコマンドを使用して推奨項目の書き出しを制限できます。

write_qor_suggestions -of_objects [get_qor_suggestions -filter {some_fillter}]

フロー中に report_qor_suggestions コマンドを複数実行すると、同じ推奨項目がフローの異なる段階で生成されることがありますが、RQS で重複した推奨項目が自動的に管理されます。

それでも、重複した推奨項目が表示される可能性はあります。たとえば、合成を実行したときや opt_design の推奨項目を実行すると、同じ結果になる可能性があります。このような場合は RQS 1 つの推奨項目のみが APPLIED (適用) されます。このとき合成の推奨項目が優先されます。

また、チェックポイントが書き出されるときは、推奨項目の現在の状態がチェックポイントに保存されます。このため、推奨項目を読み込んだ後にチェックポイントを書き出した場合は、このチェックポイントを開き直したときに推奨項目を再び読み込む必要がありません。

ケース スタディ例

例を 1 つ挙げて推奨項目がどう適用されるか見てみましょう。

次に、この特定のサンプル デザインで place_design コマンドを実行した後に表示される可能性のある推奨項目のリストを示します。

3.png

 

推奨名

まず、リストの名前に注目してみましょう。最初の推奨項目には「RQS_XDC-1-1」という名前が付いています。[Name] を見ると、推奨項目のカテゴリーがわかります。XDC には、合計 6 つのカテゴリーがあります。

  • Utilization (使用率)
  • XDC
  • Clocking (クロッキング)
  • Congestion (密集)
  • Timing (タイミング)
  • Strategy (ストラテジ)

大まかではありますが、次の図に示すように、使用率、XDC、およびクロッキングに影響する推奨項目は、デザイン サイクル早期で解決する必要があります。

4.png

 

これらの推奨項目は通常多数のパスに影響し、後のデザイン クロージャ プロセスで発生する密集およびタイミング上の問題の深刻さを低減します。クロッキング、使用率、および XDC の推奨項目と同時にアプリケーションのタイミングと密集の推奨項目を解決しようとすること自体には問題はありませんが、その場合は使用率を増やしてしまう可能性があります。

この理由からクロッキングおよび XDC の問題の解決前にタイミングおよび密集での問題を解決しようとすることは通常は推奨しません。これは、ザイリンクス UltraFast 設計手法での推奨事項に沿っています。

タイミングおよび密集での問題は、通常、特定のモジュールまたは特定のタイミング パスに集中する傾向にあります。

  • 密集は配置後にのみ発生し、配線後に精度が改善します。
  • タイミングの推奨項目は、通常、RQS でタイミング違反が発生しているパスのみでレポートされます。RQS ではデフォルトでクロック グループごとに 100 個のクロック パスが確認されます。タイミング エラーがあっても、これらのパスで発生してない場合は、RQS で推奨項目が表示されません。パス数を増やすには、次のコマンドを実行します。

 report_qor_suggestions -max_paths <value more than 100>

ストラテジ推奨項目については、今後のブログにて説明します。

自動推奨項目

次に、表の一番下の推奨項目 RQS_CLOCK-1-1 を見てみましょう。この推奨項目は、ツールにより AUTOMATIC (自動的) に実行されます。この推奨項目により BUFG で駆動されているネットに CLOCK_DELAY_GROUP プロパティが適用されます。

最後から 2 番目の推奨項目 RQS_CLOCK-2-1 は手動 (AUTOMATIC = 0) でユーザーが実行するものです。この推奨項目では、BUFGCE_DIV BUFGCE および MMCM 分周器をビルトイン分周器に置き換えてクロッキング トポロジを最適にするように提案しています。Vivado ではこれらのバッファーの置き換えを自動で実行する機能がないため、RTL での変更が必要です。

エフォートは、AUTOMATIC 推奨項目では低く、マニュアルでは高くなります。次に、自動と手動の推奨項目それぞれに必要なアプローチを示します。

  • 自動
    • オブジェクトにプロパティを適用
    • オプションをコマンドに追加
    • 制約を若干変更
  • 手動
    • RTL デザインの変更が必要
    • 制約のアップデートが必要
    • ユーザー解析が必要

推奨項目のうち 80% 弱が自動です。手動推奨項目ではエフォートが必要なため、一部のクロッキングおよび使用率の手動推奨項目を実行せずに、密集の自動推奨項目を実行しても問題にならないかもしれません。ただし、これらの問題を最初に解決したときのみ最大の QoR が得られます。

QoR ゲイン

次に、次の条件を使用した 30 個のデザインの結果を示します。

  • place_design コマンドの Explore 指示子を使用
  • 推奨項目なしの基準 run と同じフローでの推奨項目 run の比較
    • place_design コマンド実行時にクロッキング推奨項目を生成
    • route_design コマンド実行時にその他の推奨項目を生成
    • 自動推奨項目のみの比較

QoR ゲインは次の 2 つの方法で計測できます。

  • WNS での絶対改善を確認する (メトリクスを確認する簡単な方法)
  • 基準 run でエラーが発生していたクロックすべてでの平均的ゲイン (より確実な QoR ゲイン計測)

次の例は、先ほど確認した表の元になるデザインです。

5.png

 

青色は基準 run、オレンジ色は推奨 run WNS を示します。RQS でデザインの WNS が大幅に改善されることがわかります。30 個のデザインでの平均的な WNS ゲインは 0.648 ns です。

6.png

 

このグラフでは、計測値がはっきりと示されています。タイミングが満たされないクロックすべてに対する平均的な改善率が示されています。この方法では、1 つの信号に大きなエラーあるが、複数のクロックでタイミングが満たされないような場合に数値を平準化します。

これらのデザインでの平均的ゲインは 12.1% です。

また、ゲインが顕著なものがあります。上位 4 つのデザインでは、QoR の向上が平均 34.7% ありました。

ゲインをプロファイルすると、次がわかります。

  • 少数のパスに大きな影響がある特定の問題があるときに 20+% QoR ゲインが見られる。これは、簡単に解決できます。
  • クロッキングの問題を解決すると 10+% QoR ゲインが見られる。
  • 通常デザイン クロージャ段階の最後に個々のタイミング パスの問題を解決すると、多少の QoR ゲインが見られる。

簡単に解決可能な問題が既に解決されている場合は、通常ゲインが見られるのが困難です。このプロファイルから、RQS デザイン サイクル全体に影響があり、デザインで大きな変更を加えた場合には実行するべきであることがわかります。

手動推奨項目により手動で変更を加えた場合に得た QoR ゲインを計測するのは困難ですが、その場合は、上記の数値をさらに上回る可能性があります。

次のステップ

RQS を開始する場合は、チュートリアルから始めるのが最適です。

https://japan.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug938-vivado-design-analysis-closure-tutorial.pdf

また、QoR の向上に関するブログを参照してください。次に 'report_qor_assessment' に関するブログ記事をリリース予定です。

Read more
4 0 419
Xilinx Employee
Xilinx Employee

本ブログは英語版のAXI-Basics Blogを翻訳したものです。

 

概要

AXI インターフェイスで発生するトランザクションをモニターすると役立つ場合があります。このブログでは、特定のアドレスで発生するトランザクションの読み出しおよび書き込みをカウントする基本的な AXI4-Lite Sniffer IP を作成する方法を紹介します。

HDL (Verilog) コードを記述した後に、コードを IP としてパッケージし、この IP IP インテグレーター ブロック デザイン (BD) に追加します。

AXI Sniffer IP には、AXI4-Lite リンク 1 つと出力 2 つをモニターする AXI4-Lite 入力インターフェイス 1 つを含めて、特定アドレス (GUI で指定可能) で発生した読み出しおよび書き込み数をカウントします。

 

AXI5_1.png

 

Vivado IP インテグレーターで使用する AXI Sniffer IP の作成 (チュートリアル) 

  1. このブログに添付されているデザイン ファイルをダウンロードします。
  2. Vivado 2019.2 を開きます。
  3. [Tcl Console] ウィンドウで、cd コマンドを使用して (cd AXI_Basics_5)ZIP 解凍ディレクトリに移動します。
  4. [Tcl Console] ウィンドウで source ./create_proj.tcl を使用して tcl スクリプトを実行します。
    これで AXI4-Lite マスターとして設定した AXI VIP および AXI GPIO IP から構成された BD を使用した Vivado プロジェクトが作成されます。このデザインは、ブログ記事: AXI の基礎 3 で作成した最終デザインと類似しています。
     

    AXI5_2.png


    このプロジェクトでは、AXI Sniffer IP を作成し、この IP AXI VIP IP AXI GPIO IP 間の AXI4-Lite インターフェイスに接続します。

    まず、AXI Sniffer IP HDL (Verilog) コードを記述します。

 

  1. [Sources] ウィンドウで AXI_Sniffer.v ファイルをダブルクリックしてテキスト エディターで開きます。

     

    AXI5_3.png



    まず、IP のポートを宣言する必要があります。AXI4-Lite インターフェイスが 1 つ必要です。AMBA® AXI™ および ACE™ プロトコル仕様は Arm のウェブサイト (リンク) から入手可能です。これらの信号が AXI4-Lite インターフェイスに必要です。

     

    AXI5_4.png



    またポートを 2 (read_accesses および write_accesses) 追加して、IP が監視しているアドレスへの読み込み/書き込みアクセス数をカウントする必要があります。

 

  1. 次のコードを追加して、必要な信号をすべて宣言します。
module AXI_Sniffer
(
    input           aclk,
    input           aresetn,
    input           s_axi_arvalid,
    input           s_axi_arready,
    input [31:0]    s_axi_araddr,
    input [2:0]     s_axi_arprot,
    input           s_axi_rvalid,
    input           s_axi_rready,
    input [31:0]    s_axi_rdata,
    input [1:0]     s_axi_rresp,
    input           s_axi_awvalid,
    input           s_axi_awready,
    input [31:0]    s_axi_awaddr,
    input [2:0]     s_axi_awprot,
    input           s_axi_wvalid,
    input           s_axi_wready,
    input [31:0]    s_axi_wdata,
    input [3:0]     s_axi_wstrb,
    input           s_axi_bready,
    input           s_axi_bvalid,
    input [1:0]     s_axi_bresp,
    output [31:0]   read_accesses,
    output [31:0]   write_accesses
    );

 

注記: IP による動作は AXI4-Lite インターフェイスで実行されず、インターフェイスのトラフィックが監視されるのみなので、すべての AXI4-Lite 信号が入力として設定されます。


次に、監視するアドレスを設定するパラメーターを IP に追加する必要があります。

  1. 次のコードを追加します。
module AXI_Sniffer
#(
    parameter  SLAVE_BASE_ADDR  = 32'h40000000
)
(

 

最後に、アドレスへのアクセス数をカウントするロジックを追加する必要があります。次のコードでは、監視するアドレスが設定されているときに tready tvalid high になるとカウンターが増加します。

  1. 次のコードを追加します。
reg [31:0] read_accesses_cnt;
reg [31:0] write_accesses_cnt;
    
assign read_accesses  = read_accesses_cnt;
assign write_accesses = write_accesses_cnt;
    
//Check the Read Address Channel
always @(posedge aclk)
begin
    if(aresetn == 0)
    begin
        read_accesses_cnt  = 0;
    end
    else if (s_axi_arready && s_axi_arvalid && s_axi_araddr == SLAVE_BASE_ADDR)
    begin
        read_accesses_cnt = read_accesses_cnt + 1;
    end
    else
        read_accesses_cnt = read_accesses_cnt;
end
    
//Check the Write Address Channel
always @(posedge aclk)
begin
    if(aresetn == 0)
    begin
        write_accesses_cnt = 0;
    end
    else if (s_axi_awready && s_axi_awvalid && s_axi_awaddr == SLAVE_BASE_ADDR)
    begin
        write_accesses_cnt = write_accesses_cnt + 1;
    end
    else
        write_accesses_cnt = write_accesses_cnt;
end
 
endmodule
 

 

  1. AXI_Sniffer.v ファイルを保存します。

    IP
    インテグレーターで BD HDL ファイルをインポートします。
  2. BD を右クリックし、[Add Module] をクリックします。

    AXI5_5.png
     

     

 

s_axi_* 信号がまとめられて、インターフェイス s_axi 1 つ作成されることがわかります。ただし、このインターフェイスを AXI VIP AXI GPIO 間の既存の接続に接続することはできません。

 
  1. [Tools] → [Create and Package New IP] をクリックします。
  2. Create and Package New IP ウィザードの 2 ページ目で、[Package a specified directory] を選択して [Next] をクリックします。
  3. AXI_Basics_5/src/hdl/AXI_Sniffer ディレクトリを選択して、デフォルト設定のままで [Next] [Next] [Finish] をクリックします。

    これで IP パッケージャー プロジェクトが作成されます。[Package IP] タブで、[Ports and Interfaces] セクションをクリックします。

     

    AXI5_7.png



    ここでも、ツールにより s_axi_* 信号が 1 つの s_axi インターフェイスにまとめられていることを確認できます。ここでもこのインターフェイスがスレーブとして設定されています。既存の AXI バスに接続するには、ツールでこのインターフェイスの設定をスレーブの代わりに監視 ([monitor]) に設定する必要があります。

 

  1. s_axi インターフェイスを右クリックして、[Edit Interface] をクリックします。

    AXI5_8.png
     

     

 

  1. [Edit Interface] ウィンドウの [General] タブで、[Mode] の値を [monitor] に変更します。

     

    AXI5_9.png

 

  1. 次に、[Port Mapping] タブをクリックして、[Hide Mapped Ports] をオンにします。

     

    AXI5_10.png

 

  1. 名前が s_axi_* IP の物理ポート ([IP's Physical Ports]) それぞれに該当するインターフェイスの論理ポート ([Interface's Logical Ports]) を識別し、[Map Ports] をクリックしてマップします。

     

    AXI5_11.png

 

  1. すべての s_axi_* IP ポートのマップが終了したら [OK] をクリックし、[Edit Interface] ウィンドウを閉じます。
  2. s_axi インターフェイスを右クリックし、[Associate Clocks] をクリックします。

    AXI5_12.png
     

     

     
  3. 次のウィンドウで、[aclk] がオンになっているはずです。[OK] をクリックします。

     

    AXI5_13.png

 

  1. [Review and Package] をクリックして[Package IP] をクリックします。

     

    AXI5_14.png

 

IP パッケージャー プロジェクトが閉じます。

  1. 最初のプロジェクトの BD から AXI_Sniffer IP を削除します。
  2. 最初プロジェクトの BD を右クリックして [Add IP] をクリックします。IP カタログに自動で追加されているはずの AXI Sniffer IP を検索し、BD に追加します。
    AXI5_15.png
     

     

  3. AXI Sniffer IP の s_axi インターフェイスを AXI VIP AXI GPIO 間に接続してみてください。今回は接続できるはずです。

    AXI5_16.png
     

     

  4. カスタム IP aclk aresetn 入力ポートを対応する BD ポートに接続します。
  5. BD デザインを検証します。エラーやクリティカル警告メッセージは表示されないはずです。BD を保存します。

    最後にシミュレーションで IP が正しく動作するかを確認できます。
  6. シミュレーションを起動して、AXI_Sniffer IP read_accesses ポートおよび write_accesses ポートを波形ウィンドウに追加します。

    AXI5_17.png
     

     

 

  1. シミュレーションを再起動して 3 us 間実行します。

     

    AXI5_18.png



    シミュレーション波形で、書き込みと読み出しのトランザクションが 2 回ずつ発生していることがわかります。ただし、IP では書き込みが 2 回と読み出しが 1 回のみカウントされます。

     

    AXI5_19.png



    各トランザクションのアドレスを確認して出力が正しいかを確認します。2 回の書き込みトランザクションは、IP で監視しているアドレス 0x4000_0000 で発生しています。

     

    AXI5_20.png



    読み出しトランザクションの方は、1 つのトランザクションのみがアドレス 0x4000_0000 で発生しており、もう 1 つのトランザクションではアドレス 0x4000_0008 が読み出されています。このため、IP は正しく動作していることがわかります。

     

    AXI5_22.png



    この記事では、AXI Sniffer IP の使用例を 1 つ紹介しましたが、この Verilog コードを編集して別の機能を追加することもできます。

Read more
1 0 807
Xilinx Employee
Xilinx Employee

本ブログは英語版のRF Data Converter Software Drivers - Really Foolproof, not Really Frustratingを翻訳したものです。

 

こんにちは、ザイリンクスのアプリケーションズ エンジニアの Keith Lumsden (キース ラムスデン) と申します。

ザイリンクス コミュニティに最近追加された「Design and Debug Techniques Blog (設計やデバッグテクニックのブログ)」への寄稿を依頼され、大変光栄に思います。

私の主なフォーカスは、Zynq® UltraScale RFSoC 製品に統合された RF データ コンバーターを使用するお客様にサポートを提供することです。

私は、アナログおよびミックスド シグナル システム、FPGA アーキテクチャ、I/O およびシグナル インテグリティにキャリアの多くを費やしてきました。  ハードウェア系のエンジニアであるため、エンベデッド ソフトウェアは他人事だと思っていました (罪があるかもしれません)

私の考え方は、RF データ コンバーターの誕生で変わりました。世界クラスの RF-ADC および RF-DAC Zynq UltraScale+ アーキテクチャに統合されたのです。従来の RF およびアナログ エンジニアは、これまでになかった形でエンベデッド システムに必然的に接するようになっています。

RF データ コンバーター ソリューション:

詳しい方はご存知のように、RF データ コンバーターは Vivado Design Suite IP コアとしてパッケージされています。これにより、ザイリンクス提供のソフトウェア ドライバーを通じて RF Analog-to-Digital Converter (RF-ADC) および RF Digital-to-Analog Converter (RF-DAC) タイルのステータスおよび制御を管理できます。

Zynq UltraScale+ RFSoC RF Data Converter IP 製品ガイド』 (PG269) (v2.2 英語版v2.0日本語版) に、IP のすべての詳細およびドライバーの詳しい付録が含まれています。

K_1.jpg

RF アナライザー (英語版日本語版) を使用すると、すばやく開始できます。

RF アナライザーは MicroBlaze™ ベースのデザインで、任意のボードの任意のデバイスに展開できる通信層があります。また、RF-ADC で受信している内容を視覚的に表示することを可能にしたり、スティミュラス生成および RF-DAC を介した送信を有効にしたりする GUI もあります。重要なことに、アプリケーションはソフトウェア ドライバーを使用してビルドされます。

RF アナライザーは、RF システムの問題を突き止めようとしている場合に非常に効果的で、スタンドアロンで機能し、デザインまたはボードに依存しないため、システムの RF 部分を検証するために使用すると大きな効果を得ることができます。

一般的なユース ケースは、システムの RF-ADC および RF-DAC をデバッグする場合と、ランタイムにテストするために小型のアプリケーションを書き込む必要がある場合です。RF アナライザーおよびカスタム デザインの両方でソフトウェア ドライバーを使用する必要があると想定し、ドライバーに慣れ親しんでデバッグ用に使い始める方法を示すブログ記事を書くことにしました。次回のブログ記事では、RF アナライザーのアンボックスおよび順を追った説明をする予定です。

RF データ コンバーター システムについては既にある程度理解されている方も多いかと思いますので、未知のものへと話を発展させるのではなく、知識の層を重ねるため、ドライバーについて学習することにしましょう。

このブログ記事では、次について説明します。

  • どのようにドライバーがビルドされるか
  • データ構造体
  • アプリケーション プログラミング インターフェイス (API) を使用した単純なアプリケーションの作成

ここでは、ベアメタル アプリケーションの作成に専念し、これを基にした Linux アプリケーションの作成方法は、今後のブログ記事で説明する予定です。

ドライバーの構築:

RFdc ドライバーの良い点の 1 つは、Libmetal を使用してビルドされることです。Libmetal はザイリンクスが開発したオープン ソース ソフトウェア スタックで、LinuxRTOS (Realtime OS)、およびベアメタル環境におけるデバイスへのアクセス、デバイス割り込みの処理、およびメモリ アクセス要求を実行する一般的なユーザー API を提供します。

これが意味することは何でしょうか。まず、関心のあるドライバー部分がユーザー空間に実装されるため、ハードウェアとの通信機構を気にする必要がないことを意味します。また、API Linux およびベアメタル アプリケーションで共通しているため、2 つの API 呼び出しセットを学ぶ必要がなく、ベアメタルから Linux へのコードの移植を心配する必要がないことも意味します。

K_2.jpg

次の画像に、XRFdc ドライバー ソース コードの詳細を示します。ドライバーのソースは、ザイリンクス SDK インストール ディレクトリまたは Github こちらにあります。

K_3.jpg

この図では、下部に xrfdc_hw.h ファイルがあります。このヘッダー ファイルには、RF-ADC および RF-DAC タイルのレジスタ アドレス マップとして理解されている可能性のあるものが含まれています。このファイルはユーザー用ではなく、ドライバーの内部機構に使用されます。識別子はアプリケーションの記述時に役立つわけではないため、このファイルで使用する必要はなく、勉強する必要もありません。

ほかのヘッダー ファイルの xrfdc.h および xrfdc_mts.h は次を含んでいるため、より重要になります。

  • API 呼び出しで必要なデータ構造体のすべて。
  • API 呼び出しをインプリメントするコードで使用されるインライン (ヘルパー) 関数。
  • アプリケーションで使用するマクロ (ADC タイルには値 0DAC タイルには値 1 API 呼び出しに渡す代わりに、XRFDC_ADC_TILE/XRFDC_DAC_TILE マクロを必要に応じて使用できるため便利です。これにより、コードが読みやすく理解しやすくなります)
  • 最も重要なのは、アプリケーションで使用される API 呼び出しのプロトタイプがこれらのファイルに表示されることです。

次に、API 呼び出しのソース コードを見てみます。ここで、ユーザー API 呼び出しの機能をインプリメントします。通常は、個々の API 呼び出しのインプリメンテーションについて詳しく勉強する必要はありません。

  • xrfdc.c: これは、アプリケーションで使用する API の本体です。
  • xrfdc_intr.c: これにより、RF データ コンバーターからの割り込みを管理するために必要な API 呼び出しがインプリメントされます。
  • xrfdc_mixer.c: XRFdc ドライバーのミキサー設定のインターフェイス関数が含まれています。
  • xrfdc_mts.c: XRFdc ドライバーの複数タイル同期関数が含まれています。

XRFdc ソフトウェア ドライバーの使用

ドライバー ソースに含まれているものを確認したので、実際にそれを使用して実行する必要がある内容についてお話しましょう。

上記で説明したとおり、xrfdc.h ヘッダー ファイルを最も参照することになります。これには、データ構造体および API 関数プロトタイプが含まれています。データ構造体および API 呼び出しについては、『Zynq UltraScale+ RFSoC RF Data Converter IP 製品ガイド』(PG269) (v2.2 英語版v2.0日本語版) の付録 D にも完全に文書化されています。

まず、データ構造体からお話しましょう。

データ構造体とは、RF データ コンバーターに関する情報を意味あるグループに分類する方法です。私は、データ構造体のことを「コンテナー」と考えることにしています。プロのソフトウェア開発者の方からは、「コンテナーは C++ 用語だから、そのように使用するべきではない」と言われそうですが、私はこれが良いたとえだと思っています。

例として、RF-ADC または RF-DAC タイルの位相ロック ループ (PLL) に対するデータ構造体を見てみましょう。PLL に関して把握が必要な可能性のある内容 (: イネーブルされているか、入力クロック、出力するサンプル クロック) がすべて記述されているのがわかります。

K7.png

このような構造体が存在すると、API 間で容易に渡すことができ、場合によっては 1 つで読み出してもう 1 つで変更することも可能です。

また、ある構造体内に別の構造体を含めることもできます。

たとえば、XRFdc_PLL_Settings XRFdc_DAC_Tile のメンバーです。

K8.png

さらに、構造体は透過的であるため、1 つのメンバーだけをコードで変更できます。例として、コンプレックス ミキサーでの NCO (Numerically Controlled Oscillator=数値制御型オシレーター)周波数の変更を挙げることにします。

MixerSettings 構造体には、周波数に対して Freq というメンバーがあるため、コードで次のように変更できます。

MixerSettings.Freq = 2000;//MHz

データ構造体の基礎を習得したら、使用できる API 呼び出しの理解に取り組む必要があります。これらは、アプリケーションの構築ブロックです。

個々の API 呼び出しの機構は、ユーザーに対して抽象化され、XRFdc.c ファイルに実装されています。

呼び出しを使用する場合、知っている必要があるのは 3 点のみです。

  • ターゲットとする ADC または DAC タイルの機能。
  • 入力として渡す必要があるもの。
    これは通常、RF タイル タイプ、タイル ID、およびタイルに必要な個別ブロックを指定することを意味します。
    場合によっては、使用する構造体が API に渡される必要があります。
  • 出力として返すもの。
    たとえば、構造体の内容が返されるようにすることができます。

 

このドライバーで使用される API のタイプは、数個しかありません。

  • タイルを制御するために使用できる管理呼び出しがあります。たとえば、XRFdc_StartUp/XRFdc_Shutdown は、個々の RF-ADC または RF-DAC タイルを起動またはシャットダウンするために使用されます。
  • 概要ステータス レポートを有効にするための API 呼び出しがあります。例は、XRFdc_GetIPStatus/XRFdc_GetBlockStatus です。
  • 個々のサブブロックに対する Get および Set API 呼び出しもあります。たとえば、XRFdc_GetMixerSettings および XRFdc_SetMixerSettings をそれぞれ使用して、コンプレックス ミキサー設定に対して get および set の両方を使用できます。

場合によっては、Get および Set 呼び出しが IP でも設定されます (: コンプレックス ミキサー設定)。一部はランタイム実行専用です。このような例には、RF-ADC しきい値フラグおよび直交変調補正 (QMC) があります。

最後に、これらの変更によっては、タイルの再起動が必要になります。PLL セットアップの変更は、その一例です。

Hello RFdc

ドライバーの感触を得たので、非常に単純な最初のアプリケーションを Zynq UltraScale+ RFSoC ZCU111 評価ボード用に作成できます。

今回は、ADC データをキャプチャするだけにします。デザインについては、今後のブログでいつでも詳しく説明することが可能です。  

IQ データ パターンをいくつか送信し、ミキサーを使用してベースバンドにミキシングした後、デザインの System ILA (Integrated Logic Analyzer) ブロックに出力します。

K_4.jpg

ここでは、先ほどお話した概要ステータスおよび管理 API の一部と、get および set API の一部を示します。

この場合、IP のステータスをチェックし、タイルが正しく開始されていることを確認します。

次に、データパスのステータスをリードバックします。

最後に、ミキサー設定を確認します。

このデザインをインプリメントしてビットストリームを取得したら、ハードウェア ハンドオフ ファイル (HDF) をエクスポートし、SDK を起動します。エンベデッド デザインおよび SDK について詳しく知りたい場合は、チュートリアル (英語版日本語版) を参照すると有益です。

HDF ファイルによってハードウェア プラットフォームが SDK に作成されるため、HDF ファイルでは、デザインで使用されるすべてのペリフェラルおよびそれらのアドレスを認識しています。次は、ボード サポート パッケージの作成です。これにより、ハードウェア定義を取得して、必要な関連ドライバーおよびライブラリをすべて読み込みます。

[File] → [New] [Board Support Package] をクリックします。

作成したハードウェア プラットフォームを選択し、[Next] をクリックします。

K_5.jpg

特定のライブラリを含めるよう指示するメッセージが表示されます。[libmetal] がオンになっていることを確認し、[OK] をクリックします。この段階で、アプリケーションの作成に必要なものがすべて揃ったことになります。

K_6.jpg

[File] → [New] [Application Project] をクリックして、サンプルを作成します。

作成したハードウェア プラットフォームおよび BSP をポイントするようにします。

K_7.jpg

[Next] をクリックし、空のプロジェクトを選択します。

私のアプリケーションのソース コードをこのブログ記事に添付しました。これをインポートすると、テンプレートとして使用できます。

主な機能をいくつか説明しましょう。

まず、xparameters.h ファイル (必要なハードウェア パラメーターがすべて含まれている) および前述の xrfdc.h ファイル (API 呼び出しのドライバー構造体および関数プロトタイプが含まれている) を含める必要があります。

私の場合、ZCU111 ボードを持っており、起動時にクロックをプログラムする必要があります。これを有効にするため、ドライバー ソースの「examples」フォルダーにあるファイルの一部を追加します。

XRFdc 最上位構造体のスタティック インスタンスを作成するところをお見せします。つまり、構造体のインスタンスが 1 つあり、必要になる可能性がある任意の API または関数からそれをポイントできるということをここで示します。

static XRFdc RFdcInst;  /* RFdc driver instance */

main 関数内で、必要な構造体をすべて宣言します。

       int Status;

       XRFdc_Config *ConfigPtr;

       XRFdc *RFdcInstPtr = &RFdcInst;

       XRFdc_BlockStatus BlockStatus;

       XRFdc_IPStatus myIPStatus;

       XRFdc_Mixer_Settings MixerSettings = {0};

ここでは、作成したドライバーのスタティック インスタンスへのポインターを作成しているだけです。

次に、ドライバーを初期化します。これは毎回実行する必要があります。基本的には、xrfdc_g ファイルにある config 表を取得し、XRFdc_LookupConfig 関数を使用して xparameters からの値および設定をこの表に挿入します。次に、これを config ポインターの ConfigPtr に格納します。その後、XRFdc_CfgInitialize API を呼び出すと、RFdcInstPtr に設定が挿入されます。   

これで、アプリケーションでドライバーを使用できるようになりました。

ADC タイルへの入力クロックをプログラムするところをお見せします。

ここでは、XRFdc_GetIPStatus を使用して、有効にした ADC タイルのステータスを確認します。

Status = XRFdc_GetIPStatus(RFdcInstPtr, &myIPStatus);

                    if (Status != XRFDC_SUCCESS) {

                       return XRFDC_FAILURE;

                       }

int powerup_status;

int tile_state;

powerup_status = myIPStatus.ADCTileStatus[0].PowerUpState;

tile_state = myIPStatus.ADCTileStatus[0].TileState;

printf("ADC PowerUp Status: %u\n", powerup_status);

printf("ADC Tile State: %u\n", tile_state);

 

この場合、タイル ステートが 15 になるようにする必要があります。これは、ブロックがスタートアップ ステート マシンの最後に達しており、電源投入ステートが 1 (有効でアクティブであること意味している) であることを示します。

次に使用する API 呼び出しは、XRFdc_GetBlockStatus です。これにより、サンプリング周波数が何に設定されており、デジタル データパスがどのように設定されているかが表示されます。ここでは、この API 呼び出しのタイル タイプを抽象化するために XRFDC_ADC_TILE を使用しています。

 

Status = XRFdc_GetBlockStatus(RFdcInstPtr, XRFDC_ADC_TILE, 0, 0, &BlockStatus);

       if (Status != XRFDC_SUCCESS) {

       return XRFDC_FAILURE;

       }

最後に、XRFdc_GetMixerSettings を使用して、ミキサーの詳細をいくつか表示します。

変更を加えた後、XRFdc_SetMixerSettings を使用して新しい設定を書き込みます。

その後、タイル イベントを生成し、変更をハードウェアに適用します。

すると、ミキサー スケールを 0 から 2 (ハードウェアで AUTO から 1.0 ) 変更したことと、ミキサー設定も変更されたことが、XRFdc_GetMixerSettings によって示されます。

それでは、SDK のデバッガーでアプリケーションを実行してみましょう。

アプリケーションを右クリックし、[Run As...] [Run Configurations] をクリックします。ここでは、システム デバッガーを使用し、[Program FPGA] もオンにします。

([Debug As] を選択することもでき、これを選択すると、[Debug] パースペクティブが有効になり、コードのステップ スルーなどを実行できるようになります。)

K_8.jpg

UART シリアル コンソールに表示されるものを見てみましょう。

(ここでは、ビルトイン SDK ターミナルを使用して接続していますが、任意のターミナル エミュレーターを使用できます。)

K_9.jpg

次が実行されていることがわかります。

  • Hello! が出力される。
  • ZCU111 ボードでクロックがプログラムされる。
  • タイル ステートが 15 (完全に開始されており、AXI ストリームからの有効なデータがあることを意味する) になる。
  • デジタル データパスのブロック ステータスがレポートされる。
  • ミキサー設定の読み出しが表示され、変更が確認される。

最後のチェックでは、RF-ADC からのデータが System ILA に渡されていることが示されます。

K_9a.jpg

最終の考察:

これで、アプリケーションを記述する開始点ができました。私の ZCU111 プロジェクト用にハードウェアブロック デザインをビルドする Tcl スクリプトおよび XDC ファイルを添付しました。アプリケーションの C コードも添付されています。

これらの添付ファイルは、RF データ コンバーターと通信するために記述するアプリケーションの出発点として使用できるはずです。ぜひご自分のベアメタル アプリケーションで練習することをお勧めします。

このブログ記事を基に、今後 RFSoC のほかのデザインおよびデバッグ機能を紹介していく予定です。次回は、任意のプラットフォームで任意の RFSoC デバイスをデバッグできるように、RF アナライザーのアンボックスおよび順を追った説明をします。 

それでは、またお会いしましょう。

 

 

Read more
4 0 304
Xilinx Employee
Xilinx Employee

UltraScale/UltraScale+ GTH/GTYトランシーバーを使用して、ラインレート設定を動的に変更して使用したいことはありませんか? 自社の通信プロトコル向けにGTH/GTYトランシーバー単体でご利用のお客様から多くの問合せを頂いています。

 

B_PIC1.jpg

VivadoのIPカタログのUltraScale FPGAs Transceivers Wizardには1つのラインレートしか設定できないことがわかります。ご存知のようにUltraScale/UltraScale+ GTH/GTY Transceiver Wizardでは ラインレート設定を変更することができないため、トランシーバーユーザーが手動で行う必要があります。

1.DRPインターフェース経由でラインレートを変更する方法

(a) 実現したい line-rate configurationでトランシーバーマクロを生成する。

(b) サンプルデザインを生成する。

B_PIC2.jpg

(c) サンプルデザインの論理合成を実行する。
     Flow Navigator
Run synthesis をクリック

 B_PIC3.jpg

論理合成が完了したら [Open Synthesized Design] を選択してネットリストを開く。

B_PIC4.jpg

(d) Tclコンソールで 以下で添付されているgt_Attributes_97.tclスクリプトを実行する。

B_PIC5.jpg

このスクリプトを実行することで、Channel/Common属性をgtParams.txtファイルに出力することができます。また、GTH/GTY内部の属性だけでなく、固定されたGTH/GTYポートもファイルとして出力されているので、簡単に比較することができます。

~上記の (a)から(d)までの手順をインプリメントしたいGTH/GTYコンフィギュレーションの数だけ繰り返します~

 

 (e) GTH/GTYコンフィギュレーションから出力された gtParams.txtを比較することで、異なる属性がすぐにわかります。

B_PIC6.png

 

(f) DRP I/F (ダイナミック リコンフィギュレーション ポート インターフェース)
DRP I/F
経由で、必要な属性を設定する必要がありますが、各属性のアドレスは UG576/UG578 の付録B/Cに記載されています。
またDRP I/Fの制御方法が分からない場合は、詳細情報はUG576/UG578 2 章に記載されております。

(g) リセット

DRP I/Fでアトリビュート設定が完了したら、GTH/GTYを使用する前に再度リセットを実行される必要があります。


※ ラッパーRTLを比較するよりも、このスクリプトでgtParams.txt を生成して比較することを推奨します。手順として増えてしまいますが、ChannelCommon部分の属性の他に、固定された外部ポートも比較できるので、間違いなく属性を変更できます。

 

2. CPLLキャリブレーションモジュールの設定変更

デザインにCPLLを使用する場合、CPLLキャリブレーションモジュールの信号を変更する必要があります。アンサー レコード (AR#70485)で設定変更が必要な信号の変更方法が記載されていますので、参照してください。

 

B_PIC7.png

B_PIC8.png

UltraScale/UltraScale+ GTH/GTYの動的ラインレートを変更する必要がある場合、上記の(1) (2)をぜひお試しください。

Read more
4 0 220
Xilinx Employee
Xilinx Employee

概要:

近年、外部メモリ (DDR2, DDR3, DDR4など) の動作速度は高速化しつつあります。その外部メモリの動作にあわせて、FPGAMemory Interface Generator(MIG) IPも高速になっています。MIG IPと外部メモリのインターフェース設計において、予期しない不具合のリスクを最小限にすることによって、工程遅延、コスト増加、品質低下のリスクを抑えることができます。

このブログは、UltraScale アーキテクチャのMIG IPに関するデバッグ テクニックをまとめたものです。

 

 

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

評価、設計の段階に応じて行うべき開発手順を分けることができます。この記事では、プロジェクト開始前の確認事項としてFPGA選定について説明します。

 

flow.PNG

 

 

Memory Interface Generator (MIG) IPをご使用いただく前の注意事項:

  • VivadoMIG IPは最新版を推奨します。
  • 既存の MIG IP を異なる FPGA ファミリデバイスへ 移植したり再利用しないでください。
  • MIG GUIに表示されている各種パラメータの値を設定するこで作成できるIPです。IPで出力される RTL は変更せずに使用することを推奨します。
  • MIG IPはサンプル を作成できるようになっています。そのデザインを元にピン配置を含む設計をします。
  • MIG IPには PCB 設計のためのガイドラインが公開されています。ガイドラインを厳密に満たすようにしてください。
  • PCB 完成後は、外部メモリが正常に動作することを確認するために、MIG IPで 生成されるサンプル デザインを使用することを推奨します。
  • MIG IP のチェックリストは必ず実施してください。
  • 問題が発生した場合は、PG150のセクション9、 デバッグに記載されている手順に従って情報整理をお願いします。

 

 

資料の紹介:

  • UltraScale Architecture FPGAs Memory IP(PG150 : 英語版日本語版
  • UltraScale アーキテクチャ PCB 設計ガイド(UG583 : 英語版日本語版
  • メモリインターフェイスUltraScale Designチェックリスト(XTP359)

 メモリ インターフェイス デザイン ハブ - UltraScale DDR3/DDR4 メモリからダウンロードできます。他にも役立つ情報が記載されていますのでご参照ください。

xtp359.PNG

 

 

プロジェクト開始前の確認事項:

  • Vivado、MIG IP のバージョン確認

既知の問題は、AR#58435 に一覧で示されています。常に最新版のVivado、MIG IP を使用することを推奨します。

  • 使用する外部メモリの型番

サポートされているメモリ パーツは、MIG IPのGUIから確認することができます。GUI に表示されていないメモリは、AR#63462に従ってカスタム CSV をMIG IP にインポートすることにより使用できます。

csv.PNG

 

  • FPGA ファミリでサポートされるメモリ

FPGA ファミリによってサポートされるメモリが異なります。例えば UltraScale アーキテクチャでは、DDR2 メモリは使用できません。

fpga_memory.PNG

 

  • MIG IPの動作周波数の確認

MIG IP の最大動作速度は、FPGA のパッケージ、スピードグレード、および DDR メモリの種類によって異なります。各 FPGA のデータシートに DC特性 および AC スイッチ特性に記載されていますので、FPGAを選定するときに確認してください。

・Virtex UltraScale+ FPGA データシート: DC 特性および AC スイッチ特性(DS923:英語版日本語版

・Kintex UltraScale+ FPGA データシート: DC 特性および AC スイッチ特性(DS922:英語版日本語版

・Virtex UltraScale FPGA データシート: DC 特性および AC スイッチ特性(DS893:英語版日本語版

・Kintex UltraScale FPGA データシート: DC 特性および AC スイッチ特性(DS892:英語版日本語版

・Zynq UltraScale+ MPSoC データシート: DC 特性および AC スイッチ特性(DS925:英語版日本語版

・Zynq UltraScale+ RFSoC データシート: DC 特性および AC スイッチ特性(DS926:英語版日本語版

下記はVirtex UltraScale+ の例です。DS923 を参照すると、最大動作速度の違いを確認できます。

mem_speed.PNG

 

 

 

Read more
3 0 909
Xilinx Employee
Xilinx Employee

本ブログは英語版のAXI-Basics Blogを翻訳したものです。

 

概要


ブログ記事 AXI 基礎 2 では、ザイリンクス Verification IP (AXI VIP) AXI プロトコル チェッカーとして使用可能であると紹介しました。このブログ記事では、AXI4 (Full) マスター インターフェイスで AXI VIP を使用して検証とエラー検出を実行する方法を紹介します。


AXI VIP
AXI4 プロトコル チェッカーとして使用 (チュートリアル)

  1. このブログに添付されているデザイン ファイルをダウンロードします。
  2. Vivado 2019.2 を起動します。
  3. [Tcl Console] ウィンドウで、cd コマンドを使用して (cd AXI_Basics_4)ZIP 解凍ディレクトリに移動します。
  4. [Tcl Console] ウィンドウで、source コマンド (source ./create_proj.tcl) を使用して、tcl スクリプトを実行します。

    これでマスター AXI4 インターフェイスを持つカスタム IP を含むブロック デザイン (BD) を使用した Vivado プロジェクトが作成されます。
    AXI4_1.png

     

    これで AXI VIP をカスタム IP のマスター インターフェイスに接続してインターフェイスを検証できます。
  5. BD を右クリックして [Add IP] をクリックし、AXI Verification IP (AXI VIP) を追加します。
  6. AXI VIP をダブルクリックして、IP 設定 GUI を開きます。
  7. インターフェイス モード ([INTERFACE MODE]) [SLAVE] に変更して [OK] をクリックします。

    AXI4_2.png

     

 

  1. AXI VIP の S_AXI 入力インターフェイスをカスタム IP m00_axi 出力インターフェイスに、AXI VIP aclk aresetn 入力ポートを BD の該当する入力ポートにそれぞれ接続します。
    AXI4_3.png

     

  2. [Address Editor] ウィンドウを開き、[Auto Assign Address] をクリックします。AXI VIP に自動的に割り当てられたアドレスが 0x44A0_0000 であることを確認します。このアドレス以外の場合は、手動でこのアドレスを割り当てます。

 

  1. BD を検証します。エラーやクリティカル警告メッセージは表示されないはずです。
  2. BD を保存します。
  3. [Tcl Console] ウィンドウに次のコマンドを入力し、AXI VIP インスタンスの完全コンポーネント名を検索します。

get_ips *vip*

 

完全名は、デフォルトで design_1_axi_vip_0_0 のはずです。

  1. [Sources] ウィンドウでテストベンチ ファイル AXI_tb をダブルクリックしてテキスト エディターで開きます。
    AXI4_4.png

     


    AXI_tb
    テストベンチ ファイルには、カスタム IP を実行するのに必要なコードが既に含まれています。AXI VIP には必要なコードを追加する必要があります。ブログ記事 AXI 基礎 3 同様、『AXI Verification IP 製品ガイド』の「Useful Coding Guidelines and Examples (便利なコーディングのガイドラインおよび例)(PG267、v1.1、2019 年 10 月 30 日、46 ページ) に従います。 

    まず、2 つの必要パッケージ axi_vip_pkg と <component_name>_pkg をインポートします。コンポーネント名は、手順 12 get_ips で返された値です。

 

  1. 58 に次の行を追加します。

 

//Import two required packages: axi_vip_pkg and <component_name>_pkg.

import axi_vip_pkg::*;

import design_1_axi_vip_0_0_pkg::*;


次に、VIP のエージェント タイプにスレーブを宣言します。

  1. 91 に次の行を追加します。

// Declare the agent

design_1_axi_vip_0_0_slv_mem_t slv_agent;

 

次にスレーブ エージェントを作成する必要があります。

  1. 96 に次の行を追加します。

//Create an agent

slv_agent = new("master vip agent",UUT.design_1_i.axi_vip_0.inst.IF);

 

  1. このチュートリアルでは、AXI VIP でエラーがコンソールに出力されるようにする必要があるので、次の行 ( 99 付近) で冗長モードをイネーブルにします。

// set print out verbosity level

slv_agent.set_verbosity(400);

 

  1. 最後に、次の行を使用してスレーブ エージェントを開始できます。

//Start the agent

slv_agent.start_slave();

 

  1. テスト ベンチ ファイルを保存して、シミュレーションを起動し、200 us 間実行します。
  2. [Tcl Console] ウィンドウでキーワード「Fatal」を検索します。次の行が見つかるはずです。

Fatal: AXI4_ERRM_AWADDR_BOUNDARY: A burst must not cross a 4kbyte boundary. Spec: section A3.4.1.

 

AXI4_5.png



このエラーは、A3.4.1 セクションを見ると理解できます。エラー メッセージにも含まれているように、AMBA® AXI™ および ACE™ プロトコル仕様は、Arm ウェブサイト (リンク) から入手可能です。

この仕様には、次の文が含まれています。

“A burst must not cross a 4KB address boundary. (バースト モードは 4 KB アドレスの境界をまたがないようにする必要があります。)

  1.  シミュレーションを閉じて、カスタム IP axi_master_0 をダブルクリックして、GUI を開きます。
    AXI4_6.png

     

    アドレス 0x44A00FC8 で開始する 16 個の 32 ビット ワードがバースト送信される設定になっていることがわかります。この場合、書き込みバーストがアドレス 0x44A00FC8 で開始してアドレス 0x44A01004 で終了します。4 KB の境界はアドレス 0x44A01000 (4K = 4*1024 = 4096 = 0x1000) のため、バーストがこの境界をまたいでしまうため、エラーが発生します。
  2. [00 Axi Target Slave Base Address] の値を 0x44A00000 に変更してから [OK] をクリックし、IP 設定 GUI を閉じます。BD を保存します。
  3. シミュレーションを 200 us 間実行します。
  4. キーワード「FATAL」を再び検索します。エラー メッセージが変更され、最初の問題が解決したことがわかります。
    次のメッセージが表示されます。

Fatal: AXI4_ERRM_WDATA_STABLE: WDATA must remain stable when WVALID is asserted and WREADY low. Spec: section A3.2.1.

 

  1. 波形ウィンドウで、m00_axi インターフェイスの書き込みデータ チャネルを展開します。tready 信号が low のときに wvalid が変化するのがわかります。これは、AXI の仕様に準拠していません。

    AXI4_7.png

     

 

  1. シミュレーションを閉じて、[Sources] ウィンドウでブロック デザインの AXI_Master_v1_0_M00_AXI.v ファイルを開きます。

    AXI4_8.png

     

 

  1. 506/518 付近で次の個所を変更します。この変更により tready 信号が low のときに wdata 信号が変化しなくなります。

/* Write Data Generator                                                           

 Data pattern is only a simple incrementing count from 0 for each burst  */       

  always @(posedge M_AXI_ACLK)                                                    

  begin                                                                           

    if (M_AXI_ARESETN == 0 || init_txn_pulse == 1'b1)                                                        

      axi_wdata <= 'b1;                                                           

    //else if (wnext && axi_wlast)                                                

    //  axi_wdata <= 'b0;                                                          

    else if (wnext)                                                               

      axi_wdata <= axi_wdata + 1;                                                 

    else                                                                           

      axi_wdata <= axi_wdata;                                                      

end 

 

  1. ファイルを保存します。[Refreshed Changed Modules] が表示されるので、これをクリックします。

    AXI4_9.png

     

 

  1. シミュレーションを 200 us 間実行します。

シミュレーションでエラーは発生しないはずです。波形ウィンドウを確認しても、16 個の書き込みバースト トランザクションと 16 個の読み込みバースト トランザクションが正しく発生していることが確認できます。これは、2 つ目の問題が修正されたことを意味します。

Read more
2 0 649
Xilinx Employee
Xilinx Employee

本ブログは英語版のAXI-Basics Blogを翻訳したものです。

 

概要

AXI の基礎に関する前のブログ記事の「AXI の基礎 1」では AXI4 の仕様について説明し、「AXI 基礎 2」では AXI Verification IP (AXI VIP) の概要を解説しました。

このブログ記事では、AXI4-Lite インターフェイスをシミュレーションするために AXI VIP Vivado プロジェクトに追加する方法をまず示します。次に、シミュレーション波形ウィンドウで AXI4-Lite トランザクションに使用する信号について説明します。

 

AXI4-Lite マスターとしての AXI VIP の使用 (チュートリアル)

  1. このブログ記事に添付されているデザイン ファイルをダウンロードします。
  2. Vivado 2019.2 を開きます。
  3. [Tcl Console] ウィンドウで、cd コマンド (cd AXI_Basics_3) を使用して解凍ディレクトリに移動します。
  4. [Tcl Console] ウィンドウで、source コマンド (source ./create_proj.tcl) を使用して tcl スクリプトを実行します。

    これにより、AXI GPIO IP を含むブロック デザインを使用する Vivado プロジェクトが作成されます。この AXI GPIO IP には、AXI4-Lite トランザクションを使用してオン/オフにするオンボード LED への接続をシミュレーションするチャネル 1 に接続された 1 つの出力、およびステートを読み出すオンボード スイッチへの接続をシミュレーションするチャネル 2 に接続された 1 つの入力があります。
    AXI3_1.png

     

 

  1. デザインに AXI Verification IP (AXI VIP) を追加します。
  2. AXI VIP をダブルクリックして設定 GUI を開き、次のパラメーターを変更します。
    1. [INTERFACE MODE]: MASTER
    2. [PROTOCOL] (MANUAL): AXI4LITE

      AXI3_2.png

       

 

  1. AXI VIP のマスター AXI4-Lite インターフェイス (M_AXI) AXI GPIO IP のスレーブ AXI4-Lite (S_AXI) に、AXI VIP aclk および aresetn ポートをブロック デザインの入力にそれぞれ接続します。

    AXI3_3.png

     

  2. [Address Editor] ウィンドウを開き ([Window] [Address Editor])[Auto Assign Address] アイコンをクリックします。
    AXI3_4.png

     

 

  1. アドレスが 0x4000_0000 に設定されていることを確認します。
    AXI3_5.png

     



    注記: AXI GPIO の S_AXI インターフェイスをチェックすると、9 アドレス ビットのみが AXI VIP に接続されているため、ここではアドレスの上位の部分は特に関係ありません。
  2. ブロック デザインを検証します。エラーまたはクリティカル警告メッセージは表示されないはずです。
    ブロック デザインを保存します。

    次に、AXI VIP を宣言および制御するために、テストベンチ ファイルをアップデートする必要があります。
    これを実行するには、『AXI Verification IP 製品ガイド』の「Useful Coding Guidelines and Examples (便利なコーディングのガイドラインおよび例)(PG267、v1.1、2019 年 10 月 30 日、46 ページ) に従います。
  3. [Sources] ウィンドウでテストベンチ ファイルの AXI_GPIO_tb.sv を開きます。
    AXI3_6.png

     



    このテストベンチ ファイルには、クロック、リセットなどの一部の信号の制御が既に含まれており、LED のステータスをコンソールに出力するためのプロセスがあります。

 

 always @(posedge led_1)

begin

     $display("led 1 ON");

end

always @(negedge led_1)

begin

     $display("led 1 OFF");

end


Useful Coding Guidelines and Examples (便利なコーディングのガイドラインおよび例)」の記述によると、最初のステップは SystemVerilog テストベンチでのモジュールの作成ですが、使用するテストベンチにモジュールが既に含まれています。

2
つ目のステップは、2 つの必須パッケージであるaxi_vip_pkg および <component_name>_pkg のインポートです。

注記: VIP インスタンスの <component_name> を見つけるには、次の Tcl コマンドを使用して AXI VIP インスタンスに対応する出力を検出します。
添付のテストベンチでは、AXI コンポーネント名が design_1_axi_vip_0_0 (BD に追加された最初の AXI VIP に対するデフォルト) であると想定されます。

get_ips *vip*

  1. 58 付近に次の行を追加します。

//Step 2 - Import two required packages: axi_vip_pkg and <component_name>_pkg.

import axi_vip_pkg::*;

import AXI_GPIO_Sim_axi_vip_0_0_pkg::*;

 

ステップ 3 は、マスター VIP タイプのエージェントの宣言です。

  1. 102 付近に次の行を追加します。

// Step 3 - Declare the agent for the master VIP

AXI_GPIO_Sim_axi_vip_0_0_mst_t      master_agent;

 

ステップ 4 および 5 は、新しいエージェントの作成と開始です。

  1. 107 付近に次の行を追加します。

 

// Step 4 - Create a new agent

master_agent = new("master vip agent",UUT.AXI_GPIO_Sim_i.axi_vip_0.inst.IF);

 

// Step 5 - Start the agent

master_agent.start_master();


これで、トランザクションの送信を開始する準備ができました。

AXI4-Lite
トランザクションの送信は非常に簡単です。書き込みトランザクションに対しては API AXI4LITE_WRITE_BURST(addr,prot,data,resp) を、読み出しトランザクションに対しては AXI4LITE_READ_BURST(addr,prot,data,resp) を使用するだけです。

注記: AXI VIP API はすべて、japan.xilinx.com こちらからダウンロードできる ZIP ファイル内で説明されています。

このチュートリアルでは、AXI GPIO チャネル 1 に接続されている LED_1 をトグルし、AXI GPIO チャネル 2 に接続されている SWITCH_1 のステートを読み出します。

AXI GPIO 製品ガイド』 (PG144) の表 2-4 AXI GPIO IP のレジスタ マップを確認すると、アドレス 0x0 で書き込み、アドレス 0x8 で読み出す必要があります。

AXI3_7.png



まず、書き込みから開始して、LED_1 のステートをトグルしてみます。

 

  1. 次のコードを追加して 0x1 AXI GPIO レジスタ 0x0 に書き込むと、LED がオンになるはずです。

//Send 0x1 to the AXI GPIO Data register 1

#500ns

addr = 0;

data = 1;

master_agent.AXI4LITE_WRITE_BURST(base_addr + addr,0,data,resp);

 

  1. 次のコードを追加して 0x0 AXI GPIO レジスタ 0x0 に書き込むと、LED がオフになるはずです。

//Send 0x0 to the AXI GPIO Data register 1

#200ns

addr = 0;

data = 0;

master_agent.AXI4LITE_WRITE_BURST(base_addr + addr,0,data,resp);


次に、スイッチの位置の各変更の後で読み出しを実行し、スイッチのステートをコンソールに表示します。

  1. 読み出しトランザクションに対応する次のコードを追加します。

// Switch in OFF position

switch_1 = 0;

// Read the AXI GPIO Data register 2

#200ns

addr = 8;

master_agent.AXI4LITE_READ_BURST(base_addr + addr,0,data,resp);

switch_state = data&1'h1;

if(switch_state == 0)

$display("switch 1 OFF");

else

$display("switch 1 ON");

    

// Switch in ON position

switch_1 = 1;

// Read the AXI GPIO Data register 2

#200ns

addr = 8;

master_agent.AXI4LITE_READ_BURST(base_addr + addr,0,data,resp);

switch_state = data&1'h1;

if(switch_state == 0)

    $display("switch 1 OFF");

else

$display("switch 1 ON");

 

 

  1. シミュレーションを起動して 3 us 間実行します。[Tcl Console] ウィンドウに、LED のトグルおよびスイッチのステートが表示されるはずです。
    AXI3_8.png

     



    これで、AXI4-Lite インターフェイスのトランザクションを解析できます。
  2. [Scope] ウィンドウで、[AXI_GPIO_tb] [UUT] [AXI_GPIO_Sim_i] の下にある [axi_vip_0] を選択します。
    AXI3_9.png

     

 

  1. [Objects] ウィンドウで、[M_AXI] (プロトコル インスタンス) を右クリックして [Add to Wave Window] をクリックします。
    AXI3_10.png

     

  2. シミュレーションを再開して 3 us 間実行します。

    AXI4-Lite
    インターフェイスには、書き込みトランザクション 2 つの後に読み出しトランザクションが 2 つ、合計 4 つのトランザクションが表示されます。

    AXI3_11.png

  3. [M_AXI] を展開し、その他のチャネルを表示します。

    これで、書き込みトランザクションの異なるステップを確認できます。
    まず、書き込みアドレス チャネル (AWREADY および AWVALID) READY および VALID 信号の両方が High の場合、アドレスがマスターからスレーブに送信されます。

    AXI3_12.png

     


    次に、書き込みチャネル (WREADY および WVALID) READY および VALID 信号の両方が High の場合、データがマスターからスレーブに送信されます。

    注記: バーストは AXI4-Lite インターフェイスでサポートされていないため、アドレスごとに 1 つのデータのみが送信されます。
    AXI3_13.png

     



    最後に、書き込み応答チャネルで書き込み応答がスレーブにより送信されると (書き込みが成功したかどうかを通知するため)、書き込みトランザクションが完了します。書き込み応答チャネル (BREADY および BVALID) READY および VALID 信号の両方が High の場合、応答がスレーブからマスターに送信されます。
    AXI3_14.png

     


    読み出しトランザクションに対しても同じ解析を実行できます。
    読み出し応答チャネル (ARREADY および ARVALID) READY および VALID 信号の両方が High の場合、データがマスターからスレーブに送信されます。

AXI3_15.png


次に、読み出しチャネル (RREADY および RVALID) READY および VALID 信号の両方が High の場合、データがスレーブからマスターに送信されます。

AXI3_16.png

 

 

注記: 読み出しトランザクション中、読み出しが成功したかどうかを示す応答もスレーブによって送信されます。

この応答は、データと同時に読み出しチャネルで送信されます。

 

Read more
3 0 1,122
Xilinx Employee
Xilinx Employee

本ブログは英語版のAXI-Basics Blogを翻訳したものです。

 

概要:

近年、ほぼすべてのザイリンクス IP AXI インターフェイスを使用するようになりました。Zynq®、Zynq MPMicroBlaze™ および新しい Versal™ プロセッサなど、すべてが AXI インターフェイスを使用しています。このため、ザイリンクス デバイスのほぼすべての新規デザインに AXI インターフェイスが組み込まれています。AXI の基礎を理解しておくと、ザイリンクス デバイスでデザインを設計およびデバッグするのに役立ちます。

このブログ記事では、ザイリンクス デバイスでの AXI3/AXI4 の基礎についていくつか説明します。まず、理論および用語から説明します。

 

AXI とは:

AXI は、Advanced eXtensible Interface の略で、AMBA (Advanced Microcontroller Bus Architecture) 規格の一部として ARM により定義されたインターフェイス プロトコルです。

AXI3/AXI4 の仕様は、ARM ウェブサイト (リンク) から自由に入手可能なので、興味がおありの場合はダウンロードしてください。

AXI1.png

AXI4 インターフェイス (AMBA 4.0) には、次の 3 つのタイプがあります。

  • AXI4 (フル AXI4): パフォーマンスに優れたメモリ マップド要件用です。
  • AXI4-Lite: 単純なスループットの少ないメモリ マップド通信用です (たとえば、制御およびステータス レジスタの通信など)
  • AXI4-Stream: 高速のストリーミング データ用です。
    • 注記: AXI4-Stream については、この記事では説明しません。この記事の「AXI」とは、AXI3AXI4、および AXI4-Lite のことを意味します。

注記: AXI3 インターフェイスはフル AXI インターフェイスに近いものです。

AXI の読み出しおよび書き込みチャネル

AXI プロトコルでは、5 つのチャネルが定義されます。

  • 2 つは読み出しトランザクションに使用されます。
    • 読み出しアドレス
    • 読み出しデータ
  • 3 つは書き込みトランザクションに使用されます。
    • 書き込みアドレス
    • 書き込みデータ
    • 書き込み応答

AXI2.png

 

チャネルは、VALID および READY 信号に関連付けられた AXI 信号の独立したコレクションです。

注記: AXI4/AXI3/AXI4-Lite インターフェイスは読み出し専用 (2 つの読み出しチャネルのみを含む) または書き込み専用 (3 つの書き込みチャネルのみを含む) にできます。

1 つの信号チャネルで送信されるデータを転送と呼びます。転送は、VALID および READY 信号の両方が High の場合に、クロックの立ち上がりエッジで発生します。たとえば、次の図の場合、転送は T3 で発生します。

AXI3.png

 

AXI 読み出しトランザクション

AXI 読み出しトランザクションは、2 つの読み出しチャネルで複数の転送を必要とします。

  • まず、アドレス読み出しチャネルがマスターからスレーブに送信されて、アドレスと一部の制御信号が設定されます。
  • このアドレスのデータが読み出しデータチャネルでスレーブからマスターに送信されます。

次の図に示すように、アドレスごとに複数のデータ転送が発生することもあります。このようなトランザクション タイプは、バーストと呼ばれます。

AXI4.jpg

 

AXI 書き込みトランザクション

AXI 書き込みトランザクションは、3 つの読み出しチャネルで複数の転送を必要とします。

  • まず、アドレス書き込みチャネルがマスターからスレーブに送信されて、アドレスと一部の制御信号が設定されます。
  • このアドレスのデータが書き込みデータチャネルでマスターからスレーブに送信されます。
  • 最後に、書き込み応答が書き込み応答チャネルでスレーブからマスターに送信され、転送が問題なかったかどうかが示されます。

 

AXI5.jpg

書き込み応答チャネルの応答値は、次のいずれかになります。

  • OKAY (0b00): 通常アクセスに問題なし。通常アクセスに問題がなかったことを示します。
  • EXOKAY (0b01): 排他的アクセスに問題なし。
  • SLVERR (0b10): スレーブ エラー。スレーブには問題なく到達しましたが、スレーブが送信元のマスターにエラー状況 (たとえば、データ読み出しが有効ではないなど) を戻していることを示します。
  • DECERR (0b11): デコード エラー。通常はインターコネクト コンポーネントにより生成され、トランザクション アドレスにスレーブがないことを示します。

注記: 読み出しトランザクションにも応答値はありますが、この応答は読み出し応答チャネルの一部として送信されます。

AXI4 インターフェイス要件

AXI4 インターフェイスの要件は、AXI4 仕様に記述されています。

中でも次の要件は、必ず覚えておく必要があります。

  • VALID (AxVALID/xVALID) 信号がアサートされる場合、スレーブが AxREADY/xREADY をアサートしてからクロック エッジが立ち上がるまでアサートされたままにしておく必要があります。

  • 情報を送信する AXI インターフェイスの VALID 信号は、その情報を受信する AXI インターフェイスの READY 信号に依存しないようにします。
    • ただし、READY 信号のステートは VALID 信号に依存できます。

  • 書き込み応答は、常に書き込みトランザクションの最後の書き込み転送の後に続く必要があります。

  • 読み出しデータは、常にそのデータの関連するアドレスの後に続く必要があります。

  • スレーブは、有効なデータが使用可能になったことを示す RVALID のがアサートされる前に、ARVALID ARREADY の両方がアサートされるまで待機する必要があります。

 

AXI の基礎シリーズ」の次の記事では、AXI Verification IP (AXI VIP) を使用して AXI4 インターフェイスをシミュレーションします。

Read more
2 0 511
Xilinx Employee
Xilinx Employee

本ブログは英語版のAXI-Basics Blogを翻訳したものです。

 

AXI Verification IP (AXI VIP) の概要:

ザイリンクス AXI Verification IP (AXI VIP) は、AXI4 および AXI4-Lite をシミュレーションするための IP です。AXI プロトコル チェッカーとしても使用できます。

この IP はシミュレーション用なので合成されず、パススルー コンフィギュレーション ワイヤに置き換えられます。

AXI VIP コアは、次の目的で使用できます。

  • マスター AXI コマンドおよび書き込みペイロードの生成
  • スレーブ AXI 読み込みペイロードおよび書き込み応答の生成
  • AXI トランザクションのプロトコル準拠チェック

次の 5 つの構成がサポートされます。

  • AXI マスター VIP
  • メモリ モデルなしの AXI パススルー VIP
  • メモリ モデルを含む AXI パススルー VIP
  • メモリ モデルなしの AXI スレーブ VIP
  • メモリ モデルを含む AXI スレーブ VIP

AXI VIP コアの詳細は『AXI Verification IP 製品ガイド』 (PG267: 英語版日本語版)、VIP API の詳細はこのリンクからダウンロード可能な ZIP ファイルに含まれる資料を参照してください。

AXI4 VIP のサンプル デザイン

AXI VIP のサンプル デザインが Vivado に含まれています。

AXI VIP のサンプル デザインを生成するには、次の手順に従います。

  1. 新規プロジェクトを開き、[IP Catalog] をクリックします。
  2. AXI Verification IP を検索します。IP をダブルクリックし、IP を設定して生成します。
  3. IP を右クリックし、[Open IP Example Design] をクリックします。

 

AXI VIP のサンプル デザインには 3 つの AXI VIP が含まれており、それぞれマスター、パススルー、およびスレーブとして設定されています。

AXI2_1.png

 

プロジェクトには、AXI VIP を異なる組み合わせで使用する複数のテストベンチが含まれています。

AXI2_2.png

 

注記: すべてのテストベンチ ファイルは SystemVerilog で記述されています。AXI VIP のすべての機能を活用するには、この IP SystemVerilog テストベンチに含める必要があります。

 

AXI インターフェイス トランザクションの解析:

Vivado シミュレーションの便利な機能に、プロトコル インスタンスがあります。これを波形に追加すると、信号をトランザクション レベルで表示できます。

ここでは、sim_basic_mst_active_pt_mem__slv_passive シミュレーション セットを使用する手順を示します。

このシミュレーション セットを使用するには、[Sources] ウィンドウでシミュレーション セットを右クリックし、[Make Active] をクリックします。

AXI2_3.png

 

このシミュレーション セットでは、マスター AXI VIP とパススルー AXI VIP (メモリ レベルでスレーブとして動作) のみが使用されます。

シミュレーションを実行するには、Flow Navigator [Run Simulation] をクリックします。

デフォルトでクロック信号とリセット信号のみを含む波形が開きます。

AXI2_4.png

次に、マスター AXI VIP とパススルー AXI VIP の間に AXI インターフェイスを追加します。

[Scope] ウィンドウで [DUT]   [ex_design] の下にあるマスター AXI VIP (axi_vip_mst) を選択します。[Objects] ウィンドウに IP のすべてのポートが表示されます。M_AXI インターフェイス オブジェクトを右クリックし、[Add to Wave Window] をクリックします。

AXI2_5.png

 

波形ウィンドウに AXI トランザクションが表示されます。

AXI2_6.png

 

シミュレーションの開始からシミュレーション時間 1 us までの間に、読み出しトランザクションと書き込みトランザクションの両方が発生しています。

波形ウィンドウで M_AXI を展開表示すると、これらのトランザクションの詳細が表示されます。

AXI2_7.png

チャネル上の数値はトランザクション番号です。読み出しチャネル (紫) では 5 つのトランザクションが発生し、書き込みチャネルでは 4 つのトランザクションが発生しています。

特定のトランザクションをクリックすると、トランザクションがどのように発生したのかがわかります。たとえば、書き込みチャネルの最初のトランザクションをクリックすると、これがバースト トランザクションであることがわかります。

  1. トランザクションは、書き込みアドレス チャネルでアドレスが設定されて開始します。
  2. その後、データのバーストが書き込みデータ チャネルで送信されます。
  3. 書き込みが成功すると、書き込み応答チャネルでスレーブからの応答が送信されます。

AXI2_8.png

 

 

Read more
2 0 15K