Event Rejection and Time Window on AMT-VME†

AMT chip の中では、三つのカウンターがあります。

1. coarse counter
2. bunch counter
3. 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) 近くの大きな値になっていることが分かります。 実際のイベント・マッチングのプロセスを考えると、この値はマイナスの値であると考えるほうが自然です。 以下に 三つのカウンターの相対的な位置を示します。

コモン・ストップ・モードの場合、トリガーはヒットより後の時刻に 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 に渡って測定可能になっています。

ここで、マイナスの値の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 の値を返すことになります。

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
となります。 引き算をした後、

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 の端の辺りになるかが変わってきます。 しかし、どちらもコモン・ストップより後から来た検出器のシグナル、つまり要らない情報には変わりはなく、通常の実験においては無駄なデータです。