なひたふJTAG日記

FPGAでロックインアンプを作っているのですが、同じ振幅でも位相を変えていくと、計算される振幅が10uVくらい変わるという現象が起きています。

問題を簡単にするために、C言語で同じ処理を書いてCPUで実行してみることにしました。

const int PERIOD = 1280;
const int MAXITER = 1000;
const double A = 1;
for (double phase = 0; phase < 360; phase += 1)
{
    double sum_sin = 0;
    double sum_cos = 0; // ①
    for (int iter = 0; iter < MAXITER; iter++)
    {
        for (int p = 0; p < PERIOD; p++)
        {
            double sig = (A * sin(((double)p / PERIOD + phase / 360) * 2 * PI)) * 32768; // ②
            double S = sin((double)p / PERIOD * 2 * PI) * 32768;
            double C = cos((double)p / PERIOD * 2 * PI) * 32768; // ③
            sum_sin += ((long long)S * sig / 32768);
            sum_cos += ((long long)C * sig / 32768);
        }
    }
    double X = sum_sin / 32768. / PERIOD / MAXITER * 2;
    double Y = sum_cos / 32768. / PERIOD / MAXITER * 2;
    printf("%f\t", phase);
    printf("%f\t", (sqrt(X * X + Y * Y) - A) * 1000);
}

上のプログラムは正弦波と正弦波を掛け合わせて、一周期(PERIOD)の間積分するという計算をITER回繰り返すものです。それをphase=0~359まで繰り返します。

①②③の行にあるdoubleや、long longという型が結果にどのような影響を出すかを調べます。

まず、すべてがdouble型で計算した場合の結果です。見た感じでは、誤差はほぼゼロです。

拡大すると演算の誤差は概ね10-9レベルであることがわかります。

次に③の部分をlongにした場合。つまり、SIN、COSを固定小数点32bit型にした場合です。

-20uVの誤差が出ていますが、周期的構造は見当たりません。

次に②のsigをlong型にした場合。周期的な構造が見えてきました。

①のsum用の変数をlong longにした場合。

逆に、①のsumはlong long型だけれども、SIN、COSとsigをdoubleにした場合。

やはり、周期的な誤差が出てきます。

①と③、つまりsumとSIN,COSはdoubleで、sigはlongの場合。

様子が変わってきますが、より細かい周期のギザギザとなります。

最後は①②③のすべてをlong longにした場合ですが、32768倍ではなく2147483648倍して、32bitの固定小数点として計算してみます。すると、

ほぼ、ゼロでした。

つまり、固定小数点で演算するとしても32bit×32bit=64bitくらいの精度で計算すれば誤差は出てこないと思われます。

Cosmo-Zのロックインアンプの演算結果を波形としてリアルタイムに描画できるようにしてみました。

下の画面は、100kHzで約100mVppの正弦波をCosmo-Zに入れて、その振幅をロックインで計測し、計測結果をグラフ化したものです。

積算回数が1,10,100,1000,10000回と大きくなるにつれて計測結果の振れ幅が小さくなっていくことがわかります。

積算回数を10000回、50000回に設定すると、測定された振幅はほぼ10uVの範囲に収まります。

この結果を表示させたいがために、Cosmo-Zのアプリに10uV/divという電圧レンジを新設しました。普通のオシロにはこんなレンジはありません。

波形を見ると振幅は10uVくらいの範囲では揺れているのですが、その振幅の不確定さの原因がファンクションジェネレータ自体にあるのか、Cosmo-ZのADCにあるのか、演算のアルゴリズムにあるのかは現時点ではわかりません。

次に、KeysightのファンクションジェネレータをSCPIで自動操作して、位相を1度ずつ動かしていったときの波形を示します。

黄色の線で振幅を、灰色の線で位相を表示していて1°=1mVですが、位相が階段状に変化していくようすが見えています。

次の図は0°から360°まで変化させたときのようすですが、位相に合わせて振幅(黄色)が10uVほど山なりになっているように見えます。

正弦波の振幅を0.5mVに変えてやってみても、やはり位相による振幅推定の誤差が10uVくらいあるように見えます。

一方、振幅を1mV～500mVまで階段状に増やしていった場合でも、振幅の測定に与える影響はない(0.001°以下)でした。まぁ、あまりにも振幅が小さいときに誤差出るのは仕方がありません。

位相が電圧の測定に影響を与える原因を考えなければなりません。

特電の決算期は4月末です。3月末は例年案件が込み合っているので避けたいというのもあるし、GWを利用して部品の棚卸をするのでちょうどよいというのもあります。

さて、2021年の業績をまとめてみると赤字でした。原因としては、半導体不足でドイツ製のFPGAボードが製造されず入荷できなかったというのが大きいです。自社製品部門はそこそこの実績だったのですが、海外輸入部門にものすごい注文残高が残っていて、これがすべて正常に出荷されていれば黒字だったと悔やまれるのですが仕方がないですね。

