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

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

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

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
1 0 223
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
2 0 193
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
1 0 180
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
4 0 509
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 514
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 549
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 234
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 146
Xilinx Employee
Xilinx Employee

概要

Zynq MPSoC デバイスのイーサネット アプリケーションを実行する際に、PL ロジックを使用するのではなく PS の Ethernet MAC (GEM) コアを使用することを考慮している場合は、このブログに示されるガイダンスおよびデバッグに関するヒントを参考にしてください。 

尚、本ブログは、Debugging Tips when using GEM on Zynq MPSoC devicesを翻訳したものです。

 

基本

GEM モジュールは、IEEE 802.3 規格と互換性のある 10/100/1000 Mb/s イーサネット MAC をインプリメントしています。

半二重または全二重モードでの動作が可能です。速度、二重モード、およびインターフェイスのタイプ (MII、GMII、RGMII、TBI、または SGMII) は、ネットワーク コンフィギュレーション レジスタを使用して選択します。

GEM は通常、専用のハードワイヤ接続された DMA ブロックと共に使用されます。DMA の動作が不要なシステム アプリケーションでは、外部 FIFO インターフェイスを使用して GEM を SoC 環境に組み込むことができます。

GEM ブロックには、次の信号インターフェイスが含まれます。

  • 外部 PHY への GMII、MII、および TBI インターフェイス
  • 外部 PHY 管理用の MDIO インターフェイス
  • GEM レジスタ アクセス用の APB (AMBA Advanced Peripheral Bus) スレーブ インターフェイス
  • メモリ アクセス用の AHB (AMBA Advanced High Speed Bus) または AXI4 マスター インターフェイス
  • DMA の機能が不要なアプリケーションでのオプションの FIFO インターフェイス
  • オプションのタイムスタンプ インターフェイス

 

AMBA インターフェイスは、Arm AMBA リビジョン 2.0 仕様に完全に準拠しています。

 

f01.png

図1:GEM信号インターフェース

 

次に、スタンドアロンおよび Linux ドライバーでサポートされるものを示します。

 

表1:ZynqMP GEM ベアメタルおよび Linux ドライバー サポート

 EMACPSlwIPMACB
RGMII (MIO)
PS-GTR SGMII×
PS-GTR 1000BASE-X×
PL SGMII
PL 1000BASE-X
PL GMII2RGMIIN/A×
PL MII2RMII×××

 

サンプル デザイン

ザイリンクスでは、ZCU102 評価ボードで実行するためのリファレンス デザインを提供しています。

『PS および PL ベースの 1G/10G イーサネット ソリューション』 (XAPP1305) には、Linux の例が含まれています。DTS の例および Linux でのビルド手順は、次のページを参照してください。

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841830/PS+and+PL+based+Ethernet+in+Zynq+MPSoC

また、次の Wiki ページに固定リンクの例が示されています。

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842230/Zynq+Ultrascale+Fixed+Link+PS+Ethernet+Demo

上記のリファレンス デザインを開始点として使用することを強くお勧めします。

 

デバッグに関するヒント

次のセクションに、GEM コンフィギュレーションの異なるイーサネット モード別にデバッグに関するヒントを示します。

 

RGMII (MIO) および GMII (EMIO)

ZCU102 GEM3 は、オンボード TI PHY とハードワイヤ接続されています。SDK lwIP echo アプリケーションをそのまま使用して、このインターフェイスをテストできます。Linux では、ご使用のツール バージョンで提供されている BSP を使用して、PetaLinux でデザインをビルドすることをお勧めします。

 

  • RGMII の電圧サポート

Zynq-7000 デバイスとは異なり、1.8V、2.5V、および 3.3V の電圧がすべてサポートされます。

『Zynq UltraScale+ MPSoC データシート: DC 特性および AC スイッチ特性』 (DS925) の表 44 に、2.5V テスト条件でのスイッチング特性が示されています。

 

f02.png

図2:RGMII インターフェイス

 

この表はワースト ケースの状況のみを示しているので、これより高速の 3.3V を使用する場合でも参考にできます。

 

  • デバイス ツリー

PHY のバインドについては、次を参照してください。

https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/net/macb.txt

 

compatible 文字列 cdns,zynqmp-gem は、ZynqMP 用です。

この文字列は、ジャンボ フレーム サイズ 1588 の使用、ハードウェア タイムスタンプ サポート、および ZynqMP 特定の機能をイネーブルにします。

 

phy-mode 文字列については、次のページを参照してください。

https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml

次に DTS の例を示します。

 

 

 

 

 

gem0: ethernet@e000b000 { 
 compatible = "cdns,gem";
 reg = <0xe000b000 0x1000>;
 status = "disabled";
 interrupt-parent = <&gic>;
 interrupts = <0 22 4>;
 clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
 clock-names = "pclk", "hclk", "tx_clk";
 #address-cells = <1>;
 #size-cells = <0>;
 phy-handle = <&ethernet_phy>;
 phy-mode = "rgmii-id";
 ethernet_phy: ethernet-phy@7{
  reg = <7>;
 };
}

 

 

 

 

 

 

  • 共有 MDIO

デザインで共有 MDIO バスを使用する必要がある場合は、(ザイリンクス アンサー 69132) に説明されているように、パッチが必要です。

共有 MDIO のサポートは、2019.1 リリースから追加されています。

 

GEM PS-GTR SGMII

PS-GTR を SGMII と共に使用する場合のよく寄せられる質問 (FAQ) は、(ザイリンクス アンサー 66592) を参照してください。

 

  • PS-GTR SGMII のデバッグ

PS-GTR SGMII が機能しない場合のデバッグ手順では、通常まず関連のレジスタ ダンプを確認し、その後ループバックを実行します。

次のレジスタ ダンプを確認すると、問題を特定するのに役立ちます。

 

0xFD401994 GT 内部レジスタ

0xFD405994 GT 内部レジスタ

0xFD409994 GT 内部レジスタ

