SP6の問題か、MITOUJTAGの問題か
Spartan-6ボードのSPI ROMをST Micro社のM25P32に張り替えたところ、SPI ROMから起動できないという現象が発生しました。
特電Spartan-6ボードは、ATMEL社のSPI ROM「AT45DB161D」を搭載していますが、昨今、SPI ROMの供給状況が非常に厳しいため、他社のROMも乗せられるよう、2種類のICのパターンを用意しています。
下の写真は、AT45DB161DをはがしてM25P32に付け替えたものです。(なお、ジャンパが飛んでいるのは、部品をはがす際に鉛フリーはんだなので扱いにくく、周辺部品のランドをはがしてしまったためです。本当はジャンパは要りません)
このようにAT45DB161DをはがしてM25P32を取り付ければうまくいくだろうと思ったのですが、そうでもありませんでした。
さて困りました。
クロックの質が悪いんじゃないかとか、データが反射しているのではないかとか、いろいろ考えたのですが、どれも違っていました。Virtex-5やSpartan-3AではM25P32でもうまくいっていたので、なぜSpartan-6ではM25P32ではだめなのか・・・
原因は意外なところにありました。
Spartan-6は、それまでのデバイス(Virtex-5やSpartan-3E,3AN)と違い、VS[2:0]という端子がありません。SPI ROMのベンダの違いによるコマンドの違いを指定端子のプルアップ/プルダウンで指定するのではなく、自動で判別できるようになっているとのことです。
次の図はSpartan-6のコンフィギュレーションガイドに載っている、SPI コンフィギュレーションシーケンスの図です。
Spartan-6は、まず0x03という命令コードをSPI ROMに与えてデータを読み出します。その際、32バイト分のデータを読み出します。その中にAA 99 55 66という同期ワードが含まれていれば、そのままコンフィギュレーションを実行します。
もし同期ワードが含まれていなければ、0xE8という命令コードをSPI ROMに与えてデータを読み出します。2度目は実際には512サイクルではなく、340msくらい行われます。CCLKの1サイクルはおよそ1.04μ秒なので、320000サイクルくらい、つまり40kバイト程度のデータを読み出していると思われます。
このように、Spartan-6はSPI ROMに対して2回の読み出しをチャレンジします。
まとめると、Spartan-6は1回目のチャレンジで同期ワードが検出できなければ2回目のチャレンジを行います。2回目のチャレンジでは0xE8という命令コードが使われます。この命令はATMELのSPI ROMにはありますが、M25P32にはありません。そのため、2度目のチャレンジでデータが読み出せないのです。
では、1回目のチャレンジはどうなっているかというと、MITOUJTAG(や、Spartan-6ボードに付属のSP6JTAGユーティリティ)では、BitStreamファイルの先頭にある文字列(デザインの日付やファイル名などが記述されている)を削除せずに書き込んでいます。そのため、先頭の32バイトには同期ワードが現れません。
それゆえ、MITOUJTAGやSP6JTAGで書き込んだSPI ROMは必ず2回のチャレンジを行っていることになります。
しかし、M25P32では2回目のチャレンジに相当する命令コード0xE8が定義されていない・・
これが原因でした。
ではどうすればよいかというと、BitStream先頭のヘッダを削除して、FFFFFFFFFFFFFFFF5599AA66・・・から書き込むしかないのでしょう。
さらに、Spartan-6のバグ(?)と思われる現象を発見しました。先のXILINXのデータシートに記載されていたフローチャートでは512サイクルで同期ワードが現れるかどうかで判断していたようですが、実は、512サイクルぴったりで見つかった場合にはダメなようです。
つまり次のデータのようにAA995566が先頭の32バイトに書き込まれていてもダメでした。
もう1バイト余分にあればコンフィギュレーションに成功するようでした。
ST社のROMをSpartan-6に対応させるために、BitStreamのヘッダは削除して書き込むべきなのかもしれません。
というわけで、MITOUJTAGのSPI ROMライタに、BitStreamのヘッダを削除する機能を追加することにします。
最近のコメント