- 追加された行はこの色です。
- 削除された行はこの色です。
#freeze
#author("2024-03-30T11:43:42+00:00","","")
* Event Rejection and Time Window on AMT-VME [#xa8b5302]
#ref(Parameters_Related_Event_Matching_s.png,center);
#br
CENTER:[[イベント・マッチングに関するパラメータ>http://lambda.phys.tohoku.ac.jp/~kaneta/pukiwiki/index.php?plugin=attach&pcmd=open&file=Parameters_Related_Event_Matching.png&refer=AMT-VME%2FEvent_Rejection_and_Time_Window_on_AMT-VME]]
AMT chip の中では、三つのカウンターがあります。
+ coarse counter
+ bunch counter
+ reject counter
一つ目は、ヒットの時刻に対応するもの。
二つ目は、AMT chip のトリガーの時刻に対応するもの。
三つ目は、過去のイベントを捨てるために使用するものです。
この三つのカウンターには、カウンターのスタート時刻を後ろにずらすオフセットが存在しています。
上の図は AMT chip のマニュアルから引用したものです。
bunch counter と reject counter はそれぞれ、図にあるようなオフセットを持って chip 内で回っています。
時間幅は Clock 40 MHz と同じ 25 ns で、カウンターの大きさは 12 bit (0 - 4096) です。
もともと想定されているのは LHC の ATLAS 実験です。
コライダー実験では、二つのビーム・バンチが交差する時刻が加速器から実験室に送られています。
AMT chip では、この bunch time を イベント・マッチングを行うトリガー・タイミングと仮定しているようです。
意味のある物理現象はバンチ・クロッシングの後に起きます。
トリガーシグナルが AMT chip に入った時点で、イベント・マッチングが行われます。
マッチングを行う領域を決めているのが window のパラメータです。
bunch counter から見て、search_window の範囲をしらべ、matching_window の範囲にあれば Read-out FIFO に送られます。
Trigger time より過去に入っていた、ヒット情報を捨てるためにあるのが、reject counter です。
L1 buffer にあるヒットが持つ時刻が reject counter を超えていると、そのヒット情報は L1 buffer から捨てられ、Read-out FIFO には送られません。
上の図で、下側左にあるのが DSP プログラム内でどのような値を設定しているのリストです。
DSP プログラムは、一番最初に変数に初期値を与えています。
そのあと、ps_mode() という関数（パラメータ･セット･モード）の中でVME経由で指定したパラメータを見て、一部の値を変えています。
オリジナルのプログラムで変更出来るのは、AMT-VME マニュアルにある ''Time Range Count'' だけです。
この値は、DSPプログラム中で uiTime_r_c というローカル変数に代入され、counter offset や window の値を変えるのに用いられています。
図の左下のリストは、DSPプログラム中で行われている演算。
右したのものは、NKS2 実験で設定している Time Range Count = 0x25 とした場合に、具体的にどのような値になっているかのリストです。
これを見ると、reject_count_offset と bunch_count_offset が 4095 (0xFFF) 近くの大きな値になっていることが分かります。
実際のイベント・マッチングのプロセスを考えると、この値はマイナスの値であると考えるほうが自然です。
以下に 三つのカウンターの相対的な位置を示します。
#ref(Implementation_on_AMT-VME_s.png,center);
#br
CENTER:[[AMT-VMEボード上でのイベント・マッチングの動作>http://lambda.phys.tohoku.ac.jp/~kaneta/pukiwiki/index.php?plugin=attach&pcmd=open&file=Implementation_on_AMT-VME.png&refer=AMT-VME%2FEvent_Rejection_and_Time_Window_on_AMT-VME]]
コモン・ストップ・モードの場合、トリガーはヒットより後の時刻に AMT chip に入りますので、bunch counter と reject counter は、ATLASの場合と異なり''前''にずれていなければいけません。
offset がプラスの場合に後ろにずれるので、マイナスの値にする必要があります。
それでは、コモン・ストップの場合にトリガー、ヒット、リジェクトのタイミングの相関はどうなるでしょうか。
それを示したのが上の図の下の部分です。
トリガーが入った時刻に対して、bunch counter のカウントは、4 + uiTime_r_c + 1 のカウントだけ時間軸上の左側を示しています（紫の点線）。
ここから、右側に向かって、search_window の領域のヒットを検索し、matching_window に入ったヒットだけを L1 buffer から取り出します。
一方、reject counter が示しているカウントは、トリガーが入った時刻から左に 8 + uiTime_r_c + 1 の場所にあたります。
個々より過去の AMT0, AMT1, AMT2 の三つのチップに入ったヒット情報は L1 buffer から捨てられています。
トリガー時刻より過去の AMT0, AMT1, AMT2 の三つのチップに入ったヒット情報は L1 buffer から捨てられています。
今、uiTime_r_c は 0x25 = 37 = 925 ns ですので、コモン・ストップからさかのぼって 1 μs 弱の時間を記録すると思っています。
しかし、search/matching window が、約51 μs 開いていることによりコモン・ストップ後も約50 μs に渡って測定可能になっています。
#br
#ref(Matching_and_Rejection_in_Common_Stop_Mode_s.png,center);
#br
CENTER:[[イベント・マッチングとリジェクションの例>http://lambda.phys.tohoku.ac.jp/~kaneta/pukiwiki/index.php?plugin=attach&refer=AMT-VME%2FEvent_Rejection_and_Time_Window_on_AMT-VME&openfile=Matching_and_Rejection_in_Common_Stop_Mode.png]]
#br
ここで、マイナスの値のTDCがなぜ出てくるか考えます。
最初にAMT0, AMT1, AMT2 に適当なタイミングでヒットがあったとします。
上の図中の"time line of hit on AMT0-AMT2" の軸を見て下さい。
ヒットの時刻は、counter の値に対応します。
最初に、event rejection が働きます。
これにより、トリガーの入った時刻から 8 + uiTime_r_c + 1 だけ過去の時間のものは捨てられます。
次に、search_window, matching_window にかかるヒットのチェックを行います。
カウンターの範囲は 102.4 μs しかないので、トリガーが入ったタイミングのあと、matching_window にあるヒットの内、カウンターの境界を越えるものがあります。
マニュアルによると、「トリガー・マッチングはこの繰り返しを考慮して働く」とのことなので、マッチング後に残っているヒットは一つ下のタイム・ラインの様になります。
このヒット情報を DSP が読み出して処理をしますが、DSP プログラム は AMT chip から出てくるヒットの時間情報は 17 bit の整数ということしか考慮していません。
カウンターをまたいだかどうかをチェックしていないので、緑の領域にあったヒットは一番下のタイム・ラインの図にあるように見えます。
この値と、コモン・ストップの入力タイミングの差を取ると17bitの最大値に近い大きな TDC の値を返すことになります。
#br
#ref(Matching_and_Rejection_for_Different_Coarse_Counter_Timing_s.png,center);
#br
CENTER:[[トリガーの時刻と色々なCoarse counterの領域の場合のタイムラインの例>http://lambda.phys.tohoku.ac.jp/~kaneta/pukiwiki/index.php?plugin=attach&refer=AMT-VME%2FEvent_Rejection_and_Time_Window_on_AMT-VME&openfile=Matching_and_Rejection_for_Different_Coarse_Counter_Timing.png]]
Coarse counter の 0-4095 の領域とトリガーの入る時刻が、先ほどとは違った場合にどうなるかを考えたのが上の図です。
トリガーの時刻に対しカウンターの境目がどこに来るかの違いで、四つの場合を考えました。
一つ目と二つ目にある緑色の領域について考えましょう。
青色で示した領域に対し、緑の領域はコモン・ストップの時刻に対して小さな値を持っています。
AMT chip 内部での ヒットの時刻は 17 bit 長の整数です。
緑色の領域にあるヒットの時間に対し Common Stop の時間を引いた場合は、17 bit の 最大値 0x1FFFF から 0x10000 の方に向かって分布します。
DSP 内部では、AMT chip からのヒット時刻情報を 17 bit の数字として整形します。
具体的には、main.c の中で
ulHitData = w&0x0001ffff;
ulComData = ulCom_S_Time&0x0001ffff;
と書かれています。
AMT chip のヒットデータには、時間だけではなくチャンネル番号も32bitの 1 word に入っているのでマスクをかけて時間情報だけ取り出しています。
ulHitData は入力のヒットの時間、ulComData は Common Stop の時間です。
AMT-VME の出力は、Common Stop でかつオフセットを引かない設定の場合
ulWorkRD = 0x000fffff&(ulComData-ulHitData);
となり、引き算をした後で 20 bit に整形しています。
0x1???? の値は、0x000fffff とアンドをとっても 0x1???? のままです。
次に、二つ目から四つ目の青の領域に有りかつ Common Stop より後に入ったものについて考えます。
トリガーの入る時刻より後のヒットで、青の領域にあるものは コモン・ストップの時刻との引き算をするとマイナスの値になります。
コモン・ストップのヒットの時刻との引き算をすると、32 bit 長のマイナスの値 (たとえば、-1 = 0xFFFFFFFF) になります。
しかし、引き算後に0x000ffff とのアンドを取っています。
そのため、20 bit 長の整数のマイナス値、つまり 0xFFFFF から 0xF0000 の方向に向かってヒットが立つことになります。
最後に、四つ目のケースの黄色の領域のものについて考えます。
たとえば、コモン・ストップのヒット時刻が 0x0000100 (= 256)、検出器のヒット時刻が 0x0001FF32 (= 130866) だとすると、0x0000100 - 0x0001FF32 = 0xFFFE01CE となります。
たとえば、コモン・ストップのヒット時刻が 0x0000100 (= 256)、検出器のヒット時刻が 0x0001FF32 (= 130866) だとすると、~
0x0000100 - 0x0001FF32 = 0xFFFE01CE ~
となります。
引き算をした後、
if (((ulWorkRD&0x00010000)==0) || // If bit16 of ulWorkRD is 0 or
((ulRun_Status&0x0080)==0x0080)) { // bit7 = 1 (Normal mode)
ulWorkRD = (ulWorkRD&0x0fff1ffff);
}
という if 文があります。
差し引きされた値の入った変数 ulWorkRD と 0x00010000 とのアンドをとりますが、bit 16-19 の数字 E は2進数で 1110 ですので、2進数の 0001 とアンドを取ると 0000 になります。
したがって ulWorkRD の値は、0xFFF001CE となります。
上位12ビットの場所には、チャンネル番号と Falling/Rising のフラグが納められますので、時間情報としては 0x001CE だけになります。
0x1FF32 は、-206 に対応するので、256 - (-206) = 462 と計算した場合と同じ結果になり問題は起きません。
Coarse counter の繰り返しの領域とコモン・ストップがどこに入るかの相対位置により、コモン・ストップより後の時刻に入った検出器のシグナルのTDC の値が、17 bit の端の辺りか、20 bit の端の辺りになるかが変わってきます。
しかし、どちらもコモン・ストップより後から来た検出器のシグナル、つまり要らない情報には変わりはなく、通常の実験においては無駄なデータです。
