2006.11.08

BLANCAのROMの書き込みかた

BLANCAは、FPGAを起動させるために、XILINXのコンフィギュレーションROMを使っていません。

コンフィグROMを使わずに、汎用のフラッシュROMにコンフィギュレーション用のデータを書いておいて、電源投入時に、基板上のCPLDがROMから読み出してFPGAに送って起動する、という仕組みになっているようです。

したがって、電源ONでFPGAをROMから起動させるには、
 1. CPLDに「FPGA起動用回路」を書き込んでおく
 2. フラッシュROMにFPGAのデータを書いておく
という準備をしたあとで、BLANCAの電源を入れるということになるのだと思います。

で、どうやってフラッシュROMにFPGA用のデータを書き込んでおくかというのが気になりますが、マニュアルやソースファイルを読んだ限りでは、基板に2つあるFPGAのうち大きいほうのFPGA(XC3S1500)を通じてUSB経由で書き込むようです。CD-ROMにはそのためのサンプルアプリが同梱されています。

出荷時の状態ですでにROMやCPLDにはサンプルアプリが書き込まれているのですが、全く空の状態から書き込みたいというときには、まず電源ONした後に、CPLDとFPGAに必要なファイルをJTAG経由で書き込み、USBを通じてFPGA用のBITファイルを送りこむ、ということになるのでしょう。

ちょっとややこしいので、ここではMITOUJTAGを使ったBLANCAの起動方法をいくつか考えてみました。

① FPGAにJTAGで直接書き込む


BLANCAは、デフォルトの状態ではサンプルアプリが入っています。

このサンプルアプリは、MicroBlazeなどのソフトコアのCPUが動いている複雑なものなので、FPGAのハードだけで動く回路をちょこっと作って試すには、全部空にしてしまいたくなります。
したがって、まず、電源ONでデフォルトのアプリが起動しないようにしたいわけです。

それには、CPLDを消去するのが、最も手っ取り早そうです。
MITOUJTAGを起動して自動認識ボタンを押すと、3つのデバイスが認識されます。

3つのデバイスが認識された

いちばん左側のデバイスがCPLDですので、これをクリックして、MITOUJTAGのツールバーの「消去」ボタンを押します。これで、CPLDが消去され、電源ONでFPGAが起動しなくなります。

再度、電源をいれなおし、バウンダリスキャンをおこなってみます。
すると、FPGAの全端子が入力(HI-Z)状態(網掛けの状態)になっているのがわかり、また、FPGAのDONEピンがLowの状態になっていることがわかります。
つまり、FPGAが起動していないことがわかります。

起動していないFPGA

このように、MITOUJTAGでは、FPGAが起動する前でもそのデバッグ機能を使うことができます。これは、他のFPGAデバッグツールでは真似できない特徴です。

真中のデバイス(XC3S1500)をクリックして、ツールバーの「書きこみ」ボタンを押し、FFT用のBITファイルを選択します。使用するケーブルにもよりますが、およそ2~3秒で書き込みが成功し、FPGAが起動します。BLANCAはスレーブパラレルモードになっていますが、JTAGを使ってもFPGAに書き込みができるようです。

FPGA書き込み中

FPGAが起動した状態でバウンダリスキャンを行うと、下の図のように、それぞれのI/O端子が出力や入力に変わり、一見してにぎやかな感じに変わります。また、DONEピンもHighに変わったことがわかるので、コンフィグに成功したことは一目瞭然です。一番右のFPGA(XC3S400)には何も書き込んでいないので、起動していません。このFPGAの端子状態は全部入力(HI-Z)のままです。

AVPだけが起動した

② ROMから起動する

ROMから起動するには、フラッシュROMにFPGA用のデータを書き込みます。

MITOUJTAGには、バウンダリスキャンを利用したフラッシュROMライタが内蔵されているので、これを使って書き込んでみましょう。

フラッシュROMライタ機能を使うには、まず、フラッシュROMの各端子(アドレスやデータ、CEなど)がFPGAやCPLDのどの端子につながっているかを、MITOUJTAGに登録する必要があります。

その接続情報は、回路図とCPLDのUCFファイルを読んで解釈し、自分で一つづつ入力します。

ROMとCPLDの接続情報

