I/O Choices for the ATLAS. Insertable B Layer (IBL) Abstract. Contact Person: A. Grillo

Transcription

1 I/O Choices for the ATLAS Insertable B Layer (IBL) ATLAS Upgrade Document No: Institute Document No. Created: 14/12/2008 Page: 1 of 2 Modified: 8/01/2009 Rev. No.: 1.00 Abstract The ATLAS Pixel System Design Task Force for SLHC Upgrade has looked at the needed requirements of the R/O links for the Insertable B-Layer (IBL). In this document are summarised the issues that have to be considered for their design and implementations. Whenever possible, at this stage of the system knowledge, the task force makes their recommendations for the preferred options. Contact Person: A. Grillo Prepared by: ATLAS Pixel System Design Task Force for SLHC Upgrade A. Grillo, F. Anghinolfi, M.B. Barbero, R. Beccherle, G. Darbo, F. Philippe, D. Ferrere, M. Garcia-Sciveres, T.B. Huffman, S. Kersten, S. Malyukov, D.J. Nelson, F. Hügging. Checked by: Approved by: ATLAS Pixel Upgrade Distribution List

2 ATLAS Project Document No: Page: 2 of 7 Version Date Description of changes 1.0 8/1/09 Document for general distribution

3 ATLAS Project Document No: Page: 3 of 7 1 Introduction In the course of discussing the I/O options for the FE-I4 for the SLHC and the IBL as well as the services chain for the IBL, the task force has arrived at the following set of recommendations for the IBL. It is recognized that these may very well be different for the SLHC pixel system and may require different I/O components for the FE-I4 chip, but given the different development schedules for IBL and SLHC and the likely different system environment, this may be unavoidable. Again given the nature of the IBL plan with a relatively short time for development and the need to install during a close-to-normal LHC down period plus very minimal commissioning time, preference was given to maintaining as much of the existing system architecture as possible. The recommendations embody the simplest way to meet the IBL requirements using existing elements. This path should minimize needed development, cost, and integration time with the existing, running detector. Because the IBL is a relatively small system, it is unlikely that new elements could be qualified and understood at the same level as the elements already in use in the present detector. Therefore, we favor using existing elements wherever they meet requirements. This is not to say that no validation would be needed. Work towards a vertical slice system test should begin as soon as possible. In this case, the use of existing components makes it possible to begin system-testing parts of the I/O chain right away, whereas such testing would come much later if the components had to be developed. In particular, the end-of-stave to opto-board electrical communication can be prototyped immediately as proposed. The decision to use existing elements wherever possible has the implicit assumption that those elements continue to function adequately in the present detector. This is in fact a necessary condition to begin with, because the IBL is not a stand-alone detector, but rather an add-on to the present detector, such that if the present detector were to cease to function the reliability of the IBL would be irrelevant. We have also assumed that the IBL inherits its as-built quality requirements from the present B-Layer, and these can therefore be achieved using existing elements (because it was achieved -exceeded in fact- for the present B-Layer). 2 Data Rates for Output Links The simulations for a B-Layer at 3.7 cm radius and a luminosity of x3 LHC indicate that a data rate of at least 86 Mbps per FE-I4 is required. This estimate assumes the same data encoding as presently used by the Pixel FE-I3 chip and does not include any safety factor. Some improved efficiency might be gained by a more sophisticated encoding of the hit data but some safety margin is also needed to allow for the ~30% uncertainty in the occupancy simulation and for possible extra overhead to add a more sophisticated transmission encoding. Therefore, the output bandwidth requirement has been set at 160 Mbps for each front-end chip. Given that the envisioned stave will consist of a single row of FE-I4 chips, the concept for the data output link would be one per chip running at 160 Mbps. An alternate estimate that has smaller uncertainty also leads to 160 Mbps per chip bandwidth. This estimate simply scales the existing layers 1 and 2 (L1 and L2) maximum bandwidth to 3.7 cm radius using relative hit rates from simulation. The relative hit rates have smaller uncertainty than the absolute hit rate (for example there is no uncertainty from the minimum bias cross section). The 8(4) Mbps/cm 2 for L1(L2) scales to 120 Mbps/FE-I4 at 3.7 cm. This assumes that bandwidth scales exactly like hit rate, which is conservative because in FE-I4 one has 4-bit TOT instead of 8-bit, and the higher the hit rate the

