高速ディジタル信号に入れるバッファICの効果を確かめてみた

月曜日に注文したバッファIC、SN74AUC125RGYRがもう届きました。

早速、DAC8基板に実装して評価したいのですが、まずは、現在付いているSN74AUC126RGYRを外さなければなりません。

上の写真のSN74AUC126RGYRもバッファICなのですが、OE(出力イネーブル)の論理が逆だったので動いていません。そのため半田ブリッジしてバイパスしています。今回入手したSN74AUC125RGYRはOEが負論理なので同じ基板でも取り換えれば動くだろうと思われます。

ただ、コネクタの横にあるICを外すのは難しいので、基板の裏にある簡単そうな1か所だけを交換します。

それが、この場所。すでに何度も付けたり外したりしているので、汚いです。

いままでDACの入力部分の波形はバッファを使わなかったのでこんな感じだったのですが、

バッファを通すとこうなりました。

これは滅茶苦茶期待できるではないですかーーーーーっ！

次の図は、たぶん160MHzのビットレートで送った場合ですが、反射によって信号の立ち上がり後に小さな凹みがあるのがわかります。

バッファを入れると綺麗な矩形になります。

次の写真はビットレートは250MHzで送った場合です。反射やクロストークによって波形の天井と床がブレブレになっているのがわかります。

データとクロックはDDRで90°ずらして送るので、↑の波形の中央にクロックの遷移が来ると結構厳しそうな感じがするのがわかるかと思います。実際にクロックの位相を微調整してDACからデータが飛ばないように出力させるのは難しかったです。

バッファICを入れた場合は、下の写真のようにくっきりとします。

これならきっとデータ転送のエラーも起きないでしょう。

LVCMOS18の信号をFPGAから送る場合、距離が長くなると長くなると厳しくなりますが、74AUCシリーズのバッファICと抵抗を入れるだけで非常に改善できることがわかりました。

反射しまくっている汚い信号はバッファICで受けて、綺麗になったバッファICの出力は（ダンピング抵抗で弱めてから）DACへ送るというわけです。こうすると、FPGAの出力電流を必要最低限に絞ることができるし、DACには綺麗になった波形を（弱めて）与えることができます。　

心配なのはSN74AUC125内あるいはSN74AUC125間でのタイミングのずれがどれくらいあるかということです。もし到達時間に大きな差があると、ビットの到達時間がバラバラになってしまいます。

なお、74AUC125RGYRは非常にはんだ付けが難しいICで、付けたり外したり、ヒートガンであぶったりを繰り返しているうちにパターンがどんどん剥がれていって、それをジャンパでカバーしているのでどんどん汚くなってきました。

写真左下のほうは焦げているし、電圧リファレンスICが熱風でどこかへ吹き飛んでいきました。

手作業でやるようなICではありません。

暴れるLVCMOS18

開発中の8ch 125MHz DACボードは、FPGAとDACを直結せずにバッファを入れています。

なぜかというと、FPGAの端子からこの基板までは距離が長いので、LVCMOS18では信号の反射やサグが目立ってしまうからです。

下の図は、基板上のDACの信号線です。

反射によって信号電圧にピークが出るし、HHと続くところとHLとなるところではベースラインが変わってきてしまいます。

それでも、CLKとDATAの位相をうまく調整すれば125MHzで動かないこともないのですが、反射した信号はノイズとなってDACの出力を乱します。だから、FPGAとDAC間の信号で使われる電流は少なければ少ないほどいいのです。

幸い、XILINX FPGA (7シリーズ)では、XDCファイルにDRIVE制約を書けば、出力電流を2mA,4mA,6mA,8mA,12mA(デフォルト),16mAで変えることができるので、電流を絞れば反射は抑えることができます。

こんな感じで書きます。

set_property DRIVE 8 [get_ports {dac1_data_op[*]}]

電流を減らして反射を抑えると波形の立ち上がりがなまって遅くなるので高速な動作ができなくなり、電流を増やすと立ち上がりは鋭くなりますが反射によってビット間干渉を起こしノイズ源にもなります。つまり、基板によって最適な出力電流があります。

7Series FPGAのI/OにはDCIとかいう機能もあって出力インピーダンスを変えることができるので、この出力電流の調整はDCIと同じような機能を用いて実現しているのでしょう。

例えば、1.8VのLVCMOS18にして6mAの設定にした場合、300Ωの抵抗が出力ピンに直列に入るのではないかと想像しています。ダンピング抵抗の大きさを変えているのとみなすことができます。

電流を絞ってもFPGAから来た信号はLVCMOSですから受信側ICの入力インピーダンスで反射するので波形は乱れます。それをDACで直接受けるとノイズとなって混入します。そのため、間に一度バッファを入れたいのです。

バッファの前に220Ωの終端抵抗で受けるようにすることで、8mAの電流でも1.7Vの電圧を確保してLVCMOS18の閾値を超えるようにしました。

次の図はFPGAからの電流を変えながら測ったときの波形です。

どういう設定だったかは忘れました。

LVCMOSはシングルエンドで終端抵抗も何もない規格ですが、無理やり終端抵抗を入れることで反射を少しだけ抑えることができます。

理想は下の図のような波形をこの6倍の速さで動かすことです。

SN74AUC126のOEは正論理

DAC8基板でFPGAから来るディジタル信号をDACに直接与えないようにするために入れていたバッファSN74AUC126ですが、どうもこいつのOEは正論理だったようです。

SN74AUC126のピン配置は、入力と出力が隣り合っているので、

ピンを半田でブリッジしてバイパスしました。

 

これで動くようにはなったのですが、歪率が-40dB台で極端に悪い。

なぜだ・・・・？

今回のDAC8基板では出力段のAD8021を±2.5V電源で動作させるように作ってしまったのですが、これが痛恨のミス！

AD8021はレールツーレールではないから、±2.5V電源だと±1Vの振幅が取れないうえに歪率が若干悪化するようです。

せっかく作ったばかりの基板なのにジャンパを飛ばしてAD8021に±5Vを供給するようにしたのですが、それでも歪率が-50dB台しか出ません。

ためしに、AD8021を外してみると-80dB台になる。

差動増幅回路が悪いのかと思い、前回と同じ非反転増幅回路にしたり、単純なボルテージフォロアにしてみても歪率は-50dB台。

高周波での発振をしているわけでもない。

今度はAD8021をOP211AIDRに置き換えてみると-80dB台になる。

AD8021が歪率を30dBも悪化させるという謎の現象で足止めを食ってしまいました。

祭礼のためお仕事休み