この入力は10分くらいで終わるでしょう。入力した接続情報はファイルに保存しておきます。
「blanca.jfc」をダウンロード


回路図によると、フラッシュROMはAm29DL640Gという品種で16ビット幅のROMです。

ですが、CPLDとの間は8ビットでつながっているので、ROMを8ビットモードで動かさなければなりません。そのためには、ROMのnBYTEという端子をLに固定するとともに、[D15/A-1]という変なアドレス入力を使う必要があります。

また、フラッシュROMのアドレスやデータなどはCPLDにつながっているのですが、ROMのnBYTE端子、nWRP端子、リセット端子はCPLDにつながっていません。nWRPは単なるプルアップ、リセットはシステムのリセットなのでそのままでも問題ありませんが、nBYTE端子はちゃんとLowになるようにしなければなりません。

nBYTE端子はIDT QS3257QというICにつながっています。このICはおそらくバススイッチで、セレクタ代わりに使っているのだと思われます。

ROMの信号セレクト回路

このICのCFG_nBYTEという信号をLにしてやれば、ROMのnBYTE端子はLowになりそうです。幸いCFG_nBYTEはCPLDにつながっているので、CPLDを適切に制御してやればフラッシュROMの全端子を操作することができて、CPLDからフラッシュROMにアクセスできるはずです。

というわけで、「フラッシュにアクセスするときにはCFG_nBYTEをLowにするように」と、MITOUJTAGに指示します。こうしてフラッシュROMライタを起動し、「調査」ボタンを押すと、下の図のようにちゃんとフラッシュROMのIDコードが読み出せるのが確認できました。


CFIコード読み出し成功

また、0番地からフラッシュメモリをダンプしてみると、なにやらB6 00 ・・などというデータがたくさんでてきます。きっと、CPUのプログラムではないかと思われます。

アドレス0番地 CPUのプログラム?

BLANCAのマニュアルには、フラッシュROMの後ろのほうの1Mバイトにそのデータが書き込まれている、と書かれています。フラッシュROMは8Mバイトなので、0x700000番地からダンプしてみると、「3s1500」などというデータが見え、その後におなじみの「FFFFFFFFAA995566」という、FPGAのコンフィギュレーションデータが見えました。

ROM上に格納されたFPGA用BITファイル

このデータを消去してしまえば、たとえCPLDが動いても、FPGAは起動しなくなります。
また、このデータのかわりに自分が設計したFPGAのBITファイルを書き込めば、そのファイルでBLANCAが起動するようになるでしょう。

そこで、まず、MITOUJTAGのフラッシュROMライタのセクタ消去機能をつかって、0x700000番地以降をを消してしまいましょう。0番地などにあったCPUのプログラムは今後のことを考えて残しておきます。

書き込みには少し時間がかかります。XC95288XL、XC3S1500、XC3S400のすべてがバウンダリスキャンチェインにつながっていると遅くなりますので、FPGAのBSDLを割り当てないようにします。
MITOUJTAGのデバイスの選択画面で、「BSDLを使用しない」と表示されるデバイスを選択すればOKです。下の図のようにFPGAだけ灰色で表示されます。

スキャンチェインからFPGAを外す

これで、XC95288XLだけを操作することでフラッシュROMに書き込めるようになり、書き込み時間が大幅に短縮できます。

また、先ほど消去したCPLDのデータを復活させます。CPLDの絵をクリックして「書き込み」ボタンを押し、BLANCAのCD-ROM中の"normal.jed"を書き込みます。

次の図は、書き込み中の画面です。
フラッシュROMのセクタ構成(水色)の上に、ファイルサイズ(黄色)と、書き込みエリア(赤)、そしてどこまで書き込んだか(緑)が図示されます。この画面でしばらく放っておけば、そのうち書き込みが完了しています。

Programming

なお、フラッシュROMと、CPLDとはどちらを先に書き込んでも構いません。
なぜなら、MITOUJTAGはバウンダリスキャンを使っているので、フラッシュROMの書き込み時にはCPLDの中の回路は動いていないからです。

