+ All Categories
Home > Documents > Data Acquisition Systems...Outline • Introduction • A DAQ for a large – Data acquisition –...

Data Acquisition Systems...Outline • Introduction • A DAQ for a large – Data acquisition –...

Date post: 02-Feb-2021
Category:
Upload: others
View: 5 times
Download: 0 times
Share this document with a friend
68
Data Acquisition Systems CERN Summerstudent Programme 2008 CERN Summerstudent Programme 2008 Niko Neufeld, CERN-PH
Transcript
  • Data Acquisition Systems

    CERN Summerstudent Programme 2008CERN Summerstudent Programme 2008Niko Neufeld, CERN-PH

  • Introduction

    • Data Acquisition is a specialized• Data Acquisition is a specialized engineering discipline thriving mostly in the eco-system of large sciencethe eco system of large science experiments, particularly in HEP

    • It consists mainly of electronics computerIt consists mainly of electronics, computer science, networking and (we hope) a little bit of physicsp y

    • Some material and lots of inspiration for this lecture was taken from lectures by my y ypredecessors

    • Many thanks to S. Suman for his help with

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 2

    y pthe drawings!

  • Outline

    • Introduction • A DAQ for a large – Data acquisition– The first data acquisition

    campaign

    gexperiment– Sizing it up

    Triggercampaign• A simple DAQ system

    – One sensor

    – Trigger– Front-end Electronics– Readout with networks

    – More and more sensors• Read-out with buses

    C t & M h i

    • Event building in switched networks

    • Problems in switched – Crates & Mechanics – The VME Bus

    • Read-out with networks

    networks• A lightning tour of

    ALICE, ATLAS, CMS andRead out with networks ALICE, ATLAS, CMS and LHCb DAQs

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 3

  • Disclaimer

    • Trigger and DAQ are two vast subjects covering a lot• Trigger and DAQ are two vast subjects covering a lot of physics and electronics

    • Based entirely on personal bias I have selected a few y ptopics

    • While most of it will be only an overview at a few places we will go into some technical detailplaces we will go into some technical detail

    • Some things will be only touched upon or left out altogether – information on those you will find in the references at the endreferences at the end– Electronics (lectures by J. Christiansen)– High Level Trigger (lectures by G. Dissertori)– DAQ of experiments outside HEP/LHC– Management of large networks and farms– High-speed mass storage

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 4

    g p g– Experiment Control (= Run Control + Detector Control / DCS)

  • Tycho Brahe and the Orbit of MMars

    I've studied all available charts of the planets and stars and none of them match the others There are just as manynone of them match the others. There are just as many measurements and methods as there are astronomers and all of them disagree. What's needed is a long term project with the aim of mapping the heavens conducted from a singlethe aim of mapping the heavens conducted from a single location over a period of several years.Tycho Brahe, 1563 (age 17).

    • First measurement campaign• Systematic data acquisitionSystematic data acquisition

    – Controlled conditions (same time of the day and month)

    – Careful observation of boundary conditions (weather, light conditions etc…) - important for data quality / systematic uncertainties

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 5

    data quality / systematic uncertainties

  • The First Systematic Data Acquisition

    • Data acquired over 18 years, normally e every monthE h t l t d t l t 1 h ith th k d

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 6

    • Each measurement lasted at least 1 hr with the naked eye• Red line (only in the animated version) shows comparison with modern

    theory

  • Tycho’s DAQ in Today’s TerminologyTerminology

    • Bandwith (bw) = Amount of data• Bandwith (bw) = Amount of data transferred / per unit of time– “Transferred” = written to his logbookTransferred written to his logbook– “unit of time” = duration of measurement – bwTycho = ~ 100 Bytes / h (compare with LHCb Tycho y / ( p

    40.000.000.000 Bytes / s)• Trigger = in general something which tells

    you when is the “right” moment to take your data– In Tycho’s case the position of the sun,

    respectively the moon was the triggerthe trigger rate ~ 3 85 x 10-6 Hz (compare with

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 7

    – the trigger rate ~ 3.85 x 10 6 Hz (compare with LHCb 1.0 x 106 Hz)

  • Some More Thoughts on Tychog y

    T h did t d th t l i• Tycho did not do the correct analysis of the Mars data, this was done by Johannes Kepler (1571-1630), eventually paving the way for y p g yNewton’s laws

    • Morale: the size & speed of a DAQ• Morale: the size & speed of a DAQ system are not correlated with the importance of the discovery!

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 8

  • A Very Simple DataA Very Simple Data Acquisition Systemq y

  • Measuring Temperatureg p• Suppose you are given a Pt100Suppose you are given a Pt100

    thermo-resistor• We read the temperature as a• We read the temperature as a

    voltage with a digital voltmetervoltmeter

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 10

  • Reading Out AutomaticallyReading Out Automatically#include struct usb_bus *bus; struct usb_device *dev; usb dev handle *vmh = 0;usb_dev_handle vmh 0; usb_find_busses(); usb_find_devices(); for (bus = usb_busses; bus; bus = bus->next)

    for (dev = bus->devices; dev; dev = dev->next)

    if (dev descriptor idVendor

    Note how small the sensor has

    if (dev->descriptor.idVendor == HOBBICO) vmh = usb_open(dev);usb_bulk_read(vmh ,3,&u,sizeof(float),500);

    the sensor has become.In DAQ we normally neednormally need not worry about the details of the things e

    USB/RS232

    the things we readout

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 11

  • Read-out 16 Sensors

    • Buy 4 x 4-port USB hub (very cheap) (+ 3 more voltmeters)3 more voltmeters)

    • Adapt our little DAQ programp g

    • No fundamental (architectural)

    h t DAQData Acquisition Systems, CERN Summerstudent Lecture 2008 12

    change to our DAQ

  • Read-out 160 Sensors

    • For a moment we (might) consider to• For a moment we (might) consider to buy 52 USB hubs, 160 Voltmeters

    • …but hopefully we abandon the idea very quickly, before we start cabling y q y, gthis!

    • Expensive cumbersome fragile• Expensive, cumbersome, fragile our data acquisition system is notscalable

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 13

  • Read-out with Buses

  • A Better DAQ for Many (temperature) Sensors(temperature) Sensors

    • Buy or build a compact multi port volt meter module

    19”multi-port volt-meter module, e.g. 16 inputs

    • Put many of these multi-port modules together in amodules together in a common chassis or crate

    • The modules need– Mechanical support

    7U VME Crate(a.k.a. “Subrack”)

    7U

    pp– Power– A standardized way to

    access their data (our measurement values)Backplane Connectors measurement values)

    • All this is provided by standards for (readout) electronics such as VME (IEEE

    Backplane Connectors(for power and data)

    VME Board Plugs into Backplane

    electronics such as VME (IEEE 1014)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 15

  • DAQ for 160 Sensors Using VME

    • Readout boards• Readout boardsin a VME-crate– mechanical

    standard for– electrical

    standard forstandard for power on the backplane

    – signal and protocol standard for communication on a bus

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 16

  • A Word on Mechanics and PizzasPizzas

    • The width and height of racks and• The width and height of racks and crates are measured in US units: inches (in, '') and U – 1 in = 25.4 mm– 1 U = 1.75 in = 44.45 mm

    • The width of a "standard" rack is 19 in.The width of a standard rack is 19 in. • The height of a crate (also sub-rack) is

    measured in UsR k t bl thi i ti l• Rack-mountable things, in particular computers, which are 1 U high are often called pizza-boxes 49 U

    • At least in Europe, the depth is measured in mm

    • Gory details can be found in IEEE

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 17

    Gory details can be found in IEEE 1101.x (VME mechanics standard)

  • Communication in a Crate: Buses• A bus connects two or more devices and allows

    them to communicateTh b i h d b t ll d i th b• The bus is shared between all devices on the bus arbitration is required

    • Devices can be masters or slaves (some can beDevices can be masters or slaves (some can be both)

    • Devices can be uniquely identified ("addressed") on the busthe bus

    Master Slave MasterSlave

    Device 1 Device 2 Device 4Device 3Device 2 Device 4Device 1 Device 3

    Data LinesData Lines

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 18Select LineSelect Line

  • Buses

    • Famous examples: PCI USB VME SCSI• Famous examples: PCI, USB, VME, SCSI– older standards: CAMAC, ISA– upcoming: ATCAp g– many more: FireWire, I2C, Profibus, etc…

    • Buses can be– local: PCI– external peripherals: USB

    in crates: VME compactPCI ATCA– in crates: VME, compactPCI, ATCA– long distance: CAN, Profibus

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 19

  • The VME Bus• In a VME crate we can find

    th i t f d lthree main types of modules– The controller which monitors

    and arbitrates the bus

    0x000-0x1ff

    0x200-0x2ffand arbitrates the bus

    – Masters read data from and write data to slaves

    0x300-0x3ff

    0x400-0x4ff

    0x500-0x5ff– Slaves send data to and receive

    data from masters• Addressing of modules

    0 500 0 5

    0x600-0x6ff

    • Addressing of modules– In VME each module occupies a

    part of a (flat) range of addresses (24 bit to 32 bit)

    – Address range of modules is hardwired (conflicts!)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 20

    hardwired (conflicts!)

  • VME protocol 1) Arbitrationp )

    A bit ti M t t *) BR# C t ll b• Arbitration: Master asserts*) BR#, Controller answers by asserting BG#

    • If there are several masters requesting at the same• If there are several masters requesting at the same time the one physically closest to the controller wins

    • The winning master drives BBSY* high to indicate that• The winning master drives BBSY high to indicate that the bus is now in use

    Pictures from http://www interfacebus com

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 21

    Pictures from http://www.interfacebus.com*) assert means driving the line to logical 0 (VME control lines are inverted or active-low)

  • VME protocol 2) Write transferp )• The Master writes data

    and address to the data / respectively da a / espec e ydata bus

    • It asserts DS* and AS* to signal that the data

    d dd lidand address are valid• The slave reads and

    acknowledges by asserting DTACKasserting DTACK

    • The master releases DS*, AS* and BSBSY*, the cycle is completethe cycle is complete

    • Note: there is no clock! The slave can respond whenever it wants. VME is an asynchronous bus

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 22

  • Speed Considerationsp

    • Theoretically 16 MB/s can be• Theoretically ~ 16 MB/s can be achieved

    i th d t b t b f ll 32 bit– assuming the databus to be full 32-bit wideth t h t li i h b– the master never has to relinquish bus master ship

    f i• Better performance by using block-transfers

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 23

  • VME protocol 3) Block transferp )• After an address

    l l ( tcycle several (up to 256) data cycles are performedp

    • The slave is supposed to increment the address counteraddress counter

    • The additional delays for asserting and acknowledging the• Block transfers are essential• Block transfers are essential acknowledging the address are removed

    • Performance goes

    • Block transfers are essential for Direct Memory Access (DMA) M f b

    • Block transfers are essential for Direct Memory Access (DMA) M f b

    gup to 40 MB/s

    • In PCI this is referred to as "burst-transfer"

    • More performance can be gained by using the address bus also for data (VME64)

    • More performance can be gained by using the address bus also for data (VME64)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 24

    to as burst transfer

  • Advantages of busesg

    R l ti l i l t i l t• Relatively simple to implement– Constant number of lines– Each device implements the same

    interface• Easy to add new devices

    t l i l i f ti f th b b– topological information of the bus can be used for automagically choosing

    dd f b d i thi i h t laddresses for bus devices: this is what plug and play is all about.

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 25

  • Buses for DAQ at LHC?

    • A bus is shared between all devices (each new• A bus is shared between all devices (each new active device slows everybody down)– Bus-width can only be increased up to a certain point (128

    bit for PC-system bus)– Bus-frequency (number of elementary operations per

    second) can be increased, but decreases the physical )bus-length

    • Number of devices and physical bus-length is limited (scalability!)limited (scalability!)– For synchronous high-speed buses, physical length is

    correlated with the number of devices (e.g. PCI)i l b h l f l d d dd li– Typical buses have a lot of control, data and address lines

    (look at a SCSI or ATA cable)• Buses are typically useful for systems < 1 GB/s

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 26

    yp y y /

  • Network based DAQ• In large (HEP) experiments we typically have g ( ) p yp y

    thousands of devices to read, which are sometimes very far from each other N t k t h l l th l bilit i f• Network technology solves the scalability issues of buses– In a network devices are equal ("peers")q ( p )– In a network devices communicate directly with each

    other• no arbitration necessaryno arbitration necessary• bandwidth guaranteed

    – data and control use the same pathh f li ( i t diti l Eth t l t )• much fewer lines (e.g. in traditional Ethernet only two)

    – At the signaling level buses tend to use parallel copper lines. Network technologies can be also optical, wire-less

    d t i ll (diff ti l) i l

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 27

    and are typically (differential) serial

  • Network Technologiesg• Examples: p

    – The telephone network – Ethernet (IEEE 802.3)

    ATM (the backbone for GSM cell phones)– ATM (the backbone for GSM cell-phones)– Infiniband– Myrinet– many, many more

    • Note: some of these have "bus"-features as well (Ethernet Infiniband)(Ethernet, Infiniband)

    • Network technologies are sometimes functionally groupedgrouped– Cluster interconnect (Myrinet, Infiniband) 15 m – Local area network (Ethernet), 100 m to 10 km

    Wid t k (ATM SONET) 50 k

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 28

    – Wide area network (ATM, SONET) > 50 km

  • Connecting Devices in a NetworkNetwork

    • On an network a device is identifed by a• On an network a device is identifed by a network address– eg: our phone-number, the MAC address of your g p y

    computer• Devices communicate by sending

    messages (frames packets) to each othermessages (frames, packets) to each other• Some establish a connection lilke the

    telephone network some simply sendtelephone network, some simply send messages

    • Modern networks are switched with point-to-ppoint links– circuit switching, packet switching

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 29

  • Switched Networks

    • In a switched network each node is• In a switched network each node is connected either to another node or to a switchto a switch

    • Switches can be connected to other switches

    • A path from one node to anotherA path from one node to another leads through 1 or more switches (this number is sometimes referred to as thenumber is sometimes referred to as the number of "hops" )

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 30

  • A Switched Network

    • While 2 can send data to 1

    43

    and 4, 3 can send at full

    41

    2speed to 5

    • 2 can distribute 5the share the bandwidth between 1 and 4 as needed

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 31

  • Switches

    • Switches are the key to good network• Switches are the key to good network performance

    • They must move frames reliably and as fast as possible between nodes

    • They face two problems– Finding the right path for a frameFinding the right path for a frame– Handling congestion (two or more frames

    want to go to the same destination at thewant to go to the same destination at the same time)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 32

  • Ethernet

    • Cheap• Cheap• Unreliable – but in practice

    transmission errors are very low• Available in many different speeds y p

    and physical media• We use IP or TCP/IP over Ethernet• We use IP or TCP/IP over Ethernet• By far the most widely used local area

    t k t h l ( t tinetwork technology (even starting on the WAN)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 33

  • IP Packets over EthernetEthernet Header

    ac e s o e e e

    IP Header

    UDP HeaderUDP Header

    Data

    0 … 32 bits

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 34

  • Data Acquisition for a LargeData Acquisition for a Large Experimentp

  • Moving on to Bigger Things…g gg g

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 36

    The CMS Detector

  • Moving on to Bigger Things…g gg g

    • 15 million detector channels• @ 40 MHz

    15 * 1 000 000 * 40 * 1 000 000 b t• = ~15 * 1,000,000 * 40 * 1,000,000 bytes

    • = ~ 600 TB/sec

    ??Data Acquisition Systems, CERN Summerstudent Lecture 2008 37

  • Designing a DAQ System for L HEP E i ta Large HEP Experiment

    • What defines "large"?• What defines large ?– The number of channels: for LHC experiments

    O(107) channelsO(10 ) channels• a (digitized) channel can be between 1 and 14 bits

    – The rate: for LHC experiments everything happens at 40.08 MHz, the LHC bunch crossing frequency (This corresponds to 24.9500998 ns or 25 ns among friends))

    • HEP experiments usually consist of many different sub-detectors: tracking, gcalorimetry, particle-ID, muon-detectors

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 38

  • First Questions

    Can e or do e ant to sa e all the data?• Can we or do we want to save all the data?• How do we select the data• Is continuous read-out needed, i.e. an

    experiment in a collider? Or are there idle periods mixed with periods with many events – this is typically the case for fixed-target experiments

    • How do we make sure that the values fromHow do we make sure that the values from the many different channels refer to the same original event (collision)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 39

    same original event (collision)

  • What Do We Need to Read O t D t t ( f ll )?Out a Detector (successfully)?

    A l ti h i (“t i ”)• A selection mechanism (“trigger”)• Electronic readout of the sensors of the

    detectors (“front-end electronics”) • A system to keep all those things in sync y p g y

    (“clock”)• A system to collect the selected dataA system to collect the selected data

    (“DAQ”)• A Control System to configure control• A Control System to configure, control

    and monitor the entire DAQ

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 40

  • TriggerTrigger• No (affordable) DAQ system

    could read out O(107) Black magic happening here( )

    channels at 40 MHz 400 TBit/s to read out – even assuming binary channels!g y

    • What’s worse: most of these millions of events per second are totally uninteresting: oneare totally uninteresting: one Higgs event every 0.02 secondsA fi t l l t i (L l 1• A first level trigger (Level-1, L1) must somehow select the more interesting events and t ll hi h t d ltell us which ones to deal with any further

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 41

  • Inside the Box: How does a Level 1trigger work?Level-1trigger work?

    • Millions of channels : try to work as much• Millions of channels : try to work as much as possible with “local” information– Keeps number of interconnections low– Keeps number of interconnections low

    • Must be fast: look for “simple” signaturesKeep the good ones kill the bad ones– Keep the good ones, kill the bad ones

    – Robust, can be implemented in hardware (fast)• Design principle:• Design principle:

    – fast: to keep buffer sizes under control– every 25 nanoseconds (ns) a new event: have toevery 25 nanoseconds (ns) a new event: have to

    decide within a few microseconds (μs): trigger-latency

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 42

  • Challenges for the L1 at LHCg• N (channels) ~ O(107); ≈20 interactions every 25 ns

    need huge number of connections– need huge number of connections• Need to synchronize detector elements to (better

    than) 25 ns) 5• In some cases: detector signal/time of flight > 25 ns

    – integrate more than one bunch crossing's worth of i f tiinformation

    – need to identify bunch crossing...• It's On-Line (cannot go back and recover events)It s On Line (cannot go back and recover events)

    – need to monitor selection - need very good control over all conditions

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 43

  • Know Your Enemy: pp Collisions at 14 TeV at 1034 cm-2s-1TeV at 1034 cm 2s 1

    • σ(pp) = 70 mb --> >7 x 108 / (!)108 /s (!)

    • In ATLAS and CMS*20 i bi20 min biasevents will overlap

    • H→ZZZ →μμH→ 4 muons:

    Reconstructed tracks with pt > 25 GeV

    A d thiH→ 4 muons:the cleanest(“golden”)i t

    And this (not the H though…)

    repeats every 25 nssignature repeats every 25 ns…

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 44*)LHCb @2x1033 cm-2-1 isn’t much nicer and in Alice (PbPb) it will be even worse

  • Mother Nature is a … Kind Woman After AllMother Nature is a … Kind Woman After All• pp collisions produce mainly hadrons with

    transverse momentum “pt” ~1 GeVtransverse momentum pt” 1 GeV• Interesting physics (old and new) has

    particles (leptons and hadrons) with large pt:pt– W→eν: M(W)=80 GeV/c2; pt(e) ~ 30-40 GeV– H(120 GeV)→γγ: pt(γ) ~ 50-60 GeV– B→μD*+ν pt(μ) ~ 1.4 GeV

    ptp

    • Impose high thresholds on the pt of particles – Implies distinguishing particle types; possible

    for electrons, muons and “jets”; beyond that, need complex algorithmsneed complex algorithms

    • Conclusion: in the L1 trigger we need to watch out for high transverse momentum electrons, jets or muonselectrons, jets or muons

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 45

  • How to defeat minimum bias: transverse momentum ptransverse momentum pt

    Use prompt data (calorimetry MUON System

    µν

    p p ( yand muons) to identify: High pt electron, muon, jets, missing E

    MUON System Segment and track finding

    missing ET

    nφ η

    pCALORIMETERs Cluster finding and energy deposition evaluationdeposition evaluation

    New data every 25 ns

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 46

    New data every 25 ns Decision latency ~ µs

  • Distributing the L1 Triggerg gg• Assuming now that a

    i b t ll f Gl b l T i 1Local level-1 trigger

    magic box tells for each bunch crossing (clock-tick) yes or no

    Global Trigger 1gg

    Primitive e, γ, jets, µ

    ≈ 2-3 µs latency(c oc c ) yes o o

    – Triggering is not for philosophers –“perhaps” is not an

    latency loop

    perhaps is not an option

    • This decision has to b b ht f hbe brought for each crossing to all the detector front-end

    Front-End Digitizer

    Pipeline delay ( ≈ 3 µs)

    TriggerPrimitive

    Generator

    electronics elements so that they can send of their data or

    Accept/Reject LV-1

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 47

    send of their data or discard it

  • Clock Distribution and SynchronisationSynchronisation

    • An event is a snapshot of th l f ll d t t

    Plus:the values of all detector front-end electronics elements, which have their value caused by the same

    Trigger decisionBunch cross ID

    40 MHz

    value caused by the same collision

    • A common clock signal must be provided to all pdetector elements– Since the c is constant, the

    detectors are large and the electronics is fast thethe electronics is fast, the detector elements must becarefully time-aligned

    • Common system for all LHC yexperiments TTC based on radiation-hard opto-electronics

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 48

  • Bird’s-Eye View on (front-end) Electronicst t

    AmplifierFilter

    Detector

    Filter

    Shaper

    Range compressionclock (TTC) Sampling

    Digital filterZero suppression

    All thi l i dBuffer

    Feature extraction

    All this explained in great detail by J. Christiansen

    Format & ReadoutBuffer

    Feature extractionthis week --> focus on the green arrow on

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 49to Data Acquisition System

    gbeyond

  • FEE & DAQ by electronics engineers

    FEE = Front End Electronics

    Example from LHCb

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 50

  • Data Acquisitionq

    • Event data are now digitized pre• Event-data are now digitized, pre-processed and tagged with a unique, monotonically increasing numbermonotonically increasing number

    • The event data are distributed over many read-out boards (“sources”)

    • For the next stage of selection, or evenFor the next stage of selection, or even simply to write it to tape we have to get the pieces of the event together:get the pieces of the event together: event building

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 51

  • Event Building

  • Event Buildingg

    To Trigger Algorithms

    E t B ild 3

    Event Builder 3

    Event Builder 3

    Data AcquisitionSwitch

    Event Builder 3

    Event Builder 3

    Event Builder 3

    1 Event fragments are received from 2 Event fragments are read out over a 3 Event builder assembles fragments4 Complete events are processed by triggerData Acquisition Systems, CERN Summerstudent Lecture 2008 531 received from detector front-end2 read out over a network to an event builder 3 assembles fragments into a complete event4 processed by trigger algorithms

  • Push-Based Event BuildingSwitch Buffer

    g

    Event Builder 1

    Event Builder 2

    Event Builder 1

    Data AcquisitionSwitch

    Event Builder 2

    “Send next event

    to EB1”“Send

    next event to EB2”

    ReadoutSupervisor

    1 Readout Supervisor tells readout boards 2 Readout boards do not buffer so switch 3 No feedback from Event Builders toData Acquisition Systems, CERN Summerstudent Lecture 2008 541 tells readout boards where events must be sent (round-robin) 2 not buffer, so switch must 3 Event Builders to Readout system

  • Congestiong

    1 3• "Bang" translates into

    random uncontrolled• "Bang" translates into

    random uncontrolled1 32 2 random, uncontrolled packet-loss• In Ethernet this is

    f i i

    random, uncontrolled packet-loss

    • In Ethernet this is f i iperfectly valid behavior

    and implemented by very cheap devices

    perfectly valid behavior and implemented by very cheap devicesy p

    • Higher Level protocols are supposed to handle the packet loss due to

    y p• Higher Level protocols

    are supposed to handle the packet loss due to

    Bang

    the packet loss due to lack of buffering

    • This problem comes from synchronized sources

    the packet loss due to lack of buffering

    • This problem comes from synchronized sourcessynchronized sources sending to the same destination at the same time

    synchronized sources sending to the same destination at the same time

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 55

    2 timetime

  • Overcoming Congestion:Queuing at the InputQueuing at the Input

    • Two frames destined• Two frames destined to the same destination arrive

    1 32 2

    destination arrive• While one is

    switched throughswitched through the other is waiting at the input portp p

    • When the output port is free the pqueued packet is sent

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 562

  • Pull-Based Event Buildingg

    “S dEve

    “Send mean event!”“Send mean event!”

    Event Builder 1nt

    B“Send meEvent Builder 2uild

    Data AcquisitionSwitch

    EB1 0

    an event!”

    1“Send me

    001Event Builder 3

    er

    1

    “Send next event

    to EB1”“Send

    next event to EB2”

    EB1: EB2:EB3:

    0 00

    1 11

    an event!”0 11

    0 01 “Send

    next event

    1 01

    1 Event Builders notify Readout Supervisor 2 Readout Supervisor ensures that data are 3 Readout system relies on feedbackto EB3”

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 571 Readout Supervisor of available capacity 2 ensures that data are sent only to nodes with available capacity 3 relies on feedback from Event Builders

  • Head of Line Blockingg

    Th f thi i th1 32 24

    • The reason for this is the First in First Out (FIFO) structure of the input

    Packet to node 4 must wait

    pbuffer

    • Queuing theory tells us* th t f d t ffieven though port to node 4 is freethat for random traffic (and infinitely many switch ports) the throughput of g pthe switch will go down to 58.6% that means on 100 MBit/s network the

    24

    100 MBit/s network the nodes will "see" effectively only ~ 58 MBit/s

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 58

    4 *) "Input Versus Output Queueing on a Space-Division Packet Switch"; Karol, M. et al. ; IEEE Trans. Comm., 35/12

  • Output QueuingOutput Queuing• In practice virtual p

    output queueing is used: at each input there is a queue for

    1 32 24

    there is a queue for n ports O(n2) queues must be managed

    • Assuming the buffers are large enough(!) such a switch willPacket to node 2 waits at output tosuch a switch will sustain random traffic at 100% nominal link l d

    port 2. Way to node 4 is free

    load

    24

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 59

  • AACL

    ALICE, ATLAS, CMS, LHCbALICE, ATLAS, CMS, LHCbDAQs in 4 slides

  • ALICE DAQCTP

    LTU LTUBUSY BUSY

    Rare/All

    L0, L1a, L2DDLLTU

    TTC

    LTU

    TTCL0, L1a, L2

    HLT FFEPFEP

    DDL

    H-RORC

    FERO FERO FERO FEROEvent

    Fragment 342 DDLs

    HLT Farm

    10 DDLs

    10 D-RORC

    144 DDLs416 D-RORC

    LDCLDC

    Sub-event

    LDCLoad Bal. LDC LDC10 HLT LDC

    E t B ildi N t k 2500 MB/

    194 Detector LDC

    GDC GDCGDCGDCEvent

    EDM

    DS DS

    Event Building Network 2500 MB/s

    50 GDC25 TDS 5 DSS

    File

    Storage Network 1250 MB/s PDS

    25 TDS

    T t h d t i L0 +

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 61TDS TDS

    •Two stage hardware trigger L0 + L1•High Level Trigger (HLT) on separate farm

  • ATLAS DAQATLAS DAQ ATLAS•L1 selects events at 100 kHz and defines100 kHz and defines regions of interest•L2 pulls data from the region of interest and processes the data in a farm of processorsfarm of processorsL2 accepts data at ~ 1 kHz1 kHz•Event Filter reads the entire detector (pull), processes the events in a farm and accepts at 100 Hz

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 626262

    100 Hz

  • CMS DAQCMS DAQ

    Congestion is handled by synchronizing the sources to send in discrete time-l t B l Shifti

    Collision rate 40 MHzL l 1 M i t i t

    No. of In-Out units 512R d t t k b d idth ≈ 1 T bit/

    slots: Barrel Shifting

    Level-1 Maximum trigger rate100 kHz

    Average event size ≈ 1 MbyteEvent Flow Control ≈ 106

    Readout network bandwidth ≈ 1 Terabit/s Event filter computing power ≈ 106 SI95Data production ≈ Tbyte/dayNo. of PC motherboards ≈ Thousands

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 63

    Mssg/s

  • LHCb DAQDetector

    VELO ST OT RICH ECal HCal MuonL0

    TFC S t

    L0 triggerLHC clock

    Readout (ECS

    )

    L0 Trigger

    Readout Readout Readout Readout Readout Readout

    FEElectronics

    FEElectronics

    FEElectronics

    FEElectronics

    FEElectronics

    FEElectronics

    FEElectronics

    System

    MEP Request

    Front-End

    Readout Board

    ol S

    yste

    m (Readout

    BoardReadout

    BoardReadout

    BoardReadout

    BoardReadout

    BoardReadout

    Board

    READOUT NETWORK

    q

    Event building

    men

    t Con

    tro

    40 GB/s

    80 MB/sSWITCH SWITCHSWITCH SWITCH SWITCH SWITCH SWITCH

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    CP

    Expe

    rim

    SWITCH

    C C C C

    80 MB/s

    HLT farmU U U U U U U U U U U U U U U U U U U U U U U U

    Event dataTiming and Fast Control Signals

    MON farm

    CPU

    CPU

    CPU

    CPU

    Average event size 40 kBAverage rate into farm 1 MHz

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 64

    Timing and Fast Control SignalsControl and Monitoring data

    Average rate into farm 1 MHzAverage rate to tape 2 kHz

  • LHC Experiments DAQLHC Experiments DAQppLevel-1 Event StoragekHz MByte MByte/s

    ATLAS 100 1 100ATLAS 100 1 100

    CMS 100 1 100

    LHCbLHCb 1000 0.04 80

    ALICE 1 25 1250

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 65

  • High Level TriggerComplicated Event structurewith hadronic jets (ATLAS) orsecondary vertices (LHCb) requiresecondary vertices (LHCb) requirefull detector information

    Methods and algorithms are the same as for offline reconstruction(Lecture “From raw data to physics”)

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 66

    ( ec u e o a da a o p ys cs )

  • On to tape...and the GRIDpNetworks, farms and data flows

    To regional centers622 Mbit/s

    To regional centers622 Mbit/s

    Events:Events:

    Remotecontrol rooms

    Remotecontrol rooms

    Controls:1 Gbit/sControls:1 Gbit/s Events:

    10 Gbit/sEvents:

    10 Gbit/s

    Controls:1 Gbit/s

    Controls:1 Gbit/s

    Raw Data:1000 Gbit/sRaw Data:1000 Gbit/s

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 67

  • Further Readingg• Buses • Conferences

    – VME: http://www.vita.com/– PCI

    http://www.pcisig.com/• Network and Protocols

    – IEEE Realtime– ICALEPCS– CHEP– IEEE NSS-MIC

    – Ethernet“Ethernet: The Definitive Guide”, O’Reilly, C. Spurgeon

    – TCP/IP“TCP/IP Illustrated” W R Stevens

    • Journals– IEEE Transactions on Nuclear

    Science, in particular the proceedings of the IEEE Realtime

    fTCP/IP Illustrated , W. R. Stevens – Protocols: RFCs

    www.ietf.orgin particular RFC1925 http://www.ietf.org/rfc/rfc1925.txt“Th 12 t ki t th ” i

    conferences– IEEE Transactions on

    Communications

    “The 12 networking truths” is required reading

    • Wikipedia (!!!) and references therein – for all computing related stuff this is usually excellentstuff this is usually excellent

    Data Acquisition Systems, CERN Summerstudent Lecture 2008 68


Recommended