今日は地元の神社のお祭りのため、仕事は休み。

厳密にいえば、うちの町会ではなく、隣の町会のお祭りのお手伝いです。

おみこし担いできました。

明日からまたデバッグするぞー！

Spartan-7基板とDAC8基板が届いた！

Spartan-7基板とDAC8基板を面付した基板が届きました。

早速実装していきたいと思います。

まず、DAC8基板で最大の懸案だったのは、クロックと思われるノイズがアナログ出力に混入していることでした。

DACを実際に動かさなくてもDGNDやAGNDを介して（だと思う）伝わってくるノイズがあって、それが取り切れませんでした。

以前のDACボードでは、コネクタだけ取り付けた状態でこのくらい見えていたノイズが・・

新DACボードではほとんど見えなくなりました。

見えているのはオシロ自体のノイズや、同軸ケーブルが拾ってしまう周囲のノイズです。

GNDの分離、アナログ部とディジタル部の分離などは大成功といえるでしょう。

夜遅くまでかかったけれど、一気に実装を仕上げてしまいました。

ZYNQ本の体裁を整える

Wordって難しいですね。

見出しの書式とかを整えて、それっぽく仕上げてみました。

いままで、見出しは1段組で本文を2段組みにするにはセクションを分けなければならないと思っていたのですが、実際には範囲を選択した状態で「レイアウト→段組み」でいけました。

用紙はB5サイズで、2段組の中の1段の横の文字数は24、縦は49行くらいにしました。これでトラ技とだいたい同じくらいの文字数になるのかなと思います。

現在、150ページくらい。

ZYNQ本の執筆開始

技術書典に向けてZYNQの本の執筆を開始しました。

執筆開始といっても、まずは、私がブログに書いてきた約7年分の記事を1つのWordファイルにまとめる作業です。

現在、174ページ。

段組みを設定したり書式（リストの部分は詰めるとか）を設定すれば大幅に減るだろうし、カーネルの構築について書けば増えるだろうし、まだ何ページになるか予測が付きません。

DAC8基板とSpartan-7基板の出図

今日から旅行のため朝4時半に出発しなければなりません。

しかし、基板製造も開始したいので、それまでに出図を完了しておかねばなりません。

そういうわけで、徹夜で仕上げです。

バッファ周辺のパスコンを強化したり、1.8VのLDOを基板に乗せたり、部品番号の付け直し、シルクの位置修正などを行いました。

出来たのがこの基板。6層です。

表面とシルク

裏面とシルク。

そして、面付した全体。

データを送ったのが午前3:47でぎりぎり間に合った。30分は寝れそうです

8ch DAC基板の再々設計（続）

昨日の続きの配線を行っています。

何とか8CHのOPアンプ、DAC、バッファの配置配線ができました。

電源回路は前回は自作のDC-DCでしたが、ノイズが大きかったので市販のモジュールを使うように戻しました。

これでひとまず完成です。

表面はこんな感じ。

裏面はこんな感じです。

8ch DAC基板の再々設計開始

Spartan-7の基板がひとまず完成したのですが、面付して別の基板も一緒に製造してコストを下げます。

というわけで、8CH DAC基板も再々設計開始です。

まず、ノイズの削減ですが、ディジタル系で使っているDACのクロックと同じ成分のノイズが出力に乗ってきてしまっていましたが、メザニンコネクタとDAコンバータをいままで直結していたのとDGNDが基板の広い面積を占めていたためだと思われます。

そこで、FPGAから来た信号を1kΩくらいでDGNDに落としディジタルの帰り道を作り、その後ろに高速バッファで分離して、バッファの後ろにダンピング抵抗を入れる回路にしました。

メザニンとDACの配線はいままで直結だったのですが、その直結していた配線幅＋αくらいの幅にに、なんとか終端抵抗とバッファとダンピング抵抗を実装できそうなことがわかりました。

使ったバッファはSN74AUC126。AUCシリーズというのは1.8Vで動作して数百MHzまでいけそうです。74126は4chのバッファで効率悪いのですが、これ以外に使えそうなものはありません。

表面はこんな感じ。

裏面はこんな感じ。

出力段のOPアンプの回路を圧縮することで、なんとか配線幅を確保し、4ch分のバッファ、DAC、OPアンプ回路を乗せることができました。

今日はここまで

Spartan-7基板の再々設計完了

Spartan-7ボードの再々設計が完了しました。

TOP面はこのような感じ

BOTTOM面はこのような感じになっています。

内層はこんな感じです。

更新点はというと

• MOS FETで作っていたUSBの電源逆流保護回路をダイオードに変更
• USB Type-CコネクタのFootprint修正
• 5V入力のラインに100uF相当(47uF×2)を入れる
• 10uFコンデンサを2012サイズにする
• 3.3VのラインにTVSダイオードを入れた
• PHYのデジタル電源にEMIフィルタを入れ、外すことで完全に切り離せるようにした
• GPIOの差動ペア内等長配線
• MIPI CSIの配線を修正し、全線完全な等長配線とした。
• MIPI CSIの配線はHSだけでなくLPの側も差動ペア内等長配線にした。
• 不要なGND島と半島の削除
• コイル下のGNDパターンを外す

MIPIの配線に関しては、終端抵抗の後ろにFPGAのパッドを置き、その後ろにスタブを伸ばしてHS-LP間抵抗100Ωにつなぎました。LPの信号はHSUL12で受けますが、入力インピーダンスは高いはずなので、100Ωを通ってきた信号はLPの入力端子で反射するはずです。その反射した信号はおそらく150Ωの終端抵抗で再度吸収されますが、LPの部分の差動ペアの配線長に差があると次のHighSpeedの信号を乱すはずです。

つまり、MIPIのLPは遅い信号だけれどもHSと同じく等長配線しなければならないのでは？と思ったわけです。

それから、出力されたガーバをつぶさに調べていて、恐ろしい部分を発見しました。

7月再設計したSpartan-7ボードの試作版(非売品)では、MIPIの信号がつながる端子を変更したために設置したViaで、内層のVCCが細くなっていました。

わずかな隙間でかろうじてVCC1.0が接続されていたのです。恐ろしい。

テスターで測ってみても0.1Ωの違いもないのですが良くないですね。

邪魔なViaを右に移動させることができたので、事なきを得ました。

USB Type-CコネクタCX90B1-24PのFootPrint

Spartan-7ボードの改版試作版を作ったときに、実装業者さんから「ボス穴がなくてUSB Type-Cのコネクタが刺さらなかった」と聞いていたので、今日はこのコネクタの穴を徹底的に見直すことにしました。

