Minutes of CALICE Electronics Phone Meeting, 03/03/04 ===================================================== Present at Imperial: Dan Bowerman, Paul Dauncey Present at RAL: Adam Baird, Steve Quinton, Osman Zorba Present at UCL: Matt Warren Minutes: Paul Matters arising: Adam has not yet compiled a list of the Xilinx software versions used at RAL; this should be done soon. Saeed has supplied the latest firmware version numbers in use by CMS. They are VME 0x1100030D BE 0x12000233 FE 0x13000214 Dave should have the latest BE as he talked to Saeed recently. The FE is not relevant so we should just check the VME version next time a CompactFlash is made. Saeed also responded about the FE-BE interface size in the FE FPGA. This is not a trivial thing to estimate; it depends on the optimisation as well as the number of commands implemented. Osman estimated we would need 7 commands; CMS use at least 20 of the 32 possible values. However, the best thing to do is to get Dave to put the FE-BE interface code into Osman's design, even if unconnected, so as to see how full the FPGA gets. Paul had looked up the ELOG electronic logbook system. The Imperial system manager is reluctant to install it centrally as it does not use secure passwords and so could be hacked, potentially losing the whole logbook. We could install it on Paul's desktop PC but he is looking at more secure alternatives. The problem reports requested in the last meeting are linked from the bottom of Adam's external web page, or are directly available from http://www.ins.clrc.ac.uk/esdg/calice/problems/index.html A link to this page will be added to the documentation page. Hardware status: James Salisbury needs to do some further tests on the CERCs concerning the power-up sequence. This should be done before we leave RAL (although he uses a different crate for this so in principle we could bring individual boards back for these tests). However, it was not clear when he could do this. His existing plots are also available from a link at the bottom of Adam's web page, or are directly available from http://www.ins.clrc.ac.uk/esdg/calice/powerup/index.htm So far it is thought that at least the 3.3V supply needs to come up slower, which should be simply changing a component. The NIM-LVDS module has still not been tested and the cable to connect it to the backplane is not yet made. FE status: Dan and Paul went through some plots of data taken earlier in the week from CERC SER002. These were all with the DACs on but with the latest firmware from Osman only loaded into FE0, so only data from this FE were available. This version of the firmware also only read out 11 of the 12 ADC channels (missing the first). The plots show, in order: 1) The mean value for each of the 11 channels when the DAC is set to 0. There is a very clear top-bottom difference; with one set near -10 and the other near +120. 2) The spread of 400 samples for one of the channels near to -10. The width (sigma in the fit) is around 1 ADC count. 3) The spread of 400 samples for one of the channels near to 120. The width is again around 1 ADC count. 4) The ADC response across the whole range of the DAC. A approximate linear response is seen over most of the range, but the DAC:ADC ratio is roughly 4:1, meaning the DAC only scans 1/4 of the ADC range. Half of the gain loss is to be expected due to the DAC polarity problem; the cause of the loss of the other half is not known. 5) A zoom in of plot 4, showing the first point does not lie on the linear extrapolation of the other points. 6) A plot of the ADC values for several DAC values, again showing the first value is not in a linear region. 7) The ADC response for the low end of the DAC range, showing there is some saturation below DAC values of ~600 counts. 8) The ADC response for the high end of the DAC range, showing no sign of non-linear behaviour. 9) The ADC response when stepping the DAC by single counts in a linear region (1900-2000 counts). 10) A zoom of plot 10, showing no sign of a step pattern, as would be expected if the DAC LSB was being lost. The ADC readings when negative are consistent, indicating the twos-compliment is working and so making it unlikely ADC bits are being lost to cause the apparent DAC-ADC gain mismatch. Plot 10 shows the LSB of the DAC is working, again removing corruption of the DAC value as a possible cause of this. Another problem seen was that the error bit indicating the ADC BUSY line was still up at the end of the conversion was found to be set for the first read of each channel per event, but not for the subsequent reads. Each read should in principle be the same, so this needs further investigation. Osman showed some slides of his status. The VFE signals are now reliably working and can be adjusted by altering the configuration downloaded values. The missing ADC channel problem has been fixed by inverting the clock which puts the data into the readout FIFO; this problem did not show up in the simulation. The ADC BUSY error bit needs further investigation, although the data read out when the error bit is set do not seem corrupted. Paul asked that as the FE code is now getting more stable, a CompactFlash card should be made so it will load to all 8 FEs. This will allow all channels to be tested as above. BE status: Matt had looking into the multiple userReadCommands reported by Osman in the last meeting. He finds the command is indeed broadcast to all FEs, not just the requested one. He has a fix for this which could be tried at a conveninent time. The signal also stays on for the duration of the RS232 command. Neither of these seem to be causing problems, given that the FE load works. Dave did not call in so there was no report. He had said he could try the VME interface sometime this week, so he might be at RAL over the next few days. Future tests: The list of tasks to be done in the short term are, in order: 1) The sine wave test. This will show directly the ADC range and where any saturation kicks in, if within the ADC range. It would be easier to interpret a triangular sawtooth wave (rising and falling slope, not rise and sudden drop) as this should give a linear response if the ADC works correctly. A frequency of 20kHz should give at least one full period per event. Adam will find a pulse generator which can supply a differential signal to do this. It should be a short test, as only a few wave amplitude values will be needed and so could be done tomorrow. 2) External DAC loopback through the front panel connector. This should give the same results as the above, if everything is working. This is a long test as many DAC values should be scanned and so this should be done overnight tonight. Only one or two channels can be fed back in this way. As all the ADCs from one FE share the same control, the others in the FE cannot be set to internal DAC loopback while the one or two channels being tested are taking external input. However, the channels in the other 7 FEs can be tested with internal DAC loopback. Adam and Osman will leave the system set up to do this when they finish this afternoon and Paul will set it running. 3) VFE tests. Adam has exchanged several emails with Julien to try to understand the limits of what we can do with the VFE PCB we have. As soon as the above two tests are done, the VFE should be tried. The first test should be the mplex sequence to check if SROUT can be seen on a scope. 4) Trigger latency. Osman has seen an 18ns delay for the VFE sample-and-hold even just within the FE. We need to measure the total latency for an external trigger through the NIM-LVDS module, the cable to the backplane, the BE, the FE and to the rising edge of the sample-and-hold when it has its minimal delay. So far, almost all tests have been done with a trigger generated in the BE via the RS232. The external trigger path need to be tested more thoroughly. Clearly, the latency test needs the NIM-LVDS module and cable to the backplane. Paris tests: Jean-Charles needs around 3 weeks to get the permits for people planning on going to Paris, so the required information should be sent to Paul asap. Osman, Adam and Matt should plan on going for at least the startup period while at least one Paul, Dan and Catherine Fry should be there at all times to provide software support. Osman pointed out it would be a lot easier to modify the firmware if he had a laptop in Paris; Paul will investigate. Equipment move: It looks like this should be done once the above tests are complete, which could be next week. AOB; Matt asked whether we should get Bob Thompson to "pre-order" the Xilinx FE components so as to start the 15 week delivery time clock ticking; this could be done without a commitment to buy. Adam was reluctant to do this as it could get RAL a bad name. It is worth checking if there is a CMS order going out, which we could cooperate with. Paul and probably Osman will be at RAL tomorrow. Paul will ask Dave if he can come too. Next meeting: At RAL on Thu 11 Mar, starting at 1pm. Adam to arrange a room.