LabVIEW FPGA でフィードバックノードを長遅延に使用した時の注意

こんにちは、ドルフィンシステムの笹生です。

さて今回はLabVIEW FPGA でのコンパイル時間とフィードバックノード関係について少し注意したほうが良いことについてです。

フィードバックノードを遅延素子として使用する際は注意が必要？？

 LabVIEW FPGA のプログラミングでは信号間のタイミングを調整したり、揃えたりするためにフィードバックノードを使うことが良くあります。

 

フィードバックノード

フィードバックノードについての以前の解説はこちら

https://dolphinsasoh.blogspot.com/2018/09/fpga.html

このタイミング調整のためにフィードバックノードを使うこと自体はもちろん当然のように行うのですが、長い遅延をさせたい時には注意が必要です。

例えば、U32 (32bit) のデータを 2048サイクル遅延させたい場合があったとします。

（こんなに長遅延は普通ないだろうと思われるかもしれませんが、無線関係だと OFDM での CP 付与など意外と随所で大きな遅延をさせて調整することがあります）

そこでフィードバックノードで2048サイクル遅延をさせたものを作成します。

当然シミュレーションも正しく動きますし、特にこの時点でエラーも起きません。

簡単に遅延を実現できてしまうのでつい使ってしまいます。

問題はコンパイル時間に現れた

これは条件にもよって違うと思いますので一概に言えないのですが、長遅延をさせるフィードバックノードがあるとFPGAコンパイル時間（特にシンセシス時間）が非常に長くなる傾向があるようです。

私の確認した限りでは、単体でコンパイルしてフィードバックノードで遅延させたときにははシンセサイズの時間が 1時間20分程度かかっていたものが、FIFOベースの遅延に変更したところ 14分に短縮された例もありました。

実はこのフィードバックノードによる遅延の記述方法は LabVIEW NXG ではコンパイル時間の影響はあまりないようです。

私がNXGと比較した際の Xilinx の FPGA コンパイラは同じ Vivado 2015.4 なので、LabVIEW FPGA の VI の解釈による中間ファイル生成(HDL生成)と LabVIEW NXG の中間ファイル生成(HDL生成)アルゴリズムに違いがあるのかもしれません。

まとめ

程度にもよりますが LabVIEW FPGA で長遅延をさせる場合には、フィードバックノードではなくメモリ・FIFO ベースで遅延をさせたほうがよさそうです。FPGAコンパイル時間は元々長時間かかるものですがもし異常に時間がかかるようならフィードバックノードが原因ということもあるかもしれません。

LabVIEW Communications CFX - 複素固定小数点

こんにちは
ドルフィンシステムの笹生です。
皆さんは LabVIEW NXG/ LabVIEW Communications をすでにお使いでしょうか？
通常の LabVIEW と比較して色々と変わった点が多いと思うのですが、今回はその中でも新規で追加された数値の型「CFX（複素固定小数点）」について紹介します。（Webで調べたのですがあまり紹介されていないようですね）

CFX - 複素固定小数点

複素数の実数、虚数がそれぞれ符号付の固定小数点として扱える型です。
FPGA で複素数が使用できます。（←ここがうれしい！）
割と多くの演算でそのまま複素数の入力、出力として使用できます。（←ここもうれしい！）
制御器などを右クリックすると変更できる「表記法」にも CFX があります。

FPGAで複素数が扱える

FPGA ではないホスト側であれば従来から浮動小数点の複素数が使用できるのですが、通常の LabVIEW FPGA で複素数を計算するときには、型としての実数、虚数を別々の固定小数点にして計算していました。無線の世界ですと IQ 複素数を扱うことが多いので別々に計算させるのは実装上の手間が増えてしまします。
一方のLabVIEW NXG/ LabVIEW Communications では 「CFX - 複素固定小数点」が新たに型として加わり、FPGA でも使用できるようになっています。実数、虚数はそれぞれ固定小数点のフォーマットに従いますので、設定をすれば整数部分、小数部分のフォーマットを自在に変更できます。
また割と多くの演算子でこの CFX がそのまま入出力に使えるのでブロックダイアグラムが非常にすっきりします。
以下の図では、参考までに CFXを使った簡単な演算について記述してみました。
これまでの LabVIEW なら、別々に分けてから演算しなくてはいけなかったのですが、このようにシンプルに記述できるようになりました。