USB Type-CコネクタというのはHIROSEのCX90B1-24Pで、空いていなかったボス穴というのは下の図の赤い枠で囲った部分のピンです。

横から見るとこうなっています。

このコネクタのFootprintは、一見して何がなんだかわかりません。

非常にわかりにくいのですが、□の枠にYと書かれた部分の丸いやつ(Φ0.60)を座標の原点に考えると理解しやすくなります。

図面の数字には四角い枠で囲ったものと、（）が付いた数字、それから何もない数字がありますが、枠付きの数字は絶対に守らなければならない値で、（）は参考値で誤差が多少あってもよいもの、何もない数字は一般公差であるようです。

この図面を読み解いていくと、気になるボス穴や固定用の穴のサイズは以下のようになっていました。

鬼畜と言えるのは、開け忘れたボス穴と横の耳の部分はL字型の穴として一体として開けることと、そのL字型の縦と横の幅が異なること。

それから、プラスチックのボス穴は左が0.6mmで、右側は0.5mmの長穴ということです。

試作基板で作ったFootprintではよくわからず適当に作ってしまったため、USBのコネクタが実装不良を起こしていたようです。肝心の24ピンの端子も0.3mm上下にずれていたので、ケーブルを触るとたびたび通信が切れるということが起きていました。

MIPI CSI RXはどのくらいの速度まで上げられるのか？

開発中のSpartan-7ボードでMIPI CSIの実験を行っています。

下の図を見てください。

光のまわりに黒い点々が見えますね。

これは、RasPiカメラV2から912Mbpsのラインレート(標準)で出したデータをSpartan-7で受け取ったときにエラーが出てしまっているため、ビットが化けて点々が出てしまっているのです。

1280×720のとき(ラインレート552Mbps)には出なかったのですが、912Mbpsで出るようになってしまった・・とほほ

というわけで、これを消す方法をいろいろ考えました。

最初は急冷材をかけてFPGAを氷点下まで冷やしました。

するとノイズが消えたので、間違いなくFPGAでタイミングが間に合っていないのだと思われます。

次にMIPI CSI RX SubsystemコアのCalibrationをONにすることを試みました。

上のように設定すると自動でIDELAYE2のディレイを調整してくれるそうなのですが、結果は失敗。画像が出てこなくなりました。

また、データシート(PG202)によれば、キャリブレーションを使うときにはDIFF_TERMをONにするという記述があるのですが、DIFF_TERMをONにするとLVDSの2.5VのVCCIOが必要になります。当該バンクは3.3Vなので結局不可です。

そもそもSpartan-7は900MbpsのMIPIのレートに対応しているのかという心配があったのですが、

Spartan-7のデータシートによれば入力をDDRレジスタで受ければ1250Mbpsまではいけるとのこと。MIPI RXをインプリメントしたデザインを見て見ると、ちゃんと入力はDDRで受けているのでこれも問題なし。

特電Spartan-7ボードでは912Mbpsのラインレートが使えないのかと途方に暮れていましたが、回路図で一つ気になっているところがあって、このHSとLPをつないでいる抵抗なのですが、これを150Ωを実装してしまっていました。

他所の回路図ではみんな100Ωなので、ためしに100Ωに乗せ換えてみると・・

よかった！912Mbpsでも黒い点々が出ない！！

Spartan-7にRaspiカメラV2をつないで、912Mbpsのレートを達成できました。

ちなみに、30C,30DのPLL_OP_MPYレジスタを操作してビットレートを変えてみると、1024Mbpsの時には点々のゴミが出るようになってしまいました。

944Mbpsでも点々が出始めるので、特電Spartan-7ボードではこのあたりが限界なのかもしれません。

iMX219の水平垂直タイミングとデータレートの関係を理解した

今日もSpartan-7ボードでMIPI CSIを通じてRasPiカメラV2を扱うための開発をしています。

昨日までにRasPiカメラV2の画像を1280×720で取り込めるようになってきたのですが、より高い解像度で取り込んでみたくなりました。このカメラは3280×2464ピクセルがあるので、もっと高い解像度が出せるはずです。

それから、解像度とクロックレートの関係もいろいろと実験したいと思っていました。

そのためには、カメラレジスタの設定をいろいろと変えなければならないのですが、これを理解するのにはクロック関係の内部構造について理解しておかねばなりません。

1920×1080や、3280×2464で出力するときの、標準的なクロックの設定は以下のようになっています。

まず、入力した24MHzのクロックを3分周して8MHzを作り、それを114倍して91.2MHzにします。この周波数はFIFOの左側と右側で別々に設定することもできるのですが、標準設定では同じく91.2MHzになるようにしています。

読み出しピクセルレートは91.2MHzですが2画素を同時に読みだすので192.4MHz相当の速度となります。

この91.2MHzの10倍の912MHzがMIPIのデータレーンに送り出される信号のビットレートとなります。

信号は8bitごとにカプセル化されるのですが、5バイト(40bit)を使って4ピクセルを送ります。5バイト分に4×10bitが入るように5バイト目に2bitずつ詰めるようなやり方でエンコードされます。（4pixelを5バイトに詰め込んでいるということは、有効ピクセルを読み出す時間の1.25倍の時間をかけてデータを送り出しているのだろう）

MIPI CSI RX Subsystemが出力するrxbyteclkhsは912Mbpsの8分の1の速度なので114MHzになります。ただし垂直ブランキング期間にはrxbyteclkは停止するようです。

iMX219では解像度によらず水平ラインのクロック数は3448で固定なので、3448÷91.2MHz=17.92μ秒というのが水平ラインの時間になります。

画面の解像度によらず、上の図のPLLの倍率(114というもの)を上げない限り、水平期間は17.92μ秒で変わりません。基本的にはフレームレートは1画面中のライン数で決まります。

下の図は横3280pixelの最大解像度の時のFPGA内部の波形です。水平ラインの長さ(tlastの間隔)は18usであることがわかります。

約18usの間に3280pixelのデータがやって来るのでデータレートは182Mpixel/sとなります。そのため、AXI Streamのクロック速度を200MHz以上にするか、2ピクセルを同時に扱えるようにAXI Streamのビット幅を広げる必要があります。

水平時間は17.92μ秒になるので、2500ラインで44.75msとなり、約22fpsになります。

3280×2464のときのI2Cの設定例を示します。

