- 追加された行はこの色です。
- 削除された行はこの色です。
* 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プログラム中で uTime_r_c というローカル変数に代入され、counter offset や window の値を変えるのに用いられています。
この値は、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=Parameters_Related_Event_Matching.png&refer=AMT-VME%2FEvent_Rejection_and_Time_Window_on_AMT-VME]]
CENTER:[[AMT-VMEボード上でのイベント・マッチングの動作>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 に入りますので、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 から捨てられています。
今、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);
// Matching_and_Rejection_in_Common_Stop_Mode.png
#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);
// Matching_and_Rejection_for_Different_Coarse_Counter_Timing.png
#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 の領域とトリガーの入る時刻が、先ほどとは違った場合にどうなるかを考えたのが上の図です。
トリガーの時刻に対して、四つの場合を考えました。
青色で示した領域に対し、緑の領域はコモン・ストップの時刻に対して小さな値を持っています。
17 bit 長の整数の取る範囲で分布をするので、DSPで引き算をした場合は、17 bit 最大値 0x1FFFF から 0x10000 の方に向かって分布します。
トリガーの入る時刻より後のヒットで、青の領域にあるものは コモン・ストップの時刻との引き算をするとマイナスの値になります。
DSP 内部の変数は 32 bit 長のものが使用されています。
そのため、各 AMT chip からのヒットの時刻をローカル変数に代入したあと 0x0001FFF とのアンドをとり17 bit 長であることを保証します。
コモン・ストップのヒットの時刻との引き算をすると、32 bit 長のマイナスの値 (たとえば、-1 = 0xFFFFFFFF) になります。
しかし、引き算後に0x000ffff とのアンドを取っています。
そのため、20 bit 長の整数のマイナス値、つまり 0xFFFFF から 0xF0000 の方向に向かってヒットが立つことになります。
最後に、一番下に示されたケースの黄色の領域のものについてです。
たとえば、コモン・ストップのヒット時刻(coarse time)が 100、検出器のヒット時刻が 4050 だとすると、100 - 4050 = -3950 となります。
しかし、正の整数の範囲でしか表現されないので、-3950 は -3950 + 4096 = 146 となり問題なく扱われます。
Coarse counter の繰り返しの領域とコモン・ストップがどこに入るかの相対位置により、コモン・ストップより後の時刻に入った検出器のシグナルのTDC の値が、17 bit の端の辺りか、20 bit の端の辺りになるかが変わってきます。
しかし、どちらもコモン・ストップより後から来た検出器のシグナル、つまり要らない情報には変わりありません。
