イゼルローン日誌

・github copilotが制限に達したというメッセージが出てきた。ちょっとチャットでいじめ過ぎたか。
・ところで似たようなものは無いのかなと思って探していたらCodiumというのがあって、これとVSCodeを一体化したVSCodiumというものがあるのを知る。
・アプリセンターにあるのかなと検索したらあったのでインストールしてみた。さて、どんなものだろう。
・とりあえず、日本語化はプラグインというのかエクステンションでjapaneseで検索してインストールしたら簡単にできた。
・あとはvimとVerilog用のエクステンション類をちょっと揃えて・・・と

---

・という感じでシミュレーションは通ったのでQuartusに食べさせてみる。ピンアサインして合成して書き込んでRaspberryPiからアクセスしてみる。
・一瞬「？」となった動きが合ったけど、あぁなるほど。RaspberryPi側から送っているプログラムがそうなっているわけで、FPGAは正しく動いていた。
・いいじゃないか、いいじゃないか。

---

・とりあえずMode0で動かしてやるというところで、テストベンチも書いていく。しかし、テストベンチまで勝手にコード補完するのはどういうんだろうな。とりあえず止めておくか。
・こんなもんかな？というのができたので動かしてみるとなんか変。じっと見ていくと、Copilot君がSPIのクロックを同期化している部分のコード生成を眺めると
　assign spi_rising_edge = (SPI_CLK ==1) && (spi_clk_d == 0);
　assign spi_falling_edge = (SPI_CLK ==1) && (spi_clk_d == 0);
...
always(posedge CLK, negedge RST_n) begin
.....
spi_clk_d <= CLK;
....
end
...
always(posedge CLK, negedge RST_n) begin
.....
if (spi_rising_edge == 1) begin
....
end
....
end
　なんていう間抜けなことをしている。そりゃだめでしょ。
　他にもちょこまか変なところがあったりしたので手直し。まぁそんなもんだよな。
・というところで、なんとなくシミュレーションで動くようになってきた感じ。

---

・というところで、FPGA側のSPI周りを書いていく。
・新規のワークスペースを作ってVSCodeで書きかけたら例によってCopilotが勝手に補完してコード生成された。
・しかし、この情報って全部MSに筒抜けてるんだよなぁ。まぁ大したコードは書いてないけど。
・ざっと見てみるとある程度それっぽいけど、どうなのかな。一応要らなそうなところを削ったり、必要なところを足したりとゴタゴタ。

---

・そんなところでRaspberryPi上のSPIインターフェースを動かそうというところ。
・いつものように検索してみるけど、具体的な使い方が今ひとつピンとこない。どこからかのコピペで動かしたら動きました的なものばかりだな。
・まぁ、しょうがない。とりあえずraspi_configはしてSPIインターフェースを許可して、ダメ元でＧeminiだのＣhatGPTだのCopilotだのに生成AIにお問い合わせしてみたら、いきなりコード生成された。
・これ本当に動くのか？とRaspberryPiのvi上にコピペして眺めてみたけど、なんとなくそれっぽい。とりあえず送信データサイズやら配列の扱いでちょっと気になった点があったのでそこだけ手を加えてccして動かしてみたら一応データを送っている感じ。受信データは0になるな。ならばとMISOとMOSIを直結してデータを送ってみたらちゃんと１バイト遅れでデータが受信できている。
・いいじゃないか、動いているんじゃないか。
・これまた念の為にとロジックアナライザをつないでテストしてみる。いいじゃないか、ちゃんとCE0#をアサートしてクロックとデータが出てきている。
・あとはこいつの相手をするFPGA側だな。

---

・さて、いろいろ再開で今日は片道15分ほどの坂道２往復。夕方歩数を見たら4500歩ちょっと。意外といかないものだな。
・先日日帰り温泉に行った時に体重を測ったら退院したときからほとんど変化ない。ちょっと気になって巻き尺でサイズを測ったらちょっとびっくりサイズ。
・そんなところで、今度はRaspberryPiの小さいやつ。持ち運んでデバッグしやすいようにUSB接続でログインできるようにできないかなと思ったらやっぱりやっている人がいる。明日からこいつの環境を整えよう。とりあえず週末までにはなんとかなるか。