x"0114" & x"01",-- CSI_LANE_MODE = 2-lane
x"012A" & x"18",-- EXCLK_FREQ[15:8]
x"012B" & x"00",-- EXCLK_FREQ[7:0] = 24 MHz
x"015A" & x"01",-- INTEG_TIME[15:8]
x"015B" & x"F4",-- INTEG_TIME[7:0]
x"0160" & x"09",-- FRM_LENGTH_A[15:8]
x"0161" & x"C4",-- FRM_LENGTH_A[7:0] = 2500
x"0162" & x"0D",-- LINE_LENGTH_A[15:8]
x"0163" & x"78",-- LINE_LENGTH_A[7:0] = 3448
x"0260" & x"09",-- FRM_LENGTH_B[15:8]
x"0261" & x"C4",-- FRM_LENGTH_B[7:0] = 2500
x"0262" & x"0D",-- LINE_LENGTH_B[15:8]
x"0263" & x"78",-- LINE_LENGTH_B[7:0] = 3448
x"0170" & x"01",-- X_ODD_INC_A 
x"0171" & x"01",-- Y_ODD_INC_A
x"0270" & x"01",-- X_ODD_INC_A 
x"0271" & x"01",-- Y_ODD_INC_A
x"0174" & x"00",-- BINNING_MODE_H_A = x1 no binning
x"0175" & x"00",-- BINNING_MODE_V_A = x1 no binning
x"0274" & x"00",-- BINNING_MODE_H_B = x1 no binning
x"0275" & x"00",-- BINNING_MODE_V_B = x1 no binning
x"018C" & x"0A",-- CSI_DATA_FORMAT_A[15:8]
x"018D" & x"0A",-- CSI_DATA_FORMAT_A[7:0]
x"028C" & x"0A",-- CSI_DATA_FORMAT_B[15:8]
x"028D" & x"0A",-- CSI_DATA_FORMAT_B[7:0]
x"0301" & x"05",
x"0303" & x"01",
x"0304" & x"03",--最初で3分の1して8MHz
x"0305" & x"03",--最初で3分の1して8MHz
x"0306" & x"00",-- PLL_VT_MPY[10:8]
x"0307" & x"39",-- PLL_VT_MPY[7:0] = 57倍。左は456MHz
x"0309" & x"0A",-- OPPXCK_DIV 
x"030B" & x"01",-- OPSYCK_DIV 
x"030C" & x"00",-- PLL_OP_MPY[10:8]
x"030D" & x"72",-- PLL_OP_MPY[7:0] = 114倍。右は912MHzつ

次の波形は1920×1080のものです。

19usの水平間隔の間に送られてくるデータ量が少し減って、AXI Streamの占有率に余裕が出てきたことがわかります。

次の波形は1280×720のものです。ラインレートは上の2つの波形とは異なります。

レジスタ設定はZynqberryで使われていたもので、以下のようになっています。

x"012A" & x"13",-- EXCLK_FREQ[15:8]おそらく間違い
x"012B" & x"34",-- EXCLK_FREQ[7:0] = 4916 MHzおそらく間違い
x"0160" & x"04",-- FRM_LENGTH_A[15:8]
x"0161" & x"60",-- FRM_LENGTH_A[7:0] = 1120
x"0162" & x"0D",-- LINE_LENGTH_A[15:8]
x"0163" & x"78",-- LINE_LENGTH_A[7:0] = 3448
x"0164" & x"01",-- XADD_STA_A[11:8]
x"0165" & x"58",-- XADD_STA_A[7:0] = X top left = 344
x"0166" & x"0B",-- XADD_END_A[11:8]
x"0167" & x"77",-- XADD_END_A[7:0] = X bottom right = 2935
x"0168" & x"01",-- YADD_STA_A[11:8]
x"0169" & x"F0",-- YADD_STA_A[7:0] = Y top left = 496
x"016A" & x"07",-- YADD_END_A[11:8]
x"016B" & x"AF",-- YADD_END_A[7:0] = Y bottom right = 1967
x"016C" & x"05",-- x_output_size[11:8]
x"016D" & x"10",-- x_output_size[7:0] = 1296
x"016E" & x"02",-- y_output_size[11:8]
x"016F" & x"E0",-- y_output_size[7:0] = 736
x"0170" & x"01",-- X_ODD_INC_A 
x"0171" & x"01",-- Y_ODD_INC_A
x"0174" & x"01",-- BINNING_MODE_H_A = x2-binning
x"0175" & x"01",-- BINNING_MODE_V_A = x2-binning
x"0176" & x"01",-- BINNING_CAL_MODE_H_A
x"0177" & x"01",-- BINNING_CAL_MODE_V_A
x"018C" & x"0A",-- CSI_DATA_FORMAT_A[15:8]
x"018D" & x"0A",-- CSI_DATA_FORMAT_A[7:0]
x"0301" & x"05",
x"0303" & x"01",
x"0304" & x"02",-- 最初は2分の1で分周。12MHzを作る
x"0305" & x"02",-- 最初は2分の1で分周。12MHzを作る
x"0309" & x"0A",-- OPPXCK_DIV 
x"030B" & x"01",-- OPSYCK_DIV 
x"0306" & x"00",-- PLL_VT_MPY[10:8]
x"0307" & x"17",-- PLL_VT_MPY[7:0] = 23。左は12MHz×23=276MHz
x"030C" & x"00",-- PLL_OP_MPY[10:8]
x"030D" & x"2E",-- PLL_OP_MPY[7:0] = 46。右は12MHz×46=552MHz

データレーンのラインレートは552Mbpsで、ピクセルレートは110.4MHzとなります。1水平時間は3448÷110.4=31.23usとなります。フレーム長が1120ラインなので、垂直時間は34.9776msとなって、フレームレートは28.65fpsとなります。

なお、この設定ではEXCLK_FREQレジスタの設定がおそらく間違えていて、コメントにあるような4916MHzであるわけがありません。

おそらく、EXCK_FREQレジスタの[15:8](0x12A番地)にはクロック周波数(MHz)の整数部を設定し、[7:0](0x12B番地)にはクロック周波数(MHz)の小数点以下の部を設定するのが正しいのでしょう。

だから、データシートにあるように7.6MHzのときには7Hと99Hになります。99H=153dで153/256=0.597なので、799Hで7.597MHzという意味になるのだと思います。しかしながらEXCK_FREQの設定が何かに使われることはないように思えるので、適当でいいのかもしれません。

なお、動作中にPLLの倍率を変更する場合には、レジスタの0x100にあるMODE_SELレジスタに0を一度書き込んでスタンバイにしてから、0x100に1を書き込んで再び動作させないと反映されないようです。

このあたりの仕組みを理解できたので、フレームレートもデータレートも自由自在に設定できるようになりました。

