Click Click
for for
summary transparencies
*=ps #=pdf %=gif
Minutes of previous meeting.............................All 10'
Newsgroup...............................................All 10'
Data Transmission
LVDS test results with TTC clock....................Richard 10'
Hardware status summaries
Serialiser..............................................Ian 10' #
CP "chip".............................................Viraj 10' #
CP Module Prototype.................................Richard 10'
ROD prototype.........................................James 10'
Timing Control Module...................................Bob 10' *
Common Merger Module.................................Norman 10' #
Backplane & connectors..............................Richard 10'
Brief summary of "brainstorming" on 3 March............Tony 5' *
Schedule and reviews update............................Tony 10' *
Trigger simulation
FCAL jets............................................George 10' %
Online software
Heidelberg diagnostic software evolution...........Murrough 10' *
Work on DAQ software and DAQ -1...........Bruce/Norman/Tara 10' #
Other topics
Comments on JEP algorithm specifications...............Paul 10' *
Coordinates and nomenclature for towers and windows....Paul 10' *
Posters................................................Paul 10'
Trigger/DAQ reorganisation status.................John/Eric 10'
Preparation for Mainz meeting..........................Eric 10'
Status of ATLAS notes.....................Alan/Paul/Richard 5'
LEB and IEEE papers for 2000............................All 10'
Any other business......................................All 10'
Dates of next few meetings..............................All 10'
The Birmingham system was moved to the basement last week in preparation for the visit of the grant referees to Birmingham, this was then followed by a power cut. After this there were problems accessing various registers on the DSS which was finally solved by pulling the card out.
Last Friday the system was running and checking the error rates, but no checks with the TTC have been done.
First Richard will test the time jitter on the current system, then see what effect using the TTC has.
It was pointed out that the DSS PLL will give some jitter so the tests will not be a direct measure of the TTC.
The target device is now a VirtexE 100 as it is easier to achieve the timing requirements and Xilinx are encouraging VirtexE over Virtex. For final production Spartan2 device is also been considered. The serialiser pin out still has to be defined, but simulation shows the pin position does not seem to be critical for the performance.
So far 3 FPGA designs have been finished: Serialiser, Receiver and Controller.
There is a new proposal for a serialiser test module which can also test some elements of the CP chip. This will be a 6U board with 2 CMC slots for daughter cards, dual port RAM for data source and sink and direct VME access. A lot of the design is similar to the DSS. The design effort will be shared with CMS with each experiment providing a designer. The board should be ready for the tests in the 3rd quarter of 2000.
For the serialiser tests the device will be larger than in the final system using a VirtexE 600. The 100 design will be put into this FPGA. Using a larger chip in the final system will not be worth it as no more channels can be added.
It was suggested we make two test cards so that we can test using VirtexE 100.
Ian pointed out the the simulation was less likely to work than the hardware.
Comparing this to the currently available FPGAs, this amount of logic is in the 1600E family and will hopefully fit in a smaller family when more accurate calculations have been done. Although routing may mean a larger family is needed.
There is no price available for the 1600E family, although as the differences between the 1600E and 1000E are small the price should not be much more. The price for the 1000E is the release price and is expected to reduce.
The specs have not been updated yet.
It was asked whether the board could be post fitted with the remaining chips, however this could be difficult. It was suggested that some of the boards could be fully populated.
The PDR has been moved to May to avoid clashing with the Mainz meeting.
The TTCdec specs are complete and the job is in the RAL drawing office.
25 bits (3*8 thresholds + parity) enter the Crate Merging logic by the backplane from the 16 modules. What happens on a parity error still has to be discussed.
For the energy merging there is now Ex, Ey and Et on each module. As Ex and Ey are signed these need an extra bit. However the point was raised that depending on the crate layout the extra bit might not be necessary.
The summing chain allows either total scalar ET or a sum on jet elements above a threshold, but not both at the same time.
Alan pointed out that total jet ET logic may be wrong as the algorithm gives the number passing the threshold and not the one above.
If the number of jet thresholds is increased then the FPGA will need to be reprogrammed.
A presentation on the energy compression scheme will be given by Jurgen at Mainz.
The number of pin counts with all signals going via the backplane will be 810 (841 with a 17th JEM), if the signals between crates go via front cables this reduces to 554 (583). Richards module has 810 pins.
If the parity signals across the backplane are reduced then the number of pins for the reduced VME could be increased.
Specs laying down the functionality and registers for timing exists and need passing on to the engineers soon.
The latency is unknown. The UK will engineer the module. >
Sam has sent the first attempt at the pin layout, with a few minor problems, but Richard can fit the CP module into it.
If AMP are able to provide the connectors then they will now be used.
To increase the link stability it was decided to add a low-jitter PLL to each Processor Module. Two solutions for the serial LVDS fanout we suggested. There is a new TI chip which needs to be tested before use and Heidelberg is designing a ASIC.
The PPM and associated backplane will be evolved for TCM and TTCdec.
It was decided to design the CMM to "module 0" specifications which should be available for discussion at the Mainz meeting.
The JEM and CPM will be designed as a 9U "module 0" specifications using a common backplane.
The reduced VME specifications will be defined before the Mainz meeting.
Use of the latest AMP cables is encouraged, the cost and availability will be explored.
The front-end link architecture could use Virtex-E or Paroli. Each have attractive features but require low clock jitter and would impact on the PPr MCM design, so it was agreed not to proceed any further at present.
The PPrASIC FDR date is not set and may require someone from the ATLAS Technical Coordination Group.
The JEM review date will be decided at Mainz, as will the small scale milestones.
It was asked whether the modules are on time. This was doubtful, but as these modules are going to be as close as possible to the final modules future milestones may be skipped.
An FCAL trigger has been suggested as a benefit to various physics processes.
Forward jet trigger algorithms, similar to the existing trigger algorithms, have been investigated. The algorithm sums in eta then sums the EM and hadronic energies. The preliminary analysis uses 10**4 ATLFAST events to investigate the cluster size.
For the eta > 3.2 region there is good correlation between the reference and trigger jet energies and good efficiency down to 20 GeV. There are problems at the boundary region (eta = 3.2) which need further investigation on how to combine the algorithms.
We need to push for decisions and input from the rest of ATLAS as our timescales for implementing an FCAL trigger are imminent.
Bus error handling is implemented in th same way as the UK diagnostics by transporting them over the network and generating C++ exceptions.
The remote VME bus server used to need the STL/Qt libraries, this has now been removed but has still got to be tested in the UK.
The GUI still needs to be improved. Cornelius is looking in to this and will report at Mainz.
The HDMC software stores the modules registers layout in a configuration file which may be parsed to produce C++ code implementing the functionality needed in the DAQ. The full details need working out and agreeing at Mainz. Similarly it may be possible to produce a module subclass for the DAQ from the HDMC configuration files.
Code for verifying the register content should be easy to add.
More extensive tests will need some scripting capability. Work on this has begun but it is not trivial to add.
A configuration database to replace the current text files for both the HDMC and DAQ needs to be defined.
VME access over the network currently uses a VME daemon written by Murrough. In the future we will use the simplified HDMC version which complies on LynxOS. Tests of this are underway.
The aim is to have a working version within 2 months. Until then the current LynxOS version of the DAQ can be used.
The new DAQ will have the following: Run Control - using DAQ-1. Parameters - taken from the old ``daqctl'' program. Will eventually move to a proper database and editor. Producer - based on ``daqprod'' with DSS support as a recoded DSS object filling an event object. Buffer Manager - use current version with an OO wrapper to handle the event object. Analyser - rewritten to use the event object and ROOT histogramming. Histogram presentation - will use ROOT. Data Recording - none in this version.
The evolution from this will use all DAQ-1 services and add the other hardware modules in time for the UK and joint tests. Then to the ATLAS installation version all missing services and hardware modules will be provided, then any problems will be fixed giving the production version for ATLAS running.
The Jet algorithm has a ``Start at zero'' (phi, eta) coordinate system, this is orthogonal to the CP labelling. The RoI identification is done before the threshold comparison giving an increase in latency but reduces the comparator infrastructure. Saturation sets all multiplicities to 7, although it should be sufficient to only set the highest Et threshold. The backplane sends 5 bits in parallel with the parity bit along the same line as the 4th significant bit, this should not cause a problem. There is no treatment of forward jets or response about having >8 multiplicities (includes forward jets).
The 16 or 17 JEM question is now pressing as the CMM is pending. Input is needed about the forward jet algorithm. 2 or 4 crate choice should have a small impact. There are a few loose ends about saturation, error suppression. We need to converge the labelling for the CP and JEP systems.
A proposal will hopefully be ready for Mainz.
Ralf Spiwoks will be present and give a presentation on the CTP.
The deadline is the end of April
29 March - 1 April ... Joint meeting at MainzThursday 11 May ...... UK meeting at RAL
21 - 26 June ......... ATLAS plenary at Dubna
Thursday 15 June ..... UK meeting at RAL
5 - 8 July ........... Joint meeting at QMW