0xFD40D994 GT 内部レジスタ (注記: これら 4 つのレジスタは、0x7 に設定する必要あり)

0xFF0B0000 network_control

0xFF0B0004 network_config

0xFF0B0008 network_status

0xFF0B0200 pcs_control

0xFF0B0204 pcs_status

0xFF180360 GEM_CTRL

0xFF180308 GEM_CLK_CTRL (IOU_SLCR)

0xFF0B0198 rx_symbol_error

0xFF0B0158 frames_rxed_ok

0xFF0B0190 fcs_errors

0xFD410000 PLL_REF_SEL0

0xFD402860 L0_L0_REF_CLK_SEL

0xFD410010 ICM_CFG0

0xFD410040 TX_PROT_BUS_WIDTH

0xFD410044 RX_PROT_BUS_WIDTH

0xFD40106C L0_TM_DIG_6

0xFD4023E4 L0_PLL_STATUS_READ_1

 

レジスタの詳細は、『Zynq UltraScale+ MPSoC レジスタ リファレンス』 (UG1087) を参照してください。

https://japan.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html

レジスタに問題がないことが確認されたら、次に PCS ループバックおよび PS-GTR ループバックを実行し、ループバックが機能するかを確認します。

PCS ループバックをイネーブルにするには、pcs_control レジスタの pcs_control[loopback_mode] ビット [14] をセットします。

PCS ループバックは、クロックが存在する間のみ実行します。依存性はありません。

PCS ループバックが機能する場合は、問題はオート ネゴシエーションに関連している可能性があります。

PCS ループバックの実行では、それ自体とオート ネゴシエーションします。オート ネゴシエーションをディスエーブルにするには、pcs_control[enable_auto_neg] ビット [12] を 0 にします。

上記の PCS ループバックが機能する場合は、SGMII PHY の前に PS-GTR ループバックを実行します。

これは、PS_GTR トランシーバー内で実行します。

PS-GTR ループバック レジスタは内部レジスタです。

このレジスタの詳細は次のとおりです。PS-GTR ループバックをイネーブルにする前に、PCS ループバックをディスエーブルにする必要があります。

 

f03.png

図3:LPBK_CTRL0 レジスタ (内部)

 

f04.png

図4:LPBK_CTRL1 レジスタ (内部)

 

たとえば、lane3 ループバックをイネーブルにするには、0xFD41003C を 0x00000010 に書き込みます。

これが機能しない場合は、問題は GTR 自体に関連している可能性があります。ザイリンクス サービス ポータルからサポートを受けることができます。GT 担当者がトランシーバーのオープン アイの計測方法を指導し、GT 側の問題を調べます。

これが機能する場合は、GEM および PS-GTR に問題はなく、PHY 側の問題である可能性があります。PHY/SFP が正しく機能しており、ケーブルに問題がないことを確認する必要があります。

PS-GTR を GEM と共に使用する場合は、GT レーンの極性も確認する必要があります。TX と RX が反転している場合、レシーバー側で RX パケットが受信されない可能性があります。

極性を反転する TX および RX レジスタは、次のとおりです。

 

f05.png

図5:PS-GTR TX 極性の制御

 

f06.png

図6:PS-GTR RX 極性の制御

 

  • デバイス ツリー

DTS の例は、(ザイリンクス アンサー 66592) に示されています。

 

  • 固定リンク

PHY を使用せずに SGMII を SGMII に直接接続する場合 (固定リンク) は、(ザイリンクス アンサー 69769) のパッチが必要です。

 

GEM PS-GTR 1000BASE-X

1000BASE-SX/LX で PS-GTR を使用する場合、レジスタの設定、1000BaseX または SGMII の MAC のデザインには変更はありません。

設定は同じです。

外部 PHY は、必要なモード用に設定する必要があります。1000BaseX モードでは、1G の固定速度のみを使用可能です。

 

その他の問題

次に、発生する可能性のあるさまざまな問題をリストします。

 

U-Boot サポート

次の Wiki ページに、イーサネットに関連する U-Boot のサポートについて説明されています。

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842124/U-Boot+Ethernet+Driver

U-Boot では、ethact コマンドを使用して必要なイーサネット インターフェイスを選択できます。

U-Boot でのデュアル イーサネットの使用には制限はありません。たとえば、eth0 をアクティブにするには、setenv ethact eth0 を使用します。

次に、Marvell PHY で PS-GTR SGMI モードを使用する場合のデバイス ツリーの例を示します。

 

 

 

 

 

ethernet@ff0c0000 {
 phy-handle = <&phy0>;
 is-internal-pcspma;
 phy0: phy@1 {
  compatible = "marvell, 88E1518";
  device-type = "ethernet-phy";
  reg = <1>;
 };
};

 

 

 

 

 

 

  • 固定リンク

次のページに、U-Boot で固定リンクをテストおよび使用する例が示されています。

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841998/Testing+Fixed+Link+support+in+U-Boot

2017.2 以前のバージョンでは、U-Boot で固定リンクを使用するにはパッチが必要です。(ザイリンクス アンサー 69768) を参照してください。

 

GEM 外部 FIFO インターフェイス

DMA の動作が不要なシステム アプリケーションでは、送信および受信データパスの両方に外部 FIFO インターフェイスを使用できます。

このインターフェイスをイネーブルにするには、external_fifo_interface レジスタのビット [0] を 1 に設定します。

外部 FIFO インターフェイスの使用に関してよく寄せられる質問 (FAQ) は、(ザイリンクス アンサー 69490) を参照してください。

PCW コンフィギュレーション GUI で次の図に示すオプションを選択すると、GEM 外部 FIFO インターフェイスをイネーブルにできます。

 

f07.png

図7:PCW の外部 FIFO インターフェイスのイネーブル

 

f08.png

図8:使用可能な FIFO インターフェイス

 

『Zynq UltraScale+ MPSoC テクニカル リファレンス マニュアル』 (UG1085) に、このインターフェイスの機能が詳細に説明されています。

