bug, although this was still not quite clear. The problem seems to occur when there is an interrupt during a read cycle. Changing interrupt vectors an

Transcription

1 Minutes of the ATLAS UK T1 Meeting Present 17 th July 1996 RAL Adam Connors, James Edwards, Eric Eisenhandler, Norman Gee, Tony Gillman, Stephen Hillier, Murrough Landon, Viraj Perera, David Rees, Tara Shah, Alan Watson. Apologies Bob Hatley, Mike Pentney, Richard Staley. Demonstrator Status 1. Status of the TXM Viraj Perera The necessary modifications were being included into the final design, which would then be checked by Giles during his brief return to Rutherford. Kevin Hatton is to replace Giles and will be testing the TXM modules from now on. It was decided to delay the final authorisation for the production of the next batch of TXMs until more testing had been performed on the complete system this may even be after the September test-beam. Major areas still to be tested include the 80 MHz mode, block transfer and long soak tests. 2. Status of the CPM Tony Gillman for Richard Staley On the problem of the slow data transmission from the Serial to Parallel ASICs, Richard had investigated bypassing the PCB lines and just wiring directly from the ASIC pins, separated from the PCB, to the memory elements. The waveforms looked much better and the data was not corrupted. Work had then been carried out at RAL to lift the data output pins from the PCB for all 13 S/P ASICs on one CPM board. That meant lifting almost 200 pins, and proved to be quite difficult. The board was to be sent back to Birmingham for the re-wiring of the data lines to the memory components. The CP ASIC would not be wired up as this is not needed for the current demonstrator program, and it should guarantee better signal transmission to the memories. The other two CPM boards were to have the same treatment in the near future. The time needed for re-wiring each board was estimated as a week, although experience would soon indicate if this was a reasonable expectation. Other than this fix, all three boards were at the same level of modification and all other tested functions were working. Richard had done some preliminary work on the backplane output from the CPM boards using an extender card and was not very happy with the signals, but had had no more time to investigate due to illness. 3. Status of the TCM Tony Gillman for Bob Hatley There were two outstanding problems. Firstly there was the problem observed at the test-beam that the clock frequency switched to a rather unhelpful 14.3 MHz. This was found to be due to interaction between the two different clocks on the board, and was solved temporarily by removing a shaping capacitor on one of the clocks, but a genuine solution must still be found. The second was the interrupt problem, which may now have been tied down to a hardware 1

2 bug, although this was still not quite clear. The problem seems to occur when there is an interrupt during a read cycle. Changing interrupt vectors and priorities was found to make the problem better or worse with no obvious logic. Bob had identified one chip in the VME interface (VME 3000 chip) that was failing to propagate interrupts when the problem occurred, and was attempting to replace it with a custom PLD. Norman had also contacted Lynx for help. 4. Hardware Tests at Birmingham Steve Hillier The final crate had still not been received, as at Rutherford, and perhaps it was time to start making a fuss, or at least checking that the correct fan tray would be sent, since QMW had had a problem with this. It was suggested that a proper test of the J2 connector of the CPM crates should be made, since all the tests so far would have only checked the J1 part of the VME bus. 5. Diagnostic Software Status Tara Shah A new version of the software including more CPM testing and implementing the model for the TXM had been created. This was running at Birmingham and QMW, but hadn't yet been tested with the hardware at Rutherford, since it hadn't been installed as the default version. In fact it wouldn't have worked initially due to a feature relating to the slightly out of date version of tcl/tk being used at Rutherford. The new version had eventually been installed at Rutherford for more thorough testing in the near future. The correct performance of the model had still to be checked and tuned to the exact features of the real TXM. As yet the model results are not being used for comparison in a user friendly way. Dave had given a talk at a software meeting on the model implementation, and on restructuring the diagnostic software in order to simplify its use. It was felt that the software should be restructured before continuing to build models for the other hardware components. 6. DAQ software for August Norman Gee Norman stated that although the DAQ software had, with some effort, managed to cope with the June test-beam, much work was needed to get it up to standard for the next test-beam. Most of the code was essentially ready for the FADC, CPM and TXM, except for the TCM interrupt problem (which may still be hardware) and a bug relating to control of the Peak Finder Override mode in the TXM. The Babar module was `semi-supported' as a CPM this should be changed to keep the module separate from the CPMs. Only a skeleton was in place for the CPM, mostly related to the memory readout. The control of the module was still to be done now Norman had the CPM programming model. With the addition of CPM code and some work on control parameters, it would be possible to start a run, then work would be required to understand the data coming out, and to debug from there. Unfortunately, Norman would be away for three weeks up to almost the start of the test-beam, so Murrough would have to continue the work since he knows the DAQ system well. Steve would help with the CPM programming and start to learn about the DAQ software at the same time. This would cause some logistical problems since the test system is most likely to be located at RAL. Norman would make available a list of other problems that needed work. It was decided not to upgrade to LynxOS 2.4 until after the test-beam. This had been installed at QMW, and the DAQ software compiled with a few modifications, but there was an outstanding problem with EMU. 2