半導体不足は2023年まで続くようなので、今までのように自社でFPGAボードを作ったり、海外のFPGAボードを輸入して販売したりといったビジネスは2022年度だけでなく2023年度も厳しいことが予想されます。現に、来年度の生産計画を立てて、2023年末ごろに入るFPGAの発注をしているくらいです。

そこで、特電も業務の大きな転換をしようと思います。計画を立てて成功しそうなことだけをやるというのは基本的にはできません。当たり馬券だけを買うことができるかという問題と一緒です。

うまくいくプランもあれば失敗するプランもあって、実際に少しやってみないとわからないのが現実です。ですから、半導体不足の中でもできそうなことをいろいろピックアップして、それを手あたり次第やってみることにします。

① MITOUJTAGをC#で作り直す

② 同人誌出版

③ Artix版の高速ADCボード拡張

④ Artix-7ボードのMIPI CSI拡張

⑤ Spartan-7ボードの改版

⑥ JTAGユーチューブチャンネル計画を実行に移す

⑦ JTAGセミナー開催

⑧ 半導体検査装置と検査サービス

⑨ 展示会出展

⑩ OpenOCDの研究とMITOUJTAGとの接続

⑪ Cosmo-Z Miniの改版

このようなことを計画しています。

特に力を入れたいのは同人誌の出版です。私は7年間ほどZYNQを使ったシステムを構築しててきましたが、その際に得られたノウハウをブログに書き溜めてきました。それらを一度整理して、出版したいと思います。

200ページくらいの本を100冊刷ったら印刷代は18万円くらいで、そこからは冊数と印刷代は比例するようなので、だいたい200冊くらい作って2000円~2500円くらいで、技術書典などで販売しようと思っています。

そもそも同人誌を作るのは売上目的ではなく、本を出すということで新たな人とのつながりができるからです。今の閉塞した環境を打破するのは、新たな人とのつながりを作らなければなりません。

2冊目の同人誌はFPGAでの物理計測について書きたいと思います。

昨日の実験で、12bit ADCでもLPFを通せば16bit ADCと同じような精度が出ることが確かめられました。それならば、16bit ADCは不要なのかということを考えてみたいと思います。

まず、KeysightのファンクションジェネレータEDU33212Aの信号を12bit ADCと16bit ADCで比較してみます。

下の図は12bit ADC + CICフィルタで取ったスペクトラです。

次の図は16bit ADC + CICフィルタ

ほとんど差はありません。

500~1500kHzのあたりに-100dBクラスの高調波が何本も見えます。

次の図はVP7722Aの波形を12bit ADCで取ったものです。

次の図はVP7722Aの波形を16bit ADCで取ったものです。

基本的にどの波形もほとんど同じですが、EDU33212Aよりも高調波は少なくなっています。ただし、1300kHzや5000kHz付近に寄生発振かノイズか何かをひろっているのが見えます。

12bit ADCと16bit ADCのスペクトラムにほとんど差はないのですが、横に並べて比べてみると、16bit ADCのほうが5~10dBほどノイズフロアが低いことがわかります。

LPFを通してしまうと12bit ADCも16bit ADCもほとんど差はなく、高調波の差はない(歪率への影響はない)ことがわかります。その差はノイズフロアがわずかに減る程度であることがわかりました。LPFによって差の4bitに相当する信号が作り出されて滑らかになるためでしょう。

ただ、このことが言えるのは100MHzでサンプリングした信号を音声帯域～1MHzくらいまでしか使わない場合であるということを付け加えておきます。数10nsのサンプリング間隔でデータを利用したい場合は、やはり、16bit ADCを使わなければなりません。

まとめると、

• 音声帯域で使うならば12bit ADC+LPFと16bit ADC+LPFの差はわずかである
• 数十MHzのサンプリングデータをすべて使うなら16bit ADCを使う必要がある

ということです。

ADコンバータのビット数が多ければ多いほど性能は高いと思われています。そのため、ADコンバータはビット数が多いほうが高価です。

それでは、ビット数の少ないADコンバータが出してきた荒い量子化のデータをディジタルフィルタを通すことで精度を上げることはできるのでしょうか？

実際にやってみました。

まず、XILINXのFPGAの中に入れるディジタルフィルタとしてCICフィルタというのを使います。フィルタとしてのキレは緩いのですが構造が簡単で足し算と引き算と遅延素子だけでできるからです。

このフィルタでは、入力4クロックに対して1回の割合で出力が更新されます。Fixed Or Initial Rateというところの設定が4になっているからです。

まず、このADCに固定電圧を入れてホワイトノイズのヒストグラムを見てみます。

12bitのADCでは粗くしか電圧を見れていませんが、フィルタを通したほうは中間の電圧がうまく再現されています。DC~低周波においてはビット精度は向上したと言えるでしょう。

次に、VP7722Aという正弦波発振器で作った100kHzの正弦波をADCでサンプリングしてみます。

下の図の茶色い波形は生の波形、フィルタを通すと赤色の波形になります。

フィルタを通したほうがカクカクしているのですが、それは4回に1回しか出力されないためです。

