Minutes of CALICE Electronics Phone Meeting, 25/02/04 ===================================================== Present at Imperial: Paul Dauncey Present at Manchester: Dave Mercer Present at Oxford: Matt Warren, Present at RAL: Adam Baird, Steve Quinton, Osman Zorba Minutes: Paul Matters arising: Dave went to RAL and had a very productive meeting with Saeed. Note, Saeed's email address has changed to s.taghavi@rl.ac.uk. Adam did not distribute the Xilinx software version numbers, but this should still be done to ensure everyone is compatible. Paul emailed Saeed and Ed asking for the latest firmware version numbers but has not yet heard back. Dave should have the latest BE as he got this from Saeed last week. However, we should still ensure we are using the latest VME firmware also. Paul will chase this up. Paul also got no response on his request for info on the FE occupancy for the FE-BE interface code. Dave thought he might be able to see how big the BE part of this is from his code. The equipment was moved to a different bench in the RAL test area a few days after the last meeting. The crate is no longer on a supply which goes off every night. List of tasks: Paul had posted a list of the tasks which needed to be done before the equipment could be taken from RAL to Imperial. (See the minutes of the cancelled meeting on 19/02/04.) The status of these tasks was o Sine wave test: This requires the FE to be working. Osman reported that he had had problems with the computers at RAL and Imperial holding things up. However, he had now resolved the previous DCM problems and verified the RS232 trigger input was working. He is now trying to check the interface between the configuration RAM and his registers. He will use Chipscope; he is now using it in a different mode as previously he had not been able to get it to work. Osman had successfully written into the event FIFO this morning but the results were not easy to interpret. The FIFO was full on the first event but then stayed empty until event 451, when it appeared to start working again for no obvious reason. Also, even then, only 12 values were read from the FIFO, presumably corresponding to one from each ADC. However, there should have either been 16 per ADC (if the configuration RAM data were being used) or the default of 4 per ADC if it was not. The data from the FIFO were also odd, being either 0 or 4294967295 (i.e. 0xffffffff). Even if the ADC was giving -1, i.e. in 16-bit twos complement 0xffff, then with the 3 error flag bits, this would be 0x0007ffff. Hence it seems the ADC data themselves are being corrupted. One possibility is that the triggers are coming too quickly. Paul can delay the trigger to run at ~1Hz, which should be slow enough. The whole sequence seems to work in simulation, although the loading of the configuration block is too slow to be practical to simulate. Matt suggested just simulating the output bus response, but setting this up would not be a minor amount of work. o Latency: We need to measure the latency from an input NIM signal to the leading edge of the VFE sample-and-hold being sent on the front panel. This will need the NIM-LVDS unit and a SCSI connector cable which can also plug into the back panel. The NIM-LVDS unit has not been checked since being made for us. RAL said they would test this some time ago and it should now be done soon, in case the FE problems are overcome in the next day or so. Providing the cable is also something RAL said they would do and again this should be done asap. o VFE tests, both normal and with DAC: Julien had recently sent a message describing some of the problems with the VFE board we have. However, Adam was not clear how many modifications this would need for us to use it. Julien's message described using it unipolar, which Adam had told him previously could be worked around. Adam will clarify this with Julien. It might be possible to return PCB_A to Paris for some modifications, but it would be good to have it when the FE starts to work. Hence, we should hang onto it, possibly until we get PCB_B; it may be that this is sent to us rather than us going to Paris. Either way, we must aim to be ready by mid March, as that is the time when we can expect to start testing with this PCB. o Power-up problems: This had previously not been look at as it required there to be a reasonable amount of firmware being loaded. Dave was aiming to get his BE code into a downloadable state for this test in the next day or so. However, James Salisbury has already gone ahead and measured the power supply power-up sequencing, using the firmware in the CompactFlash. This was reasonable for the FE but minimal for the BE; it is hoped that the single BE is a small effect compared to the eight FEs. Adam had not yet looked through James' results. As there have been substantial changes from the CMS design, the timings could easily be different. The power consumption in the crate could be easily checked to see that the basic current being drawn is about right. It was not at all clear that the power sequence was the cause of the FPGA unreliable boot-up seen previously. Some weeks ago, it was found that the FPGAs did not boot on power-up but required the CF card to be removed and replaced, which then lead reliably to a correct firmware download. However, Osman reported this no longer seemed to be the case and that power-up seemed to work reliably; why this has changed is not known. Matt also stated that pressing the reset button used to not boot correctly but this has not been checked recently; Osman will try this later. Adam suggested that the firmware designs need to be checked to ensure the DCMs are not coming up at the wrong times, although some of the previous problems didn't even get as far as downloading the firmware, so this could not be the whole problem. Dave asked about where all this information is recorded; apparently the only source is the problem reports which Adam completes and which are on the private RAL web area. These need to be made available to everyone so Adam will send Paul the URL. Matt suggested using an electronic logbook called ELOG, which is free GNU software and being used by Stewart Boogert for the LC Laserwire project; Paul will investigate. Software: Osman reported that he had seen the command which loaded the FE configuration RAM data into his registers (userReadCommand0) issued multiple times in one FE, whereas it was only expected once. This could be a software problem or possibly it could be that all FEs are incorrectly responding to the command, even when sent to the other FEs. A count of the number of times the command appears may clarify things a little. Matt also said the RS232 interface times out when an incomplete packet is seen. This means interrupting the program using Ctrl-C (which potentially could occur part way through a command packet) will not cause a problem the next time the program is run. The program itself flushes the port of any residual data each time is it started up. Equipment move: Despite previously wanting to leave the crate at RAL until both the ADCs the verified and the VFE PCB was tested, it looks like it will be better to bring the equipment to Imperial quite soon, to help Osman's firmware development. Adam is prepared to travel to Imperial when needed. Hence, Paul will try to arrange for it to be brought back to Imperial within the next week, most likely not before Thu 4 Mar. This should be discussed at the next meeting to check the status. Next meeting: Phone meeting at 1pm on Wed 3 Mar. Call into Rob's office on 01235 445140 as before.