DigilentのUSB-JTAG Programming Cableのドライバ

このDigilentのUSB-JTAG Programming Cableにはドライバがありません。

ドライバどころか、箱の中にはマニュアルさえありません。

デバイスドライバは、Firmware Loaderのまま止まっています。

何とかUG344にたどり着き、その中に記載されているug344_windows.zipをダウンロードすることはできました。

UG344によればWindows7まではサポートされているようなのですが、Windows 10 64bitで動くかどうかはわかりません。何とかやってみましょう。

解凍してみると、install_xusb.batがあります。

nt64フォルダの中にはドライバやinf、catがあるので、これをインストールすればよさそうです。

基本的にはデバイスマネージャからではなく、install_xusb.batを実行するようです。

インストールが終わると、Xilinx USB Cableというそっけない感じのドライバが登録されました。

詳細を見てみると、2007/10/01の日付で、バージョンは2.0.0.2とあります。

プロパティを見ると、おおジュンゴ！　これは嫌な予感しかしません。

実は、一発ではインストールは成功せず、いろいろガチャガチャやっているうちに、いつの間にか動くようになりました。

何をしたかというと、

• Windowsアップデートからドライバを探す
• ug344のドライバをインストール→うまくいかない
• Vivado 2018.2のdata\xicom\cable_drivers\nt64の中にあるドライバを再インストール→認識しない
• Vivado 2017.2のdata\xicom\cable_drivers\nt64の中にあるドライバを再インストール→認識成功
• ug344のドライバを再インストール

わかってきたのは、このドライバはDLC9という、黒いPlatform USBの亜種であることです。

Vivado2018.2などの比較的新しいVivadoではなく、古い2017.2くらいのVivadoに付属のドライバを入れないとダメなようです。

下の図のように謎のエラーで止まってしまったり、認識すらされないようです。

Vivadoのフォルダのdata/xicomは拡張機能の宝庫なので、ここを探すといろいろなお宝が見つかります。

2017.2のドライバを入れ、ug344に戻すと、Vivadoからも認識できるようになりました。

うまくいくポイントは、2017.2の中にあるinstall_drivers.exeを管理者権限で実行することのようです。

●ug344
2007/10/01 2.0.0.2 iMPACT・・OK Vivado 2018.2 OK

●Vivado 2017.2のdata/xicomからインストール
2007/10/26 2.0.0.3 iMPACT・・OK Vivado 2018.2 OK

●Vivado 2017.3
そもそもdata/xicomに該当ドライバがない

●Vivado 2017.4
そもそもdata/xicomに該当ドライバがない

●Vivado 2018.1
そもそもdata/xicomに該当ドライバがない

●Vivado 2018.2のdata/xicomからインストール
2007/8/28 1.0.0.0 iMPACT・・NG Vivado 2018.2 NG

●Vivado 2018.3
そもそもdata/xicomに該当ドライバがない

必ずしも新しいVivadoが良いというわけではなく、古いVivadoが必要になるようでした。

Vivado 2018.2をパッケージングした際の手違いのような気がしますが。

Digilentの古いUSB-JTAG Programming Cableを試す(1)

Digilentの古いUSB-JTAGケーブル「USB-JTAG Programming Cable」を買いました。

最近のDigilentのUSB-JTAGケーブルとは違い、中身はXILINXのEmbedded Platform Cable USBというキワモノです。

箱にはXILINX University PROGRAMと書かれています。

箱を開けると、本体とフライリードワイヤ、14ピンリボンケーブル、USBケーブルなどが入っています。

さあ、一体このケーブルは何者なのか。

フエルトだかゴムだかよくわからない素材でできていて、すぐに埃まみれになります。

これをWindows 10のPCに挿すと、Xilinx Embedded Platform USB Firmware Loaderとして認識されます。

デフォルトではファームウェアは書き込まれておらず、ローダーが起動してファームウェアを転送し、再度EnumerationしなおすというタイプのUSBデバイスのようです。おそらく中にはCypressのEZ-USB FX2か何かが入っているのでしょうか。

ベンダIDは3FD、プロダクトIDは000Dのようです。