FFTで高調波を確認してみます。下の図は100kHz 7dBの正弦波を入力した場合のものです。このLPFでは、1MHz以下の減衰はないので赤と茶色の線はほぼ重なっています。

100kHzの信号に対して200kHzのところに高調波があります。もともとの正弦波が綺麗すぎるのと、このADCのひずみが少ないので基本波に対して-90dB以下でしか見えていません。CICフィルタを入れても歪みが改善されるわけではなく、悪くなるわけでもありません。

INLやDNLが悪化するとひずみ率の増加として見えてきますので、CICフィルタではINLやDNLが悪化することもなく、改善されることもないことがわかります。

また、12bit ADCの量子化の間にある電圧の推定も、非常に滑らかに妥当に行われていることがわかります。もし、1LSBの間の中間電圧の推定で偏りがあれば、歪率の悪化として見えてくるからです。

CICフィルタを通した場合と通さない場合で、0~40MHzまでのノイズを見てみました。

4MHz以上のノイズは綺麗に削減されているのですが、カクカクしていることに起因して、折り返し周波数あたりに新たなノイズが出てきているのが見えています。

これは良くないので改善が必要です。

具体的には、CICフィルタを2つ使いました。100MHzの信号を第一のCICフィルタで25MHz相当にデシメーションし、第二のCICフィルタで100MHzにインタポレーションしました。これで、100MHzのカクカクしない波形が得られます。

こうして得られたベストなFFTを下の図に示します。

今までは-100dBのところにノイズフロアがあったのですが、2段CICフィルタを入れることでノイズが抑圧され、-120~-140dBまでノイズフロアが下がりました。それによって、いままでノイズに隠れていた高調波が見えるようになってきました。

20kHzの基本波に対して、二次高調波が-90dBのあたりに見えていますが、これは発振器が出している高調波であるように見えます。

いくつかのファンクションジェネレータで試してみたり、一つのファンクションジェネレータでも出力レベルを変えてみると、高調波の出方が変わってくるのが見えます。

おそらく、ファンクションジェネレータの生の特性が見えているのでしょう。

結論として、CICフィルタ(LPF)により、

• ADCの量子化された間の電圧を推定することは可能（低周波領域でのビット数は増大）
• 高周波成分のノイズ削減が可能
• 歪や高調波は改善しない

ということがわかりました。

ZYNQの管理者パネル「ZYNQ Admin Panel」をgithubで公開しました。

この管理者パネルでは、CPUの負荷やディスクの容量、メモリの残量などを確認することができるほか、boot.binの書き換えも可能です。

インストールは簡単で/var/www配下の任意のディレクトリでgit cloneするだけです。このWebアプリは、このフォルダ内で閉じているので、ZYNQ内に作りこんだ既存のWebサイトに影響は与えません。

再起動ができるようにしたりboot.binを書き換えるにはroot権限の問題で、少しだけ設定が必要です。

Apacheライセンスなので、どうぞ気軽にご利用ください。

https://github.com/tokuden/zynq-admin

ZYNQの起動ファイル「boot.bin」は、bootgenというコマンドを使って、BitStreamとfsbl.elfとu-boot.elfを固めて作ります。

通常のZYNQ開発の手順では、FPGAの論理合成が終わったらホストPC上でbootgenコマンドを実行してBitStreamからboot.binを作り、SCPなどの手段を使ってZYNQのシステムに転送して、boot.binを置き換えて新しいデザインで動かすことになります。

バッチファイルにしておけばboot.binを作る毎回のコマンド操作はしなくてもよくなりますが、それでも

• bootgenでbit→boot.binを作る
• ZYNQ Linuxのシステムに転送する
• 転送した先のLinuxでboot.binを置き換える
• rebootする

という4つの手順を踏むことになり、面倒です。

できれば出来上がったBitStreamをZYNQのLinuxのシステムに送れば自動的にboot.binを作って新しいデザインで再起動してほしいものです。

そこで、ZYNQ Linux上でbootgenを動かす方法を調べました。

bootgenのソースコード自体はXilinxのgithubからダウンロードすることができます。

https://github.com/Xilinx/bootgen

これはARMのLinux用にコンパイルして動くと書かれていますので、やってみました。

ZYNQのLinux上で、

git clone https://github.com/Xilinx/bootgen

でダウンロードします。OpenSSLのライブラリが必要と書かれているので、次に、

sudo apt install libssl-dev

でlibssl-devをインストールします。

ライブラリとヘッダファイルがインストールされたディレクトリを調べて、makeのコマンドは以下のようにします。

make "LIBS=/usr/lib/arm-linux-gnueabihf/libssl.a /usr/lib/arm-linux-gnueabihf/libcrypto.a -ldl -lpthread" "INCLUDE_USER=-I/usr/include/openssl -I/usr/include/arm-linux-gnueabihf/openssl"

さて、これでビルドができるかと思ったのですが、

authkeys.cpp: In member function 'uint8_t Key::ParseOpenSSLKey(FILE*)':
authkeys.cpp:198:32: error: 'RSA_get0_n' was not declared in this scope
         keySzRd = BN_num_bytes(RSA_get0_n(rsaInst.rsa));
                                ^
