入力DC電圧特性～XC2C256の場合

CPLDやFPGAに限らず、ほとんどのICは、入力端子に加わった電圧が
ある電圧以上なら'H'、ある電圧以下なら'L'と認識するようにできている。

CMOS ICだと、HとLの境目はだいたい0.5*VCCになるのであるが、
中身はCMOSでも、入力特性だけはTTL互換やLVTTL互換にしたICはいっぱいある。

そういうICは、入力特性が
　VIH High level input voltage 2V(min)
　VIL Low level input voltage 0.8V(max)
というように、0.8V以下を'L'、2.0V以上を'H'とするようにできている。

XILINXのCPLD、XC2C256も例外ではない。
データシートによれば0.8V以下は'L'で、2.0V以上は'H'である。

さて、この中間の電圧、たとえば1.6Vを入力したらどうなるか？

実際にやってみた。
まず、CPLDを消去して空にした状態で、半固定抵抗をつかって0V～3.3VまでのDC電圧を作り出し、入力ピンに加えていく。
そして、'H'と認識したか、それとも'L'と認識したかを調べる。これはバウンダリスキャンを使って、CPLDがブランク状態のまま調べる。

結果は、下の図のとおり。

なんと、ヒステリシス特性をもっていた！

入力が既にHと認識されているときに1.2Vくらいまで入力電圧を下げないとLにならず、Lと認識されているときには2.0V近くまで上げないとHと認識されなかった。
確かにCoolRunnerIIにはBus-Hold回路というのが入力に入っているのだけれども、これはプログラムされるまでは動作しないはずである。だからなぜヒステリシス特性が生じたのかは分からない。

世の中の全てのデバイスがこうなっているとは限らないし、私が使ったCoolRunnerではたまたまこうなっただけかもしれない。
CPLDに限らず、TTL特性やLVTTL特性のICの入力に0.8V～2.0Vまでの電圧を入れる可能性があるときには注意した方がいいだろう。

データシートの些細な寸法の違い

RSコンポーネンツで扱っている、PCB実装型LEDがある。
ライトアングルで赤と緑の2つのLEDがついているやつだ。

　┏━┓
⊂　　 ┃
⊂　　 ┃
　┗━┛
　　 　||
こんな感じのイメージのLEDである。

筐体設計のため寸法を計算しようと、RSの寸法図をみると、下のLEDの中心は底面から2.45mmとなっている。
そして上のLEDの中心はそこから5.08mmの高さにある。

2.45…？
これは、2.54の間違いじゃないかと思い、データシートを読んでみると、2.45[0.100]となっている。
0.1インチは2.54mmなので、2.45か、2.54か、どちらかが正解だ。
RSの寸法図はこのデータシートをもとに起こしたものなのだろう。

0.1mmにも満たない差であるが、悩ましい。
このメーカーはインチでサイズを設計しているようなので、インチを信じることにしよう。

水晶と負荷容量とEZ-USB FX2

昨日から引き続き、USB2.0のための水晶発振回路について考えています。

USB2.0 Spesificationによると、USB2.0のHighSpeedモードの周波数は480.00Mbpsなのですが、実際には479.760～480.240Mbps、すなわち500pmまでずれが許されているようです。

一般の水晶モジュールや水晶振動子の周波数は±50～100ppmなので、ジッタがなければ水晶をUSB2.0の原発振に使うのは問題ないでしょう。

さて、EZ-USB FX2LPでは、負荷容量が12pFの水晶が要求されるようになりました。12pFという文言があちこちに書かれています。

負荷容量というのは、水晶デバイスに指定されている一種のパラメータで、その容量の負荷容量をつないだときに、水晶は望みの周波数で共振するというものです。

もちろん、負荷容量が定格ぴったりでなくても水晶は共振しますが、負荷容量が大きいと周波数は下がり、負荷容量が小さいと周波数は上がる傾向があるようです。
すなわち、負荷容量が合っていないと周波数がシフトします。