つまり、CPLDやFPGAなど、すべてのデバイスが正しく動作していなくても、CPLDとROMがつながってさえすれば、書き込みができます。CPUの場合も同様です。クロックが怪しくてICEすら起動しなくても、バウンダリスキャンならなんとかなるでしょう。
MITOUJTAGのフラッシュROMライタは「つながってさえいれば」、CPLDでも、CPUでもFPGAでもなんでも使えてしまいます。この万能さは、各社から発売されているCPU用JTAG ICEやFPGA用デバッグツールにはない特徴のひとつです。

これで、BLANCAのCPLDは電源ON時に、新しいBITファイルをFPGAに流し込み、新しいデザインで起動するようになりました。
Done

バウンダリスキャンでフラッシュROMに書き込むのは時間がかかります。デフォルトのサンプルアプリを使うのでなければ、開発時にはCPLDを消去しておき、JTAGでFPGAに直接ダウンロードするのがよいと思います。

| | コメント (3)

2006.02.05

WindowsXP時代のパラレルポート制御

パラレルポートのアクセス権を理解するため、parport.sysの使い方を習得しました。

parport.sysにアクセスすると、パラレルポートのアドレス等の情報や、排他的アクセス権を取得することができます。
このデバイスドライバを理解するのに、いちばん参考になったのは、翔泳社の「WDMデバイスドライバ 」という本でした。

この本によれば、
 1.「\Device\ParallelPort0」という名前のドライバがある。
 2.IoGetDeviceObjectPointerでデバイスオブジェクトのポインタを得る。
 3.Internal IOCTLを発行する。
 4.TryAllocatePort関数を呼び出す。
 5.FreePort関数を呼び出す。
という手順が書かれています。1ページに満たない短い解説なのですが、意味を理解するのに数日かかりました。

何が大変だったかというと、Internal IOCTLを発行するにはIoBuildDeviceIoControlRequest関数でIRPを作って、IoCallDriverを呼び出す、という手順を理解するので一苦労。
IoCallDriverでIOCTL_INTERNAL_GET_PARALLEL_PORT_INFOを発行する方法がわかれば、PARALLEL_PORT_INFORMATION構造体を得ることができます。

そして、PARALLEL_PORT_INFORMATION構造体の中にTryAllocatePort関数のポインタが格納されています。
このTryAllocatePort関数を呼べばよいのですが、引数をどうすればよいのか、かなり悩みましたが、PARALLEL_PORT_INFORMATION構造体の中にあるContextという値を引数にして、
portinfo.TryAllocatePort(portinfo.Context);
とするのが正解のようです。

ただし、同一のプログラムでTryAllocatePortを2回呼び出してしまうと、なんかロックがかかってしまうようで、パソコンを再起動しないとアクセス権が得られなくなってしまうようです。

さて、苦労の末、ようやくInternal IOCTLの使い方をマスターできたのですが、これを使うと、パラレルポートのアドレスや、ポートがECPやEPPに対応しているか、などの情報を得ることができます。
おそらく、ポートのアドレスを調べる最も正当な方法でしょう。

私のPCでは、こんな情報が得られました。

 OriginalController=0x378
 Controller=0x378
 SpanOfController=0x8
 OriginalEcpController=0x778
 EcpController=0x778
 SpanOfEcpController=8
 HardwareCapabilities=0x9  (ECP mode,BYTE mode, )
 FifoDepth=16
 FifoWidth=1
 EppControllerPhysicalAddress=0
 SpanOfEppController=0
 Ieee1284_3DeviceCount=0
 CurrentMode=0x0


いろいろやった末、ようやくTryAllocateで排他的制御権を獲得することができるようになりました。
WindowsXPのWarmPollを停止させることができ、当初の問題は解決できました。

しかし、排他的アクセス権を得ると、もっと重大な問題が出たのです。

そのことを書く前に、そもそも、なんでこんなことをやっているかを説明しましょう。
ことの発端は、MITOUJTAGからALTERAのByteBlasterを使おうとしたとき、WindowsXPで動作がおかしいことに気が付いたことでした。

WindowsXPでWarmPollが動きだすと、ByteBlasterの中の重要な制御信号がWarmPollに勝手にいじられてしまい、ByteBlasterが正常に動作できません。そこで、WarmPollの回避方法として排他的アクセス権を獲得しようと考えたのです。

