Windowsの物理メモリの使用状況

Windowsの物理メモリがどのように使われているかを調べてみました。
（本当に正しいかどうか怪しいですけど・・）

検証に使ったマシンは、メインメモリ2GBで、OSはWindowsXPです。

次の図は、OSが起動してからあまり時間が経っていないときに、mallocして確保したメモリが、物理メモリ上でどのアドレス（物理ページ）に配置されるかを図にしてみたものです。

16MBytesの領域をmallocで確保して物理ページを調べ、その後freeし、再びmallocして調べ・・ということを延々と繰り返しています。

なお、画面上の1ドットが1物理ページ(=4096バイト)に対応しています。一度使った点を消していないので、物理アドレス上のどの領域がどんなふうに使われていくかがわかります。

(クリックでアニメーションします。アニメーションGIFのサイズ3882kB)

Windowsが起動後間もないので、比較的連続して固まった領域を確保できています。

次は、起動してから少しだけ時間が経ったときの物理メモリ使用状況です。

(クリックでアニメーションします。アニメーションGIFのサイズ5054kB)

確保できている領域が少しだけばらけてきました。

最後に、起動してから十分に時間が経ったときのようすです。
mallocで取った16MBytesのメモリ領域は、物理メモリ上ではかなり断片化されて広大な範囲に確保されていることがわかります。

(クリックでアニメーションします。アニメーションGIFのサイズ6424kB)

まぁ、物理メモリ上でいくら断片化していようとも、アプリケーションから仮想メモリでアクセスする分にはTLB(PTE)が自動変換してくれるから、全く気にしなくてもいいんですけど、DMAをするには大事なことなので、調べてみました。

わかってきたのは、
・Windowsが起動してから時間が経つと、mallocで確保された領域はどんどんばらける傾向にある。
・mallocとfreeを繰り返すと、物理アドレスが大きくなる方向に確保されていく。
・物理アドレス０番地から、普通に使われている。
・mallocとfreeを繰り返すと、物理メモリのほとんどの領域は満遍なく使われるが、物理メモリ上で決して使われない領域がある。おそらく、非ページメモリに割り当てられた領域か、他のプログラムが使っていて開放していない領域と思われる。（32～160MBytes付近、512MBytes付近、最後の32MBytes付近）
・連続した領域が確保されやすい場所（最初の512MBytesあたりまで）と、確保されにくい場所（後半）といった傾向はある
・大きなサイズの連続した非ページ領域を確保するのって、結構大変なことなのかも。

ということでした。

このツールを作ってみたきっかけは、DMA用のデバイスドライバを作るために、MapTransferとかで苦労してスキャッタギャザリストを取得してみたら、MDLの中身と同じだったということで、図示してみたくなったということです。

Windowsのプログラミングでは、物理メモリは秘められた世界です。カーネルモードのプログラムでさえもメモリの物理アドレスを直接扱う機会はありません。そういうところを調べるのが好きです。

正確なタイミングでバウンダリスキャン

MITOUJTAG ProのJTAGスクリプトで、正確なタイミングでバウンダリスキャンを行なうことができるようにしてみました。

こんなふうに記述します

　　j_extest(); // EXTESTモードにする


　　GPIO   <= "1"; // Hを出力


　　j_enter_syncop(time); // 次の2つの操作の間隔を指定


　　GPIO   <= "Z"; // ここで端子をハイインピーダンスにする


　　GPIO   <= "Z"; // 読み出しのためのスキャン


　　printf("GPIO = %x",(int)GPIO);

このスクリプトは、３回のバウンダリスキャンを行ないます。
①　最初にGPIOという端子から'1'を出力します
②　その端子をハイインピーダンスにします
③　その端子の内容を読み出します

ここで、②と③の動作が行なわれるタイミングを正確に指定できるようにしたというわけです。
これが何の役に立つのかというと、次の波形をご覧ください。

