イゼルローン日誌

・さて、それではということでPLLも埋め込んでみた。実機に合わせて50MHzのクロックを入力して試しにPLLで３倍の150MHzを生成して内部ロジックを駆動してみる。
・これをQuestaでシミュレーション。特別何もせずそのまま普通にシミュレーションしたら、ちゃんと波形が出た。うん、ちゃんと３倍になっている。
・で、実際に書き込んで動かしてみるとこれもOK。なるほどいい感じで動いてくれた。FIFOの動作もそれなりで動いていることがわかった。
・よし、これで部品の下準備はできたかな。あとはあれこれ合体させていくというところか。

---

・そんなこんなでQuestaでシミュレーションできるようになったのだけど、とにかく波形ウインドウの文字が小さすぎる。なんとか大きくならないのかと四苦八苦してやっと発掘
・Tool=>Edit PreferencesでBy WindowタブでWave Windowsを選択。ここでWave Fontのところでフォントを選択しなおしたら波形ウインドウの文字が大きくなった。

---

・Quartusがエラーになるというのか、Quartus自身がバイオレーション起こしたとかいうダイアログ出してコケる（一応落ちたりはしないけど）という現象がどうにもよくわからない。
・23.1で作っていたプロジェクトを読ませてやってみると無事に終了するので、ソースコードかプロジェクトの設定なのか。
・改めてプロジェクトを作成してソースコードをコピーしてきてやってみたけどやっぱりだめ。
・ソースコードをどんどん削って削って単純化していってもだめ。自分で書いたダミーFIFOがいけないのかと使わないように書き換えてもだめ。
・なんだかわからないまま、なんとなくソースコードの一覧の上下を入れ替えて最上位にトップモジュールを置いてみたら普通のエラーメッセージが出てきたので、verilatorで改めてエラー箇所をチェックして修正してからやってみたらなぜか無事にいった。
・Questaに食わせるテストベンチを指定してシミュレーションしても問題なし。
・でも、改めてソースコードの順番を入れ替えてもエラーにならない。
・ということで、本当の原因がこれだったのかはわからないけど、とりあえず結果よければ・・・か。git checkoutしておこう。

---

・さて、そんなところでVSCodiumを使っているのだけど、どうもVerilog/SystemVerilogのLint機能がうまく働かない。Verilog-HDL/SystemVerilog/Bluespec SystemVerilogは入れているんだけどなぁと思いながら、なんとなく設定らしきギヤのアイコンをクリックして「設定」を開いてみたらなるほどLintingのツール設定が必要なのか。
・ここをiverilogやらverilatorにしてみたらなるほどねということになったけど、lintingのプログラムによって、指摘のされ方が違うんだな。
・と、ここでverible-verilog-lintを選ぶとどうなるのかなと思ったら、既にインストール済みになっていたようでこれもOK。VSCodeのときはveribleをつかっていたので、とりあえずこれでやっていってみるか。
・というところで、Questaも無事に動いているようなのだけど、とりあず他に簡単なデザインを作って動作確認。使い方は検索しても手頃なのがなかなか見つからなかったけど、Gemini君に聞いたら教えてくれた。
・さて、とりあえず動かし方はわかったけど、Quartusが持っているIPを使ったデザインだとどうなるのかな。もう少しやってみよう。

---

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

---

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

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

---

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

---

・一応そんなこんなで謹賀新年である。
・今年は昨年のような入院騒動にならないことを望む・・・というところ
・一応年越しで書いていたFPGAは動いているようだけど、なんだかまだよくわからない挙動もある。ここは調べないとな。
・一応正月っぽいことはしたいなということで、雑煮を作る。本当はあれもこれも・・・と入れたいところだけど、あまり買い込んでいるものもないので、シンプルに済ませた。
・というところで、高尾方面の温泉に行ってみる。さほど混雑していなくてのんびり。

---