クラスやサブクラスはFFになっていて、やる気のなさ 独自仕様感を感じさせます。

しかしながら、Xilinx Embedded Platform USB Firmware Loaderのまま変化せず、Windows 10では本体のファームウェアが読み込まれないようでした。

iMPACTからも認識させることはできませんでした。

どうやって使えばよいのでしょうか。

Cosmo-Z Miniの特注版の動作確認

徹夜で作業し、明け方にはCosmo-Z Miniの特注版が動くようになりました。

とてもホッとしております。

波形も見えるようになりました。ちょっと電源に起因すると思われるノイズが大きいかもしれません。

本当は今日納品したかったのですが、LEMOコネクタを買い忘れていたので昨日大急ぎでRSコンポーネンツに発注していました。

届いたLEMOコネクタを取り付けてようやく完成です。

アナログ部で±12Vとかの電源が必要になるのですが、いままで私は市販のDC-DCコンバータモジュールを使っていました。

ですが、今回はSEPIC-Cukコンバータという回路を使って自分で作ってみることにしました。正負の電源が必要で電流がほぼ同じような場合に使える回路だそうす。

↓がSEPIC-Cukコンバータの回路です。

コイルのL24とL23がちょっと汚れていますが、これはコイルの1番ピンの位置をシルクで示すのを忘れていたため、実装されたコイルを取り外して再度手作業で実装したためです。

これはCoilCraft社のコイルで、とても薄型で性能の良いものです。しかし、手作業での取り外しやはんだ付けは困難を極めます。

とても放熱が良いためか、外すには破壊するしかありませんでした。

使われている銅線もめっちゃ細い！

SEPIC-Cukコンバータについてはトラ技に解説があります。

https://toragi.cqpub.co.jp/Portals/0/backnumber/2007/12/p239-240.pdf

コイルを正しい向きに取り付けたら、設計通りの電圧を出してくれました。

☀

1日時間が出来たので、もう一晩くらいデバッグを行います。

朝になったらオフィスに行って波形を入れて測定してきましょう。

Cosmo-Z Mini特注版の基板実装あがり

Cosmo-Z Miniの特注版基板の実装が上がったので、17時ごろ、南武線沿線の某工場まで受け取りに行きました。

立派なZYNQですね。

今日は徹夜でデバッグです。

いくつかの抵抗値の間違えや、プルアップ/プルダウンなどを修正して、電源を入れます。

最初の火入れはとても緊張するのですが、皆さん、どうやってますか？

私は定電圧電流源で電圧を5Vに固定して、電流を徐々に増やしていくというやり方です。

☀

とにかく、この新しい基板が出来上がってきたときの緊張感はたまりません。

もし、失敗していたら数十万円と１か月が無駄になるし、納期が間に合わなくなってしまいます。

☀

祈るような気持ちで電源を入れて、異常な過電流や発煙が無いことを確認します。

普通はここでFPGAのサンプルデザインとかを作ってLEDチカチカとかするのでしょうが、そんな時間の余裕はないし、ZYNQのシステムなのでLEDチカチカで何とかなるほど単純ではありません。

MITOUJTAGをつないで・・・

☀

ZYNQが見えた！

少なくともFPGAは生きています。

バウンダリスキャンで一瞬で生死判別できるこの安心感はたまらない。

外部からのクロック入力や、コンフィグをしようとしてのSDカードへのクロック出力などががすぐに見えました。

MITOUJTAGを使えば、FPGAの中身を作らなくても基板に問題がないかどうかが一瞬で判別できるので、自分で基板を設計する人にとってはなくてはならないツールです。

DDR3メモリのDLLのOFFにするという機能

MITOUJTAG Proを使った基板検査をしていて、あるDDR3メモリにおける「DLLオフモード」の不具合を発見したかもしれません。

今回のCosmo-K DVI基板でDDR3メモリの検査をしていると、読み書きしたデータが2ワードずれるという現象に気が付きました。

この原因がずーっとわからなかったのですが、DDR3メモリの波形を良く見比べてみると、新しい基板ではDQSが出てくるタイミングが1クロック分遅くなっていることに気が付いたのです。

DDRメモリはCASを入れてからCas Latency(CL)クロック後にDQSとデータが出てきます。

基板検査で使っているスクリプトではCL=5に設定しているので、下の波形で正しいはずです。

しかし、昔に作った正常に動作していた基板では、CL=4で出てくるのです。

さて、どちらが正しいのでしょうか・・

☀

ちなみに、DDR3メモリにはCL=4という設定はありません。最低が5です。

新しい基板が正しいのか、古い基板が正しいのか・・・

新旧基板の違いは、使っているメモリが「AS4C256M16D3A-12BCN」か「AS4C256M16D3B-12BCN」かというだけです。

☀☀☀

原因がわかりました。

AS4C256M16D3A-12BCNのデータシートによれば、DLLをOFFにしたときには、CL-1クロック後に出るようです。

DLL(Delay Locked Loop)というのは、DDR3メモリの中に入っているクロック逓倍装置みたいなもので、FPGAの中に入っているあれと同じです。クロックが遅い場合にOFFにするというオプションがあります。

バウンダリスキャンによる検査は非常に低速なので、当然ながらDLLをOFFにするのですが、DLLをOFFにするとCL-1で出てくるのがAS4C256M16D3Aの仕様で、おそらくこれがDDR3メモリの正しい動作です。

AS4C256M16D3BではCL-1ではなくCLで出てきてしまうようです。

まぁ、DLL offモードなんていうマイナーな動作状態にする人は少ないから、あまり気が付かれないかもしれません。

Cosmo-K DVIの基板不具合調査

１月末に、新規に製造したCosmo-K DVIの8台のうち、2台がDDR3読み書きエラーで、2台がDDR3の初期化が完了しないという記事を書きました。８台中の4台が何らかの致命的なハードウェア不良を抱えていたことになります。

あまり自社製品の不具合を書きたくはなかったのですが、問題の原因を発見できた事例として書くことにしました。

DDR3メモリをUSB経由で読み書きするアプリを試してみると、ビット化けが起きているようでした。

これは厄介な問題だな・・と思っていたのですが、どうやらDDR3だけではなくFPGA内のブロックRAMに対して読み書きした場合でもこのエラーが起きていました。

FPGAでグラデーション的な画像を発生させて表示させてみると縞模様が見えるので、これはUSBインタフェースチップ(EZ-USB FX3)とFPGAとの間の問題ではないかと疑いました。

そこで、MITOUJTAG Proを使って検査を行いました。

まず使ったのはシンプル基板検査機能。

JTAGバウンダリスキャンを使って端子を1つずつHLHL・・・と、トグルさせて、別の端子から同じ波形が出てくるかどうかで導通試験を行うというものです。

テストパターンの作りこみもネットリストも要りません。FPGAのピン定義ファイル（XDCファイル）を読み込んで、開始ボタンを押すだけでスタートするので簡単です。

実際にやってみた結果が下の図です。

なんと！FX3とUSBの間のデータバスの24と27が導通しているではないですか！？

基板上のどの場所かというと、この配線。

長い距離を平行して走っているので、このどこかでショートが起きているのかもしれません。ちなみに余った生基板をテスターで測ったところではショートしていなかったし、基板屋さんによればフライングチェッカーで100%検出できるとのこと。

そうなると実装時にブリッジしてしまったとしか考えられません。基板屋さんによれば、実装屋さんから孫請けに出したときにX線検査をしなかったとのこと。8台中の4台でこの現象が起きていました。

⚡

さらに、4台中の2台はDDR3メモリの起動さえしません。

これについてはMITOUJTAG ProのAdvanced JTAG Function Generator(以下、AJFG)という機能を使って確かめました。

AJFGを使うとC++で端子の動作を書いて、FPGAを論理合成せずにバウンダリスキャンで動作させることができます。

論理合成する必要がないので、トライ＆エラー方式で迅速に何度でも気軽にいろんな動作を試せます。

DDR3メモリの端子を操作するサンプルプログラムをこのボードに適合するように書き換えて実行してみると、確かに「エラー」と表示されます。

波形で見てみると、メモリ読み出し時にDQS_P[2]が動いていません。

しかしながらDQS_N[2]は動いているので、Readコマンド(RAS NOP NOP CAS)はDDR3メモリに正しく伝わっていると考えられます。

そこで、バウンダリスキャンでこの辺りの端子を操作してみると、AE5番(DQ[19])とAF5番(DQSP[2])が一緒に動くことが確認できました。

基板の配線では平行して走っている区間はないので、FPGAのBGAパッドのショートなのでしょう。

幸いなことにTOP層を走っている配線と、終端抵抗のViaに出ている配線だったので、テスターで測ってみると、見事に導通していました。

いかがでしたでしょうか。

通常ならば「ショート箇所を発見するだけのためのFPGAデザイン」を作って、何度も論理合成して試さなければわからなかったような調査を、MITOUJTAG Proのシンプル基板検査機能と、AJFG機能を使ったことで基板の実装不具合を迅速に行うことができました。

このようなJTAGを使った基板検査技術が、同じように基板の不具合で悩む皆様のお役に立てば幸いです。

Artix-7ボードの実装があがってきた

特電Artix-7ボードの実装が上がってきました。

取り急ぎ6台だけ動作検証を行ってみました。

USB3.0の動作速度も370MBytes/s超が出ていて、問題ありませんでした。

とりあえず一安心。

Cosmo-Z Mini特注版の基板が出来上がってきた

Cosmo-Z Miniの機能を10cm以下に凝縮し、さらに低速のADC/DACを16chずつ用意したボードが出来上がってきました。

3/14(木)に出図して3/16(土)に出来上がって、3/17(日)に到着という超特急製造です。

急ぎで作ったので、金フラッシュではなくプリフラックスになってしまいました。

問題は、これを超短納期で実装してくれる業者さんがなかなか見つからないこと。

ZYNQのSDカード用クロックと終端抵抗

ZYNQの試作基板を設計して、今日、ようやく出図ができました。

しかし、出図後に、SDカードのクロックに終端抵抗を入れ忘れていたことに気が付きました。

このSDクロックは、基板の内層を通っているので、軽微なパターン修正では抵抗を挿入できません。

ちなみに、Cosmo-Zでは開発初期の試作機でこのSD_CLKを入れ忘れて、何か苦労して、量産機からは22Ωの直列終端抵抗を入れるようにした記憶があります。

↑はCosmo-Zの現行バージョンの回路図ですが、ちゃんと、22Ωが入っています。ちなみに、ZYBOでは40.2Ω、TE0720では33Ωが入っているので、SD_CLKには何かしらの直列終端が必要なのでしょう。

この終端抵抗がないとどうなるのでしょうか。

手元にあるCosmo-Zを使ってZYNQのSDカード用クロックの終端抵抗の効果を実験してみました。

まずはCosmo-Zの通常のSDクロック波形を示します。22Ωを介した状態です。MIO Bank501の振幅は1.8Vです。ちょっとリンギングが出ていますが、許容範囲です。

この抵抗をショートして0Ωにしました。つまり直列終端がない状態です。信号線の長さは135mmです。FPGAを大きく迂回しているので結構な長さがあります。

かなりリンギングが激しくなっているのがわかります。一応これでもSDカードからZYNQは起動できますが、不安がいっぱいです。

では、直列終端抵抗を使わずにリンギングを治めるにはどうすればよいでしょうか？

一つのテクニックとして、AC終端というのがあります。

回路的にはこんな感じです。

目的のICのインピーダンスが高いため、電圧が反射して戻ってくるのがリンギングの原因なので、目的のICの近くで低いインピーダンスの抵抗でGNDに落とせばよいのです。しかし抵抗だけをつなぐと電圧レベルが減ってしまうし電力がもったいないので、コンデンサをつけます。

ここでは100Ωと33pFにしましたが、値は適当でかまいません。本当はプリント基板上の配線のインピーダンスと合わせるのがベストですが、そこまで精度は要求されません。

直列終端をなくしてAC終端だけにした場合の波形はこちらです。

直列終端よりもむしろ綺麗になりました。

直列終端が使えないとき(入れ忘れたとき)や、クロックのリンギングが気になる場合には、ぜひAC終端を試してみてください。