この周波数のシフトがどれくらいかということですが、普通に負荷容量がミスマッチしている状態では、±40～60ppmくらいではないかと私は思います。いろんな水晶のデータシート等をみたところ、たとえ16pF用の水晶を12pFや24pFの負荷容量で使っても、200ppmもずれてしまうことはあまりなさそうで。温度変化や経年変化を考えても考えにくいです。

そうすると、EZ-USB FX2LPが12pFの負荷容量の水晶を要求している理由がわからなくなります。例えば16pFの負荷容量の水晶をつかっても、負荷容量が16pFになるようマッチングさせれば周波数は正確になるのですから。
おそらくEZ-USB FX2LPは、低消費電力化に対応させるため、ドライブ電流を減らしたためか、もしくは発振用のアンプの安定度などが変わったのではないかと私は推測しています。

つぎは、機会があれば、発振用アンプと負荷容量の関係について考察してみます。

水晶なんてどうでもいいと思ってきたけれど

せめて今夜だけでも 綺麗(な波形)になりたい～♪

EZ-USB FX2(CY7C68013)というデバイスがあります。
このデバイスは非常に消費電流が大きく熱いデバイスなのですが、EZ-USB FX2LP(CY7C68013A)という低消費電力版も出ています。これは、基本的には上位互換なのですが、アプリケーションノートによれば、水晶の負荷容量CLを12pFにするようにと書かれています。(CY7C68013では20～33pF)

ところが、事実、CY7C68013AはCL=12pFではない水晶でも発振します。
しかし、もし違う容量のものを使ったら、発振周波数がシフトする影響があるかもよ、とアプリケーションノートに示唆されています。これは一体、どういうことでしょうか。

負荷容量というのは、下の図のように水晶からみた回路の容量のことで、水晶の横に付け加えれれたコンデンサの容量と基板のストレ容量の並直列になります。

負荷容量は、外付けするコンデンサや基板の出来で決まる値ですが、
一般に水晶は、負荷容量が指定されています。

さて、一般に、負荷容量が小さいと負性抵抗が大きくなって発振が強烈になりますが、周波数の安定度が下がります。逆に負荷容量が大きいと安定性は上がりますが、負性抵抗が小さくなるので発振自体が危うくなります。
負性抵抗の値が水晶の等価直列抵抗の5～10倍となるようにしておくとよいと言われています。

負性抵抗は主にアンプの性能で決まります。
もし、負性抵抗が大きすぎる場合はRdの値を増やします。負性抵抗が小さい場合はRdを減らしたりゼロにし、それでもだめなら、負荷容量を下げて発振しやすくします。

まず、下の図は、EZ-USB FX2(CY7C68013)の水晶の端子(ドライブ側)の波形です。とても元気よくドライブされていて、多少歪んでいるくらいです。振幅は4V近くあります。

(CH2は水晶の信号)

一方、次の図は、EZ-USB FX2LP(CY7C68013A)の水晶の端子の波形です。省電力タイプであるためか、CY7C68013無印に比べるとドライブが弱く感じられます。振幅は3.1Vくらいです。

(CH1はCLKOUT信号、CH2は水晶の信号)

推測ですが、EZ-USB FX2LPでは定消費電力化のため、水晶をドライブするためのパワーを減らし、さらに何かの安定度に関わるファクターを変更しため、CL=12pFの水晶が要求されるようになったのだろうと思われます。

---

次に、回路の負性抵抗を測ってみましょう。
負性抵抗を測るには、水晶に直列に反固定抵抗を入れ、徐々に値を上げていって発振しなくなったところの抵抗値を測ります。
表面実装用の小型の水晶を使用した場合、EZ-USB FX2では1kΩ以上でも発振したのに対し、FX2LPでは約300Ωで発振しなくなりました。
また、大きめの水晶(HC49U?)を使用しても約800Ωで発振しなくなりました。
(水晶の物理的サイズが大きいと、等価直列抵抗が減り、負性抵抗が小さくても発振しやすくなる。小型の水晶ではその逆の傾向が出る。)
信号の振幅が70mVくらいになり、非常に弱々しくなります。それでも、EZ-USB FX2LPの中のPLLは動作しているようで、この弱い24MHzの信号から480MHｚを作り出してくれています。

