Xillybusの「Hello, world」テスト
これは、 Xillybusを使い始めるための 3 番目のステップです。 Xillybus を含む bitstream は FPGAに既にロードされており、 driver は hostにインストールされています。ここで、簡単なテストを行います。このテストの目的は、 device files が作成され、動作することを確認することです。
このページでは、 Windows host上の Xillybus について説明します。 Linuxにも同様のページがあります。
ここでは PCIe で Xillybus に焦点を当てますが、 XillyUSBでもほとんど同じです。相違点は、このページの下部に記載されています。
このトピックの詳細については、 Getting started with Xillybus on a Windowsを参照してください。
PCIe device は検出されていますか?
Device Manager は、検出された PCIe devices を示します。これは、 driverのインストールのコンテキストで以前に説明されました。
driver がインストールされる前は、 Xillybusの device が「Other Devices」のリストに表示されていました。インストール後、この device は「Xillybus」というグループに表示されます。 Device Manager がこれら 2 つのオプションのいずれも表示しない場合、 FPGA は PCIe deviceとして検出されません。 FPGAに問題がある可能性があります。多くの場合、その理由は、どの bitstream が FPGAにロードされているかについての混乱です。
screenshots と、 Getting Started guide for Windowsのこのトピックに関するより詳細な説明があります。
driver は正常に起動しましたか?
次のステップは、 driverのステータスを確認することです。これは Device Managerで行われます。 Xillybus グループの icon を右クリックします ( device の名前は「Xillybus driver for generic FPGA interface」です)。 「Properties」を選択。 pop-up window が登場します。 「Device status」というタイトルの text window を見てください。そこにあるテキストは「The device is working properly」である必要があります。これは、 driver が Xillybus を正常に初期化し、必要な device filesを作成したことを意味します。
テキストにそれ以外のことが書かれている場合、 driverの初期化中に何か問題が発生しました。これは通常、 FPGAの logicの問題です。特に、これは、 FPGA 内の PCIe block が正しく構成されていない場合に発生する傾向があります。たとえば、 demo bundleで PCIe block のパラメーターを変更した場合、この種のエラーが発生する可能性があります。
この問題の詳細については、 Windowsの Event Viewerを参照してください。 Xillybusの driver からのメッセージはフィルタリングできます。 「Xillybus」というソースからのメッセージを表示する custom view を作成します。これを行う方法は、 Getting Started guide for Windowsで詳しく説明されています。
「Hello, world」
driver は 5 つの device filesを作成します。 \\.\xillybus_read_8、 \\.\xillybus_read_32、 \\.\xillybus_write_8、 \\.\xillybus_write_32 、 \\.\xillybus_mem_8。 IP Core Factoryで custom IP core を作成する場合、作成する device files の数、およびそれらの名前とプロパティを選択できることに注意してください。
しかし現在、 FPGA には demo bundleが含まれています。 2台の device filesを試してみましょう。これらの device files は実際には operating system objectsですが、通常のファイルのようにアクセスできます。 「\\.\」の部分は、 Windowsでの低レベルのプログラミングに慣れていない人にとっては奇妙に思えるかもしれません。ただし、これは通常、 user-space software (多くの場合 DLLs) がハードウェアにアクセスする方法です。
read_8 と write_8の間の demo bundle に loopback があります。これは、コンピュータが data を write_8に書き込むと、 FPGA が read_8を通じてまったく同じ data を返すことを意味します。これはデモンストレーションのみを目的としています。この loopbackには他に実用的な用途はありません。
テストは次のとおりです。 コンピュータで 2 つの Command Prompt windows を開きます。両方の Command Prompt windowsで、 directory を「precompiled-demoapps」に変更します。この directory は "xillybus-windowspack" directoryの中にあります。 demo bundleと一緒に xillybus-windowspack.zip をダウンロードすることを提案したことを思い出してください。
最初の Command Prompt windowで次のように入力します。
$ streamread \\.\xillybus_read_8
次に、2 番目の Command Prompt windowで次のように入力します。
$ streamwrite \\.\xillybus_write_8
次に、2 番目の Command Prompt window に何か入力して、 ENTERを押します。同じテキストが最初の terminalに表示されます。これは、テキストが最初の device fileに書き込まれ、次に FPGAに到達し、最終的にコンピューターに戻った様子を示しています。
これら 2 つのプログラムは、 CTRL-Cで停止できます。
これらのプログラムの source code は、 demoapps subdirectory (同じ zip ファイルから) にあります。プログラムは Cで書かれており、標準の I/O APIで Xillybusの device filesにアクセスする方法を示しています。 Getting Started guide for Windowsは、これらのプログラムの compilation を実行する方法を提案します。
この例は単純ですが、その仕組みを理解することが重要です。特に、 FPGA の logic がどのようにこれを実現したかを理解することが重要です。これは、独自の logicを統合するための出発点です。
XillyUSB
XillyUSBを使用している場合、上記のすべてが適用されますが、いくつかの違いがあります。
XillyUSB には、 FPGAとの物理的な接続の品質を調べるための showdiagnostics というツールがあります。 raw data link にエラーがないことを確認するために、このツールを使用することを強くお勧めします。 XillyUSB が完全に動作しているように見えても、このチェックを行うことが重要です。その理由は、 USB 3.0 protocol が raw data linkのエラーを隠しているためですが、これらのエラーは依然としてバグのように見えるまれな問題を引き起こす可能性があります。
この種のエラーを許容する理由はありません。多くの場合、解決策は簡単です。たとえば、コンピュータの別の USB plug を使用します。
その他の違い:
- device files の名前は少し異なります。たとえば、名前は \\.\xillybus_read_8ではなく \\.\xillyusb_00_read_8です。 「00」の部分が異なる場合がございます。
- Device Manager は、「Universal Serial Bus controllers」というグループの下に device を表示します ( driver がインストールされているかどうかに関係なく)。