注記: 外部 FIFO インターフェイスを使用する場合、ドライバー サポートはありません。

 

GEM TSU および IEEE 1588 サポート

(ザイリンクス アンサー 67239) に添付されている資料『GEM TSU インターフェイスおよび IEEE 1588 サポート』を参照してください。

 

GEM のパフォーマンス制限

GEM には TX/RX FIFO のオーバーフローを検出するフロー制御ハードウェア ロジックがないので、大量の双方向トラフィックがあると、FIFO がオーバーフローする確率が高くなり、パケットが欠落することがあります。

 

詳細は、(ザイリンクス アンサー 71168) を参照してください。

次に、パフォーマンスをテストする手順を示します。

前提条件: Linux ホストおよび PetaLinux イメージの両方に iperf3 バイナリがあることを確認してください。

また、ホストおよびターゲットの両方で基本的な ping 機能が動作することを確認してください。

Zynq MP ボードと Linux PC の間で次の双方向 iperf3 コマンドを実行し、パフォーマンスを計測します。

 

  • ボード側

iperf3 -A1 –s

iperf3 -c <host_ip> -t 999

 

  • PC 側

iperf3 –s &

iperf3 -c <board_ip> -t 999

 

追加情報

(ザイリンクス アンサー 71349) に、Zynq UltraScale+ GEM の既知の問題がリストされています。

次のザイリンクス Wiki にパフォーマンス値が示されています。

 

  • XAPP1306

2017.1 – https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842391/Ethernet+performance+for+LVIP+on+zynqmp+with+2016.4

  • XAPP1305

2017.3 – https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841752/ZynqMP+Ethernet+Performance+2017.3

2017.1 – https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842533/Zynq+mp+Ethernet+Performance+2017.1

 

Zynq-7000 の GEM

次の表に、Zynq-7000 デバイス上の GEM のスタンドアロンおよび Linux ドライバーでサポートされるものを示します。

 

表 2: Zynq GEM ベアメタルおよび Linux ドライバー サポート

 EMACPSlwIPMACB
RGMII (MIO)
PL SGMII
PL 1000BASE-X
PL GMII2RGMII
PL MII2RMII×××

 

Zynq の GEM に関する質問の多くは、エラッタに関連しています。エラッタの内容は、『Zynq-7000 SoC テクニカル リファレンス マニュアル』 (UG585) の既知の問題として、および (ザイリンクス アンサー 52028) に記載されています。


Zynq の GEM には、ハードウェアの制限により、PTP サポートはありません。

Zynq GEM には TSU が含まれており、これを使用して入力および出力 PTP イベントを検出し、内部 PTP タイマーでタイムスタンプを付けることができます。

タイマー レジスタとタイムスタンプにはレジスタを介してアクセスでき、PL へのパスはありません。

タイムスタンプの FIFO キューは 1 つのみで、深さは 1 です。値が失われないように、各フレームとタイムスタンプをすばやく一致させる必要があります。

PPS 信号はありません。

 

また、2 つの GEM には個別に PTP タイマーがあり、同じ参照タイマーを使用することはできません。

サードパーティ ソリューションを使用したり、独自のタイマーを設計して精度を上げることはできますが、ザイリンクスがサポートするソリューションはありません。

(ザイリンクス アンサー 71352) に、Zynq-7000 デバイスの GEM の既知の問題およびリリース ノートが記載されています。

 

 

more
7 0 371
Xilinx Employee
Xilinx Employee

概要

 

このブログでは、Zynq-7000 および Zynq MPSoC デバイスで、 PL 部からPS 部への割り込みを使用する場合に確認する必要がある、属性設定用のレジスタを紹介します。割り込みプログラムを作成する際の、ご参考になれば幸いです。本ブログは、株式会社 PALTEK 瀧澤様が作成されたブログです。

 

1. Zynq-7000 デバイスの場合


Cortex-A9 コアは、nIRQとnFIQの 2 つの割り込みポートを持っています。

PL から、この割り込みポートに接続するためには、CoreX_nFIQ ポートか CoreX_nIRQ ポート、またはは IRQF2P ポートを使用します。

優先度の高い割り込みについては、一般的に CoreX_nFIQ ポートや CoreX_nIRQ ポートを使用します。

 

1.png

 

1.1 センシティビティの設定


1.1.1 CoreX_nFIQ、CoreX_nIRQ の場合


CoreX_nFIQ、CoreX_nIRQ は PPI (プライベートペリフェラル割り込み) なので、センシティビティを変更することはできません。

 

1.png

 

1.1.2 IRQF2P の場合


IRQF2P は、立ち上がりエッジ か High レベルを選択できます。

尚、Rising edge をGIC(汎用割り込みコントローラー)が認識するためには、クロック「CPU_2x3x」の、2 サイクル以上のパルス幅が必要です。

 

2.png

 

次に、関連する設定レジスタをに示します。

詳細は、『Zynq-7000 デバイス テクニカルリファレンスマニュアル』(UG585 日本語版 英語版)を参照してください。

 