なお、このPLLの設定を理解する上で、RyuzさんのZYBO-Z7 で Raspberry Pi Camera Module V2 (Sony IMX219) を 1000fpsで使うサンプル (復刻記事) がとても参考になりました。この場を借りて御礼申し上げます。

RasPiカメラ2をSpartan-7ボードにつないで画像が撮れた

RasPiカメラ2はiMX219型番のCMOSイメージセンサだそうです。

ようやく綺麗な画像が得られるようになりました。

最初に撮れた装置の自画像がこちらです。

ちょっと暗いかな～と思っていたのですが、イメージのデータは10bitなのに[11:2]だけを見ていたのが原因でした。

FPGAから制御できるコントロールレジスタを作り、10bitの生画像データに0~63の値を掛けて16で割った値を取り出せるようにしました。つまり、ゲインを0~4でコントロールできるというわけです。

暗いところが見えるようになりましたが、今度は明るすぎる感じですね。

iMX219はコントラストの調整などがないようなのですが、どうやったらもっと鮮やかな色が出るのでしょうか？？ガンマ補正みたいなテーブルを用意したり取り込んだPC側で処理するしかないのでしょうか。

結局のところ、最終的なBlockDesignは下の図のようになりました。

Video DMA coreと書かれているvideo_bloganaというのはAXI Streamで送られてくる画像をAXIに投げるものです。tuser(0)をフレームの開始としてtlastを水平ラインの終了として、AXIのトランザクションを発生させるものです。

XILINXのVideo DMAは正直言ってわけがわからないので自分で作ったほうが早いと思いつくりました。

なお、カメラレジスタの設定(一部を抜粋)はTrenz社の設定を参考にして以下のようにしています。

x"0114" & x"01",-- CSI_LANE_MODE = 2-lane
x"0128" & x"00",-- DPHY_CTRL = auto mode
x"012A" & x"13",-- EXCLK_FREQ[15:8]
x"012B" & x"34",-- EXCLK_FREQ[7:0] = 4916 MHz
x"0160" & x"04",-- FRM_LENGTH_A[15:8]
x"0161" & x"60",-- FRM_LENGTH_A[7:0] = 1120
x"0162" & x"0D",-- LINE_LENGTH_A[15:8]
x"0163" & x"78",-- LINE_LENGTH_A[7:0] = 3448
x"0164" & x"01",-- XADD_STA_A[11:8]
x"0165" & x"58",-- XADD_STA_A[7:0] = X top left = 344
x"0166" & x"0B",-- XADD_END_A[11:8]
x"0167" & x"77",-- XADD_END_A[7:0] = X bottom right = 2935
x"0168" & x"01",-- YADD_STA_A[11:8]
x"0169" & x"F0",-- YADD_STA_A[7:0] = Y top left = 496
x"016A" & x"07",-- YADD_END_A[11:8]
x"016B" & x"AF",-- YADD_END_A[7:0] = Y bottom right = 1967
x"016C" & x"05",-- x_output_size[11:8]
x"016D" & x"10",-- x_output_size[7:0] = 1296
x"016E" & x"02",-- y_output_size[11:8]
x"016F" & x"E0",-- y_output_size[7:0] = 736
x"0170" & x"01",-- X_ODD_INC_A 
x"0171" & x"01",-- Y_ODD_INC_A
x"0174" & x"01",-- BINNING_MODE_H_A = x2-binning
x"0175" & x"01",-- BINNING_MODE_V_A = x2-binning
x"0176" & x"01",-- BINNING_CAL_MODE_H_A
x"0177" & x"01",-- BINNING_CAL_MODE_V_A
x"018C" & x"0A",-- CSI_DATA_FORMAT_A[15:8]
x"018D" & x"0A",-- CSI_DATA_FORMAT_A[7:0]

iMX219は本来3296×2512という8MpixelのCMOSイメージセンサなのですが、ビニングといって2つのピクセルをオンチップでまとめる機能があります。それを使うと1920×1080や、1280×720といったハイビジョンサイズの画像をチップ上で作り出してくれるようです。

上の設置絵では画像サイズを1296×736にして(おそらく1280×720で端に8pixelの余白を付けている)いるのですが、XADDとYADDのサイズは2935-244=2591、1967-496=1471で2倍のサイズにして2x2のビニングを有効にして1296×736で出力しています。

今回作ったvideo_bloganaコアは、video dmaのほかロジアナ機能が内蔵されていて波形のパルス長のカウントができるようにしてデバッグに大いに役立ちました。

tvalidが有効になっている期間の長さや、tuser(0)が来る間隔のtlastの回数を数えてみると、確かにtvalidは1296クロック、tlastは736個来ているのがわかります。また水平ラインの周期は約31usであるようです。

レジスタの設定を変えれば画面の解像度を変えることができるはずなので、次はI2CをUSB経由で操作して解像度やデータレートを変えたりできるようにしてみたいと思います。

Spartan-7でUSB-AXI-DDR3に成功。次はカメラだ

昨日、FX2からAXIにつなぐコアを作ったので、AXIの先にMIGを置いてDDR3 SDRAMにつなげてみました。

結果は、なんと一発で成功！

512Mバイトの広大な空間を自由自在にUSBからアクセスできるようになりました。しかも、全くのノーエラー。

次にやることは、RaspberryPiカメラ2をつないで、このDDR3 SDRAMのメモリに画像を書き込んでやること。

USBとDDR3がAXIでつながっているのだから、メモリ上に画像を入れてやればすぐにデジカメアプリが作れるでしょうというわけです。

そこで、以前作ったMIPI CSIの回路をつないでI2C経由で初期化シーケンスを与えてみると、

CP/CN、DP0/DN0、DP1/DN1のラインに何らかのデータが出てくるのが見えました。これはMITOUJTAGを使ってFPGAのピンをバウンダリスキャンして見ています。FPGA内蔵のロジアナではないから10秒くらいの間の出来事が記録されています。

バウンダリスキャンだと100MHzで動く信号は見えないあら、次の波形はFPGAに内蔵ロジアナを仕込んで取りました。

MIPIのデータバスをアナログ値で見ていると毎回少しずつ揺れているし、きっと画像なんでしょうね！

いったいどんな画像なのでしょう。楽しみです。

今日のBlockDesignはこんな感じになりました。

MIPI CSI-2 RX Subsystemという大きなコアはXILINXのIPですが、Vivado 2020.1からは無償で使えるようになりました。

このRX Subsystemが出す信号はいろいろあるのですが、それを右上のvideo-bloganaというコアで解析しています。どういうタイミングで信号が来るのかとかを見るためのコアです。