まとめ

LabVIEW NXG/ Communications では「CFX - 複素固定小数点」が新たに型として追加されたことでFPGA の実装でも実数・虚数を別々に計算させる必要がほとんど無くなりました。
まだまだ勉強中ですが引き続き、従来の LabVIEW と違うところをお知らせしていきたいと思います。

P2P使用時のPXIeシャーシでのスロット位置の注意点

ドルフィンシステムの笹生です。

以前、「PXIeシャーシのトリガについて」という記事を書きました。

http://dolphinsasoh.blogspot.com/2018/01/pxie.html

この記事では、トリガを使用する際に設定の注意点などを書きました。

それ以外にも PXIe シャーシにボードを挿して使用する場合には気を付けたほうがよい点があります。

P2P を使用する場合のスロット関係は注意

P2P は CPU に負荷がかからずにボード間でのデータ転送ができるので便利です。

CPUを経由しないので転送レートも高速にできます。

しかし、注意が必要なのです。

P2P を使用する場合で、転送レートが必要でないのであれば、挿すスロット位置は気にしなくてよいでしょう。

しかし、高速に転送する必要がある場合には挿すスロットを離してしまうとうまく転送できないことがあります。

例えば、複数 FPGA ボードを使って信号処理を行う場合、ある FPGA から ある FPGA へデータを転送する必要があります。

実際適当に P2P する FPGA ボードを挿すと、転送がうまくいかないなどの現象が起きたりして混乱をする場合がありました。

P2P高速転送時には同じスイッチのスロットに挿す

PXI シャーシはスロット間は CPU へのデータの転送のためにスイッチが使用されていますが、スロット毎に接続されているスイッチが異なります。

例えば、PXIe-1085のバックプレーンの構造は以下の図のようになっています。

このような構造なので、高速に転送したい場合は同じスイッチを使っているスロットに FPGA ボードを挿入する必要があります。

逆に転送レートはそれほど必要なければ離れていても大丈夫です。

どのくらいの転送レートまでなら OK なのかは P2P の使われ方の状況によって違うと思うのでここでは言及できませんが、基本、同じスイッチのスロットを使うようにすると良いと思います。

また、一度ホスト経由（ソフトウェア経由）でのデータ転送であればスロット位置は気にしなくてよいでしょう。

どのスロットがどのスイッチに接続されているかなどはシャーシの資料を確認してください。

まとめ

大規模な信号処理アプリケーションになってきて、FPGA ボードを複数枚使用して高速に転送を行う P2P をする時には、同じスイッチのスロットに挿入して使用しましょう。

USRP-RIO レベル設定とゲイン設定で表示される受信電力が異なるのはなぜ？

こんにちは

ドルフィンシステムの笹生です。

 

今週開催のマイクロウェーブ展 MWE 2018 に NI 様ブースに出展させていただきます。

期間 2018/11/28(水) ～ 11/30(金)

会場 パシフィコ横浜

NI様ブース番号 H-03

https://apmc-mwe.org/mwe2018/kigyo/data/A07100.html

弊社は「お客様の「作りたい」をソフトウェア無線機で実現する開発サービス」をテーマとして出展致します。

MWE 2018 にお越しの際は是非のぞいてみてください。

 

さて本日のメールニュースは、USRP-RIO の設定方法についてです。

USRP-RIO の受信のゲインを設定する方法としては以下の 2種類あります。

・ Reference Level (dBm) での設定

・Gain (dB) での設定

じつはこの2種類の設定で表示される入力信号の電力値換算が異なる現象がありました。

今回はなぜ異なってしまうのか、そのあたりを見ていきたいと思います。

 

電力表示の仕組み

 

弊社で USRP-RIO のソフトウェアを開発する際にベースとして良く使用しているサンプルでは受信の RF 設定は Reference Level (dBm) を指定する方式です。

※これはこれでどういう設定値なのかというのは別途こちらに調査した記事がありますので参考にしてください。

