光ガイド

前回、プラスチックシンチレータとMPCCで試したところでは、光量が足りない感じでした。

それもそのはず。60mm×60mmのシンチレータに、3mm×3mmのMPCCを貼り付けただけだから、光の大部分は漏れていってしまっているはず。

そこで、光ガイドを作って、シンチレータから出た光を効率的にMPCCに集めることを検討しました。

まず四角錐のアクリル。

ラミエルみたいなやつです。

これをシンチレータの上に乗せて、さきっぽにMPCCを付けます。

寸法を間違えて、シンチレータが60mm×60mmなのにラミエルの底面は50mm×50mmで作ってしまいました。

しかし、このラミエル型のアクリルは特注で作ってもらうものなので、なんと3万円もします。シンチレータより高価になってしまいました。

そこで、シンチレータの横から光を取り出せばいいじゃんという発想で、

こういう三角形の先を切ったものも作りました。これなら千数百円で作れます。

長いのと短いのがあるのは、どちらが良い結果を出すかを比較するためです。

シンチレータにオプティカルグリスで接合して、三角の先にMPCCを付ける予定です。

確かに全反射しているのですが、でも上から見ると向こう側が透けてみえるので、集光効果はあまり期待できないかもしれません。

プラスチックシンチレータがうっすら紫色に光ってみえます。

箱根に行ってきました。

今日からロマンスカーにのって箱根へ1泊の家族旅行です。

普段はなかなか時間がとれないので、こういう時こそと、SurfaceにVivado HLをいれてFPGAマガジンも持ってきました。今度こそは覚えるぞ～

ロマンスカーの車内でパソコンを広げたら、隣にいた息子（小６）もラズベリーパイ（液晶ディスプレイ組み込み済み）とフルキーボード持ってきてた！！

げげっ。

小田急フリーwifiにつながったとか言って喜んでいます。

その後、24日(日)は箱根神社→箱根関所→遊覧船→バスで宿→温泉

25日(月)はロープウェイで大涌谷→代替バス輸送→ケーブルカー→登山鉄道というルートで一周して帰ってきました。

大涌谷は26日から規制が解除されるそうだったのですが、私たちが行ったのは一日早かったので、駅から出ることはできませんでした。ロープウェイの大涌谷駅では、ホームで記念撮影して、すぐに反対方向に乗って姥子まで戻り、そこから代替バスに乗って早雲山に行くというコースでした。

駅舎から出られない（改札や土産物屋にも行けない）ので残念ではありますが、これはこれで貴重な体験です。

バスで姥子から早雲山に行く途中、木が広範囲に立ち枯れしているところがありました。火山ガスとかでこんなふうになってしまうのでしょうかね。

ひさびさにAD360を製造＆出荷

特電にはAD360という製品があります。20ch、18bitのAD変換ボードという意味です。

DC-DCモジュールが乗っているのは、±12Vを供給するため。最初のお客様は±12Vを基板外部から供給していたので、外付けになっている

超レアなこの製品ですが、最近なぜか2社のお客様からほぼ同時に注文がありましたので久々に製造しました。

信号がないときのAD変換結果、つまり無信号時のノイズは、

でした。18bitのA/D変換結果が±3くらいの範囲に収まっているのですから、かなり良い結果です。

歪率は

と-90dBでした。入力を開放せずに50Ωで終端すると-110dBくらいまで下がります。この歪は発振器に由来するものと思われます。

全チャネルで歪率-90dB以下。ゲイン誤差100ppm以下。オフセット0.3mV以下という良い結果でした。1年以上ぶりに製造したのに、ちゃんと動いたので、ほっとしました。

徹夜で計測していたら、もう5時近くになっていました。窓の外を見ると燃えるような赤い色になっていて、何事かと思ったら朝日でした。

測定には時間がかかります。

Cosmo-ZのVivado Block Design

Cosmo-ZのVivado Block Design化を進めています。