わかってきたことは、

• rxbyteclkhsは、MIPIから再生されたクロック。使わなくていい。BUFRで出てくる。
• ビデオデータはvideo_outというAXI Streamに全部入っているので、これ以外の出力信号(system_rst_out~frame_rcvd_pulse_outまで全部)は基本的に使わない
• ビデオデータはvideo_aclkに同期して出てくる。今回はMIGが出す83.33MHzを使用している
• dphy_clk_200Mには200MHzを入れること
• video_areset_nとctrl_core_enは一緒にアクティブLのリセット信号につなげばいい。I2Cの初期化が終わったら0→1に上げればよいのだと思われる。

ビデオ信号はAXI Streamで出てきますが、tuser(0)がフレームの先頭、tlastがラインの終わりです。

ラインの先頭やフレームの先頭を示す信号はありません。

フレームやラインの先頭を知るには、AXI Streamのtreadyを常に'0'にしておいて、RX Subsystemがtvalidを0→1に上げたときに先頭であるとすればよいでしょう。カウンタのリセットや出力側のAXIの起動をしてからtreadyを1にすればよいのです。RX Subsystemの中にもFIFOは入っているので、数クロックの遅れは余裕で吸収できます。つまり、tvalidの立ち上がりを使ってフレームやラインの先頭を出せばよいのです。

EZ-USB FX2からAXIにアクセスできるようにした

2年前に作りかけたソースを発掘し、かなり手直しして、ようやくEZ-USB FX2からAXI-4にアクセスできるようになりました。

今日の成果のブロックデザインはこんな感じです。

AXIの先にはSmartConnectがあって、その先にはAXI BRAMがつながっています。

Spartan-7のXC7S50の内蔵BRAMを最大限に使うと256kByteまでのRAMを作ることができます。

USBからAXIを通じてBRAMにアクセスする速度を測ってみるとOUT方向が43MBytes/s、IN方向が26MBytes/sでした。

USB 2.0 HighSpeedとしては妥当な値といえます。

やはり内蔵RAMは小さいですね。VGAサイズの画像すら入りません。

豊かなアプリケーションのためには、どうしてもDDR3 SDRAMを使う必要があります。

いろんなものが壊れて何も進まない時は・・

今日はいろいろな物が壊れまくっています。

開発中のSpartan-7ボードのオンボードスイッチング電源の波形を見て実験していて、あるコンデンサをショートさせたら、突如大電流が流れて壊れました。

貴重なFPGAが壊れてしまったのかと思い、昔作った初期型のSpartan-7ボードで実験するも、こちらも大電流が流れて故障。

結局のところ、新しいSpartan-7ボードは電源ICが壊れただけでFPGAは無事だったのですが、電源ICを取り替えたりするのに非常に時間がかかってしまいました。

Spartan-7ボードの電源ICを交換すると、今度はUSBが接続できない。

今回、USBのコネクタをType-Cにしたのですが、ボス穴をあけるのを忘れてしまっていたため、ボスを切って実装していました。そのためか、コネクタの端子がグラグラしてひび割れして接続不良になったものと思われます。USB Type-Cのコネクタはリフローしないと実装できないので、特電の社内では再実装ができません。

仕方がないので外から見える片側のコネクタだけをはんだ付けしなおして何とか片面だけUSBを安定して使えるようにしました。

せっかくなのでUSB顕微鏡で写真を撮ろうと思いノートPCを起動しようとすると、なぜか起動しない。

充電ケーブルを挿しても充電が始まらない。

NECのLavieでPC-PM750SAGという機種なのですが、NECのサイトを見てもよくわからない。

サイトでAIとチャットしたりしていてようやく回復手順を見つけました。他のPCの「放電」手順で電源スイッチを20秒間押すというのがあったので、これを試してみたら復旧しました。

物が壊れまくって何一つ成果がでないようなときは厄が溜まっているので、明日、浅草にお参りに行くことにします。

HOZANの顕微鏡を試す

HOZANのUSB顕微鏡を買いました。

もともとははんだ付けなどの実装状態を見ることを想定して作られているのだと思いますが、私としてはICのパッケージのマーキングを見て偽物と本物を見分けられないかと思っています。

まず、手近にあったXILINXのCPLD、XC2C256の表面を拡大してみました。黒いパッケージですが拡大していくと溶岩が固まったようなでこぼこした構造が見えてきます。

マーキングの部分はレーザーで掘ってあるのか平らに削られているようです。

CPLD表面の白い四角の部分はレーザーを何度も走査したのでしょう。縦筋が見えています。この縦筋からマーキングの分解能もわかりそうですね。

彫ってある文字をよく見ると、1本の文字が2回の走査で書かれているのではないかという筋が見えます。

マーキング自体は光の反射加減で非常に見づらいのですが、

偏光フィルタを通すと非常に鮮明に見えるようになります。

偏光フィルタでマーキングが鮮明に撮れるというのが今回の最大の収穫でした。

ただ、この顕微鏡は最大倍率に拡大してみてもぼやけていてμmレベルの構造は見えません。画像自体も8x8ピクセルで塊を作っていて、500万画素が活かせている感じではありませんでした。

下の写真は万能基板のランドの表面です。BMPで保存しているのでファイル保存時には圧縮されないはずですが、8x8のブロック構造が見えています。

このUSBカメラのインタフェースはUVC規格だそうなので、自分でプログラムを組んで非圧縮で画像を取り込めば500万画素が活かせるのかもしれません。

下の写真は私が手半田したコネクタの端子です。

拡大率を上げると暗くなってノイズが目立ち始めます。

端子間隔は0.5mmで、配線の幅は0.1mmです。ブリッジしていそうでしていないのはわかります。

光学的分解能は10μmくらいではないかなと思います。

ハイサイドスイッチの実験回路

1つの信号ラインに、1.0Vや、1.2V、1.5V、1.8V、2.5V、3.3V、5Vなど多様な電圧を与えるためのハイサイドスイッチの回路を検討しています。

MOSFETでスイッチするとどうしてもボディーダイオードを通じて漏れてくるので、専用のロードスイッチを使います。候補になっているのは、Vishay社のSiP32408、RenesasのSLG59M1563V、TexasInstruments社のTPS22917LDBVRです。

これらのデバイスは逆流防止機能があって、OFFの放電抵抗がないという特徴があります。

いずれも非常に小さいパッケージなので、万能基板で作る前にExcelで実体配線図を描きました。Excelを方眼紙の状態にするのですが、列の幅を0.96、行の高さを9.6くらいにすると正方形になるので描きやすいでしょう。グリッドに固定するためのボタンをツールバーに出しておくとなお描きやすくなります。