確かに、パラレルポートへの排他的アクセス権は獲得できました。WarmPollも回避できました。

ところで、ALTERAのQualtusIIは、内蔵のJTAGプログラマを使用しなくても、なぜかコンパイル中にパラレルポートへ頻繁にアクセスします。困ったことに、QualtusIIも排他的アクセス権を獲得しようとするらしいのです。しかも、獲得できない場合には、諦めるのではなく、長時間のWAITを行ってしまいます。

つまり、QualtusIIは、パラレルポートの排他的アクセス権が得られないと、コンパイルがとても遅くなるらしいのです。
この現象は、QualtusIIに内蔵されたJTAGプログラマを使わない場合でも発生します。

例えば、スカスカのVHDLファイルをコンパイルすると、普通なら10秒くらいで完了します。しかし、QualtusIIがパラレルポートの排他的アクセス権を得られないと4~5分かかってしまうようです。

これではちょっと困ります。QualtusIIを使う場合にはMITOUJTAGが排他的アクセス権を持ったままにはできないのです。

結局、WarmPollを回避するには、レジストリに値を設定するのがベストということなのでしょう。

Windows2000やXPで、パラレルポートのアドレスを正当に取得する方法がわかっただけでも、この数日間の作業の成果があったと思うことにしましょう。

いずれ時間ができたら「WindowsXP時代のパラレルポート制御」ということで、まとめようと思います。

| | コメント (1)

2006.02.03

WindowsXPでパラレルポートを自分の物に!WarmPollの回避方法

WinXPのデバイスドライバparport.sysのソースを読んで、WarmPoll機能の回避方法を考えてみました。

WarmPoll機能が動いていると、パラレルポートの制御信号などが勝手にアクセスされてしまって、自分で作ったハードウェアなどに誤った信号を出力してしまうからです。

そこで、parport.sysのソースを読んで解析した結果を、次の図に載せます。ちょっと流れ意訳しているので、微妙に違うかもしれませんが。
warmpoll

このWarmPoll機能は、parport.sysというデバイスドライバが起動しはじめたところから始まります。
つまり、WindowsXPの起動とともに、WarmPollは潜伏を始めると考えていいでしょう。
parport.sysの起動時にはPptFfoStartDevice()という関数が呼ばれます。
PptFfoStartDevice()関数の中では、システムレジストリ
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parport\Parameters
を読んで、DisableWarmPollというキーがゼロ以外になっていれば、WarmPoll機能は起動されません。

したがって、レジストリにDisableWarmPoll=dword:00000001を書く、というのも一つの解決方法です。

もし、DisableWarmPollが設定されていないと、PptFfoStartDevice関数はWarmPoll用にスレッドを作成します。

そして、そのスレッドが開始します。
まず、規定の時間、待ちます。
もし、バッテリ駆動であれば、WarmPoll機能は作動せず、スレッドはループを繰り返します。
ノートPCならバッテリ駆動にするというのも、解決策の一つではないかと思います。

そして、PptTryAllocatePort()という関数を呼び出して、ポートのアクセス権を取得しようとします。
ここで、アクセス権が獲得できなければ、パラレルポートへの出力は発生しません。

次に、GetStatus()という関数を呼び出します。
この関数で、パラレルポートが接続されていないとか、ケーブルがない、と判断されれば、パラレルポートへの出力は発生しません。

もし、何かがありそうだ、ということになれば、P4ReadRawIeee1284DeviceId()という関数を呼び出します。
この、P4ReadRawIeee1284DeviceId()が、勝手にパラレルポートへアクセスして悪さを引き起こしていると考えられます。

つまり、GetStatus()で何かがある、と判断されれば、P4ReadRawIeee1284DeviceId()を呼び出して悪さをするわけです。システムが暖まったころにポーリングを始めるので、WarmPollというのではないかなと推定されます。

このP4ReadRawIeee1284DeviceIdが呼ばれないようにするためには、バッテリ駆動にするか、TimeToTerminateThreadという値を設定するか、パラレルポートのアクセス権をWarmPollに獲得されないようにするのがよいでしょう。TimeToTerminateThreadは10回失敗すればセットされますが、10回失敗するまでには1分程度かかります。
したがって、「パラレルポートのアクセス権を獲得させない」というのが、最も正解に近いのではないかと思います。

