Quartus IIの動作がまずくなったのはもともとQuartus IIは波形の汚いインチキケーブルでもsetup時間が十分余裕がとれるようにH時間が長くとってあるのが災いしていると思われる。

影響を受けるとすれば長いH時間が続く可能性のあるTCK以外の信号である。

そこでまず受信バッファのベース抵抗を5.6kから22kに全て取り替えた。これによってパルス幅が忠実で無くなる可能性は無くなる。

結果的にこれがあっていたようでQuartus IIの動きも少しましになった。とは言え、まだEPM240?とか表示されてUSERIDコードもFFFFではなく0000とか嘘が表示される。

今度は出力バッファを見直す。出力波形がやはり歪んでいる。ブレッドボードでできるだけ周囲も含めて同じ回路構成にして同じ入力信号を与えて観測してみた。すると同じような波形が現れた。



あやしいのはシミュレーション時には入れていなかったが、後に２段目のトランジスタのベース電流が余分に流れすぎないかと心配して1kの制限抵抗を入れてあった。それが災いしているかもしれないとシミュレーション回路通りに前段のコレクターと直結してみたり、スピードアップコンデンサをかましてみたところ台形らしくなった。



しかしこの状態だと実動作はかえって悪くなる。どうも立ち下がりのところにある微妙なヒゲが悪さをしているように見える。よく自作プログラミングケーブルの回路で出力にも300pぐらいのセラコンをつけているものをみかける、ヒゲ取り用だと思われるので入れてみたところ、綺麗にヒゲはそれた。



少しレベルは低めだけれども綺麗な感じがする。これならいけるのではと思い実機も同じようにしてみたら、かなりまともになった。それでも時々誤動作するのはきっと他の出力バッファのスピードアップコンデンサを付け忘れていたせいだと思われる。ちゃんと回路図通り作らないのが悪いのだが。

ちょっと100pのセラコンをもっと余分に買っておけばよかった、結局全部使いはたしてようやく完成。

Quartus IIでも何度やってもエラーは起きなくなった、MITOUJTAGはQuartus IIを使った直後だとMITOUJTAGは常時Output enbaleで動作することを前提としているためかOutput disabl->enableの出力ディレイタイムに対してあまり考慮されていないか拙作のケーブルのディレイタイムが大きすぎるのか最初の一回は誤動作になる。その後は常時Output enableのままになるので何度操作を繰り返してもエラーは発生しない。今までエラーが出ると心臓に悪かったが、もう安心して使えるようになった。

安心して使えるケーブルがあればMITOUJTAGはかなり面白い使いかたが出来そうである。もうMITOUJTAGで書き込みをしてもエラーは起きなくなった。できればQuartus IIのように吸い出しやverifyだけ出来るようになるとうれしいのだが。あといちいち確認のダイアログが出ると連続操作が面倒なのでQuartus IIのようにログウインドウに結果だけ表示してくれるとなおよい。

自作のFLEX10Kボードで試した結果、IDCODEすらまともに読み出せないことが判明。目下原因究明中。

3.3VのMAXIIでは問題ないのに5VのFLEX10Kでは最初に作った時のようにまったくだめなのは何故だろう。波形はそんなに違わないのに。

MAXIIのデータシートを見ると3.3Vの場合はLVTTL仕様なのでTTLよりもかなりVIHが低く1.7V、それで2.0Vぎりぎり超えるかどうかでも余裕なのかもしれない。FLEX10KはTTL仕様なのでVIHは2.0Vとぎりぎり（余裕がまったく無い）。

段ボール箱の中から既に過去の遺物となったARMの評価ボードを取り出してきて、ケーブルをつないでIDCODEの読み出しを行ってみた。

