T/DAQ Workshop

T/DAQ Workshop

Detector Interface Session

SCT-Pixels

J.C.Hill

Cambridge University

21 October 1998

SCT/Pixel RODs

Schedule

Design requirements for SCT and Pixels are very similar, so a common ROD is being designed at UCI/Wisconsin/LBL

Full details at URL:

http://positron.ps.uci.edu/~rodatlas/rodwork.html

Pre-prototype ROD ("ROD99")

available Spring 1999

intended to handle 24 SCT or 48 Pixel modules

9U VME module (customised P3 connector and backplane)

Back of Crate (BOC) card for optical interfaces (to Front Ends and ROBs)

~16-18 RODs per crate (depending on other requirements of ROD crate)

interface to TTC via distribution module (aka MCCC). Distributes TTC commands via custom backplane to RODs. RODs transmit Clock and Control to FEs

ROC communicates via VME backplane with RODs

Prototype ROD

expected Spring 2000

final channel count (aim is to handle 48 SCT or 96 Pixel modules if possible)

other functionality as in final ROD in light of lessons learnt with ROD99

Performance Readiness Review

Autumn/Winter 2000

if all is well, start final ROD production

ROD production expected to be completed in Autumn 2002

ROD tasks and requirements

Calibration

event created by CalStrobe command to Front end ( + L1Accept )

module data not distinguishable from normal event

use Trigger Type from TTC to flag ROD (may need >1 type, as not all channels calibrated on every event)

calibration needs of SCT and Pixel are very different:

SCT – typically scan one or two parameters and accumulate occupancy histograms. Limited extra processing on ROD.

Pixels – much more demanding – may want

crude pulse-height measurement for each

pixel. ROD may need to do significant

processing on the measurements.

Unlikely events will routinely go to ROB or

ROC, though may need to on occasion. Histograms/processed data to ROC.

May wish to calibrate in beam gaps –

though it may prove impracticable

Need to have capability for calibration runs – whether these will be needed between physics runs or only in setup periods is unknown

Monitoring

"spy mode" on event data via ROC

histogramming in ROD (eg. occupancy)

for debugging – need to be able handle all events via ROC (at up to ~1kHz)

keep track of chip error counts, missing events, other protocol errors

ROD might be allowed to disable a module automatically if error rate too high – but must flag this (either in data and/or to status display).

need monitoring also in Event Builder so can use track segments.

Control

initialisation of Front Ends (and selves) when instructed

details depend on database information and/or explicit Run Control commands

possibly disable a module if appears faulty (cf. monitoring)

synchronise events from modules – handle missing events

also need control of optolinks, power and bias supplies etc. from DCS.

Run Control

overlaps with previous section

Start of Run: initialise RODs, download database, tell ROD to initialise FEs

End of Run: organise update of databases, save histograms

During Run: handle dead ROD (eg. reset or end run early)

Timing

ROD will determine relative timing of detector modules. Mechanism not determined – may involve TDC on ROD itself or on BOC card.

Databases

ROD needs access to configuration database to:

Initialise Front Ends

Initialise own inputs from FEs (enable/disable)

Initialise monitoring (eg. ignore channels)

Update database at End of Run (revised configuration) – probably via ROC

ROD needs access to calibration database to:

Know which channels to pulse and pulse size

Load threshold information into DACs

no need for RODs to access metrology database

code versions for ROD and ROC need to be in a database

Event Builder will need access to metrology information as well as configuration and calibration databases for eg. track fitting

If tools currently in development for Back end could be used for handling databases by RODs/ROCs, Event Builder and offline, this could be very attractive.

Errors

Inform Run Control (status display may show error counts?)

Also flag ROB and ROC

In some cases, might reset appropriate FEs, but this is probably in light of experience and must have ability to override (eg. if reset rate excessive, want to debug the problem).

Special Triggers

Calibration triggers – possibly in "beam gap" (see earlier). More likely as separate calibration runs ( could be at start or end of physics runs – depends on time taken).

Random triggers at low level – could use to study detector behaviour. If envisaged as "long deadtime" events, could use as calibration triggers.

Event format

Minor discrepancies in documents, but basically appears OK. Need to see final confirmed version before formal agreement

Partitioning

16 partitions probably more than we could handle in practice. However, total number of ROD crates will be 5-10 in SCT, 2-5 in Pixels (depending on number of modules per ROD), so >4 partitions might be useful in both SCT and Pixel.

Test Beam 1999-2004

1999 similar to previous years – 2-3 periods to test out modules in preparation for PRR. Possibly a joint run with TRT/SCT/Pixels, but maybe outside test beam

2000+ - further module testing to ~2002, moving towards ATLAS trigger rates. Need for ATLAS T/DAQ increases over years.

In parallel, we will have "system tests" with significant number of modules in "final" ATLAS physical arrangement – this will start next month with prototype Low Voltage supplies, cabling etc. and will utilise ATLAS-style equipment as and when it is available. In particular, RODs will be used as they become available.