実機デバッグ

• 赤だけでる -> colorram のデコード関連で直前に bytemask もいれてテストしなかったのがまずかった
• 色がおかしい -> colorram のデコードがさらに間違ってた
• 色がおかしい -> RBG の順番に記載されてた
• 文字がアップスキャンモードでつぶれる -> dotclock がシミュレーション向けに固定されてた(おそい)
• 時々画面表示が変 -> DRAM への書き込みが失敗する

最後の DRAM への書き込みは画面表示を見る感じ成功率にして 70% くらい。ここで昨日活躍した signaltap II をフルに活用するものの、観測できる時間が短いとか、CPU が効率的に VRAM への転送を行えないとか、観測できる場所が特定のアドレスの VRAM の書き込みだけでそこに書き込み失敗するまで100回ぐらいリセットが必要とか。

文字列を転送するときに途中の文字がばけたりしてたんで、共有RAMでCPUが止められるときに失敗したのかといろいろ観測するもののどうも違うらしい。たまたまデータが化けたのをみると WR が下がってもデータバスに書き込みデータが来てるかは確定してないのでちょっと書き込みを遅らせるもののあまり効果なし。
観測頻度を 27MHz だと 64MHz で動いている DRAM をちゃんと解析できないので 64MHz にしたり 128MHz にしたりして詳細を追うもののCPUの書き込み波形が1つぐらいしか見えなかったりするのでさらにリセットしまくり。

メモリウェイト、データバスと疑ったがわからなかったのでアドレスラインをみたときに ras の値が変なことがあることが分析を始めて9時間後に判明した。

sdram_a の値が 7E0h と表示されるが正常な場合は 7D0h で、書き込みに失敗する場合は 7A2h だったり、下位8bitが変。ここまでわかればアドレスを渡しているところを追っていけばよい。それでわかったのはロジック的には問題なくて Quartus II の論理合成が悪いと言うことだった。

どうも1つのステートで Read/Write で RAS アドレスを渡すところが気に入らないみたい。前述のデータバスの関連もあって write を1ステート遅らせてから発行したらちゃんと動いた。というわけで分析開始10時間で問題解決。これを早いと取るかはどうなんですかね...

久しぶりに DRAM のデータシートを見て気づいたのは、burst write の使い方。いまは burst 2回で write 時は1回かいて BST (Burst STop) コマンドを送っているんだが、 bytemask をhighするだけで書き込まれないから時間も同じで簡単だということ。 burst が3回以上なら時間短縮できるんだけどいまのところそういった使い方は必要ないので、将来的には直したい。

CPU はちゃんと動いているし、 VRAM アクセスも出来たと言うことで SD カードからデータを取ってきて m72 のソフト起動はすぐにできそう。