SCT/Pixel TIM Functional Requirements

November 24, 2000

Draft 0.6 by John Lane

Abstract

This document is a preliminary draft of the requirements on the SCT/Pixel TTC Interface Module. Feedback is welcome.

Contents

Introduction

The SCT/Pixel Timing, Trigger and Control (TTC) system consists of the ATLAS standard TTC distribution system [ref. TTC_TDR] together with a custom TTC Interface Module (TIM) in each crate of Read-Out Drivers (RODs). In addition, an ATLAS standard Busy module returns the SCT/Pixel Busy signal to the Level-1 Central Trigger Processor (CTP).

The TIM distributes TTC signals to the RODs, and the clock to each ROD's back-of-crate (BOC) optocard. The essential model is described in another document [ref. TIM_overview].

This document describes the functional and interface requirements on the SCT/Pixel TIM. It should be consistent with the interface specification documents [ref. TIM_interfaces] and also the ROD Functional Requirements document [ref. SCT_ROD]. It inherits essential requirements set out in the SCT Off-Detector Electronics Requirements Document [ref. SCT_ODE].


Interface to ROD

A TIM interfaces to a crate of RODs via a custom backplane.

* Output to ROD

The TIM must distribute TTC-related signals to each ROD. The clock and control signals required are:

Class Signal Name
clock BC Bunch Crossing clock
fast command L1A Level-1 Accept
ECR Event Counter Reset
BCR Bunch Counter Reset
CAL Calibrate strobe
event ID L1ID Level-1 Accept Identifier
BCID Bunch Crossing Identifier
TTID Trigger Type Identifier

The clock is sent via the BOC. Fast commands are synchronous to a given BCID, ie they occur on a defined BC. The ROD receives the ATLAS-wide event ID for each trigger as serial streams.

Justification: These signals are received by each ROD via the backplane of the crate.

Signal Description and Justification
BC system clock for timing: it strobes the front-end detector signals, validates the command signals, and synchronizes the system to bunch crossings in the LHC machine
L1A trigger accept/reject decision for each bunch crossing: it should arrive at the front-end pipeline after a fixed latency on the correct bunch crossing to read out the event data
ECR resynchronization reset of L1ID event counters periodically, used as front-end reset; it should be transmitted whenever L1ID is reset before wrapping round, in order to retain L1ID integrity between the ROD and the front-end counters
BCR resynchronization reset of BCID pipeline counters each LHC orbit; it should be transmitted every orbit during LHC running, in order to retain BCID integrity between the ROD and the front-end counters
CAL test-pulse command a fixed latency before its L1A; during LHC running, the calibration sequence would be CAL in the long gap, followed by its L1A in the next short gap of the LHC cycle, in order to account for the front-end pipeline length
L1ID 24-bit trigger number for each L1A, used to tag event fragments; unique within the latency of the system, including the ROB level: defined by counting L1As since ECR
BCID 12-bit bunch-crossing number for each L1A, used to tag event fragments; corresponds to the BC at which the event occured: defined by counting BCs since BCR until L1A
TTID 10-bit trigger type for each L1A, used to control ROD readout: 8 bits from CTP + 2 bits reserved; may be used at the ROD level to select the same event coherently across the detector, eg CAL trigger or data collection in a stand-alone mode

In response to the fast commands, the ROD generates the control bit sequence of the front-end protocol appropriate to the module type: strips (SCT) or pixels.

For synchronization of event dataflow, the system uniquely identifies each event with two identifiers: L1ID and BCID; the ROD checks the values received from the front-end against those received from the TIM. The ROD sends the event ID on to its Read-Out Buffer (ROB); it is received as serial streams to minimize use of backplane pins.

Note: CAL is a slow command in the SCT front-end protocol, ie it is a long serial bit string that includes chip address.

* Front-end resets

The front-end readout chips require resets to be sent via the ROD. However, there is a distinction between resynchronization and reset of the front-end:
  1. resynchronization of L1ID and BCID by ECR and BCR
  2. reset of the front-end and reconfiguration of its registers
Front-End Reset (FER) is a generic command name for equivalent reset functions in SCT and Pixel. It is mapped onto ECR, so it should not be required as a separate TTC signal, although its function at the front-end is different. The TIM should be capable of sending a separate FER command if required by the front-end.

Justification: The front-end has no L1ID reset as such. FER is the Soft Reset command in the SCT front-end protocol, which also resets BCID, the pipeline and buffers, deleting data both stored and in transmission, in addition to the ECR function. If FER does not occur on BCID=0, there should be a BCR before the next L1A.

The Trigger/DAQ group will send ECR as a periodic reset; although the details are not yet finalized, the scheme is:

  1. a short period with no triggers (eg a few 100us), to flush the front-end buffers
  2. ECR is issued, marking the beginning of a possible reconfiguration period
  3. another short period of deadtime, during which Busy may be asserted for reconfiguration
  4. BCR is issued before triggers restart
