前の記事でも触れましたが、8月17日に「みかん箱」が15周年を迎えました。
現在・過去問わず、ご支援・ご声援ありがとうございます。


過去10周年の時にも書きました（当時の記事）が、
まさか10代の、右も左も怖さも現実も何も知らない　ガキ真っ只中の時に
ノリと勢いで作ったようなWebサイトが、色々あったものの、2021年現在
でも続いているとは全く思いませんでした。
当時の「2006年」から見たら、15年後の今「2021年」なんて遠い未来の
話ですし・・・。
いやー、サイト上でも、XOPS界隈でも、リアルの私生活でも、
この15年間 色々あったなぁ（遠い目

本当は色々思い出を語る場ではありますが、上記の10周年の記事に加えて、
既に比較的直近（？）で昔話を語っているため、割愛させて頂こうかと
思います。
例：
　・XOPSに出会ってプログラミングを始めた昔話（2020.09.20）
　・「みかん箱」の掲示板閉鎖について（2020.11.26）


冒頭に『2021年現在でも続いているとは・・』と書きましたが、
皆さんお気づきの通り、正直に言うと ここ数年は（サイトに対して）
積極的な活動・管理をしているわけではありません。
なので、決して「15年間サイト運営を頑張った」ではなく、
「時々触りつつダラダラしていたら、気が付いたら15年経った」
という表現が正しいぐらいです。
現に、今でもソフトウェアの公開（アップデート）は続けているものの、
追加ミッション（addon）の公開は、2014年8月17日（8周年の時？）を
最後に止まってますし（＾＾；

サイトについて何かを期待されている方がいれば申し訳ないですが、
今後、直近で何かサイトに直接関係する活動予定があるかと問われると、
はっきり言ってありません。
XopsAddonCreatorなどのソフトウェアのバージョンアップしたり、
あとはOpenXOPSオンラインの件がどうなるか分かりませんが、
例えば新作addonやその他コンテンツを公開するとか、ほか何かサイト
運営を頑張るみたいな予定や計画もなく、特に考えてもいません。

強いて強引にネタを絞り出すのであれば、作りかけで未公開のaddon
があるなぁ　とか、サイトのデザインが10年以上変わっておらず、
全体的にダサいなぁ　とか、いっそのこと英語版のページ並みに
シンプルな構成でも良いのではないか　とか思ったりもしなくはない
ですが、
（addonを出さない以外は）今のまま放置しても誰のデメリットにも
ならず、むしろサイト管理に時間を捻出するぐらいなら、OpenXOPS
などXOPS全体に還元されメリットに繋がる活動にリソースを割きたい
と思っているので、今後も何か積極的な活動はしないと思います。

ただ、去年11月に閉鎖した掲示板のように、サイト自体を潰して閉鎖
することはないと思っているので、当面（年単位）は このまま残す
つもりです。

そんな感じですが、今後ともよろしくお願いします。


サイトの話からは逸れますが、
この15年間の間でも自分自身 色々あって変化した通り、次の10年～15年
も今からさらに変化していくと思います。
色々な意味で、次の10年・15年を生き抜くことを考えなければなりません。

もう過ぎてしまいましたが、8月17日は「みかん箱」誕生15周年だった
のですね。今年は（今年も？）何もできませんでした。ごめんなさい。
15周年ということで思うこともありますが、次回以降 改めて書きます。


FPGAでのギガビット・トランシーバーによるGbps通信ですが、ゴール
（最終ゴールではなく、正しくは第一部のゴールで全体の中間地点）
が見えてきているものの、まだ最後が詰め切れていません。

今ある大きな課題は、
　１、初期化シーケンスがうまく行かない場合がある。
　２、FPGA内でデータが化ける場合がある。
です。


『１、初期化シーケンスがうまく行かない場合がある。』というのは、
前の記事でも触れた通り、通信を初期化する際に不規則に初期化処理が
コケて通信が開始できない場合があるのです。。

ロジックアナライザーやプロトコルアナライザーで解析する限りは、
FPGAから出てきている信号は正しい「はず」で、通信相手のデバイスが
決められた応答が返ってこない状況です。
状況的には「デバイス側の問題だ」と断定したいところですが、他の
メーカーのデバイスに交換しても、やっぱり動かないことがあるので、
問題発生の前後含め、何かしらFPGA側の信号に非があると考えられます。
こっち（FPGA側）は規格通りに動いているはずなんだけどなぁ。
んー謎だ。。よく分からん。


『２、FPGA内でデータが化ける場合がある。』というのは、FPGA側
の送受信処理時に通信データが化けたり、意図しない通信サイズに変化
してしまう（だいたい増える）現象が発生します。
前の記事では『特定のコマンドの組み合わせが通らない』と書きましたが、
これも中の通信データが化けることで、プロトコルとして成立しない
のが原因でした。

これは何となく原因が予想できており、おそらくプロトコルの制御部分
か、またはFPGA内に実装したキャッシュメモリーの挙動が怪しいのでは
ないかと思っています。
別途シミュレーションを実行しても問題なく、タイミング解析上でも
エラーは出ていませんが、
プロトコルとメモリーの制御周りのロジック動作が非常にシビアで、
わずかな信号・動作遅延により、プロトコルの入出力処理が崩れ、
メモリー内のデータが破壊されているのではないかと推測しています。