authkeys.cpp:198:32: note: suggested alternative: 'RSA_get0_key'
authkeys.cpp:207:19: error: 'RSA_get0_d' was not declared in this scope
         memcpy(D, RSA_get0_d(rsaInst.rsa)->d, keySize);
                   ^~~~~~~~~~
authkeys.cpp:207:19: note: suggested alternative: 'RSA_get0_key'
         memcpy(D, RSA_get0_d(rsaInst.rsa)->d, keySize);
・・・

というエラーが大量に出て、ビルドは失敗！！

エラーメッセージによればRSA_get0_dという関数がないようです。

調べてみると、RSA_get0_dはOpenSSLの1.1.1から使用できるようになった関数で、Ubuntu18のARM版ではaptでインストールされるlibssl-devのバージョンは1.1.0gどまりのようです。

仕方がないので、OpenSSLから1.1.1nのソースコードをダウンロードして解凍してビルドします。

やり方は、

wget https://www.openssl.org/source/openssl-1.1.1n.tar.gz
tar -xvf openssl-1.1.1n.tar.gz
./config --openssldir=/home/cosmoz/openssl
make

configureのオプション --openssldir= で指定しているのはインストール先のディレクトリです。

cosmoz@cosmoz:~/openssl/openssl-1.1.1n$ ./config --openssldir=/home/cosmoz/openssl
Operating system: armv7l-whatever-linux2
Configuring OpenSSL version 1.1.1n (0x101010efL) for linux-armv4
Using os-specific seed configuration
Creating configdata.pm
Creating Makefile
**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL file first)         ***
***                                                                ***
**********************************************************************

何も苦労することなく、configureとmakeは終了しました。

makeは40分程度かかりました。　

次にbootgenのビルドです。makeのオプションにはopensslをインストールしたディレクトリを指定します。

make "LIBS=/home/cosmoz/openssl/openssl-1.1.1n/libssl.a /home/cosmoz/openssl/openssl-1.1.1n/libcrypto.a -ldl -lpthread" "INCLUDE_USER=-I/home/cosmoz/openssl/openssl-1.1.1n/include/"

いけー！

無事に通りました！bootgenのビルドも結構時間がかかりました。

bootgenが出来上がったら、とりあえず実行してみましょう。

なんかいい感じで動いています。

そうしたら、bifファイルを作り、

the_ROM_image:
{
	[bootloader]./FSBL.elf
	./cosmoz_main_wrapper.bit
	./u-boot.elf
}

fsbl.elfとu-boot.elfをZYNQのシステム上にコピーしておいて、bootgenを実行します。

ちゃんとbootgenが動いてboot.binを生成してくれました。

Windows上のbootgenで作ったboot.binとdiffやcmpで比べてみても、1バイトの違いもなく同じものが出来ていました。

上の手順で生成したbootgenをダウロードできるようにしておきます。自分でビルドするのが面倒だという方はご利用ください。

ダウンロード - bootgen

FPGAで作るロックインアンプで、内部での演算が溢れないように積和計算の和の部分を48bitに拡張してみました。これによって周期が長い場合でもオーバーフローはしなくなり、最大で65536回の積算ができるようになりました。

下の図のようなノイズまみれの約1mVppの波形を測っても

5万回積算すれば0.4809~0.4812Vの間をいったりきたりして、計測値はだいたい3uVの範囲で落ち着くようになりました。

それで昨日の実験の続きをすることにしました。

ファンクションジェネレータが出す正弦波の位相を1度ずつずらしていって、どのくらいの精度で位相を読み取れるかという検証を行います。

結論からいうと昨日の結果と同じで、振幅が大きいほうが誤差が少なく、振幅が1mVの時は最大で6°もの誤差が出てしまうという結果でした。この誤差はファンクションジェネレータで1mVの正弦波を作って測っても、ファンクションジェネレータで1Vの正弦波を作ってアッテネータで1000分の1に落としても、振幅が1mVならば誤差は6°という決まった値となっていました。

なぜこうなるのか謎です。

ロックインアンプでは、被測定信号の振幅と位相を測ることができます。

今日は、Keysightの任意波形発生器で作った信号をFPGAで作ったロックインアンプで測り、FPGAで作ったロックインアンプの「位相測定性能」を評価しようとしています。

Keysightの任意波形発生器はSCPIコマンドの SOUR2:PHASE <deg> で正弦波の位相を変えることができます。Cosmo-ZはZYNQのLinuxで動く計測器なので、LinuxからSCPIコマンドを発行してKeysightの計測器を操作しつつ計測するというプログラムを作って測りました。

その結果です。

出力する正弦波の位相を0度から360度までずらしたときに、Cosmo-Zで測った位相は当然ながらのこぎり波状になります。

この波形がy=xからどれだけずれているかを示すと、

まぁ、このように正弦波の形になるわけです。