まずは比較的新しいものの買ってなにもしないままお蔵入りしたARM EVALUATOR-7T。これは結構良くできていて512KBのROM/RAM、シリアルポートが２つに7seg LEDと単LEDが４つに20pin JTAGコネクタがついている。3.3V動作なのでうまくIDCODEが読めるかもしれない。搭載されているSAMSUNGのKS32C50100 CPUチップのデータシートの付録にJTAGに関して書かれている。最後にはBSDファイルも載っている。それによるとスキャンレジスタ長は233bitでIDCODEは1F0F0F0Fらしい。購入してから今初めて電源を入れてみるとLEDが全点灯してしばらくして三の文字がLEDに表示された状態に落ち着く。三は三星のことだろうか。MITOUJTAGトラ技評価版でIDCODE読み出しを実行してみると、なにやらLEDの表示が変化しJを鏡に映したような表示になる。しかしIDCODEは安定しては読めず、比較的安定して固定した値が得られる状態でも1F0F0F0Fとは似てもにつかぬ値である。期待に反してうまくは働いてくれなかった。



そこでもう一枚別のARM基板をひっぱりだしてきた。最も古いARMの評価ボードでAEB1と呼ばれる。これは昔結構使ってeCos 2.0が出た頃にいろいろカスタマイズするのに使った記憶がある。JTAG ICEとかも使えた実績がある。これはちょっと手元にボード付属のCDが無いのでJTAG IDCODEがいくつなのか不明だが、つないでスキャンしてみると27790061と一定している。このボードはかなり初期の試作レベルのLH77790BというARMチップが搭載されている。どうやら型式名からしてIDCODEはこれで合っていると思われる。ARMの標準的なIDCODEの付与の仕方にも合っているので間違いないだろう。こちらはたぶん問題無くつながった感じだ。さて不思議だ。原因がさっぱりわからなくなってきた。



とりあえず5V用に簡単な元祖Byteblaster風ケーブルを作ってみよう。といってもプリンターポートの信号を直接つなぐだけだが。

FLEX10Kボードで拙作のプログラミングケーブルを使ってQuartus IIだとPSモードでコンフィグレーションができたが、同じことがMAX+PLUS IIでも出来ると思ったら、こちらはまったくだめだということが発覚。

その原因が判明した。

拙作のプログラミングケーブルは巷で公開されているByteblaster II互換回路を参考にまねてnCE信号をターゲットへの出力イネーブル信号として使っている。これはALTERAのByteBlaster IIユーザーガイドに載っているブロック図とはまったく異なるが、Quartus IIではあたかもnCE信号が出力イネーブルであるかのようにコンフィグレーション開始に先立ってHighになり終了するとLowに戻る。

実は本当は本来プリンターポートのpin14が出力イネーブル信号のようでMAX+PLUS IIではこの信号だけがコンフィグレーション開始時にHighになり終了時にLowに戻る。nCEは常にLow固定だ、これはASモードでしか使われない信号なのでこれは正しい。Quartus IIはどうかというと、nCEもpin14も同じ様にトグルされている。これは意図的なのかバグなのかは謎。

ということでByteblaster IIに似せるにはちょっと回路変更が必要になった。変更すればMAX+PLUS IIでもQuartus IIでも使えるようになるがMITOUJTAGトラ技評価版では動かなくなることは確実である。

原因が判明すれば簡単な話。

どうやらMAX+PLUS II側のByteBlaster IIサポートはByteBlaster IIユーザーガイドに載っているブロック図にある通りのプリンタポート信号(pin14)を出力イネーブルとしてトグルしているらしいことが判明。

しかし従来nCE出力用のpinからそちらに切り替えると少しは進むようになるが途中でエラーが出る。オシロで観測するとプリンターポートの信号にはかなりリンギングノイズが乗っている。

そこで他の信号と同じように100オームのシリーズ抵抗で終端しVccへpull upしてみたところMAX+PLUS IIでもPSモードでコンフィグレーションが出来るようになった。Quartus IIでも同様に確認できた。これが本来のByteBlaster II仕様なのだろうか。そうすると巷に出回っているByteBlaster II互換ケーブルの回路図には厳密には互換性が無いものが存在することになる。MAX+PLUS IIで使わなければ問題ないが。

同様にMAX+PLUS IIでもトラ技付録のMAXII基板をつなげてMulti-Device JTAG Chain SetupでDetect JTAG Chain Infowを実行するとMAXIIがしっかり検出されるようになった。