WarmPollが起動するための関数、GetStatus()では何を調べているのか、
P4ReadRawIeee1284DeviceId()は何をしているのか、
そして、WarmPollにパラレルポートのアクセス権を獲得させないようにするには、どうすればよいか、ということは次回に書きます。

| | コメント (2)

2006.02.01

WindowsXPでパラレルポートが勝手にアクセスされる!?

WindowsXPで、パラレルポートが勝手にアクセスされるという不可解な現象に悩まされています。

私のマシンでは、WindowsXPを起動後、パラレルポートのコントロールポート(0x37a)に
書き込みを行うと、この不可解な現象が始まります。

最初、このポートの値は0x0cになっていますが、0x0eを書き込んでみると・・・
なぜか勝手に0x06に書き換わってしまい、その後0x0cになります!

一体全体どのプログラムが値を書き込んでいるのかは不明ですが、パラレルポートのAUTOFXINITとSLCTINという信号線が勝手にアクセスされてしまいます。
OSの何かが何かをしているのでしょうか・・

じっと見てみると、0x06→0x0c→0x06→0x0cという動作を、5秒周期で11回繰り返し、
約50秒間続けた後、この不可解な現象は収まるようです。

古いマシンでも、最近クリーンインストールしたマシンでも、同じ現象が起きてしまいます。デバイスマネージャで見ても、LPT1のプラグアンドプレイが有効になっているわけでもないですし。一体なんなんだろう。

XPでパラレルポートにアクセスするプログラムを作るときには、デバイスドライバから、
バスドライバ(?)のparport.sysにアクセスして、排他的制御権を得なければいけないのでしょうかね。
(DDKのコードを見て、パラレルポート関係を調べるは一苦労です・・)

ちなみに、Windows2000ではこの現象は起きません。

| | コメント (4)

2006.01.17

MITOUJTAG体験版!

MITOUJTAG体験版が、ようやく出来上がってきました!

mjtrial-cdrom

18日から始まるインターネプコンで、ご来場いただいた方にこのCD-ROMを配ります。
予約分を含めて100枚しかつくっておらず、数量限定なので、お早めにお越しください。
体験版CD-ROMを予約された方の分はお取りおきしておきます。
確実な入手をご希望される方は、是非ともMITOUJTAGをご予約ください。

mjtrial124

体験版は、開発中の最新バージョン1.2.4をベースに作られており、すべての機能が使えます。体験版の制限は、JTAGチェーン中のデバイスの数が2個まで、フラッシュROMライタでの操作長の制限、それから30日間の試用期限が設定されています。
また、体験版はあくまでも評価のためのバージョンなので、実務でご使用なさる場合は、MITOUJTAG BASIC版へバージョンアップしてください。

なお、MITOUJTAG体験版は、展示会にお越しいただいた方限定のバージョンです。
展示会終了後に、ネット等で受け付けて配布する予定はございませんので、ぜひこの機会をお見のがし無く!

※インターネプコンへの入場は、招待状または事前登録が必要です。
http://www.nepcon.jpで事前登録を行ってからご来場ください。
事前登録や招待状がないと、入場料5000円を取られるそうです。ご注意ください。

・・・ホントに取られます。昨年、それで某展示会に入れませんでした。(泣)

| | コメント (0)

2006.01.16

Spartan3E フラッシュメモリへの書き込み

Spartan3Eは、コンフィギュレーション用に、汎用のフラッシュメモリを使うことができます。

そこで、Spartan3E Sample PackにMITOUJTAGのフラッシュROMライタ機能をつかって実験してみたところ、bitファイルをそのまま書き込むのではだめで、ビットリバースしないとうまくいかないようでした。

flashwriting

XILINXのツールが出力するビットストリームは、デフォルトではFFFFFFFFAA99556630…という並びになっていますが、これをSpartan3E Sample PackのフラッシュROMに書き込むには、ビットリバースしてFFFFFFFF5599AA660C…という形に変換しなければいけないようです。

ビットリバース処理は要りますが、BitをHexやMCSに直すという手順は必要ありません。Bitをそのままフラッシュメモリに書けばよいようです。ビットリバースだけちゃんと処理しておけば、フラッシュメモリの適当なところに書き込んでおくだけで、FPGAはそのデータで起動します。

