ログイン
ユーザ名:

パスワード:


パスワード紛失

新規登録
Main Menu
(1) 2 3 4 ... 8 »
スレッド表示 | 古いものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
webadm
投稿日時: 2006-8-7 0:49
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
新たな謎
ロジアナで観測して新たな謎を発見。

ホストからTDI+TMSのビット列をまとめて受け取ってから44us毎に8bitづつJTAG信号を生成している。つまり大変効率が悪い。

せっかくTCKは6MHzぐらいでトグルしているのに。

おそらくTDIを8bit単位でマイコンが読み出す処理のために間が開いてしまうのだろう。単純にバッファに格納するだけでもそれなりに処理時間がかかってしまう。もう少し工夫すれば間隔は短くなるのかもしれない。

JTAG信号の生成をCPLDでやっていると思うのでTDI,TMS,TDOにそれぞれFIFOとかを入れるような大げさなことはできないだろうし、一回8bit単位が精一杯というところだろう。

JTAGリセットシーケンスはTCKが5回だけ生成されているのとTCKのレートが低い(750kHz)のでこれはマイコンが直接JTAG信号を制御しているのだろうか。もしくはJTAGリセットだけは確実に行えるように可能な限り最低のレートで行っているのだろうか。それにしても5bitとかいう中途半端な数はなんだろう。


webadm
投稿日時: 2006-8-6 9:50
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
仮説は間違っていなかった
カメレオンUSBロジアナにご登場願って、USBアナライザーでキャプチャーしながらJTAG波形を観測してみたところ仮説が正しいことが確認できた。



最初にUSBアナライザー上で現れるINTERRUPT転送(Host->DeviceとDevice->Host)とJTAGのTCKサイクル毎のTDI,TMS,TDOのビット列がぴったり合致することが確認できた。

IDCODEがLSBファーストで現れるのとバイトの途中のビットから現れるので簡単には識別できない。ビット列に書き直すと、

1111100000001010000011111011001001000000110010101101101000000000

この中から左から順にIDCODEと合致するパターンを見つけると、

11001001 00000011 00101011 01101000

というのが確認できる。これを左から右を右から左に並べ変えると、

00010110 11010100 11000000 10010011

16 D4 C0 93

となりCoolrunnerIIのIDCODEであることがわかる。これで仮説は証明された。
webadm
投稿日時: 2006-8-5 19:14
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
USBアナライザーで見てみた
USB 1.1のポートにつないで見てみたところ意外と複雑な動きをしていた。

常になにかのオペレーションを開始する際にはSETUPトランザクションでなにやら初期設定を行っているらしい。何をやっているのかは謎。

その後で非同期データ要求(INTERRUPTデータ)でTDIとTMSをペアにしたビット列が送信され、その後でTDOのデータ列が返される。

一度チェインを認識した状態でわざとTDOのフライングケーブルをオープンにするとTDOのデータ列は先に送られたTDI+TMSのビット列の長さの半分だけ1が連続して表示されていることからそれで間違いないだろう。

Platform Cable USB側は要求されたTDI+TMSのビット列を順次8ビットずつTCKをトグルしながらJTAG信号出力し、その都度TDOをサンプルしてその結果をホストに返すという仕組みなのは誰でも想像できる。

ただ問題なのはTDOのビット列をどう解釈しても意図したデータ列が見えてこない点である。IDCODE読み出しを行っているので上位に表示されるTDOビット列にはIDCODEの32bitが含まれているはずである。しかしどのビット位置から読んでもIDCODE値が含まれているようには見えない。

もしかしてスクランブルしているとか? いやそれならTDOをGNDに落としたりオープンにした際に0や1に固定されないはずである。

ロジアナで実際の波形を併せて観測してみる必要がありそうだ。
webadm
投稿日時: 2006-8-5 16:02
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
Platform Cable USB Model DLC9G
最新のPlatform Cable USBはModel DLC9Gという記載がされていてそれ以前のUSB 2.0 Hight Speedバージョンの更に鉛フリー対応と称するものらしい。

鉛フリーはどうでも良いとして、USB 2.0 High Speedバージョンというのがくせ者で、これによって大変ダウンロードが高速になって大規模のFPGAを複数チェインしても短時間でコンフィグレーションが可能になるとかいう利点がある。

しかし今回動作の謎に迫るために中古のUSBアナライザーを購入したのだがこれがUSB 1.1 Full Speedの時代の産物。当然High Speedは観測できない。

今まで使っていたUSBの口がFull Speedまでの口だと思っていたらちゃっかりUSB 2.0の口でHigh Speedが使えるということに気づかなかった。デバイスが接続されて認識されるまでの間はFull Speedで行われるのでそれ自体はUSBアナライザでモニターできた。しかしそれ以後のトランザクションがさっぱり観測できないことでやっと気づいた次第。かなりまぬけである。

USB 2.0 Hight Speed対応のデバイスは古いUSB 1.1までしかサポートしないPCやハブにつないで使用できるはずであるので、USB 1.1しかサポートしていない古いPCにISEとかをインストールし直してやるしかない。

一度Xilinxのサイトで登録IDを取得してあれば、それを使えば別のPCにもインストールできる。ことISE Web Editionに関してはAlteraみたいに1ライセンスPC固定という縛りはないようだ。おそらく売り物のFoundationは違うと思うけど。

それにしてもISEのインストールは時間がかかる。
webadm
投稿日時: 2006-7-31 11:05
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
Platform Cable USBの出力レベル
オシロで観測してわかったのは5v動作時には拙作のプログラミングケーブルと同じようなレベルしか出力されないことが判明。

レベル変換用に使われているフェアチャイルドのバッファICの等価回路を見ると最終段にバイポーラートランジスタによるトーテムポール出力回路が使われていることがわかる。なのでfull swingとはならないわけである。少し安心した。

というか無理してByteBlaster IIみたいにfull swingにしなくても良いということがわかっただけでも良かった。

さて買ったFETをどうしようか、どれもパワースイッチング用だから小信号のデジタル回路には向かないかも。
webadm
投稿日時: 2006-7-31 10:55
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
新たな謎
Platform Cable USBに使われている部品とかを見てみようと中を開けてみてびっくり。部品面がほとんどアルミのシールドケースに覆われていてどんな部品が実装されているか見えない。

たぶんコンパレーターとか微妙な回路があるので周囲の誘導を受けないようにシールドが必要なのだろう。24MHz動作だしね。入出力のレベル変換があるのを除けばSpartan3E Starter Kitの回路と一緒な気がする。

Platform Cable USBで謎なのは実際に24MHzというTCKレートでどうやってホストとやりとりしているのかという点。JTAG側で観測するとどうもTCKが8bit単位でバースト的に観測されるので8bitパラレル・シリアル変換でもしているのかもしれない。上りと下りの信号があるけどどうやって同期をとっているのかな。ホスト側のソフトウェアがやっているのだろうけど。この辺りが秘密くさいので互換品が存在しない理由かも。

もう一方のDegilentのパラレルケーブル。これも良くみるとJTAGコネクタ側が熱圧縮チューブで覆われているものの中に背の高い部品とかがついているのが突き出ているのがわかる。それにしても謎なのがよくこんな少ないスペースで給電も無く実現できているなという点。おそらくByteBlaster IIみたいに余っているピンから給電を受けているに違いない。プリンターポート側のコネクタハウジングにも何か回路が入っていそうな気もするけど爪でロックしているタイプなので簡単には開かない。

今回Platform USB Cableを使うとJTAGチェインのスキャンで決め打ちで10MHzでTCKが駆動されるということが判明したので、もしかしたら自作した場合そんなに速いクロックでは動かない可能性もなきにしもあらず。パラレルケーブルが必要なのはそういう時かもしれない。なので自作する価値はありそうである。問題はホスト側へのレベル変換に必要となる給電だな。
webadm
投稿日時: 2006-7-29 20:00
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
Spartan3e Starter Kit基板をJTAGしてみた
今度はSpartan3E Starter Kit基板につないでみることに。



まずはQuartus IIのAutodetectから。問題なく3デバイスチェインが認識された。



次にJam STAPL Player



これでかなり実用になることが証明できた。といってもIDCODEのスキャンだけだけど。
webadm
投稿日時: 2006-7-29 18:42
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
CPLD Design Kit基板をJTAGしてみた
とりあえず拙作プログラミングケーブルでXilinxのCPLD Design Kit基板がJTAGできるか試してみた。



Quartus IIのprogrammerでautodetectしてみたところちゃんとJTAGチェインが認識された。16D4C093がCoolrunner II(XC2C256)で49604093がXC9572XL-vq44