新たな問題は、MAX+PLUS IIとQuartus IIどちらでも使えるように変更した回路だとMITOUJTAGトラ技評価版でJTAG出力信号がイネーブルにならなくなってしまう点である。

というのもMITOUJTAGはByteblaster IIが出力イネーブル信号として定義しているpin14をプログラムでLow固定にしているためである。

巷にあるByteblaster II互換回路にあるようにnCEを出力イネーブル信号として使うようにしていた変更前の回路であれば問題なかったのだが。もしかして純正のByteblaster IIはnCEかPin14のどちらかがHighなら出力イネーブルとしているのだろうか。そうすると論理和回路を追加しないといけない。またトランジスタが増えてしまいそうである。

どうもMITOUJTAGトラ技評価版はこのあたりのプリンタポートの扱いはプログラム内部で固定になっているようでPin14をpullup状態にするとかいう設定変更はできないようだ。というか汎用プリンタポートのケーブル設定を選択しても起動し直すと自動的にByteblaster IIを認識してそちらになってしまう。

もしかしたらMITOUJTAGトラ技評価版はByteblaster IIでの動作確認していないのかもしれない疑惑発生。画面上にはByteblaster IIと自動認識して表示されているが、ケーブル認識時に出るダイアログにはByteblaster MVのままなので矛盾している、これはもうどうしようもない。

白黒をつけるには純正のByteblaster IIを手に入れて確認してみるしかない。

純正ByteBlaster IIが届いたので実際に試してみたところ、それまでの疑念が一気に晴れた。

まず、ByteBlaster IIはnCE(Pin5)とnOE(Pin14)のどちらがHighでもターゲットへの出力がイネーブルになるということがMAX+PLUS IIとQuartus IIそれにMITOUJTAGトラ技評価版を使って確認された。

ということで拙作のプログラミングケーブルは早速回路修正する必要がありそうである。

それとMITOUJTAGトラ技評価版では「指定されたピンをHにする」機能をケーブルのピンに対しても行うことが出来るのを発見。これを使ってPin14を常時Hに設定変更することが出来た。この状態でPin5でなくPin14を出力イネーブル信号として使うように変更したケーブルでも問題無くJTAGが使えるようになることを確認。

MITOUJTAGには要らぬ疑いをかけてしまった。でもケーブル表示でVref:15とnOE:15と両方15なのが間違いなのは本当ですから。どうでもいいことだけど。

ということでByteBlaster IIの真の仕様について新たな事実が発見されたのでよしとしよう。これによって本当にByteBlaster II互換なケーブルがやっとできるようになった。

ふと思って以前自作ケーブルで試してだめだったJam STAPL Playerを純正ByteBlaster IIでやってみたら正常に動作した。

自作ケーブルだとどうしても出力イネーブル信号がJTAG操作中にイネーブルにならない。Jam STAPL PlayerでIDCODE読み出し実行中のパラレルポート出力信号状態を見てみると出力イネーブル信号のPin14がJTAG操作中OFFにトグルしている。これはByteBlasterMVの場合の仕様である。

ということは純正ByteBlaster IIはこの信号以外でも出力イネーブルにする条件があることを意味する。

実際に中身を調べたわけではないが、ByteBlaster IIをつなげてMITOUJTAGトラ技評価版でパラレルポートのPin14やPin5などの状態をHやLのすべての組み合わせを試してみたところJTAGのTMS,TDIは常にLが出力されていることが判明した。本来なら出力イネーブルでなければHi-Zになるはずで、その場合ボード上のpull upによってHとなるはず。

試しにPC側側コネクタを抜いてみると今度はpull upされている信号はHに変わった。むむこれはどういうことだろうか？

MITOUJTAGトラ技評価版でプリンタポートのPin14やPin5それにLに出来る信号ピンはすべてLにしてみたが出力はイネーブルのままだった。どうもByteBlaster IIのユーザーガイドに書いてあるブロック図とはこのあたりが違っているようである。