ただ、直すのは至難の業です。
一番単純な解決方法は、動作クロック周波数を（例えば倍に）上げて
1クロックあたりの実行ステップを減らすことで安定性を高めることですが、
FPGAの動作速度にも限界があり、これ以上動作クロックを上げることは
できなさそうです。
こりゃ、アーキテクチャ自体を見直さないとダメだろうか・・・。


おそらく上記１・２をクリアーすれば、（中間地点へ）無事ゴールできる
と思っていますが、
一方は全体の見直しが必要な可能性があり、もう一方は原因すら掴めて
いないので、ここから前進するのは難航するかもしれません。

XOPS関係など他にリソースを充てたい関係で、可能であれば8月中、
遅くとも9月中には、何かしらの目途を付けたいです。

なんか、いつもの休日とは異なる変な時間に起きてしまった。。

ここずっとハードウェアのFPGAネタばかり書いていたので、久しぶりに
他のネタ書きます。って言っても、独り言回ですが。


ソフトウェアのプログラミング関係については、活動の中心は依然として
XOPSで、XOPS関連活動は紛れもなく自身の中で最先端の技術・ノウハウを
投入しているのですが、
XOPS以外の世界・界隈はどんなものなのか、XOPS以外のゲーム界隈や
オープンソースのコミュニティを時々視察しています。
・・・・「視察」って言っても、言うほどのことはしていないですが。
ゲームの場合、普通の人が遊ぶような完成しきった商業作ではなく、
XOPSのように ある程度ユーザーメイドの文化があるコンテンツです。

人が多いコミュニティというのは発信される情報量も絶大で、24時間は
言い過ぎですが、常に誰かが何かをやっており、SNS上や公式コミュニティ
だけでも色々な作品・活動が上がり続けているような世界です。
ネット上に何かを配信・アウトプットしない人も多々いるでしょうから、
実際の活動人数はとてつもなく多いはずです。

2021年現在のXOPSのように、活動メンバーが非常に限られている世界とは
真逆で、とんでもない人数がいるため、どんな人がいてどんなことをやって
いるのか、全容は全く把握できません。
ここまでくると、把握する必要すらないのかもしれませんが（＾＾；

あとは、やはりXOPSとは文化が全然違ったり。


現在XOPSの世界にいる人間からすれば、とにかく人が多いコミュニティは
魅力的ではありますが、人が多いゆえに色々な人がいるため、問題もある
ようです。

見掛けた事案としては、
開発も有志で言わばワンオペによる1人運用にも関わらず、毎日のように
何かしらの問い合わせを受けており、毎晩のようにサポートやデバックに
追われているとか・・・。
マニュアルやダウンロードページには、「～についての問い合わせには
応じられない」との旨が書いてあるにも関わらず、公の場で開発元に質問
して、「日本語が読めないのですか？」とキレられているとか・・。
私はその界隈をよく分からないですが、比較的よくあるエラーでググれば
簡単に見つかる類（らしい）の問題を、やはり堂々と開発元に聞いてくる
とか・・。
もっと酷い場合だと、単に「なんか変なエラーが出ました」とだけ報告が
上がってきて、開発元が困惑（ってより呆れ）しているとか・・・。
ユーザー同士のトラブル・いざこざ も絶えない雰囲気だったり。

実年齢は不明で別ですが、精神年齢が幼い方もいるようで。
まぁ人が多い界隈・世界 特有の問題ですよね。

今だと全く想像できませんが、XOPSも ひと昔前（2006～2010年頃？）は
似たような雰囲気でした。
nine-two氏の元にどんな問い合わせが行っていたのか分かりませんが、
私の所にも、よく
「ezds.dllがないってエラーが出ました」
「オンライン版って、どうやって遊ぶのですか？」
「addonってどうやってプレイするのですか？」
「どうやったらXOPSのマップって改造できますか？」
みたいな問い合わせが来てました。
ユーザー同士のトラブルも、意図しない事故から　意図的に起こされた事件
まで、色々なパターンでちょくちょく起きてました。
ちょっと今じゃ考えられませんけど（遠い目


今のXOPS界隈は非常に落ち着いている（我ながらかなり良い表現ｗ）ので、
落ち着いて自分の作業に没頭できますが、
人が多いと人が多いで、色々問い合わせやトラブルも増えるんだろうなぁ
っと思いました。

「だから今のまま過疎状態で良い」とは微塵も思ってないですが。
これ以上人が増えるとも思っていませんけど。

ここ数日は殆ど晴れなかったので、涼しい日々を過ごしていました。
暑いのは苦手なので、このままの温度感で夏が終わってほしい感じは
あります。


FPGAでギガビット・トランシーバーを用いてGbpsの高速通信に挑戦
している件、この連休を潰して黙々と取り組んだ結果、そろそろ動き
そうなところまで来ました。
てか まだ不完全ですが、なんかそれっぽく動きつつあります。