IRQF2P [7:0](IRQ ID# = 68:61)の設定レジスタ


ICDICFR3 レジスタ(アドレス0xF8F01C0C)

 

3.png

 

ICDICFR4 レジスタ(アドレス0xF8F01C10

 

4.png

 

IRQF2P[15:8](IRQ #ID = 91:84)の設定レジスタ


ICDICFR5レジスタ(アドレス0xF8F01C14)

 

 

111.png

 

1.2 ターゲット CPU の設定


IRQF2P は、割り込みの入力先を、CPU#0 かCPU#1 の片方または両方に設定できます。

割り込み ID と設定レジスタの関係は、次のように定義されています。

 

6.png

 

2. Zynq MPSoC デバイスの場合


PL から PS への割り込み信号には、SPI(共有ペリフェラル割り込み)と SPI 以外の FIQ/IRQ が用意されています。

SPI(pl_ps_irq0, pl_ps_irq1)は、ほかのペリフェラルからの割り込みと同様の手続きで処理できます。

割り込み ID が各ビットに割り当てられており、その割り込み ID は、APU と RPU から、同じ ID 番号で扱うことができます。

 

例)pl_ps_irq0[0] の割り込み信号は、APU、RPU 共に ID=121 として扱います。

 

優先度の高い割り込みについては、一般的に FIQ/IRQ を使用します。

 

7.png

 

2.1 割り込み ID の割り当てについて

 

割り込みIDは、次のように割り当てられています。

 

8.png

 

詳細は、『Zynq UltraScale+ デバイス テクニカル リファレンス マニュアル』(UG1085 日本語版 英語版 )を参照してください。

 

9.png

 

10.png

 

 

2.2 センシティビティの設定

 

2.2.1 FIQ/IRQ の場合

 

pl_ps_apugic_fiq、pl_ps_apugic_irq、nfiq0_lpd_rpu、nirq0_lpd_rpu、nfiq1_lpd_rpu、およびnirq1_lpd_rpu は、

「CPU プライベートペリフェラル割り込み」であり、センシティビティを変更することはできません。

PLから入力する際の極性は、アクティブ High です。


2.2.2 pl_ps_irq0/1の場合

 

Active High または Rising Edge の選択ができます。

尚、Rising Edge の場合、LSBUS クロックの 2 サイクル以上のパルス幅が必要です。

設定用レジスタは、GICD_ICFGR[0:11] (GIC400) です。

レジスタの詳細については、Arm 社の仕様書を参照してください。

 

Capture.PNG

 

2.3 ターゲット CPU の設定


pl_ps_irq0/1 は、SPI(共有ペリフェラル割り込み)なので、ターゲット CPU を指定できます。


2.3.1 APU(GIC-400)の場合


GICD_ITARGETSR レジスタで設定します。1つの ID に 8 ビットが割り当てられています。

レジスタの詳細については、Arm社の仕様書を参照してください。

 

a.png

 

 

 

b.png

 

 

2.3.2 RPU(PL-390) の場合


enable_targets_spi_INTID レジスタで設定します。RPU (PL-390) の場合、1 つの ID に8 ビットが割り当てられています。

 

222.PNG

 

まとめ

 

このブログでは、PL から PS への割り込みを使用するときに設定が必要な、関連するレジスタを紹介しました。

 


参照資料

 

Zynq Ultrascale+ デバイス テクニカル リファレンス マニュアル 日本語版 英語版

Zynq-7000 デバイス テクニカル リファレンス マニュアル 日本語版 英語版

ARM Generic Interrupt Controller Architecture version 2.0 Architecture Specification

more
4 0 418
Xilinx Employee
Xilinx Employee

概要:

本ブログは、Memory Interface Generator(MIG) を実装するための PCB 設計のガイドラインについて説明します。具体的には、PCB 基板設計において注意すべき事項を中心に説明します。PCB 基板完成後のサンプルデザインの実装は、次回以降のブログで紹介します。

 

 

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

評価、設計の段階に応じて行うべき開発手順をわけることができます。この記事では PCB ガイドラインについて説明します。1_flow.PNG

 

 

PCB ガイドライン:

MIG の PCB ガイドラインは、UltraScale アーキテクチャ PCB デザイン(UG583 : 英語版日本語版) に記載されています。UG583に記載されている内容は、厳密に満たすように設計してください。

  • 第 1 章は、UltraScale デバイスの電源について説明しています。デカップリング キャパシタの選択、推奨個数とPCB 形状の推奨を説明しています。
  • 第 2 章は、メモリ インターフェイスの PCBガ イドラインについて説明しています。
    • (1)電気的な配線の制約や信号スキューは、表2-1に示す基準スタックアップをもとに計算されています。異なるスタックアップを使用される場合は、お客様で層の高さ、間隔、誘導材料を調整して、適切なインピーダンスおよび伝搬遅延を計算するようにしてください。2_stackup.PNG
    • (2)メモリの一般的な配線ガイドラインには、23 項目の説明があります。必ずこれらの項目を満たすように設計をしてください。下図は項目1、 2 と3 を示しています。3_guide.PNG

    • (3)メモリの配線には、フライバイ トポロジとクラムシェル トポロジの 2 種類があります。フライバイ トポロジは、メモリ デバイスが一つの層に配置されている構成です。フライバイ トポロジにおいて、基板の制約によってメモリ デバイスをトップ層とボトム層の両方に配置する必要がある場合は、SIの観点から適切なグランド ビアを確保するようにしてください。またIBISシミュレーションも実施するように検討してください。4_fly.PNG

    • (4)図 2-1 と図 2-2 に信号配線の重要事項が記載されています。必ず確認してください。5_top_layer.PNG
  • 付録 A は、メモリのディレーティング表を示しています。スキューの数値は、FPGA の速度定格、メモリ コンポーネントの定格、およびシステムの動作速度によって決定されます。動作速度によってスキュー数値を緩和することが可能です。6_derating.PNG

 

  • メモリ インターフェイスのデバッグ テクニック1 に記載しているように、チェックリスト (XTP359) があります。ご活用ください。7_debug.PNG
  •  PCB の設計において、メモリ インターフェイスの信号品質をプローブで確認できるように次を検討してください。
    1. 信号スキューを確認するために、メモリ クロック、リード ストローブ、ライト ストローブの信号すべてを測定できるようにする。
    2. 各データ バイトの中で1 ビット は、信号品質確認のため観測できるようにする。
    3. MIG のキャリブレーションのデータ (キャリブレーション結果、経過データ、ウィンドウ マージン) は XSDB に保存されます。XSDB は JTAG を経由して読み出しますので、必ず JTAG を接続してください。
    4. FPGA とメモリ デバイスの電源とグラウンドを測定できるようにする。

8_signals.PNG

 

 

消費電力と熱:

  • MIGは、高レート、高ビット幅であり、双方向バスの入力終端であるため、消費電力が大きくなる傾向にあります。
  • Xilinx Power Estimator (XPE) を使用することにより、事前に消費電力を見積もることができます。MIG IP 単体の消費電力は含まれないため、次に示 MIG IP 単体の消費電力を加算してください。

http://www.xilinx.com/products/technology/power/xpe.html
XCK7325T HP バンク DDR3 32bit 1600Mbps ~1.75W (1.906 - 0.156)
KCU040  HPバンク DDR3 32bit 1600Mbps ~ 1W (1.5 - 0.5)
KCU040   HPバンク DDR4 32bit 1600Mbps ~ 0.7W (1.2 - 0.5)

 

 

IBIS シミュレーション:

  • IBIS シミュレーションを実行することにより、設計基板による信号品質を事前に確認できます。信号の反射や減衰、アイの大きさを確認してください。参考までに、グラウンド スティッチ ビアのあり・なしを比較している図 2-13 PG150 に記載されています。9_via.PNG

     

  • シグナルおよびパワー インテグリティの詳細は、下記のラウンジにあります。ご参照ください。

https://japan.xilinx.com/member/ultrascaleplus_si_pi_lounge.html 

 

 

 

 

 

more
5 0 471
Xilinx Employee
Xilinx Employee

概要

このブログでは、ザイリンクス評価ボード用 BSP に含まれるデバイスツリーに対し、ノードを追加、削除する方法を紹介します。

デバイスツリーを新規作成するよりも、既に動作しているものを流用することで、作成工数を削減することができます。

本ブログは、株式会社PALTEK 瀧澤様が作成された特別なブログです。

 

PetaLinux ツールが生成するデバイス ツリーについて

評価ボードをターゲットにしたデザインを作成した場合でも、Ethernet PHY 等の外部デバイスに依存するペリフェラルのデバイスツリーは、PetaLinux ツールでは自動生成されません。

これは、外部チップ自体の設定や、クロックの供給方法などがさまざまであり PetaLinux ツールにより判断すできないため、ユーザーが追加、修正する必要があります。

カスタムボードの場合も同様です。

次のいずれかの方法により、評価ボードのデバイスツリーを生成できます。

評価ボード用 BSP を使用して、PetaLinuxプロジェクトを生成する、

または、

評価ボード用 BSP を使用せず、petalinux-config コマンドでコンフィギュレーションを実行する時に、MACHINE_NAME 変数に評価ボード名を指定する

 

評価ボード用デバイス ツリーの生成(評価ボード用 BSP を使用する場合)

評価ボード用 BSP を使用して生成した PetaLinux プロジェクトは、特に設定することなく、そのボードで動作する Linux イメージをビルドできます。

petalinux-build コマンドを実行した後の、デバイスツリーのファイルは、次のように構成されています。

 

b.png

 

system-top.dts が、デバイスツリーの最上位のファイルです。

Ethernet PHY 等の情報は、system-user.dtsi ファイルに追加してください。

Ethernet PHY 等の情報は、ボード レベルおよびプラットフォーム特有であり、system-user.dtsi に含める必要があります。

system-user.dtsi は、system-top.dts から include されます。

詳細は、『Petalinuxツール資料リファレンスガイド』 (UG1144) を参照してください。

 

評価ボード用デバイス ツリーの生成(評価ボード用 BSP を使用しない場合)

評価ボード用 BSP を使用せずに、PetaLinux プロジェクトを作成した場合は、MACHINE_NAME 変数に、PetaLinux ツールに登録されている"評価ボード名"を指定することで、その評価ボード用のデバイスツリーが生成されます。

次に、petalinux-config コマンドで表示されるメニューの、MACHINE_NAME の指定例を示します。

 

1.png

 

2.png

 

指定可能なボード名は、『Petalinuxツール資料リファレンス ガイド』 (UG1144)を参照してください。

 

デバイスツリーの変更例

ZC702 評価ボードの GEM0 を、MIORGMII)から EMIOGMII)に変更し、PL の IPGMII2RGMII)を介して、外部の Ethernet PHY チップに接続する場合の例を示します。

 