ぱこっと開くと、こんなのが出てきるので眺めて楽しんでいます。

目標はこういう感じのものなので、まだまだ先は長い気がします。

Cosmo-ZのDACとADC

開発中の「Cosmo-Z DAC拡張ボード」から、任意の波形を出力できるようにしました。

/cosmoz.elf dacfile ファイル名

と打つとファイルから読み込んだ波形を出力します。

こんな複雑な波形（周期がスイープするsin波）も簡単に出せます。

Cosmo-ZのVivado化デザインをはじめました

Cosmo-Zの設計を本格的にVivado化することを検討しています。

えっ！？いまさら！？？と思うかもしれません。

はい、そうです。今のCosmo-Zの設計はISEで、VHDLで作られています。

だから、ISEのソースをお客様に渡しても、どこをどう修正すれば自分の研究に適合できるかが非常にわかりづらいと思います。

そこで、Vivado化して、AXIとかステートマシンとかを全部隠してしまって、お客様（＝研究者）が簡単に使えるようIPブロックを積み重ねた設計に変えていこうというわけです。

でも、ISEで作ったプロジェクトをそのままVivadoに取り込んでも、こうなってしまい、

何がなんだかさっぱりわかりません。

お客様（＝研究者）にしてみれば、Interconnectとか、クロック生成器とかUSBモジュールとかは本質的ではないものです。

そこで、いままで作ってきたCosmo-Zのデザインをいったん破棄して、トップダウンで再度設計しなおすことにしました。

Cosmo-Zの機能をすごくわかりやすく図にすると、こんな感じです。

Cosmo-Zのお客様は「物理や電気の様々な研究室」なので、波形をどう取り込むかは研究によってまちまちです。特に、波形の加工（フィルタを入れたり、相関の計算をしたり、ロックインアンプを入れたりなど）やトリガに関してはほんとうにみんな違います。

また、メモリ内に蓄えられたデータを数値計算（たとえばベイズ推定したりとか、行列計算したりとか）するような場合のロジックをVivado HLやSDSoCで書いて、それをCosmo-Zのデザインに容易に組み込めるようにしなければならないと考えています。

そこで、上のような構造のデザインに変えていこうと思うわけです。

このようなポンチ絵を描いたら、特電の優秀なアルバイトさんやインターンさんがVivadoのブロックデザインにしてくれました。

これをgitで管理して複数の人で同時に開発を進められるようにしようと思っています。

Cosmo-Zの開発にGitを導入

今更ですが、Cosmo-Zの開発にGitを導入しようとしています。

いままではXILINXのISEプロジェクトのフォルダ(200～300MBくらい)を、できれば毎日、そうでなくてもマイルストーンのたびに全部保存するようにしていたのですが、さすがに大変になってきました。

subversionを導入しようとしたのですが、RAIDのドライブをNFSでマウントするとうまくいかななったり、亀が嫌なので、ナウなヤングにバカウケのgitを使ってみることにしました。

Cosmo-Zの開発のブランチをこんな感じでまとめてみました。

ブランチが目に見えて嬉しいのですが、結局、マージするところは手作業になるので、ちょっとげんなりです。

デザインを細かく細かく分けて、ファイルをいっぱい作るのがgitをうまく使うコツかなと思えてきました。

将来的には、特電のGitサーバを立ち上げて、お客様にCloneしてもらうようにしたいと思います。

このISE版のCosmo-ZのプロジェクトはGitでも管理するけど、しばらくは毎日のフォルダを全保存しておいて、df.exeで差分を見るという方法をまだまだ併用することになると思います。

おれデバ第３話を更新

回路マンガ「おれデバ」 第３話を更新しまいた。

アナログ対決もいよいよ佳境です。

回路マンガ「おれデバ」は、↓こちらで読めます。

http://www.tokudenkairo.co.jp/manga/

MPPCとプラスチックシンチレータで遊んでます(2)

MPPCからの信号をCosmo-Zに入れてみました。