(CH1はCLKOUT信号、CH2は水晶の信号)

つまり、EZ-USB FX2LPは、低消費電力化のため、発振回路の周波数特性や増幅力などをFX2よりも下げているのではないかと推測されます。

---

ところで、水晶を選定する上でのパラメータはいくつかありますが、
・周波数と安定度
・共振モード
・負荷容量CL
・ドライブレベル

普通は、周波数と安定度、共振モードまでは誰でも見るでしょう。
でも、なかなか負荷容量までは気にしないことが多いのではないでしょうか。
さらに、ドライブレベルというパラメータもあります。これは、水晶をドライブするパワーのことで、オーバーすると水晶の性能や精度に悪影響を及ぼすそうです。
CYPRESSのEZ-USB FX2とFX2LPではどちらも500μWとなっています。これはかなり強烈なドライブレベルです。耐えられる水晶はどれだけあるでしょう。

---

そういうえば、昨今の高速なシリアル通信は、マスターかスレーブのどちらかが作り出した周波数にもう一方がPLLであわせて送信受信を行うのが定石ですが、USB2.0のHigh Speedモードでは480MHzの周波数はどちらが作り出しているのでしょうか。

EZ-USB FX2LPにはCLKOUTという信号がありますが、それは通信用の480MHzを分周したものだそうです。
そのCLKOUTと水晶の周波数をオシロで見ると、整数倍の関係で位相が見事に一致していているので、USBの基準周波数はターゲットが作り出しているのでしょうか。

工大祭に行ってきた

22日、23日は、工大祭(東京工業大学のお祭り)に行ってきました。
２日間とも、サークルのOBで飲み会。
意外と私のホームページが読まれているようで驚きでした。

ARM9のJTAGデバッグのしくみ

ARM9のJTAGデバッガを開発中しています。

ARM9は、命令バスやデータバスをJTAGで操作できるので、ホストPCから任意の命令を送り込んで実行させることができます。任意の命令を実行させられれば、メモリやレジスタ、IOの操作をパソコンから指示して自由に行うことができるわけです。

さて、ARM9には下の図のように、スキャンチェイン１という、命令とデータを送り込むための67ビットのレジスタがJTAGから操作できるようになっています。

CPUを停止させた後で、このレジスタに任意の命令を送り込めば、CPUを自由に操作することができるというわけです。

ARM7にも同じような33ビットのレジスタがありましたが、ARM9はデータバスと命令バスが分離されているため、このレジスタは67ビットに拡張されました。また、ARM7にあった「命令のビットがリバースされている」という妙な特徴はそのまま残っています。命令のビットは反転していますが、データは反転していないので注意が必要です。

また、今回、下から数えて33ビット目がDDENというレジスタになりました。この値を読み出したとき1になっていれば、データバスに表れたデータが有効であるというものでしょう。

さて、ARM7の場合は「フェッチ→デコード→実行」の3段パイプラインで実行されており、実行がメモリアクセスを伴う場合には4サイクルで実行されていました。従って、JTAGでメモリアクセス命令を実行させる場合には、
　① shift dr 0xE5800000 // LDR R0,[R0]
　② shift dr 0xE1A00000 // NOP
　③ shift dr 0xE1A00000 // NOP ← ここで命令が実行される
　④ shift dr 0x01234567 ← これは命令ではなく、LDR命令で取り込まれる値
といった具合に、命令とデータを同じ要領で送り込む必要がありました。(詳細はInterface誌を参照)

さて、ARM9ではどうなるでしょう。
実際に、次の9ステップのコードをARM9にJTAGで送り込み、実験してみました。
　① MOV R0,#5500
　② STR R0,[R0]
　③ LDR R0,[R0]
　④ STR R0,[R0]
　⑤ STR PC,[R0]
　⑥ NOP
　⑦ NOP
　⑧ NOP
　⑨ NOP

結果は、下の図のようになりました。