↓

http://dolphinsasoh.blogspot.com/2018/04/rf-iq-4.html

 

この Reference Level (dBm) での設定は、結局関数内部で USRP-RIO のアナログゲイン設定に変換されて設定されています。このReference Level (dBm) での設定方法以外に、直接 Gain (dB) で設定する方法(関数)もあります。

 

さて、USRP-RIO のサンプルは非常に良くできていて、USRP-RIO 本体から吸い上げた受信信号は本来 IQ 16bit の整数データにも関わらず、表示上ではきちんと受信電力 (dBm) に変換されて表示されます。

 

整数から電圧値への変換係数を USRP-RIO のライブラリが出力してくれているのでそれを使って変換すれば正しい電圧値に変換できるわけです。

ところが、 RF 設定で  Reference Level (dBm) を指定した場合はほぼ正しく表示される電力ですが、Gain (dB) を指定する場合ではかなりずれた電力値が表示されてしまいます。

 

実際に計測

 

例として -20dBm の正弦波を USRP-RIO に入力した場合のサンプルソフトウェアでの表示を見てみます。

まず、Reference Level (dBm) を 0dBm 設定にした時

正弦波は約-21dBm の表示で基本的に正しい値が表示されました。

Reference Level(dBm) を -10dBm, -20dBm の設定に変化させても、正弦波のレベルはほぼ同一の -21dBm程度でした。

 

今度は Gain 指定の関数を使用した場合です。

Gain 設定を 0dB にした時

正弦波は約 -14dBm を表示しており、実際の正弦波と比べても 6dB以上の誤差がありました。

それだけではなく、Gain を 10dB, 20dB とすると、正弦波の表示も -4dBm, +6dBm と大きくなっていきました。

 

なぜ違ってしまうのか？

 

先ほどお伝えした整数データから電圧値に変換するための係数にありました。

Reference Level(dBm) 指定の場合では、USRP-RIO のライブラリ側で変換係数をきちんと計算した上でそれを使っています。

例えば、0dBm 設定での変換係数が 0.652253 で、-10dBm の設定では 0.206261 、-20dBm では 0.065225 にという具合に変化します。

当然ゲインの設定も +10dB, +20dB になっていて、取得する整数データもそれに応じて大きくなります。

なので、係数で調整されて表示される電力値は実際の入力値に一致するようになっています。

 

ところが、Gain 指定の場合では、変換係数が固定値の 2 になっており、Gain を 10dB, 20dB と変えても変換係数は 2 のままです。

これが原因で、表示の電力値も実際の入力レベルではなく、設定とは無関係の変換係数 2 での値であるため表示電力も誤った値を表示しているのでした。

 

まとめ

 

個人的には、Reference Level(dBm) 指定でも実際には設定する Gain に変換して設定しているはずなので、Gain 設定でも変換係数は正しく出してほしいなと思うところです。

Gain 設定を使用される場合は変換後の値は実際の値ではないので注意が必要です。

PXIe-791X の LabVIEW サンプル FPGA がコンパイルできないt時の対処法

 

こんにちは

ドルフィンシステムの笹生です。

 

本日は、最新の NI FPGA ボードシリーズ FlexRIO の PXIe-791X のサンプルについてです。

実はこのシリーズの FPGA ボードについて調査をしていたのですが、そのサンプルの FPGA がコンパイルエラーになってしまいました。

結論としては、LabVIEW 2017 SP1 では新規プロジェクトを作成し、サンプルのプログラムを移植すれば FPGA のコンパイルは成功しました。

LabVIEW 2018 ではサンプルのまま FPGA をコンパイルしても問題ないようです。

PXIe-791X FlexRIO コプロセッサモジュール

今回調査した PXIe-791X (PXIe-7911, PXIe-7912, PXIe-7915) は NI ホームページでは以下の様に紹介されています。

