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

RF データ コンバーターの同期化

karnanl
Xilinx Employee
Xilinx Employee
4 0 392

本ブログは英語版の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 エラーのデバッグ方法に関する別のブログを記述する予定です。