どうもByteBlaster IIはPC側コネクタがはずれたことをうまく検出して出力をディスエーブルにしているようだ。

今度はQuartus IIを使ってJTAGコンフィグレーションした後JTAG信号を見るとHi-zになっている。むむ。

もう一度MITOUJTAGトラ技評価版を立ち上げるとデフォルトでPin5,6,7,9がHに出力されるため赤く表示される。この状態で順番に赤いピンをLに変更していくとすべてLにし終わったところJTAGの出力がHi-zになることを発見。更に一つだけHにする組み合わせを試したところどうやらPin6,7,9,14のいずれかがHだと出力がイネーブルになる仕様だということが判明した。これはこまった。

わかったことはMAX+PLUS II,Quartus IIそれにJam STAPL Playerはそれぞれ共通してJTAG操作が終了するとJTAG信号出力をディスエーブルにするためにプリンターボートのPin5,6,7,9をすべてLにするということ。それとJam STAPL PlayerはJTAG操作中14をL出力し操作終了するとPin14をHにするという点（これはByteBlasterMVの仕様だと思われる）。MAX+PLUS IIとJam STAPL PlayerはどちらもPin5はJTAG操作中も操作後もL固定である。Quartus IIだけはJTAG操作中Pin5がHになり終わるとLに戻る。ばらばらである。

拙作のインチキケーブルもそれに準拠しないと今のところJam STAPL Playerでは動作しないことになる。実現するにはスイッチングダイオードが４つも要る、頭が痛い。

出力イネーブル信号の互換性問題で、MAX+PLUS IIやQuartus IIそれにJam STAPL PlayerにMITOUJTAGトラ技評価版をとりまぜ純正ByteBlaster IIと拙作インチキケーブルの動作を比較検証してみると、Jam STAPL Playerでだけ拙作のケーブルが出力イネーブルにならない。

何故純正ByteBlaster IIはそれでも動くのか、Jam STAPL PlayerでJTAGのIDCODEスキャンをさせている間にプリンターポートの各信号ピンをロジックチェッカで確認してみたところ慟哭の新事実が判明。