気になる書き込み時間ですが、MITOUJTAGとMobile JTAG Cableを使って、73kBytesのコンフィギュレーションビットを書き込んでみたところ、およそ90秒でできました。

jtag flash

なお、Spartan3E Sample Pack推奨の方法では、どうやらMicroBlazeを使った書き換え専用回路を一度FPGAの中に入れて、その中のMicroBlazeとパソコンで通信し、MicroBlazeがフラッシュメモリにアクセスして書き込むという方法のようです。とても面倒そうなので試していませんが。

それに比べてMITOUJTAGのフラッシュROMライタはバウンダリスキャンで書き込んでいるので、FPGAの中に書き込み専用の回路を書く必要がないので、簡単に書き込みができました。

| | コメント (0)

2006.01.09

JTAGロジアナ

ブロックRAMに溜め込んだデータをJTAGで吸い出して解析するタイプの、JTAGロジックアナライザの開発をつづけています。

この新ロジアナ機能は、ロジアナ用のIPコアを、FPGAの中に埋め込んで使うタイプです。

このIPコアはNGCネットリストの形で配布しようと考えていました。

最初、このコアのVHDLソースでは、ロジアナのパラメータ(バス幅やデータ長など)をGenericで受け渡ししていました。しかし、VHDLから論理合成して作成されたNGCファイルをngc2edif.exeで変換してみてみると、IF~GENERATE構文を思わせる内容が書かれていませんでした。どうやら、GENERICで指定した初期値で作られてしまっている感じでした。GENERICで渡していたような値は、ネットリストにする段階で確定させなければならないのでしょうか。

そこで、結局、GENERATE構文を使うのはやめ、論理合成での最適化を期待して、各種パラメータをSTD_LOGICのSIGNALで渡すことにしました。

いろいろと苦労しましたが、データバスの幅を1~72ビットまで、データ長を512~1024ワードにまで対応させることができるようになりました。Spartan3のブロックRAMを1個または2個または4個消費します。
今後、データの幅や長さをより柔軟に変えられるようにしたり、より一層気前良くブロックRAMを使って、もっと大量のデータを蓄えられるようにしたいところです。

とりあえず、40MHzのサンプリングで、72ビット幅のデータ(LFSRの出力)をキャプチャしてみたところ、ものすごい迫力のロジアナとなりました。

blogana72x1024
クリックで拡大

ところで、この回路を作る上で、いくつかハマった点があります。例えば、
integer range 0 to 1023みたいに指定しているところを、
実際に使われる数値の範囲を決めて
integer range 16 to 512みたいに親切に書くと、合成された回路の挙動が怪しくなりました。

この詳しい原因は解析していませんが、合成結果の予測がしやすいSTD_LOGIC_VECTORが一層好きになりました。

| | コメント (0)

2006.01.05

MITOUJTAGのVerUP開発スタート!

MITOUJTAGの新しいバージョンと、各種体験版の開発を本格的にスタートしました。

次のバージョンの主な改良点を挙げてみると
・FPGAに内蔵されたブロックRAMを使用する超高速ロジックアナライザ
・描画速度の高速化
・SmartJTAGの動作速度の、5~10倍程度の高速化
・Spartan3Eの書き込み対応
・JTAG命令「CLAMP」と「HIGHZ」のサポート

その他、20箇所程度、使いやすさの改善を予定しています。

画面の描画速度の高速化は、画面を更新する際に状態が更新されなかった端子の描画は行わない、などの工夫を行うことで、描画速度をおよそ5~10倍に向上できる見通しです。
この改良によって、BGAの巨大なデバイスをバウンダリスキャンして表示するときの速度が劇的に速くなるので、大きなデバイスを扱う際にとても役立つと思われます。

高速バウンダリスキャン
毎秒270回のサンプリングと画面更新を達成

ご期待ください。

| | コメント (0)

2005.12.23

Spartan3EのBSDLファイル

Spartan3E Saple PackのCDにあるWebPACK7.1をインストールしてみたところ、WebPACK7.1に入っているSpartan3EのBSDLファイルが正しくないようです。
MITOUJTAGでバウンダリスキャンを行う場合に、WebPACKやサポートパックをインストールした際に入っているBSDLファイルを使うと、バウンダリスキャンが正しくできないどころか、回路にダメージを与える危険性があります。

