5SQ Zynq基板――GPT-6 Astra＋AMD Rossで独自IPを作成

引き続き、5SQ Zynq基板を使って、GPT-6 AstraとAMD RossによるFPGA開発を検証しています。

前回までに試したのは、Xilinxの既存IPをIP Integrator上へ配置したり、Zynq PSの固定ポートを利用したりする開発でした。

今回はもう一段進めて、独自のPL側IPを作成した場合に、どこまで自動的に開発できるのかを試しました。

対象に選んだのは、5SQ Zynq基板に搭載しているFT2232HQのBチャネルです。FT245非同期FIFOモードで動作させるIPを作成し、FPGA内部の回路だけでなく、FTDIの設定変更、テスト回路、PC側ソフト、実機デバッグまでまとめて行いました。

結果として、1時間は少し超えましたが、2時間以内に実機で動くところまで到達しました。以前なら数日はかかると考えていた作業です。

FT2232HQの空いているBチャネルを高速通信に使う

5SQ Zynq基板には、FT2232HQを搭載しています。

FT2232HQにはAチャネルとBチャネルがあり、AチャネルはZynqのJTAG接続に使っています。Bチャネルは通常UARTとして利用できますが、UARTでは通信速度に限界があります。

そこで今回は、BチャネルをFT245非同期FIFOモードに設定し、ZynqのPLとPCの間で、より高速なデータ転送ができないか試しました。

この機能は、もともと使いたいと考えていたため、基板の回路にも入れていました。しかし、実際に動かすためには、FPGA内部の回路だけを作れば終わりというわけではありません。

少なくとも、次の作業が必要です。

• FT2232HQの外付けEEPROM設定を変更する
• BチャネルをFT245非同期FIFOモードに設定する
• 設定変更後にUSBデバイスを再起動・再認識させる
• FT245の非同期FIFOインターフェースを制御するPL側IPを作る
• FPGA内部のテストパターン回路を作る
• VivadoプロジェクトへIPを組み込む
• 論理合成、配置配線、ビットストリーム生成を行う
• Zynqへ書き込んで実機動作を確認する
• PC側の送受信ソフトを用意する
• PCとFPGAの間でデータ転送を試験する

今回は、これらをGPT-6 AstraとAMD Rossに進めてもらいました。

最初に与えた主な資料は回路図

今回、最初にChatGPTへ与えた資料は、主に5SQ Zynq基板の回路情報です。

ZynqとFT2232HQが、どの信号で接続されているかを回路図から読み取らせました。独自IPの完成仕様書や、詳細なHDL設計書を先に用意したわけではありません。

こちらから指定した主な条件は、次のようなものでした。

• FT2232HQのBチャネルを使用する
• FT245非同期FIFOモードで動作させる
• PL内部とのデータ受け渡しにはAXI4-Streamを使用する
• 実機で送受信できるところまで確認する
• 作成したソースファイルを指定したディレクトリへ保存する

指示は基本的に日本語で行いました。

5SQ Zynq基板はUSBでPCへ接続してあり、JTAG書き込みやデバッグができる状態にしていました。

IPを作るだけでは終わらない

今回の検証で面白かったのは、AIがHDLソースを生成しただけではなかったことです。

FT245非同期FIFO通信を動かすためには、複数の作業を関連付けて進める必要があります。

まず、FT2232HQのBチャネルをUARTからFT245非同期FIFOモードへ変更するため、外付けEEPROMの設定を書き換えます。

設定を変更した後は、一度USBデバイスを再起動し、新しいモードで認識させる必要があります。

そのうえで、ZynqのPL側には、FT245のデータバスや制御信号を扱うIPが必要です。さらに、動作確認のためのテストパターン回路も作成しなければなりません。

FPGA側が動いても、それだけでは通信を確認できません。PC側にも、FTDIデバイスを開いてデータを送受信するテストソフトが必要です。

今回は、この一連の作業がほぼ連続して進みました。

• FTDI EEPROMの設定変更
• USB接続の切り替えと再認識
• PL側IPの作成
• AXI4-Streamとの接続
• テストパターン回路の作成
• Vivadoプロジェクトへの組み込み
• ビルドエラーの確認と修正
• ビットストリームの書き込み
• PC側テストソフトの作成
• 実機でのデータ転送確認

単に「IPを生成した」というより、IPを実際に使える状態へ持っていくところまで作業した、という方が近いと思います。

以前作った回路を再利用できた可能性もある

FT245非同期FIFOのインターフェースは、以前に一度作ったことがあります。

そのときはAMD Rossを使っておらず、何度かエラーを確認しながら、ChatGPTとのやり取りを繰り返して完成させました。

今回は、そのときの設計や知見を再利用できた可能性があります。完全にゼロからすべてを作ったのか、以前の成果物をどこまで参考にしたのかは、作業ログを確認して切り分ける必要があります。

ただ、前回と比べると、今回は途中で人間が細かく介入する場面がかなり少なく、ほとんどそのまま実機デバッグまで進みました。

GPT-6 Astraの能力によるものなのか、AMD RossがVivadoの操作やエラー修正を支援した効果なのか、以前の成果物を再利用できた効果なのかは、今回の結果だけでは明確に分けられません。

実際には、これらが組み合わさっていたと考えています。

PC側ソフトを含めて実機確認まで進んだ