図の左側は、JTAGで入力した値、右側はJTAGから出力された値を示しています。

ステップ2で実行されたSTR命令のメモリアクセスの結果、3ステップ後のステップ5の時にデータ系データバスにR0の値が出力されています。
しかし、ステップ4で実行されたSTR命令の結果は、4ステップ後のステップ8で出力されています。

このように、LDRを間に挟むと、データが出力されるタイミングがかわってきます。

また、LDR命令で取り込まれる値はどのステップで入力すればよいのかも悩みました。

この動作は、なかなか妙なふるまいだったので最初は理解に苦しみましたが、次の図のようにパイプラインの動作をイメージすることで、理解することができました。
ARM9の命令は、「フェッチ→デコード→実行→メモリアクセス→レジスタライト」の5段パイプラインで実行されます。

上のテストコードは、LDR命令にメモリからレジスタR0に値を読み出した後、すぐ次の命令でR0を使っています。LDR命令でR0が更新されるのはステップ7のタイミングなのに、STR命令でR0が使われるタイミングもステップ7になるため、パイプラインにインターロックが発生して、後のSTR命令の実行が待たされたと考えられます。

さらに次のSTR PC,[R0]命令でも、R0が使われます。これを普通に実行するとメモリ書き込みのタイミングがSTR命令と重なるので、結局どこかのステージで1つ待つことになります。

なお、このコードを繰り返し実行すると、PCが32番地づつ増えていくのが確認されました。インターロックが発生してパイプラインが待たされているステージでは、アドレスカウンタがインクリメントしないような気がします。

ARM7もARM9も、マニュアルやアプリケーションノートにはこの辺の考え方はおろか、JTAGデバッグの詳しい仕組みさえ全く記載されていないので、JTAGデバッグのやり方を見つけるだけで苦労します。マニュアルにかかれているのは各種レジスタの説明くらいで、どういう順序で何を与えればよいかは、すべてJTAGデバッガの設計者が考えなければなりません。

この仕組みがわかってきたので、まもなくARM9用のJTAG ICEをバリバリ作り始めます。

MAX II DevKITとPlatformUSBを購入

だいぶん前に注文していた、ALTERAのMAX II Development Kit と、XILINXのPlatform USB ケーブルが到着しました。

MAX IIキットの方はキャンペーン価格で購入したので、１万何千円。箱を開けてみると、ByteBlasterIIが入っていました。こないだByteBlasterII購入したときの価格は１万何千円、あれぇーっ！？

MAXIIキットには液晶モジュールが(基板にピンヘッダで直付け)ついていて、USBケーブルをつなぐと、MAX II by ALTERAとか表示されます。ボタンを押すと現在の温度や電圧が表示され、よく出来ているというな感触を受けます。
JTAGでつなぐと、ちゃんとEPM1270F256と表示され、バウンダリスキャンもできます。

さて、このくらいにしておいて次はXILINX。

Platform USBケーブルは、Parallel Cable IVより若干大きめのサイズで、本体にはフライリードワイヤーのコネクタはなく、リボンケーブルのみとなっています。フライリードワイヤーは同梱のアダプタでつなぐようです。
USBケーブルを挿すとPnPで認識されます。

マニュアルを読むと、波形とかAC特性が細かくかかれています。TCK速度は24MHz～750kHz、USB2.0で消費電力は300mAということは、中身はサイプレスのFX2とCPLDかな～、と思っていたら、正解でした。
あっ、ISEのバージョンが古い！？まぁいいや。

ARM9とJTAGの関係

アットマークテクノさんのArmadillo9を購入しました。

このボードは、ARM9TDMIコア(ARM920T?)を内蔵したCirrus Logic社製のCPU「EP9315」を搭載し、200MHzの速度で動作し、Linuxが動くというものです。

早速JTAGケーブルを接続し、MITOUJTAGからARM9TDMIが見えるのが確認できました。

ARM920Tのマニュアルを読んでみると、ARM920はバウンダリスキャンができるようなことが書いてあります。
BSDLファイルを作成し、MITOUJTAGに読み込ませてみると、見事にCPUのバスの波形を見ることができました。