ファンクションジェネレータが出した波形の位相と、測定された波形の位相の差は多くとも0.04度程度であるということがわかったので、めっちゃ優秀だと言えます。

なぜ正弦波になるのかというと、ファンクションジェネレータの波形とCosmo-Zのクロックは同期していないので端っこのデータがどっちへ行くかとかで決まるのではないかと思いますが、絶対誤差が0.04度であれば大きな問題ではありません。

で、いろいろとパラメータを変えてみました。

次はファンクションジェネレータの出す振幅を半分にしてみたとき。

振幅を10mVにしたとき。

振幅を1mVにしたとき。

振幅が10分の1になると、位相誤差が10倍に増えていくのが分かります。

いろいろ試してみたところ周波数や積算回数には関係なく、ファンクションジェネレータの出す振幅だけが位相の誤差に関係しているようです。さて、一体なぜこういう現象が起きるのでしょう。

ADCで量子化する際の誤差なのか、Cosmo-Zの中での計算のアルゴリズムの問題なのか、atanの誤算の問題なのか、それともKeysightのファンクションジェネレータの問題なのか、まだわかりません。

IC真贋判定装置の概要設計を見直しました。

最初は、様々なICに対応するために、たくさんのピンをジャンパワイヤーでポチポチとつないで、電圧の確認はLEDでしようと考えていましたが、それだとやっぱりダサすぎるので、アナログスイッチを使うことにしました。

原理は下の図のとおりです。

原理を説明します。

まず、アナログスイッチをICのピン数×6個並べておきます。検査対象ICのピンにつながっているのが横のライン、電源レールにつながっているのが縦のラインで、その交点にアナログスイッチがあります。

例えば、検査対象ICの120番ピンと150番ピンがGNDだとすると、その120と150に対応するアナログスイッチをONにして、その端子をGNDに接続します。このようにして、任意のピン番号の端子にGND、1.0V、1.2V、1.8V、3.3Vを与えられるようにします。モード設定的な信号もこのアナログスイッチから供給できるでしょう。

アナログスイッチの制御信号はピンごとに6本なので、内層を2つ使えば余裕で引き出し可能です。つまり、この回路は6層基板で製造可能というわけです。

一番左側にTSTという縦のラインがありますが、このラインはDACやADCがつながった特別なラインで、電圧を測ったり、任意の電圧を与えることができます。

用途としては、

• 検査前に各ピンの電圧を確認して、電源が間違っていないかどうかのチェック
• 検査対象ICが出力H/Lレベルの読み取り
• 検査対象ICの出力するドライブ電流の測定
• 電圧-電流特性のテスト(ICが壊れていてGNDにショートしていないかなど)

に使います。

アナログスイッチは探せば、1mm角くらいの小さいのが見つかるので、

こういうのを1440個並べればQFP240ピン用の万能検査装置が、3000個並べればBGA484用の万能検査装置が作れそうです。

Cosmo-ZのロックインアンプをGUIで操作できるような機能を作っています。

下の図では、青い線に約80mVppの正弦波が加わっています。

この振幅を推定するわけですが、GUI画面で数字が出るようにしました。

今まではTeraTermでログインしなければならなかったので、大きな進歩です。

半導体不足が続く中で、どうしても流通在庫を使わなければならない人たちもいます。流通在庫の不安を解消するために、JTAGバウンダリスキャンを使ったFPGAの真贋判定装置を作ろうと考えていて、本日から具体的な設計を始めました。

下の図は装置のイメージ図です。最初のターゲットデバイスはQFP240です。

中心にあるのはゼロプレッシャーのソケットで、

ピンがスプリング構造になっているので、機械的なダメージを最小限にして検査できるというわけです。

このソケットが乗った基板を「プローブ基板」と呼ぶことにして、それとは別に、下の段にテスト信号を発生させる「ベース基板」を置きます。プローブ基板を変えることで、QFP240、QFP208、QFP144、QFP100、BGA324、BGA484、BGA676あたりに対応させたいと思います。

この基板をタカチのこのケースに納めようと思っています。

さて、たくさん並んだピンヘッダとLEDは何かということを説明するために、1つ1つのピンが電気的にどのようになっているかを下の図に示します。

左にあるのがテスト信号発生IC（これをどうやって作るかは検討中）で、右にあるのがゼロプレッシャーソケットに装着された検査対象IC(FPGA)です。

検査の原理は、「1本1本のI/Oをテスト信号発生ICと接続して、検査対象IC(FPGA)の端子をバウンダリスキャンで操作して、I/Oが生きているかどうかを確かめる」というものですが、FPGAの端子には、GNDやVCCなどI/O以外の様々な端子があるので、それらの端子をどう作るかという問題があります。

今回は迅速かつ低コストで作りたいので、極めて簡略化した作りになりますが、ピンヘッダとジャンパピンでテスト信号発生ICと検査対象ICを電気的につないだり切ったりすることができるようにします。

VCCは、ピンヘッダのピンからブレッドボードのジャンパ線みたいなのを使って電源レールに接続するようにします。

