Minutes of the CALICE electronics meeting, UCL, 05/07/02 ======================================================== Present: Jon Butterworth, Paul Dauncey, Steve Hillier, Dave Mercer, Martin Postranecky, Dave Price, Osman Zorba Minutes: Paul News: The main news was the disappointing outcome of the PPRP meeting on 01/07/02. The electronics project was thought to be good but overall, CALICE-UK was seen to be understaffed. We can resubmit the proposal to the next PPRP meeting on 30/09/02 if we can boost up the effort but until then, we should continue to try to hold the schedule. There is officially no travel allocation at this point but Paul is negotiating a small fund to see us through to the next meeting. Jon and Paul attended an HCAL meeting at DESY on 06/06/02 and Paul then went to Ecole Polytechnique on 26/06/02. The outcome of these discussions is that there is no other possibility for readout electronics foreseen for the tile HCAL, so that we have to assume they will use our ECAL readout board. Hence, any small modifications or flexibility we can build in to make its use in both systems easier should be done. Also, the complexity of having buffered readout for acquiring events during beam bursts was thought to be impractical. This would need a sophisticated fast control system to distribute some event label and require all systems (including the beam monitor and trigger readout) to have buffering built in. In addition, the memory required for this has not been included in our budget. Hence, we should assume only single event readout at a time is needed. However, to get our assumed few 100 Hz speed, we now must take this as the average rate, which means around 1 kHz is needed during the actual beam burst. Hence, we must push the speed up to deal with a 1 KHz peak rate. Organisation: As we are not (yet) approved, we have no RAL TD allocation at this time. Paul had had informal discussions with Rob Halsall on 24/06/02 and Rob suggested Adam Baird would be an appropriate person to join if we get approval. Adam is currently working with Dave on the H1 trigger boards and Dave thought this would be an excellent outcome. Adam has enough experience to potentially be able to be lead system engineer for the whole project. However, until we at least have TD effort, someone else must take on this role; this could be temporary (i.e. for the three months until the next PPRP meeting) or permanent. Osman volunteered to do this task and he will re-evaluate whether to continue if/when we know better who will be working with us from RAL. Schedule: We will be expected to go through a reasonably formal ISO9000ish review system if/when we are involved with RAL TD. Even in their absence, we should probably try to stick to this so as to not cause issues later. The reviews needed are: the Conceptual Design Review (CDR), where a description of the board in some detail is presented, with all interfaces specified so that an evaluation of its performance compared with the requirements can be made; a Preliminary Design Review (PDR), which should occur just before prototype fabrication and checks the schematics (and layout?) for any remaining errors before money is spent; and a Final Design Review (FDR), which should occur just before production fabrication and again looks at the schematics but also the prototype test results. The earliest date which would be feasible for a CDR is in a few months. Politically, it would be very good to have the CDR completed in time to be reported in the next PPRP submission, for which the deadline is 16/09/02, although it could be reported verbally if done after that but before 30/09/02. Hence, we should aim to schedule the CDR for early September; this sets the scope of work to be achieved before the PPRP meeting and people should concentrate on this target (see below). We could try to get Adam Baird up to speed by asking him to be on the review, which would not require us to have TD effort allocated. Other possible external people might be Mark Raymond (IC), Greg Iles (IC) or John Lane (Manchester?); we should probably aim for three in total. For the CDR, the specification document needs to be made more detailed and other more specific documents should be produced. A preliminary list and the people who volunteered to do this are: o) Cable specification - IC o) Master/slave FPGA I/O specification - Manchester o) VME interface specification - Manchester o) Readout board block diagram - Manchester o) FPGA internal block diagram, master - Manchester, slave - IC o) Xilinx component choice, master - Manchester, slave - IC The costing needs to be tightened up following specification of most of the significant components also. According to the original schedule, fabrication of the prototypes would take place in February 2003, so a PDR in January would seem appropriate. However, some schedule slippage seems inevitable so this may be more like February in reality. Paul will try to get CALICE as a whole to firm up the beam test schedule so that we know more accurately the end-date needed. The FDR is clearly hard to schedule yet but should be sometime next summer. Technical: There was a long discussion on several aspects of the readout board. This is seen as setting the schedule and so is the place where effort should be concentrated at this time. It is very likely RAL TD people will insist on using Cadence, so we should all probably work in this package; IC do already. Also, they tend to favour JTAG testing so this facility should be built in from the start. The 1 kHz readout rate (see above) has several implications. The tile HCAL, as it uses our boards, will be non-zero-suppressed and will total around 3 kBytes/event. The digital HCAL, however, will have most channels removed from readout in the front-end electronics and so is likely to be smaller in event size. Together with the ECAL (19 kBytes/event), beam monitoring and trigger (unknown but likely to be small), then 25 kBytes/event total is a reasonable estimate. A 1 kHz rate therefore implies 25 MBytes/s data rate. Standard VME using DMA can reach 30-35 MBytes/s in theory; this requires D32 transfers which are not "natural" for our 16-bit system but apparently will be needed. This does not give a lot of overhead for other inefficiencies in the system. 64X VME can double this rate but the non-standard aspects were thought too much of a complication to be worth the gain. It might be possible to increase the throughput by using two crates, not chained together but on different PCI-VME cards, still into a single PC. The PCI bus can support around 80 MBytes/s so in principle this could double the readout rate. However, there is very little experience with this and there could be many implications of having two PCI cards, from interupts, etc. Another issue is the ADC sampling speed, as the dead period between the trigger and the readout board being ready to be read will subtract directly from the achievable rate. Osman has suggested a 16-bit, 500 kHz ADC (AD7663) which he saw costed at $16 (and so is likely to be around 16 pounds in the UK). This is 2us per multiplex channel for 18 channels, which would imply a dead period of around 40us total. This is small compared with the 1ms total available at 1 kHz and so is perfectly acceptable. This price is also small compared with the 30 pounds assumed in the proposal, so we might save ~11 kpounds. (This would be useful if the equipment budget is reduced by the PPRP.) This ADC can have serial or parallel readout; to transfer 16 bits within the 2us sample period needs a clock period of 125ns, i.e. 8 MHz or more. This should be straightforward. The data and configuration transfer interface between the master and slave FPGA's was discussed. The scheme proposed in the specification document (dated June 7) was scrapped. Instead, the configuration data will be transfered via a bus connected to all six slave FPGA's, probably implemented as an extension to the VME bus, so that R/W of the configuration data via VME should be transparent. To forestall any issues with compatibility with the test board, where there might be a lot of configuation data, then the address used for the configuration bus should be at least 12 bits. The data transfer will need more thought. It will clearly be optimal to transfer the data during the dead period as far as possible, to minimise any extension to this time. To keep up with the ADC output, then clearly a rate of at least 8 mBits/s is needed. The whole readout board needs a clock of around 10 MHz for data transfer (see above) as well as specifying the timing for the readout sequence to the VFE multiplexer. However, there is a single signal, the sample-and-hold, for which the front edge must be timed to much higher accuracy, specifically around 10ns, corresponding to a 100 MHz clock. It seems easiest to distribute the slower clock, maybe a nominal 12.5 MHz, and then count this up by a factor of eight to get 100 MHz within the slave FPGA only when it is needed for the sample-and-hold timing. Note, this means the trigger, which is the signal from which sample-and-hold is timed, much not be shifted to a clock edge anywhere, but must be passed through the system as an "analogue" signal. It would be good to always consider the compatibility of the test board during the readout board design. It was thought impossible to have identical PCB's for the two boards and having a common mother board with different daughterboards was thought to introduce reliability issues from the extra connectors needed. However, if the master/slave FPGA I/O can be kept entirely generic, then the master FPGA firmware can be used for both boards. Also, the schematics and layout can be done so as to reuse a lot of the common parts of the boards. In principle, only the front half of the slave FPGA and the components upstream need differ. The French groups designing the VFE PCB's have found a cable connector which is compatible with their tight space contraint. Due to the thinness of the tungsten layers at the front of the ECAL, the PCB's only have 4.5mm maximum for the connector height. The proposed connectors are apparently 1.8 mm. Paul will ask them to send us a sample to see what we think. We need to see if both ends of the cable need the samne connector and how compatible twisted pair (with an overall shield connected at the readout board end) would be. We also need the exact cable signal specification, particularly as the calibration signal has changed from voltage to current source and potentially added 5 signals to the cable, taking it to 23, i.e. 46 pins for differential signals. In addition, the first French prototype of the VFE PCB was built with single-ended signals so they may not start to consider the final specification unless pushed by us. Next Meeting: TBD. [Note added after: preliminary versions of the above CDR documentation should probably be available for the next meeting. Would this be possible by early August, e.g. for a meeting in the week Aug 12-16?]