ATLAS-UK Level-1 Calorimeter Trigger Meeting

Thursday 17 December 2002 at RAL

Agenda

Click this side                               Click this side
for summaries                                for slides (pdf)
 
Hardware
Cluster Processor Module and related cards..........Richard
Cluster Processor Module tests.......................Gilles
Common Merger Module....................................Ian
ROD testing...........................................Bruce
TCM, GIO, CAN, TTCrx...................................Adam
Module database and new account codes................Norman
Heidelberg, Mainz and Stockholm status.................Tony
JEM 1 review...........................................Tony
Schedule...............................................Tony

Online software
Comments on compression of readout data................Eric
Module services, ROS status, Linux situation,
   Mainz visit to RAL, etc............................Bruce
Simulation, including JEM.............................Steve
Databases, general status and priorities...........Murrough

Offline simulation and physics
Trigger simulator and integration status.................Ed
 
Recent meeting highlights
ROD workshop...................................Bruce/Norman
T/DAQ week.........................................Murrough

Any other business
Date of next UK meeting

Hardware

(Richard's talk was presented by Gilles.) The new extender card is in regular use and greatly improves access to the module.

The 160 Mbit/s signals from the serialisers to the CP chips on the same board look good. The ones coming via the backplane are reasonably clean but have low voltage margins due to reflections, attenuation and crosstalk. There is attenuation in the tracks, which are narrow and possibly don't have enough copper and so present a resistance of 5–6 ohms, or perhaps due to vias switching layers in the PCB. The situation could be improved by using reference voltage pins on the FPGAs to lower the thresholds, but in the present version these pins are not accessible.

There is also a problem in the timing calibration of the 160 Mbit/s signals at the CP chips. It varies with firmware versions. This should be understood at least in principle before going ahead with the second board. Various suggestions were made in an extended discussion. There should be a tutorial on how the timing calibration works in January. It was also felt strongly that the way we are working is not efficient for finding and fixing problems and there has to be a lot more discussion between firmware authors and testers.

LVDS data from a DSS daughter-card have been sent and recovered successfully inside spy memory of at least one serialiser. Other serialiser chips have to be investigated. Minor modification is needed if we want to perform the synchronisation automatically, as this is easily done by software. The extender board has access to the realtime path of the hit results, and checks of the validity and integrity of the hit data have been done.

A glitch seems to appear for some configurations of data and will require some work on the firmware itself. In a similar way, checks of the validity and integrity of signals on the readout controller for DAQ and RoI have been performed and no problems have been observed. The next step will be to feed the data inside a G-link source and perform some soak tests. The best way will be to modify the ROC firmware in order to generate a pseudo-random pattern, pattern check for errors inside the G-link Source.

Problems have been found on the CP chip, where corrupted data appear from time to time. It appears that those channels suffered from a bad calibration process. James and Ian came to Birmingham to debug the calibration process with the help of ChipScope. The problem seems to be in the CP chip itself, where the quality of the 160 MHz clock and its relative phases is not perfect at all. More discussion and investigation are needed and a meeting is foreseen for early January. Without changing the FPGA, one solution could be tested by by-passing the calibration process, as it has been seen that input signals arrived on the chip with a timing window of less than 1 ns.

On the software side, nothing has been done but a student is expected to be available in January in order to help in writing more services for the CPM and its peripherals.

CAN and I2C access, when the new TTCdec card is available at Birmingham, need to be done, but it will be matter of 2–3 days of testing. For the near future, soak tests will finalise the complete set of tests of the CPM.

Common Merger Module - Ian Brawn (slides)

Ian gave a presentation on the status of the CMM. The Configuration Controller has not yet been fully tested, but all other proposed tests have been completed. All of these tests were successful, except for a small error in the format of data recorded by the DSS in the CMM-DSS G-link tests. At present this appears to be a probem with the DSS. It will be investigated fully when the G-link Rx card used for these tests is returned from Birmingham. Data have been sent to the ROD.

The final tests of the Configuration Controller will proceed in parallel with the development of the next design iteration of the CMM. The schematic modification necessary to produce this design is currently being performed. It should be completed by the end of December and layout of the board should start at the beginning of January. The resultant boards should be ready for sub-system tests by the end of March 2003.

ROD testing - Bruce Barnett (slides)

Bruce presented a short update on the progress of ROD tests. There are a couple of minor items in the area of ROD testing which are non-crucial but need tidying up. More pressing is test work on CMM/JEM firmware variants. In that area software from Steve has been available for some time, but awaits integration and extensive use. As concerns new ROD hardware, the mechanical bits and pieces are being brought together and tested by ID and will soon need to be tested with the test setup in lab 12, R1.

TCM, GIO, CAN, TTCrx - Adam Davis (slides)

Version II of the GIO card is well under way and is based on virtex II technology; the card is split into "front end" and "back end". Two "front-ends" are being designed: the TTCvi driver and LVDS, CMOS card. The schematics for the "new" TTCrx card are complete and four PCBs made, two assembled. Initial tests look promising. The "old" TTCrx cards are being tested but a lot of problems, they don't work.. No further problems reported for the TCM.

Module database and new account codes - Norman Gee (slides)

Norman had asked for a set of new RAL accounting cost centres to be created. From now on, FK40000 should not be used. The new cost centres will help in accounting for costs of the different modules, which have different sharing between our collaborators. Note that cost centres for travel will not change.

Norman also gave a brief demonstration of an Access database which will track movements of modules within the collaboration. The database should know both where each module is, and also its movement history. The database will go live when a web interface has been built. The underlying tables are SQL-compliant, so the data can be exported at any time to other databases, and Access also allows combined network queries between this and other SQL databases. It was suggested in discussion that this database should be extended to cover repair history.

Heidelberg, Mainz and Stockholm status - Tony Gillman (slides)

Tony summarised the hardware status phone conference that took place on 6 December. For further information please refer to the summary that was sent out by email.

JEM 1 review - Tony Gillman (slides)

A mini-review of proposed changes to the JEM was held in Birmingham on December 11-12, with Eric, Richard, Steve, Tony and Uli present and additional material sent in by Murrough and Norman. The aim was to assess updated design features and decide which variant of JEM 1 to build.

Design issues concerning data synchronisation, clocking, readout sequencing and Xilinx configuration were discussed, as well as implementation issues concerning the use of daughter-cards in various roles. Available design resources and consequent possible timescales were considered.

Recommendations:

• Boundary-scannable 6-channel LVDS deserialisers
• Input processors on 4 daughter-cards, using Virtex-II devices
• VME control ring-bus removed
• Main Processor as 1.27 mm BGA Virtex-II device
• 2.5V -> 1.5V signals with DCI
• FPGA configuration via parallel flash memory, and all CPLDs replaced by FPGAs (to be confirmed)
• Fujitsu CANbus controller
• etc. ...
• All further JEMs to be full JEM 1 specification

Schedule - Tony Gillman (slides)

Tony reviewed the two schedules (pre-slice and production) agreed immediately following the Birmingham collaboration meeting. The key point is the projected acceleration of the Preprocessor pre-slice schedule, to be achieved by changes to the Preprocessor work packages (PPrROD is now CP/JEP ROD, assistance from RAL with some of the PCB design/manufacture jobs, etc). This has saved ~5 months, providing for a much more comfortable contingency to the production schedule, which had been re-organised to allow more time for rigorous subsystem tests before integrating the full trigger in USA15.

The end-date for the fully operational trigger to be available remains the end of August 2006, ready for cosmic-ray run in November 2006. Some of the milestones from the post-Birmingham list have already been modified. In discussion, it was pointed out that we now have to look at the installation process in more detail.

There would now be a much greater emphasis on the UK sub-system tests, leading gradually into full slice tests.

Online software

Comments on compression of readout data - Eric Eisenhandler (slides)

In view of the changes to the Preprocessor readout, namely the use of CP/JEP ROD and G-links from each module instead of PipelineBus, Eric presented some general points concerning compression of readout data that he has been discussing with others, notably Norman. The PipelineBus had been a bottleneck, driving compression of Preprocessor data on the PPMs whereas other data was to be compressed on the RODs. The only reason for data compression is now to reduce the data volume to DAQ (not a hard limit), and that re-opens the question of where and how to do it.

Not all possible data will be read out all the time. The largest data volumes come from the Preprocessor (both raw data and look-up table outputs), and from CPM input data. JEM input data is next in size. CPM and JEM results, and CMM input and results, are relatively small by comparison. Eric noted that at present it is not possible to separately turn on readout for input data and results on CPM, JEM and CMM – if we want one, we get the other. This should be changed, since in normal running it is wasteful to read out data from both ends of data links – this is only needed for tests.

The compression should be done as late as possible, i.e. on the RODs, keeping things simple on the trigger modules. That would allow monitoring on the RODs without having to uncompress the data, and in fact some data might sometimes be sent to the RODs for monitoring without reading it out to DAQ. Simple zero-suppression is already foreseen for look-up table outputs and CPM inputs. This would be less effective for JEM inputs since they are sums of four channels, and will not work for raw data as it includes noise and pedestals. Huffman coding had been an option for the Preprocessor, but its variable word length is not easy to work with, and if the most frequent values change the coding must also change in order to get good compression. Eric suggested that since the raw data and JEM input data tend to be clustered around one value (pedestal or zero, respectively), a simple code with short word-length for the most frequent values and full word-length for the rest would be much simpler and would probably provide adequate compression.

Module services, ROS status, Linux situation, Mainz visit to RAL, etc. - Bruce Barnett (slides)

In this presentation, Bruce summarised the status in several areas:

Module Services: DSS software now supports a single LVDS output card, but multiple cards of the same type pose a difficulty. Modifications to the DSS default-eeproms allow dynamic recognition of link cards (but not S-link variants). GIO support will soon be an issue. The TTCvi module service now provides some useful clock (deskew) setup methods. A number of generic needs, required for support of many types of test setups have been identified. These include the creation of some new and/or rationalised software packages.

ROS status: New OO software is available for test. Downloaded code is under study. It is important that our monitoring needs are not lost in the shuffle between ROD Crate Daq and ROS.

Linux strategy: Migration to Red Hat 7.3 will soon be necessary. Probably this should wait undtil after first Mainz/RAL tests. All code will need to compile under gcc3.2: use of namespaces becomes mandatory, so some work may be required.

Mainz visit to RAL: This was a successful integration session where much work on JEM moduleServices was accomplished. Initial integration with the Run Control and dataBase was achieved.

Simulation, including JEM - Steve Hillier (slides)

There has been little recent progress, with only a couple of non-urgent issues being addressed since the joint meeting. These were making the code ANSI/ISO standard compliant, and adding CVS check targets. The plans are still much the same as before, with some work needed on all the modules plus some infrastructure work required for testing large data sets and DSS L1A generation. The JEM simulation still requires a lot of work.

In discussion, it was asked whether we have to be able to run old and new versions of the same module at the same time. This has not been foreseen and it would be much easier if we could avoid it.

Databases, general status and priorities - Murrough Landon (slides)

Murrough gave a brief overview of the online software status. The most significant recent activity was the visit of Cano to work with Bruce and Murrough at RAL, which was very productive and software for the JEM is rapidly being integrated. Unfortunately, other activity has taken a back seat to a large number of meetings.

Given the existing JEM 0 and recent software progress, we have to decide if the JEP system should be focus of the first subsystem tests instead of the CP subsystem.

Murrough has (in principle) been a member of a TDAQ databases working group on which there has been little activity; however, there is now a proposal to have an ATLAS-wide database workshop early next year.

He has also recently been invited onto two new working groups to discuss monitoring requirements, and to study the area of error handling and fault tolerance in TDAQ (and detector DAQ) systems. He presented the first thoughts on L1Calo contributions in these areas.

A discussion and brainstorming in January should produce a test plan for the JEM at RAL.

Offline simulation and physics

Trigger simulator and integration status - Ed Moyse (slides)

Ed has finished coding TrigT1Calo, but still needs to do some tidying up of code and testing. He intends to only support ATLAS release 5.0.0 (unless changes for later releases are trivial). He will maintain web pages and code for as long as possible, but his focus now is on writing up his thesis.

Recent meeting highlights

ROD workshop - Bruce Barnett and Norman Gee

Bruce and Norman gave a summary of the recent ROD workshop at Annecy.

T/DAQ week - Murrough Landon (slides)

Murrough gave a short summary of a week of long TDAQ meetings. The presentations were focused on what is required for the DAQ/HLT/DCS TDR. In general the architectural plans for each component were reiterated and confirmed, with no surprises. However, there are ongoing studies on how to adapt the dataflow architecture to cope with budget deferrals.

Any other Business

There was no other business.

Next UK meeting

The next UK trigger meeting was tentatively set for Thursday, 23rd January at RAL.

Eric Eisenhandler, 13 January 2003

This page was last updated on 16 December, 2013
Comments and requests for clarification may be sent to
E-mail:
Telephone: