First light

Despite the fact the the description below is really outdated, I can pronounce the first really important step from connecting the new RICH ADCM to the TRBnet, and getting it working with the new APV-FE.

triggered.pdf

One ADCM (version 0) is connected to one APV-FE via a first version of backplane; connection to the TRB is made by TRBnet fibre.

Access is done by slow control channel, with help of Jan Michael's TrbRegIO entity and the new written bus_handler from me.

The entities taking care of the APV data handling were taken from the first GTB based development and connected nearly 1:1 to the new TRBnet slow control access.

Triggering was achieved by simple TRBnet register access.

The attached PDF shows (in the lower part) the data sent from the APV module (analog measurement). This differential signal passes an input stage, enters the ADC and is digitized by 40MHz @ 12bit. ADC data is sent at 480MHz serially (240MHz DDR data encoding) to the FPGA, is being deserialized and put into different entities which data care about data separation. The result is sent as 12bit data to a logic analyzer debug port and shown as "analog" representation in the upper part of the PDF page.

As you can see, digital reconstructed data is the same as the analog input data

Analog Frontend (AFE)

(pictures to be inserted soon)

This module connects directly to the RICH padplane by 64pin CSI connectors, replacing the old (mixed analog / digital) FEs. It carries only the analog parts, needed to readout the raw detector signals. Neither power consuming parts nor digital stuff will be placed there, which should allow us to re-use this board also for Si stripe and / or CVD detectors in vacuum.

As preamp chip the APV25S1 (designed for CMS) will be used (editors note: in the data sheet replace "VDD" by "+2.50V", "GND" by "+1.25V" and "VSS" by "GND"):

• 128 channels
• 40MHz sampling rate
• shaping time between 50ns and 300ns
• completely digital control by I2C interface
• analog "history" for 192 * 25ns
• adjustable "latency" to look back into past
• only a readout trigger needed, no real trigger

The AFE will offer 64 analog channels, each one protected by a double diode against discharges from the wire chamber. A small capacitor will AC couple the pad signal to the inputs of the APV25S1 (including a 10M resistor to discharge this coupling capacitor). The remaining 64 unconnected channels can be used for common noise rejection.

A massive GND connector (same style as the old FEs) is foreseen to reduce noise at this place.

The AFE card will provide a hex rotating swich (0x0...0xf) to allow setting the APV25S1 I2C address, allowing more than one AFE card to be connected to one I2C bus. Moreover, a small temperatur sensor must be placed on the AFE, allowing online measurements of temperature in case of vacuum operation (either I2C based, or single wire protocol).

The connection to the ADC card will be a normal pinheader (20 pins, RM2.54mm) to allow a standard flat ribbon cable with twisted pairs to be used if the AFE card is to be used in vacuum. A short note: operation in vacuum has been tested once during a test beam time at the Garching Tandem accelerator.

Power supplies: we will place the LDOs for the APV chips on the passive backplane, based either on the 48V POLA concept, or on the +5V / +3.3V linear regulated power supplies already in use for the old system. This is to be discussed, as replacing all the power supplies will include quite some work (cabling, testing, ...)

Power requirements: the AFE board needs +1.25V @165mA and +2.50V @243mA (worst case numbers, taken from APV data sheet). In normal operation we need +1.25V @65mA and +2.50V @90mA.

Main questions still open:

• availability of Known Good Dies (1000 pieces APV25S1)
• bonding of APV (serial production, for prototyping solved)
• protection of bonded APVs (glue blob?)
• internal or external reference bias

Some of these questions will hopefully be answered in cooperation with the specialists from E18, which already used the APV25S1 for upgrading the COMPASS RICH.

ADC card (ADC)

(pictures to be inserted soon)

The next chain link is the ADC board. It connects on the detector side to the AFE board, and on the DAQ side to the passive backplane. This board contains mainly the ADC and all needed components for adjusting the APV differential output to the ADC, as well as decoupling components for the ADC. By separating the preamp part from the ADC part we hope to meet two main goals:

• easy upgrades in case we need more ADC bits
• better noise figures by keeping the high speed LVTTL outputs from the ADC away from analog parts

Our first choice in ADC is the Analog Devices AD9136 family, together with a differential opamp AD8138. These two components are already in use on the Bridgeboard prototype used for first APV readout together with CVD detectors. We propose to use 10bit 40MHz ADC, with possibility to upgrade to 12bit 80MHz should this become necessary. The role of the ADC will be discussed later, together with fundamental questions on how to control and trigger the APV25S1 chip in this system.

