19Nov1998 Page 1

1
ATLAS TRIGGER/DAQROBs
Rationale
Context
Current work
Issues
Main institutes
CERN, MANNHEIM, NIKHEF,RHUL, SACLAY, UCL
2
Rationale

• The ReadOut Buffer (ROB) is a key component in
  the current ATLAS trigger/DAQ strategy
• RoI concept ? only a subset of main readout data
  needs to go to Level-2 processors
• Full data sits in ROBs until event is accepted or
  rejected at Level-2
• The ROB is the first common element in the
  readout chain
• Demanding performance

3
ROB rates

• Large asymmetry between input output
  event-fragment rates and bandwidths
• Input from ROLs _at_ 100MB/s (100kHz of 1kB
  fragments)
• Output to Level-2 processors (RoI data) _at_ 10MB/s
• Output to Event Builder _at_ 1MB/s
• (Assumed average event latency in the ROB 1ms)

4
ROB context
Run Control
Monitoring Status system
monitoring /status requests
RC requests
LVL1 accepted event data
monitoring data, errors, status
RC responses
RODs
RoI data
ROB busy (XOFF)
ROB
RoI requests
LVL2 system
LVL2 decisions
EB-requested event data
EB release requests
Level-1 control
EB data requests
Event Builder
5
Requirements

• URD for ROB ( ROB-in), June, 1996
• (http//www.cern.ch/HIS/rob/)

• Sub-detector data input
• Level-2 trigger
• Level-3 (obsolete term)
• Run control

• TTC
• Error handling
• Global system
• Physical constraints

• Revision planned for Dec 1999
• Unofficial TDAQ document - future requirements
  documentation to be discussed

6
Current work

• ROB studies in the Level-2 Pilot Project
• (http//www.nikhef.nl/pub/experiments/atlas/daq/RO
  B.html)
• prototypes for vertical slice tests
• study of options for ROB Complex
• DAQ Prototype -1
• (http//atddoc.cern.ch/Atlas/)
• demonstrate COTS approach (where appropriate)
• implement required functionality

7
ROB prototyping model
ROB-controller
ROB-out(s)
Level-1 accepted data
Network to Level-2
EBIF
Event Builder
ROB-in(s)
8
ROB-in design approach
Buffer manager
Level-1 accepted detector data
Messages
Input fifo
Interface to other ROB components
Buffer memory logic
Local comms
100 MB/s
selected data
10 MB/s
9
ROB-in development

• Mainline in-house variants (i960 PCI)
• RHUL/UCL ROB-in RD (DAQ-1 Level-2)
• Saclay ROBIN (Level-2)
• SHARC-based alternative (DSP links)
• NIKHEF CRUSH (Level-2)
• Commercial FPGA board (FPGA PCI)
• Silicon Software/Mannheim microEnable (Level-2)
• Commercial PMC board (PowerPC PCI)
• CES MFCC (DAQ-1)

10
ROB-in RD (RHUL/UCL)
11
ROBIN (Saclay)
12
CRUSH (NIKHEF)
13
microEnable(SiliconSoftware/Mannheim)
14
MFCC (CES)
PCI bus
PPC bus _at_ 66 MHz
Electrical Adaptor
Front-End FPGA
PCI bridge (CES FPGA)
64
Electrical Adaptation
64
Optional 512 Kbytes SSRAM buffer
System SDRAM 4 or 16 Mbytes
PowerPC 603ev or Arthur
PN4
Flash EPROM 2 or 4 Mbytes
CPLD SDRAM CTL glue logic
15
DAQ high-level design
16
DAQ front-end crate
17
Some issues

• TTC interaction does ROB need direct TTC
  connection? E.g. for bcid checking
• XOFF, LVL1 interaction How should full ROB
  buffers be handled? Back-pressure or direct BUSY
  to LVL1?
• XOFF timing How rapidly does a ROD need to
  respond to XOFF?
• timeouts should a ROB implement any special
  timeouts for e.g. front-end data not arriving or
  events not being released?

18
Some more issues

• byte order should a standard byte order be
  defined for ROD-ROB data?
• event types / monitoring what event types need
  to be recognised by a ROB? What kind of
  monitoring will be needed at the ROB level?
• ROB grouping / pre-processing is there any
  advantage to be gained from grouping ROBs, or
  from pre-processing data in the ROBs?
• in-house v. COTS v. semi-COTS what is the true
  cost of ownership for different ROB options?

19
Summary

• Healthy ROB-in development activity
• Programme of studies underway to explore the
  possibilities for a ROB Complex
• Prototyping well underway implementing ROB
  functionality with COTS (or semi-COTS) items
• Issues being highlighted for common discussion
• Conclusions from current work to be documented
  together for Technical Proposal at the end of 1999