RS232C-JTAGの写真

R8Cを使った、RS232C-JTAGの写真をアップします。

R8C基板のほかには、抵抗5本、コンデンサ、LED、コネクタ以外には部品を使っていませんので、簡単に作ることができます。電源はターゲットボードのJTAGコネクタからもらいます。

DSUB変換コネクタを万能基板に丈夫に実装するには、ドリルで穴あけが必要です。それ以外は難しいところはありません。

使うときには、R8Cのデバッグケーブルでファームウェアを書き込んでから使用します。プログラムのROM化のやり方がよくわからないので、毎回HEWから転送しています。これではちょっと面倒ですね。

上の写真は、ヒューマンデータさんの、XSP-014Cにつないで実験しているところです。
XC2C256Cのバウンダリスキャンとかはできます。
ただし、R8Cのプログラムで一部完成していない処理があるので、SVF経由で書き込みがまだできません。
昔のDWM付録基板、CycloneにもSVF経由で書き込めませんでした。
もうちょっとデバッグが必要なようですね。

また、今年のDWM付録基板のSpartan3は全く認識できませんでした。

私がこれまで実験してきた感触によると、TCK信号の遷移時間がJTAGの成否に関係しているようです。
JTAG信号の電圧の振幅は十分でも、信号の遷移時間が遅いとうまく動作しないようです。JTAGを正常に動作させるためには、TCKが十分に鋭く立ち上がる必要があるようです。また、このあたりはSpartan3のデータシートにも書かれていないようです。あまり知られていないことですが。

今年のDWM1月号の付録基板で、74HC125でうまくいかない人が続出したのは、おそら、電圧の問題ではなく、TCKの立ち上がりの鋭さの問題です。だから、AC125に変えたり、HC14のシュミットのバッファを通すとうまくいくのでしょう。
R8CをつかったRS232C-JTAGにも、LVT***などのバッファを入れるように改良したほうがいいのかもしれません。部品が増えちゃうのは面倒ですが仕方ないですね。

USB-RS232C-JTAG

昨日のRS232C-JTAG変換アダプタですが、ELECOMのUSB-RS232C変換機「UC-SGT」を経由して、RS232C-JTAG変換アダプタへアクセスしてみたところ、劇的な速度の低下はありませんでした。
シリアルポートがついていないノートPCでも使えるようです。

RS232C-JTAG変換アダプタの開発

トラ技2005年4月号付録のR8C基板を応用して、「RS232C-JTAG 変換アダプタ」を開発しています。
付録基板に、RS232Cのコネクタと、JTAGのピンヘッダをつなげば、すぐにRS232C-JTAGとなるというものです。

ようやく、JTAGの一通りの機能が使えるようになり、バウンダリスキャンやデバイスの書き込みができるようになりました。
バウンダリスキャンは遅いですが、デバイスの書き込みはそれほど遅くはありません。
(XC9572に書き込みに約2分)

もちろん、JTAGロジックアナライザも動作しますが、バウンダリスキャン長=540で毎秒33回しか出せず、速度的には遅いです。

RS232Cの通信速度が115200bpsなのに、JTAGのスループットが平均してパラレルポートの10分の1くらいしか出ていません。

これは、RS232C上の通信にチェックサムを設けて、チェックサムが一致しないと動作しないようなアーキテクチャにしたのが原因です。なぜこうしたかというと、RS232Cの上で通信エラーが起きるかもしれないと考えて、互いにチェックサムの確認によってハンドシェイクをしようと思ったからです。(後から考えてみればあまりよくなかった)
ホストPC→R8C、R8C→JTAG、R8C→ホストPCというデータの流れがすべて半二重(いや半三重(？))なので、スループットが落ちています。
チェックサムを厳密にチェックするのをやめて、R8Cをもっと効率よく動かせば、5倍くらいは速くなりそうな気配です。

今回は、このRS232C-JTAG変換アダプタをデスクトップパソコンのRS232Cポートにつないで実験しましたが、ノートパソコンとかでUSB-RS232C変換アダプタを使ってもスループットが落ちなければ、面白いことができるでしょう。XPortのようなLAN-RS232C変換アダプタでも試してみたいですね。

Interface9月号 JTAGによるCPUデバッグ機能の詳細

Interface9月号に、連載「JTAG徹底活用研究（第5回）　JTAGによるCPUデバッグ機能の詳細」が掲載されました。本記事では、ARM7とMIPS32について、JTAGデバッガが内部でどのようなことをやっているかについて書かせていただきました。いかがでしょうか？

ご意見・ご感想をお待ちしております。nahitafu@nifty.comまでお気軽にお寄せください。
※なお、Yahoo、hotmailなど、フリーメールからのメールは自動的に削除されてしまいますので届きません。ご了承ください。

バウンダリスキャンセルとピンの状態