きっと何かが変わるはずです。

BGAをリワークして、Cosmo-Zの修理成功

先日の記事で、Cosmo-Zがお客様先で壊れて戻ってきたので、実装業者に送ってFPGAを再加熱してもらったらFPGAの中の電源がすべて導通して完璧に壊れて戻ってきたので、厄除けに行ったという記事を書きました。

その壊れた基板と新品のFPGAを実装業者さんに送り、FPGAを新品に交換してもらいました。

そうしたら、見事に復活！

念入りに動作テストを行っていますが、特に問題は起きていないようです。

すばらしい。

これが導通してしまったFPGA。

いずれ暇な時が来たら、テスターで電源ピンを１つ１つ当たってみたいと思います。

BGAリワーキングの素晴らしい技術をお持ちの実装業者さんでよかったです。

Amazonの倉庫にいろいろ送る

今日は、Amazonのフルフィルメントにいろいろな商品を作って納品しました。

• MITOUJTAG BASICフルセットを3個
• Artix-7ボードを計7個
• Zynqberryスタータキットを6台

Amazonのセンターに預けておくと、自分で出荷するよりも手間がかかりません。土日でもWeb管理画面から出荷できるし、佐川急便やヤマトさんが集荷に来てくれるのを待たなくてもよくなります。それに商品出荷のための人を雇う必要がない。

さらに、製品を出荷するための外箱の段ボールをどうするかという悩みが完璧に解消されるのがありがたいですね。

配線済みのDDR3の塊を移動した

ZYNQとDDR3の配線ですが、いま、だいたいこのようになっています。

全体的に配線が右斜め上に向かっているので、DDR3のブロックを5mmほど下に下げました。

作業を始める前はめちゃめちゃ気が重かったのですが、いざやってみると意外と簡単で、50分くらいで終わりました。

一度配線に成功したものは並びがよくなっているので、多少の移動に関してはそれほど難しくはならないのでしょう。

ZYNQ用DDR3メモリの配線戦略

ZYNQ7000シリーズ、484ピンの基板を設計していて、DDR3メモリのデータバスを引いたところで行き詰まってしまいました。

ZYNQの484ピンでは、RASやCASといった制御線と、BAやADDRといったアドレス線はFPGAの内側のほうから出ています。

これに対して、DDR3メモリのピン配置はデータ、データ、RAS,CAS、ADDRという順に並んでいるので、データバス同士を内側に向けた配置がベストと思われます。そうすると、データバスが表面の1層だけでほぼ直結できるからです。

アドレス線と制御線はFPGAの奥のほうのパッドから出ているのでViaを使うのが必須となります。必然的に内層を通ることになります。

ここで、データバスの先にあるDDR3の制御線に配線するときに上から通すか、下から通すかという選択を迫られることになります。真ん中から通すという選択肢はありません。

次の図のように上から通した場合、RAS,CASなどの制御線はある程度右に出てから上に行って右折してDDR3メモリに到達しますが、どうしてもアドレス線とクロスしてしまいます。内層でクロスするとViaがさらに必要になり、配線は困難となります。

これで行き詰まってしまいました。

下から通すと内層の配線はクロスせずにDDR3まで到達できそうです。

実際にやってみると、うまく配線できました。

この配線がどうなっているか、層ごとに分解してみてみましょう。

まずTOP層。ほとんどがデータバスで占められています。

次は内層1。

下から回って北上していますね。

次は内層２。

これも内層１とだいたい同じような傾向です。

最後は半田面。

バイパスコンデンサと電源の配線があり、たまに配線がある程度です。

このように4層＋電源2層で引くことができました。

全体として見れば、DDR3メモリの下に何もない部分ができてしまい勿体ないので、あと1cm下に、DDR3の塊を下げたいなと思います。

ZYNQ用DDR3メモリの配線

何か月ぶりかの基板設計です。

ZYNQの484ピンとDDR3メモリの間の配線なのですが、32bitのデータバスを引くことができました。

この１年くらい何かが足りなくて、設計やプログラム開発といったクリエイティブな仕事ができなかった気がします。ようやく長いトンネルを抜けたように、設計ができるようになってきました。