イゼルローン日誌

・さて、QuartusでFPGAの内部FIFOのIPを使ってやろうと思ったけど、IPがあるとiverilogとかでのシミュレーションは難しいのか。
・なんとかQuesta（昔はModelSimだったのだけど）を動かさねばということで、チャレンジ
・Intel-Alteraのサイトからライセンスを取得して設定しなくてはならないのだけど、とりあえずマクニカさんのサイトがお役立ちだった。
・最後に得られたライセンスファイルがどこにあるかを環境変数に設定しないといけない。
SALT_LICENSE_SERVER="フルパスでのライセンスファイル名.dat"
を/etc/environmentに書き足してやれば良い。
・これでQuartusからTool=>Run Simulation ToolでQuestaが起動した。
・ところで、コイツラの本体は？と思って探したらどうやらQuartusのインストール先（~/altera_liteなど）の下を掘っていった先のquesta_fse/bin/vsim。
・で、ディレクトリを眺めていたら~/intelFPGAの下に20.1のディレクトリが残っていてこの下のmodelsim_ase_bin/にもvsimがあったので試しに起動してみたらそっくりさんが起動した。でもウインドウ上部のタイトルはModelSimになっている。全くの別物になったのかと思ったけど名前が変わった程度なのかな？

---

・Quartus23.1を使っていたのだけど、「お前のメインテナンスサブスクリプションは17日までだよ」としつこく言ってくる。そのまま使い続けられるのかどうかはわからないけど、使えるとしてもいい加減うっとおしいのでアップデートしてやることに。
・どうやらLiteエディションの最新版は25.1らしいので、こいつの.runファイルを落としてきて実行権を付けて実行。
・sudo付けないとだめかなと思ったけど、どうやら不要らしいのでそのまま実行。あとは基本的におまかせ。
・最後にアイコンは配置された。・アップデートしたら23.1は消されるのかと思ったけどそのまま残っている。つまり、複数バージョンが同居できるということか。
・で、25.1がメニューに登録されるのかと思ったけど、そちらは無い。
・これはどうしたら良いのかなとちょっとAIにお問い合わせすると、~/.local/share/applicationsの下に.desktopファイルがあるので追加すれば良いよとのこと。
・開くと確かにquartus23.1.desktopファイルがあるのでこれをquartus25.1.desktopにコピーして中身のパスなどを書き換えてみたらちゃんとメニューに現れた。
・起動してみたらちょっと起動画面の雰囲気が違っていたけど結局同じ使い方でそのままいける。わかってるなやっぱり。
・一応現行のプロジェクトをフォルダまるごとバックアップしてから、25.1で読み込ませてみたけどQuartusの設定ファイルのアップデートするよという程度のメッセージが出た程度でそのままいけてビルドしてProgrammerでの書き込みもOK。むしろ安定したような感じもするな。
・ちなみに23.1のアンインストールはどうするの？と思ったら、Quartusのインストール先にちゃんとアンインストーラが（QuartusだのQuestaだのに別れた）置かれていた。たぶんこれを実行すれば良いんだろう。

---

・そんなところでVSCodiumを入れたらAIな補完機能が動くのかなとおもったのだけど、どうもそういうものではないらしい。ただ、VSCodeと違ってオープンソースであることは利点なのか。
・一応整形機能とかが動かないと不便なのでVeribleをインストール。といっても、Veribleのリポジトリからダウンロードして展開。binディレクトリの下を/usr/local/binにコピーするだけ。ファイル名の先頭が共通（verible-verilog-なんちゃらかちゃら）なので、要らなくなったら消すのも難しくない。
・とりあえず、これで入れた後に「Verilog-HDL/SystemVerilog/Bluespec」あたりを入れたらフォーマッティングなどが動き出した。
・で、AI関係はと検索しているとどうもCodeium(eがついているのが微妙)というプラグインだったのが
Ｗindsurfという名前に変わっていたらしい。
・ただ、このＷindsurfがVSCodeの方のマーケットプレースの評価で「Kubernetesに大量のデータを送信しはじめた」なんていうことが書かれていたりもするけどどうなのかな？
・とりあえず、これと、あとはGoogleが提供しているGoogleのGemini Code Assistも入れておいてみようかな。
・というところで、やってみたら定番的なコード補完はやってくれるようになってきた。どんなものか眺めていくことにするか。

---

・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側を書き換えて実験したらちゃんと動いた。まぁ、今回はこれで良しとするか。

---