クリックで拡大

この波形は、Linuxにログインして、ls -aR / と入力したときの波形です。だいたい80msごとに激しくバスが動いているのがわかります。

さて、ARM9用のJTAG ICEも作り始めました。ARM9のデータシートを読む限り、ARM7とよく似ています。ARM7のデバッグの仕組みについては、Interface誌の9月号に詳しく書きましたので、ぜひご覧下さい。

ARM9のデータシートをざっと読んでみたところ、ARM7とARM9のJTAGデバッグの大きな違いは、
・Scan Chain選択レジスタが5ビット(ARM7は4ビット)
・Scan Chain1が67ビットに拡張され、命令系データバスとデータ系データバスを独立して指定するようになった。
・シングルステップ実行用に専用のハードウェアが追加された。
といった感じです。EmbeddedICE-RTの使い方などには変更はないようです。

ARM7用のデバッグルーチンをちょこっと修正してARM9に適用してみると、見事にCPUを停止させることができました。手ごたえ有りです。

このArmadillo9をターゲットにして、ARM9用のJTAGデバッガの開発を本格的に始めることにします。

1個からのCPLD購入法

XILINXのWebサイトにあるオンラインストア使ってみました。
http://www.xilinx.co.jp/buy_online_redirect.htm

「日本やその他の国のお客様には、通常の国内代理店のご利用を強くお勧めします。」と書かれていますが、日本からでも注文できるようです。
今月7日(金曜日)に、CoolRunnerIIを2品種(XC2C128VQ100*2,XC2C256VQ100*3)注文し、土日を挟んだ11日(火曜日)にXC2C128だけが届きました。残りのXC2C256ももうじき届くでしょう。

一方、国内代理店で注文すると、在庫があれば1週間。なければ１ヶ月とか1.5ヶ月、3ヶ月くらいかかりますので、試作なんかですぐに欲しいときにはこれからも使ってみようと思います。
さて、値段を見てビックリ。1個2個買うなら国内代理店より安いんじゃないのと思える値段です。在庫がオンラインで確認できるのもありがたい。

CoolRunnerIIのほかにも、ParallelIVやPlatformUSBといったケーブルや、Spartan3 FPGAも買えます。ただし、FPGAの相場は結構高めだし、在庫切れも多く、3～4週間と表示されているので、国内代理店の方がいいですね。

そういえば代理店に注文したFPGAがそろそろ届くかな・・・。

国勢調査票の書き方

国勢調査が来た。
９月２４日から３０日の１週間に仕事をした合計時間を書くところがあるのだが、欄が２桁しかない。
（３桁目は薄いので、ここに書いていいのかどうか）
１００時間を越えたらどうすればいいんだーー

JTAGデバッガとInsight/GDB

引き続きJTAG ICE(デバッガ)を開発しています。

開発中の新しいJTAG ICEは、様々なアーキテクチャのCPUを統一の取れたGUI環境からデバッグすることができることを目指したソフトウェアです。このソフトウェアは各種CPU用のアルゴリズムとGUIの部分が独立しているため、アルゴリズムをとりかえれば別のCPUでもそのまま動作するという仕組みです。

今日は、GDBとの接続ルーチン(GDBSTUB)を作成しました。GDBからTCP/IP経由でこのデバッガにコマンドを送ると、このデバッガの中ではGDBプロトコルを解釈して各種CPUのJTAGのプロトコルに翻訳するルーチンが動き、ターゲットボードを操作することができます。

GDBとInsightは同じようなものだと思っていたのですが、実際に動かしてみると、GDBとInsightで微妙に動作が違う点がありました。Insightは、プログラムをロードした後に、デフォルトでは自動でブレークポイントを設定するので、JTAG　ICEがブレークポイントに対応していなければうまく動作しません。また、普通のCPUに内蔵されているハードウェアブレークポイントは１個から４個くらいまでなので、数が限られています。
ハードウェアブレークポイントだけだと、ARMの場合には2箇所までしかブレークポイントを設置できないなんていう悲しいことになります。常にその数に注意しなければならないのでは、デバッグに集中できません。
気軽にブレークポイントを設置できるようにするためには、ソフトウェアブレークポイントにも対応させないといけません。