実際に作った回路はこんな感じです。

万能基板の上にカプトンテープを貼って、その上に各種ICをエポキシで固定しています。そこからボンディングワイヤで周囲のパッドへ配線を引き出しています。

あまりやりたくない作業です。

結果はどうかというと、Vishay社のSiP32408とTexasInstruments社のTPS22917LDBVRは期待通り逆電圧を阻止してくれました。

RenesasのSLG59M1563Vは期待した動作をしませんでした。

Sに5Vを加えてDに1.2Vを加えた状態で、ON端子がLの場合はS→Dへの逆流は防止してくれますが、ON端子をHにするとDに5Vが漏れ出てきて、非常に危険です。

データシートを読んでも逆流防止についての詳しい説明は書かれていないので、正しい動作なのかどうかはわかりませんが、ON=Lの場合にしか逆流を防止できないのかもしれません。

SLG59M1563Vのことを調べていたらRenesasRulzに同じような疑問を持った人がいたので、書き込みをしておきました。

https://renesasrulz.com/power-management/f/power-management/28316/slg59m1563v-reverse-blocking

DACボードのLCフィルタ

今回作っているDACボードには出力にLCフィルタが入っています。

回路はこんな感じで、解説記事はこちらです。

要するに5次のチェビシェフフィルタです。0.1dBの低リップル型でキレが悪いので、13pFのコンデンサを追加して70～80MHzあたりにノッチを入れてキレを改善しているというわけです。

その性能を測ってみました。

周波数を少しずつ変えて振幅をオシロで測る・・というのを繰り返すのも面倒なので、DACから疑似乱数を出して、そのスペクトラムをオシロで測ります。

なんということでしょう！透過域が波打っています。

どおりで10MHzくらいの正弦波を作ったときに、設計値よりも大きな電圧がでていたわけだ。

フィルタを50Ωで設計しているのにOPアンプの出力を10Ωくらいの抵抗を介して出していたのがいけなかったのでしょう。

OPアンプの出力に50ΩをつないでからLCフィルタに通すと穏やかになりました。

少し肩が下がってきているのは50Ωの抵抗だと少し大きいのかもしれませんね・・

ちなみに、阻止域に1本スペクトラムが立っているのは、クロックから漏れてくる125MHzです。

どの程度の周波数でカットオフされているのかを見るために、PWM波形を出してみることにします。PWMの比を75:1くらいにするとくし形が見やすくなります。

設計どおり62MHzくらいで急激に減るようになっていました。

ただ、やはり、30MHzあたりからゆっくりと下がっていくのはなんとかしたいですね。

DACのノイズを減らすための長い闘い

DACのノイズを減らすための長い闘いもだんだん勝利が見えてきました。

まず、非常に小さい正弦波を出して(0x1fffと0x2000を繰り返す)、全データバスが激しく同時に遷移する波形を与えます。

そのときに出力のようすはこちら。

XDCファイルにLVCMOSの出力電流の制約を書いて、DACに与えているクロックの電流を減らしてみたのがこちら。

劇的に減りましたね。

クロックはデータが遷移していなくても常に125MHzとか100MHzがDACに与え続けられているので、非常に大きなノイズ源になっているようでした。

次に、周期が異なる2つの正弦波をDACから出力して、クロストークを見ます。

Cosmo-ZのDACから出して、Cosmo-ZのADCでサンプリングしてFFTしてみると、

干渉があるんだかないんだかわからない結果になりました。今、緑のスペクトラムは100kHzで、茶色が約68kHzすが、ここで緑だけを消して見て見ましょう。

100kHzや200kHzのところに何もないので、クロストークが測定できないほど小さいことがわかります。

次に茶色を消して緑のチャネルだけみると、

わずかに、-100dBあたりのところにちょこっとだけいるのが見えます。クロストークは-90dBは達成できているといえます。

これで、「DACのAD9717はIとQチャネルが分離できていないのではないか」という不安は払拭できました。AD9717は2つのチャネルが混ざっているということはなく、7月20日ごろに実験していてうまくいかなかったのはディジタルの遷移が出力に乗ってきているためだったと確信しました。

さて、FPGAにADCやDACをつないだ「RedPitaya」というのがありますが、こちらはどうなっているでしょう。

RedPitayaのヒートシンクを外してみると、FPGAとDACが露出します。

使われているDACはAnalog DeveicesのAD9767で、Cosmo-Z DACで使用しているAD9717とは近い関係にあります。

AD9767も14bitのパラレルバスをDDRでマルチプレクスして14bit 125MHz 2chを実現しているので、条件は同じです。RedPitayaのDACへのデータバスの配線は上の写真のとおりFPGAと直結です。ただし、非常に距離は短くできているようです。

RedPitayaの波形も同じようにノイズが乗っていました。

下の図はRedPitayaで1MHzの方形波を出力したときの出力コネクタを同軸ケーブルでオシロにつないで観測したものです。

矩形波っぽい波形の上に発振するものが見えています。この発振は12～18MHzくらいでした。

 

ですが、たまに125MHzのクロックに起因すると思われるノイズも乗ります。

RedPitayaで100kHzの正弦波を出力してTHDを測ると-55dB～-72dB程度だったので、このノイズの問題をクリアできていないのではないかと思われます。

別々の波形を出しながらひずみ率が-90dBを達成した

今日もCosmo-Zの拡張DACのデバッグを進めています。

いろいろな部品を付けたり外したりしているので基板は汚くなってきていますが、

その分、波形は綺麗になりました。

THDもSINADも90dBを余裕で超えられるようになってきました。

これまで2つのチャネルから別々の波形を出した状態では70dB台だったのが、一気に90dB台までいけました。

何を変えたかというと、まず、THS3491という電流帰還OPアンプをやめたこと。このOPアンプはすぐ発振するし熱いし7V必要だし使いこなすのは無理だ。

それから、自作したSepic-Tuk型のDC-DCをやめて市販のDC-DCモジュールにしたこと。DC-DCのノイズを減らすのって意外と難しく、ひょっとしたらコイルの向きとか磁界の結合とかを考えなければならないのかもしれません。それを極めるには時間がかかりそうなので今回は市販のモジュールに戻りました。

さて、S/Nを悪化させている一番大きな原因はDACのディジタル部から漏れてくるノイズでした。

DACの入力にはFPGA等から信号がパラレル（またはシリアル）で送られてきて、それをGNDでリターンしています。ディジタルの入力ピンには電流は流れないはずですが、ピンには容量があり若干の電流が流れています。