「PXI FlexRIO​コプロセッサモジュール​は​高​性​能​FPGA​を​搭​載​し​て​お​り、​PXI​システム​に​信​号​処​理​機​能​を​追​加​し​ま​す。​こ​れ​ら​の​モジュール​は​Xilinx​の​最​新​FPGA、​PCI Express​な​ど​の​ストリーミング​技​術、​お​よ​び​NI​ピアツーピアストリーミング​の​メリット​を​活​用​し​て、​バックプレーン​経​由​で​そ​の​他​の​モジュール​と​の​高​帯​域​幅​の​データ​通​信​を​実​現​し​ま​す。​PXI​ベクトル​信​号​トランシーバ​と​いっ​た​別​の​PXI​デバイス​と​組​み​合​わ​せ​る​と、​複​雑​な​アルゴリズム​の​リアルタイム​実​行​に​必​要​な​FPGA​リソース​を​追​加​で​き​ます。」

 

https://www.ni.com/ja-jp/shop/select/pxi-flexrio-coprocessor-module

 

弊社のように無線信号処理を実装するとき、システムにこのような FPGA モジュールを追加して、アルゴリズムの追加を行うことがあります。

 

ちなみに、開発環境の必要な条件は以下の様になります。

・LabVIEW 2017 SP1 以降

・LabVIEW FPGA 2017 SP1 以降

・FlexRIO 18.1.1 ドライバ

 

サンプルの FPGA がコンパイルエラー

まずは環境として LabVIEW 2017 SP1 、LabVIEW FPGA 2017 SP1、FlexRIO 18.1.1 のドライバをインストールしました。

その後サンプルを見つけるためにサンプルの検索で、デバイスを PXIe-7915 に限定して検索をしたところ「PXIe-791X Getting Started.lvproj」を見つけました。

 

サンプルのプロジェクトをコピーして、開き、FPGA のビルド仕様からビルド(コンパイル) をしたところ、中間ファイル生成の時に以下の様なエラーがでてしまいました。

 

日本NI のサポートに連絡

まず、日本 NI のサポートに連絡をしました。こういったときにサポートは大変心強いです。私の環境などが良くないかもしれないとも思っていたのですが、サポートの方の環境でも同様に再現したようで、対処法を一緒に考えてくださいました。

 

まず、先ほどのコード生成エラーでは、以下の様に対処することで先に進むことができました。

 

１．サンプルプロジェクト内の「Rounting (Host Control v1)」を右クリック

し、プロパティを選択。

 

 

２．Routing PropertiesダイアログのGeneralカテゴリにおいて、

右側コーナーある更新ボタンをクリックし、再スキャンする。

 

 

しかし、今度はコンパイルが進んでいくとシンセサイズの時にエラーが発生してしまいました。

 

 

こちらも、サポートの方の環境で再現されたようでした。

ただ、LabVIEW 12017 SP1 で起きる現象で、LabVIEW 2018 の環境では特に問題なくコンパイルできるようでした。

 

新規プロジェクトを作成し、サンプルのファイルをコピーしてみる

結局、新規にプロジェクトを作成しサンプルのファイルをコピーした場合は問題なく FPGA のコンパイルができました。

 

 

まとめ

PXIe-791X のサンプルプロジェクト「PXIe-791X Getting Started.lvproj」は、LabVIEW 2017 SP1 ではそのまま使用できないので一旦新規プロジェクトにコピーすることで解決しました。

 

CEATEC2018 に展示されたので行ってきました

こんにちは、ドルフィンシステムの笹生です。

先週 2018/10/16 ～ 10/19 まで幕張メッセで CEATEC 2018 が開催されました。

情報通信研究機構様 (以下 NICT様) の展示ブースにて、弊社が NICT様から受託開発した装置が展示されたので行ってきました。

「超多数接続・低遅延無線アクセス技術 STABLE」です。

この技術は、NICT 様が現在研究されている 5G の先を行く技術です。

デモでは 5G で要求されている接続端末数 100万台/km^2 を凌駕する 160万台/km^2相当 と表示されていました。またそれだけの接続数を確保しつつ、遅延時間も 4G で要求されている 10ms より大幅に少ない 3.8ms を表示していました。

デモでは、実際に 5台の USRP-RIO 端末局から同一周波数同一タイムスロットで送信し、PXI の基地局と通信をさせていました。