これは、Spartan-3Eの適当なI/O端子にオシロのプローブをつなぎ、②と③を連続して行なったときの波形です。上側の波形はI/O端子の電圧、下側の波形はJTAG信号（TCK)です。

I/Oの端子は、オープンにされるとH→L（あるいはL→H）に遷移します。この遷移時間は、端子の容量や、プルアップ抵抗、プルダウン抵抗、漏れ電流などの大きさによって変わります。短いものでは1μ秒くらい、長いものでは1秒以上も同じ状態が保持されることもあります。

この減衰カーブは、端子に寄生する容量やプルアップ/プルダウン抵抗の大きさによって変わるので、遷移するまでの時間を測ることができれば、どのような回路が接続されているかがわかります。

このカーブが急であれば端子容量が少ない（あるいは弱いプルダウン抵抗がある）とわかりますし、カーブが非常に緩やかであれば大きな容量が接続されているか、もしくはオープンかつインピーダンスが高い状態であるとわかるわけです。なお、妥当なプルアップ/プルダウン抵抗が存在する場合、寄生容量はおよそ1μs以下で放電するでしょう。

②の最後のフェーズでバウンダリスキャンレジスタの内容が端子に反映されるようにしておき、③の最初のフェーズで端子の内容がバウンダリスキャンレジスタに取り込まれるようにしておきます。そして、②と③の間の待ち時間を正確にします。そうすれば、放電時間を測定することができ、オープン/プル（アップ）ダウン/ショートが判定できるというわけです。

ややこしいですが、実際に行なってみました。次の図をご覧ください。

まず、遅延なしの場合。この場合、端子の値はHレベルと判定されました。

次に、50μ秒後に読み出した場合。この場合もHレベルと判定されました。

次は100μ秒後に読み出した場合。まだHレベルと判定されています。

220μ秒後に読み出した場合。Spartan-3EでHレベルと判定されるぎりぎりのラインでした。

240μ秒後に読み出した場合。Lと判定されました。

こんな感じで、Hにしてから読み出すまでのタイミングを1μ秒単位で設定できます。タイミングはPocket JTAG　Cableの中のCPLDで作り出しているので、かなり正確です。パソコンがプチフリーズしてもタイミングは影響を受けません。

（なお、上の図では230μsあたりがスレッショルドとなっていますが、これはオシロのプローブを通じて端子容量が放電されているため、実際の放電時間よりかなり短いです。オシロをつながずに、バウンダリスキャンだけで見た場合、5ms程度は持ちます。）

すなわち、バウンダリスキャンを使って、I/O端子が、オープンか、プルアップ/プルダウンされているかを調べることができるというわけです。

ISE11.6に期待します

XILINXのISE11.5が出たようなので、早速インストールしてみました。

Spartan-6のバウンダリスキャンの問題が解決しているかと期待していたのですが、全く改善されていません。

未使用ピンや入力ピンはハイインピーダンスになっているのに、バウンダリスキャンで見たところ出力として認識されてしまいます。半年前にXILINXに連絡して、確かにISEの問題があると認めてもらったのに、全然改善されていません。

もう、ISE11.6にこそは期待していますので、よろしくお願いします。＞XILINXさん

MITOUJTAG常備プランを開始します

回路のデバッグの必要性は突然やってきます。それが起きてからでは遅いのです。
いざデバッグしなければならないときに、JTAGデバッグツールが手元にないと、手遅れになります。

だから、金銭的なリスクなしに、いつでもデバッグできるという安心をお届けする「MITOUJTAG常備プラン」をスタートしました。貴方のオフィスに、置き薬のようなイメージでMITOUJTAG BASICを常に１台、常備してください。

もちろん、ご利用いただかなければ、費用は全く発生しません。
このプランをスタートしていただくにあたって、金銭的な負担は一切ございません。
リスクのない、「いつでもデバッグできる安心」が、無料で手に入ります。

ご利用のイメージは、具体的には次のようになります。

