ATLAS 実験における高速トラッキングトリガーシステムのシミュレーションによる最適化

ATLAS 実験における高速トラッキングトリガーシステム

のシミュレーションによる最適化

　　　　　　　　　　　　　　　　

千葉英誉 , 木村直樹，寄田浩平早稲田大学

ATLAS FTK Group

日本物理学会　 2010 年　春季大会

３月２１日　岡山大学津島キャンパス　21aBE 会場

FTKFTKFTKFTK

1

１ GeV 以上 (|η|<2.5) の全てのTrack の Pt,φ,η,Z,d を LVL2 に渡す。

Output

飛跡検出器内部の Pixel/SCT からHit 情報のみ貰い， Track を再構成する。

Input ＆ Process

飛跡検出器

Pixel 3Layer

Barrel

SCT 8Layer

ATLAS Trigger System ＆ＦＴＫ (Fast TracKer)

数週間前　 Technical Proposal(p.93) を提出

現在 TDAQ(USG) でレビュー中

FTK の目的現行のデザイン

1. Track 情報の使用　

　　　 b ジェット同定 ,τ 同定を飛躍的に向上 @LVL2

高ルミノシティ下でも安定した Track 情報の供給

LVL2 でより洗練された Algorithm が使用可能に

100μsec 以下の処理速度で事象中の

全ての Track 　 (1GeV 以上 ) 　を再構成

35

L=1034[cm-2 ･ s-1]@Atlfast

FTK有

FTK無

FTK 挿入後

2.RoI 以外のオブジェクトを LVL2 トリガーに加えられる

⇒QCD 事象をより多く破棄することできる。⇒ マルチジェットトリガーの P ｔ閾値を下げられるなど。（右図）

2

WH(120)3×1034 PILEUP

Black→OffLIneRed→FTK

Impact

Parameter

light quark

b quark

3. e や μ トリガーにも応用可能　　など

領域を選択し (RoI),Track を再構成

LVL2 以降の PC ファームで

FTK の基本動作原理1. Hit 情報をどの” Super Strip” に

モジュール Super Strip

Layer4

Layer3

Layer2

Layer1

Hit 位置

Road1 Road2

3. Track Fitting Stage＜ FTK の重要なパラメータ＞

Super Strip size

3

素早く処理できる構成方法

1. SCT8Layer Fit Pixel+SCT 11Layer Fit⇒

2. Pixel 3L+SCT 4L Fit 11Layer Fit⇒

今回はコチラのみ

現状の方法　２つ提案中

2. Super Strip 単位でのPattern Recognition → 　” Road” (Associative Memory)

Full Resolution の Hit 情報を使用

Layer の組み合わせpattern size に影響

位置するか分ける。 (Data Organizer)

ＦＴＫシステム

4

Pixel & SCT

RODs

Raw dataROBs

Data Organizer(DO)

Associative Memory(AM)

Track Fitter(TF)

FTK

Track DataROB

Hit

Super Strip

Road

Ｘ 64 (each region)

DataFormatter

(DF)

cluster findingsplit by layer

overlap regions

S-links

Processor Unit

Hit RoadInput

50kHz ～ 100kHz

1st Stage

SCT8Layer のみ計算

Processor Unit

2nd Stage 11Layer 全てにおいて計算Φ 16 等分 ×η 4 等分⇒ 64 Processor Unit

１等分に１ Board

Hit Warrior(HW)

8(16) Processor Unit 1 VME Crate⇒

但し , 十分なOverlap を含んだRegion 分け

Data Organizer / 1Board=1 分割分

☆1 つの DO に対し 100MHz の Clock で処理　

☆Input ＆ Output は Pipeline で 100MHz

☆LVL1 の Output は 100kHz を仮定

　１ Layer 辺り，１０００ Hit までなら

処理可能 (Input OK)

１ Region におけるLayer ごとの平均 Hit 数

Pixel 1 868.1 6.4

Pixel 2 687.3 4.2

Pixel 3 627.3 4.2

SCT 4 411.1 2.0

SCT 5 410.8 2.0

SCT 6 446.0 2.1

SCT 7 441.1 2.1

SCT 8 404.0 1.8

SCT 9 404.6 1.9

SCT 10 387.4 1.7

SCT 11 386.2 1.7

5Hits of SCT11

Hits of SCT 4

Hits of SCT 5

Hits of SCT 6

Hits of SCT 7

Hits of SCT 8

Hits of SCT 9

Hits of SCT10

100 MHz100MHz

DO

hit

SCT8L

SS

#SS<#Hit なので OK

WHbb L=3×1034[cm-2 ・ s-1] Pile-up

1Ev を 10μs で処理が必要

Associative Memory "Pattern Recognition"

DO から全ての SS 情報を

得てから処理開始 !!

AM は４枚 (LAMB) で処理する

1LAMB 200MHz の処理能力

4LAMB=4×200MHz=800MHz　

→ 8k Road まで耐える！ 6

Road

AM

100 MHz

SS 200

200

200

200

From

DO

< スペック >

Input 100MHz #SS<#Hit から OK

平均 Road 数　3.1k

→Output 　 OK


LAMB200MHz

AM

Track Fitter / 1Board

20k の Fit Combination

まで時間 Loss なしに

処理することが可能 7

Hit と Road を TF に送る2ndDO TF⇒

Road 内の Hit を Full Resolution で Fit する

TF

Fit1Fit2

Fit3

< スペック >

0.5GHz×4=2GHz

転送速度 100MHz×4

4k 以内のデータ量

3.1kRoad から転送可能

平均 Fit 数　 12.8k → OK