3 7. Ideas for DAQ software for next year Murrough Landon The present run control via menus was unpopular, and Murrough proposed replacing it with a more user-friendly GUI, probably written in tcl/tk. This would be particularly useful for configuring the many cards in the complete system, and also provide an opportunity to clean up the code although it appeared Norman had done much of this already. Other than the extra work involved writing the new interface, there is one major problem. That is the large memory requirement of the X-based program, which might be a problem in an already stretched 16 MByte MVME167. One solution could be to split the interface over two systems, with a simple program running on LynxOS communicating with the tcl/tk application running on a different system. This has the disadvantage of added complexity. Alternatively buying more memory for the 167 might be a simpler solution. Murrough showed some ideas he had already been working on for run control and card configuration. It was thought that this would be a great improvement, but run control from a dumb terminal must be preserved too. General Status and Plans 8. ASIC and MCM Developments Viraj Perera Viraj presented plans for producing an ASIC with many prototype circuits to gain experience for the final ASIC design. This would be submitted to the December Europractice run, and would cost about 3K. Elements included in the ASIC would be test designs for the phase locked delay, 160 MHz and 40 MHz timing calibration logic, 160 Mbit/s transmitter and, if space permits, fast adders and multipliers. Costing constraints mean that the size should be restricted to a mm 2 chip, but if it is felt that some elements should not be left to the next round, then two chips could be submitted. Two chips of the same size would save on testing costs as the same test card could be used. It was felt that some priority should be placed on the adder/multiplier development. Viraj had attended the Cadence course which was useful for some aspects, but had no MCM specific work. There will be no new MCM courses for the version of the package bought by RAL, but hopefully the old documentation can be obtained. Viraj then discussed the possible MCM technology choices and their implications for power dissipation, packaging and chip removability. For tight power constraints, an Aluminium substrate appears to be the best option. Plastic Ball Grid Array (PBGA) is another potentially cheaper choice for MCM packaging. On the AMCC alternative to G-Link, Viraj had established that bare dies could be supplied, even if this is unusual. There is the problem that that are designed to run at 50 MHz +/- 20%, which in principle may be alright for 40 MHz running, but should be checked. Alternatively schemes could be devised to run at them at 50 MHz but not use all of the bandwidth. Timescales for trying out the AMCC option, probably combining this with a first trial of MCM design, were discussed. It may be possible to have an AMCC based link ready for the April test-beam allowing a couple of months for the MCM design. The custom G-Link alternative design that had been discussed in the last meeting would definitely not be ready to be integrated into the demonstrator for April. 3

4 9. BCID Developments David Rees Dave had been working on a more detailed simulation of the CFD algorithm in order to compare performance with digital BCID. This duplicates some of the work done by Jacques Colas, but it is useful for us to have a full understanding of the issue. Dave needed more time to look carefully at the noise and threshold effects and would then write a document summarising the results. 10. BCID paper Norman Gee Copies of Ian's thesis and various figures were now available, John and Norman were undertaking the task of distilling them into the outline of a paper. 11. Simulation status and programme Alan Watson Alan stated that there was still much work to be done to finalise and justify trigger design choices in terms of the physics performance offered by the complete trigger system. He had attempted to list all the parts that still needed work and had categorised them in six areas: ffl Front End Processing and Data Format Assuming digital BCID, the ADC type (8 or 10 bit, 40 or 80 MHz) and dynamic range must be chosen, and the implications of compressed data investigated. The nature of the noise also plays a large part in these decisions. The issue of trigger tower definitions comes under this heading. Simulations so far suggest that summing different detectors across transition regions will be unnecessary, which is good, but should be checked with an up-to-date simulation. Use of the presampler has not been considered yet, and the FCAL trigger tower definition still needs work. ffl e=fl Trigger Although the cluster algorithm itself seems to be stable, the declustering is still a potential problem especially for Level 2. Classification of trigger codes could also be usefully looked at. ffl Jet Trigger Both the cluster definition and the declustering are still undecided. No evidence exists at the moment for a preference for any one algorithm, so more simulation is needed to check that the simpler 0:4 0:4 option is viable. The fact that this proves to work well in existing simulations relies partly on the small jet size predicted by PYTHIA, but how much can this be trusted? ffl Missing E t Trigger A decision on the ffi granularity is still needed, taking into account other factors degrading the resolution. ffl fi/hadron Trigger The exact physics requirements here are still unclear, so it should be considered as of secondary importance, and an algorithm found to fit in with the rest of the architecture. ffl Other Issues This includes issues such as luminosity monitoring, other triggers, such as Sum-E t and the currently unclear problem of beam-halo background. Alan had circulated a long note summarising the current areas of interest in order to prompt a discussion. This had had little response. It was commented that this is an area where help from other institutes could be fruitful. Another idea that should be considered with front-end processing was the effect on the trigger if small signals were let through the system with no BCID processing. 4