先週「タイミング制約がうまく行かない」と言っていた件は、ネットで
調べながらアレコレ試行錯誤していたら、良い感じに制約できたっぽい
です。（多分）

ポイントは、ロジックアナライザーでのデバック用に一時的に引き出して
いる信号線については「set_false_path」でタイミング制約から除外、
かつ、お互いに同期せず無関係なクロック信号は「set_clock_groups
-asynchronous」で外してあげると、うまく行くようです。
タイミング制約の条件をちゃんと書いてあげることで、タイミング解析
のエラーが防げ、コンパイル時間も短縮し、回路が動作する最高周波数
も向上しました。・・・知った後から思えば当たり前なのですが。
あとは、回路のクロック同期処理を見直したり、不必要に速いクロック
ラインは速度を一段下げたり、コンパイラの最適化設定を変更しました。

結果として、40MHz程度でしか動かないとされ大量にタイミング解析で
エラーが出ていたロジックが、解析結果からエラーが無くなり回路自体
も200MHzオーバーで動くようになりました。
そして、コンパイルするごとに挙動が変わる不安定さも無くなりました。
・・凄いぞ！　不安定なLSIが 5倍以上高速化して安定したぞ！
いやー、FPGAのタイミング制約って超重要なんだなぁ・・（痛感
またひとつ勉強になりました。


それ以外に行ったこととして、プロトコルのリセット処理を見直したり、
勘違いにより特定の信号の論理（0・1）が逆だったことが判明したので
修正したり、プロトコルの上位レイヤーのエラー処理やデータ転送処理
を修正したりしていました。

そんなこんなやったことで、なんか所々は動くようになりつつあります。
全体的にはまだまだ不安定で、不規則に初期化シーケンスがコケたり、
特定のコマンドの組み合わせが通らず途中でフリーズしたりするので、
まだ「動きました」「できました」とは言えない状況ですが、
ちょっと前のように「全く動かない」というような文鎮状態ではないので、
だいぶ望みは出てきた感じです。

そろそろ何を作っているのか詳細を公言（本ブログに記載）しても良い
かもしれませんが、XOPSと関わりのない他所で どのように活用・展開
していくのか未定なため、もうしばらく伏せておきます。


本一件は、XOPSの世界では全く使わない無縁な話で、XOPS以外の他所で
使うことを見込んでやっているわけですが、
昨今の世間の状況や、使用・活用先の近状、今後の自身の状況など総合的
に考えると、まさに『やるなら今しかない』みたいな状況なので、
短期集中で今勝負するしかありません。
今のところは まだモチベーションが保てていますが、（他の世界へ）
よそ見をして道を外れる前に終わらせたいと思っています。

もう2ヶ月以上経ちますが、FPGAでギガビット・トランシーバーを
やっている件、それっぽく動く（はずの）ロジックはできました。

トランシーバー（正しくはRXなのでレシーバーだが）のPHYの初期化
処理を変更し、クロック同期の処理を変更することで、『タイミングが
合えば』RXも信号が拾えるようになりました。
通信相手が不意なタイミングでリセット処理に入ると、こちらも追従
しなければいけないわけですが、
これが結構クセモノで、相手の信号にクロックを同期していると、相手
のリセットシーケンスをうまく検知できないようです。
なので、通信状態を常に監視し、相手がリセットらしき処理に入った
場合は、クロック同期の処理を変更するようにしました。
・・・・何を言っているか分からないと思いますが（＾＾；


そんなこんなで、ギガビット・トランシーバー自体はできたはず、
クロック同期処理もできたはず、プロトコルを扱うロジックも
基本的な処理は抑えたはずなのですが、やっぱり動きません（ｎ回目

直接動作の関係ないところのロジックに軽微な修正を加え、コンパイル
（論理合成と配置配線）を掛け直すと、
変更するたびに動いたり動かなかったり、その動かない個所や不具合内容
も毎回変化する状態です。
実行後のタイミング解析結果を見ると、数ns（ナノ秒）レベルのタイミング
違反が多数出ているので、実デバイス上に実装する際にロジックの速度・
タイミングが要求速度に満たしていないようです。

正直言って、どうして良いのかよく分かりません。
一応クロックラインのタイミング制約は掛けているはずなのですが、
そもそも正しいのか、制約が不足しているのか、記述が間違ているのか、
確信がなく よく分かりません。
今まで扱っていた数十Mbpsクラスの通信であれば、適当なタイミング制約
で良く、ぶっちゃげ制約ゼロでも問題なかったのですが、
Gbps単位の通信となると、しっかりと制約を加えてコンパイルしないと
まともに動かず、動いても「まぐれ」で動いているだけになってしまいます。
・・・まさに今がその状態（汗

これも「ｎ回目」と言った感じですが、
FPGAの参考文献でも、HDLのロジック設計やツールの基本操作については
初心者向けに丁寧に説明していることは多々ありますが、コンパイル時に必要
なタイミング制約やタイミング解析に関する解説やノウハウは殆ど紹介されて
いません。
まともにFPGAを使うならば、必須な技術だと思うのですが・・。


こりゃもう、いつになったら まともに動くようになるのか、分からねぇな。。