CALICE MAPS Meeting, RAL, 07/03/07 ================================== Present: Jamie Ballin, Jamie Crooks, Paul Dauncey, Anne-Marie Magnan, Yoshi Mikami, Owen Miller, Matt Noy, Vladimir Rajovic, Marcel Stanitzki, Konstantin Stefanov, Renato Turchetta, Giulio Villani, Nigel Watson Minutes: Paul Sensor simulation: Giulio showed results from the simulation; see the usual web page. He finds the 1.8mu diodes collect effectively the same charge from a corner hit (~260e-) as the 3.6mu diodes but have smaller noise and so give better S/N. Note, the noise values given do not include the comparator noise. The obvious question is whether this is the optimal size or whether 0.9mu diodes might give a further improvement. Giulio will try to simulate this situation before the design is finalised. The decision for now was to change to 1.8mu diodes, pushed into the region closest to the pixel corner of the current area reserved for the 3.6mu diodes. Renato questioned the statement in the previous minutes that the deep p-well thickness around the n-wells might not be sufficient if done at the minimum width of 0.5mu. Giulio's previous results from 08/02/07 had show signs of charge still getting into the n-well even within a deep p-well. It would therefore be prudent to broaden the deep p-well region around the n-wells to ~2mu. It should be made symmetric in any case. Giulio should also check directly the effect of changing this width. Sensor design: Jamie reported that the design was not yet complete, although the schedule called for it to be submitted next Monday. However, the foundry has announced a new shuttle run with a submission deadline of Apr 23 and it would be possible for us to submit to that run instead. It was unanimously decided to submit to the Apr run and accept the six weeks extra delay. (Note, in late 2006 we were working to a schedule with a submission date of Apr 17, so this is only one week later than that.) Jamie also reported on progress since the FDR last week. The presampler pixel is now complete and he has laid out a full array of pixels which agree with the schematics, which is a major milestone. The total sensor should be completed by the end of next week (excluding the test structures) and so will be submitted to the foundry for a dry run, to test for technical problems. The 14fF input capacitance for the 3.6mu diodes was checked and does appear to be correct. Changing the distance to the guard ring by 2mu, which is not physically possible, only changes the capacitance by 2fF so little improvement seems to be possible without a major redesign. The preshaper design is still outstanding; a preliminary layout exists but needs further work. The noise from the preshaper is predicted to be lower than for the presampler given the range of input capacitance values we expect. Explicitly, it is expected to give 28e- noise for 1.8mu diodes and 38e- for 3.6mu diodes, again excluding the comparator noise. During the FDR, it was decided to leave the unused monostable for the preshaper in place to keep the charge absorbtion the same for both pixel types. However, Jamie now thinks it will need to be removed as a 4Mohm polysilicon resistor will be needed and this will have to occupy the space of the monostable. The pin-out of the sensor is needed for the DAQ PCB design to proceed. This should be frozen within a week and Jamie will distribute the pin-out list when it is fixed. The idea is to submit the design around two weeks ahead of the deadline as both Jamie and Renato are away from early April. We will also need to complete the FDR as the design was not finalised in time for the first part last week. Part 2 of the FDR was therefore scheduled for either Fri 30 Mar or Fri 13 Apr, depending on Renato's availability. DAQ design: Matt reported on the USB_DAQ board he has developed at Imperial; see slides on the usual web page. His board does not have 1.8V already so this will need to be generated locally. Generally, power could be supplied either through a cable to the sensor PCB from the USB_DAQ board or locally to the sensor PCB. Both options should be possible and jumpers should be included to choose which to use. The USB_DAQ board could supply 3A, while the first round sensor should take ~0.3A. The firmware will need to allow an external clock and control as this is needed when running several USB_DAQ boards synchronised; one will be master and the others slaves. The USB_DAQ board does have LEDs but it will still be possible to operate it within the laser light-tight box as they can be disabled. There was a discussion on the memory requirements. Each first round sensor will give a maximum of ~51kBytes of data per bunch train. The 2 or 4MByte memory extension card planned by Matt is therefore easily sufficient when reading every bunch train, even with four sensors being operated from one board. However, if we wanted to run multiple bunch trains without reading out, then we would clearly be limited. This mode was not thought to be essential and reading out only a small fraction of the bunch trains in such a mode was thought sufficient. The USB interface is via the Cypress chip and the identical component is in use on Matt's functioning I-MAS board. Vladimir showed his ideas for the sensor PCB; see slides on the usual web page. He needs more details on the sensor I/O to proceed. The external analogue inputs in the top-level schematic are labelled as "bias" and "reference"; the former refers to a current and the latter to a voltage. The currents required are all around 100uA maximum and could be supplied by a digital potentiometer (i.e. a current output DAC) or by a high current voltage DAC. The biases are a mixture of current sinks and sources. The voltage references are all up to 1.8V. All would be sufficient with 8-bit precision devices except for the sensor global threshold reference, for which a 12-bit DAC will be needed. This needs to be able to cover a differential 0.9+/-0.9V range, giving an LSB of ~0.5mV, and will probably be implemented using two DACs. The reference voltages should not draw significant current, even under high occupancy (although this will cause a higher power supply current). There will not be logic analyser connectors on the sensor PCB as the space is limited. Instead, it would be straightforward to build a "spy board" which can be inserted between the cable and connector with pins to allow any signal to be picked off. There was also a discussion on the DAQ software. This will be implemented in C++ on Linux and so the Microelectronics group may need a PC and help with the installation; Matt said this should not be a problem. The laser communication between the DAQ PC and laser control PC should be done using sockets and the interface for this can be developed at the laser PC end now. The laser gives a warning signal a few ns before firing but this is not long enough to start the sensor up and get it running. Hence, we will have to operate in one of two modes: o Drive the laser from the DAQ PC via the USB_DAQ which then gives out a fire signal in hardware which is picked up by the laser. o Run asynchronously, where the laser fires independently of the DAQ and the hits are seen at random times in the DAQ bunch trains. The maximum rate of the laser is 50Hz, i.e. a period of 20ms, so for either approach, at most one hit will be seen in a bunch train of 1ms. For the second approach, the probability of seeing a hit is 1/20 = 5% per train. With a train repetition rate of 10Hz, this is only one pulse per 2sec, or 0.5Hz and so is low. The first approach will have a pulse in every bunch train and so would give 10Hz. In both cases, the time of the laser warning signal will be recorded by the USB_DAQ as a logic level detected on a multiple of the ~6MHz bunch crossing clock. The multiple will probably be 2^3 = 8 so this would give a timing roundoff of ~20ns. There will be a need for online histograms. These will be implemented in ROOT and some discussion on which plots are most useful will be needed. ROOT is widely used so there is quite a bit of experience within the group on this. The choices for output format are a custom binary format, ROOT or LCIO. LCIO was thought not stable enough while ROOT is stable and also allows interactive simple analyses. A converter to make LCIO output for use in Marlin will probably be required. Marcel reported that RAL have a CALICE licence server for LabView and this could be used by groups off-site. People who would like to use LabView using this syetm should contact him. Physics simulation: Owen presented some results on machine backgrounds in the endcap, where they are expected to be highest; see slides on the usual web page. He measures the effect in terms of the number of pixels which are inactive due to having hits. The number is given as a function of the reset time, which will be at most 1us = 1000ns. The fractions of dead pixels he finds are all small, even in the innermost ring of the endcap. In terms of hit rates, the innermost ring has 4.5k hits per bunch crossing. This is in a circular ring between 300 and 400mm in radius, which is an area of 2.2x10^5 mm^2. This contains 88M pixels and so is equivalent to a rate of 5x10^-5 per pixel, which will dominate over noise but only within this small area. Marcel showed some results on pixels with multiple hits and hits in neighbouring pixels; see slides on the usual web page. His pattern types defined in these slides are not mutually exclusive, e.g. three pixels in an L-shape would give two of type 1 and one of type 2. He finds the problem is distinguishing between one or more particles within a pixel and believes the values Mokka gives are not physically sensible. It may be worth trying the SLIC simulation as Nigel has previously seen meaningful results using it. Yoshi showed results on clustering; see slides on the usual web page. All his results are with no B field and without noise or charge spread. There was a discussion on how these results can have any impact; to be used they would need to be used in a PFA. Marcel has been looking into this for MAPS with Mark Thompson, who wrote the Pandora-PFA code. It is not clear how different Yoshi's algorithm is from what is already implemented by Mark. Mark is currently cleaning up the code in preparation for MAPS modifications although it is not clear how long this will take. It is however clear that Yoshi's code cannot be simply switched into Pandora-PFA as the latter is not modular. It was not thought worth trying Wolf as this is now depreciated. Anne-Marie showed some results on dead areas from the digitisation; see slides on the usual web page. She sees a 5% degradation of the EM energy resolution when including 4/46 dead pixels. This is effectively a 10% dead fraction, which if randomly sampled would lead to the worsened resolution measured. This implies there is little effect of correlated dead areas within individual showers. Note, the FDR layout actually has 5/47 dead pixels in the logic columns. AOB: Marcel is giving a MAPS talk at the SiD detector concept meeting at FNAL on Tue 10 Apr. The talk is currently scheduled for 15 mins. He will give a practise talk by phone on Tue 3 Apr at a time to be fixed later. He should finesse any questions of collaboration in the short-term, saying we need to show the concept is viable before broadening the effort. Paul asked for volunteers to give a MAPS talk at the CALICE-UK meeting at Imperial on Tue 27 Mar. As Marcel would be collecting the material for his SiD talk, he thought it would be straightforward to give the Imperial talk also. Yoshi is giving a more specific talk on clustering with MAPS at the Imperial meeting also. Next meeting: The FDR part 2 will be held on either Fri 30 Mar or Fri 13 Apr, in R76. The next standard meeting will be on Mon 16 Apr in a PPD meeting room.