この技術内容について解説されている NICT様のプレスリリースはこちらです↓

http://www.nict.go.jp/press/2018/08/20-1.html

私はCEATEC 最終日に短い時間でしたが足を運びました。NICT 様ブースは大盛況で、多くのお客様が熱心に説明を聞いておられました。

この技術に関して、開発事例として NI様 Web ページにも掲載されているのでご興味のある方はご一読ください。

http://japan.ni.com/usersolutions/nict

まとめ

今回は CEATEC での NICT様展示 「超多数接続・低遅延無線アクセス技術 STABLE」についてお送りしました。USRP-RIO や PXI といった SDR プラットフォームを使用して研究されるケースは今後一層増えていくのではないかなと思いました。

高速なクロックでも FPGAコンパイルを成功させる秘訣

皆様こんにちは、ドルフィンシステムの笹生です。

 

さて、引き続き LabVIEW FPGA の解説をしたいと思います。

なかなか本題の無線信号処理に入ることができませんが、やはり LabVIEW で FPGA を扱ううえで避けて通れないところもありますので、慌てずに解説していきたいと思います。

 

前回、どちらもやりたいことは同じなのに、コンパイルが失敗するものと成功するものを紹介しました。

成功したほうには処理の前後に「フィードバックノード」を挿入しており、これが成功の秘訣だとお伝えしました。

 

今回は LabVIEW FPGA で動作周波数の高いクロックでもコンパイルを成功させる秘訣、「フィードバックノード」の解説をします。

 

この「フィードバックノード」、通常の LabVIEW ソフトウェア開発でも使ったことがある方もいるかもしれません。しかしそれほど頻繁に使用しないと思います。でも、LabVIEW FPGA の開発では意識的に使用する非常に重要になるキーコンポーネントで、私はかなり多用しています。

 

フィードバックノード

 

「フィードバックノード」を LabVIEW FPGA で使用する目的は主に 3つあります。

１：データを保持する（シフトレジスタ）

２：並列処理間のタイミング合わせ

３：動作クロックの向上（コンパイル時のタイミングエラー回避）

（これを見て FPGA を昔からご存知ならお分かりかもしれません。要はフリップフロップです。）

 

LabVIEW のヘルプなどに書いてあることは基本的に 1 だと思うのですが、LabVIEW FPGA で開発するうえでは、2、3 の役割も大変重要になってきます。今回は主に 3 について解説します。

 

「フィードバックノード」で動作クロックを向上させる

 

なるべく話を簡単にして解説をしたいと思いますので厳密な部分でおかしなところがあるかもしれません。

より詳しく学びたい方は、FPGA の専門書は今やたくさんあるのでそちらをご参照いただければと思います。

（以下、色々たとえ話を考えていたのですが身の回りの例えでうまく表現できませんでした。すみません。。。）

 

演算を何もしない経路でもコンパイルエラーは起きる

 

例えば極端な例です。16bit の幅のデータを入力からそのまま出力に出すようにします。

演算は何もしてません。

 

 

ソフトウェアなら、単なるコピーです。データが壊れるといったことはありません。

しかし、FPGA ではコンパイルで計算された最大動作周波数以上のクロックの場合、データが壊れることがあります。

 

なぜか。

 

それは FPGA では物理的に距離が変化するからです。

FPGA のコンパイラが配線をするとき、もちろん最大限努力して全てのビットを最短距離にしようとしてくれます。しかし、物理的な限界もありますしそれぞれの経路で差がでてくるのです。

そのため、あるビットの距離があるビットの距離よりも長いといったことは当然起こりえます。

 

距離が違うとどうなるのでしょうか。

この例では入力16bit はきちんとそろって入力されたとします。

出力の 16bit には、下位 15bit は 10ns で到達する距離でしたが、最上位ビット 1bit だけ距離が長くなって20nsかかったとします。

 

（これはイメージです）

 

 

この "最大距離＝最大時間" で "動作可能な最小ティック時間=最大クロック周波数" が制限されるのです。

 

この例であれば、最も遅い 20nsのティックのクロックであれば問題ありません。

つまり 50MHz 未満なら全ビット入力から出力に正確にわたります。

