先日発売されたInterface誌の連載「ＪＴＡＧ徹底活用研究第4回 JTAGによるフラッシュ・メモリへの書き込み」はいかがでしたでしょうか？
本記事では、FPGAやCPUなどにつながったフラッシュROMを、JTAG経由で間接的に書き込む話について書かせていただきました。
ご意見・ご感想をお待ちしております。nahitafu@nifty.comまでお気軽にお寄せください。
※なお、Yahoo、hotmailなど、フリーメールからのメールは自動的に削除されてしまいますので届きません。ご了承ください。
JTAGロジックアナライザを改良中です。
いままでのMITOUJTAGのロジックアナライザは、数百種類の信号、数万ポイントといった多量のデータを取ると、解析と描画に非常に時間がかかってしまい、重い動作となってしまっていました。
そこで、解析ルーチンと描画ルーチンを徹底的に見直し、劇的な高速化を実現しました。
これまで、データが多いときに感じていたストレスが全くなくなり、非常にスムーズに動くようになりました。また、Mobile JTAG Cableの高速化とも合わさり、非常に快適になりました。
また波形の表示も四角くしました。
JTAGロジアナの改良は、他にはサンプリングタイミングの指定、カーソル機能、信号名のソートなどの機能充実を予定しています。近いうちに次のバージョンをリリースすることができるでしょう。
早く明日の資料もつくらなきゃ・・
MIPS命令互換のCPUには、NECのVR4131という64ビットの組み込み用CPUがあります。
MIPSのCPUをJTAGでデバッグする仕様といえばEJTAGですが、最近、EJTAGのルーチンを開発中だったので、VR4131でもJTAGデバッグができないか試してみました。
使用したボードは(有)ハンブルソフト殿のN-Cardです。
VR4131をはじめとして、NECのVRシリーズにはJTAGの信号を利用したN-Wireというデバッグ方法があります。これがEJTAGと似ていればいいのですが・・・。さっそく開発中のEJTAGデバッガにつないでみましたが、全く認識しません。やはり、N-WireとEJTAGは根本的に違うようです。
N-Wireには、JTAGでいうところのTDI,TMS,TCK,TDO,TRSTなどの他に、NWIREENとBKTGIOという信号があります。Googleで調べると、NWIREENはN-Wireを使うときにはHにしておくとのこと。BKTGIOはよくわかりませんが、入出力双方向とのことです。おそらくCPUをブレークさせたい時やCPUがブレークしたことを知るための兼用の信号でしょうか。とりあえずプルアップ。信号の接続は問題ないようです。
JTAGでのレジスタの実際の操作の仕方ですが、N-Wireについては公開されている情報が何もないので、力技で調べてみることにしました。
まず、IR(命令レジスタ)の長さがわからなければどうしょうもありません。TAPをShift-IRステートに遷移させて、適当なデータをTDIから流してみると、TDOから8ビット遅れて出てきます。IRの長さは8ビットといっていいでしょう。しかも、IRの初期値は00000001なので、ラッキーなことにこの点はJTAGに準拠しています。
IRが8ビットとわかったので、IRに0x00～0xFFまでを順番に入れていって、DRの値を読んでみます。DRは32ビットくらいを仮定しておけばよいでしょう。
何らかのデータが出てきたものは、
IR DR
0x04 0x00430C83
0x08 0x00000102
0x09 0x000040CC
0x0a 0x00300000
0x10 0x7000003E
0x11 0x7000003E
・・・
0x17 0x7000003E
これらの値にどんな意味があるのかは全くわかりませんが、上の表の0x000040CCは動作中に60CCになったり変化します。
また、IR=0x01ではDRに1ビットのレジスタが選択されます。このあたりの意味もわかりません。
ちょっとした発見は、リセット後、IRに0x0aを入れてDRに0x00000000を書くとリセットがかかるようです。その後でDRに0x00000001を書いて0x00000000を書くと再度リセットがかかります。
IR=0x0Aでは制御レジスタか何かが選択されるようで、そのbit0はリセット信号なのでしょう。
しかもTDIから入ったデータは32ビット遅れてTDOから出てくるので、このDRの長さは32ビットと推定されます。
また、IR=0xFF(BYPASS)で1ビットのバイパスレジスタが接続されるようにもなりましたが、IR=0x00(EXTEST)を行ってもバウンダリスキャンレジスタらしきものは見当たりません。残念ながらVR4131はバウンダリスキャンには対応していなさそうです。
N-WireとEJTAGは全くの別物であることがわかったことが今回の発見です。N-Wireについてはこれ以上深追いせずに、また機会があった時に試してみることにしましょう。
※この記事の内容は無保証ですのでご注意ください。
Mobile JTAG Cableの高速化と動作安定化を目指して改良を行っています。
右の図は、いままでのMobile JTAG CableでキャプチャしたJTAGロジアナの波形です。Mobile JTAG Cableには非同期モードという動作モードがありますが、これはUSBのフレームのタイミングに合わせて送受信しているので、1msごとにサンプリングしていました。よって、毎秒1000サンプル程度が限界でした。
次の図は、改良中のMobile JTAG CableでキャプチャしたJTAGロジアナの波形です。
TCKのレートを3.1MHzまで向上させると同時にUSBの転送タイミングもそれに合わせることで、綺麗な波形が高速に取れるようになりました。XC2S100に対して使用した場合、ほぼ4倍に速度が改善されます。
拡大すると、右の図のように256μ秒で変化する波形も綺麗に見えています。
この改良では、Mobile JTAG Cableの中のFPGAの設計は変更せず、ソフトウェアのみで対応しています。（いずれFPGAの設計の改良も行うことで更なる高速化を行うことを目指しています。）
XC9572などのCPLDでは毎秒10000サンプリングほどできます。Virtex2Proなどの大きなデバイスでも順調に動作しています。
ただ、デバイスによってバウンダリスキャンレジスタ長が変わるので、USBの転送タイミングを適切に調整しなければならないのが難しいところです。
MITOUJTAGの次のバージョンでは、Mobile JTAG Cableの高速化対応と、ロジックアナライザの改良(サンプリングタイミングの指定や、時間を計るカーソル機能、操作性の向上、描画速度の向上など)を予定しています。
ご期待ください。
今年も多くの方にIPAXにお越しいただき、誠にありがとうございました。
さて、ある理由があって、ある新規のデザインでSpartanXLが使えないかどうか検討していました。デバイス自体はまだ入手できるのですが、どうやら開発ツールがSpartanXLはサポートしていないのです。
仕方なく古いWebPACKを探してみるも、WebPACK3以降はSpartanXLは扱えなくなっています。(その前はというと、無料WebPACKではFPGAはサポートされていなかったような気が・・)
XILINXのWebサイトでWebPACK Classicを見て、その中でSpartanXLを扱えるという「spartan4k.exe」を見つけ、早速ダウンロードし試してみみましたが、プロジェクトを作るときに、VHDLとかVerilogとか回路図とか選ぶところでEDIFとしか出てこないのです。まさか、EDIFで入力するわけにはいきませんし。
もう一度WEBをじっくり読んでみると、これはフィッターだけあってデザインの入力ができない。デザインの入力はサードパーティーのツールを使うように。と書いてあるように読めます。
デザイン入力用に古いWebPACK3.3を組み合わせてみましたが、DLLが何たらと言って起動できず。
もっと古いXILINX Foundationのバージョン1をインストールしてみようと思いましたが、これも断念。
結局、新規のデザインにSpartanXLはあきらめた方がいいのかもしれません。PDN2004-01に製造中止品と書かれていて、最終注文日が2005年3月5日で最終納期が2005年9月5日となっています。残念。
SmartJTAGの高速化を行うため、EZ-USB FX2のファームウェアをアセンブラでガリガリと書いて最適化しました。
最適化とはいっても、EZ-USBは8051なので、限界が見えてしまいます。ほとんどの命令は8～12クロックも使ってしまい、クロック48MHzでももっさりとした動作です。
＃遅いマイコンを触ったあとでWindows上でのプログラミングを行うのは気持ちのいいもので、Pentiumってなんでこんな速くいの!?って感じてしまいます。
将来的には、USB2.0 HighSpeedのマイクロフレームの効果によるキビキビした応答性と、FPGAによる正確かつ高速なタイミング発生ができるUSB-JTAGインタフェースを設計したいですね。
さて、下の図は、XC2S100の信号を従来のSmartJTAGでロジックアナライズした絵です。8.192msごとに変化する信号は見えるものの、4.096msごとに変化する信号は全く見えません(エイリアシング)。ということでサンプリング速度はだいたい4～8msの間ということになります。
次の図は、高速化されたバージョンです。
XC9572のバウンダリスキャンだと、毎秒1500回くらいでした。
設計値では、ロジアナは7倍に高速化され、フラッシュメモリ書き込み速度は14倍になります。JTAG-ICEも耐えられる速度になりました。
これで書き込んだFPGAはちゃんと起動するし、各種CPUもちゃんとデバッグできるので、大きな問題はないのでしょう。
これからしばらくの間は動作検証が続きますので、出荷は来月くらいになります。
引き続き、MIPS用JTAG ICEの開発をつづけています。
MSDOSプロンプトからコマンドを打つことで、CPUの汎用レジスタやCP0レジスタの書き換えや、メモリの書き換え、シングルステップ実行ができるまでになりました。
でも、JTAGデバッガ上で変なアドレスをたたくと、JTAGデバッグから復帰したときに、YAMONに「おまえ、TLBに載ってないところ触ったろ！？」と怒られてしまいます。
* Exception (user) : TLB (load or instruction fetch) *
CAUSE = 0x00808008 STATUS = 0x00000002
・・
YAMONに気づかれないようにいろいろとできればいいのですが・・
うーむ、それにしてもJTAGデバッガって面白いですね。
MIPSのJTAGデバッグ機構はEJTAGといいますが、これを利用したデバッガを開発中です。
MIPS32とかMIPS64とかのCPUを、シングルステップ実行させたり、メモリやレジスタの中身をJTAG経由で読み書きする機能です。これは本来動作しているのプログラムとは無関係に強制的に動作するので、ROM上にプログラムがない状態でも使えてしまうというものです。(いや、変なプログラムが書かれているとEJTAGが使えなくなることもあるようだが、究明中)
EJTAG仕様書を見ながら、AlchemyのAu1550に強制ブレークをかけると、YAMONさん(MIPS用高機能モニタデバッガ)に「勝手にデバッグするな!！」と起こられてしまいました。
(絵をクリックで拡大)
気を取り直して、順序よくEJTAGを操作していくと、ちゃんとメモリの内容やレジスタの内容を読み書きすることができるようになりました。
(絵をクリックで拡大)
このスクリーンショットは、フラッシュメモリの0番地に書き込まれているデータを、JTAG-ICEで読み出しているものです。(メモリダンプはShiftJISを気にしていないので、文字コードの切れ目で化けていますが・・・。さらに、よく見るとアドレスカウンタが変わってませんね(笑)
近いうちにWindows上からGUIでEJTAGを気軽に触れるアプリケーションに育つことでしょう。あとは動作速度の改善と、EJTAGのデバッグから復帰したときにYAMONさんに見つからないようにすること、逆アセンブラの搭載かな。
IPAXの展示内容詳細を決めました。パンフレットを印刷屋さんに発注。オフセット印刷の仕上がりが楽しみ。
さて、今年はただのソフトウェアの展示だけではなく、組み込み機器のデバッグにおいてMITOUJTAGを使ってどのような場合にどうすればよいか、という活用ノウハウを充実させて紹介したいと思っています。
MITOUJTAGをつかうと組み込みのデバッグがこんなに楽になる、というデバッグの楽しさをお伝えできればと思います。
また、MITOUJTAGJTAGを応用した新しいソリューションの提案もいたします。
多くの皆様のご来場お待ちしております。
詳細はこちら
VirtexII Proの中のPowerPCを動かそうと、EDKで開発。
PowerPCと、UARTと、4ビットのLED用GPIO、そしてデータ・命令兼用のブロックRAMを入れてみた。
ブロックRAMは、アドレス0xffffc000～0xffffffffにマッピングされている。
OCMのバスは使用していない。
これらのCPU一式をSubModuleとして、上位のモジュールをVHDLで開発した。
上位のモジュールはRocketIOを4基備えている。
ISE6.2で全体をSynthesize(中でEDKが動作)+Implementすると、約６分３０秒かかった。
そのうち、EDKでの処理に３分程度かかっている模様。
MicroBlazeの時よりはずっと速い気がするのだが、それでもずいぶん待たされる。
ハードウェアを変更せず、FPGAの中に組み込んだソフトウェアの変更だけならば15秒ほどしかかからないが、FPGAのロジックを変更しようとすると、３～６分程度かかってしまう。
なお、CPU一式を外して、上位のモジュール(RocketIO周辺のみを実装)だけだと、Synthesize+Implementで１分しかかからない。
PowerPCを使うために毎回プラス２～５分の合成時間が必要ということになると、ちょっとためらってしまう。
FPGAの中に作りこんだレジスタをRS232で身をいろいろと操作したいだけなので、UARTとステートマシンで頑張りたくなってしまう。
今日の収穫は、EDKの中で書くソフトウェアのためのライブラリのリファレンスは下記のファイルの中にあることがわかったこと。下記のファイルはWebで検索すればすぐに見つかる。
・xilinx_drivers.pdf UARTやGPIOや、IICなど、各種IPのリファレンス
・edk_libs_ref_guide.pdf xil_printfなどのリファレンス
OPBとかLMBとか慣れない用語と格闘しつつ、ついにEDKの使い方をマスターした。
そこで、XC2S100に、MicroBlazeを入れてみた。
4ビットのLED(GPIO)と、RS232Cと、debug_moduleを入れた状態で、
Number of SLICEs 847 out of 1200 70%
CPUコアには命令バスとデータバスがあって、それぞれのバスは独立しているが、同じブロックRAMのポートAとポートBに接続できる。
こうして、ブロックメモリは全体の80％を使用。(全部で4kBytes)
MicroBlazeは、debug_moduleというのが優れもので、FPGAの中でBSCANマクロを使って、JTAGから送られてきた信号を、内部でUARTに変換して、なにやらデバッグを行うらしい。このモジュールはいくらかのハードウェアリソースを消費する。ソフトウェア(xmdstub.elf)をメモリに常駐ささせるタイプのようだ。
別のインプリメンテーションでは、GPIOとSDRAMインタフェースを入れることもできた。SDRAMを命令兼データ用メモリとして使えれば、もっと面白いことができるかもしれない。
MicroBlaze 偉い！JTAGでデバッグできる！
大型連休を利用して、VirtexII ProのRocketIOをカスタムモード(GT_CUSTOM)で動かしてみました。
RocketIOというのは、XILINXのVirtexII ProやVirtex4などのFPGAに内蔵されている高速シリアル通信インタフェースで、これを使うと1チャネルあたり最大3.125Gbpsの通信が行えます。
XILNIXのアプリケーションノートには8b/10bをバイパスした設計例はいくつかありましたが、内蔵8b/10bを活用した設計例は見つけられませんでした。
そこで、試行錯誤の末、RocketIOの使い方をマスターできました。
私がRocketIOを動かす上で、ポイントだと思った箇所を書きます。
★マニュアルの熟読
ユーザーガイド（UG024）にはすべて目を通すこと。読み飛ばしていい個所は、Visetteディスパリティ、チャネルボンディング、CRCそして第4章、付録AとC。これ以外の箇所は細部まで重要。
特に、デジタル部の設計ではこのマニュアルと東京エレクトロンデバイス殿のWebサイトにある資料「wb_Rocket_IO_Manual_rev20」を熟読すること。
アナログ部の設計(基板設計と電源フィルタ、部品の選定など)は、wb_Rocket_IO_Manual_rev20とUG024、そしてアプリケーションノートを熟読。
★デバッグの順序(送信側)
１ ありえないK符号を送信し、TXKERRが立つことを確認。
２ 適当なK符号やD符号を送信し、TXRUNDISPが正しく変化することを確認。
３ カンマやIDLEにどのようなK符号を使うかを決める。
これは、ユーザが勝手に決めていいのだが、GigabitEtherやFiberchannelを参考にして合わせても良い。カンマでもIDLEでもないダミーのK符号(自分専用)も決めておくと便利。
なお、ユーザガイドにはK28.7をプロトコルに使用するなと書かれている。ビット配列が0011111000と単純なためだろうか。
４ 以下のようなフレームを連続して繰り返し送信する機能を作る。これで受信側のテストに備える。
COMMA、適当なデータ(乱数など)・・・、IDLE・・・
順番は適当でよい。
★デバッグの順序(受信側)
１ 送信側と異なる水晶モジュールを使って実験し、RXRECCLKが復元できることを確認。
２ RXCOMMADETが見えるか
（*COMMA_DETECTや*COMMA_10B_VALUEアトリビュートなどの設定が必要）
３ RXCHARISKが見えるか
（長いK符号の列を送ると、弾性バッファの影響で多少不思議な挙動をするかも）
４ 受信ステートマシンを作って、データの中身をチェック
→LFSRで作った乱数を送受信するなどして、データを検証
次に、ユーザガイドや、wb_Rocket_IO_Manual_rev20を読んでもなかなか掴めなかったポイントを以下に書きます。
★GT_CUSTOMでは、以下のアトリビュートの設定は必須
・CLK_COR_SEQ_*_*
→これは、IDLEの符号を指定する。これを入れないと送受信間のクロックの差を吸収することができず、エラーが頻発する。
これは11ビットのベクトルである。最上位ビットは8b/10bをバイパスする(1)か、否(0)かの指定。8b/10bを使用する場合、9ビット目はK符号かD符号かを表す(マニュアルに詳しく記載されていない？)。
・CLK_COR_SEQ_LEN 16ビットモード時には、当然、「２」でしょう。
・M/PCOMMA_10B_VALUEと関連するアトリビュート一式。いわゆるカンマの符号を設定する。
★その他のポイント
・RXCHARISCOMMAとRXCOMMADETの違い。RXCHARISCOMMAは8b/10bと弾性バッファの後ろなので、クロック補正などの影響を受ける。
・RXCOMMADET *COMMA_DETECTに影響を受ける
・RXCHARISCOMMA DEC_*COMMA_DETECTに影響を受ける。K符号すべてに反応！？(MCOMMA_10B_VALUEとかで設定した値が反映されない！？)
・再アラインメントは行ってくれないと思ったほうがいい。
・16ビットモードならば、クロックコレクションのシーケンス長を２にすること。１だと補正の時にバイトの上位下位がひっくり返ってしまう。
・8b/10bを使用する場合、送信ディスパリティの計算は自動で行ってくれるようだ。ユーザがTXCHARDISPMODEとTXCHARDISPVALを触る必要はない。
・1.2Gbpsくらいでは内蔵シリアルループバックは正常に動作したが、2.5Gbpsでは内蔵のシリアルループバックがうまくいかない。なぜ？何か設定を間違えたか？
・送信電圧を増やすと消費電流が増加。かなり熱くなる。きちんとした基板と伝送線路なら最小電力でも十分。
・カンマの値は、マスクを利用して複数の値を設定するのではなく、１つの値に特定させたほうがデバッグが楽。
・作動ペアの片側をはずしても2.5Gbpsでそれなりに通信できる。ただし、多少エラーは発生する。頻度は未測定。しっかりしたエラー訂正を行えば1本線での通信ができないだろうか。(邪道か？)
最近のコメント