こんな感じで波形は取れています。

パルスの大きさが、ある大きさの整数倍になっているて、段々になっているのがわかります。

たまに大きなパルスが入ります。

横軸にパルスの大きさ、縦軸に頻度を取ってヒストグラムを表示させてみると、こうなります。

これは4時間計測したときのヒストグラムです。

左の方がギザギザしていますが、フォトン1つ分の高さ(1p.e.)、フォトン2つ分の高さ(2p.e.)・・のところにピークができていて、7p.e.(255番くらいのところ)まで見えているためです。

255番より小さなものはダークカウントによるものなので、ディスクリで切ってしまうべきでしょう。2p.e.のところが1Gカウントくらいしています。

それより右側(255以上)になると、発生頻度は指数関数的に減少していきますが、最後に2040くらいの高さのところにもピークがあります。一番右のピークは、振り切れるほど大きな発光があったことを示しています。

しかし、プラシンとフォトマルで測ったときのようなピークはありませんでした。

50mm×50mm×10mmのシンチを使っているので、全エネルギーを落としておらず、しかも、発光が足りず、その上、うまく光をMPPCに導けていないのでしょう。

結論を言うと、煎餅くらいの大きさのプラスチックシンチレータの横にMPPCを貼り付けただけでは、入射した粒子のエネルギーは測れないということがわかりました。

MPPCとプラスチックシンチレータで遊んでます(1)

昨年度に買い込んでいたプラスチックシンチレータとMPPCをいよいよ使ってみたくなりました。

MPPCというのは、小さなフォトダイオードが寄せ集まったアレイです。1つ1つのフォトダイオードは100万倍くらいの増幅率を持っていて、フォトンのある/なしで、一定量の信号を出します。1つ1つの小さなフォトダイオードは「あり」か「なし」の二値しか出しませんが、1つのチップ上にたくさんのダイオードが集まっているので、信号を出したダイオードの数で元の光の強さが大きさがわかるという、アナログのようなデジタルのような素晴らしいデバイスです。

光電子増倍管と比べて、小型で、割れにくく、高電圧が60V程度でよく、地場の影響を受けないというメリットがあります。

なひたふが購入したMPPCは浜松フォトニクスのS13360-3050CSというものですが、初めて扱うので、最初はHVとアンプをセットにしたモジュールを買いました。

50mm×50mm×10mmのプラスチックシンチレータの横に、MPPCのモジュールを貼り付けます。あとで取り外せるよう、カプトンテープで軽く止めておきます。

そして、これを遮光のための箱の中に入れます。

アルミ等でしっかり作ってもいいのですが、まずは、ダンボールの適当な箱に「遮光シート」を貼り付けて、その中にシンチレータとMPPCモジュールを入れました。

そして、さらにもう一回箱の中に入れます。

光学用の遮光シートで二重に包まれているので、これで十分な遮光ができます。

オシロで見てみると、

ものすごい勢いで何かの信号が出ていました！

「フォトマルで作った検出器よりも信号がたくさん出ている！MPPCスゲー」と喜んだのもつかの間。これは「ダークカウント」という偽の信号でした。MPPCはどうしてもダークカウントや、アフターパルス、クロストークといった偽の信号が出てしまいます。

データシートによれば500kcps～1500kcpsということなので、かなりの数のダークカウントが見えているのも納得できます。10μ秒に5～15回くらいのダークカウントが出ていることになります。

ダークカウントは量子的な理由で出ているので、フォトン1個分の大きさが多いのですが、2個や3個の高さのものもあります。

このMPPCモジュールでは、1p.e.=17mVのようです。1p.e.、2.p.e.と段々になっているのが見えます。たまに幅が広いやつがいるのですが、複数のダークカウントがたまたま重なっているのではないかと思います。

さて、オシロで見ていると、たまに1400mVくらいの信号も来ます。

フォトン100個分の高さの信号です。こういう大きいやつはきっと宇宙線や、コンクリート内のカリウムなどの放射線由来なのしょう。