では 100MHz のクロックだったらどうでしょうか。

コンパイルはエラーになってしまうので実際に実行はできませんが、無理やり実行できたとすると最上位ビットだけデータが間に合わず、最上位だけおかしなデータになってしまいます。

 

つまりこのコンパイルでは、50MHz のクロック指定ならコンパイルは成功しますが、50MHz 以上のクロック指定だとタイミングエラーで実行はできないのです。

 

しかし、仕様だからどうしても 100MHz で動かしたい。ということもあると思います。

答えは「フィードバックノード」を入れる、です。

 

 

「フィードバックノード」はデータを保持してくれる役割があるのですが、その保持するタイミングはクロックの立ち上がりになります。そして、立ち上がり以外はその時の値を保持します。

次のクロックの立ち上がりでは新たな値を保持します。

 

さてこれがどうして動作クロックを向上させるための秘訣なのかというと、

距離を分割してくれるから

です。

 

「フィードバックノード」はクロックによって動作を規定されます。乗算やその他のプリミティブな処理は通常クロックは関係ありません。

 

先ほどの 16bit のデータをそのまま出力に出す例にフィードバックノードを入れてみます。

通常、コンパイラは動作周波数を大きくするようにしたいので、物理的にほぼ真ん中あたりに「フィードバックノード」を挿入しようとします。

つまり、15bit は 5ns + 5ns の距離に分割され、最上位ビット 1bit は 10ns + 10ns に分割されます。

こうすることで、最も長いデータパスは 10ns になり、100MHz でコンパイルが成功します。

（あくまでイメージです）

同様にして、前回の例でいうと

「フィードバックノード」が入っていない場合、入力から出力までの処理時間と経路距離がそのまま動作周波数として計算されるため、高い周波数ではタイミングエラーとなってしまいます。

そして、「フィードバックノード」を入れたほうでは、処理時間、経路距離が分割されるため、動作周波数も高い周波数でコンパイルが成功するわけです。

 

 

まとめ

高い動作周波数で動作させたいときには、データを経路を分割するために「フィードバックノード」を入れることで解決します。

 

コンパイルで起きるタイミングエラー、もし起こった場合どこで起きているのかわかればそこに「フィードバックノード」を入れることで修正ができそうですよね。一応コンパイラの「タイミング違反の調査」で調査できるのですが、表示される部分がそのまま本当に原因ではないことがあったりします。（むしろ表示された場所じゃないことのほうが多かったりします）

 

タイミングエラーが起きてしまった場合には、「タイミング違反の調査」の場所以外にも、新しく追加したところの処理が多くないかなどを見ていく必要があると思います。

意外と本来動作速度と関係がない、動作周波数は遅くてもいい制御器、表示器にフェードバックノードをつけると改善されたりすることも。

この辺りの改善ノウハウは経験によるところが大きいです。

 

 

 

 

LabVIEW FPGA でリアルタイム無線信号処理をする(2)– 1ティックで高速に処理をさせるコツ-

 

皆様こんにちは、ドルフィンシステムの笹生です。

 

さて、今回は 引き続き LabVIEW FPGA での無線信号処理について解説をしたいと思います。

 

無線信号処理と言ってもその処理内容は多岐に渡ります。

例えば OFDM のような送信無線信号処理を例に取ると

・符号化

・インターリーブ

・変調

・IFFT

・サイクリックプリフィックス

・フィルタリング

・アップコンバート

など様々な信号処理を経て、ビット列から無線信号へと変換されて送信されます。

 

ビットを主体とした信号処理から、数値を主体とした信号処理まで多岐にわたるのですが、いずれの処理も FPGA に実装することができます。

FPGA に信号処理を実装するには、FPGA 独特の考え方で設計・プログラミングをしないといけません。

それは、

・1ティック (1クロックサイクル) で動作が完結するようにする

ということです。

このお約束を守らないとコンパイル時にタイミングエラーが起きて、実行することができません。

1 ティックでの処理

LabVIEW FPGA では、基本的にクロックのティックで動作するように作成します。

