今度のコードは未経験のステートマシン、SRAMのアクセスが入っている。最初から動くことは余り期待していない。電源を入れ、iMPACTを始動させてプログラムを書き込む。おお、UARTの端末にプロンプトの>が出た。キーボードを叩く、文字が出た。良いぞ、このあたりは動いているようだ。おやあ、文字は同じ>のままで増えていくだけだ。SRAMに入れたデータを端末に戻すキー、リターンキーを押す。何も表示されず、カーソルだけが最初に戻った。さあ、これからが本番だ。久しぶりの少しまともなプログラムのデバッグに心が躍る。事件の現場に乗り込んだ刑事の心境である。目の前に犯人の残した沢山の証拠がある。この証拠を元に何が原因でこれが起きているかをつきとめ、正しく事件を解決していく。現在、起きている状況をなるべく詳しくメモにする。まとまったら、それに対して仮説をたて、ソースコードを検証していく。暴走か、全くの沈黙では仮説の立てようがないが、こんどは結構動いて証拠を残してくれている。調べただけで、いくつかのミスが見つかり、SRAMのテストベンチは、とりあえずUARTからのデータ入力を受付け、出力はされないがリターンキーで次の入力を受け付けるところまで動いた。7セグには受け付けたバイト数がちゃんと表示され、リターンキーを押すと0に戻る。実際の出力がされないのは、バイナリー端末(アクノリッチ)で、入力した最後のデータ(改行)を入力バイト数だけ出力していることがわかった(改行の連続なので普通の端末ではデータがないように見える)。SRAMにデータが入っていないか、正しくとりだせないかだが、UARTのステートマシンのところはほぼ想定どおりの動きをしていることがわかった。SRAMのアクセスがうまくいっていない。この確認は実際にSRAMに所定の信号が入っているか調べるしかない。これ以上の机上デバッグは無理である。オシロをとりだして、実際の動きを確かめることにする。SRAMの読み書き成功。UARTにゴミが残る(4/29/2010)オシロで見た結果は一目瞭然だった。CE(ChipEnable)が一旦、アサート(L)になると、元に戻っていない。CEは今の状況では大きな問題にならないが、WEは書き込みenableになったままなので、いつまでたっても読み込めない。動作しない原因はわかった。して制御線が元に戻らないのか。SRAMモジュールでは1クロック回した後、CEなどを戻している。SRAMアクセスの部分をさらに念入りに調べる。タイミングチャートを描いてみて原因がわかった。FPGAのHDLは、クロックが同じだと、すべてのモジュールが同時に動く。リクエスト/ビジーの連携は、必ずクロックをひとつ遅らせないと正しい結果を受け取れない。SRAMモジュールにもステートマシンを入れて順序処理にしてやる必要があるのだ。単なる繰り返しで処理をしていたSRAMアクセスにも、アイドル->アクセス->ウェイトの3つのステートマシンにして、コーディングしなおす。よーし、これで動くはずだ。