いままで、ALTERAのCPLDやCoolRunnerにEXTESTを行って、端子の状態をグラフィカルな操作で変更しようとしても、正しく反映されないことがあった。

この現象は、コンフィギュレーション前では正しくEXTESTできるのに、コンフィギュレーションした後ではうまくいかなかった。
しかも、これらのデバイスでは、JTAGをEXTESTモードにしてもクロックを認識し、内部ロジックは動いている。

どうやら、これらのデバイスでは、バウンダリスキャンレジスタの出力セルの構造が、他のデバイス(XILINX FPGAやXC9500シリーズCPLDなど)と、細かい点で異なるようだ。

現在改良中のMITOUJTAGでは、ピンのグラフィックを右クリックすると、その内部構造を図示するようにしている。この絵を即座に見るとわかるように、EXTESTモードでピンが出力状態でありながら、入力セルと出力の値が一致していない。

クリックで拡大

ALTEAR CPLDやCoolRunnerでは、EXTESTモード時に、出力セルの値は内部ロジックが出力しようとしている値になっているようだ。実はこれは正しい。
一方、XILINX FPGA等では、EXTEST時の出力セルから読み出される値は、バウンダリスキャンで入力された値になっている。Spartan3やVirtex2の場合、これも正しい。

何が正しいかは、BSDLファイル中に記述されているBC_1とかBC_2という記述がその情報を少し与えてくれているのであるが、それに記述された情報と、実際のデバイスの動作は必ずしも一致していない。
しかも、CPLDやFPGAのようなPLDでは、コンフィギュレーション前後でJTAGバウンダリスキャンのふるまいが変わってもおかしくない。バウンダリスキャンセルの順序が入力→出力→制御か、といった順序にも関係があるかもしれない。
IEEE1149.1の規格書と、各デバイスのBSDLファイルと、データシートに記された内部構造を見ているが、未だにはっきりしないデバイスがいくつかある。

ブロックRAM活用!! JTAGロジアナ新機能

JTAGロジックアナライザのあたらしい機能を開発中です。

新しいロジアナ機能は、FPGA内のブロックRAMに波形を超高速で溜め込み、それをJTAG経由で読み出して表示するというものです。このような方式では、FPGA自身の動作速度でサンプリングすることができます。
この機能を使うには、VHDLファイルの中に、下記のような非常に簡単な記述を付け加えるだけで、どのようなデザインにも簡単に埋め込むことができます。

次の波形は、SDRAMコントローラのRASやCAS信号やアドレス等を、この新ロジアナ機能で観察した図です。
SDRAMコントローラはクロック40MHzで動作しており、ロジアナは36本の信号を25n秒周期でキャプチャしています。

シングル書き込みシーケンス。途中で1回リフレッシュが入っている。
クリックで拡大

試しにXC3S50に実装してみたところ、36ビット幅で512サンプリングのロジアナを構成した場合、スライスを80個使用し、最大約200MHzで動作するようです。

今回開発したロジアナは
　・非常に簡単なインタフェース
　・VHDLのどの階層にあってもOK
　・パラメータはgeneric渡し
　・genericで渡したパラメータは、JTAG経由で自動的に読み出される
　・トリガーはユーザが自由に設計したロジックで構成可能
　・WebPACKにも対応
という、他にない長所を持っています。

この新しい機能は、まだ開発がはじまったばかりで、安定性や使い勝手の面で改善すべき点はいくつかあります。今後、私がいろいろなFPGAの開発を行っていく中でより洗練し、近い将来MITOUJTAGに実装してリリースする予定です。

従来のバウンダリスキャンによるJTAGロジアナと、今回のブロックRAMによるJTAGロジアナを上手く組み合わせることで、さらに効果的なデバッグが可能になるものと考えています。ご期待ください。

ALTERAのピン定義ファイル

ALTERAデバイスのピン定義用に、MITOUJTAGの次のバージョンからは、.QSFファイルも読み込めるようになります。

ALTERA CPLDへの書き込み

ALTERAのCPLDである、MAX IIシリーズ用デバイスプログラミングツールを開発中です。
MITOUJTAGから、MAX IIデバイスへ書き込みができるようにしています。

QualtusIIで作成したPOFファイルをCPLDに直接ダウンロードできるようになりました。
SVFファイルやJAMファイルを経由する必要はありません。
とりあえずは動作しますが、いろいろな検証を行う必要があるので、リリースはしばらく先になります。

ご期待ください。

LEDチカチカデバッグ

あるマイコンを使うことになった。
動作を見てみたいので、サンプルプログラムを書いて、
部品棚にある適当なLED(新品)をつないでチカチカさせようとしたが、
まったく光らない。
どれだけソースコードを見ても問題ないし、ツールの使い方も問題なさそうだ。
いったい何が悪いのか・・・

