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

ATLAS実験における
高速トラッキングトリガーシステムの
シミュレーションによる最適化
千葉英誉, 木村直樹，寄田浩平
早稲田大学
ATLAS FTK Group
日本物理学会 2010年春季大会
３月２１日岡山大学津島キャンパス 21aBE会場
ATLAS Trigger System ＆ＦＴＫ(Fast TracKer)
飛跡検出器
Input＆Process
飛跡検出器内部の Pixel/SCTからHit
情報のみ貰い，Trackを再構成する。
FTK
Output
１GeV以上(|η|<2.5)の全てのTrackの
Pt,φ,η,Z,d をLVL2に渡す。
Barrel
SCT 8Layer
数週間前 Technical Proposal(p.93)を
提出
Pixel 3Layer
現在TDAQ(USG)でレビュー中
1
WH(120)3×1034 PILEUP
FTKの目的
Black→OffLIne
Red→FTK
Impact
現行のデザイン
Parameter
LVL2以降のPCファームで
領域を選択し(RoI),Trackを再構成
b quark
FTK挿入後
100μsec以下の処理速度で事象中の
全てのTrack (1GeV以上) を再構成
light quark
1. Track情報の使用
bジェット同定,τ同定を飛躍的に向上 @LVL2
L=1034[cm-2 ･s-1]@Atlfast
⇒QCD事象をより多く破棄することできる。
⇒マルチジェットトリガーのPｔ閾値を下げられるなど。（右図）
2.RoI以外のオブジェクトをLVL2トリガーに加えられる
3. eやμトリガーにも応用可能
など
高ルミノシティ下でも安定したTrack情報の供給
LVL2でより洗練されたAlgorithmが使用可能に
35
FTK有
FTK無
2
FTKの基本動作原理
1. Hit情報をどの”Super Strip”に
位置するか分ける。(Data Organizer)
2. Super Strip単位での
Pattern Recognition → ”Road”
(Associative Memory)
Layer4
Layer3
Road1
Layer2
Road2
Layer1
モジュール
Hit位置
Super Strip
3. Track Fitting Stage
Full ResolutionのHit情報を使用
＜FTKの重要なパラメータ＞
素早く処理できる構成方法
Super Strip size
pattern sizeに影響
Layerの組み合わせ
現状の方法２つ提案中
今回はコチラのみ
1. SCT8Layer Fit ⇒ Pixel+SCT 11Layer Fit
2. Pixel 3L+SCT 4L Fit ⇒ 11Layer Fit
3
ＦＴＫシステム
Pixel & SCT
RODs
FTK
cluster finding
split by layer
S-links
Input
overlap
regions
Data
Formatter
(DF)
Processor Unit
Super Strip
Data Organizer
(DO)
Hit
50kHz～100kHz
Raw data
ROBs
１等分に
１Board
Hit
Road
Associative Memory
(AM)
Road
Track Fitter
(TF)
Hit Warrior
(HW)
1st Stage
SCT8Layerのみ計算
Ｘ64 (each region)
Processor Unit
2nd Stage 11Layer全てにおいて計算
Φ 16等分×η 4等分⇒64 Processor Unit
8(16) Processor Unit ⇒ 1 VME Crate
但し,十分なOverlapを
含んだRegion分け
Track Data
ROB
4
Data Organizer / 1Board=1分割分
☆LVL1のOutputは100kHzを仮定
１Regionにおける
Layerごとの平均Hit数
1Evを10μsで処理が必要
WHbb L=3×1034[cm-2・s-1] Pile-up
☆Input＆OutputはPipelineで100MHz
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
Hits of SCT 6
SCT 8
404.0 ± 1.8
Hits of SCT 7
SCT 9
404.6 ± 1.9
Hits of SCT 9
SCT 10
387.4 ± 1.7
Hits of SCT10
SCT 11
386.2 ± 1.7
１Layer辺り，１０００Hitまでなら
処理可能 (Input OK)
☆1つのDO に対し100MHzのClockで処理
#SS<#HitなのでOK
SCT8L
DO
Hits of SCT 4
Hits of SCT 5
Hits of SCT 8
Hits of SCT11
100MHz
hit
100 MHz
SS
5
Associative Memory "Pattern Recognition"
Input 100MHz
#SS<#HitからOK
AM
SS
100 MHz
200
AM
Road
LAMB
200MHz
200
From
DO
200
DOから全てのSS情報を
200
得てから処理開始!!
WHbb L=3×1034[cm-2・s-1] Pile-up
<スペック>
AMは４枚(LAMB)で処理する
1LAMB 200MHzの処理能力
平均Road数
3.1k
4LAMB=4×200MHz=800MHz
→Output OK
→ 8k Roadまで耐える！
6
DO
Track Fitter / 1Board
TF
100 MHz500MHz
2ndDO⇒TF
HitとRoadをTFに送る
Road
転送速度100MHz×4
From
Fit1
Fit2
Fit3
AM
4k以内のデータ量
3.1kRoadから転送可能
TF
Road内のHitをFull
ResolutionでFitする
road & hit
100MHz
WHbb L=3×1034[cm-2・s-1] Pile-up
<スペック>
0.5GHz×4=2GHz
20kのFit Combination
まで時間Lossなしに
処理することが可能
平均Fit数 12.8k → OK
7
Timing Simulation
<目的>
処理すべきInputの平均値が，各段階の平均処理速度を超えると処理が
追いつかず，次のイベントの処理が遅れ続ける。
処理時間が遅れることにより
TriggerのDead timeを生ま
ないか確認のために
＜変数＞
最初の1Hit
情報が駆け
抜ける時間
・Hit数
・Boardの処理速度
・Input，Output，Delay time
Total時間を計算する！！
パイプラインなので，それぞれで
時間かかるところが全体の出力時間に影響！
Output
Input
DF
1data
DO
AM
全Hitを待つのでパイ
プラインではなくなる
⇒時間がかかる
DO
TF
HW
Fitも時間がかかる
処理されて
Outputの時
間が延びる
8
Timing Simulationの式
i=0-8(DO 8CPU) , ProcTime(ClockTime)=10nsec , InTime(Input time)=10nsec , Delay=40nsec
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) + Delay
EwOut(i)=max[ FwOut(i)+ProcTime×#Hit(i) , EwIn(i)+Delay ]
AM j=0-4(LAMB4枚) , ProcTime(ClockTime)=5nsec , InTime(Input time)=10nsec , Delay=500nsec
FwIn(i)=max[ min(DO_FwOut(i)) , max(Pre_EwOut(j))-10μsec , max(Pre_Pre_EwOut(j)) - 20μsec]
EwIn(i)= max[ max(DO_EwOut(i)) , max(#SS(i))×InTime + max(DO_FwOut(i)) ,
max(Pre_EwOut(j)) - 10μsec , max(#SS(i))×InTime+max(Pre_EwIn(j)) - 10μsec
max(#SS(i))×InTime+max(Pre_Pre_EwOut(j)) - 20μsec
]
FwOut(i)= EwIn(j) + Delay
EwOut(i)=FwOut(j)+max(ProcTime×#Road(j))
DO
SecDO I=0-4(DO 4枚) , ProcTime(ClockTime)=5nsec , InTime(Input time)=5nsec , Delay=200nsec
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) + Delay
EwOut(I)=max[ FwOut(I)+ProcTime×#Road(j) , EwIn(I)+Delay ]
TF k=0-4(TF 4枚) , ProcTime(ClockTime)=2nsec , InTime(Input time)=5nsec , Delay=300nsec
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) + Delay
EwOut(k)=max[ FwOut(k)+ProcTime×#Fit(k) , EwIn(k)+Delay ]
FwIn→最初のデータが処理部分に入る時
EwIn→最後のデータが処理部分に入る時
FwOut→最初のデータが処理部分から出る時
EwOut→最後のデータが処理部分から出る時
9
End Word Out Time
End Word Out Time １イベント内の最後のデータがOutputされる時の時間と定義
WHbb L=3×1034[cm-2・s-1] Pile-up
処理できない場合
処理が蓄積して時間が増加する
処理できる場合
蓄積した処理時間はリセットされる
平均Hit数＜Spec上限Hit数
処理時間は
蓄積され続けることはない
(Deadtimeがない)
100KHzで100ev分走らせた結果
10
Event example (Total Process Time)
AMは全LayerのSSを全て使うので
最大処理時間がかかっているEvent
SSを待つ時に時間がかかる。
前のイベントの処理によって遅れている
WHbb L=3×1034[cm-2・s-1] Pile-up
WHbb L=3×1034[cm-2・s-1] Pile-up
8つのリージョンのうち最も遅いリージョンを最終的な事象プロセス時間とした
11
FTK processing time
μsecオーダーで処理することが可能！
現状のLVL2を想定したTrack再構成にかかる時間
⇒RoIのみを1PC(Intel Core 2 Duo E8400 3.0GHz)
でTrack計算しても 1RoIにmsecオーダーかかる。
WHbb L=3×1034[cm-2・s-1] Pile-up
WHbb with Pile-up
平均
24μsec
1RoI/1PC
msec
12
纏め
• ルミノシティ3×1034[cm-2・s-1]でも,現在のFTKのデザインでは平均Hit数，
Road数，Fit数がBoardの許容範囲内であることが分かった。
→ その結果、100μsec以下で処理が可能である。
• 100Evで確かめた結果，Dead Timeなしに処理することが可能である。
展望
Time Simulationとしての予定
• DF，HWのデザイン最適化はまだ詰める必要がある。
⇒ DFやHWの処理時間を考慮し，デザインの最適化に反映。
• 2nd Stageに関しても最適化を行う。
• シミュレーションの統計数を増やす必要あり。
FTK 全体としての予定
• 全領域のEfficiencyを高めるために記憶パターンやSuperStrip sizeの最適化
• Real Dataの有効利用
2012年のShutdown時での挿入(プロトタイプ版)を想定して開発・制作中！
13

Download Report