シンチレータを外してもダークカウントは大量に見えますが、それほど大きいパルスはなくなります。最大でも7p.e.くらいまでになります。

次回は、この信号をマルチチャネルアナライザに入れてみたいと思います。

ハードウェアFFT回路がようやく動いた

長い間がんばってきたハードウェアFFT回路がようやく動きました。

まずは、この結果を見てください。

信号発生器(Agilent E4432B)を用いて1～40MHzの正弦波を生成し、Cosmo-ZでキャプチャしてハードウェアFFTしたした際の結果です。

基本波に対してスプリアスが2倍、3倍の速度で動いていくのが見えます。

次の図は、信号発生器からCDMA信号(いわゆる昔の携帯電話)を出した生の波形です。

電圧の振幅は1V程度ありますが、FFTしてみると-70dBしかないので、スペクトラムが拡散されていることが窺われます。

このFFT IPコアは、32768ポイントのFFTを、最短51μ秒で実行します。Radix-8、周波数間引き、改良型FFTアルゴリズムを採用しています。

FPGAのリソースは、BRAM36Kを96個、DSP48Eを216個使用します。Cosmo-Zに8chのキャプチャ回路など諸々一式を入れた状態でのリソースの使用率を示します。

Slice Logic Utilization	Used	Available	Utilization
Number of Slice Registers	15,302	15,720	9%
Number of Slice LUTs	11,431	78,600	14%
Number of occupied Slices	4,874	19,650	24%
Number of RAMB36E1/FIFO36E1s	140	265	52%
Number of RAMB18E1/FIFO18E1s	82	530	15%
Number of DSP48E1s	224	400	56%

このように、FPGAに入れても圧迫しない、コンパクトな設計になっています。

1回の32768ポイントFFTを51μ秒で実行できるので、連続した時系列データをFFTした場合、最高80MHzまで切れ目なくできる計算になります。

回路マンガ「おれデバ」第3話を更新

特電ではアナログ回路設計の面白さを味わっていただくため、回路マンガ「おれデバ」というものを描いています。

今日、第3話を更新しました。一挙に7ページ追加です。

回路マンガ「おれデバ ～俺のデバッグがこんなに簡単なわけがない～」は、こちらのページから読めます。

http://www.tokudenkairo.co.jp/manga/

お楽しみに！

Radix-4とRadix-8 FFTのビットリバース

FFTの結果が正しくならない原因がわかりました。

Radix-4とRadix-8 FFTのビットリバースは、Radix-2のものとは違うのです。

普通のFFT、つまりRadix-2のFFTでのビットリバースは誰でも知っているとおりこうでした。

つまり、B'00000000、B'00000001、B'00000010・・がB'00000000、B'10000000、B'01000000になるというわけです。

FFTの基本のキです。

Radix-4になると、ビットリバースはこうなります。

驚きの交換法則。

つまり、

00000000→00000000
00000001→01000000
00000010→10000000
00000011→11000000
00000100→00010000
00000101→01010000
・・・
11111101→01111111
11111110→10111111
11111111→11111111

となります。Radix-2では2ビットずつリバースするわけですね。

だから、Radix-8では3ビットずつリバースします。今作っている32768ポイントのFFTであれば、こうなります。

0x0000→0x0000 B'000000000000000
0x0001→0x1000 B'001000000000000
0x0002→0x2000 B'010000000000000
0x0003→0x3000 B'011000000000000
0x0004→0x4000 B'100000000000000
0x0005→0x5000 B'101000000000000
0x0006→0x6000 B'110000000000000
0x0007→0x7000 B'111000000000000
0x0008→0x0200 B'000001000000000
0x0009→0x1200 B'001001000000000
0x000a→0x2200 B'010001000000000
0x000b→0x3200 B'011001000000000
0x000c→0x4200 B'100001000000000
0x000d→0x5200 B'101001000000000
0x000e→0x6200 B'110001000000000
0x000f→0x7200 B'111001000000000
0x0010→0x0400 B'000010000000000
0x0011→0x1400 B'001010000000000
0x0012→0x2400 B'010010000000000
0x0013→0x3400 B'011010000000000
・・・

