Subject: Meeting on possible use of common L1 module by calorimeter (fwd)
Date: Wed, 27 Nov 2002 14:09:18 +0100 (CET)
From: Bolek Pietrzyk <Bolek.Pietrzyk@cern.ch>
To: CROP LHCb LAPP <boget@lapp.in2p3.fr>, cyril@subatech.in2p3.fr,
david@lapp.in2p3.fr, debonis@lapp.in2p3.fr, decamp@lapp.in2p3.fr,
dumont@lapp.in2p3.fr, minard@lapp.in2p3.fr, moynot@lapp.in2p3.fr,
perrot@lapp.in2p3.fr, pietrzyk@lapp.in2p3.fr, prast@lapp.in2p3.fr,
terrier@lapp.in2p3.fr
---------------------------------------------------------------------
Dear all
I found the meeting yesterday very useful to get a first understanding
of the possibilities of the calorimeter using a common L1 front-end module.
For your information, what I presented can be found from my presentation in
the TB:
http://agenda.cern.ch/age?a021592
I think that we can divide the problems related to the possible
use of a common L1 into two different categories:
A: Technical
B: Organization ( institute responsibilities, manpower, planning, costs,
etc)
TECHNICAL
For the technical part quite some questions surfaced that needs to be looked
at in more detail. I have tried in a simplified fashion to identify points
that would need to be clarified from the two groups.
----------------------------------------------------------------------
Lausanne:
A data flow diagram showing partitioning of channels into groups and
the available data busses between the different groups and processing
FPGAs.
A first idea about the size and type of FPGAs used. The use of large FPGA's
is quite convenient but may have a significant effect on costs ( FPGA's,
PCB).
The possibility of adding four simple bi-directional (4 output, 4 input)
LVDS
links to neighbor L1 modules. Each link only needs to carry maximum 32 bits
at a 40kHz rate ( 1.28 Mbits/s per link).
Define which connections of the module could be on the front panel and which
must be on the back ( via connectors mounted in back of crate).
It has previously been mentioned by the Velo Lausanne group, that they
expect a
first final prototype to be available mid next year. This seems optimistic
with
the current state of things. A realistic estimate for the availability of
first prototypes
is needed. For external users the date that will count is the date where
mounted and tested prototype modules can be distributed with some simple
basic transparent FPGA programming.
----------------------------------------------------------------------
Calorimeter group:
A first estimate of the effect (event size) of only performing 2D
zero-suppression of
the interior of a L1 module ( assuming treating 1 or 2 crates of Ecal data)
without communicating with neighbor modules. ( this may require some
remapping of front-end cards treated by each L1 module). Verify that
Hcal and preshower/spd date does not have similar processing problems
as Ecal.
A first simple estimate of the requirements to FPGAs ( processing and
internal memory)
supposing a FPGA grouping with 4 (6) Preprocessing FPGAs ( working on local
data from
24/4 = 6 fibers) and one final FPGA. Can a simple communication between the
4 preprocessing
FPGAs simplify the job (eg. relatively slow communication of thresholded bit
map).
I may mention here that from a proposal from Jacques Lefrancois it may be
possible to simplify
buffering requirements in the processing by a guaranteed spacing between L1
trigger accepts.
This will be discussed in the coming LHCb week from where you can find my
transparencies
on this:
http://agenda.cern.ch/age?a021900
How many connections to neighbor cards are needed to perform the full 2D
zero suppression
using a common L1 front-end module (can less than four do the job).
------------------------------------------------------------------------
There are for sure some important questions I have forgotten to enable us to
get a first serious feeling if using a common L1 front-end module is
possible
(without weeks of work).
ORGANIZATION
For the organization part it is clear that the proposal for the use of such
a common module
comes at a rather unfortunate time as the current calorimeter design is
already quite advanced.
The time invested in this would though not be wasted as it has enabled a
good understanding
of the processing required for the calorimeter data. This current
understanding should hopefully
allow us to get a quick estimate of the possible technical difficulties in
using a common solution.
If it is found feasible to base the calorimeter readout on the common L1
front-end module there will
still be quite some work to do for the calorimeter group as they will have
to develop the specific
FPGA code needed for the calorimeter specific processing. Final board
verification and system
integration tests must also be made. If wanted the calorimeter group could
also take
responsibility for a well identified part of the common L1 front-end module
( e.g. 12 way
fiber receiver plug-in card, ECS interface, DAQ interface, etc.)
A first crude cost estimate using a common L1 front module varies from 150k
CHF
to 300k CHF. From this the costs of the original system must be subtracted (
L1 buffer
in cavern, readout links and finally special 2D zero-suppression system).
I would find it very useful if we could advance on some of the mentioned
points
before the coming LHCb. I will unfortunately not be present at CERN next
week
but I will hopefully still be capable of reading my Email. If any of you
would like to
make a presentation related to this subject in the electronics meeting
during the LHCb week
I would be very pleased. There are still some time available on the agenda.
We should also at some point try to get a feeling if there is a serious
interest
in having a L1 trigger interface from the Calorimeter for future upgrades
of the L1 trigger.
As you can probably sense from my Email I am myself still convinced that
a common solution would be the best long term solution for LHCb. I though
also fully understand that this dos not necessarily look the same seen from
the calorimeter group.
Please comment, and hope to see you all soon.
Jorgen
PS: Bolek, Can you forward this to your colleagues from Annecy
Jorgen Christiansen <jorgen.christiansen@cern.ch>
VLSI designer & LHCb electronics coordinator
CERN
EP-MIC-DG
Jorgen Christiansen
VLSI designer & LHCb electronics <jorgen.christiansen@cern.ch>
coordinator
CERN
EP-MIC-DG
14-6-011 Work Voice: +41 (0)22 767 5824
Geneva 23 Home Voice: + 33 (0)4 50 41 61 49
1211 Work Fax: +41 (0)22 767 3394
Switzerland
Additional Information:
Version 2.1
Last Name Christiansen
First NameJorgen
Label Work14-6-011 Geneva 23 1211 Switzerland
Label Home201 rue de la belle fermiere Segny 01170 France
Birthday 20010425
Revision 20021127T111531Z