ARMの場合、ソフトウェアブレークポイントは、止めたいアドレス上に未定義命令を置くことで実現されます。
未定義命令を実行すると、例外にジャンプしてしまいますが、普通のROMモニタ型のGDBSTUBでは、ジャンプした先の例外ルーチンを使ってGDBとやりとりします。
一方、JTAGデバッガではふつうは例外ルーチンにジャンプしません。命令フェッチの際に未定義命令がデータバスに出現したのを検出して、例外ルーチンへ飛ぶ前にCPUを停止させるというのが正解になります。
※要するにアドレス一致ブレークではなく、データ一致ブレークを使う。
しかしこのような技巧が使えないCPUもありますので、悩ましいところです。

また、GDBには命令キャッシュやオペラントキャッシュの有効無効を指定するコマンドがないようです。あまり考えずに作ったら、GDBからプログラムをダウンロードしても古いキャッシュのままCPUが動作するなんていうこともおきました。でも、これは何とか解決できました。

それから、
　for(i=0;i<1000000;i++) { }
なんていう箇所を、GDBからステップ実行させたら、大変です。
GDBは、次のアドレスまでステップ実行でなんとかしようとしますし、GDBSTUBは受け取ったコマンドを忠実に実行するだけです。
100万回のステップ実行コマンド「s」を発行してくれます。もう止められません。
これはGDBが悪いのでもなく、JTAG-GDBSTUBが悪いのでもありません。
たぶん仕様だと思われます。

そんな感じで動作もだいぶん安定してきました。そろそろお客様からご要望の多かったARM9への対応もはじめようかと思います。

JTAG ICE開発の続き（ブレークポイントの実装）

引き続き、JTAG ICEを開発しています。
GUIの簡単な操作だけでブレークポイントを設定できるようになりました。
JTAG ICEなので、ROM上のアドレスにもブレークポイントを設定することができます。

さて、JTAG ICEに限らず、デバッガのもつブレークポイント機能というのは、プログラムが指定したアドレスの命令を実行する際に、CPUの動作を停止させる機能です。

普通、JTAGデバッガでは、大抵のCPUに対してブレークポイントの設定で、命令の「実行前に止める」か、「実行後に止める」かという選択ができます。
やはり実行前に止まるのが嬉しいでしょう。

しかし、ここで、悩ましいことが一つ出てきます。

ブレークポイントというのは、やはり命令の実行前に止めて欲しいのですが、その止まったアドレスから再開するときには、一度だけブレークポイントを無視してほしい、というわけです。普通に考えればしっくりとくる動作なのですが、これを実装しようとすると意外に難しいことに気が付きました。

なぜなら、「実行前に停止」にすると、停止しているCPUの動作を再開（リスタート）するときに、ブレーク指定を解除しないと同じアドレスで止まり続けてしまいます。つまり再開（リスタート）できません。
逆に「実行後に停止」を選ぶと、CPUの動作は再開（リスタート）されますが、ループなどで再び同じ番地を通ったときに、設定した次の命令のアドレスで止まってしまいます。

これはあらゆるCPUの、モニタやデバッガを作る際に共通する問題ではないでしょうか。

上手い解決方法もあるのだとは思いますが、眠いので今日はここまでにしておきます。
ブレークポイントで止まった後はシングルステップ実行で１命令進めてからCPUの動作を再開（リスタート）するのがベストといったところでしょうか。

インターネプコンに

MITOUJTAGの展示を行うため、
ナヒテックは、インターネプコンに出展するかもしれません。
出展するかどうかの決定は２週間後に発表します。
--------------------------------------------------------
会期：２００６年１月１８日～２０日
場所：東京ビッグサイト
展示会：インターネプコン・ジャパン エレクトロニクス製造・実装技術展
http://www.nepcon.jp/