One technological limitation for our new FEs will be connector sizes. We use now ERNI 50pin finepitch connectors on the old backplanes, and it doesn't look reasonable to go to higher pin densities, as these connectors are fragile. Moreover, we need to send 12bit ADC data with LVTTL levels at 40MHz over this connectors.

From a first educated guess we suggest using a 40pin header on the ADC board to connect to the BP. One of these pins should be used as a simple "module connected" pin, to allow the LM to findout how many AFEs are present on one specific backplane. This should also avoid problems with misaligned connectors, which we know to happen quite often when backplanes are removed for service. We also recommend to use the "look-through-hole" technique which was tested for the HERMES specific backplanes, allowing both optical inspection and an easy access for mechanical guiding during assembly of the FE electronics.

Main questions still open:

• do we need a DAC for adjusting the gain?
• are 10bit sufficient?

passive backplanes (BP)

(pictures to be inserted soon)

The backplane (BP) board will take over several tasks in the readout system:

• mechanical stability: keep the AFE/ADC combination in place
• concentrate data from four / five AFEs to one logic module (LM)
• distribute low voltage power to AFEs / ADCs
• distribute trigger and clock to AFEs

We will need 16 backplane outlines for covering our "piece of cake" shaped sectors, with connectors on the detector side at the same position as in the old system. Therefore a simple board layout with few components is prefered, so we can reuse the old Eagle board files as starting points for board layout. By this we hope to minimize chances for misplaces connectors and mechanical problems. With the RICH geometry in mind we have 14 different styles of BPs to route.

The BP will carry only one active component: LVDS driver chips to distribute differential Clock and Trigger signals to four / five AFEs. Regarding all other signals the BP is a pure passive component.

Main questions still open:

• power supply concept: 48V POLA or 5V/3.3V from "old" FE power supplies
• connectors towards the LM
• decoupling / filtering issues

logic module (LM)

(pictures to be inserted soon)

The logic module integrates the interface to the common DAQ system. It processes data from four / five AFEs / ADCs connected to one backplane. Incoming triggers will be handled there, the ADC control will process data from the AFEs and generate a subevent for four / five AFEs.

Main idea is to use the serial link protocol under development by Ingo Frhlich, by this we get rid of detector specific readout controllers; moreover we can use s generalized slow control / error tracing solution, as we do not have any proprietary protocols inbetween.

From the current point of view, the following components should be integrated into the LM:

