Xillybusの「Hello, world」テスト
これは、 Xillybusを使い始めるための 3 番目のステップです。 Xillybus を含む bitstream は FPGAに既にロードされており、 driver は hostにインストールされています。ここで、簡単なテストを行います。このテストの目的は、 device files が作成され、動作することを確認することです。
このページでは、 Linux host上の Xillybus について説明します。 Windowsについても同様のページがあります。
ここでは Xillybus と PCIe に焦点を当てますが、 XillyUSBでもすべてがほぼ同じです。相違点はこのページの下部に記載されています。 Xillinuxに関しては、 PCIeに直接関連するトピックを除き、すべてが同じように機能します。
このトピックの詳細については、 Getting started with Xillybus on a Linuxを参照してください。
PCIe device は検出されていますか?
最初に確認することは、コンピュータが FPGA を PCIe deviceとして認識していることです。この目的には、「lspci」コマンドを使用します。このコマンドは、コンピューターが PCIe busで検出したすべての devices を表示します。場合によっては、非常に長いリストになることもあります。
たとえば、 Xilinx / AMD FPGA上の Xillybus の場合:
$ lspci [ ... several lines ... ] 01:00.0 Class ff00: Xilinx Corporation Device ebeb [ ... several lines ... ]
Intel FPGA (Altera)の場合:
01:00.0 Class ff00: Altera Corporation Unknown device ebeb
お使いのコンピューターでは、出力が若干異なる場合があります。重要な部分は「ebeb」です。これは Xillybus deviceであることを示す Device IDです。
lspciの出力にそのような行がない場合、 FPGAに何らかの問題があります。多くの場合、その理由は、どの bitstream が FPGAにロードされているかについての混乱です。
driver は正常に起動しましたか?
次のステップは、 driverのステータスを確認することです。最も簡単な方法は、 kernel logで「xillybus」という単語を検索することです。例えば：
$ dmesg | grep xillybus
xillybus_pcie 0000:01:00.0: can't disable ASPM; OS doesn't have ASPM control
xillybus_pcie 0000:01:00.0: Created 5 device files.
出力の形式は、コンピューターによって異なります。 ASPM に言及している行は正常であり、エラーを示していません。しかし、そのような行がなくても構いません。
「Created 5 device files」という行は、 driver が Xillybusを正常に初期化したことを示しています。この行がない場合、 driverの初期化に問題がありました。
kernel log に Xillybusに関連する他の行がある場合は、何が問題なのかを説明するのに役立ちます。これは通常、 FPGAの logicの問題です。特に、これは FPGA 内の PCIe block が正しく構成されていない場合に発生する傾向があります。たとえば、 demo bundleで PCIe block のパラメーターを変更した場合、 driver が正しく初期化されない可能性があります。
kernel logに "xillybus" という単語を含む行がなく、 lspciの出力に "ebeb" を含む行があった場合はどうなりますか?これは、 driver が kernelにロードされていないことを意味します。次のように lsmod でこれを確認します。
$ lsmod | grep xillybus xillybus_pcie 16384 0 xillybus_core 28672 1 xillybus_pcie
この例は、 driver が kernelにロードされたときの正しい出力を示しています。数値 (16384 と 28672) は異なる場合があります。 xillybus_class もこのリストに表示される可能性があります。
この driverをインストールしたばかりの場合は、コンピューターを再起動するか、 insmodを使用して手動で driver をロードする必要があることに注意してください。
「Hello, world」
driver は 5 つの device filesを作成します。 /dev/xillybus_read_8、 /dev/xillybus_read_32、 /dev/xillybus_write_8、 /dev/xillybus_write_32 、 /dev/xillybus_mem_8。 IP Core Factoryで custom IP core を作成する場合、作成する device files の数、およびそれらの名前とプロパティを選択できることに注意してください。
しかし現在、 FPGA には demo bundleが含まれています。 device filesの2台を試してみましょう。
read_8 と write_8の間の demo bundle に loopback があります。これは、コンピュータが data を write_8に書き込むと、 FPGA が read_8を通じてまったく同じ data を返すことを意味します。これはデモンストレーションのみを目的としています。この loopbackには他に実用的な用途はありません。
テストは次のとおりです。 コンピューターで 2 つの terminal windows を開きます。または、2 つの shell promptsを提供する他の配置を使用します。たとえば、2 つの ssh connections。
最初の shell promptで次のように入力します。
$ cat /dev/xillybus_read_8
次に、2 番目の shell promptで次のように入力します。
$ cat > /dev/xillybus_write_8
次に、2 番目の terminal に何か入力して、 ENTERを押します。同じテキストが最初の terminalに表示されます。これは、テキストが最初の device fileに書き込まれ、次に FPGAに到達し、最終的にコンピューターに戻った様子を示しています。
この例は単純ですが、その仕組みを理解することが重要です。特に、 FPGA の logic がどのようにこれを実現したかを理解することが重要です。これは、独自の logicを統合するための出発点です。
permission denied エラーが原因でこれらのコマンドが失敗した場合は、これを rootとして繰り返します。または、前述のように udev ファイルをインストールします。
XillyUSB
XillyUSBを使用している場合、上記のすべてが適用されますが、いくつかの違いがあります。
XillyUSB には、 FPGAとの物理的な接続の品質を調べるための showdiagnostics というツールがあります。 raw data link にエラーがないことを確認するために、このツールを使用することを強くお勧めします。 XillyUSB が完全に動作しているように見えても、このチェックを行うことが重要です。その理由は、 USB 3.0 protocol が raw data linkのエラーを隠しているためですが、これらのエラーは依然としてバグのように見えるまれな問題を引き起こす可能性があります。
この種のエラーを許容する理由はありません。多くの場合、解決策は簡単です。たとえば、コンピュータの別の USB plug を使用します。
その他の違い:
- lspciの代わりに lsusb を使用します。
- driverの modules は xillyusb であり、おそらく xillybus_classです。
- driverのインストール後にコンピュータを再起動する必要はありません。 device が USB plug に接続されると (切断された後)、 driver は自動的にロードされます。
- device files の名前は少し異なります。たとえば、名前は /dev/xillybus_read_8ではなく /dev/xillyusb_00_read_8です。 「00」の部分が異なる場合がございます。