では、LEDは何かというと、I/O端子に直接つないだLEDは2V程度で点灯しはじめて3.3VくらいでMAXに光るでしょう。一方、トランジスタを介してつないだLEDは1VくらいでMAXに光るでしょう。このLEDの光をみて、電圧をなんとなく目視で把握できるようにします。

この考えでどこまで大きなICに対応できそうか考えてみると、BGA676までは対応できそうです。

BGA676は26×26なので、ピンヘッダは26×26×3本になります。

さすがにピンヘッダがここまでたくさん並ぶと基板の強度的にも良くなさそうですし、配線も大変そうな感じなので、別の方法を考えるかもしれません。

1.8V対応のSPI ROMで、8ピンSOICパッケージで、128Mbitくらいの容量がもので、かつ、現時点で入手可能なものとしてCypressのS25FS128SAGMFI101というのがあるのですが、これはXILINX FPGAのコンフィギュレーションに使うことができないとされています。

似たような型番のS25FL128Sというのは3.3Vですがコンフィグに使うことができて、Vivadoも対応しています。

S25FS128SAGMFI101がなぜ使えないかというと、S25FL128とS25FS128Sのコマンド体系に微妙な違いがあるからです。

7シリーズのFPGAはSPI ROMからコンフィグしようとしたとき、最初にFast Readというコマンド(0x0B)を発行してビットストリームの先頭を読み出します。そして、データバス幅がx2やx4になっていると、デュアルまたはクアッド読み出しのコマンドを発行して、2ビット幅や4ビット幅でコンフィギュレーションしようとします。

なお、デュアル読み出しのコマンドは3Bまたは3C、クアッド読み出しのコマンドは6Bまたは6Cです。※128bit以上だとアドレスが3バイトになるのでコマンド3Cが使われる。それ以下は3B

S25FL128L(3.3Vの動作するほうのROM)では、3B 3Cまたは6B 6Cのコマンドは用意されているのですが、

S25FS(1.8Vの対応していないほうのROM)では、なんと、3B 3Cのコマンドがないのです。

これが原因で、S25FSをコンフィグROMとして使うことができないのです。

XILINX FPGAが対応しているROMのファミリの一覧はAnswer 65463に書かれているのですが、

https://support.xilinx.com/s/article/65463?language=ja

ここにS25FSには3B 3Cコマンドがないことは書かれていました。

それなら、SPIのビット幅をx2ではなく、x1にすれば使えるかというと、使えました。

そもそもSPI ROMのビット幅をx2やx4にするには、VivadoのXDCファイルに

set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]

という行を書くのですが、ここを2にするとDualになって、4にするとQuadになります。

デフォルトは1なので、x1サイズのSPI ROMを使うようなBitStreamを作ればS25FSからでもFPGAはコンフィグはできます。ただし遅くなりますし、Vivadoが対応していないので自分でツールを作らなければならなくなります。

x1幅にすればコンフィグROMとして使えないことはありませんが、S25FSはセクタの構成がややこしいので、ページイレースやセクタイレースはうまくいきませんでした。書き込みの前に全消去をしたほうがいいです。