どうやら、使ったLEDが赤外LEDだった。

本日の教訓：赤外LEDと普通のLEDを同じ場所に保存してはいけない。

技術士第二次試験の受験票届く

技術士第二次試験の受験票が届いた。
受験願書の業務経歴の書き方に問題はなかったらしい。
（大学院２年＋技術士補２年で受験資格はOKということ）

今年は８月まで仕事がいっぱいなので、果たして受験できるかどうかが一番の問題だ。
とりあえず、秋葉原に寄って論文対策の本や、電気電子の対策本を買う。
いろいろ良いことが書いてある。さすが書籍。

IBUFGとBUFGの違い

IBUFGというコンポーネントがあるが、IBUFGとBUFGは全く別物で、IBUFGの出力はBUFGの出力(グローバルクロック)にはならないようだ。
つまり、
IBUFG≠IBUF＋BUFG
である。
少なくとも、Spartan2とSpartan3とVirtex2Proではそうなった。

なぜこんなことが気になったかというと、CoregenでDCMを合成すると、CLKIN_IBUFG_OUTとCLK0_OUTという同じ周波数の2つの出力が作られる。
ここで、CLK0_OUTを使っていればよかったのだが、CLKIN_IBUFG_OUTを使ってしまった。

そして次の図のような回路を組んだときに、下側の青いクロックで組んだ回路のスキューが非常に大きく、ハマったからである。(ハマりの詳細については前回と前々回を参照)

このとき、FPGA内で使用されるグローバルクロックは、上の図の赤い線の部分の２つのクロックであって、青い線のクロックはグローバルクロックではなく、ローカルな配線を使用しているため、非常に遅くなってしまったようである。

次の図は、1026ビットのシフトレジスタと、バイナリカウンタをVirtex2Proにインプリメントしたときの合成結果である。

明らかに重い。Localと書かれている点に注目。
これをFPGA Editorで見ると、確かにローカルの配線を使っている。

一方、次の図はCLK0_OUTを使った場合の合成結果である。

今度はBUFGMUX７Sと書かれている点に注目。

さらに、次のリストのようにDLLやDCMを使わない場合であっても、クロックの入力をIBUFGに通したけどBUFGを通さない場合、この場合も遅いローカル配線に接続されてしまうようである。

なお、アンサー#5304によれば、IBUFGはDLLまたはBUFG専用の入力信号であって、DLL への入力として使用されていない場合は、遅延が増加することがあるそうである。確かに実感。
http://www.xilinx.co.jp/xlnx/xil_ans_display.jsp?iLanguageID=2&iCountryID=2&getPagePath=5304

アンサー#11756には、IBUFG→DCM→BUFGというクロックの構造が描かれている。
http://www.xilinx.co.jp/xlnx/xil_ans_display.jsp?iLanguageID=2&iCountryID=2&getPagePath=11756

ところで、FPGAエディタでいくら見てもIBUFGの正体が見えない。その配線は単なる入力パッドからの出力であって、通常の配線と何らと変わらないように見える。ロングラインすら使われていない。
IBUFGの出力というのは、実装上は、DCM(DLL)やBUFGの入力やRocketIOのREFCLKのどれかにつなぐためのローカルな配線なのだろうか。

今回は、クロック入力にIBUFGだけを使うと、かえってパフォーマンスが悪くなるという教訓を得た。IBUFGはBUFGとセットで使わなければならないようである。

※検証に使ったツール ISE6.2

ESECに行けない

ESECに行きたい。だけど、忙しすぎて行けない

昨日のVirtexII Proのクロックの件、どうやら、クロックのソースが弱かった模様。
メインのクロックからDCMで、変な倍率の周波数のクロックを作り出し、それらがブロックRAMの各ポートにアクセスするようなアービタのようなものを作っていたのだが、どうやら、メインのクロックがFPGAに入ったところで、弱い何かにつながってしまったようだ。
結局、メインのクロックをDCMに通すように明示的に指定したら、ドライブ能力が強力になって、解決した。

しかし、スキューが発生して、Holtタイムが満たされなくなると、ISEのImprementation(の中のRoute)が非常に遅くなるというのは、ちょっとした発見かも知れない。
具体的には、次のような箇所で重たくなる。
-------------------------------------------------------
Phase 4: 1473 unrouted; (424) REAL time: 38 secs
Phase 5: 1479 unrouted; (0) REAL time: 39 secs
Phase 6: 1479 unrouted; (0) REAL time: 39 secs
Phase 7: 0 unrouted; (0) REAL time: 41 secs
★　ここで非常に時間がかかってしまう！！　★
Total REAL time to Router completion: ・・・ secs
Total CPU time to Router completion: ・・・ secs
-------------------------------------------------------

ちょっと時間ができたら、詳しく調べてみようと思う。
確実にこの現象を発生させられる方法もみつけたい。