そして、その動作を決めるのが SCTL (シングルサイクルタイミングループ) です。

 

 

この SCTL ループ内に記述したプログラムは、基本的に1ティック（1クロックサイクル) で動作します。

 

そのため、この SCTL 内におかれる関数やサブ VI も 1ティックで動作が完結するように記述してあげる必要があります。

そして、SCTL 内のプログラムが 1ティックで終わるか終わらないかは、長時間かかるコンパイルが終了するまで分からないという FPGA 特有の事情があります。

本当にこれは厄介で、FPGA の経験があっても難しいプログラムになってくると、論理的には正しく 1ティックで終わらないというタイミングエラーがコンパイル開始から数時間後に通知されて唖然とすることも良くあります。

 

例えば、以下のプログラムはコンパイル可能です。

 

 

単純に 4つの整数値を乗算して足すだけのプログラムです。

 

これを SCTL 内に記述してコンパイルしてみます。

ターゲットは PXIe-7976R とします。

SCTL のクロックがデフォルトの時は 40MHz クロックなのでコンパイルが通ります。

しかし、250MHz といった高速のクロックの場合はコンパイルエラーになってしまいました。

 

これは乗算して足し算するまでが

・40MHz 1 ティックで終了する処理量なのでコンパイル OK

・250MHz での 1ティックでは終わらない処理量なのでコンパイル NG

だからです。

つまり単純に処理をどんどん増やしていくと高速なクロックで処理させることがだんだんできなくなっていくのです。

ではどうしたら 250MHz 1ティックに間に合わせることができるでしょうか？

高速なクロックでコンパイルを通すには。。。

 

答えは「フィードバックノードを途中に入れる」です。

実はこの「フィードバックノードを途中に入れる」ことで、高速なクロックで処理させることが可能になります。

 

実際、以下のようにフィードバックノードを各所に入れると 250MHz のクロックでコンパイルが OK になります。

 

 

なぜか？

 

なぜフィードバックノードを途中に入れると高速なクロックで処理させることができるかについては次回解説したいと思います。

 

フィードバックノードは物理的な意味合いもあるので、次回じっくり解説したいと思います。

 

 

 

 

 

 

 

 

 

 

LabVIEW FPGA でリアルタイム無線信号処理をする(1) -LabVIEW FPGA は何ができるのか-

こんにちは。ドルフィンシステムの笹生です。

残暑が厳しいですが、皆様いかがお過ごしでしょうか。

メールニュースでも何度か FPGA の話題は出てきておりますが、今回から数回、LabVIEW FPGA をテーマにしていきたいと思います。

今回は最初ですので、概要として「LabVIEW FPGA は何ができるのか」をお伝えします。

一般的な「FPGA」というもの自体は既にポピュラーになっていますが、皆さんはどのようなイメージをもたれるでしょうか。ちなみに Wikipedia には以下のように書かれています。

"FPGA（英: field-programmable gate array）は、製造後に購入者や設計者が構成を設定できる集積回路であり、広義にはPLD（プログラマブルロジックデバイス）の一種である。現場でプログラム可能なゲートアレイであることから、このように呼ばれている。"

貼り付け元 <https://ja.wikipedia.org/wiki/FPGA>

確かに上記の通りなのですが分かりにくいですね。私の FPGA に対するイメージですが、もう少し簡単に言うなら

・(ソフトウェアのように) 柔軟

・リアルタイム（時間確定的）に処理が可能

ことを実現できることが FPGA (の真骨頂) だと思っています。

FPGA はソフトウェア無線 (SDR) にとって重要なキーコンポーネントだと思います。

さて、LabVIEW にはこの FPGA をプログラミングできる LabVIEW FPGA モジュールがあり、インストールすることで、LabVIEW から簡単に FPGA の開発ができるようになります。

LabVIEW FPGA では何ができるのか？

LabVIEW FPGA では、GUI 以外のことはほとんどできる

と言っても良いかと思います。特に無線信号処理に関して言えば、物理層をリアルタイムに実装することが得意です。

無線信号処理での物理層では、符号・変調・フィルタなどの信号処理が必要になりますが、多くの処理はLabVIEW FPGA で実現可能ですし、要求に合った時間確定的な処理をさせることができます。

