Minutes of CALICE Electronics Meeting, UCL, 14/01/03 ==================================================== Present: Adam Baird, Dan Bowerman, Paul Dauncey, Dave Mercer, Martin Postranecky, Dave Price, Matthew Warren Minutes: Paul News: There is a CALICE ECAL meeting at LAL-Orsay next week on Tue 21 Jan. There have been no other details circulated about start and end times or the agenda so it is difficult to book travel tickets. The UK should try to have a good representation; Adam, Matt, Martin and Paul will try to go and Stewart Boogert and Roger Barlow are also expected to attend. Paul will try to get any details from Jean-Claude Brient on this asap. Osman is away from work due to illness and may not be back for several months. Matters arising: Paul has added a link to the Fermilab beam line web site on the CALICE-UK home page. This contains a lot of information, including some on safety requirements for experiments at Fermilab. In particular, the document at: http://www-ppd.fnal.gov/EEDOffice-w/Projects/Infrastructure/Reviews/H011228A.pdf states cables should be "fire rated to resist flame spread, i.e. cable type CL2 or better, fire rating VW-1 or better". Martin reported that DESY (similarly to CERN) require halogen free, fire resistant cables. However, our use is a couple of metres of cable above ground in a temporary installation and so there may be some flexibility in applying these requirements. DESY can provide twist-and-flat cable to their safety specifications but it was not clear if it would fit the high density SCSI connector proposed. A cable with the lower density SCSI made from flat cable was shown by Matt. Flat cables would probably be preferable for the VFE-PCB end where a high density of cables (3 per 4.5mm) is needed. [Note added after meeting; Martin forwarded a note from the DESY safety officer (Richard Stromhagen) and a paper on the CERN cable safety requirements, which is now on the CALICE-UK web page. The DESY note states: All cords and coats must be: - halogen free, - hardly flammable, - pvc free. An industry regulation is that the safety data sheets (Sicherheitsdatenblatt) are to be requested from the manufacturer. All cords must correspond to DESY specification MKK-EV 4/99and CERN specification of no. 165.] Adam circulated a pin count and table of potential FE Virtex-II components following the previous meeting. He calculates a total of 188 I/O pins is needed if all ADC control is done separately, i.e. the most flexible arrangement. By doubling up some of the control, this can be easily reduced to 163 I/O pins with effectively no loss of flexibility. Adam regards these figures as quite firm. CMS are using the FG676 for the FE FPGA and this is footprint compatible with the FG456. The minimum number of I/O pins for a FG456 is 200, so even 188 pins is acceptable. As a rough guide, Matt pulled out prices for 25 off of the various choices for the FG456 of logic gates (250k, 500k or 1000k) and speed (-4, -5 or -6) from: http://www.avnetmarshall.com/dynamic/search These prices were, in US$/component: Gates 250k 500k 1000k Speed -4 86 147 213 -5 120 206 299 -6 168 288 418 For comparison, the CMS FG676, 2000k gates, were 428, 600, 839 for the -4, -5 and -6 speeds, respectively. There is clearly a large potential cost saving if we can buy cheaper components. However, this requires a reasonable estimate of the amount of logic needed and this will not be known for a while, due to the lack of detailed firmware. It is necessary to know how long we can put off the choice of FE FPGA and this may be driven by the order lead times. If the components take 8 weeks, we would need to order them by the end of Jan. Dave Price will check on prices, availability, order lead times and minimum order numbers. As requested, Rob circulated the link for the CMS FED schematics and this is now on the CALICE-UK electronics web page. However, he has not yet distributed the FE-BE configuration data protocol; Paul and Adam will chase this up. The CMS VME FPGA does not have any interupts implemented yet. As we would like to use the firmware for this FPGA with no modifications, then we should try to encourage CMS to include interupts in their design. This is being done by Edward Freeman in RAL ID and the status of this is not known. Adam will investigate whether adding interupts would be a possibility. Alternatives to interupts in the readout board are polling for the information or, as suggested by Dave Mercer, routing the signals out onto the backplane and then using them to generate an interupt in another VME module, such as the VME controller. It was not clear if the Struck module would allow this but this option should be considered in more detail. The block diagrams Paul produced for the RAL 06/12/02 meeting (available from the CALICE-UK web page) should be redone by DaveP (for the FE), DaveM (for the BE) and Matt (for the BE-trigger) to reflect a more realistic firmware design. These should try to be ready for the next meeting. Layout status: Adam has the full Cadence files for the CMS FED now. It will be several weeks work to merge his schematics (for the ADC, etc) into the rest of the board. However, this requires some interaction with Chris Day to make sure it is done in a modular fashion. Adam will provide the modifications for the 8MByte memory also. A specific component which would fit the available space and BE connections needs to be found. Ideally, the memory would have JTAG but not if it requires major changes to the CMS layout. Other changes to the rear of the CMS layout are the addition of termination resistors to all the backplane I/O lines. This could be avoided if a native Xilinx-specific differential protocol was used as the termination is done internally to the FPGA. These I/O lines only go within the crate, so if only UK boards are used, this would be feasible. The layout is proceeding fast enough that it is still compatible with going to the drawing off at the beginning of Feb. However, there may be a problem with availability of Chris Day at that time, as he is the main person with modular layout experience and he is known to be busy for the next 4 weeks. CMS FED status; The PCBs have been returned and are out for assembly. They are expected back within a few days. Adam will notify us when they arrive. There are some known issues with the CMS boards. One is that oscillator blocks for a 3.3V supply are not easy to find; however, CALICE should use the same ones. Another issue is that it is known that the clock must be at least 24MHz for the digital clock handler to function correctly; CALICE is planning to use a clock around 40MHz, so this should not be a problem. It is likely that there will be some spare components from the CMS assembly which we could use, although not FPGA's. This might relieve the problem of ordering the components with long lead times. FE status: No progress reported. The discussion on the component choice for this FPGA is described above. The information needed is the amount of logic needed and the pin-out. Adam will proceed with the layout using the 200 I/O pins of the FG456/XC2V250, as this will allow any larger component to be used. If there is still some uncertainty at the time of assembly, only one or two of the FE FPGA's could be mounted initially and the rest added when the firmware has been tested. BE status: No progress reported. DaveM has not obtained the CMS BE VHDL files from Rob yet. This is actually written by Saeed Taghavirad. Adam suggested that talks should be organised from the CMS firmware designers so that we can get up to speed, particularly on the BE FPGA. BE trigger status: No progress reported. It was thought that there is no issue fitting the "extra" trigger code into the BE FG676 component. DAQ: Steve Hillier had circulated an email asking for a memory map of the readout board asap so as to start on software. It was thought unlikely that the memory map would be known for quite a while. VHDL design effort: Given the loss of Osman, potentially for several months, there was a discussion on shifting the design effort between projects. Matt, Martin and DaveM all thought they would not have any time to look at the FE design, particularly as UCL has Atlas commitments until June. Adam also claimed he was too busy with other projects. DaveP will try to cover as much as he can, although there will clearly be a delay. Test board: The overall plan for the test board was discussed. If it is not a purely passive board, power should be obtained via a flying lead connected to J1 in an empty slot of the crate. This would ensure common grounds to the readout boards and so allow single-ended level tests. The aim is to use this board for production testing of both the readout boards and the cables. This is mainly connectivity testing; the FE and BE firmware will be debugged by hand using a scope. The test board needs to have two connectors; one to go directly to the SCSI connector on the front panel of the board and one with the VFE-PCB connector to connect to the VFE-PCB end of the cable. The functionality of the board should be the same for both cases. The original test board was supposed to help diagnose the firmware during prototyping. This would require a much more sophisticated board and this had previously been dropped as being excessive. No requirement for an intermediate-level board was seen, so a simple connectivity test board is now planned. The analogue channels could be tested for both connectivity and crosstalk using a simple resistor chain from the DAC voltage. This would be purely passive. The digital lines were more of an issue. It would be quite likely that, even with a broken connection on one of the LVDS differential lines, the board would pass digital tests. It was thought that single-ended tests for each line would be needed. However, putting TTL output down lines which will be used for LVDS is not possible without loading different firmware code, which is undesirable but not out of the question. Next meeting: Phone meeting on Mon 3 Feb, starting at 2pm.