4 ATLAS Project Document No: Page: 4 of 7 smaller the overhead due to headers and trailers. There is no need to add a safety margin to such an estimate because the maximum L1 and L2 and width are already fixed. Therefore, 120 Mbps is the maximum FE-I4 net bandwidth (before DC balancing overhead) that is useful for IBL. 3 Clock and Command Two options were considered: sending a 40 MHz clock and providing a clock multiplier on the FE-I4 or sending an 80 MHz clock and using both clock edges as is now done at 40 MHz to achieve the 160 Mbps data output. The former option would allow the TTC chain to operate as it now does but requires a new clock multiplier circuit on the front-end readout chip. The latter would require modifications to the BOC and possibly the ROD to produce the higher speed TTC. Additionally, a synchronization protocol would have to be developed and built into FE-I4 to provide for the correct phasing of the beam crossings to the 80 MHz clock. It would also require a new DORIC chip to decode the clock at twice the frequency. While the BOC and some parts of the ROD will have to be modified in any case to handle the higher bandwidth data stream, being able to keep the TTC chain as presently designed including using the existing DORIC chip and not modifying the ROD & BOC to generate an 80 MHz clock and command stream was considered a very positive aspect of the 40 MHz clock scheme. A first discussion with the FE-I4 designers did not raise any serious concerns about the implementation of a clock multiplier, however, this circuit will need to be designed and its robustness tested, especially against possible upsets from SEU. Also, the present thinking for the upgrade strip readout calls for a clock multiplier in the module controller chip. The design of such a circuit for the IBL could likely be used for the upgrade strip readout as well. In keeping with the idea to maintain as much of the present TTC link as possible, the proposal is to take the decoded clock (40 MHz) and commands (40 Mbps) from the DORIC and propagate them as separate LVDS lines from the opto-boards to the FE-I4s. Furthermore, it should be possible at this frequency to connect two FE-I4 chips to each of the LVDS clock and command lines thus reducing the number of electrical links by a factor of two. 4 Data Output Links As stated above the data output links must run at 160 Mbps, one link from each FE-I4. These LVDS links will run to the opto-boards where a VDC chip and VCSEL will convert them to optical, one optical link per LVDS link. No further multiplexing or encoding will be done on the opto-boards. Given that the data rate will be four times the base clock rate at the BOC/ROD and that the shorter clock period for the data makes phase adjustments more critical, it has been decided to provide some encoding of the data at the front-end chip such that the data clock can be re-synchronized to the data back at the BOC. Preliminary investigation indicates that 8bit/10bit encoding is adequate for this purpose and there should be sufficient bandwidth to accommodate it. The FE-I4 chip will have to encode the output data and the BOC decode and re-synchronize the receiving clock. We believe that these BOC functions can be accomplished in an FPGA and firmware to do it may already exist in the public domain. Likewise, the 8bit/10bit scheme is so widely used that examples of the necessary circuitry for the FE-I4 may also exist.