Jam STAPLE playerのIDCODEでも複数デバイスチェインを認識しそれぞれ正しいIDCODEが読み出せた。

引用:


F:\altera\jp_25\exe\32bit>jam -aread_idcode IDCODE\idcode.jam
Jam STAPL Player Version 2.5 (20040526)
Copyright (C) 1997-2004 Altera Corporation

CRC mismatch: expected BAD6, actual 8DCB
******************************************************************************
* Altera Chain Interrogation Version 4.0 *
* Copyright (c) 1999-2005 Altera Corporation. All Rights Reserved. *
******************************************************************************
Chain Continuity Checker
Chain Continuity during IR is not stuck at zero or one
******************************************************************************
Chain Length -- Load IR of all ones then count DR length
Number of Devices is 2
******************************************************************************
IR Length Calculator
Instruction Register Length is 16
******************************************************************************
IDCODE Reader
---------- | ---- ------------------- ------------- - |
TDO -> TDI | Rev Device Mfgr 1 |
---------- | ---- ------------------- ------------- - |
Device #1 | 0100 1001 0110 0000 0100 0000 1001 001 1 |
Device #2 | 0001 0110 1101 0100 1100 0000 1001 001 1 |
---------- | ---- ------------------- ------------- - |
******************************************************************************
Device Identifier -- Search for device name from list of device IDCODE values
---------- | ------------------- ------------- |
TDO -> TDI | Device Mfgr |
---------- | ------------------- ------------- |
Device #1 | Unknown IDCODE |
Device #2 | Unknown IDCODE |
---------- | ------------------- ------------- - |
******************************************************************************
Exit code = 0... Success

F:\altera\jp_25\exe\32bit>
webadm
投稿日時: 2006-7-29 12:59
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
貫通電流を観測してみた
どんな感じで貫通電流が発生しているか見てみた。

といっても電流はオシロでは観測できないので、電流制限抵抗10オームをNチャネルMOS FETのソースとグランドの間に入れてその両端の電圧を観測することにした。



1kHzではこんな感じで出力の立ち上がりと立ち下がりの時に貫通電流がパルス的に発生している。この状態では貫通電流は10オームの抵抗で1v程度出ているので100mAぐらいと推測される。単位時間当たり電流が流れている時間は短いのでFETは熱をもたない。

更に入力周波数を上げていくと入力パルス幅が段々と狭くなるにつれて出力の立ち上がりと立ち下がりの間隔が狭まりついには二つの貫通電流パルスは連続してしまう。



ほぼ5割の時間が貫通電流が流れている。安定化電源の電流計は平均値である50mAを示している。この程度であればまだFETはほんのり暖かい程度。

ただこれも電流制限抵抗が入っているので流れる電流のピークが抑えられているものの、そうでないと更に周波数を上げていくと比例して電流も増えていく。電流制限抵抗があるとローパスフィルター効果で特性が悪くなり出力波形が相当鈍るので電流が増えていくというのは100kHzぐらいまででそれ以上になると逆に出力状態が変化しなくなり電流は減っていく。

シミュレーションでも電流制限抵抗をほんのわずかでも入れただけで特性が悪くなることは確認済み。

教科書に書いてあるような単純なCMOSインバーター回路ではちょっと役にたたないということが判明してきた。別の回路を実験してみる必要がありそうである。
webadm
投稿日時: 2006-7-29 12:21
Webmaster
登録日: 2004-11-7
居住地:
投稿: 2990
方針の変更
今までは一般に入手しやすい部品を使ってプログラミングケーブルを自作するということにチャレンジしてきたけれども、どうも限界が見えてきた感じがする。

トランジスタでがんばって作らなくてもすぐれた性能のICが手に入る時代になっていた。もう秘密は何も無くなってしまった。

とりあえず当面はせっかく購入したトランジスタを全部評価してみてお勉強することにしよう。

それから拙作のプログラミングケーブルでXilinxのCPLDやFPGAがスキャンできるか試してみよう。

いずれにせよ次作る時は出力バッファはフェアチャイルド、入力バッファはリニアテクノロジーで決まりな感じ。それとてもう秘密は無いので作る意味があるかどうかも疑問である。

さて次に探求すべき秘密、何かないかな。
(1) 2 3 4 ... 8 »
スレッド表示 | 古いものから 前のトピック | 次のトピック | トップ

投稿するにはまず登録を
 
サイト内検索