それからS25FLとIDCODEが同じなのも憎いです。必要なコマンドが入っていないのに、IDCODEを同じにするな(# ﾟДﾟ)と思います。

さて、現時点でDigikeyで購入可能な1.8V QSPI ROMで、FPGAのコンフィグに使えそうなものはないかというと、MX25U12835FM2I-10Gがいいかもしれません。なぜならば、 D:\Xilinx\Vivado\2020.1\data\xicom\xicom_cfgmem_part_table.csv に記載があって、Vivadoからでも使えそうな感じだからです。しかしながら「新しい設計には推奨できません 」と書かれているので、すぐになくなって長納期化する可能性もあります。

Kintex-7やArtix-7のボードでBank0を1.8Vにすると、入手可能なROMの選択肢がほとんどないのが厳しいですね。

AD9633(AD9253,AD9653)の入力電圧範囲は対GNDで-0.3~+2.0Vですが、前段のOPアンプがフルスイングすると2Vを超えてしまいます。

そこで、Cosmo-Zでは下の図のように保護ダイオードを入れているのですが、この保護ダイオードが歪やクロストークの原因となっていることが、昨日の実験で確かめられました。

この保護ダイオードを取ってしまうと特性は飛躍的に改善されますが、ADCの入力にどのくらいの電圧が加わってしまうのかを調べてみました。

Cosmo-Zの基板としての入力電圧範囲は±0.5Vですが、その2倍になる1.数V以上を加えるとADCに加わる電圧は2Vを超えるようになります。

下の図は保護ダイオードがONして、-0.3V~+2Vの範囲でクリップしているようすを示しています。

保護ダイオードを取り外してみると、-0.5V~+2.3V程度が加わるようになります。

この+2.3Vという電圧は、ADCのフロントエンドに使っているレールツーレールの完全差動アンプの電源電圧でクリップしているのかもしれません。-0.5Vというのも、完全差動アンプの反対側が2.3Vになる電圧です。

AD9633自体には入力電圧をクリップするようなダイオードは本当に入っていない可能性が高いです。

保護ダイオードを外してしまうと、保護してくれるのは前段のOPアンプの電源電圧だけということになります。

逆にいえば、Cosmo-Zではこの保護ダイオードがちゃんと仕事しているので安全に使えるということも確認できました。

Cosmo-Zのクロストークを改善する方法を模索しました。

分かっていることは、クロストークの大きさが周波数に依存しないということです。つまりLやCの結合ではないので、保護用ダイオードが一番疑わしいと思われるわけです。

AD9633のアナログ入力の絶対最大定格は-0.3V~2.0Vなので、この入力に過大な電圧が加わらないよう、ダイオードで保護しています。

ADCの入力の+と-の電圧がGND以下、VCC以上になったときにダイオードで逃がすというものです。

ところが、最もクロストークの強いCH5とCH6は以下のようなパターンになっていました。

このダイオードを片側だけでも外してみると、見事にクロストークが減ったのです。

今まで-70dBくらいで見えていたクロストークが-100dBまで減りました。

ダイオードに加わっていた逆電圧が10nAくらい漏れてGNDを揺さぶり、隣のチャネルを揺さぶっていたと思われます。

ただし、CH3とCH4のクロストークを減らすにはこれだけではダメなようでした。

Cosmo-Zのアナログ入力には保護ダイオードだけではなく、RCフィルタが入っています。（厳密にはフィルタというよりも、ADCの入力Cを充電するためのコンデンサ）

差動線間の1000pFは通常は入れてありませんが、GNDにつながっている33pFのコンデンサは入っています。この33pFのコンデンサを外して線間につなぐと、CH3とCH4のクロストークも見事に消えたのです。

CH3→CH4へのクロストークを-100dBまで減らすことができました。

クロストークの原因は、保護ダイオードに漏れて流れる電流が隣のチャネルに干渉していたことと、GNDに逃しているRCフィルタの電流が隣のチャネルに干渉していたということでした。

保護ダイオードを外してよいのかという問題があるので、GNDや電源パターンを工夫して電流の経路を調整し、部品を外さずにクロストークを減らせないかということを次のバージョンで研究することになるでしょう。

Cosmo-Zは8ch 12~16bit 125MHzのADCボードですが、

チャネル間のクロストークがどのくらいあるのか調べてみました。

次の図は、Cosmo-ZのCH1にほぼフルスケールの100kHzの正弦波を入れて、CH1とCH2に出てくる波形をFFTしてみたものです。CH1に入れた信号強度が-0dBに対して、CH2に-90dB程度出てきているのが分かります。

全部のチャネルがこのくらいのクロストークであれば問題ないのですが、CH5とCH6のクロストークが毎回大きいことがいままで気になっていました。CH5→CH6へのクロストークが-70dBほどあります。

このような感じで、あるチャネルに入れた正弦波が他のチャネルにどのくらい漏れてくるかを調べてみたところ、次の表のようになりました。

この表を見ると、CH5-CH6間が特に大きく、CH7-CH8間、CH5-CH4間がその次に大きいことが分かります。

CH5-CH6がいつも大きいので、当初はADCの中で結合しているのだろうと思っていたのですが、AD9633のクロストークはデータシート上は-89dB(25℃では-95dB)なので、基板上でクロストークしているのではないかと考えるようになってきました。また、CH5とCH4間でわずかではあるのですがクロストークが観測された(CH4とCH5は別のADC)ので、基板上でクロストークしている可能性が強く疑われるようになりました。

また、AD9633のデータシートではクロストークを改善するために、CH1-CH2間、CH3-CH4間の差動配線間にGNDのビアを打てと書いてありました。これは、CH1-CH2、CH3-CH4間の配線が隣り合っているからなのですが、今から基板を変更するわけにはいかないので、この配線間にGNDに接続した細い配線を置いてみましたが特に変わりはありませんでした。

さて、このクロストークの特性について詳しく調べてみると、漏れてくる信号は2倍高調波・3倍高調波も見えているということと、周波数に依存しないということがわかってきました。つまり、100kHzでのクロストークも10MHzでのクロストークも、1kHzのクロストークも、-70dBなら-70dBでほとんど変わらないのです。

ということは、寄生コンデンサ的な電界の結合や、配線が平行するなどのコイル的な磁界的な結合ではない、と推測されるわけです。

Cosmo-Z MiniはAnalog DevicesのAD9717というDACが搭載されていて、2chのアナログ信号を出力することができます。

このDACを使って5Hz~100kHzまでの範囲で様々な周波数で正弦波を出力し、ゲインやひずみ率の変化があるかどうかを調べてみました。

測定に使った機械はVP7722Aというオーディオアナライザというものです。普段は正弦波発生器として使っていましたが、外から信号を入れてひずみ率やTHD等を測ることもできます。

5Hzのときの値はあまり信用できませんが、結果は以下のようになりました。

この測定器の表示を読んだ感じではゲインは0.2dBほど変動していました。THDは測定に時間がかかるので何とも言えませんが、概ね-70dB以下で、周波数が高くなると減少傾向にあるといえます。

なお、Cosmo-Z MiniのDAC出力にLCフィルタを入れても変化はありませんでした。10MHz以上の高い周波数の正弦波を作るときにはLCフィルタが効いてきますが、低い周波数の信号を作る場合には効果は全くないようです。

また、同じ周波数でKeysightのEDU33212Aで測ったものと、VP1122Aの内蔵発振器で出力した正弦波を比べてみました。

ゲインについては、Cosmo-Z MiniとEDU33212Aが同じような傾向を示しているので、このわずかな変動は計測する際のVP1122Aの測定側の特性なのだろうと思われます。

THDについては、EDU33212Aのほうが全体的にCosmo-Zよりも10dBほど良い値を出しています。VP1122Aに内蔵された正弦波発振器はは-110dBという驚異的な値を出しています。

Cosmo-Z Miniでは、周波数が上がるとなぜTHDが下がるのかは謎です。高い周波数のほうが変化が激しいのでTHDも増えると思ったのですが・・・。FPGAで正弦波を作るためにまずランプ信号で位相を作って、その位相をもとにCORDICで正弦波を作っているのですが、そのランプ信号の分解能が低いのかもしれません。ほかにも、位相がπを超えて-πに戻るところの接続に問題があるのかもしれません。

DDSのアルゴリズムを変えれば周波数の変動を抑えられるかもしれません。しかし、AD9717のデータシートを見ると-84dBくらいが限度なようなので、現時点でも十分な性能といえるのかもしれません。

ドイツから輸入したFPGAボードの代金はユーロ建てで払うのですが、ユーロの相場が激しく変動しているので、ユーロが安いときに買って蓄えておきたいものです。

そう思いたって先日、三菱UFJのBizStationに外貨預金のメニューを追加したのですが、ユーロ建ての外貨預金口座を持っていないと何も使えないということなので、外貨預金の口座を作ってきました。

外貨預金の通帳は即日発行してくれましたが、BizStationにつなぐのは郵送になるみたいでした。

グラフを描けるJavascriptのライブラリを探しているのですが、まともに株価のチャート(ローソク足)を描けるのはなさそうです。

chart.jsかc3.jsがよさそうだと思ったので試してみました。

chart.jsは、chartjs-chart-financial.jsを使えばローソク足が描けるそうなのですが、日付のデータをLuxonで与えなければならないようで、私のChromeではLuxonのところでエラーが出ます。

c3.jsはd3.jsをグラフに特化したものらしいのですが、これもちゃんと動かない。

私のJavaScriptのスキルが足りないだけなのかもしれません。

積み立てNISAを始めたことから株の勉強をすることにしました。

株の初心者向けの解説ではチャートがどうのというのが出てきますが、「チャートを読む」というのは読む人の主観が入り込みます。上がってほしいと思う人には株価が上がるサインを見つけてしまうし、下がってほしいと思う人には日々の値動きを株価が下がるサインだと思いたいからそう見えてくるのではないかと思うわけです。

人間的な感情が入ると絶対に勝てないのだろうなと思い、機械的に売ったり買ったりするような統計学的なやり方はないのかと思い調べてみました。

そういうのを「テクニカル解析」というようです。

その手の本を２、３冊買って読んでみました。

なお、テクニカル解析の対義語としてファンダメンタルズというのがあって、ファンダメンタルズは財務諸表などから分析して現在の株価が割高か割安かを判断して投資するやり方で、数字と計算式で判断するものであれば信頼できると思います。

そういった、数学的で統計学的で人間の判断の入らないような売り方買い方ならばいいのだろうと思います。

逆に、「上がるチャートのサインだ」とか「出来高が増えてきた」みたいな読む人によって主観が入り込めるやつは×です。

テクニカル解析で計算できる指標はMACDとかバンドとか様々な手法を全部合わせると20種類以上ありそうです。まず、銘柄ごとに１年分くらいのデータを集め、5~10種類くらいの指標を試してみて、銘柄ごとに有力そうな指標の候補を選びます。そして、指標のパラメータ(例えば平均日数)を変えながらバックテストを行い、最適な値を探ります。

変動する値の背後に隠れるアルゴリズムを推定し、最も良い成績が出せるようなパラメータを見つけるというやり方は、ノイズに埋もれた信号を計測するのと似ているのではないかと思われる次第です。

2022年のエイプリルフール企画として、「永田町バトル2000」をリリースしました。

http://www.nagata2000.jp/game.html

「野党が不信任案を提出したのに乗じて与党内から造反者が出てしまった！！あなたは幹事長になって、支持率低迷にあえぐ内閣を支えつつ造反者を叩くという政治ゲームです。」

マスコミ出演すると支持率は少し回復しますが、首相が出てきて失言するとかえって支持率が減ってしまいます。

どうぞお楽しみください。

http://www.nagata2000.jp/game.html

P.S.

4月5日時点で、およそ5400人の方にプレイしてもらった計算になります