イゼルローン日誌

・ある程度動いたのでGPIOのデータをSPI経由で読めるように細工することに。
・SPIでの１バイト目がレジスタ番号とすると、２バイト目を読むときにはレジスタ値を用意しないといけない。SPIのクロックに同期させて動かしていると間に合わないしでどうしようかなというところで、とりあえず２バイト目をバイパスして３バイト目で８ビット分だけ読むように書いてみたら動いたようだ。
・さて、次はどうしたものかな。書き方は思いつくけどちょっと格好悪い。もう少し格好良く綺麗にいかないものかと考え中・・・考え中。

---

・いままでダミーデータをセットしていたロジックを分離して信号を外に引き出さないといけないな。ここはサブモジュールとの間なのでイメージ的にはケーブルのつながったモジュールがズルズル・・・引きずり出す感じ。
・なんとなくうまくいったので今度はSPI
・こちらもサブモジュール化した上でトップモジュールに取り込み。手慣れた感じだな。
・さて、こちらを試しているとなんだか結構な率でリードしたデータがおかしい。FPGAが受け取ったデータはエラーが無いし、シミュレーション上でも特にタイミング的に変なところもない。SPIなんてCS下げてから１クロックずつデータを送るだけなので、それほど悩むことではないだろう。
・とりあえず少しタイミングを調整したほうが良いかなということと、なんとなくいくつかSPIバス対応のセンサICなどを見ていると今使っているmode0ではなく、mode2やmode3を使っているものが多そうな雰囲気だったのでmode3を使うことに。これでだいぶ良くなったかな。
・そんなことをしていてふと、・少なくとも自分が使う範囲では結構自由に使えるようになったなぁと改めて思う。「書きなぐり」ができるようになったしな。目的がはっきりしていて毎日リトライを繰り返していけば学習していくというのはAIと同じか。
・合成は通るけどQuestaのシミュレーションではエラーを出すというのはなんだろうな。信号の宣言が使用される場所より後ろにあると駄目というのが典型的な場面だけど。

---

・とりあえずうまくいったように見えるので次はSPIバス側かなということで改めてチェック。
・以前どうやってたかなという感じ。RaspberryPi Zeroで毎回日付時刻が初期化されてしまうので、ls -lrtではどれが最新なのかわからないけど、中身を見て確認。
・これだなということでソースコードを見て、FPGA側のソースコードを見てという感じ。一瞬何をやっているのかと思ったけど、あぁという感じで思い出した。
・そうそう、SPIでCSされた時の先頭バイトの初期化を省略したから先頭バイトは前回最後に用意したダミーデータだな。
・さて、部品は揃った。あとは一気にやるだけ。

---

・昨日の続き。
・FPGAのドキュメントやらIPのドキュメントを眺めて色々やるのだけど、うまく行かなかったり改悪になったりして、そのたびにgit reset --hard HEAD@{0}の繰り返し。
・タイミング図やらシミュレーション波形をにらみながらやっていった結果、FIFOへの書き込み信号生成のステートマシンは自体はクロックの立ち上がりエッジで動かして、これで生成した書き込み要求（fifowrとでもしておく）を反転したクロックで取り込んで1/2クロックおくれたものを作る（fifowr_delayとでもしておく）
・で、FIFOのFULL信号（FIFO_FULLとでもしておく）がアサートされるまで書き込み要求信号をアサートするので
　assign fifowr_req = ~FIFO_FULL & fifowr & fifowr_delay;
てな具合で、立ち上がりをクロックの立ち下がりエッジに同期させておくという形。
・これで昨晩まで悩まされた10000回ループも問題なく動き出した感じ。
　今回はFULLになるまで連続書き込みなので、fifowrの立ち上がりより前にFIFO_FULLがアサートされるのが早いので幸いしているのだろうな。
・ということで、「アサートしはじめるのはクロックの立ち下がりエッジに同期させないとだめよ」という結論だな。

---

・ある程度動き出した感じだったのでテストプログラムを変更して連続リードライトをやってみると、また変な現象がでてきた。
・ダミーデータのライト部分で同じデータを２度書きしたような挙動になったりする。
・まぁ、私の分担範囲は読み出し側であり、そちらはちゃんと動いているようなので良いのだけど、なんだこれは。
・ということで、書き込み側のロジックを見直して、タイミングを少しいじってみたらなんとなく良い感じになったかな。
・100回程度なら良さそうなので10000回繰り返してみたらやっぱりおかしい。更に変なのは途中でFIFOがハングアップすることがあるようなこと。
・信号を外に引き出してLEDで確認すると（DE10LiteはLEDがたくさんあるのが助かる）FIFOがFULLではない状態でライト信号はアサートされたまま、リード信号はネゲートされたまま。つまり、読み出さずにひたすら書いているのにFIFOがFULLにならないという奇っ怪現象。もちろんクリア信号もアサートなんてされていない。なんだこれは。

---

・書き直してシミュレーションして修正というのを繰り返して、実機で確認するとちょっとおかしい。手を入れているうちにまたわからなくなってきたので、さっきの変更までgit reset --hardして復旧。
・改めて書き直してチェックしたら予定通り動き出して一安心。
・実機ではまだチェックできない挙動についてテストベンチをいじってチェックするとちょっとおかしい。
・こちらは、単純にムーア型のステートマシンで組んでいくとどうしても１クロック遅れる。すると、１クロック分余計に動いてしまうというのが原因だった。
・仕方ないので組み合わせロジックも組み入れてなんとか対処。まぁ、組み合わせる相手も一応クロックに同期しているはずなのでこれでも一応問題はないはず。
・しかし、git様様だな

---

