製品情報>ZYNQ搭載 ADCボード「Cosmo-Z」>開発日記>2016年7月

2016年7月

光ガイド

2016/7/27

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

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

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

まず四角錐のアクリル。

Optguide1

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

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

Optguide2

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

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

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

Optguide3

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

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

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

Optguide4

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

Optguide5

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

 

Cosmo-ZのVivado Block Design

2016/7/21

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

Cosmoz_vivado_bd

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

Cosmoz_vivado_bd2


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

Cosmoz_top1

 

Cosmo-ZのDACとADC

2016/7/20

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

/cosmoz.elf dacfile ファイル名

 

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

Cosmozdacadc

 

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

Cosmozdacadc1

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

2016/7/19

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

 

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

 

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

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

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

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

Cosmoz_vivado_x

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

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

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

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

Cosmoz_top

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

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

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

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

Cosmoz_vivado_top


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

 

Cosmo-Zの開発にGitを導入

2016/7/18

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

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

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

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

Git_2

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

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

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

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

 

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

2016/7/12

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

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

Mppc4

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

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

Mppc_big

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

Mppc4hour

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

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

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

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

 

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

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

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

 

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

2016/7/11

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

Mppc


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

Mppc0


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

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

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

Mppc1

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

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

Mppc2

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

Mppc3

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

オシロで見てみると、

Mppc4

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

 

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

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

Mppc5

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

Mppc6

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

 

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

Mppc7

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

 

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

Mppc8

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

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

2016/7/9

長い間がんばってきたハードウェア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まで切れ目なくできる計算になります。

 

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

2016/7/6

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

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

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

Bitrev2

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

FFTの基本のキです。

 

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

 

Bitrev4_2

驚きの交換法則。

つまり、

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であれば、こうなります。

Bitrev8

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本のスペクトラムが立ちました。

Fft_1

 

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

Fft_2

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

あとすこし。

 

ビットリバースのバグ?

2016/7/6

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

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

Fft_error

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

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

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

Fft_error2

 

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

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

2016/7/5

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

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

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

Fifo_error

この波形を見ると、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回路ができました。

Hvfft_tim1

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

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

Hvfft_tim2

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

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

Hvfft_tim3

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

 

Cosmo-ZのDACの動作

2016/7/4

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

Cosmoz_dac

これを組み立てると・・

Cosmoz_dac2

こうなります。

Cosmoz_dac3

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

Cosmoz_dac4

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

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

Cosmoz_dac5

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

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

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

Cosmoz_dac7

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

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

Cosmoz_dac8

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

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

 

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

2016/7/2

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

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

Fft0701_1


中心にある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結果をメインメモリに格納します。

sun

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

Fft_timing

  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ステージをなくせるかもしれません。

sun

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

Fft_comp

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

 


© 2017 TokushuDenshiKairo Inc. All rights reserved