実際に、MITOUJTAG常備プランをご利用いただく際のイメージを写真でまとめました。

まず、本プランにお申し込みいただくと、MITOUJTAGの入ったダンボール箱が佐川急便で届きます。もちろん、お申し込みは無料です。

ダンボール箱を開封していただくと、中に、「返信用着払い伝票」「案内状」「内容物一覧」「小冊子 JTAGのツボとコツがゼッタイにわかる本」などの同梱物が入っています。この時点では費用は発生しません。

これらの同梱物は差し上げます。ご返送いただく必要はございません。

箱の奥にMITOUJTAG BASICとPocket JTAG Cableの入ったプラスチックケースが、透明なOPP袋（ポリエチレン製のピチッとした袋）に入っています。

この箱を取り出し、裏返してみると、OPP袋の綴じ目に封印シールが貼られています。

このシールを剥がして、中からMITOUJTAG BASICのケースを取り出すと費用が発生します。
ご注意ください。

もし、ご利用いただかなければ、このOPP袋の中身（MITOUJTAG BASICの箱）を、同封の着払い伝票を使って送り返してください。お客様には一円の費用負担も発生せず、このMITOUJTAG 常備プランを終了することができます。

なお、「小冊子 JTAGのツボとコツがゼッタイにわかる本」は無料で差し上げます。この小冊子は、新しい小冊子で、MITOUJTAGを使って様々なデバッグを行う際に役立つ事例が満載です。

この冊子はご返送いただく必要はございません。どうぞご活用ください。

以上のようなイメージです。

つまり、常備しておくのは無料です。実際に使う際に料金が発生します。

なお、このサービスは、まだまだ検討して改良していかなければならないと思っています。そこで、4月19日までにお申し込みいただいた方に限定させていただきます。また、Pocket JTAG Cableも同梱して送るため、それほど数に余裕があるわけではございません。そこで、大変恐れ入りますが、先着10名様に限定させていただきます。

つまり、先着10名様で、4月19日までにお申し込みいただいた方、ということになります。

詳しい案内や、サービスのご提供条件等は、こちらのページに記載しました。
「MITOUJTAG常備プラン」 http://www.tokudenkairo.co.jp/jtag/joubi.html

サービスのお申し込みは無料です。ご利用されなかった際の返送料金も無料です。どうぞお気軽にご利用ください。いつでもJTAGに頼れる安心をお届けいたします。

追記
お申し込みフォームを作成しました。

MITOUJTAG BASICの新しいサービス

「MITOUJTAG BASICを購入したいけど、迷っている」
「いますぐではないけど、近いうちに欲しい。」
「今は買えないけど、必要になったらすぐに使えるようにしておきたい。」
・・とお考えの方はいませんか？

明日、新しいサービスを発表します。

真夜中でも、土日でも、いざというときに納期＝ゼロ時間ですぐに頼れる、究極の安心をお届けするものです。
このサービスを開始していただく際に、お客様には金銭的な負担は一切ございません。
ただし、先着何名様かに限定させていただきますので、ご了承ください。
新サービスの詳細は、当ブログと、特殊電子回路のホームページで発表します。

では、詳しくは、明日。

＃どんなサービスか予想できたよ～という方は、コメントいただけるとうれしいです。
正解の方がいらっしゃいましたら、（ご希望なら）優先的に提供させていただきます。

PCI Expressのデザインアップロード

特電PCI Expressのサンプルデザインと、IPコア、デバイスドライバをアップデートしました。
・・・といってもまだ問題が多いので正式リリースとはせず、開発途中のβ版をアップロードしました。

ダウンロードはこちらから

だいぶんまともに動くようになってきたのですが、通常の転送中にISRの応答が行われたときに混乱するので、そういう状況で問題が出ます。進展があり次第、上記のURLにアップロードしていくつもりです。

ISE11でPack I/O Registersの設定オプションにご注意