と変化します。

昨日のスペクトラムが二進数的に変な具合だった原因もわかりました。

これでFFTの結果を見てみます。

まずは3MHzの正弦波を入れたとき。ちゃんと1本のスペクトラムが立ちました。

ADCが12bitなのに計算が16bitだったので、16倍してみましたところ、にぎやかなスペクトラムになって、高調波がいっぱいでました。

どうやらADCの結果は符号なし二進数だったのに、FFTの計算は符号付二進数なので、歪になってしまったのでしょう。しかし、スペクトラムはすべて等間隔にでているのでFFTの計算自体はあっていそうです。

あとすこし。

ビットリバースのバグ？

ハードウェアFFT回路が出来たので、今日はそれをパソコンに転送してグラフで表示するソフトを作っています。

しかし、結果は惨憺たるものでした。

単一の正弦波を入れているのに、これはないでしょう。

なんでこんな滅茶苦茶なスペクトラムなのか。ギザギザすぎです。

周波数によっては1本の線だけになる場合もあるし、こんな二進数的な形になることもある。

1本の線だけになる場合があるということは、FFTの計算は合っていると考えてよいでしょう。だとすると、原因はビットリバース回路にあると思われます。

CoreGen FIFOのリセットは非同期？

連日の徹夜デバッグの末、ようやくFFT回路が出来てきました。

デバッグしていてハマったのが、XILINXのCoreGeneratorで作ったFIFOにデータを溜めていくと、なぜか8192を超えたところで急にリセットがかかってしまうという問題でした。

CoreGenのFIFOはリセットがかかるとEMPTYとFULLが同時に立つので、すぐにわかります。

この波形を見ると、FULLとEMPTYが同時に立って、RDCOUNTが0になっているので、どうしてもリセットとしか思えない挙動でした。FIFOがいっぱいになったときのバグかとも思ったのですが、FIFOの深さを2倍にしても結果は同じ。しかし、FIFOのRST信号をFPGA内蔵ロジアナで見ても、特にアサートはされていない。

いろいろ苦労しましたが、RST信号をFFに通したら直りました。

原因は完全には究明していないのですが、おそらくCoreGen FIFOのRST入力は非同期入力だからなのだろうと思います。

wf_reset <= '1' when (rd_state = "000") and (vfft_start_i = '1') else '0';

という式でFIFOのリセットを作っていたので、rd_stateの動作、あるいはvfft_start_iの動作によっては非常に短いヒゲが出て、それが原因でwf_resetが'1'になってしまい、FIFOがリセットされたものではないかと考えられます。

そう考えると、

• ISIMのシミュレーションでは期待したとおりに動く
• 深さを2倍にしても解決しない
• ロジアナではヒゲが見られない
• FFに通したら正常に動作するようになった

という実験結果とも一致します。

そんな苦労をしながら、ようやくハードウェアFFT回路ができました。

このような構成になっています。

メモリの読み出しや、書き戻しのタイミングをオシロで見てみると、

のようになっていて、期待したとおり、1chあたりの32768ポイントFFTが約80μ秒かかっていて、それを8ch分繰り返しています。

連続して動作させると、このように切れ目なく動きます。

ようやくFFT回路が動くようになってきました。

Cosmo-ZのDACの動作

Cosmo-ZにDAC出力ボードを装着して、信号が出るかどうか測ってみます。

これを組み立てると・・

こうなります。

DACの出力をオシロにつないで測ってみました。波形は／＼_／＼_／＼_というのを繰り返し出しています。

ちゃんと出ているようですが、頂上の近くでヒゲが見えます。

拡大してみると、やっぱりヒゲがあります。