5 June test-beam run 12. First look at data Adam Connors Adam had checked that the data transfer through the DAQ seemed to have worked correctly to the bit level. One problem that persisted from previous test-beams was FADC `slipping', which was observed to be the same with the old DAQ chain, and still appeared to happen with the new DAQ. However it was more difficult to be certain about what was happening with the new DAQ, since the TDC stopped working, so cuts on trigger phase relative to the clock could not be made. Adam showed an example with the new DAQ where the FADC had slipped one tick, but the TXM seemed to have the data in the correct time slice. However, he also found examples where the TXM data seemed to have slipped too. This is perfectly understandable given that no attempt was made to adjust TCM delays to time the TXM in correctly. Slightly more puzzling, but perhaps still OK, was an event where the TXM and FADC seemed to have slipped two clock ticks. The data had been copied, and was available in various places Eric had the original tapes. It was stressed that the Babar data should be checked out in the near future. Norman and Eric also had some plots showing the data flowing correctly through the DAQ system. Mike and Bob were at CERN uncabling the system from the old test-beam setup ready for th new run. August/September test-beam run Overall Scenario Tony Gillman Tony showed the SPS schedule which indicated the Tile Calorimeter run starting on 21 st August. In fact they requested a change in schedule meaning they would start on 29 th August and run until 16 th September. The configuration of the detector would be three layers consisting of 0:2m 0:2m towers, the new `Module 0' detector being the middle layer. The detector would be situated in H8B and access would be guaranteed up to 21 st August. It was not clear if there would be significant access after this date. Also Tony was not sure where precisely H8B is, and therefore if perhaps the Level 1 crates need to be moved. The Tile schedule should mean that the detector is complete and in place by 15 th August, but Mike would find out more information during his visit to CERN. Tony then presented his four stage test-beam plan. ffl Stage 1. Cabling to Module `0' and 1994 linear signals must be done. Tony proposed to just use the front layer of Module `0', but sum all layers of the 1994 signals. Sten had been involved with making sure there were sufficient outputs for us to take signals, we should check this has been done for Module `0' it should be OK already for the 1994 modules. Several 40m cables (possibly 80m depending on location) should be laid, and also a couple of optical 80m cables. The initial DAQ system would just consist of the FADC TXM CPM(BaBar) chain in order to set up a simple system which should be well tested before going to CERN. The use of 1994 or Module `0' signals means that we should start to use the TXM lookup tables. ffl Stage 2. Next a second full FADC to CPM chain should be added, and then we would be starting to exercise the backplane. 5

