Minutes of CALICE Electronics Phone Meeting, 29/04/04 ===================================================== Present at Imperial: Dan Bowerman, Paul Dauncey, Osman Zorba Present at Manchester: Dave Mercer Present at RAL: Adam Baird, Rob Halsall Present at UCL: Matt Warren Minutes: Paul Matters arising: The current (as of 29 Mar) firmware version numbers from Saeed Taghavi are VME 0x1100030F and BE 0x1200023A. The CERCs currently have VME 0x11000304 and Saeed says there have been "significant" changes but it is not clear if this affects the BE interface. Osman thought the new VME firmware may support BE/FE firmware updates through VME, which would be very useful if so. Status of Paris tests: The VFE tests went throughout most of April. They went very well overall and we learned a lot. However, the "final" V3 of the VFE PCB was not available and so everything has been done with V2 so far. The first three V3 pre-production VFE PCBs should arrive mid-May and be assembled before the end of May, including wafers. They will make a fully populated PCB and two half populated PCBs, one right-handed and one left-handed. We will need to return to Paris to retest with V3 PCBs later in May. Hence, the equipment is still at Ecole Polytechnique although we do not currently have anyone from the UK out there. Unfortunately, Paul bent a pin on the CF writer, so we cannot easily update the firmware on the CERC which is there (SER002) without someone going out and taking a new writer with them. The tests included seeing signals with a Sr-90 source and cosmics on a single wafer. The preliminary results from this were shown by Paul at the LCWS04 workshop which was also in Paris last week. Paul's talk can be found at: http://www.hep.ph.ic.ac.uk/calice/others/040419lcws04/dauncey.pdf The most basic result is that a MIP corresponds to 45 counts, or 3.4 mV. There are further data on SROUT (which is available on V2 after all), the DAC response of the VFE PCB, and Sr-90 and cosmics with a second wafer, all of which have yet to be analysed. The VFE seems to have a very long time constant on the output line when not being driven by the multiplexer such that for triggers at random times apart, the baseline drifts differently for each event and so contributes to pedestal noise. To avoid this, the multiplexer is clocked exactly 18 times for each event so that the last channel is left on the output until the next event. This prevents the baseline drifting. Noise: One big issue with the VFE PCB was noise. This seemed to vary by more than a factor of two within only 10 minutes or so. The best case noise was 8 counts but it was seen to be as high as 20 counts at some times, for no obvious reason. One effect was found to be due to where the crate power cord was plugged in but changing this has by no means cured the problem completely. The differential signals are supposed to overcome most sources of grounding noise. This depends on the grounding of the two systems being as planned, i.e. the cable shield grounded on our end and grounded through a 100ohm resistor at the VFE PCB end. This has not been check explicitly yet. It was thought most likely that the noise originated at the VFE chip input as this is single-ended. However, why the noise fluctuates when nothing obvious is changing is unknown. Adam will try to go out to Ecole Polytechnique within the next week or so to look into these noise issues. Latency: One of the other things measured at Paris was the latency, which seems tight. The times for the trigger signal to propagate through from the input to the NIM-LVDS module with the HOLD delay set to zero are as follows: Time Total Output of NIM-LVDS module 37ns 37ns Output of Dev Board 11ns 48ns HOLD on CERC front panel 46ns 94ns Output of HOLD LVDS-TTL converter on VFE PCB 32ns 126ns There is some latency used prior to the NIM-LVDS module in the cosmic trigger logic which is difficult to measure, but Jean-Charles Vanel estimates it to be around 80ns, making a total of 206ns. This works with the V2 shaping time of 210ns but is more marginal with the expected V3 shaping time of 180ns. However, the 80ns may be an overestimate given measurements made with the Sr-90 source; this needs further work. In any case, it would be useful to reduce the latency in the firmware if possible as this is one of the places we can change things. The total CERC latency contribution is 46ns, so even shaving 10ns off this would be useful (although hard to do). The other place where the latency could be reduced would be on the NIM-LVDS board; bypassing some of the components would help and a method to do this should be investigated. AHCAL readout: The analogue HCAL will now almost certainly use the VFE chip (or some modified version of it) and will have an equivalent of the VFE PCB (but not exactly the same board). Hence, it should be quite straightforward for them to use CERCs for readout and this seems to be their prefered option. They will obviously have to pay for the extra CERCs needed. The extra components have of course not been ordered but it is assumed the boards can be procured and fabricated through RAL. Bob Thompson is due to retire at the end of the year, although Rob was clear that procurement can continue to be done through RAL next year, even if it is outsourced. The AHCAL VFE PCB equivalent may need some serial data inputs to set trim levels via DACs. How much data, what the interface would be (clock, strobe, data, read and write, etc) are not yet specified, but this would clearly require a somewhat different FE firmware design. ADC and DAC ranges: The VFE PCB pedestals are close to the centre of the ADC range, i.e. within a few hundred counts of zero in a range -32768 to +32767. This means the bottom half of the ADC range is unused. The VFE PCB output range is nominally 0V to +2.5V, but the channel-to-channel tolerance is around 100mV or so. Hence, the maximum possible required range is around -0.2V to +2.7V. We should investigate if the CERC input ADC range, which is currently -2.5V to +2.5V can (and should) be set to something closer matched to the VFE PCB, such as -0.5V to +3.0V. If it is possible, then one of the FE modules on SER001 should be modified so this can be tested when we return to Paris. This raises the question of what the DAC range would then be. It currently goes over the range 0V to +1.2V; something effective the same as the ADC range would be ideal. Adam was not sure if pushing the DAC below zero would be possible without a major relayout (which would not be worth doing); he will look into this. One final complication is the analogue HCAL; we need to try and make sure whatever they do is within our final chosen ADC range. CERC SER001: Paul brought back SER001 as it seemed unusable in Paris. He found it would boot OK (when reinserting the CF card as usual) with V3.5 (or V3.6) and the clock LEDs would flash normally. However, almost every time (except once with V3.5), FE access via RS232 would then just return 0xffffffff. Adam has JTAG'ed this board since it was returned and sees no problems at all. As the fault seems to be somewhere in the RS232 path, Matt will go to RAL sometime next week with his laptop and drive the RS232 commands to see if he can duplicate the problem. He will need to take the dev board which he has; the history is that the RAL one was taken to Paris but there was no way to upgrade the firmware there. Hence, when dev board firmware V7 was needed, Matt upgraded the UCL one which Paul then took out to Paris and he returned with the RAL one. Hence, Matt should upgrade the RAL one to V7 (or higher if there is a further version) and this should then be taken back and swapped over again by whoever goes out next. Assuming SER001 can be fixed, then it should also be taken back to Paris. It should have the following modifications done before being returned: o The QDR memories should be mounted o The VME firmware should be upgraded to Saeed's latest version o The ADC and/or DAC ranges should be modified on one FE module Adam will get the memories installed early next week. If this board then works well in Paris, we should return SER002 for at least the first two modifications above at some point soon. Return to Paris in May: The tests with three VFE PCBs in May will need extra items taken out to Paris: o 3 cables of the same length; there is currently one 1m and one 3m cable there. The 1m cable does seem sufficient for these tests, so three more (giving four total and hence allowing for a spare) should be borrowed by Adam. [Note, Bernard Bouquet (LAL-Orsay) who is in charge of the ECAL mechanical support table has started trying to define the cable length which we will need, so we may know the final cable specs soon.] o A new CF writer; Matt knows a cheap online place for these and will distribute information on this. [Note added after the meeting; he used http://www.directusbstore.co.uk/ and in fact he previously ordered for another project http://www.directusbstore.co.uk/cnb/shop/directusbstore?listPos= &productID=67&search=&op=catalogue-product_info-null&prodCategoryID=25 where the URL should all be on one line.] Documentation: This is an area which needs quite a bit of work. Paul would like a complete set of documentation collected together for the prototype which can then be frozen. This includes: o Adam should send Paul the definite final schematics for the prototypes (or the URL to them) as Paul is not sure he has the latest set. o A board write up (i.e. user guide) is needed. Adam has some of the information on his web pages but these are labelled as transient. It would be much better to have a written document which can be version controlled. This should include things such as the link array settings, backplane usable pins, etc. o The documentation web page is very out of date; Paul will try to fix this. Schedule: The schedule for the next month is to test and verify the final V3 VFE PCB design so they can proceed with production of the 60 boards needed for the total ECAL. Assuming no problems and that this goes ahead, then the ECAL assembly schedule has the first 10 layers ready by the beginning of Sept, with the other 20 layers being finished within the following month or two. Hence, we should plan on bringing all our equipment back from Ecole Polytechnique after May and then returning in Sept to start system and cosmic tests with the 10 layers. If this goes well, we would then go directly to DESY for the first beam test in Oct or Nov. The 10 layers are 10 full and 10 half-full VFE PCBs and hence needs 15 input slots, i.e. just under two CERCs. Hence, in principle we could start these tests using the prototypes (assuming SER001 can be made to work reliably). However, we should not plan on this given that we will need more boards quite soon afterwards as the rest of the layers become ready. Hence, we need to work towards having our CERC production finished by the end of Aug. Even then, the production testing time would be quite small, so earlier would be better if possible. This means that roughly speaking, we should aim for o Production redesign finished by end June o Relayout finished by end July o Fabrication and assembly finished by end Aug Clearly, given the history, the relayout is one of the critical issues; we cannot have another six month delay in the drawing office. Given that some modifications are already known, Paul wants the DO to start work on those asap (i.e. now if possible), even if it means more work for them overall. Rob will look into this. With 10 layers, the data rate will be much higher (x15) than with the one wafer used to far, so RS232 will not be practical at this point; it would take minutes per event to read all the data. Hence, it will be necessary to have VME readout working by Sept. The AHCAL are trying to get a prototype VFE PCB equivalent made by June or July, so they would like to try testing this with our boards around that time. This is likely to be in DESY, although again we might try to get them to bring their boards to the UK initially. Except for the possible modification to the FE firmware, nothing extra is needed for these tests. Firmware issues: To finish production redesign by the end of June will require the BE firmware to be functioning, so as to test all the parts of the board which have not been accessed yet. Dave will go to RAL within the next week to talk to Saeed and do the most basic test of trying to load a modified CMS design, possibly with the VME access to the BE enabled. To check the VME access at RAL will require using the CMS test crate; their software should be able to read the BE firmware version number from the CERC with no changes. There is clearly a lot of work to be done on the BE in the next few months. Enough has to be in place to test the board within two months, and full and reliable VME readout is needed within four months. To help with the board check, Osman and Matt should consider if some of the functions to be tested might be checked using RS232 in the short term. These are listed below. For the existing FE and BE firmware designs, modifications can be broken down into things needed for the May tests, things to allow hardware board checks until the BE is working, and things to progress towards the longer term final designs. The list of items for the FE is: o For the May tests: - The link array readout will be needed. - The ADC BUSY on first read should be fixed. - The DAC bit-shift problem should be fixed. - The ADC readout order should be the OUTPUTn order. The reason for the different ordering is now understood so this should be straightforward. - The HOLD latency should be shortened if possible. - Investigate if internal FPGA pull-ups can be used for the VFE type and link array lines. - Ideally there should be only one version number and it should include the FE number in it on readback. - A higher RS232 baud rate would help if possible. o For hardware checks: - Use all the FE-BE traces; e.g. can the RS232 data be sent parallel using all the lines available? - Can the LM82 sensor be accessed and are there other parts of the FE module which have not been used yet? o For longer term developments: - Currently, four bytes are read per channel, of which one byte is unused, one byte has several error and status flags and the other two bytes are the ADC data. The unused byte should be stripped out of the data format before it is put in the QDR memory, presumably within the FE before being sent to the BE. - The AHCAL serial data implications should be considered and possibly some test code could be tried, if it is relatively straightforward. The list for the BE is: o For the May tests: - The trigger latency should be shortened if possible. - The trigger distribution reliability should be improved. - A higher RS232 baud rate would help if possible. o For hardware checks: - Use all the FE-BE traces, as above. - The board serial number is supposed to be readable; can this be done? - Test the I/O to all the backplane J0 and J2 pins which will be used for the trigger I/O. E.g. the logical status of the lines, all treated as inputs, could be made readable, or half could be settable outputs and the other half readable. In either case, simple loops of wire on the backplane could be used to check the connectivity. - Can anything be done with the QDR memories via RS232? Even a simple addressed write and read would test a lot. - Can the LM82 sensor be accessed and are there other parts of the BE module which have not been used yet? o For longer term developments: - The full trigger design, as discussed several times previously, has a lot more functionality than the current version. Could the design move towards incorporating all the final features? A start has been made on this with the status history FIFO which Matt recently implemented. Production modifications: Although it is not yet definite whether the production boards will use a modified PCB design, there are several known changes which would be put in if this is the case. These include: o The reset line which needs a wire on the prototype should be added. o If it cannot be done in the FE firmware, pull-ups are needed on the VFE type and link array FE input pins. o The two FE pins being used which are not present on the smaller (500) FPGA, W16 and Y16, need to be rerouted to another pair. o The ADC and DAC range adjustments may (?) need PCB changes. o The power up/firmware load circuit may need modifications; the firmware usually does not load on power up or when the reset button is pushed, even though this part of the board is effectively identical to the CMS FED (which doesn't have this problem). Until the cause of this is known, it is not clear whether PCB changes are needed. A reminder that Adam's problem report page can be found at http://www.ins.clrc.ac.uk/esdg/calice/problems/index.html where more details and other identified problems can be found. Next meeting: RAL on Wed 12 May at 3pm.