From

AM

Road

100 MHz

DO

road & hit100MHz

TF 500MHz

Timing Simulation

処理すべき Input の平均値が，各段階の平均処理速度を超えると処理が追いつかず，次のイベントの処理が遅れ続ける。

Total 時間を計算する！！

＜変数＞・ Hit 数

・ Board の処理速度

・ Input ， Output ， Delay time

最初の 1Hit情報が駆け抜ける時間

DF DO AM DO TF HW

全 Hit を待つのでパイプラインではなくなる⇒時間が

かかる

パイプラインなので，それぞれで

時間かかるところが全体の出力時間に影響！Input

1data

Output

処理されてOutput の時間が延びる

Fit も時間がかかる

8

< 目的>

処理時間が遅れることにより Trigger の Dead timeを生まないか確認のため

に

9

Timing Simulation の式DO

FwIn(i)=max[ 0,max(Pre_EwOut(i))-10μsec , max(Pre_Pre_SecDO_EwOut(I)) - 20μsec) ]EwIn(i)= #Hit(i)×InTime + FwIn(i)FwOut(i)= FwIn(i) + DelayEwOut(i)=max[ FwOut(i)+ProcTime×#Hit(i) , EwIn(i)+Delay ]

i=0-8(DO 8CPU) , ProcTime(ClockTime)=10nsec , InTime(Input time)=10nsec , Delay=40nsec

AM FwIn(i)=max[ min(DO_FwOut(i)) , max(Pre_EwOut(j))-10μsec , max(Pre_Pre_EwOut(j)) - 20μsec]

max(Pre_EwOut(j)) - 10μsec , max(#SS(i))×InTime+max(Pre_EwIn(j)) - 10μsecEwIn(i)= max[ max(DO_EwOut(i)) , max(#SS(i))×InTime + max(DO_FwOut(i)) ,

FwOut(i)= EwIn(j) + DelayEwOut(i)=FwOut(j)+max(ProcTime×#Road(j))

j=0-4(LAMB4 枚 ) , ProcTime(ClockTime)=5nsec , InTime(Input time)=10nsec , Delay=500nsec

max(#SS(i))×InTime+max(Pre_Pre_EwOut(j)) - 20μsec]

SecDO FwIn(I)=max[ min(AM_FwOut(j)) , max(Pre_EwOut(I)) - 10μsec) ]EwIn(I)= max[ max(AM_EwOut(j)) , max(#Road(j))×InTime + FwIn(I) ]FwOut(I)= FwIn(i) + DelayEwOut(I)=max[ FwOut(I)+ProcTime×#Road(j) , EwIn(I)+Delay ]

I=0-4(DO 4 枚 ) , ProcTime(ClockTime)=5nsec , InTime(Input time)=5nsec , Delay=200nsec

TF FwIn(k)=max[ min(SecDO_FwOut(I)) , max(Pre_EwOut(k)) - 10μsec) ]EwIn(k)= max[ max(SecDO_EwOut(I)) , max(#Hit(i))×InTime + FwIn(k) ]FwOut(k)= FwIn(k) + DelayEwOut(k)=max[ FwOut(k)+ProcTime×#Fit(k) , EwIn(k)+Delay ]

k=0-4(TF 4 枚 ) , ProcTime(ClockTime)=2nsec , InTime(Input time)=5nsec , Delay=300nsec

FwIn→ 最初のデータが処理部分に入る時EwIn→ 最後のデータが処理部分に入る時

FwOut→ 最初のデータが処理部分から出る時EwOut→ 最後のデータが処理部分から出る時

End Word Out Time

処理できない場合

　処理が蓄積して時間が増加する

処理できる場合

　蓄積した処理時間はリセットされる

平均 Hit 数＜ Spec 上限 Hit数　

10

処理時間は

蓄積され続けることはない

(Deadtime がない )


１イベント内の最後のデータが Output される時の時間と定義

End Word Out Time

100KHz で 100ev 分走らせた結果


AM は全 Layer の SS を全て使うので

SS を待つ時に時間がかかる。　　

11

最大処理時間がかかっている Event

前のイベントの処理によって遅れている

8 つのリージョンのうち最も遅いリージョンを最終的な事象プロセス時間とした

Event example (Total Process Time)


μsec オーダーで処理することが可能！

平均24μsec

12


現状の LVL2 を想定した Track 再構成にかかる時間⇒RoI のみを 1PC(Intel Core 2 Duo E8400 3.0GHz)

で Track 計算しても　 1RoI に msec オーダーかかる。

FTK processing time

msec

1RoI/1PC

WHbb with Pile-up

• ルミノシティ 3×1034[cm-2 ・ s-1] でも , 現在の FTK のデザインでは平均 Hit 数，

Road 数， Fit 数が Board の許容範囲内であることが分かった。　　→　その結果、 100μsec 以下で処理が可能である。• 100Ev で確かめた結果， Dead Time なしに処理することが可能であ

る。

• DF ， HW のデザイン最適化はまだ詰める必要がある。　　⇒　 DF や HW の処理時間を考慮し，デザインの最適化に反映。• 2nd Stage に関しても最適化を行う。• シミュレーションの統計数を増やす必要あり。

13

Time Simulation としての予定

FTK 全体としての予定• 全領域の Efficiency を高めるために記憶パターンや SuperStrip size の最適化

• Real Data の有効利用

　　 2012 年の Shutdown 時での挿入 (プロトタイプ版 ) を想定して開発・制作中！

纏め

展望

Documents

ATLAS 実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化

ATLAS 実験における高速トラッキングトリガーシステムのシミュレーションによる最適化