---

・ということで更に諦めずにあれこれやったのだけど結果は芳しくない。やっぱりTXE#は延々とトグルし続けてしまうのは治らない。ということでこれは諦めろということなのかな。
・FT_GetQueueStatus()してキューのサイズを眺めると、ずっとFULL状態(65536バイト）で変わらないので、延々と受信しているのは確かだな。
・いったんFT_Close()するとこの延々トグルは止まるので、FT232H側は悪くないんだろう。となれば、LinuxのD2XXドライバがフロー制御をせず、延々と受け取っては捨てるということを繰り返しているという話になるか。
・検索しても同じような不具合を報告している例は見つからない。やはりFT232H+SynchronousFIFO+Linuxという組み合わせがレアだったりするのかな。
・あるいは、そもそもデータ転送開始のタイミングでホストは受信待ちになっているし、転送サイズは限定されているし、64Kバイトもあるバッファがオーバーフローするほど遅いこともまず無いから気づいていないという可能性もあるのかな。
・直接調べるならUSBバスアナライザで調べるしかないのか。そういえば昔ゲットしたものもあったなぁとか思いながら検索してみたらUSB2.0までなら7000円程度で高速バスプロトコルアナライザー USBスニファー 2.0 オープンソース ポータブルパケットスニッフィングツール ネットワークデータキャプチャ用なんていうのが売られているのか。口コミはないし、人柱になるかどうかちょっとお悩み。
・まぁ、とりあえず暫定的にこちらからFT_Write()したら送信許可にして、予め決めたサイズ分送信したらストップという具合にFPGA側を書き換えて実験したらちゃんと動いた。まぁ、今回はこれで良しとするか。

---

・昨日の続きで調べていく。
・やっぱり変なのは受信していないのに、FPGAが延々と送信し続けているところ。最初はFPGA側のミスかと思ったのだけど、ソースを見てもおかしなところはなくて、シミュレーションしてみてもそんな変な挙動をするところはない。
・これはロジアナで調べたほうが早いかというところだけど、そういえばSignalTapがあったなということで、組み込んでみる。
・データが暴れだしたらトリガということで待ち構えてやってみたら、こんな感じ。
・Readなんかしていないのに、オープンしたらTXE#がアサートされる。つまり、送信バッファが空だと言っている。このおかげでFPGA側は延々とダミーデータを送っている。
・これだけなら、FT232Hの内部バッファなりD2XXドライバのバッファにたまるだけで、しばらく放っておけば収まるのかと思ったけどそういう気配もなくアサートされっぱなし。
・ちなみにFT_READかけて読み出ししても、読み終わった後はやはりこんな感じ。
・これだと、USBホスト側が受信しきれずにいるということは許されないという話になる。TXE#がアサートされているのだからどんどんデータを送るけど、実はホスト側は受け取っていないということが普通に起きてしまうのだから。
・さて、どうしたものか。

・そんなこんなでFPGAも結構いい感じで動き出していてちょっと遊べている。
・ホスト側のテストプログラムを変更して、オープン、初期化、クローズ、リード、ライトなどをコマンドで行うようにして、DE10側ではLEDで転送カウンタやデータなどを表示するようにしてテスト。
・ライト方向で送信したはずのデータ数より１バイト少なく表示されるけど、最後に送ったデータは合っている。１バイトだけ送ると送られていないような挙動。
・リード方向もなんか変でちゃんと読めたり読めなかったり。一度読めるようになるとそれなりな挙動なんだけどな。
・もう少し調べよう

---

・ちょいと都心方面に用があって電車を使ってみる。
・しかし・・・だ。意外と電車賃もかかるものだな。
・久しぶりというのかずいぶん長らく使っていなかったSuicaにチャージしたけど、あまりいれっぱなしでもJRの「預り金」勘定になるだけか。適当に使ったほうが良いかな。
・ということで、席が確保できたので道中ノートPCを広げて軽くプログラミング。なんとなく立っている人が手元に視線を送っているような気がしたけどタッチタイプがそんなに気になるのか、あるいはキーボードの上に敷いている100均の布で作ったキーボードカバーが気になるのか。

---