今回特に大きかったのは、FPGA側だけで作業が終わらなかったことです。

FT245非同期FIFOの動作確認には、PC側から実際にデータを送受信する必要があります。そのため、PC側のテストソフトも用意してもらいました。

FPGA内部ではテストパターンを生成し、PC側ソフトから送受信結果を確認しました。

USBデバイスの設定変更、FPGAのビルド、書き込み、PC側プログラムの実行という異なる作業をつなげて、最終的に実機で確認できたことが重要でした。

これまでは、それぞれの作業で問題が出るたびにログをコピーし、ChatGPTへ貼り付けて、修正箇所を確認していました。

今回は、エラーが発生しても作業の途中で調査と修正が進み、人間が何度もログを受け渡す必要はほとんどありませんでした。

自動デバッグが始まっている、と感じた部分です。

人間が指定・確認した部分

今回、私が最初に決めたのは、主に次の内容です。

• FT2232HQのBチャネルを高速通信用に使う
• FT245非同期FIFOモードを採用する
• FPGA内部ではAXI4-Streamへ接続する
• 5SQ Zynq基板の回路情報を作業の基準とする
• ソースファイルを指定ディレクトリへ保存する
• 実機で通信できるところまで確認する

作業後には、指定したディレクトリに保存されたソースファイルを開き、内容も確認しました。

生成されたコードは、少し読みにくいと感じる部分がありました。ただし、確認した範囲では動作結果と矛盾するような大きな問題は見つかりませんでした。

もちろん、実機で一度動いたことと、製品へそのまま組み込める品質であることは別です。

長時間の連続通信、さまざまなデータ長、FIFOのフル・エンプティ処理、USB切断からの復旧、クロック境界、タイミング制約などは、今後さらに確認する必要があります。

数日を想定した作業が2時間以内で動いた

このインターフェースは以前から作りたいと考え、回路には入れていました。

しかし、実際に取りかかれば、FPGA側のIP、FTDIの設定、PC側ソフト、実機デバッグまで含めて、数日はかかるだろうと思っていました。

今回の作業時間は、1時間を少し超えましたが、2時間以内でした。

これは厳密な比較試験ではなく、私自身の過去の開発経験との比較です。また、以前作った設計が再利用された可能性もあるため、「常に数日分の作業が2時間になる」と断定することはできません。

それでも、回路図と日本語の指示から始まり、独自IP、PC側ソフト、実機デバッグまで一つの流れで進んだことには驚きました。

FPGA開発がかなり楽になったという実感があります。

独自IP開発でも自動化が進み始めた

前回までの検証は、既存IPやZynq PSの固定ポートを利用する内容でした。

今回は、自分の基板に必要な独自IPを作り、周辺デバイスの設定を変更し、PC側ソフトまで用意して、実機で通信を確認しました。

まだ、生成された回路を無条件に採用できる段階ではありません。ソースコード、タイミング制約、クロックドメイン間の処理、例外条件、転送データの完全性などは、人間が確認する必要があります。

それでも、GPT-6 AstraとAMD Rossを組み合わせることで、独自IPの作成から実機デバッグまでが一続きの作業になり始めました。

これまで人間がツール間を移動しながら行っていた作業を、AIがまとめて進めるようになっています。

今回の検証では、「HDLを書かせる」だけではなく、「回路を実機で動かす」ところまで自動化の範囲が広がっていると感じました。

次は、転送速度、長時間動作、異なるデータパターン、エラー処理などを試し、独自IPとしてどこまで実用化できるかを確認していきます。

English Summary

This article describes an experiment in which GPT-6 Astra and AMD Ross were used to create and test a custom FPGA IP core for the 5SQ Zynq board.

Previous tests mainly used existing Xilinx IP blocks in IP Integrator or fixed Zynq PS interfaces. This time, I wanted to determine whether the same workflow could handle a custom PL-side interface.

The target was channel B of the FT2232HQ device on the board. Channel A is used for Zynq JTAG, while channel B can be configured for asynchronous FT245 FIFO operation to provide faster communication than a conventional UART.

The initial input consisted mainly of the board schematic and the connection information between the Zynq device and the FT2232HQ. I specified that the PL-side interface should use AXI4-Stream and that the workflow should continue through actual hardware testing.

The work involved more than generating HDL. It included changing the FTDI EEPROM configuration, restarting and re-enumerating the USB device, creating the PL-side interface IP, integrating it into the Vivado project, generating a test-pattern circuit, building the FPGA design, writing the bitstream, creating PC-side test software, and confirming data transfer on the physical board.

A similar interface had been developed previously, so some earlier work may have been reused. It is therefore difficult to separate the contributions of GPT-6 Astra, AMD Ross, and the existing design. However, compared with the earlier development, very little manual intervention was required this time.

The complete process took slightly more than one hour and less than two hours. This is an experiential comparison rather than a controlled benchmark, but I had originally expected the combined FPGA, FTDI, PC software, and hardware debugging work to take several days.

The generated source code still requires human review. Long-duration transfers, different packet sizes, FIFO boundary conditions, USB reconnection, clock-domain handling, timing constraints, and error recovery must also be tested before the IP can be treated as production-ready.

Even with those limitations, this experiment showed that AI-assisted FPGA development is moving beyond HDL generation toward integrated hardware and software debugging on a real board.