1.png

 

ノードの追加

ノードを追加する場合は、system-user.dtsi に次を追加します。

 

1.png

 

パラメーターの追加

パラメーターを追加する場合は、system-user.dtsi に次を追加します。

 

1.png

 

パラメーターの変更

パラメーターを変更する場合は、system-user.dtsi を次のように変更します。

 

1.png

 

パラメーターの削除

パラメーターを削除する場合は、system-user.dtsi ”delete property” を追加します。

 

1.png

 

ノードの削除

ノードを削除する場合は、system-user.dtsi ”delete-node” を追加します。

 

1.png

 

ノードを削除する時、そのノードが他から参照されている場合は、注意が必要です。

次のように、phy-handle ethernet-phy@7 を参照している場合、phy-handle の値を変更した後に、ethernet-phy@7 を削除する必要があります。

 

1.png

 

この例では、system-user.dtsiで phy-handle の値を変更した後に、ethernet-phy@7 を削除しています。

 

1.png

 

ドライバー定義の無効化

次に示す pcw.dtsi では、status = "okay" により、ドライバー定義が有効になっています。

 

1.png

 

次のように、system-user.dtsi に入力することで、無効にできます。

 

1.png

 

まとめ

このブログでは、評価ボード用デバイスツリーの変更例を紹介しました。尚、上記ファイルの内容は、評価ボードやツールのバージョンにより異なる場合があります。

 

参照資料

エンベデッド デザイン ハブDesign Hub - PetaLinux ツール

https://japan.xilinx.com/support/documentation-navigation/design-hubs/dh0016-petalinux-tools-hub.html

ザイリンクスWiki Device Tree Tips

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842482/Device+Tree+Tips

 

more
7 0 553
Xilinx Employee
Xilinx Employee

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

 

皆さん、こんにちは。

前回のブログ記事では、RF データ コンバーター デザインのデバッグ用にザイリンクスが提供している RF アナライザーの説明から開始しました。