・git branchで元に戻して動作確認、新規ブランチを切って・・・まずはFIFOを埋め込んで、そちらの動作を再確認。
・このFIFO、データシートの文章ではクロックの立ち上がりエッジに同期して使えば良いような書き方だけど、図ではリード、ライト信号などはクロックの立ち下がりエッジに同期させている感じで描かれている
・たとえば、FIFOのFULL信号は確かに立ち上がりエッジに同期して出力されるけど、これを次のクロックで検出してリード信号を落とすのではだめ。まぁ、そりゃそうなんだけど。
ということで、このあたりの信号はちょっと小細工しないといけないのだけど、ここがだめだったのかなぁ。一応シミュレーションではうまくいってたのだけど。
・まぁ悩んでいても仕方ないので、別の方法を考える。リードライト信号をクロックの立ち下がりで生成するブロックを本体のステートマシンから独立させて・・・と。
・これでFIFOのリードライトをするテストブロックを作って接続。シミュレーションは通った。さらに実機の７セグメントLEDに動作状態表示して動かしてみたら良い感じで動作した。ここまでは問題なし。

---

・なんとかなだめすかしてみようと思っているのだけど、うまく動かない。
・シミュレーションではそれなりなのに、実機にダウンロードして動かすとFIFOにデータが残ったままになったり、転送データ数がバラバラでどう解釈して良いのかさっぱりわからない。
・こういう隘路に迷い込んでしまった時の定跡は・・・元に戻ってやり直す。これが遠回りなようで一番の近道。
・ということで、git branchで元のブランチに戻して一応動作確認をしてから新規のブランチを作成してそこで作業することに。
・さっきまでのやり方だとハマることはわかったので別の方法を考えよう。

---

・家の前の道が工事で車の出入りが面倒なので、なんとか車で出た後、工事が一段落するであろう時間までイオンに避難することに。
・平日はガラガラのフードコートでノートPCを広げる。ここなら空調効いてるし、当然のように飲食自由だし（水で良ければ紙コップもある）。あとは電源があれば言うこと無いのだけどと思っていたけど、今日２時間ちょっと使っていてもバッテリ表示は99%から10%ほど落ちただけ。なんか前より持つようになっている感じだな。Linux（Ubuntu)のバージョンにもよるのか、動かしているアプリにもよるのか。
・しかし、平日は勉強している学生、なにかの資格試験の勉強をしているらしき方、外回りの仕事の合間にPCを広げているらしき方などいろいろだな。駅に近いからというのもあるのだろうかな。
・VSCodiumで、AIアシストとしてGeminiやらWindsurfとかを切り替えながらやってみているけど、今ひとつな感じ。そういえばとVSCodeに戻ってCopilotを使ってみたら明らかに自動生成の出来が良い。
・Geminiもそこまで頭悪いはずはないと思うのだけど、こういうのにはまだ不向きなのかな。

---

・とりあえずデザインしていたものにPLLに加えてFIFOを追加
・今までダミーデータを直接書き込んでいたのだけど、これをFIFOからのデータに差し替えてFIFOの制御も追加。
・Questaでシミュレーションしたらシミュレータ上では無事に動いている感じになってきた。明日実機でチェックしてみるか。

---

・というところで、原因がわかってきたかな。テストベンチでコメントアウトしていた範囲をどんどん絞っていったところで見つけたのはうっかりして複数ブロックから同じ信号に書き込みを行うというミス。これを修正したら動きだした感じ。
・なんでエラーにならないのかなど含め、いろいろ疑問符はあるけどまぁ解決したかな。他のコメントアウト箇所を戻しながら確認していこう。
・トランプ君がグリーンランドに対して随分と攻撃的になっている。彼には「北風と太陽」の話をしてあげるのが良いのかもしれない。多分それが一番「楽で良い」のではないかな。
・ついでに国内も選挙がらみでグダグダ。消費税は給与を消費税の課税対象として、たとえば250万円までは10%、250万円を超えて500万円までは超えた分について8%・・・とかいう具合に逆累進的な税率にすれば、消費税の逆進性を緩和しながら手取り額は増え、レジ改修なども不要で、しかも事業者の新規の税負担もなくて「楽で良い」と思うのだけどな。
・まぁ、給与に関しては「非正規が正規より安上がり」というのも変な話。たとえばレンタカーを借りっぱなしにする方が買うより安いという現象にあたる。これはやはりかなり割高になるようにしなくてはおかしいのではないのかな。

---

・市役所に書類提出。まったく面倒くさいこと。
・さて、合体をはじめるかということで、ベースになるソースがあるプロジェクトからソースをコピーしてファイル名、モジュール名を変更して、ここに他のものを付け足すかというところ。
・とりあえずAnalysis＆Synthesisが通ることは確認して、Icarusとverilatorでテストベンチでの動作も確認してQuesta起動。
・ところが波形が出ない。よーく見るとどうもエラーになっているらしい。
・IcarusでもVerilatorでも問題なくシミュレーションできるし、論理合成して実機でも動いたソースなのになぜ？
・よくわからないので、まずはロジックをごっそり削ってみたけど現象が変わらなくてエラーメッセージが出ている。
・ということで、原因はテストベンチかなということで、こちらもごっそり削除したらエラーが無くなって波形が出てきた。
・しっかし、シミュレータによってこんなに極端な違いがあって大丈夫なのか。

---

・さて、それではということで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は動いているようだけど、なんだかまだよくわからない挙動もある。ここは調べないとな。
・一応正月っぽいことはしたいなということで、雑煮を作る。本当はあれもこれも・・・と入れたいところだけど、あまり買い込んでいるものもないので、シンプルに済ませた。
・というところで、高尾方面の温泉に行ってみる。さほど混雑していなくてのんびり。

---