BOC_model3.html @15:18 on 9-Feb-00

BOC Essential Model

<Maurice Goodrick> (University of Cambridge, Cavendish Labs)

Notes and Conventions

Links within the document end with a colon, such as Introduction:

Status

This document is a preliminary and incomplete draft of the Essential Model of the SCT BOC Module and its interfaces. Feedback is welcome.

Contents

• Introduction:
• Context:
• Interfaces:
• Realisation:

Introduction

Function:

The BOC (or Back Of Crate) module is a component of the Atlas Silicon Central Tracker - Off Detector Electronics: it is the primary data and control interface between the modules (both Strip and Pixel, and in both the Barrel and the End-Caps). As such, it performs the following core functions:

• It receives the optical data packets from the detector modules via the fibre ribbons, converts them to electrical form, and passes them to the ROD (Read Out Driver) modules.
• It takes the electrical control signals form the ROD, converts them to Bi-Phase Mark encoded optical signals, and dispatches these down the clock and control fibres to the detector modules.
• It takes the data stream from the ROD in parallel form, and provides the S-Link path via the ROB (Read Out Buffer) to the DAQ.

A number of related and ancillary tasks are also performed, such as:

• the reception and regeneration of the clock signal as provided by the TIM module
• timing comparison, threshold adjustment, and clock synchronisation for the received optical signals
• masking, timing and laser current adjustment functions for the transmitted control signals, and other operations supported by the BPM chip.
• provision of the required laser safety interlocks

General:

The format will be a single width 9U VME64 transition module of depth 240mm.

Each ROD in the crate will have a BOC sitting behind it in the transition-module (or "back-of-crate") location.

BOC will have no connection to P1/J1, and will have no VME functionality.

All control operations on BOC are achieved through its partner ROD using the Set-Up Bus

Variants:

A version is planned that matches the needs of the Pixel modules: this may imply different numbers of data and control streams, and a de-multiplexing of the 80MHz data streams into pairs of 40 MHz streams.

Prototypes may have different formats (in particular, reduced numbers of streams) according to the available components. There may also be differences in function.

Context

A complete description of Atlas SCT Off Detector Electronics is available at Atlas_Off-Detector>>

Interfaces

Outline:

Signal levels:

TTL signals originating on BOC are from drivers running from a +3.3V supply.

TTL signals received by BOC should preferably be from drivers running from a +3.3V supply.

PECL5V signals originating on BOC come from ECL drivers running on a +5V supply: they are balanced, and have pull-down resistors (but no termination resistors) on-board.

PECL5V signals received by BOC should come from ECL drivers running on a +5V supply: they should be balanced. They are terminated on BOC, but have no pull-down resistors.

BOC <> Detector Module

• > Clock and Control Fibres: MT12 connectors on the 12-way fibre ribbons plug straight into 12 stream VCSEL arrays. These connections will be at the back of each BOC, allowing access from the cabling space of the rack. A total of 48 such fibres will be served by each BOC, grouped as 4 ribbons. BOC0 uses 4 stream devices (VCSELs and BPMs), and, therefore, interfaces to MT4 connectors and 4-way fibres.
• < Data Fibres: MT12 connectors on 12-way ribbon fibres plug straight into 12 stream PIN diode arrays. These connections will be at the back of each BOC, allowing access from the cabling space of the rack. A total of 96 such fibres will be served by each BOC, grouped as 8 ribbons. For data fibres, BOC0 uses the same 12-stream components.

BOC <> TIM

• < Clock signal: an individual copy of the clock originating from the TIM module residing in the crate, routed via the crate backplane. Thus the TIM sources some 16 identical copies of this clock signal. This signal should be carried on a balanced, impedance-matched pair of conductors on the backplane, with matching termination on the BOC. The signal level should be a balanced PECL5V signal.

BOC <> LV_PSU

Laser Interlock: no appropriate way of organising a useful interlock of the on-detector lasers has been found: this aspect of laser safety should be dealt with in other ways. It may be sufficient to set up procedural systems to obviate risk during installation. Hence there are no connections to LV_PSU. Note that there are separate arrangements to provide an interlock for the on-BOC lasers.

BOC <> ROD