6 ffl Stage 3. Next we can test out the Heidelberg front-end module, if it is available, and use it instead of a TXM. This could be used to make a full third chain meaning the third CPM should be available for use too. Extra software will need to be written to test the Heidelberg module, although as far as the data chain is concerned, it should behave exactly the same as the other TXMs. ffl Stage 4. Finally different data links can be tested. It would be good to try out the VCSEL links which have not been part of a test-beam so far. Tony presented a new schedule of work before and during the test-beam. The CPM again has been delayed due to the time taken in finding a solution to the ASIC problem. Tony also showed the timetable of peoples movements. It was clear that careful planning would be needed to make sure there was enough effort in the right areas in order to be ready for the test-beam. On priorities, it was clear that the backplane and integrating the Heidelberg module were the most important objectives, with the VCSEL testing being less important. 14. Organisation for the test-beam Discussion Steve, as test-beam coordinator, was given a list of jobs that should be seen to over the next few weeks. Important tasks included overseeing the equipment, contacting other groups and making a plan for the manpower at CERN and in the UK. There was also a discussion of how best to do system tests, whether with the diagnostic software, DAQ software or offline with recorded data. Some tests could be done with the diagnostic software, though soak tests are limited to the DAQ system at the moment. Dave would be working more on the model with the idea of being able to perform soak tests via the diagnostic model, but it was clear that the possibility of analysing data offline shortly after a DAQ run was still vital. Reports on Recent Meetings 15. TDSG and Institutes Board at CERN Norman Gee The Institutes Board included a report from Cracow, the presentation of the summary of trigger activities (report included in minutes), a report from the referees meeting, guidelines for the proceedure for giving ATLAS related talks, and a discussion of changes to the Trigger/DAQ steering group in order to make it more effective. The Steering Group meeting had included a long discussion of the situation with the Compact Demonstrator program, and it was decided to endorse the view of the referees to stop the project after the development of TASIC2, ie not to proceed to the full PASIC production. There was also a discussion of the need for a Level 1 URD Level 2 had already gone through many iterations on their URD. Finally there was discussion of ATLAS introducing a common management scheme (using some form of Project Breakdown Schedule, or PBS). In both meetings the use of the new building 40 proved to be a hot topic. Eventually it was decided to leave the assignment of rooms to Nick Ellis. Building 40 has about 50 rooms, each of which is meant to be for 2, 3 or 4 people. The UK group had been assigned one office with several occupants, one being Nick. Many people from all groups were unhappy with the office arrangements. Suggestions of common working areas by many were unpopular with CERN. Norman also had an ATLAS schedule of activities up to the start of physics in 2005 that had been presented at the plenary. 6

7 16. Level 1 Trigger Meeting at CERN Tony Gillman There were only three items in the meeting. Firstly Tony had summarised the current demonstrator status. Ulrich then presented work on optical analogue data transmission, which was quite enlightening. The VCSELs he had tested turned out to be no better than the more conventional LED setup. The LED actually outperformed the VCSELs in dynamic range, and is also cheaper. There was also some question of the radiation hardness of VCSELs, which, all considered, makes Monnier's enthusiasm for VCSELs difficult to understand. Finally there was a round-table discussion of the integration of the groups activities now the Swedish program had been stopped. Ideas for the promotion of collaboration on various parts of the system were proposed, along with encouragement to keep lines of communication open. 17. Level 1/Level 2 Meeting at CERN Eric Eisenhandler Eric had presented the ROI information currently proposed to be formed by Level 1, which had provoked much discussion. Level 2 were in general shocked by the lack of information, so Eric then went on to describe what extra information could be made available, and of this extra data, which would be easy to provide, which hard. There would be a follow-up meeting to discuss this further in the near future. There was also a presentation by Nick on the Muon Interface. The Muon URD had already been completed. 18. Discussion with Calorimeter community Eric Eisenhandler This meeting was a follow-up to the front end electronics meeting. It was primarily attended by LAr people, but also some Tile Calorimeter were present. The first part was dedicated to BCID with Bill Cleland starting by presenting his analogue BCID. The main drive behind the CFD technique was that it saves a little in latency (perhaps two ticks). One novel feature was the simple transmission of signals below 5 GeV, without BCID. The effect of this needs some investigation. Bill Cleland had built some NIM hardware to try out analogue BCID. There was some disagreement about ADC noise levels at this stage. Dave then talked about digital BCID and the problem of resolution of close together signals was raised. Digital BCID does quite well with these, but Dave isnowinvestigated how the CFD technique works, and perhaps there is little difference. The general feeling was that digital BCID was fine, and a couple of ticks latency was unimportant. The meeting became rather less amiable after Jacques Colas presented his ideas for the trigger front end, where a major feature was scope access for the calorimeter group. The Level 1 group stated strongly that they should be responsible for building everything beyond the analogue cable from the detector. Just as we need to discuss the specification of the analogue summing to be done by the calorimeter group, they would discuss with us the specification for their access to the analogue signals in the counting room. Lists were compiled saying who was interested in which areas of the data chain. Since the meeting there has been little communication on this issue. However, it seems clear that the trigger tower sums will have to be done in close collaboration with Teiger, and so it might behelpful to arrange some talks in Paris to get this started. 7

8 Next Meeting There will probably be a small test-beam planning meeting before the next full meeting. The date of the next full meeting is: Friday 16 th August, 10:00 am, RAL 8