dHLT activities at Saha Institute, India

1
dHLT activities at Saha Institute, India
Responsibility To supply RecontructedHits from
PadHits for each cathode plane of Station 4 and 5
using FPGA which will sit on the corresponding
RORC card. Constraint Hit reconstruction has to
be done on-the-fly for 140 particles (for
central Pb-Pb) which fires 550 pads for every
event as there will be no buffer. Expected
trigger rate - 1 kHz gt available time 1
ms. trigger distribution? of Central Pb-Pb
2
DATA FLOW

• 450 Hijing central Pb-Pb events in AliRoot 3.09
• Analyzed for Hits and PadHits

• All processes switched ON
• 32000 particles
• ABSO, DIPO, SHIL and MUON was ON

3
Station 4 - numbers are averaged over the
cathodes for each chamber
4
Station 5 - numbers are averaged over the
cathodes for each chamber
5
Trigger stations - numbers are averaged over the
cathodes for each chamber
6
Immediate Goal was Search for a suitable
HitRecontruction algorithm which respects the
time constraint. Activity in last 4 months An
algorithm has been identified and simulation
studies using the digitized data of AliRoot show
that it has the required efficiency and accuracy
in HitReconstruction.
7
The Algorithm
Basic Idea Each cluster is characterized by one
Central Pad (Pad with maximum charge for a given
cluster). gt No. of Tracks/event No. of
Central Pads/event if overlapping clusters are
ignored. This is only 1.4 for central Pb-Pb in
stations 4 and 5. So, presently they are not
considered. Thus, to generate RecHits, it is
not essential to make clusters but
identification of Central Pad is sufficient.
Once the Central Pad is found, the resolution in
y-direction (for bending plane) can be simply
obtained from the CG of the charge distribution
between the Central Pad and its top and bottom
neighbours.
8
Algorithm for finding the Central Charge

• Two Approaches have been used

CASE 1 Hierarchical Algorithm
Example for bending plane Step 1 The initial
data is stored in a 2-D Register lt-
ORDATAixiy iqPad where ix is the pad
no. in x-direction and iy is the pad no. in
y. This data is generated from AliRoot. Step 2
Put a Threshold cut on Pad Charges. This is
quite handy as we know that almost all the
central charges are above 100 ADC channels while
a substantial number of non-central charges are
below 100 ADC channel. So after threshold cut
of 100 ADC channel, we generate an
intermediate register IRDATAixiyiqPad and we
assume all the members to be Central charges.


9
STEP 3 Start connecting the Central Charges. We
know for the bending plane the charges will
spread in the y-direction only as the pad
dimension is 5 mm in y-direction and 25, 50 and
100 mm in x-direction. So, look for the largest
of IRDATAixiy, IRDATAixiy1 and
IRDATAixiy2 and remove others from the
register. All the surviving pads are then assumed
to be Central Pads. Step 4 Start connecting the
Central pads in the x-direction. As these are
strip chambers, it is sufficient to consider only
IRDATAixiy and IRDATAix1iy as the charge
will never spread over three pads in the
x-direction. After step 4, we have the Register
for central hits where we know the ix and iy
of all the central hits which can now be
correlated to the ORDATAixiy.
10
Hit Reconstruction (RecHit)
Main issue The reconstructed hits have to be
given in absolute coordinates.

• For the bending plane, y-resolution can be
  extracted with reasonable accuracy while in the
  x-direction there will be no resolution. So we
  can only return the center of the Central Pad (in
  absolute coordinate)
• Now for the bending plane the dimension in
  y-direction is constant which is 5 mm.
• So mapping from pad no. in y-direction to the
  pad positions in cm is trivial. Only we have to
  remember that the slats in y-direction overlap
  with each other.
• Similarly for the non-bending plane the pad
  dimension in x-direction is constant - 7.143 mm
  and it is possible to estimate the x-resolution
  accurately in this case.

11