• >Clock Feed: this is a copy of the clock received from the TIM by the BOC; it is a balanced PECL5V signal.
• < Module Control Streams, XC[47:0] (TTL)
• >Module Data Streams, RD[95:0] (TTL)
• Set-Up Bus (note the revised signal names)
• <> Data Lines, SD[7:0] (TTL)
• < Address Lines, SA[9:0] (TTL)
• < Read-not-Write Line, SWRN (TTL)
• < Strobe Line, SSTBN (TTL)
• > BOC Busy, SBUSY (TTL): this takes part in the handshake for transfers, and can serve as a status line.

• S-Link: these data are being reviewed for consistency with the Atlas S-Links data. It is expected that signal name changes will result, plus additional changes in the signals that pass between BOC and ROD.
• BOC <> ROD (all TTL)

• Internal to BOC (hence not part of the interface):
• CNTRL/DATA hard wired on BOC

• BOC <> Backplane
• < Power
• +5V standard J2/P2 pins (3 off)
• +3v3 user defined J3/P3 pins (4 off)
• Ground
• J2/P2: 28 pins
• J3/P3: 27 pins
• PIN Diode supply: 2 pins on J3/P3. This may not be needed: the current plan is bias the PIN diodes from the +5V supply (filtered); the pins are being retained for now.
• ROD-Sense: this line was specified to protect against TIM modules being plugged into ROD slots. The plan is now to use the mechanical keying features of VME64X to avoid this eventuality, but the pins are being retained for now.
• Laser Interlock: this is bussed line on the backplane with connections to the RP3 connectors at BOC slots, and to a 2-pin connector on the backplane. This will allow the BOC lasers to be interlocked to a crate or rack door, should this be found useful for safety reasons.

 Realisation

 Details

The detailed definition of the SCT Off-Detector Crate Backplane and Slot Usage is given in Backplane-and-Slots (.ps) >>

The realisation of this in the BOC schematics is shown in rp2_rp3.pdf >

The Set-Up Bus interface and the State Maps for the handshake for transfers across it are shown in setupbus.pdf > . The version shown is correct, but will be augmented shortly.

The Top Level Address Map for the Set-Up Bus is shown in add_map_top.pdf >. The fine structure is shown in add_map_detail.pdf >.

The BOC Timing document, BOC_Timing_Overview.pdf >, shows the provision for adjusting the phase of the incoming data streams with respect to the ROD clock, and the way in which it can be used to accurately measure the relative timing of clock and control signals arriving at each detector module with respect to its neighbour. This is an early version of this document which gives an overview of hardware implementations and how they would operate: BOC0 implements one of these architectures.

The Pixel Modules have special requirements:

• The numerology changes: Data and Clock and Control stream counts differ from the Silicon Strip Modules: currently there is some uncertainty in these parameters.
• The data links may run at 80 Mbaud for non-B-Layer modules.
• B-Layer Data links running at 80 Mbaud may be paired to give an aggregate data rate of 10Mbaud.

BOC0 will not adjust the stream count to optimise for Pixels. It will also make a trial provision to split a small number of 80Mbaud data streams into pairs of 40Mbaud streams to be passed to the ROD.

BOC1 will aim to fully provide for Pixel modules. The differences in numerology will probably be accomplished by partial population of a standard BOC module.

A document will be added to explain this splitting of 80 Mbaud streams. BOC_Pixels.pdf (not yet valid) >

 Notes

BOC0 differences:

Most of the differences between BOC0 and BOC1 appear in the text above. The following notes are also relevant:

• BOC0 uses either BPM4A or BPM4B Bi-Phase-Mark encoder chips, depending on availability.
• Both BPM4A and BPM4B have current-sinking outputs, and therefore depend on external current mirror circuits to match to the common-cathode VCSEL arrays. This circuitry has been tested, but may impose some compromise in performance.
• If BMP4A is used, there will be no ability to control the laser drive currents: these will be fixed by the values of shunt resistors.
• 4-Stream VCSELs are used, with MT4 connectors holding 4-fibre ribbons.
• Only a few BOC0 data streams will be capable of handling the 80Mbaud data streams proposed for Pixel modules.
• The intention is that all data writing operations form ROD to BOC should be capable of data read-back. However, the delay chips and multiDACs used do not offer read-back of their internal registers, so this operation has to be emulated. This provision may not be fully implemented on BOC0.