Spartan-6の開発を行うにはXILINX ISE 11が必要ですが、ISE11のデフォルトの設定では、I/O内のフリップフロップが使われる設定になっていません。
このため、入出力のタイミングをきっちり正確に作ったつもりでも、予期しない遅延が入ってしまって、正確なタイミングを出せないことがあります。それは、周辺ICとのインタフェースにおけるセットアップ・ホールドタイムの不足や、論理合成後のタイミングエラーを引き起こします。

目安としては、5ns以下の制度で制御したいタイミングは、OFD（出力フリップフロップ）やIFD（入力フリップフロップ）を使うべきです。OFDを使うと、クロックから出力信号の遷移するタイミングが予測可能になるからです。

それに対して、スライス内のFFを使った場合は配線遅延が出てきますので、クロックから出力信号の遷移するタイミングは制御できません。UCFファイルにOUT AFTER属性を書けば最大値を制約することはできますが、最小値は制約できません。
やはり、OFDが必要なのです。

しかし、XILINXのプリミティブにIFDやOFDはありません。ODDR2を使う方法もありますが、面倒です。

具体的には、OFDやIFDは次のようにして「推論」させます。

process(clk) begin
if(clk'event and clk='1') then
input_signal_X <= input_signal_X_ip;
output_signal_X_op <= output_signal_X;
end if;
end process;

このように書くと、input_signal_Xやoutput_signal_XにはIOB内のIFDやOFDが適用されることが期待されます。
ISE9のころは推論されたのですが、ISE11ではそうなりません。スライス内の通常のFFが使われてしまいます。

この問題を回避するには、Implement DesignのオプションでProcess Propertyを開きます。

次にMap Propertiesタブを開いて、Pack I/O Registers/Latches into IOBsを見てみます。なんということでしょう。「OFF」になっています。
もちろん、「For Input and Outputs」に変更します。

こうして論理合成します。論理合成後のDesign Summaryで、IOB Propertiesを見たときに、IFF1やOFF1と書かれていれば成功です。

貴方の設計したI/Oは、設計したとおりのタイミングで動くでしょう。
逆に、この方法を使わないと、まず間違いなく高速インタフェースでは失敗します。論理合成時の偶然で動いたり動かなかったりということが起こります。ご注意ください。

DMAと他人の割り込みとの共存

昨日の問題が解決しました。

特電PCI ExpressボードがDMA転送を行なっている最中に、グラフィックカードが割り込みをかけてきて、特電PCIeのISRが呼び出されて、BAR0に配置した割り込みステータスレジスタを確認しにいっても、うまく動作しつづけられるようにしました。
DMA中にメモリ読み出しリクエストが来た場合、DMAを一旦中断させてメモリリードに応答し、その後、再びDMAに戻るようにしました。

これで、DMA中にInternetExplorerを数十個立ち上げようが、ISEのコンパイルを走らせようが、何をしてもびくともしなくなりました。合計100ギガバイトくらいのデータをやりとりしていますが、エラーなしです。

DMAに失敗する

開発中のPCI ExpressのDMA機能で、検証用のマシンを変えてみたら、かなりの頻度でデータのエラーが起きました。

データを128バイト単位でFPGA→PCのメインメモリに送っているのですが、DMAで転送されてきたデータを見ると、128バイト単位で転送されてきたデータが、途中から00になっていることが稀に起こります。

もし、伝送線路上で電気的なエラーが起きていたり、パケットの組み立てやプロトコル上の誤りがあると、パケットごと無効になるので、こうはならないはず。

だとすると、キャッシュの問題か、それともFPGAが間違ったデータを送ってきているのか。

最初に疑ったのは、キャッシュを制御する関数。
KeFlushIoBuffersという関数は、どうやら、wdm.hの中で
#define KeFlushIoBuffers(Mdl, ReadOperation, DmaOperation)
と無効化されているので、これではなさそう。

うーん。悩ましい。

#追記
原因がわかってきました。

問題の起こるPCでは、割り込み番号が、グラフィックカードの間で共有されています。

そのため、グラフィックカードで割り込みが発生した場合も、当ドライバのISRが呼び出されます。そして、当ドライバのISRでは、デバイスのBAR0に配置した割り込みコントロール、ステータスレジスタを読みにいきます。これがDMA中に行なわれると、アクセスがぶつかって、以後送信するデータが化けてしまうようです。

つまり、このIPコアは、今はDMA中はデバイスのステータスレジスタを読めないけど、割り込みを共有する他のデバイスが割り込みをかけたときにはDMA中でもデバイスのステータスレジスタを読まなければなりません。

自分のデバイスがDMAを完了したことは、割り込みによって通知するしかないので、さあ、どうしましょう、ということになります。メモリ空間読み出しリクエストが来たら、いったんDMAを中断して、そちらを優先するしかなさそうです。

割り込みを確実に受け取るために

DMA転送を1000万回くらいやっていると、PCの負荷が高いときに割り込みが受け取れていないことがわかりました。InternetExplorerを起動したりすると、すぐに割り込みを受け取れなくなります。

原因は単純なことでした。

今は、メインのDMA転送ルーチンでは、デバイスのDMA関係のレジスタをセットした後、イベントが来るまで待つようにしています。
DMAが完了すると、PCIeカードはINTA#割り込みを発生させます。すると、ISR（割り込みサービスルーチン）が呼ばれて、その中でDPC(遅延プロシージャコール)を呼び出して、DPCの中でイベントフラグをセットし、メインのルーチンが再開するという仕組みでした。

つまり、メインのルーチンでは
DMA転送開始→KeClearEvent→KeWaitForSingleObjectという流れでした。これらの処理は間に余計なものを挟まずに、連続して行っています。

しかし、DMA転送開始→KeClearEventの間で、（Windowsの負荷が高いときに）気まぐれでコンテキストのスイッチが行われるか何かして時間を食ってしまい、その間にDMA完了の割り込みが発生してしまうことがあるようでした。すると、イベントフラグは下がったままなので、KeWaitForSingleObjectでタイムアウトしてしまいます。

だから、
KeClearEvent→DMA転送開始→KeWaitForSingleObject
という順番にしなければいけないようです。この順番にしたら何千万回DMAをしても取りこぼすことはなくなりました。

だんだんドライバ開発の醍醐味が分かってきました。

次はスキャッタギャザーの実装にでも入るとしましょう。

割り込みのハンドリングはできたが・・

IoConnectInterruptを使って割り込みを受け取ることに成功しました。
割り込み処理ルーチンで遅延プロシージャコールを呼び出して、遅延プロシージャコールするところまでは成功。
DMAの転送完了待ちに割り込み適用するには、最初のIRPを保留にしておいて、遅延プロシージャコールで完了にすればよいのか。うーん。
Interfaceの2月号の記事（で紹介されているMicroSoftのPCIドライバのサンプル）がとても役に立つ。

割り込み処理ルーチンでは割り込み要因をクリアしている。だから、Windowsが応答したらINTA#が即座にDeassertされるはず。そんな状況で、押しボタンスイッチで直に割り込み発生させたら、割り込みが発生しまくって、Windowsがフリーズした。やっぱり割り込み処理ルーチンの中でDebugPrintとかしちゃいけない。

あとはスキャッタギャザー対応とか、割り込み発生をユーザのルーチンに伝えるしくみの構築とか、割り込み発生で次のDMAを行うしくみの構築とか、いろいろやることがある。ほとんどがデバイスドライバの仕事。

DMAの完了を割り込みで通知するようにした。INTA#をアサートしてから割り込み処理ルーチンが反応するまで約6μ秒要していることがわかった。結構かかる。

PCI Expressでの割り込みの発生

割り込みを発生させられるようにしてみました。

INTA#のピンをアサートする通知のメッセージパケットを送ってみました。

今度はデアサートする通知のメッセージパケットを送ってみました。

アサートが
34 00 00 00 01 00 15 20 00 00 00 00 00 00 00 00
デアサートが
34 00 00 00 01 00 15 24 00 00 00 00 00 00 00 00

これが何なのか、マニアじゃなければ見てもわかりませんよね。。

コンフィギュレーションレジスタでINTA#を使うように設定しておきます。
すると、デバイスマネージャで16番の番号が割り当てられました。

アサートとデアサートをしたので、割り込みが発生しているはずなのですが、何も起きません。（ブルー画面になるのを期待したのですが）

やっぱり、割り込みハンドラを作らないといけないようですね。

DMAによる長いメモリライトを実装

開発中のPCI Expressコアで、DMAによる長いメモリライトを実装しました。
128バイトを超えるサイズのデータを、128バイト単位に細切れにして複数回のMemWrトランザクションを発生させるというものです。

下の図は800バイト分のDMAを行ったところです。128バイトのペイロードを持つパケットが6個と、32バイトのが1個発行されました。

各パケットは920ns間隔で発行されているので、転送速度は128Bytes/0.92us = 139MBytes/secとなります。
問題は、コアがパケットを送ってからAckが返るまでの時間が長いこと。264nsもかかっているので、この時間が無駄となって、もっと密度を上げることができません。
本当はAckが返る前に次のパケットを送ってもよいのですが、そうするともっと速くなりそうですね。
でも、フローコントロールが必要になってきますので、FPGAのリソース使用率とのトレードオフになります。

最初に5回、PCからFPGAにむけて書き込んでいるのは、DMAの転送先アドレスや長さなどです。このオーバーヘッドはほとんど無視できるほどです。

PCI ExpressのDMA実装

ようやく重い腰を上げて、PCI ExpressコアにDMAと割り込みの実装をはじめました。
実は、昨年3月にも少し作業していたのですが、いろいろと不可解な現象にあたって途中であきらめていたようです。

DMAを実装する最大の理由は、FPGA→PC方向への転送速度の改善です。PC→FPGA方向はDMAを使わなくても、工夫次第で190MBytes/secくらい出ています。しかし、FPGA→PC方向が遅くて、DMAが必要ということになったわけです。

さて、今あるコアのDMAの問題点を洗い出してみると、
① DMAのバッファ用にアロケートするメモリが4096バイトしか取っていない
② MaxPayloadSizeやRCBにあわせて転送を細切れにすることができない
③ DMAの完了を知る術がない
④ DMAで送ってくるデータを入れる専用のポートがない

-----
①の問題。
DMAのバッファをどこに確保するかというのは、奥が深いテーマのようです。ユーザアプリケーションで使っているバッファ（つまりmallocとかで取ったやつ）の物理アドレスを調べて、そこめがけて転送するのがベストですが、何かと難しいようです。
しかし、カーネルモードでDMA用の安全なバッファを取るのが一番簡単ですが、安全なバッファとユーザバッファの間でデータをコピーしなければいけないので、DMAのメリットが出ません。ユーザのバッファをめがけてDMAする方法を、私自信、もっと勉強するしかないですね。

②の問題。
FPGA内にDMAコントローラを内蔵させることにしますま。数メガバイトとか数百Mバイトといったサイズの転送を128バイト単位で細切れにしなければなりません。スキャッタギャザーにも対応させたいです。
ユーザ回路とPCI Expressコアとの間には、やはりFIFOが1段くらいは必要になりそうです。
この実装は明日。

③の問題
やっぱり割り込みを実装するしかないですね。

④の問題
特電PCI ExpressコアにDMA用の制御信号を増設します。
component pciecore is Port (
　　・・　中略　・・
dma_cfg_c : in std_logic_vector(15 downto 0);
dma_sysaddr_i : in std_logic_vector(31 downto 0); -- PC内メインメモリの物理アドレス
dma_lcladdr_i : in std_logic_vector(31 downto 0); -- ローカル(コア上)のアドレス
dma_length_i : in std_logic_vector(9 downto 0); -- DW単位
dma_wr_req_i : in std_logic; -- DMA要求(FPGA->PC)
dma_wr_ack_o : out std_logic; -- DMA応答
dma_rd_req_i : in std_logic; -- DMA要求(PC->FPGA)
dma_rd_ack_o : out std_logic; -- DMA応答
dma_wrdata_i : in std_logic_vector(31 downto 0); -- 書き込みデータ
dma_rddata_o : out std_logic_vector(31 downto 0); -- 読み出しデータ
dma_addr_o : out std_logic_vector(31 downto 0);
dma_length_o : out std_logic_vector(31 downto 0);
dma_wdata_o : out std_logic_vector(31 downto 0);
dma_be_o : out std_logic_vector(3 downto 0);
dma_dvalid_o : out std_logic; -- DMA受信データ有効
dma_dreq_o : out std_logic; -- DMA送信データ要求
　　・・　中略　・・
);
これだけ作っておけば足りるでしょう。

---

さて、テストしてみます。まず、PC→FPGA方向への転送。
FPGAの中からPCのメインメモリに対して読み出しリクエストを行っています。

FPGAがリードリクエストして、PCが応答します。この場合、データを何バイト単位で返すかはPC内のチップセットが決めますが、やはり64バイト単位に細切れにされていました。

CombinedWriteの時と違うのは、MemRdに対するCompletionとしてデータが送られてきている点です。
この速度は190MBytes/secも出ていました。PCI Expressの帯域は200MBytes/secなので、良い結果でしょう。
しかし、CombinedWriteの時と速度は変わりません。

次に、FPGA→PC方向の転送。

おおっ、夢にまで見たバースト転送。このデータは、ちゃんとPC内のバッファに蓄えられていました。

しかし、まだ128バイトまでのDMAしかできません。128バイトを超えたときどのくらいの速度が出るかは、明日、試してみることにします。

DMAの実装は、FPGAだけではなく、ドライバもセットで作っていかなければならないから大変です。

Virtex-4&PowerPCの書き込みアルゴリズム改善

「JTAGひろば」のほうで、MITOUJTAGを使ってSUZAKU-Vに書き込みができない（PowerPCのプログラムが起動しない）というご連絡をいただきました。

そこで、SUZAKU-Vを購入して、試してみました。
まずJTAGをつなぎます。

そして、バウンダリスキャン。
うんうん。確かに何か動いているのが見えます。

そして、サンプルアプリケーションでCD-ROMに入っていたfpga-sz410-sil-101i-20090427.bitやfpga-sz410-101i-20090427.bitを書き込んでみると、確かに起動しません。
一体原因は何なのか。それに、赤や緑のLED、ジャンパはどういう意味があるのか？

忘れそうなのでメモしておきますと、SUZAKU-V基板の緑のLEDはただの電源確認です。赤のLEDはソフトウェアで光らせていて、Linuxのローダーか何かが走ると光るようになっているみたいです。ジャンパのJP2はINIT_Bにつながっていて、ROMからの起動を阻止します。JP1はソフトウェアから読まれるポートで、これがオープンだと、起動時にブートローダで止まるというもののようです。

JP1をショートして-silとかいうほうを書き込むと、ブートの段階で止まってスロットマシンのデモが動きます。7セグLEDは１２３と光ります。fpga-sz410-101i-20090427.bitを書き込むと、BBootが起動します。

いろいろデバッグした結果、MITOUJTAGでうまく書き込めるようになりました。

Virtex-4のPowerPCに対応した書き込みアルゴリズムのパッチは、暫定版としてこちらに置いておきました。

そのほかのいろいろな修正項目がまとまったら、MITOUJTAG1.5と2.1の次のサービスパックとして正式にリリースしたいと思います。