うーん、なぜでしょう。ビットが同時に変化しているのでしょうか。クロックとデータの位相を調整しても消えません。

また、オシロで測っているため、ノイズが乗って線が太くなってしまっています。

そこで短いSMAケーブルでCosmo-ZのADCに入れて自分自身でサンプリングしてみました。

オシロで見るよりも綺麗な波形です。

平らになっている部分（DACやOPアンプが飽和しているのではなく、わざと固定値を出している）を拡大しても、±1LSB(244μV)しか揺らいでいません。

つまり、DACボードのノイズは極めて少ないといえるでしょう。

とりあえず動いてよかった。

FFT回路が実機で動いたようだ

ようやくZYNQに作りこんでいた「Radix-8、周波数間引き、改良型アルゴリズム」の超高速FFT回路が動きました。

今、作っている回路は、このような構成になりました。

中心にあるHyperFFTエンジンは、216個の乗算器を持っていて、演算メモリとしてBlockRAMを64個使います。

BitReverseメモリは、周波数間引きでなので計算結果がビットリバースしているので、それを元の順序に戻すためのメモリです。

例えば、アドレス00000001を10000000から読み出し、アドレス10100000を00000101から読み出すような動作をします。ハードウェア的にはアドレス線をひっくりかえせばよいだけなのですが、意外とアクセス時間がかかってしまいます。

書き込みは256ビット単位(8ワードまとめて)なので16384ポイント/8ワード/250MHz=8.2μ秒で終わるのですが、読み出しが32bit単位なので66μ秒もかかってしまいます。

FFT自体が80μ秒で終わるのですが、それに近い時間をビットリバースで使ってしまうことになります。ビットリバースの効率よいアルゴリズムがあれば知りたいです。

その後ろにあるAXI HPポートは64ビットのバス幅でDMA転送して、FFT結果をメインメモリに格納します。

全体的なタイミングはこうなります。

1. AXIバスからデータを読み出してくる。32768ポイントのデータの読み出しに32.768μ秒かかる。
2. 読み出したデータは入力バッファに蓄えられる。そのバッファ内のデータはFFTマシンのLOADステートで演算メモリに取り込まれる。LOADステートは16.384μ秒かかる。
3. FFTマシンは演算を実行する。その時間は81.92μ秒である。最後のループ5では計算結果をBITREVメモリに書きだす。32768ポイントのFFTの結果は、前半の16384ポイントだけが必要である。
4. BITREVメモリに書き込まれたデータは65.536μ秒かけて読み出され、ほとんど遅延なくAXIバスを通じてメインメモリにライトバックされる。

上のステップ1のデータの準備と、ステップ4のBITREVメモリの読み出しは、FFT演算器とは独立しているので、次のデータの準備や、前のデータの転送と同時に実行できるので、98μ秒で連続してFFTを行うことができます。

頑張ればループ5での演算メモリをロックしなければ、LOADステージをなくせるかもしれません。

サンプルデータを与えてFFTしてみて、メモリダンプしてみたところ、先日のVHDLのシミュレーションで出力した結果と完全に一致しました。

ついに、実機で計算を間違わずにFFTができたと言えるでしょう。

おれデバ 第３話を公開スタートしました

回路マンガ「おれデバ  ～俺のデバッグがこんなに簡単なわけがない～」の第３話がスタートしました。

今回はアナログ回路の設計のお話です。

まだ最初の5ページしかできていませんが、これから毎週4ページくらいのペースでどんどん描いていくのでお楽しみに！

今回はどんな展開になるのでしょうか！？

実は、描いているのは私(なひたふ)ではなくスタッフの者なのですが、私があらすじを書いたテキストファイルを送ると、私の頭の中にあるイメージと寸分違わないマンガに仕上げてくれるのです。ほとんど会話もせずに、「できました」とだけ言って、完全なものに仕上げてくれるとても不思議な人です。

「おれデバ」はこちらのページで読むことができます。

http://www.tokudenkairo.co.jp/manga/