これまで長い間、テストエンジニアは、LabVIEWなどのソフトウェアパッケージのメリットを利用して、RF計測器システムをカスタマイズし、従来のスタンドアロン型計測器を使用した場合と比較してコストを軽減してきました。この方法では柔軟性が得られるだけでなく、最新のPC、CPU、およびバステクノロジで実現される性能のメリットも活用できます。
にも関わらず、要件の厳しいRFテストアプリケーションの多くでは、CPUがボトルネックになる場合があります。CPUは本来、並列処理に制限があり、通常のソフトウェアスタックはレイテンシを発生させます。これにより、テストの刺激信号を計測データの値や検査対象装置 (DUT) の状況に基づいて動的に調整する必要がある場合に、テストシステムの性能を低下させる可能性があります。最適なRFテストシステムの性能を実現するには、カスタム計測器ハードウェアをマルチコアCPUテクノロジと組み合わせることが望まれます。そうすることによって、低遅延と高スループットのバランスを取り、テスト時間を大幅に短縮できるようになります。
従来、市販の計測器ハードウェアの機能は固定ですが、NIはよりオープンで柔軟性に優れた計測デバイスをFPGA (Field-Programmable Gate Array) テクノロジに基づいて供給するという道を切り開いています。要するに、FPGAとは、ユーザがカスタマイズできる高密度のデジタルチップで、カスタム信号処理/制御アルゴリズムを計測ハードウェアに直接組み込むことができるものです。その結果、固定の高品質計測テクノロジと、品質が保証された最新型のトレーサブルな計測の両方のメリットを活用した、市販品のRFハードウェアが生まれました。さらにこのハードウェアでは、ユーザがカスタマイズ可能なロジックも組み込まれ、高度な並列処理と低遅延が可能となり、I/Oと直接的に結び付いて、インライン処理と緊密な制御ループが実現します。
このハードウェアの例が、NIベクトル信号トランシーバ (NI VST) です。このデバイスは、ベクトル信号発生器の機能とベクトル信号アナライザの機能を兼ね備えているのに加え、ユーザがプログラム可能なFPGAも含まれており、リアルタイム信号処理/制御が可能です。FPGAの柔軟性が追加されたVSTは、カスタムトリガ機能、DUT制御、並列計測、およびリアルタイムデジタル信号処理 (DSP) に最適です。
FPGAはカスタムボード設計と市販デバイスの一部としての両方に幅広く使用されているものの、ユーザがカスタマイズ可能なFPGAは、これまで市販のRF計測器には広く採用されてはいませんでした。これは主に、これらのデバイスのプログラミングに必要な専門知識が原因でした。ハードウェア記述言語 (HDL) は一般的に習得が難しく、その使用はデジタル設計専門家に限られています。
LabVIEW FPGAモジュールでは、エンジニアや研究者などの幅広い層が最新のFPGAテクノロジを使用できます。グラフィカルプログラミングを使用すれば、ハードウェア内のRF計測器の動作を定義するロジックを実装できます (図1)。実際、LabVIEWのグラフィカルデータフローという特性は、FPGAで実装可能な並列処理のタイプを実装/可視化するのに適しています。LabVIEWでFPGAをプログラミングするには異なる知識が必要となりますが、HDLに比べると習得の難易度が大幅に低くなります。
図1:NI LabVIEW FPGAモジュールを使用すれば、使い慣れたLabVIEWコードを使用して計測器ハードウェアをカスタマイズできます。RFアプリケーションの場合、あらかじめ作成されたサンプルプロジェクトを初めに使用してから、カスタムトリガ機能、DUT制御、信号処理などの変更を追加できます。
複数のLabVIEW FPGAサンプルプロジェクトが、RFアプリケーションのスタートポイントとして用意されており、NI VSTなどのデバイスで使用できます。特に、計測器のデータ移動パラダイム (カスタマイズ可能な開始、停止、および基準トリガ機能をベクトル信号アナライザ/発生器と類似したインタフェースで表示) やストリーミングパラダイム (インライン信号処理や記録/再生アプリケーションに最適) に従ってFPGAをカスタマイズできます。
RF計測システムのFPGAベースハードウェアを活用すれば、低遅延のDUT制御からCPUの負荷軽減まで、数多くのメリットを得ることができます。以下のセクションでは、さまざまなシナリオで得られるメリットを詳しく説明します。
RFテストシステムの多くでは、制御下にあるデバイスやチップは、デジタル信号およびカスタムプロトコルで制御する必要があります。従来の自動テストシステムにはDUTモードで順序付けを行う機能があり、必要な計測を各段階で実行していました。場合によっては、自動テスト装置 (ATE) システムが組み込まれていて、受け取った計測値に従って、DUTの設定を変更していくという場合もあります。
いずれのシナリオでも、FPGAを組み込んだソフトウェア設計型計測器を使用することで、コスト削減と時間の短縮につながります。計測処理機能とデジタル制御機能を1つの計測器にまとめることによって、システムにデジタルI/Oを追加する必要性が減り、計測器間のトリガを構成する必要もなくなります。受け取る測定データに応えてDUTを制御する必要がある場合、ソフトウェア設計型計測器はハードウェア内で閉ループ制御が可能なため、大幅な遅延時間を発生させてソフトウェア側で判断を下す必要が減ります。
現在のソフトウェアベースのテストシステムでは、並列処理で可能な計測の実行数には制限がありますが、ソフトウェア設計型計測器では、使用可能なFPGAロジックでのみ制限されます。真のハードウェア並列処理が可能になるため、データチャンネルの数が多い計測も一度に行うことができ、計測対象を選択する必要もなくなります。高速フーリエ変換 (FFT)、フィルタ処理、変調/復調などの処理機能はハードウェアに実装できるので、CPUに転送して処理する必要があるデータの量は減ります。ソフトウェア設計型計測器を使用すれば、リアルタイムスペクトルマスクなどの機能が、従来のスタンドアロン型計測器に比べて大幅に高いレートで実現します。
さらに、ハードウェアで計測を実行することによる低遅延とは、標準テストシステムで計測を1つ実行するのと同じ時間で、多数のリアルタイムの計測を一斉に実行して平均値を取ることができるということです (図2)。これによって、RF計測のテスト結果の品質と信頼性が向上します。さらに、計測はハードウェアで連続して実行し、ホストテストアプリケーションから定期的にサンプリングできるため、重要なデータを逃すことがなく、確実性が増します。
図2:ソフトウェア設計型計測器を使用すれば、集録プロセスを停止して情報を転送することなく、データを連続的に集録して計測を実行 (定期的なサンプリングの結果を取得) することができます。
RFテストの特定のクラスでは、DUTの設定や環境、製造プロセスの量は受け取る計測データに従って変更することを求められます。これには、閉ループシステムが必要となりますが、このシステムはソフトウェアスタックの遅延によって制限されることがよくあります。多くの場合、ハードウェアでこの閉ループ制御を実行することができるので、CPUで次の設定ポイントを計算する必要がなくなります。これによって、閉ループテスト時間を数十秒から、コンマ1秒単位へと短縮できます。
従来、低遅延のトリガの動作のオプションは使用されている計測器ハードウェアによって固定されてきました。しかし、ソフトウェア設計型計測器を使用すれば、カスタムトリガ機能をデバイスに組み込んで、対象となる状況にすばやく焦点を絞ることができます。柔軟なハードウェアベースのトリガ機能を実装することで、カスタムスペクトルマスクやその他の複雑な条件を実装でき、重要な計測データをキャプチャする、あるいは他の計測器をアクティブ化するといったことが可能となります。また、ハードウェアで対象データを選択することによって、CPUを解放し、その他の重要なタスクに使用することができます。
この技術資料では主にRFテストに焦点を絞っていますが、設計段階とテスト段階でIPを再利用するエンジニアが増加しています。これによって、市場投入までの時間とテストの全費用が大幅に削減できます。LabVIEW FPGAを使用して、デジタル信号処理アルゴリズムを定義し、デバイスまたはコンポーネントの検証の一部として再利用できるため、最初からテストコードを生成する必要がなくなります。したがって、テスト開発が確実に促進され、設計サイクルのより早い段階でテストが可能になり、テスト範囲をより確実なものにできます (図3)。
図3:IPを設計段階とテスト段階で再利用できるため、テスト開発時間を短縮し、テスト範囲をより確実なものにできます。
ベンダ定義の計測器や機能が固定された市販計測器は、今後も数年間は販売が続けられるでしょう。しかし、RFデバイスの複雑性と市場投入までの時間に対するプレッシャーが増したことにより、ソフトウェアベースの計測器システムが台頭してきました。こうした傾向が続けば、ソフトウェア設計型計測器が近い将来、RFテストや一般的なテスト計測器でますます重要な役割を果たすことになります。
ソフトウェア設計型計測器は、市販のハードウェアによって、現時点において可能な限り高いレベルの柔軟性、性能、および将来的な保証を実現します。システム要件が変わっても、ソフトウェア設計型計測器では、異なるモジュール式I/Oすべてに対してソフトウェア投資が維持されるだけでなく、既存のI/Oをアプリケーションに従って手元で変更することも可能です。