Minutes of CALICE Electronics Phone Meeting, 06/09/04 ===================================================== Present at Imperial: Paul Dauncey, Osman Zorba Present at RAL: Adam Baird, Rob Halsall Present at UCL: Matt Warren Minutes: Paul Production status: The board is ready to go although no quote has been sent by DDI yet. Darren Ballard is back from his holiday and has finished everything needed. The layout has been checked by Chris Day as part of the internal quality control. The request for a quote was sent to DDI on the day of the last meeting, Thu 19 Aug, which is more than two weeks ago. They have taken quite long over quotes in the past because they do a thorough review of the board. (For CMS, they came back with a long list of changes, although we will not make any further changes unless absolutely necessary.) For the prototypes, DDI only did the PCB manufacture, not assembly, so they may be reviewing the assembly step in some detail. [The quote did arrive just at the end of the meeting; see below.] Prototype tests: There are still some outstanding parts of the prototypes which have not been tested. While we will not change the production boards at this point (unless a very major error is found), we need to continue with these tests so as to be sure we can test the production boards when they are returned. Osman incorporated the internal pull-ups (as suggested by Adam in the last meeting) and can now read the LM82 for FE0. He cannot access any of the other FEs as they seem not to be receiving a clock from the BE. They work fine with the RS232 code so he assumes this is due to the BE firmware (from Saeed) having disabled those clock outs. He tried using Matt's BE code but could not get it to run. Matt will come to Imperial within a few days to fix this. Testing the remaining QDR lines has not been done but should be easy to do. The BE-backplane trigger line tests have also not been done. The power-up/reset problem was looked at further by Paul. As suggested, he tried to get the firmware to reload after having failed to load from a push-button reset. This worked every time he tried it (only a few times) but gives confidence that a software reset can be used if the boards don't boot. More work is needed, specifically on how to tell in software that the firmware needs to be reloaded. Paul also received some information from John Coughlan on the System ACE programming via VME which Paul has not yet had time to look through. Production firmware: We need now to move to having final firmware, preferably before the production boards are returned, i.e. by the end of Sep. After the production boards are JTAG tested at RAL, it seems most sensible to bring them to Imperial rather than take the crate to RAL, unless significant hardware errors are seen. The main changes to the CMS firmware which are needed were listed in an email send round by Paul on Wed 19 May, which is copied at the end of the minutes. Rob has not yet found anyone with the necessary expertise to take over the work from Saeed; Ed Freeman is not available. The division of the work was then discussed. Merging Osman's existing FE module into the FE command decoder from Saeed was thought to be relatively straightforward. Osman will try to do this and will come to RAL to talk with Saeed, possibly on Thursday this week if he is available. The BE work was thought more difficult. Rob will try to find time for Saeed to do the modifications to the QDRs to use all the address lines; Saeed may do this within the FED code anyway to keep them compatible. Matt will need to talk to Saeed to figure out how to get the trigger firmware incorporated in the best way. It seems he will have to do this himself, at least for now. (If Dave Mercer comes back to work, then he would clearly help out in this area.) System tests: The production version of the VFE PCBs have now all been assembled (except for the wafers) and are under test in France. The wafers are being carefully retested before being glued onto the VFE PCBs. There are now several fully populated PCBs including wafers for which results were shown in the Durham workshop last week. Hence, the VFE PCB production is on course to produce the first ten layers by the end of the month. The first tests of our production boards with the VFE PCBs will be a cosmic test of these first ten layers. This is an order of magnitude more data than we previously read out, so the RS232 port would be too slow; we have to use VME for this. However, we could live with the restricted QDR address range (2MBytes rather than 8MBytes) for this first round of tests. Also, if there is no trigger history for the cosmics, this is probably OK due to the low rate. However, it is clearly better to have these items if possible. The ten layers needs only two CERCs (assuming all channels work) so this means only two production CERCs are needed immediately. However, it does mean a common trigger to both boards will be required. After the cosmic tests in Paris, the next step is to take the ten layers to DESY for test beam running. The system would then be expanded to the full thirty layers by the end of the year, which sets the timescale for the other seven CERCs to be assembled. Note also that in this first test beam, while the 2MByte memory would not restrict us too much, the trigger time history would be required, as the possibility of multiple beam particles would not be negligible. Production costs: The quote from DDI arrived just as the meeting was finishing. The costs quoted are as follows: SMT cost 2x .bŽ£ 300.00 No Nre (rebuild) Pcb Mfr 9 off 7 day Ž£ 682.77 10 day Ž£ 568.98 15 day Ž£ 455.18 Tooling and test Ž£ 900.00 Pcb Assy 9 off 5 day Ž£ 1,292.49 7 day Ž£ 1,189.09 10 day Ž£ 1,137.39 15 day Ž£ 1,033.99 Pcb Assy 2 off 5 day Ž£ 1,807.72 7 day Ž£ 1,663.10 10 day Ž£ 1,590.79 15 day Ž£ 1,446.17 Pcb Assy 7 off 5 day Ž£ 1,335.26 7 day Ž£ 1,228.44 10 day Ž£ 1,175.03 15 day Ž£ 1,068.21 No tooling cost as rebuild, There was some confusion about whether the tooling and SMT applied to all combinations. It was also assumed the prices did not include VAT. Adam and Darren were to clarify these points tomorrow morning and Paul would circulate his calculation of the total price so we could decide on how to proceed tomorrow. [Note added after the meeting; there was confusion at DDI about the board and an addition cost for Front end Cam/Eng/AOI Ž£ 3,652.00 has been added on.] Next meeting: A phone meeting on Tue 21 Sep at 2pm. ======================================================================= Message on firmware changes previously emailed out by Paul on Wed 19 May: BE firmware changes: o Pin layout changes; reroute signals to different pins. o Backplane connections; remove or disable SLink code and install trigger line (i.e. the trigger input on every board). o TTC signals; remove or disable. Ensure the event counters, etc, used by the QDR/VLink are still OK. o QDR control; the CALICE QDRs are actually double not quad data-rate, so the only change needed is for the extra address line(s). o Trigger code; this includes the VME control interface and event data readout and most of the backplane I/O. This is enabled only on one board. FE firmware changes o FE-BE interface; the FE needs to change from using the RS232 to using the serial commands (for configuration and monitoring) and the fast burst to the QDR (for event data). The trigger code needs to be controllable through VME and it seems sensible to use the serial command interface for this. However, there will be up to ~100bytes/event of data from the trigger itself which needs to be read out. Given the aim is to buffer up to 2k events on board, then to do the same with the trigger data will be ~200kbytes. This is too big to store within the BE FPGA. The obvious possibility is to store it in the QDRs along with the FE event data. However, the modifications to the QDR firmware to allow these data to be merged seem difficult and a different approach would probably be easier. Clearly, if not buffered, then the trigger data need to be read out for each event before the next trigger. At 2kHz, this would imply a readout rate of 200kBytes/s, which should be possible in VME. There are (at least) two possibilities; o Use serial commands to read the data out. o Switch the VLink input to take the trigger data during a spill so it can be read directly (i.e. fast) from VME. Then after the spill, switch the VLink input back to the QDR, so the FE event data can be read. This second possibility needs some thought; the VLink only sends up one event at a time to the VME FPGA, so the trigger would have to package the data into a header, etc, similar to FE data so that it is handled correctly. This would also prevent any access to FE data during a spill (although for the first possibility, it would never be clear if there was enough time to use VME cycles on the VLink data anyway so it probably comes to the same thing). Finally, we have previously discussed the need to read at least a trigger counter from each board per event so as to be sure all boards saw the trigger. It would make sense for this to be sent out on the same path as the trigger data, so two different readouts for data from the BE don't have to be implemented. The board which is actually being used for the trigger would clearly send out both the trigger counter and the trigger data itself, preferably as one packet.