OpenOCDをMinGWでコンパイルする

昨日はOpenOCDをWSL2で動くようにビルドしてみたのですが、ホストのWindows上で接続されたUSBをWSL2から認識させるにはかなり面倒くさい手続きが必要なので、Windowsのネイティブのアプリとしてビルドしたほうが便利だと気が付きました。

そこで、VisualC++でOpenOCDがコンパイルできるように移植をしようとしてみたのですが、すぐに挫折しました。contains_ofなどのLinuxカーネル系のマクロの扱いがGCCとVCで何か違うらしく、修正するのが馬鹿らしくなってきたためです。

↓こういうマクロです。

そこでMinGWを使うことにしました。MinGWやMSYSは古臭いという印象があったのですが、いろいろアップデートされているらしくmingw-w64とMSYS2という環境が最新のようです。

MSYS2は本家のページからダウンロードします。現時点での最新は msys2-x86_64-20231026.exe であるようです。

パッケージの管理はDebianやUbuntuではaptですが、MSYS2ではpacmanというのを使うそうです。世の中知らないことばかりです。

ダウンロードしたら

pacman -Syuu

をデータベースの更新がなくなるまで繰り返します。

この時点ではgccすら入っていないので、

pacman -S unzip bzip2 base-devel mingw-w64-x86_64-toolchain
pacman -S git

で基本的なツールをインストールします。

そして、

git clone git://git.code.sf.net/p/openocd/code openocd-code

でgitからクローンして、

cd openocd-code/
./bootstrap

をしてみますといろいろと足りないものが出てくるので、

pacman -S libtool
pacman -S pkg-config
pacman -S automake 
pacman -S autoconf

で必要なツール類をインストールします。

これでbootstrapが通るようになりました。

ところが、MSYS2 MSYS(紫アイコン)の環境で./configureをしてみるとエラーで止まってしまいます。

どうやらMSYS2の環境にはいろいろあるらしく、

MSYS2-mingw64(青アイコン)の環境では無事にconfigureが通りました。

気にせずに青アイコンのMSYS2で続けます。

pacman -S mingw-w64-x86_64-libusb
pacman -S mingw-w64-x86_64-libhidapi
pacman -S mingw-w64-x86_64-libftdi

で、USBまわりのドライバと開発環境を入れて再びconfigureを行います

ちゃんとUSB関係のドライバも入りました。

これで、

make

ができるようになりました。

WSL2と比べるとものすごく時間がかかるのですが、仕方ないですね。

出来上がったopenocd.exeは、Windowsの環境に、libusb-1.0.dllと、ibftdi1.dllとlibhidapi-0.dllを持っていけば起動することが確認されました。

DependencyWalkerで見てみると、kernel32やMSVCRT.dllなどのDLLがあれば動くらしく、

使い勝手に関してはWSL2上で動かすよりも良いと言えます。

Cosmo-Z MiniにFIRフィルタを実装

あるお客様がCosmo-Z Miniで、波形データが流れるAXI StreamバスにFIRを実装したところ、カクカクしていてランダムな波形が出てきたという連絡がありました。

実際にやってみるとたしかにランダムでカクカクな波形が出てきます。

その原因なのですが、お客様が使っていた係数でFIRフィルタを作ると出力が36bitになるのですが、そのまま使うと下位16bitだけが接続されてしまうため、このようなぐちゃぐちゃな波形になっていたようです。

XILILNXのFIRコアはデフォルトでは入出力のビット幅が異なるので、綺麗に接続するには上位16bitを取り出すことを明示的に指定するか、
下のダイアログのようにFull PrecisionからTruncated LSBを選んで16bitだけを取り出すようにします。

なお、AXISのバス幅は8bit単位なので、計算の精度が36bit必要ということになっても40bitで出力されます。

それから、波形がカクカクしているのですが、おそらくFIRのclocksで示した部分を設定していないため、デフォルトのまま300MHzの速度で0.01MHzの信号を計算するという緩い仕様で作られてしまっています。

これが実際にはそこまで緩くはならず、5クロックで1つの値を計算するという程度の速度で作られているため、カクカクした波形になってしまっていたようです。

スペクトラムを見ると、fs/2までにゼロになる点が4つほど見えています。だから5クロックで1つの計算なのです。

FIRフィルタのクロック設定を変えて、1クロックで1つの値を計算するようにしたところ、下の図のようにきれいな(茶色)スペクトラムとなりました。FIRなし(赤)のチャネルのノイズフロアを下回っていることが分かります。

Cosmo-Z MiniでCICフィルタを実装する

Cosmo-Z Miniは4chのADCを持ちますが、FPGAの中ではデータはAXI Streamで流れています。

そのAXI StreamにCICフィルタを挟めば、受信した波形をCICフィルタに通した効果というのを確認することができます。

実際にやってみましょう。Cosmo-Z Miniのソースコードを開き、SignalProcessingブロックの中のFilterブロックに下記のような構造のBlock Designを作ります。

Cosmo-Z Miniではデータは14bit×8chのAXI Streamなので112bitありますが、それを1chごとにバラバラにするのがcosmoz_data_sliceとうIP、結合するのがcosmoz_data_combineです。

ダウンロード - cosmoz_data_combine.zip

ダウンロード - cosmoz_main_cic_compiler_0_0.xci

下の波形のような信号を入力して、それをCICフィルタに通してみました。

すると、このようにカクカクながらも正弦波に近い波形となりました。

CICフィルタはデシメーションがセットで行われるので、このようにサンプリングレートが下がってカクカクしてしまいます。

BLANCAのROMの書き込みかた

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

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

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

で、どうやってフラッシュROMにFPGA用のデータを書き込んでおくかというのが気になりますが、マニュアルやソースファイルを読んだ限りでは、基板に２つある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を起動して自動認識ボタンを押すと、３つのデバイスが認識されます。

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

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

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

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

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

② ROMから起動する

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

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

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

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

この入力は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はおそらくバススイッチで、セレクタ代わりに使っているのだと思われます。

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

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

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

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

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

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

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

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

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

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

なお、フラッシュ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に流し込み、新しいデザインで起動するようになりました。

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

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

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

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

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

何が大変だったかというと、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時代のパラレルポート制御」ということで、まとめようと思います。

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

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

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

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

この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にパラレルポートのアクセス権を獲得させないようにするには、どうすればよいか、ということは次回に書きます。

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

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

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

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

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

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

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

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

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

MITOUJTAG体験版！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JTAGロジアナ

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

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

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

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

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

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

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

クリックで拡大

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

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