RF アナライザーを使用すると、無線アプリケーションのプリント回路基板 (PCB) やシステム オン チップ (SoC) デザイン全体から切り離して RF データ コンバーターを動作確認できることについてお話しました。また、RF アナライザー デザインをプログラマブル ロジック (PL) に構築する方法と、MicroBlaze を使用して RF-ADC および RF-DAC タイルとの通信を管理する方法についても説明しました。

ここでは、ハードウェア上での実際の RF アナライザーの使用について見てみることにします。

ボードに接続してアプリケーションを開始する方法を説明した後、RF アナライザー GUI を使用して機能の実地試験を実行できるようにします。

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

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

また、アナライザーのバージョン 2019.1 もリリースされています。バージョン 2019.1 における制限のいくつかを理解するために、(Xilinx Answer 71746) を参照してください。ザイリンクスでは常に製品の改善に努め、新しい機能を追加しましたが、注意点もいくつかあります。

ZCU1275 の概要

RF アナライザーの優れた柔軟性を紹介するために、ここでは Zynq® UltraScale+ RFSoC ZCU1275 特性評価キットを使用することにします。

ZCU1275 ボードの詳細およびすべての資料は、こちらにあります。

次の図に、ボードと主な該当部分を示します。
ZZ_00.jpg

前回のブログ記事で覚えていらっしゃる方もいるかと思いますが、RF アナライザーはボードから切り離されているため、PCB を気にする必要はない、とお伝えしました。

ところが、今回の場合は、必ずしもこれは当てはまりません。このボードについていくつか重要事項を把握している必要があります。

このボードでは、RF-ADC および RF-DAC のアナログ I/O とタイル クロック入力が Bulls Eye コネクタを使用して接続されいます。図を見ると、これらに対するパッドがデバイスの左側にあるのがわかります。

そのため、これらの Bulls Eye コネクタのピン配置を把握する必要があります。

次の図に、コネクタとパッドのピン配置を示します。

ZZ_01.jpg

Bulls Eye に接続される ADC および DAC タイルについて理解するには、『ZCU1275 ボード ユーザー ガイド』 (UG1285) の表 1-12 および 1-13 を参照してください。

このボードでコンバーターをクロックする方法は 2 つあります。Bulls Eye を使用すると、ラボ装置のタイルにサンプル クロックを提供できます。または、スーパー クロック モジュールで RF 位相ロック ループ (PLL) を使用してクロックを提供することもできます。ここでは、このボードのシステム コントローラー GUI (SCUI) を入手して、これらのクロックのプログラミングを管理するために使用する必要があります。

このボードの SCUI は、ZCU1275 の製品ページからダウンロードできます。

ダウンロード パッケージには、アナログ スーパー クロック モジュールで RF PLL をプログラムするためにあらかじめ用意されたオプションが豊富に含まれています。

シンプルにするため、ここではサンプル クロックを RF-ADC および RF-DAC に直接提供することにしました。

DAC サンプリング周波数 (Fs) 3932.16 GHzADC Fs 1966.08 MHz にそれぞれ設定します。これにより、キャリアを 3500 MHz で送信できるようになります (これは LTE Band42 ユース ケースに適合します)

すると、RF-ADC でこれを受信し、信号をダウンコンバートして、送信したベースバンド データをリカバリできます。

次は、周波数計画を示したものです。

ZZ_02.jpg

これを達成するには、RF-PLLA RF-PLLB をプログラムして 3932.16 MHz および 1966.08 MHz をそれぞれ出力するようにする必要がありました。

(使用したボードでは、RF-PLLA RF-DAC に、RF-PLLB RF-ADC にそれぞれ接続されていました。)

システム コントローラーに接続し、次のように設定できます。

ZZ_03.jpg

これでクロックのすべてが設定され、RF-DAC タイル 0 チャネル 0 RF-ADC タイル 0 チャネル 0 にループされます。

ビットストリームはアナライザーにあるので、準備が整いました。

RF アナライザー GUI の起動

それでは、RF アナライザーの使用を開始しましょう。RF アナライザーを初めて使用する場合、Vivado またはハードウェア サーバーへのインストール パスの場所を GUI で指定するよう指示するメッセージが表示されます。

パスが必要な理由は、JTAG を介したボードへの接続の管理に hw_server が使用されるためです。

ZZ_04.png

また、バックグラウンドで XSDB サーバーが起動されることもわかります。これは、ターゲット上で実行中の MicroBlaze アプリケーションと通信できるようにするためです。

次のステップは、デザインの起動です。

ローカル サーバーまたはリモート サーバー (ターゲットがそこに接続されているリモート マシンがある場合) を選択してハードウェア サーバーを開始するよう指示するメッセージが表示されます。

ZZ_05.png

hw_server を接続すると、ターゲット上で何が実行されているかを示すハードウェア ツリーが表示されます。

ZZ_06.png

私が実行したように独自のビットストリームをポイントしても、RF アナライザー ダウンロードに含まれるビルド済みビットストリームの 1 つを選択してもかまいません。

ビルド済みビットストリームでは、すべてのタイルが使用されます。これは、Vivado デザインがない場合や単にラボでボードを起動する場合に役立ちます。

ZZ_07.png

ビットストリームを読み込み、デバイスのステータスが [Configured] になると、29DR デバイスの下に MicroBlaze が表示されます。

アプリケーションは MicroBlaze で起動する必要があります。MicroBlaze を選択し、[Select Target] をクリックします。

ZZ_08.jpg

これで設定フェーズの終了となるため、ADC および DAC タイルの使用に移ります。

アプリケーションを起動すると、GUI でタイル設定が検出され、GUI にハードウェアの設定が反映されます。

ここでは 1 つの ADC および DAC タイルを使用したので、この設定が GUI に反映されます。

ZZ_10.png

タイルを選択して GUI でその状態を確認できます。この場合、両方のタイルに電源が投入されており、スタートアップ ステート マシンの最後の状態に達しています。