純正ByteBlaster IIはPin6,7,9,14の他にPin36(手元のアンフェノール36ピンケーブルではここにnStrobe信号が結線されているようだ、Dsub-25だとPin1に該当）も出力イネーブル信号として使用していることが判明した。nStrobe信号はMITOUJTAGトラ技評価版では表示も制御もサポートされていないので確かめようが無かった。

さっそくスイッチングダイオードをつないでnStrobe信号でも出力イネーブルになるように変更するとJam STAPL Playerでもターゲットへ信号が出力されるようになった。

MAXIIでは問題ないが、自作のFLEX10KボードだとIRスキャンは問題ないがIDCODEが正常に読み出せない。他のツールではIRすらまともに読み出せない。違いというとJam STAPL Playerはインターブリタ動作のためTCKパルス間隔が他に比べて大変長いということぐらいしかない。TCKパルス幅はMITOUJTAGと同じで他に比べると短く1uSぐらいしかない。しかしトラ技MAXII CPLD基板ではどれも問題ない。この違いはやはりTCKの波形にあるのかもしれない。

そう思ってついに純正ByteBlaster IIをFLEX10Kボードにつないだ状態でFPGAのTCKピンにオシロをつないで波形を観測してみた。その結果、想像していたのとはまるで違っていた。



見事なまでのフルスイングである。写真で見えたのはバイポーラトランジスタではなくCMOS FETだったのだろうか。立ち上がりと立ち下がりどちらもシャープで文句のつけようが無い。これなら動いて当たり前である。FLEX10KボードのTCKラインには300pのセラコンを付けているがそれでも波形がなまったりしているわけではないのがすごい。

今度は拙作のインチキケーブルをつないで同じように観測してみると、同じスケールだが明らかにレベルが低く立ち下がりになにやらおかしな残像が見え隠れしている。立ち上がりエッジしか使わないPSモードは問題ないものの両エッジを使うJTAGでまともに動かない理由はこのあたりにありそうである。



よく見るとオーストラリア大陸にあるエアーズロックのようにも見えなくもない。

この波形が低い理由は分かっている。シミュレーションでもVCC側の２つのトランジスタのベースバイアス電圧が足らない（入力信号のレベルが低い場合）のでどちらかのトランジスタが完全にONにならないためである。オシロで観測すると出力イネーブル制御用のトランジスタは完全にONしているのでVceはほぼ0vに近いもののVCCにコレクタがつながっている方のトランジスタはL出力時には完全にOFFしているもののH出力時にVceが2.5vまでしか下がらない。これがレベルが頭打ちになる理由だ。シミュレーションだとどちらのトランジスタも完全にはONにならないため、出力は更にレベルが低く実用にならない状態になる。

なんとかVcc側のトランジスタを完全にONするようにできればかなり波形はまともになるのだが。

FETで作るとバイポーラートランジスタを使ったのに比べ以下のメリットが生じる。

(1)すくない消費電流

バイポーラートランジスタをONするのにはベース電流を流し込まなければならない。１回路だけならまだしも出力５回路分の出力イネーブルトランジスタをONに保つためには数mAの電流が常時流し込む必要がある。PCのプリンターの出力信号は電流をとれば電圧が比例して下がるので今度はベースバイアス電圧が低下してONしきれない。

FETはバイポーラートランジスタとは違って制御電流を流す必要がないためその分だけでも消費電流は減る。

(2)高速なスイッチング

バイポーラートランジスタを高速に動作させるには有る程度大きなコレクタ電流を流す必要があった。最低でも数mA、本当は数十mAが望ましいが負荷抵抗がそれほど低くないので数mAがせいぜいである。

FETは数mAの負荷電流でもバイポーラートランジスタよりも遙かに高い周波数に応答する。ロジック回路などの高速スイッチング回路に向いている。

良く調べたら以前購入した「定本：続トランジスタ回路の設計」にバイポーラトランジスタによるものだけでなくFETによるスイッチング回路が詳しく説明されていた。どちらかというとこの本はFETを使った回路が主らしいことも今更気づく。

というわけで次のバージョンのプログラミングケーブルはFETを使ったものになる予定。

ふと思いついてVcc側のトランジスタを少しでも完全にONしている状態にできないかとブレッドボードで実験的にTCKバッファ回路だけをダーリントン接続にしてターゲットにつないでを試してみた。

すると出力波形は少し高くなったもののやはりうまくツール類は動作してくれない。以前よりも立ち上がり立ち下がりともシャープに見えるが微妙なところだ。

もう少しレベルを上げないとだめかとあちこちゴニョゴニョバイアス電圧を高くしてみたころある方法ですべてのツールで問題なくJTAGが使えるようになった。やった、やれば出来るじゃないか。

早速拙作のプログラミングケーブル基板にブレッドボードと同じようにトランジスタを追加して回路を変更してみたところ、出力波形が似てもにつかぬものになってしまった。

おかしいこんなにも違うはずがないと、あちこち確認していくと出力イネーブル用のトランジスタのベース電流制限抵抗の値がブレッドボードとは違っていた。ブレッドボードは10Kを間違って挿していたが基板の方は1Kだ。

もしや10Kの方が良いのかと思って基板の方も10Kにしてみたところブレッドボードと同じ波形になった。しかし残念ながらツールの動作ははかばかしくなかった。部品のばらつきや配線の引き回しの違いなどが影響して必ずしも同じ効果が再現するとは限らないわけである。

すくなくともこれでTCKだけ波形を改善すれば問題は解消することが確認できた。一歩前進である。

波形が少し高くなった弊害として貫通電流が大きくなり以前は出力トランジスタのVceは0vで平坦だったが、今度は入力の立ち上がりと立ち下がりのタイミングで＋とーの山が出るようになった。これが出力波形の立ち上がりと立ち下がりのスロープ上に微妙なヒゲを作る原因になっている。これもなんとかしないといけない気がする。