また複雑な信号処理も、IP コアとして提供されているものを使用できれば相応のコストが掛かる場合もありますが、開発期間も短縮できます。

例えば弊社では LTE の仕様に準拠した送信機・受信機の物理層を LabVIEW FPGA で実装し、リアルタイムでの送受信を実現しています。

またこれは LabVIEW FPGA の通常の FPGA 開発と比較しての開発上のメリットなのですが、

・ハードウェアのインターフェースが抽象化されているので、あまり考えなくて良い

・LabVIEW のブロックダイアグラムなので、HDL (ハードウェア記述言語）よりも分かりやすい

ただし・・・引き換えとして以下のような制限があります。

・使用できる関数等のライブラリが制限されます。

・完全に並列処理になるので、ソフトウェアとは違う考え方が必要です。

・時間（クロック）の概念が導入されます。

・リソース使用量を気にする必要があります。

・コンパイルに非常に時間が掛かります。エラー時の修正にはコツが必要です。

このあたりの制約はやはり最終的にハードウェアとして動作するので避けられないところです。

まとめ

LabVIEW FPGA での具体的な開発方法については、解説されている書籍が既に出版されていますし、NI のチュートリアルのページも充実してまいりました。

メールニュースでは次回からはあまり解説されていない LabVIEW FPGA での無線信号処理開発のポイントについてお伝えできたらと思います。

ドルフィンシステムでは、長年 FPGA を用いた無線信号処理をしてきており得意としており、お客様のアプリケーション実現に最適な SDR システムのご提案をしております。

USRPの 最大入力レベルは？

こんにちは、ドルフィンシステムの笹生です。

本日は USRP の最大入力レベルについてです。

「フロントパネルでは -15dBm max の表記となっているが、NI の仕様書には 0dBm max までとなっている。どちらが正しいのか？」

あるお客様からこのようなご指摘をいただきました。

実際、弊社所有の USRP のフロントパネルをみると全て 「-15dBm max」という表示になっています。普段からフロントパネルを見ていたのですっかり USRP シリーズの最大入力レベルは -15dBm だろうと思っていました。

ところが、NI のサイトからダウンロードできる USRP の仕様書の方はというと、USRP-2922 の仕様書には、受信側の最大入力レベルは 0dB max と書かれていました。

確かにこれではどちらが正しいのかわからないので、実際にSGから信号 (CW) を -15dBm, -5dBm, 0dBm のレベルで出力し、USRP 実機で受信させ確認してみました。（USRP の Rx Gain 設定は 0dB）

ちなみに、今回調査に使用した USRP のうち仕様書に 0dBm max となっているのは 2922、他の USRP は仕様書でも -15dBm max となっていました。

USRP の最大入力レベルは結局どこまで可能か?

USRP	フロントパネル表示	仕様書での記述	SG -15dBm	SG -5dBm	SG 0dBm
2922	-15dBm max	0dBm max	OK	OK	オーバーフロー
2943	-15dBm max	-15dBm	OK	OK	OK
2954	-15dBm max	-15dBm	OK	OK	オーバーフロー

弊社にある USRP で試したなかでの結論ですが、少なくとも -5dBm 程度までは信号を入力できました。日本 NI の技術の方にも確認していただいておりますが、同じように-5dBm の信号は問題なく入力できるという報告をいただいております。

0 dBm を入力した際にはサチってしまいましたが入力自体はできますので、仕様書での 0dBm max は正しいと思います。

なぜフロントパネルの表示や多くの仕様書で -15dBm までという表示になっているのかは結局謎のままですが、ドーターボードを載せ替えることができたりするので安全マージンを見ているのではないかと想像します。

以下は USRP-2922 の実際の計測です。

USRP-2922 SG 出力-15dBm

USRP-2922 SG 出力 -5dBm

USRP-2922 SG 出力0dBm：オーバーフローしています。

まとめ

USRP のフロントパネル表示は最大入力レベルは -15dBm となっていますが、実際には -5dBm 程度の信号は入力しても故障しませんし、データとしても問題ないことがわかりました。