Note that BCR is issued within each partition by its TTC source: if necessary, the TIM could hold Busy asserted until the next BCR, following the end of the last ROD_Busy after an ECR. The TIM should continue transmitting BCR while the ROD is Busy.

Note: If a ROD resets an individual front-end channel, event ID integrity across the detector is lost. The ROD has no L1ID counter but has L1ID offsets for error recovery.

* Busy from ROD

The TIM must receive and monitor the ROD_Busy signals.

Justification: Each ROD transmits its Busy signal via the backplane of the crate. Monitoring should indicate which ROD is going Busy and to what extent.

Note: Busy should be asserted after reset and during initialization.


Interface to BOC

A TIM interfaces to each BOC via a custom backplane.

* Clock distribution

The TIM must distribute the clock to each BOC. The characteristics of the clock must satisfy the BOC input requirements. The duty cycle tolerance should be +/- 2ns.

Justification: The BOC transmits the clock to the front-end and to its ROD. Jitter on the BOC should be sufficiently small for calibrating the timing, encoding the biphase mark and its subsequent decoding on the detector; both clock edges are used by the encoders.

Note: The BOC may well use a phase-locked loop.


Interface to TTC

A ROD crate interfaces to the ATLAS-wide TTC distribution system via a TIM.

* Input from TTC

The TIM must receive TTC signals from the TTC system. The clock and control signals required are:

Class Transmission Signal Description
clock biphase mark BC 40 MHz clock of programmable phase from the LHC
synchronous
command 		A-channel L1A trigger for the event bunch crossing, from the CTP
B-channel
short format 		ECR reset of L1ID counters periodically
BCR reset of BCID counters from the LHC ORBIT signal
CAL test-pulse command from the CTP Pre-Pulse Signal
event data local counter L1ID 24 bits from the receiver, prompt after L1A
BCID 12 bits from the receiver, prompt after L1A
asynchronous
data 		B-channel
long format 		TTID 8 bits from the CTP, queued with a latency of 1-10us after L1A

The latency of transmission is fixed except for the queued Trigger Type. The trigger is carried on the low-latency dedicated A-channel with zero deadtime. Transmission on the B-channel has additional latency and deadtime given by the frame size.

Justification: These are Level-1 signals distributed ATLAS-wide, and TIMs are the TTC destinations for the SCT/Pixel system.

Note: A TTC synchronous command occurs on a defined bunch crossing, which is achieved by a programmable timing adjustment in the TTC receiver (TTCrx). BCR timing is also controlled by the TTC source (TTCvi). Asynchronous transmission is undefined with respect to the LHC cycle.

* Latency of TTC commands

The TIM should be capable of transmitting all fast commands received from the TTC system with the same programmable latency. The L1A latency due to TIM, after the TTC receiver, must be less than 2 BC.

Justification: These are timing signals that occur on a defined bunch crossing. The data is lost if the trigger arrives too late at the front-end pipeline, so the TIM should not exceed its latency budget.

Note: The ATLAS standard TTC receiver has programmable latency.


Interface to CTP

A TIM interfaces to the CTP via a standard Busy module.

* Busy to CTP

The ROD_Crate_Busy signals must be combined into an SCT_Busy or Pixel_Busy signal that is sent to the CTP. It should be done by a logical OR using a programmable mask, and be monitored.

Justification: The global ROD_Busy signal requests that the CTP issues no further L1A triggers in order to prevent data loss in the SCT/Pixel system.

Note: This can be carried out by a standard Busy module.

* Busy from crate

The individual ROD_Busy signals within a crate must be combined into a ROD_Crate_Busy signal. It should be done by a logical OR using a programmable mask, and be monitored.

Justification: The ROD_Crate_Busy signals are sent to the SCT/Pixel Busy module in order to prevent data loss in a ROD crate.

Note: This can be carried out by the TIM or a standard Busy module.


Interface to local trigger

A TIM interfaces to local trigger inputs in order to allow stand-alone running.

* Command deadtime

The TIM must introduce deadtime to respect the front-end protocol.

Justification: The front-end protocol is a serial bit stream of command strings: one command sent at a time, each taking several clock periods.

Note: The command strings for SCT and Pixel may be of different length.

* Trigger latency

The TIM must be capable of transmitting external triggers and calibration triggers with a programmable latency delay.

Justification: The front-end data is pipelined with a fixed latency, after which the trigger should arrive immediately at the pipeline.

Note: The latency is undefined for internal triggers except for calibration triggers.

* Trigger phase timing

The TIM must synchronize the local trigger signal to the clock. The timing of their relative phase should be measurable.

Justification: Local triggers may occur at any time with respect to the clock. The relative phase is used in studies of efficiency against timing.

Note: The relative phase can be measured by a TDC module.


Interface to local processor

A TIM interfaces to a local processor via a standard backplane.

* VME interface

The TIM must implement a VME slave interface to provide read/write access to its registers and control bits.

Justification: This is an ATLAS standard interface for ROD crates.

* Configuration and monitoring

The TIM must be configured and may be monitored by the local processor. Configuration means setting control registers and monitoring means reading status registers.