なお、iMPACTで書き込みを行うだけなら問題はないと思われますが、より高度なJTAGの使い方をする場合は、ご注意ください。

Spartan3EのBSDLファイルは、
WebPACK7.1に入っている
 ・xc3s100e_tq144.bsd バージョン1.1.1.2、2005年2月10日
サービスパックに入っている
 ・xc3s100e_tq144.bsd バージョン1.3 2005年8月26日
と、XILINXのサイトからダウンロードしたもの、
 ・xc3s100e_tq144.bsd バージョン1.5 2005年12月15日
があります。

結論を言うと、12月15日版のバージョン1.5のBSDLファイルが最も正しいようです。
古い1.3などBSDLファイルには誤りがあるので、正しくバウンダリスキャンができません。

どこが違うかを調べてみると、WebPACK7.1に最初から入っているバージョン1.1.1.2のBSDLファイルでは、まず、JTAGの命令コードが違いました。

バージョン1.3
"EXTEST (001111)," &
"SAMPLE (000001)," &
"IDCODE (001001)," &
バージョン1.1.1.2
"EXTEST (111100)," &
"SAMPLE (100000)," &
"IDCODE (100100)," &

つまり、古いBSDLファイルでは、ビットの上下が逆転して記述されているようです。

また、各入出力端子の記述のうち、端子の出力を禁止するレジスタの値(DISVAL)が、バージョン間で異なっています。

***** xc3s100e_tq144_1_3.bsd
" 270 (BC_1, PAD28, INPUT, X),"&
" 269 (BC_1, PAD28, OUTPUT3, X, 268, 0,Z),"&
" 268 (BC_1, *, CONTROLR, 1,),"&
***** XC3S100E_TQ144_1_1_2_1.BSD
" 270 (BC_1, PAD28, INPUT, X),"&
" 269 (BC_1, PAD28, OUTPUT3, X, 268, 0,Z),"&
" 268 (BC_1, *, CONTROL, 0),"&
*****

バージョン1.5のBSDLファイルではその極性が正しくなっています。

***** xc3s100e_tq144_1_5.bsd
" 270 (BC_1, PAD28, INPUT, X),"&
" 269 (BC_1, PAD28, OUTPUT3, X, 268, 1, PULL1),"&
" 268 (BC_1, *, CONTROLR, 1),"&
***** XC3S100E_TQ144_1_3.BSD
" 270 (BC_1, PAD28, INPUT, X),"&
" 269 (BC_1, PAD28, OUTPUT3, X, 268, 0,Z),"&
" 268 (BC_1, *, CONTROLR, 1,),"&
*****

つまり、
 ・バージョン1.1.1.2 → JTAG操作不可
 ・バージョン1.3 → 入出力の極性の定義が逆転
 ・バージョン1.5 → 正しい

ということで、Spartan3Eのバウンダリスキャンを行う際には、極力新しいBSDLファイルを使うようにする必要があるようです。さもないと、EXTESTの際に入出力が逆転して機器を損傷する危険があります。

参考までに、バージョン1.3のBSDLファイルを使ってバウンダリスキャン(SAMPLE)した際の画面を載せます。
バージョン1.3のBSDLファイルでバウンダリスキャン
バウンダリスキャンで観ると、ほとんどの信号が出力として認識されている(実際には入力またはHi-Zである)のがおわかりかと思います。

Spartan3Eをバウンダリスキャンする際には、是非とも
XILINXのサイトから最新のものをダウンロードしてご利用ください。

この問題、最初はSpartan3Eのsteppingの関係かと思いましたが、Spartan3E Sample Packで使われているFPGAは、"4CES"とマーキングされています。つまり、このFPGAはES品で、Stepping 0に相当するようです。それに、データシートによれば2005年の11月時点ではまだStepping 1の製品は出ていないようです。よって、BSDLファイルの問題はSteppingとは関係がなさそうです。