それでは、ここでコンバーター クロッキングをダブルクリックしてみましょう。ADC では、内部 PLL をバイパスし、1966.08 MHz でサンプル クロックが入力されるように設定されています。

同様に DAC タイル 0 でも、内部 PLL をバイパスし、3932.16 MHz でサンプル クロックがボードから直接入力されるように設定されています。

ZZ_11.png

ZZ_12.png

次に、RF-DAC データパスの設定を見てみましょう。 

RF-DAC タイルでチャネル 0 を選択し、それがどのように設定されているかを確認します。

ZZ_13.png

ミキサーのモードは [I/Q to Real] に設定されているのがわかります。その理由は、QAM (Quadrature Amplitude Modulation = 直交振幅変調) 信号を送信するようにしたためです。

ミキサーの周波数は 432.16 MHz、補間は 8x にそれぞれ設定されています。これは、491.52 MHz というサンプル レートを使用して 432.16 MHz で未変換のベースバンド データを RF-DAC に渡すことを意味します。

RF-DAC のナイキスト ゾーンは [Zone 2] に設定されています。

これは、3500 MHz の第 2 ナイキスト ゾーンのイメージが DAC から出力される信号になることを意味します。ループバックでは、バンドパス フィルターを使用して、このイメージだけが RF-ADC に渡されるようにします。 

スティミュラスの再生には、LVM ファイルを使用します。RF-DAC タイル 0 チャネル 0 [Generation] タブでは、信号タイプを [From File] に設定する必要があります。

ここでは、約 15 MHz の帯域幅の 256QAM 信号を使用します。

データ フォーマットの使用の概要は、(Xilinx Answer 71687) を参照してください。

 

GUI では、RF-DAC に渡されるベースバンド スペクトラムが表示されます。

ZZ_14.jpg

この信号の送信を開始するには、[Generate] をクリックします。

次に、私の RF-ADC データパスを見てみましょう。

ここでは、ナイキスト ゾーンが 2 になるように設定しました。これは、信号が第 4 ナイキスト ゾーンにあり、偶数であるため、[Zone 2] という設定が適切であるからです。

この後、ミキサーで -432.16 MHz NCO 周波数が提供されるようにし、8x 間引きを実行するように設定しました。

これにより、サンプリングされたキャリアはベースバンドにシフト ダウンし、スペクトラムの不要な部分は間引きされます。

ZZ_15.png

これで終了したので、[Acquisition] をクリックします。すると、ADC タイル 0 チャネル 0 のキャプチャ ウィンドウが開きます。

[Acquire] をクリックすると、ベースバンドでの受信信号を確認できます。また、スペクトラムが 122.88 MHz までしか拡張していないのもわかります。

これは、間引きフィルターによって係数 8 で間引きされていることを意味します。

ZZ_16.jpg

 

以上で、RF アナライザーの順を追った説明を終了します。

ここでは説明しなかった機能もいくつかあります。たとえば、ADC でのキャリブレーション フリーズやしきい値検出、DAC の逆 sinc などを試すことも可能です。

割り込みを確認するスコープもあります。

今後も RF アナライザーをお試しになり、デバッグに使用してみることをぜひお勧めします。 

more
5 0 440
Community Manager
Community Manager

ザイリンクス オンライン サポート リソース - 場所と使用するリソースの選択方法

 

ザイリンクスでは、資料アンサー レコードWiki、このブログを含むフォーラムなど、さまざまなオンライン リソースを提供しています。

どのリソースをまずチェックすればよいかは、デザインのタイプおよび設計段階によって異なります。

このブログでは、これらの各リソースに関する情報と、それらをいつ使用するのが最適かを説明します。

 

 

内容:

 

 

どのリソースを使用すればよいか

 

 

入門:

 

Documentation Navigator をダウンロードすると、製品の資料を検索できます。

注記: Documentation Navigator からは、日本語版は参照できません。

これらの資料は、ザイリンクス サポート サイトの [資料] セクションでも検索できます。

ザイリンクス サポート サイトからデザイン ハブにアクセスします。

これらのページには、入門資料、キー コンセプト、さまざまな設計タスクおよびツールに関連する資料へのリンクが含まれます。

 

 

特定のトピックに関するより詳細な情報が必要:

 

サポート サイトからソリューション センターにアクセスします。

エンベデッド デザインに関しては、ザイリンクス Wiki を使用し、資料で学んだトピックについてさらに詳しい情報を取得できます。

 

 

問題が発生した場合:

 

ザイリンクス サポート サイトの検索機能を利用すると、資料、既知の問題およびデザイン アドバイザリを含むアンサー レコード、フォーラム、ザイリンクス Wiki から検索できます。

 

 

ザイリンクス サポート リソース

 

資料アラート

 

ザイリンクス ウェブサイトにはアラート機能があり、製品資料のアップデートおよび新規刊行、製品の変更や製造中止、デザインアドバイザリのアンサー レコードなどのアラート通知を電子メールで受け取るよう設定できます。

https://japan.xilinx.com/myprofile/doc-alerts.html

 ザイリンクス アンサー 18683 の手順に従って、興味のあるザイリンクス製品に関するアラートを設定してみてください。

注記: 新製品がリリースされても、アラート設定には自動的には追加されません。新製品のアラートを受信するには、手動で追加する必要があります。

 

 

Documentation Navigator

 

ザイリンクス Documentation Navigator は、Vivado に含まれる無償のツールですが、個別にダウンロードすることもできます。

https://japan.xilinx.com/support/documentation-navigation/overview.html 

1.png

ザイリンクス デバイスまたは製品に基づいて関連の資料をフィルターする機能があり、また [Update Catalog] ボタンをクリックすると各資料の最新版をダウンロードできます。

2.png

資料のタイプでフィルターすることもできます。次に、エラッタのみをリストした例を示します。

3.png

注記: Documentation Navigator からは、日本語版は参照できません。

 

 

デザイン ハブ:

 

