Focus on: 
Login

TDR Run 3 Editor meeting

→ Europe/Zurich
CERN

CERN
Slides
  • Wednesday 12 June
    • 14:00 → 14:15
      Introduction 15m
      Speakers: Alex Kluge (CERN), Pietro Antonioli (Universita e INFN (IT))
      Slides
    • 14:15 → 14:45
      CTP 30m
      Speakers: Orlando Villalobos Baillie (University of Birmingham (GB)), Orlando Villalobos Baillie (University of Birmingham), Mr Pierre Vande Vyvre (CERN)
      Slides
    • 14:45 → 15:15
      CRU 30m
      Speakers: Gergely Barnafoldi (Wigner RCP Hungarian Academy of Sciences (HU)), Gyorgy Rubin (Wigner Research Center for Physics), Tivadar Kiss (Hungarian Academy of Sciences (HU))
      Slides
    • 15:15 → 15:30
      DAQ 15m
      Speaker: Mr Pierre Vande Vyvre (CERN)
      Slides
    • 15:30 → 17:00
      Discussion on individual detector interfaces 1h 30m
      Speakers: Alex Kluge (CERN), Pietro Antonioli (Universita e INFN (IT)), Werner Riegler (CERN)
    • 17:45 → 18:05
      Following entries are not meant to be individual presentations: entries are there only to upload sub system material 20m
    • 22:15 → 23:20
      muon tracker 1h 5m
      Speaker: Herve Borel (CEA/IRFU,Centre d'etude de Saclay Gif-sur-Yvette (FR))
      Slides
    • 23:25 → 23:30
      ZDC 5m
      Speaker: Pietro Cortese (Universita del Piemonte Orientale (IT))
      document
    • 23:30 → 23:35
      trigger detectors 5m
      Speakers: Gerardo Herrera Corral (Centro Invest. Estudios Avanz. IPN (MX)), Gerardo Herrera Corral (Centro de Investigacion y de Estudios Avanzados del IPN (CINVESTAV)), Tatiana Karavicheva (Russian Academy of Sciences (RU)), Wladyslaw Henryk Trzaska (University of Jyvaskyla (FI))
      Slides
    • 23:35 → 23:40
      HMPID 5m
      Speaker: Giacinto De Cataldo (Universita e INFN (IT))
    • 23:40 → 23:45
      TRD 5m
      Speaker: Joerg Lehnert (Johann-Wolfgang-Goethe Univ. (DE))
      Slides
    • 23:45 → 23:50
      PHOS 5m
      Speaker: Prof. Bernhard Skaali (University of Oslo (NO))
      Slides
    • 23:50 → 23:55
      muon identifier 5m
      Speakers: Pascal Dupieux (Univ. Blaise Pascal Clermont-Fe. II (FR)), Pascal Dupieux (Univ. Blaise Pascal Clermont-Fe. II (FR))
      Slides
    • 23:55 → 00:00
      EMCAL 5m
      Speaker: Terry Awes (Oak Ridge National Laboratory - (US))
      Slides
      EMCAL info after meeting:

      Dear Alex,
       
      See replies below.
       
      Have a nice weekend!
      Terry
       


      On Fri, Jun 14, 2013 at 4:04 PM, Alex Kluge <Alexander.Kluge@cern.ch> wrote:
      Dear Terry,
       
      thank you for the info.
       
      I have seen you added that L1 is needed in your system,
       
      Why do you need a L1 and you could not just read-out upon L0?
      Yes, we don't need an L1 - we could readout always on L0 (with a change in firmware).  But if there is to be an L1 trigger (such as the jet trigger from EMCal) we would readout on L1. The EMCal Jet trigger is only available some few us after L0. Maybe there is some clarification needed. With the ALTROs, the time samples (pre/post L0) are saved onto a stack when L0 is received. With Multi-Event buffering, when the L1 is received the pointer to the stack is incremented so that the ALTRO is ready to take another event immediately, and the readout of the event can proceed in parallel (i.e. no readout deadtime). If the L1 is not received at the expected latency it means the event has been rejected (L1r) and the pointer to the stack is not incremented. The next L0 will just overwrite the previous event. So basically the event is rejected before the readout starts. Alternatively, one could always increment the pointer on L0, and begin the readout. However,  if there is to be any rejection at L1 one would then need to be able to "abort" the event somewhere along the readout process. Obviously, the easiest and safest way to do that is either before the readout starts, or after it completes. So the L1r is necessary to reject the readout before it starts.
      Currently, the event can also be accepted or rejected at L2 with the L2a or L2r, but that happens essentially at the end of the readout process - after the "subevent" has been readout and assembled in the (RCU or SRU) and, before being sent to the LDC. So one has paid nearly the full readout busy time. 
       
      As you see, another consequence of this is that with the current (TPC inherited!) readout of the EMCal (and PHOS) there cannot be interleaved L0 and L1s, each L0 must be followed by an L1a/L1r, otherwise the second event will overwrite the data on the readout stack. The only solution would be if it's possible to always increment the pointer on the MEB stack when the L0 is received, and then either read the event and remove from stack on L1a, or just remove from stack on L1r. I don't know if this is feasible with the ALTRO - Luciano would be best to ask. If it's possible, then the FEE BC firmware could be modified to do this I think.
       
      Also what would the busy time be when you read-out at 50 kHz?
      That would be 100% busy. The readout has multi-event buffering, so we can approach the full rate before going fully busy. Actually, the 50kHz (19us readout) was our "theoretical estimate" based on the expected readout times. So far we are more like  22us (45kHz) which may be due to overhead that we hope can be improved with further FW work.
       
      You write you might use DDL or 10 Gbit/s, which DLL version you would use? 1/2//3?
      The SRU currently has implemented DDL1 in firmware, to be compatible with the existing readout. If DDL2 is just a matter of a firmware modification it could be implemented as well. There is also the hardware to implement a 10Gbit ethernet fiber output, or DDL3 I suppose. As I discussed in my presentation - the DDL1 bandwidth is not the limitation on the EMCal readout speed, it is dominated by the ALTRO bus, so there is no bandwidth reason to improve the speed of the link to the LDC, it's only a question of compatibility with the wishes from the DAQ side. This also means that the EMCal readout speed will not be improved by any CRU alternative.
       
      Regards,
       
      Alex
       
      On Jun 12, 2013, at 2:25 PM, Terry Awes <terryawes@gmail.com> wrote:
      Hi Alex,
      DId you get this?
      Regards,
      Terry

      ---------- Forwarded message ----------
      From: Terry Awes <terryawes@gmail.com>
      Date: Mon, Jun 10, 2013 at 5:23 PM
      Subject: Re: TDR - ALICE run 3 interfaces
      To: Alex Kluge <Alexander.Kluge@cern.ch>, Pietro Antonioli <Pietro.Antonioli@cern.ch>, Werner Riegler <Werner.Riegler@cern.ch>


      Hi Alex,
      I plan to attend the meeting on Wednesday. I attach the spreadsheet with the modified EMCal information.
      Regards,
      Terry


      On Fri, Jun 7, 2013 at 10:43 AM, Alex Kluge <Alexander.Kluge@cern.ch> wrote:
      Dear colleagues,

      after a first round with individual sub-system TDR discussions, it is time for our common discussion on June 12, 14:00.
      For those at CERN I reserved 14-4-10. Please let me know if you intend to come in person, to be certain the room is large enough.

      The aim is to disucss the interfaces between the sub-systems:
      trigger, TTC or successor, CRU, DAQ

      Please find the indico entry with the video information here:
      https://indico.cern.ch/conferenceDisplay.py?confId=256477
      The meeting is planned to finish around 17:00, the indico entries later serve only to upload sub system information.

      A table with general sub-system parameters has been prepared, please verify it for your system and add missing parameters (table is attached to this mail and available from the meeting indico page)

       In addition to that we would like to ask to present (even if some of these data are already in the table) the following items:

      *) Interface to the common read-out unit (CRU), if used

      ·      how many CRUs does your sub-system need assuming a 10 Gb/s bandwidth to the DAQ?

      ·      how many inputs does a CRU need under the assumption it has 10 Gb/s link to the DAQ?

      ·      what is the transmission speed requirement of your detector links to the CRU?

      ·      what is the type if interface (optical/electrical/differential/...)?

      ·      what kind of trigger interface, which kind of trigger information, does the detector connected to the CRU need?

      ·      does the CRU need to perform data processing or only multiplexing?

      ·      how big would the buffer need to be if data processing/multiplexing is performed?

      ·      does the CRU need to perform trigger selection?


      *) Type of DLL interface to DAQ, if CRU is not used

      *) Trigger input to detector

      ·      how many trigger levels does your system need?

      ·      what is the maximum latency for each of this trigger signals you can accept?

      ·      will your system use the old TTC?

      ·      (if the answer to previous question is yes): will you use the TTCrx chip?

       *) Trigger output from detector

      ·      will your system provide a trigger output?

      ·      (and if yes) which interface and with which latency?

       *) Busy

      ·      will the front-end or read-out system deliver a busy signal?

      ·      do you expect the CRU do extract the busy state of the detector?

       *) Rate

      ·      what will be the maximum read-out rate of the detector?

      ·      with which kind of dead time?



        Kind regards,  Pietro, Werner and Alex
      <RunningSummaryEMCal.docx>

  • Thursday 13 June
    • 00:00 → 00:05
      TOF 5m
      Speaker: Pietro Antonioli (Universita e INFN (IT))
    • 00:05 → 00:15
      Common Front-end ASIC 10m
      Speaker: Hugo Daniel Hernandez Herrera (Universidade de Sao Paulo (BR))
    • 00:05 → 00:10
      ITS 5m
      Speaker: Luciano Musa (CERN)
    • 00:10 → 00:15
      TPC 5m
      Speakers: Christian Lippmann (GSI - Helmholtzzentrum fur Schwerionenforschung GmbH (DE)), Harald Appelshaeuser (Johann-Wolfgang-Goethe Univ. (DE))
      Slides