XILINXさんをはじめとして、JTAG対応デバイスのベンダーさん。
(有)ナヒテックは、次世代のJTAG技術を専門に開発しているベンチャー企業です。
もし(有)ナヒテックご連絡いただければ、リリース前でもBSDLファイルを検証させていただきます。ぜひともご検討ください。

| | コメント (0)

2005.12.22

Spartan3E Sample Pack

ET2005で抽選で配られていたボードについて、いろいろわかってきました。

まず、このボードの名前は「Spartan3E Sample Pack」というようです。これは、前に発売された例のSpartan3 Starter Kitと、2005年12月に発売が予定されているSpartan3E Starter Kitの間に位置するようなボードといったところでしょう。

このボードの名前が「Spartan-3E Sample Pack」ということがわかったので、Googleで検索してみると、DigilentのWebサイトの中にあるユーザガイドがヒットします

このボードを調べていて、どのようにしてSpartan3Eがコンフィギュレーションされてるかがわかりました。Spartan3Eは、M2,M1,M0のピンを010または011と設定することで、パラレルフラッシュROMからコンフィグレーションするようになるようです。
このとき、フラッシュROMとFPGAの接続は固定的に決まるようで、つまりFPGAのどの信号がフラッシュROMのどの信号につながる、ということは一意に決まってしまいます。
(ということは、Spartan3EとフラッシュROMの部品の位置関係やパターンもほとんど一意に決まる)

さて、Spartan3E FPGAコンフィグ用のビットストリームは、FPGAと共存するCPUのブートコードと重ならないように選択できます。つまり、メモリの0番地から下向き(?)に格納する方法と、FFFFF番地から上向き(?)に格納する方法が選べるようです。


そこで、MITOUJTAGのフラッシュROMライタで確認すると、アドレス0xE423からおなじみのコンフィギュレーションビット列が入っているのがわかります。
これは、ボードの電源を入れたときに起動する、"Circling LED Design"というサンプルアプリケーションです。

s3esp_1

また、どんどんしらべていくと、アドレスE0000からF1BDCまで、別のビットストリームが、TopとBottomが逆向きに格納されているのがわかります。これは"Dice Game"という別のサンプルアプリケーションです。

s3esp_2

なるほどSample Packの説明書を読むと、起動時にはUPモードでコンフィギュレーションし、ボタンを押すとDOWNモードで再コンフィギュレーションするようで、MultiBootという技術が使われているようです。

データシートを読むと、MultiBootは、STARTUP_SPARTAN3Eというプリミティブを使用することで使えるようになる機能で、コンフィギュレーション後に別のデザインをロードするしくみです。このMultiBootのトリガとなる信号は、FPGAの内部信号であってもよく、つまり、FPGAに、自分自身で再コンフィギュレーションを行うしくみが備わっているということです。誤ったコンフィグデータを書いてしまわないためのフェイルセーフに使えるでしょう。

つまり、マルチブートを発動すると、最初の起動とは逆の方向からコンフィギュレーションデータを探すというものです。このボードでは、最初、0x0000から下向き(?)にコンフィギュレーションデータを探したので、マルチブートの際には0xfffffから上向き(?)に探し、Dice Gameが起動するというものです。

データシートをざっと読んで理解したコンフィギュレーションの仕組みを絵に表すと、下の図のような感じです。

multiboot

(間違ってたらすみません)

コンフィギュレーションファイルをフラッシュメモリに書き込むのは、iMPACTではできないようです。
このボードでは、FPGAに「フラッシュ書き込み回路」をコンフィギュレーションしておき、FPGAに書き込み用回路がダウンロードされると、JTAGを通じてデータを受信してフラッシュメモリに書き込む機能がインプリメントされ、書き込みアプリケーションが動作するようです。実際のところ、私もまだ試していません。

このアプリケーションでは、FPGAの中でMicroBlazeが動いているようです。昨日の日記で、JTAGロジアナを使って観測されたアドレスバスの動きは、そのMicroBlazeの動作と思われます。

MITOUJTAG用で使う、Spartan3Eのフラッシュメモリ定義ファイルは、下記のリンクからダウンロードできます。
MITOUJTAG BASICをお持ちの方は、是非お試しください。
「s3esp.jfc」をダウンロード

| | コメント (0)

その他のカテゴリー

DWMのARM | 仕事 | 技術士 | 研究開発 | 雑記