5 ATLAS Project Document No: Page: 5 of 7 The actual encoding of hit information in the FE-I4 (e.g. header, hit address, TOT, etc.) is still under development and no firm proposal is yet ready. 5 BOC/ROD The BOC will need to be redesigned to handle receipt of the 160 MHz data stream and to decode the 8bit/10bit data to its raw form. The simplest adaptation will be to have the BOC hand off the data to the ROD as four 40 Mbps data streams for each input link as it now separates the 80 Mbps data stream into two 40 Mbps streams. This will minimize changes to the ROD and require still one S-Link per BOC/ROD but will mean more new RODs are required. It may be possible by the substitution of faster versions of some of the ROD FPGAs for the BOC to pass 80 Mbps data streams to the ROD, however, then two S-Links would be required per BOC/ROD. These decisions require more study by the BOC and ROD designers. In any case a strong requirement is that the RODs built for the IBL be backward compatible with the existing ROD so that they can be used as spares for the present system. 6 Possible Opto-board Upgrade There has been discussion about possible upgrades to the existing opto-board as part of the IBL project. In particular, it has been suggested that some redundancy could be added to allow dead TTC or Data Out links to be replaced by spare channels. Also, separate control of the VCSEL optical power would improve robustness. These added features would have been helpful for the existing system and should be seriously considered for the SLHC upgrade, however, they appear not to be a good use of scarce resources for the IBL project. If these enhancements were designed into new opto-boards, they would be used only for the new IBL and not for the existing Pixel layers since no access to those opto-boards is planned. This means that the enhanced opto-boards would only improve the reliability of a small fraction of the Pixel system, one that is expected to have a much shorter lifetime than the larger fraction already installed and required to continue operation with the IBL. Also, these new opto-boards will be positioned at a larger, safer radius and accessible during yearly down periods. Therefore, it is recommended not to include these upgrades to the opto-board for the IBL if the existing components are verified to meet the requirements. Improvements could instead be made to the optical receivers on the BOC such that they could be tuned over a wider range. This could mitigate the lack of individual control of VCSEL optical power on the VCSEL arrays inside the detector for both the existing layers as well as the new IBL. 7 DCS and Interlocks The general plan is to use the same components that are used in the present Pixel system, however, more study is needed to determine the exact configuration and location of components. This will be covered in a future document. 8 Near Term Tests Several aspects of this proposed plan for the IBL should be tested in the very near future. Reliable electrical transmission of DC balanced 160 Mbps signals over the estimated 4 meters from FE-I4 chips to

6 ATLAS Project Document No: Page: 6 of 7 the planed location of opto-boards should be verified. The LVDS test chip recently fabricated can be used for this. The ability of the existing VDC chip to drive 160 Mbps must be tested. Likewise the reliability of the present DORIC chip to transmit 40 MHz clock and 40 Mbps commands over the same 4 m must be verified, as well as the possibility of two FE-I4 chips sharing the same clock and command signals. A test of this services chain using an existing opto-board and the LVDS test chip should be employed as soon as possible as the results of these tests impact these architectural decisions. To assure that there is some margin for the 4 m transmission, testing at 4 m, 5 m and 6 m should be attempted. 9 Options to Keep in Design for the Near Term Some options should be included in the FE-I4 design. The FE-I4 command set should include a reset-clock-multiplier command, which can be used to reset the clock multiplier circuit if it should be upset. Since the bulk of the FE-I4 chip including the command decoder will run off the 40 MHz clock, this is quite possible. The FE-I4, for the time being, should be provided with a second 80 MHz clock input and the option to either use the result of the clock multiplier or this alternate input. If the above tests show some difficulty transmitting data at 160 Mbps, pre-emphasis circuitry can be added to the FE-I4 output drivers. Likewise, if the present DORIC has trouble with reliable transmission of clock and command signals over 4 m, an LVDS buffer chip with pre-emphasis can be added or similar pre-emphasis circuitry could be added to the DORC outputs in a modified chip.

7 ATLAS Project Document No: Page: 7 of 7 10 Summary of IBL I/O Recommendations TTC Optical Downlink Electrical links DORC to FE-I4 Data Output Electrical link FE-I4 to VDC Optical Uplink BOC/ROD TTC Data Input BPM encoded 40 MHz clk and 40 Mbps commands 2x LVDS 40 MHz clk & 40 Mbps commands Each link drives two FE-I4 chips One LVDS / FE-I4 at 160 Mbps Encoded as 8bit/10bit One optical link/fe-i4 at 160 Mbps 40 MHz/40 Mbps BPM encoded as present system 160 Mbps input links 8bit/10bit decoded in BOC Data passed to ROD as 4 x 40 Mbps streams 8 input links per BOC/ROD