SLHC Data Rates
V 2.1 12/7/07Abdel Abdesselam, Todd Huffman & Tony Weidberg
Introduction
This note presents results of simple Monte Carlo calculations for the readout of short strip modules at SLHC. The dead time is calculated as a function of the buffer depth for different assumptions about the occupancy. At this stage only the readout of individual modules is considered and the multiplexing for a super module will need further studies.
Method
A simple toy Monte Carlo programme was written to calculate the dead time. The calculations are based on GEANT4 simulations for the current version of the SLHC strawman geometry for the short strip barrel detector. A very simplified description of the material is used for the strip layers but the material per layer was adjusted to be the same as the current SCT. It was checked that the results are rather insensitive to reasonable variations in the material distribution. Histograms of the number of bits to read out per trigger were generated from the full GEANT4 simulations. These histograms were then read in to a simple toy Monte Carlo programme which calculated the dead time as a function of the depth of the de-randomising buffers.
Single sided modules have been assumed for these calculations. The parameters of the modules are given in Table 1. Note that we are still using a strip width of 80 m as opposed to the currently preferred value of 75.6 m which will means the results will be slightly too conservative.
Table 1 Parameters for the barrel short strip layers.
Parameter / Value / UnitsRadii of layers / 39, 49 , 61 / cm
Strip length / 2.5 / cm
Strip width / 80 / m
Number of strips per ABC-N / 128 / -
Number of ABC-N per “column” / 10 / -
Number of “columns of ABC-Ns” per module / 4 / -
Figure 1 Data flow architecture for one module containing 40 ABCD-Ns. The data is read out serially at 40 Mbits/s from one “column” of 10 ABCD-Ns into the MCC. The MCC MUXes the 4 data streams at 40 Mbits/s into one output stream at 160 Mbits/s.
The data flow architecture is illustrated schematically in Figure 1.In these calculations we will assume that the data is read out serially at a speed of 40 Mbits/s for groups of 10 ABC-N chips into the module controller chip (MCC). There are 4 such serial links going into each MCC. There are level 2 de-randomising buffers in the ABC-Ns. After an L1 trigger is received the data for that bunch crossing is transferred to these buffers. The readout of these buffers is initiated as soon as they contain any data to transfer. If the buffers are full for one “column” of ABC-Ns when an L1 trigger is received, then the data corresponding to that trigger will be lost. Since the occupancies are dominated by pile up background they will be very little correlations between modules. This means that the deadtime will effectively appear as a decrease in hit efficiency for the modules. Therefore in order not to significantly degrade the tracking performance, the deadtime should be maintained below 1%. The ABC-Ns (like the current ABCDs) will contain an overflow counter to keep track of buffer overflows, so that synchronisation will always be maintained.
The MCC contains a MUX to combine the 4 parallel data streams at 40 Mbits/s into one 160 Mbits/s serial line. In this note we will assume that there are no buffers on the MCC so that the MCC effectively acts like a simple MUX. However the MCC will need to inject some DCS data into the data stream. This could be done in several different ways. Probably the simplest would be if the MCC would be configured as the “master” for each column of ABCNs. Then the MCC would initiate readout of a column of ABCNs on receipt of an L1 trigger, or immediately after the readout of earlier triggers had been completed. The MCC could then also inject DCS data into the data stream The DCS data could be wrapped in the same preamble and trailer as normal data but the data would need to be flagged as DCS rather than event data. By definition the total quantity of DCS data will be negligible compared to the event data, so this will have no influence on the dead time and so can be safely ignored in these calculations. There are other options for the injection of the DCS data but they would also have negligible impact on the overall data rates.
Assuming that we use serial powering the data must be sent using a balanced code. This encoding could be done in the master ABC-N for each group of 10 ABC-N chips or in the MCC[1]. The encoding would involve a cost penalty in the number of bits to transmit. If we assume that we will use the 8b/10b encoding scheme the cost penalty would be 25% but other encoding schemes would give a similar figure.
The key numbers for the readout are summarised inTable 2. Note that we have increased the number of address bits to be read out compared to the current ABCD, to allow for the read out of 40 ABC-N in one serial link.
Table 2 Key parameters for the readout.
Parameter / Value / UnitsSLHCBC frequency / 20 / MHz
Number of pile-up events per BC / 400 / -
Average L1 rate / 100 / kHz
Number of hybrids to read out in one link / 4 / -
ABC-N read out speed / 40 / Mbits/s
MCC read out speed / 160 / Mbits/s
Number of bits for the preamble, header and trailer / 35 / -
Number of bits/isolated strip / 19 / -
Number of bits/neighbour strip / 4 / -
Scale factor in number of bits for balanced code / 1.25
To take into account the worst case, modules from the smallest radius strip detector were used.
Sanity Check
As a simple check of the code, the programme calculated the dead time assuming an exponential distribution in the number of trigger bits and compared the results with an analytic formula[[1]] . The results shown in Figure 2are in good agreement, which gives some confidence in the code.
Figure 2 Test of the code. The number of bits to read out was generated with an exponential distribution (upper plot). The lower plot shows the dead time fraction as a function of the number of buffers, calculated analytically (smooth curve) and from the simulation programme (histogram).
Results
The dead time as a function of the depth of the de-randomising buffer (number of buffers) for the default conditions is shown in Figure 3. It is clear that for these conditions the dead time with the proposed number of buffers of 42 will be negligible.
Figure 3 Number of bits to read out per event per module (upper plot) and dead time fraction as a function of buffer depth (lower plot).
In order to study how much safety margin there is, the number of hits was scaled by a factor and the resulting dead time as a function of the depth of the de-randomising buffer was calculated. This is not quite the same as simply scaling the number of bits because of the fixed overhead of the preamble, header and trailer. In order to determine the ultimate safety factor, the scale factor was set to 1.2. The simulation was changed to increase the depth of the de-randomising buffer to 42 and the results are shown in Figure 4. With a scale factor of 1.2, the system is at the limit of working acceptably.
Figure 4 Same plots as for Figure 3 with the occupancy increased by a scale factor of 1.2. Note that the x axis scale has been changed to go up to a maximum value of 42.
Conclusions
If serial powering is used to operate different groups of ABC-N chips at different voltages then the balanced code encoding would need to be performed in the master ABC-N chips.
The proposed read out speed of 40 Mbits/s for the ABC-N and 160 Mbits/s for the MCC are sufficient for one serial link to read out the 40 ABC-N chips on one side of a short strip module. There is a safety factor of ~ 1.20 in this result. If this safety factor is considered inadequate, then we would need to increase the readout speed of the ABC-N to 80 Mbits/s and the speed of the MCC to 320 Mbits/s. Alternatively the speed of the MCC could be maintained at 160 Mbits/s if two MCCs were used to read out one module with 40 ABC-Ns.
Therefore to be safe at this stage, we should design ABC-N to operate at 80 Mbits/s but this decision should be reconsidered if the first LHC data show that the occupancies are equal to or lower than those given by theMonte Carlo calculations.
1
[1]Ideally, the extra encoding would be done in the MCC to save power and chip area, but if serial powering is used such that the 4 groups of 10 ABC-N chips are powered at different voltages, then the encoding would have to be done in the master ABC-N chips. However this choice has no impact on the data rates out of the MCC. Also if the balanced codes were generated in the MCC, the MCC would require some data buffering,.
[1]R. Bock et al., Data Analysis Techniques for High Energy Physics, 2nd Ed. CUP.