また、DACの入力ピンは解放端とみなせるので、ディジタル側から来たエネルギーはほぼ100%反射して戻りますが、LVCMOSなどのシングルエンドのラインではGNDは信号のリターンとしては不十分なので、ノイズとなって放射されます。

つまり14本とか16本のアンテナが並んでいるようなものなのです。その14本、16本の信号が遷移することでアナログ側にノイズとして乗ってしまい、それが出力にまで乗ってきます。

ただし、このノイズは単純な電流のノイズとして乗るのではなく、空間を伝わっていくのか、もしくはGNDを揺さぶっているので、ローパスフィルタでは落とせません。このノイズがどうやって伝播しているかは後で研究することにしましょう。

同様のことがクロックにも言えていて、DACのクロックのラインにクロックを送るだけで、出力から漏れてきてしまうのが観測できました。

クロックを80MHzで動かしているのに、どうして240MHzくらいのノイズが乗るんだろうと悩んでいたのですが、OPアンプの発振ではなく、データバスが80MHzでパタパタ動いているのが240MHzくらいのノイズになって見ていたのです。

下の図はDACの2つのチャネルからSINとCOSを出力したもので、もともとかなり小さい振幅の正弦波を作っています。

振幅に対して大きなノイズが乗っていますが、これはディジタルから漏れ出てきたノイズによるものです。

こういったディジタルラインからのノイズを劇的に減らす方法があります。

XILINXのFPGAでは、XDCファイルに

set_property IOSTANDARD LVCMOS18 [get_ports {dac1_data_op[*]}]
set_property IOSTANDARD LVCMOS18 [get_ports {dac2_data_op[*]}]
set_property IOSTANDARD LVCMOS18 [get_ports {dac3_data_op[*]}]
set_property IOSTANDARD LVCMOS18 [get_ports {dac4_data_op[*]}]
set_property DRIVE 2 [get_ports {dac1_data_op[*]}]
set_property DRIVE 2 [get_ports {dac2_data_op[*]}]
set_property DRIVE 2 [get_ports {dac3_data_op[*]}]
set_property DRIVE 2 [get_ports {dac4_data_op[*]}]
set_property DRIVE 2 [get_ports {dac_clkin_op[*]}]
set_property DRIVE 2 [get_ports {dac_clkio_op[*]}]

のように、電流を制限するための記述を書けばいいのです。

上の例ではI/Oの電流を2mAに制限しています。FPGAの出力電流が制限されたことで空間に放出されるノイズが減ったかGNDが揺さぶられるのが減ったかして、THDが10～20dBは改善しました。

2つのCHに別々の波形を出した状態でTHD -80dB以下を達成することができました。

パラレル入力だといくら減らしても限界はあります。LVDS入力が使えるDACがあれば使いたいものです。

拡張ADCと拡張DAC

今日は、たまりにたまった注文を出荷した後、Cosmo-Zの拡張ADCと拡張DACの実験を行っています。

まずは、拡張ADCボード。

 

クロストークやひずみを減らすため、GNDのパターンを工夫したはずなのですが・・・全然性能は向上しませんでした。

やはり、保護用ダイオードによる歪は避けられないのか！？

次は拡張DACボード。

Cosmo-Z Miniと比べてノイズが大きいなと思っていたのですが、根底にあるのはこのノイズ。

Cosmo-Z本体からのDC-DCのノイズを拾ってしまっているようでした。

ぐぬぬ。

ハイサイドスイッチ

IC真贋判定装置では、検査対象ICに電源を与える部分でハイサイドのスイッチを使います。

PNPトランジスタで作るか、P-ch MOSFETで作るか、アナログスイッチで、専用のICで作るか、いろいろな選択肢があります。

P-MOSで作る場合、電源は下の図のような回路で与えます。

上の図ではPIN1～PIN3までしか書いてありませんが、最大のBGAの場合、これが1500個くらい並ぶわけです。

ピンにぶらさがったP-MOSFETのどれか1つをONにすることで1.0V、1.8V、3.3Vのいずれかの電源を与えることができます。

しかし、P-MOSだとFETの中に寄生ダイオードが入っているので、うまくいきません。

電位差が0.8VくらいあるとOFFしているFETの寄生ダイオードから回り込んできて低い電圧の電源電圧が上昇してしまいます。

これは危険です。

こういう回路を作るための専用のICがあるかというと、あるんですね。

DigikeyでSiP32408とか、TPS22916Bとか、SLG59M1551Vなんていうのが見つかりました。

「PMIC - 配電スイッチ、負荷ドライバ」

というカテゴリで1mm角以下のICがいっぱいでてきます。

こんな小さいのに2Aとかをスイッチできて、しかも1個100円以下。

1500ピンのBGAをコントロールするには6000個必要なのですが、6000個買っても20万円未満です。

これで超クロスポイントマトリックスが作れると喜んでいたのですが、こういった電源ICには逆電流保護の機能があるものと、ないものがあるようでした。

下の図はSLG59M1551Vの内部等価回路です。

あー、だめですね。

これだと逆流してしまいます。

しかも、スイッチがOFFになったときに放電用のFETがONしてしまう構造なので、使用しない電源ピンがGNDに200Ωくらいの抵抗で接続されてしまうことになります。

これでは私の目的には使えません。

TPS22917というのもあって、これは逆流防止をしてくれて放電Rがないのですが、逆電流を500mA流さないと防止回路がONしないそうです。

DigikeyでこういったICを探したところ、「逆流防止機能あり」で「放電なし」で「1.0Vから使える」という至れり尽くせりのICを3～4種類見つけました。

逆電流素子回路がそれぞれ独自の実装がされているみたいで、少しずつ求めているものとは異なっていました。データシートに乗っていない部分が実際にどうなのかわからないので、Digikeyで購入して実験してみることにします。

半導体真贋判定装置の構造

半導体真贋判定装置では、1つ1つのピンをGNDやVCCに接続することができるのですが、VCCは少なくとも3種類必要であり、非常に密度の高い基板になってしまいます。

また極小のFETを並べる構造のため、基板の歩留まりも悪くなってしまうことが想定されます。

そこで、数十チャネルの規模の電源をモジュールを作り、

これを下の図のようにベースボードに敷き詰める構造にすることにしました。

この敷き詰め方だと密度が全然足りなくて、これを8階建ての構造にします。

4×4×8で128枚の小さなモジュール基板で電源を与える構造になります。

ただし、これもスマートではないので、下の図のように立体的に重ねるのも素敵かなと思います。

ノートパソコンの中のDIMMモジュールのように三次元的な構造になります。