Documentation Navigator には、製品別にフィルターする機能に加え、特定のトピックに基づいて構成されたデザイン ハブもあります。

デザイン ハブには、概要、キー コンセプト、よくある質問 (FAQ) などのセクションがあり、関連資料、ビデオ、およびサポート リソースにすばやくアクセスできます。

たとえば、[Embedded Design] の下の [Boot and Configuration] を選択すると、次のリソースがリストされます。

4.png

5.png

注記: Documentation Navigator を使用しない場合は、ザイリンクス サポート サイトからデザイン ハブにアクセスできます。ウェブサイトのデザイン ハブには、日本語版の資料へのリンクも含まれます。

https://japan.xilinx.com/support/documentation-navigation/design-hubs.html

 

 

 

ザイリンクス サポート サイト

 

ザイリンクス サポート サイトには、https://www.xilinx.com/support.html からアクセスできます。

Documentation Navigator と同じ資料に加え、ザイリンクス ナレッジ ベースおよびコミュニティ フォーラムも含まれます。

6.png

検索ボックスに検索テキストを入力すると、ザイリンクス Wiki も含むすべてのリソースからの結果がリストされます。

これは、デザインで特定の問題または状況が発生し、それに関する情報を探している場合に便利です。

 

 

ザイリンクス ナレッジ ベース

 

ザイリンクス ナレッジ ベースは、アンサー レコード、公式資料の補足となる短い記事で構成されています。

これらの記事は、既知の問題、エラー メッセージの説明、一般的なガイダンスが記載されています。

7.png

注記: Vivado Design Suite でエラー メッセージが表示された場合は、関連のアンサー レコードがあるかどうかをツール内からも検索できます。

8.png

 

 

デザイン アドバイザリ:

 

デザイン アドバイザリは、設計に重大な影響を与える可能性のある問題に関する情報を含むアンサー レコードです。

上記のアラート システムの一部として、新規またはアップデートされたデザイン アドバイザリの通知も送付されます。ご使用の製品に関するデザイン アドバイザリの通知が送付されるように、ザイリンクス アンサー 18683 の手順に従ってアラートを設定することをお勧めします。

 

 

ソリューション センター

 

https://japan.xilinx.com/support/solcenters.html

9.png

ソリューション センターは、特定の製品またはトピックに関するアンサー レコードをまとめたものです。すべてのトピックにソリューション センターが作成されているわけではなく、要望に基づいて作成されます。

次のセクションがあります。

デザイン アシスタント:

デザイン アシスタント アンサーには、簡潔な順を追ったデバッグ情報が含まれ、推奨されるデザイン フローに従った手順を示します。

資料:

関連の資料へのリンクが含まれます。

デザイン アドバイザリ:

デザイン アドバイザリへのリンクが含まれます。

主な問題:

よく寄せられる質問および関連する既知の問題アンサーへのリンクが含まれます。

 

 

 

フォーラム

 

https://forums.xilinx.com/

ザイリンクス フォーラムも有益なサポート リソースです。ほかのユーザーが同様のユース ケースを使用していたり、同じような問題に遭遇している場合があり、それらの情報が共有されている可能性があります。ザイリンクス社員がフォーラムを管理し、ディスカッションに頻繁に参加しています。フォーラムには、この記事が含まれる設計およびデバッグ テクニックのブログなどのブログも含まれます。

 

ソリューション

 

フォーラム内で質の高い回答を簡単に見分けられるようにするため、問題を解決した投稿は質問を投稿したユーザーによりソリューションとしてマークされます。

10.png

 

 

 

 

 

 

 

 

 

ザイリンクス Wiki

 

https://xilinx-wiki.atlassian.net/wiki/spaces/A/overview

ザイリンクス Wiki はエンベデッド デザインに焦点を置いており、Linux や U-Boot などのトピック、MicroBlaze、Zynq-7000、および Zynq UltraScale+ デバイスの入門チュートリアルとリファレンス デザインが含まれます。

Wiki の内容はユーザー ガイドを補足するものなので、まず公式資料を参照してから、Wiki を使用して知識を深めるようにしてください。

11.png

 

 

 

GitHub

 

https://github.com/Xilinx

ザイリンクスでは、より多くの Vitis のライブラリおよびほかのソフトウェア リソースを GitHub で提供するようになっており、チュートリアルなどのソフトウェアに焦点を置いた資料の一部もここに掲載されます。

12.png

情報は Jupyter Notebook でも提供されます。

 

 

ザイリンクス トレーニング

 

上記の無償のリソースに加え、ザイリンクスでは有償のトレーニング コースも提供しています。

https://xilinxprod-catalog.netexam.com/

 

 

クラスルーム トレーニング

 

ザイリンクスのインストラクターによるトレーニングは、エキスパートが受講者個人個人と対面して、集中した環境で広範なカリキュラムを提供します。

13.png

 

 

オンライン トレーニング

 

オンライン トレーニングは、トレーニング ポータルを使用して提供されます。質の高い、インタラクティブで実践的なトレーニングを提供することに焦点を置いています。

14.png

 

 

 

 

 

 

 

 

 

 

 

 

オンデマンド ビデオ

 

オンデマンド ビデオは、自分のペースで進めることができるコースで、講義、デモ、演習が含まれます。

15.png

more
4 0 346
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

     

more
1 0 361
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 の機能を見てみることにします。 

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

more
3 0 640
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' に関するブログ記事をリリース予定です。

more
5 0 730
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 コードを編集して別の機能を追加することもできます。

more
1 0 1,015
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 アナライザーのアンボックスおよび順を追った説明をします。 

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

 

 

more
4 0 537
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)をぜひお試しください。

more
4 0 402
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

 

 

 

more
3 0 1,114
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 つ目の問題が修正されたことを意味します。

more
2 0 860
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

 

 

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

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

 

more
3 0 1,302
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 インターフェイスをシミュレーションします。

more
2 0 771
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

 

 

more
2 0 15.2K