Justification: The local processor should have control of modes of operation and their parameters, and be able to check the status of operation and for errors.

* Command execution

The TIM must be capable of executing commands, including preloaded command sequences, in response to commands issued by the local processor.

Justification: This allows stand-alone running and testing by users.

* Interrupt generation

The TIM must be capable of issuing a VME interrupt when a fatal error condition occurs or a trigger is issued.

Justification: The local processor should be notified immediately of fatal errors so that it can initiate error recovery or alert a higher-level authority. It should also be notified of events for local readout of data.


Transmission of Clock and Control

A TIM transmits clock and control signals to the BOC and the ROD.

* Clock source

The TIM must operate with any one of three 40 MHz clock sources: The clock source should be selectable by a register.

Justification: This enables a choice of running with ATLAS, stand-alone operation and diagnostic testing, without cabling operations or any other manual intervention.

* Clock stability and jitter

The long-term stability (against drifts relative to the LHC phase) and short-term jitter in the phase of the clock signal transmitted to each BOC should be less than 0.5ns RMS combined.

Justification: At the front-end, clock timing with respect to particle passage should be good to 1ns in order to minimize the effects of time-walk in detector signals.

Note: Clock stability is temperature dependent: allow 30 minutes after power up for stabilization.

* Clock phase delay

The phase delay of the clock signal must be programmable. The TIM must satisfy the setup and hold requirements, at each ROD slot, for the backplane signals with respect to the clock. The clock should arrive at each slot at the same time.

Justification: The clock signal strobes the front-end detector signals and is a timing marker that validates the command signals, so these timing relationships should be adjustable.

Note: The phase delay of the clock signal sent to the front-end is adjusted channel-by-channel in the Bi-Phase Mark (BPM) encoder chips on BOC.

* Commands required

The TIM must be capable of transmitting the full set of fast commands required by the front-end. Commands should be broadcast to all RODs without introducing deadtime, except to respect the front-end protocol.

Justification: These are the timing signals for control of the front-end readout chips. The TIM is not required to support command destination addresses or slow control commands.

* Origin of commands

The TIM must be capable of transmitting commands that are received from the TTC system or from the local processor. The TIM should also be capable of generating commands internally under control of the local processor. Sources of stand-alone commands should include:

Justification: This enables running with ATLAS, stand-alone operation and calibration, and diagnostic testing.

* Latency of fast commands

The TIM must transmit all fast commands with a fixed latency, ie it should not vary from one command to the next of the same type and origin.

Justification: These are timing signals that occur on a defined bunch crossing.

Note: The front-end readout chips see a different latency for command strings of different length. The ROD should be capable of applying an offset to the front-end BCID: it is given by the number of clock periods between arrival at its counter of BCR and L1A, and is offset from the ROD value because the L1A command string is more than 1 bit long. BCR should be sent early because its command string is more than 1 bit and the L1A latency has to be minimized.

* Queuing of event ID

The TIM must queue the event IDs before serial distribution to the ROD. The FIFO buffer sizes on TIM and ROD should be large enough to not need flow control of the serial streams.

Justification: There should be no loss of event IDs in the case of rapid triggers. The ROD and the TTC system have no flow control of the event identifier.

Note: Two serial streams (one for L1ID and BCID, one for TTID) reduces the queuing latency on TIM because the Trigger Type is also queued in the TTC system.


Additional requirements

* Operating environment

Justification: The TIM is in ROD crates in the Underground Service Area USA15.


References 

On the Web via:  ATLAS -> Inner Detector -> SCT -> Off Detector

SCT_ODE        Off Detector -> Requirements Document
SCT_ROD        Off Detector -> ROD -> Functional Requirements Document
TIM_overview   http://www.hep.ucl.ac.uk/~jbl/SCT/TIM_overview.html
TIM_interfaces http://www.hep.ucl.ac.uk/~jbl/SCT/TIM_interface_BOC.html
               http://www.hep.ucl.ac.uk/~jbl/SCT/TIM_interface_ROD.html
               http://www.hep.ucl.ac.uk/~jbl/SCT/TIM_interface_RCC.html
TTC_TDR        http://www.cern.ch/Atlas/GROUPS/DAQTRIG/TDR/V1REV1/L1TDR_TTC.*

           .* = .pdf or .ps

History:

0.1  3Nov98 JBL First draft
0.2 10Nov98 JBL Add Front-end resets (FEReset maps onto ECReset)
0.3 26Nov98 JBL Clock phase delay is controlled by BPM chips
0.4 15Jul99 JBL Add Interface to BOC, and minor changes
0.5 26Jul00 JBL Add Interface to TTC and local trigger, Justification text,
                Origin of commands - sources
0.6 24Nov00 JBL Add Additional requirements, Interrupt generation;
                Justification text; comments by J.Hill; re-title & pixel too
    22Jun04 JBL Remove broken off-detector link
Last update: 22 June 2004 by John Lane (UCL) email: jbl@hep.ucl.ac.uk 
http://www.hep.ucl.ac.uk/~jbl/SCT/TIM_requirements.html