• one big FPGA (either Lattice SC or Lattice ECP2M)
• boot rom for FPGA, allowing "live at powerup" - no long bitstream download anymore by software
• local clock (40MHz)
• either optical or LVDS connection to TRB
• LEDs (important feature
• debug connectors

For RICH data processing at frontend level we will need some space, so we better should go for one big FPGA with enough ressources for future enhancements (current XC4000E FPGAs in RICH RCs are 95% full). I would recommend the Lattice SC FPGA, as it offers huge logic ressources, as well as PLLs and DLLs - which will be crucial for adjusting the 40MHz clock for the ADC relative to the APV clock.

Inside the LM FPGA some preprocessing must be done, as we want to take three data samples per pad and trigger, to compensate baseline shifts and to recognize real photon hits from noise. Another point for the Lattice SC is the autoboot by SPI FlashROMs, which are available from several large companies dirty cheap - no need anymore for overpriced special Xilinx boot PROMs. This can reduce costs.

The choice of connection to TRBs (optical / LVDS) has to be based on the expected data rates during experiment, as well as on the need of additional connections (like a central clock / trigger).

Data rate estimation

For selecting a suitable media as connection between the LM and the TRB addon, we must consider one "worst case" scenario. If we take one BP with five AFEs, we have 5*64 analogue channels. We can assume 5% occupancy in the detector, and we will take three samples of the detector signal to be able to distinguish photons from noise, and to do some baseline restauration.

As raw data per channel we will have three data words of 32bit, which should be compressed to one 32bit word after processing in the LM.

Assuming a trigger rate of 20kHz and a header of 32bit, we will end up with a data volume of (320 * 0.05 * 4byte + 4byte) * 20kHz = 1.3MB/s per BP. For the whole RICH this number must be multiplied by 16 BP and by 6 sectors, ending up with a total amount of RICH data of approx. 128MB/s.

In case of pedestal making this number will increase, as all channels need to be readout, and 20kHz won't work anymore if we want to do pedestal creation in the event builder:

(320 channel * 1.00 * 4byte + 4byte) * 20kHz = 24.5MB/s per BP

(16 BP * 6 sectors * 24.5MB/s = 2.3GB/s (whole RICH)

Pedestal calculation could be implemented in the TRB DSP?

APV25S1 - basics of operation

The APV25S1 preamp ASIC was designed for the CMS experiment. It has been used mainly for silicon readout, but recently also to upgrade the COMPASS RICH from GASSIPLEX readout. From our first experiences it seems feasable to get the HADES RICH also working with the APV25S1, giving us more possibilities than the current GASSIPLEX based readout.

Internal structure

The APV25S1 has 128 analogue input channels, each one connected to a 192 cell analogue pipeline. This pipeline can be considered as a ring buffer, which is filled at a fixed sampling rate of 40MHz. By an external "trigger" (namely a readout trigger) one or more of this ring buffer cells can be "taken out" of the ring and be read out, while the rest of the ring buffer is being filled as normal.

This mode of operation can reduce the deadtime for readout significantly.

To point out clearly: in contrast to the GASSIPLEX (which uses a fixed shaping time of 550ns) the APV25 can "look back" into history up to 192 * 25ns = 4.8us, which makes the trigger timing somewhat easier to fulfill.

Slow control

For configuration the APV25S1 has implemented an I2C slave interface. The I2C address of the APV25S1 can be set by five address inputs, while one of these addresses is a "general APV call" address where all APVs will respond.

Besides several registers controlling analogue functions (like bias currents and voltages) there are some registers defining the operation mode of the APV25 (Deconvolution, Peak, Multi), the polarity of input signals and the latency between the write pointer (i.e. cell being written to) and the cell to be readout when being triggered.

Note: the APV25S1 will fail whenever a "repeated start" condition is present on the I2C bus. Only simple "start" and "stop" conditions are allowed. In case of repeated start conditions the complete I2C interface inside the APV will go weird, don't expect any response after this. Only a hard reset will get the APV25 back into communication.

Triggering

The APV25 is controlled in operation by a differential CLK (40MHz) and a differential TRG input. Commands are sent as a three bit sequence:

Sequence	Command
000	No OPeration, NOP
100	normal trigger
110	calibration pulse
101	synchronization

These command sequences have to be sent synchronous to the 40MHz CLK signal. The behaviour of the APV25 in case of unknown command sequences is undefined.

The RICH trigger distribution will change from the current system (CTU -> DTUs -> VME backplane -> RCs -> Backplanes -> FEs).

For the HADES RICH upgrade I propose a central 40MHz clock being distributed from one source, together with the TRG lines. Distribution should be done by LVDS signals.

Tickmarks and dataframes

The APV25 has only one differential output, which is used for both digital and analogue data. After configuration by I2C accesses the APV25 must be "started" by a synchronization trigger ("101"), which resets all internal pipelines and sets the latency between write and read pointers in the ring buffer. After synchronization the APV25 will send a "tickmark" every 35 clock cycles, which have dual purpose: first, you can check if all APVs were started synchronously (and if the are responding), second the tickmark defines the starting point of data frames.

It is necessary to synchronize the FPGA logic to these tickmarks, as data frames consist of both digital and analogue data bits, which must be interpreted correctly.

Digital bits are sent as full range swing of the differential output, with "1" and "0" being different in the sign of both lines. Analogue data has a smaller signal swing as digital bits.

If a readout trigger ("100") is sent to the APV, then one (or more) ring buffer cells are locked out and prepared for readout. After a maximum of three tickmarks (depending on the position of the readout trigger relatively to the tickmarks) the APV will send a data frame.

A data frame consists of 140bit of information, starting with three "1" bits as header, followed by eight bits of row address (the cell being read out), one error bit (either readout FIFO overflow or LATENCY error), and 128 analogue bits.

To recognize this data frame one needs to sample the APV25 output lines with an ADC at 40MHz, phase shifted in a way to compensate cable delays.

-- MichaelBoehmer - 20 Mar 2007

• triggered.pdf: complete data chain successfully done