ATLAS-UK Level-1 Calorimeter Trigger Meeting -------------------------------------------- Wednesday 8th December 1999 - Birmingham Present: Bruce Barnett, Ian Brawn, Eric Eisenhandler (chair), John Garvey, Tony Gillman, Bob Hatley, Murrough Landon, Ed Moyes, Viraj Perera, Tara Shah, Richard Staley, Scott Talbot (minutes) LVDS tests - Richard ---------- The error rates on the LVDS tests were degraded by power supply noise, especially on the receiver, so Richard added capacitors, etc. to compensate. Before Stockholm the tests were with 1 cable (4 channels) and had a large error rate. Current tests are with 2 cables (8 channels) and most channels are error-free (rate < 10^-13). The worst channel has an error rate of < 10^-12. Test have been carried out with cables longer than 15m and equalisers to compensate for the high frequency loss over the cable. The error rate is < 10^-12 on all channels. The eye diagrams are wide and clear with signals above the LVDS receiver threshold voltage. Future tests will use more realistic data (eg. more 0's) and check inter crate communication. The TTL will also be used instead of the current crystal oscillator. The DAQ software will be used to capture the errors and check the error detection schemes. New cards without the supply noise problems will be made. Tony asked about the errors Paul Hanke observed in bit transmission of strings of 0's followed by a 1. Richard thought it might be because Paul wasn't using equalisation. With the latest FPGAs it is possible to check errors using playback data. In Stockholm the LVDS decision needed to check transmissions between crates. This test is urgent and Richard said this would happen quickly, possibly as early as tomorrow. It will use the same rack but a different crate with its own power supply. It is hoped that the remaining errors are coming from the chips and new boards, to be built sometime next year, will have lots of precautions against this. This is separate to the LVDS decision. Paul pointed out that the observed error rate of the worst channel was already 4 orders of magnitude better than we need. Eric said the tests need more background VME activity. Richard put an interim report about the tests on the web, but has not received any feedback yet. G-link - Bob ------ There are 4 sets of transmitters and receivers. 2 for use with twisted pair cables and 2 with co-axial cables. The twisted pair tests are error free over 12m (2*5m + 2m) cables over night. Future tests will use the same cables as Richard. The co-axial cabletests are error free over 2m. Currently the tests are differential, but can be run single ended. Longer lengths are being made (up to 20m). Other makes of cable can be used. S-link - Viraj ------ Tests of transmission from 1 block to the other were successful over 1m length. This test was with electrical signals not optical, so it should be OK to use over the 100+ m optical cables needed to reach the surface. Currently on 33MHz tests (100MBit/s) but we need up to 160MBit/s so the present S-links might not be fast enough. Also the whole experiment will be using S-link so it should be reliable. ROD prototype - Viraj ------------- Version 1 of the specs have been released and James is working on the design. 5 FPGAs will be needed for this design and it may be possible to get 2 channels into one FPGA. Although only 150 FPGA inputs are used the design is such that more can be used if necessary. The final board will be 6U and have 16 channels. It is not as densely populated as the DSS. Serialiser status - Ian ----------------- The last report was of the 'final' design, but since then the FPGA has been redesigned and can cope with the possible 12ns LVDS skew. The software has also been upgraded as it can now target Virtex devices, route the DLL in more stable configurations and interpret constraints more zealously. And as such it is now more difficult to get a design that meets our timing requirements. This is currently being explored; overall the latency is about 2 bunch crossings. In the future Ian will use a double CMC daughter board for DSS to test the hardware implementation of real-time and readout paths. He will also test some elements of the CP chip and may be able to provide a data source for the ROD tests. The deserialiser FPGA (which looks like a CP chip) is needed for testing designs with the serialiser RAL215 chip and the CP chip, and has many things in common with the serialiser. The design is easier as there are no worries about latency and it is basically a mirror of the serialiser. The final spec and FPGA design should be ready by the end of the year, followed by the receiver FPGA, ROC FPGA and serialiser test module design. Serialiser tests should begin by the end of March 2000. Paul asked if there was any way to design it so the backplane transmission could be tested. Ian says this would make the board far too complicated. John asked why consider Virtex-E? Virtex-E is smaller, faster, with more DLLs and RAM. It also supports LVDS. The Virtex design is fully portable to Virtex-E. The benefits of the design are being investigated, but the chips might not be available until Spring 2000. CP 'chip' - Viraj --------- Version 1.2 of the specs are ready for review. Some issues arising are the handling of saturation and transmission errors, and whether it will be an ASIC or FPGA. The deserialiser is based on Ian's work on the serialiser, so the main work needed is on the algorithm block. Hopefully it will be an FPGA, but current FPGAs might not have enough gates and might be too slow. But it will be tried as hard as possible to make the FPGA work. Paul pointed out that the design used the naive latency calculation from the TDR and this could be wrong, and even an ASIC might be too slow. Also the TDR latency calculation might have missed some of the ideas that arose in the TDR. If the FPGA's latency is within the TDR envelope then it will be used. The decision has to be made within a few months. Paul had four comments: 1) The number of inputs can be reduced from 120 to 108. 2) BCmux error detection relationship means error could be within the BCmux part, so it is necessary to kill two cycles if an error is detected, not one. 3) Thresholds, etc. should be named so the software can be designed. 4) There should be a standard co-ordinate naming scheme. Coding for the FPGA is very complicated. Norman is interested in a software package available that converts from C to VHDL, but it may be very inefficient. We need to find out if anyone else has used it. CP module - Richard --------- The specs have been updated, but there has not been much change. CMM prototype - Eric ------------- There has been no response from Stockholm about whether they could build the prototype. However, Viraj thinks the UK should have enough engineering effort available. [Note added 22/12: Stockholm thinks it could also find effort to do it, but would be more stretched so the decision is for the UK to build this. EE] Backplane - Richard --------- Richard and George will use backplane evaluation cards for testing the ground bounce. George has been looking on the web for more information about backplane connectors, but there is nothing to show yet. Very little other investigation into the connection has been done, this is urgent and needs pushing. At Stockholm crate mechanics were mentioned and Sam was going to look into it, but there has been no word about it yet. Timescales - Tony ---------- The future testing plans were described. The first phase is expected to begin in the first quarter of 2001 and will involve only UK modules. Everything will be connected together, with the DSS emulating other components. Individual modules will already have been tested. This test will check the interfacing between modules, the real time data flow, and let us explore the system timing. The second phase will be a LVL1 slice test and should be in the second quarter of 2001. It will involve the prototypes for all systems. This will let us study the whole chain and check the performance of the DAQ, software, the data transport to LVL2, the interface to non-LVL1 systems, etc. For this test a lot of hardware will be needed and everything must be available in time. These tests may be held in Heidelberg, Mainz or the UK. The PDRs of the new modules should be next year's internal milestones. There are two reviews imminent: The PPr MCM reviewers are Christian, Paul B-T, Viraj and Uli. The documentation has just been released but it contains many references to Ullrich's thesis. After a thorough reading the plan was to hold a 1-day review in Heidelberg, unfortunately it is not possible to fit this inbefore the end of the year so it will be in January. The CP ASIC/FPGA reviewers are Paul B-T, Ullrich, Sam and Richard. The documentation has been available for several weeks and there have been extensive comments received. Again is is hard to get everyone together before the end of the year. These PPr and CP reviews may now be held over a two day period at RAL towards the end of January. TCM - Bob --- The main features of this module are to distribute the timing and control signals from the DCS. It has to be compatible with the CP and JEP crates via backplane connectors, and with the PPr crate through cable connections. The backplane and front panel therefore both need connections. Areas still under discussion are the fanout method for the TTC signals, the allocation of the pins in the backplane and which VME version/format to use. The design of the daughter card is waiting for comments from within the UK, and after agreement it will be circulated to everyone else for their comments. Is multidrop a sensible method for the fanout in a high-precision timing system? Eric added that the TTCrx chip final version should have been ready in Spring 2000, but has now been delayed by two months. TileCal - Paul ------- Incomplete draft specs for the liquid-argon receiver stations are available by anonymous ftp from: ftp://cleland.phyast.pitt.edu/pub/atlas/reciever/reciever.ps There are three kinds of output: T (for the FADC on the PPr), S (for summing on the receiver) and M (for monitoring). There are 16 receivers and 1 controller per crate. The backplane distributes power, control/configuration data, and return monitor signals to the controller. The receiver has a motherboard, input daughterboards with a variable gain in the range 1-4 controlled by 12-bit DACs for ET conversion, an interconnect daughterboard, eight output daughterboards and four monitor buffer daughterboards. There are many different types of interconnection boards but the receivers will not be equipped with the unused ones. Murrough asked whether the software would be able to tell what type of interconnect board was in place. Will the gain be under our control? How is the design going to be reviewed? A LVL1 person should be involved. EDMS - Eric ---- Eric has tested the EDMS by updating the User Requirements Document (after getting the ownership of the file changed) and putting up other files in various formats. The archive tree is a bit complicated, but the user interface is improving, and the designers would like feedback from users. It is easy to log into the system as a guest, but from some sites authorised users are unable to upload anything. The reason for this isn't clear, but seems related to ftp and firewall issues. It is possible to get into EDMS from the ATLAS home page, and it will be linked from our web pages. There are questions about what level of document should be put in. It is suggested that final specs are certainly appropriate; Nick would also like to put up important talks such as LHCC referees. Newsgroups - Paul ---------- The mailing lists we currently use have wide distribution, so some discussions have gone on in private using ad hoc and inconcsistent email lists. This means some interested parties can miss out on various parts and uninterested parties receive unwanted mail. We should look into changing to an organised newsgroup system. Setting up and maintaining a server would not be too hard. The are two obvious options for the newsgroup, either the ATLAS news server or HyperNews (as used by BaBar). The ATLAS news server is fairly simple but it doesn't seem to be used very much, and it is not clear whether we could protect it within our group. The HyperNews system is much more user-friendly, but it does not work on an NT server. We should try to find a suitable server and someone to set it up, and then try a trial installation of a LVL1 calo trigger newsgroup. We should also see if there are any other contenders. T/DAQ commission - John ---------------- The T/DAQ commission proposal document has been sent to everyone for discussion. The proposal is that the commission will be headed by a single Project Leader, who has overall responsibility and seems to be able to add or remove subsystems at will if s/he so desires. The Project Leader will nominate a Project Coordinator and Sub-system Coordinators for assistance. The Project Coordinator will be responsible for the integration into the rest of ATLAS. The proposed Sub-systems are: - Trigger/Event Selection - Level-1 - Data flow (from experiment to storage, including LVL2 and EF) - Online Software (from experiment to storage) - DCS Configuration Data - Eric ------------------ Eric presented a crude list of the information we need to store during running so that we know the overall setup of the LVL1 trigger system at all times. The list has also been circulated by email to all of the software group. The list is only a first look so it is missing many details about the number of bits, etc. as these haven't been considered yet. If any details are missing let Eric know. DAQ-1 - Murrough ----- The pre-prototype of the final DAQ -1 software exists and is distributed on CD-ROM with regular updates. It was tested on a small system over the summer. The software has two major components: Dataflow (fast data transport) and Backend (slow support software). The dataflow software is not suitable in the small scale environment we will be using for the next tests as it requires several LynxOS processors to emulate the final Readout Crate. The DAQ group is working on collapsing their system into a single crate, but more work is required and until April 2000 they will be concentrating on their Technical Proposal. After that it will be at least 3 months work to produce something usable by detectors in the test beam. Several systems would like it to be ready for this year's test-beam work, so that is a problem. Overall the DAQ -1 backend software is only a prototype, so it is evolving with a few rough edges and is incomplete. It consists of many components, some of which are complex. But in general it is well documented and we can use it with support from the DAQ group. In the short/medium term will continue to use our existing software and migrate towards the DAQ -1. Our software needs to be as independent as possible of how we evolve. When to make the changeover is a subject for discussion, there is never a good time to do it as there will inevitably be a period when testing is affected. The lack of source code for the DAQ-1 software is a problem as it would be nice to see how they do various things for learning purposes. It would be more efficient for us to have it, but the DAQ group feel they would have to provide more support than they would like. In the UK our software in running on old LynxOS processors, but we are developing network VME access so that we will be able to run our software elsewhere. This already works for the diagnostics but still needs to be done for the DAQ. HDMC - Tara ---- Until now the diagnostic software was developed within the UK using Tcl/Tk and the current software contains many defunct modules. It also contains a models of the hardware modules. Heidelberg has developed some HDMC software that has a modular framework to access the hardware using GUI. It was developed to test hardware components. The GUI is object oriented and comes from the free Qt package and uses the qwt package for histogramming. The software and documentation is available on the web. The online help is still incomplete but is improving. The software is made of 'Parts' and each hardware component has a corresponding software Part object. There are also special parts representing things like VME access. The Part hierarchies can be made using the GUI and then a configuration file contains the details of the register formats. The software is partly installed and working at RAL and QMW. However, the GUI is already cluttered with a simple module so some work is needed to allow creation of 'Part Collections'. Also there are no verify or automatic updating of related registers. The bigger issues of how we integrate it with DAQ -1 have to be faced. Network VME access - Bruce ------------------ VME access can either be done locally or over the network. Local VME access has the advantages of being a simple, complete development environment, but with our limited processor there is a lack of high level tools, a restricted memory model and is limited by the speed of the old processors. Network VME access means the in-crate processors are freed from other tasks, however the speed is limited by the transfer over the network of the single long word. This meant it took over 90 seconds to transfer 32K. This is overcome by allowing batch transfers, which brings the speed up from 1.3 KB/s for 1 long word transfer to 130 KB/s for 250 long word transfer. And optimisation of the compiler and architecture of the system may improve the speed. Schedule - Murrough -------- Murrough presented estimates for schedule of software development needed to meet to external timescales of: ROD module : April 2000 ROD crate DAQ-1 : August 2000 Prototype CPM: end 2000 Prototype of complete system: early 2001 The estimate 'assigned' people to the development, but raised the question of whether there are enough people available for the development. The list of jobs and the time needed to do them was daunting. Papers/Notes - Eric ------------ At the previous meeting four ATLAS notes were pending, but none have appeared yet. *********************************************** * Next Meeting : Tuesday 25th Jan 2000 at RAL * * (provisional and quite likely to change!) * ***********************************************