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


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

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


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

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


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

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

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


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

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