• Steps 2, 3 and 4 and the hit-reconstruction was
  implemented on a single intermediate register as
  the data flows in (on-the-fly), using a similar
  logic to that used in the game of Chinese-checker.

• The process time was found to be within 10 ms
  for 150 particles/event which was within the
  right ball-park.

• But the data register for a given plane in the
  present scenario is too big (110 X 880) to fit in
  the RAM of FPGA (hardware constraint).

• So an alternative data storage scheme.

12
Case 2
Step 1
The digitized data from AliRoot was stored in a
Data Register. Each hit (x- position,
y-position and the charge) was stored as a 32-bit
number to mimic the real data. So for 550 hits
the size of the data register is 2.2 kB which is
quite acceptable.
Step 2 Each data from the data register is masked
to extract the charge. If it is bigger than 100
then we search for its top and the bottom
neighbors. If they are present and both the
charges are less than the present data then we
proceed to extract the hit position in cm using
CG.
Step 3 If a cluster has been sorted then all the
members are removed from the Data Register to
avoid double counting.
Step 2 and 3 are repeated for all the Data members
13
Central hit efficiency No. of Central Pads
per event / No. of Tracks per event
(the efficiency is averaged over
100 events)
Central Hit efficiency for a
threshold of 100 is 99
14
Residue in bending direction
15
Hit Reconstruction
Accuracy (averaged
over 100 events)
99 of the reconstructed hits are within
100 micron of Geant hits
16
Estimation of process time (averaged over 100
events)
Data is structured column-wise
We need to structure the data in the Data
Register.
17

• Non-bending resolution (x-direction) has been
  obtained from similar logic. For non-bending
  plane the pad dimension in x-direction is
  constant 7.143 mm

• Is cathode correlation needed?
• dHLT algorithm will dictate whether the bending
  plane data is sufficient or not.

• The data structuring scheme and the realistic
  time estimation can only be done with a realistic
  data. This is because AliRoot data is structured
  -gt data is written cluster-wise. This will not be
  the case in real life.

18
What is a realistic data? A Binary stream of
data with appropriate headers. Each hit will be
represented as 32 bit number where 12 bits will
be used to store the charge, 11 bits for the Manu
No. and 6 bits for the corresponding ADC
number. Thus, we need the convolute the AliRoot
data by the detail Slat mapping and the bus-patch
connections and add the appropriate headers.
19
What has been done along this line

• For the bending plane of station 4
• The basic mapping from ix and iy of AliRoot to a
  Manu Card and ADC has been done and the data
  is stored as a 32-bit number.
• The Manu card numbers the bending plane are
  assumed to vary from 1 to 988.
• For the non-bending plane it can be from 1001 to
  1988.
• Now we have a macro which produces realistic
  data (but still no headers are included) from
  AliRoot. In addition, the data is not written
  clusterwise but from the beginning bus patch
  (assumed to be the left hand bottom corner) to
  the end. Now we can get a better estimates of
  time required for the dHLT algo.
• Time required for de-convolution of header in
  ix, iy.

20
But, more has to be done The bus line mapping
mixing of bending and non-bending bus patches.
However, the exact bus-patch connection is not
important. -gt HitReconstructed hit in global
co-ordinates (GMS data?) Presently, we are using
this binary data for the dHLT algo. Look-up table
-gt a very large array (2 Mb !) in a external
memory? Mapping logic -gt computation
time? Present plan Mapping logic -gt columnwise
structured data in a intermediate data register
(additional 2.2 kb) lt- random memory allocation.
21
Hardware Status

• Altera-Quartus ver. 4.0 is installed. Licensing
  issue yet to resolved. (Back-end tool).
• Interface issues between dHLT HitRecontruction
  logic and the I/O sub-systems developed by the
  Heidelberg group has been formalised.
• VHDL coding of the logic will commence as soon
  as the software algo is standardised lt- realistic
  data is needed.