CERN QMUL
L1Calo Software meeting on 18 December 2002
Present: Bruce, Cano, Gilles, Murrough, Norman, Sam, Steve, Thomas.Before the video conference, the UK members had a short discussion, mostly about timing calibration.
Timing Calibration
As soon as we have more than one type of real time module, we will need to set up the timing between them. The general scheme has been discussed before, but little of the software required yet exists. We need a sequence of runs (or multistep single run) with timing parameters incrememted between each step. The data needs to be read out, analysed and histograms of valid data vs timing parameters fill and presented.As a slightly separate issue, the results of the CpChip auto calibration should be read out (eg at the config step) and published in IS so that other software can graphically display it.
At this point, the video conference with Mainz began (with Sam joining by phone).
CMM software status: Norman
Norman has not been working on CMM software recently as the CMM is still being debugged by Ian. The CMM should be released to us very soon and Norman could then restart work on CMM module services and simulation early in the new year.CPM software status: Gilles
Gilles has been concentrating on debugging the CPM hardware and firmware rather than software developments. He reported that the recent fixes to HDMC cured segment violations he was seeing. He has updated the database for the Birmingham tests. The next steps are integration with run control. This work may be done by an undergraduate as part of a project.JEM software status: Cano
Cano reported that following his visit to RAL he has completed the JEM parts file. All modules, submodules and their registers are now included. He has seen some crashes with HDMC, but this may be due to using an older version on one machine in Mainz. He has started implementing a TestVectorReader for the JEM test vectors prepared by Juergen. Unfortunately he took an obsolete class as an example. Steve and Bruce should send him more up to date suggestions. Murrough should also add relevant objects to the MainzTest database.The present set of JEm test vectors consist of some 10000 files with a total of 1Gb of data. We cannot yet store this centrally but we should consider how to store this kind of data in future. Steve should make suggestions for how sets of JEM test vectors could be fitted into our "test descriptor" type scheme and should also summarise how the system works in our CPROD tests.
Progress report: Murrough
Murrough has done a little work on the database schema and library mainly to add support for the JEM and some new options for the TTCvi. The run control and IGUI have als been updated for the same modules.On the subject of databases, Norman mentioned that he has developed a module inventory database which can record the locations of all our modules, their daughtercards and the movements of each one. In future the fault and repair status can be added.
Progress report: Bruce
Bruce reported that the DSS module services now automatically recognised the daughtercard configuration on he module. This requires up to date EPROMS. However he software does not yet support more than one card of the same type per module. Both LVDS and Glink source and sink cards are supported, though the sink card software has not yet been tested.Regarding the ROD, the JEM Daq and RoI firmware exists, but has not yet been tested. [Steve and Bruce later fixed a date of Thursday 9 January 2003 to make these tests].
Using the ROS has long been part of our strategy. The ROS software has recently been changing rapidly. Bruce has started looking at the latest version.
Simulation
Steve said that he has done a little tidying up of the simulation code. Rolling out recent updates to other modules in still to be done.Sam reported that Daniel and Asa are still working on the JEM simulation, both structure and algorithm. They hope to release this in early January. In later discussions we remembered that although the existence of Juergens test vectors mean that the JEM simulation in Steves framework is not required for standalone JEM tests, it will be necessary for JEM tests with the ROD. So this work is becoming urgent.
TTCvi software for JEM0
As the JEM0 TTCrx chips are not connected to an on board I2C bus, they cannot be configured via VME, only via the TTC system itself. This is not yet supported in our software, so some extra database and module services work is - temporarily - required to permit this. Bruce has already added methods in the TTCvi module services to send the necessary broadcast commands. The database needs to be modified to provide a list of TTCrx addresses and the delays to be set in each one.Mainz visit to RAL
We discussed the nature and timing of the visit by member of the Mainz group to RAL to start the JEP subsystem slice tests. Up to five people (Andrea, Cano, Juergen, Thomas and Uli) will come, at various times. A tentative date for the first visit is Monday 20 January. If tests of JEM 0.2 (expected to be done from 6-10 January) are successful, two JEMs will be brought to RAL.The first steps will be to repeat all the tests done on JEM0.1 at Mainz on the same module at RAL. Then communication between two JEMs should be tested. Also from JEM to ROD and CMM. The Mainz group should produce a detailed test plan and also their requirements (or requests) to RAL, eg ability to do firmware development at RAL.
It is hoped that the main JEM FPGA code will successfully include both energy and jet algorithms combined by then. However many useful tests can be done with only one or the other so that it not a holding item.
Only the CPM variant of the CMM firmware yet exists, but this can still be used to read the bit patterns sent across the backplane so it should be sufficient to start with.
Details of the hardware Mainz should bring will be confirmed at the hardware phone meeting. The Mainz TTC system would be useful and probably also their DSS as there is a shortage of Glink daughercards.
We should discuss the details of the visit again in early January.
Handling firmware
We briefly discussed how we handle firmware. When loading the JEM firmware, Cano is presently checking both the file names and some internal markers within the file. In future, with JEM 0.2 he will need to check the revision of the module as different main FPGA firmware is needed in JEM 0.1 and 0.2.The latest JEM firmware binary files have been included in the HDMC CVS repository. This has not been done for other modules. We need to decide the best way to organise this.
At this point, the video conference with Mainz ended.
Data formats
Steve reported a couple of inconsistencies in the JEM data formats arising from the JEM1 review. Should the crate number be sent in the Glink data (there is no room in CPM Glink data to contain this)? A missing parity bit in the RoI data must be implemented.Test Vector API
The present test vector API only handles a single test vector load. This needs to be extended to allow multistep runs where new test vector data is loaded into modules at each step. This may either be taken from the same file or else a succession of files might be read, one per step. Steve should make and circulate proposals for how the API should be changed. Bruce and Murrough also need to propose how this will be used by the run control and module services.Use of ROS and monitoring framework
The ROS will be the preferred means of readout out once we have more than one type of module to read. Using the monitoring framework should precede this to allow a smooth transition from a "looper/kicker" style readout to the ROS. It should not be hard to convert the "kicker" program to use the monitoring framework - apart from the usual problem of finding the time.Work for JEM tests
We tried to summarise the short term work needed to prepare for the JEM0 tests in January.- Test vector work: extended API, use by run control and module services.
- Database: updates for MainzTest to read single test vector (for now).
- TTCvi: database and module service updates to configure list of TTCrx chips by TTC comands.
- Sequencer: finish multistep run control sequencer (existing functionality may almost be enough).
- kicker: move to a common "kicker" type program to read out data from single standalone module tests and compare with test vectors. This program needs (in some cases) to be tightly coupled with the sequencer program.
- Infrastructure: we (and others) need to ensure all required hardware is present or brought from Mainz
- JEM simulation: this will be required as soon as we move on from standalone tests (eg prepare Glink packets)
- The Mainz group should prepare a test plan. The preliminary suggestions are that first the standalone JEM tests should be reproduced at RAL, next JEM-JEM backplane traffic should be checked. After than connections to other modules, eg ROD, CMM should be tested.
- The CPM tests also hope to benefit from the above developments.
There are also a number of outstanding questions:
- JEM scripts: if these are used to check the JEM is working after its trip to RAL, do they still required the VMElinux driver (which will not be available at RAL) or have they been ported to the CERN VME driver?
- Test vectors: do Juergens test vectors have jet outputs already? Or do they only provide the results of the energy algorithm. What about JEM to JEM backplane traffic?
Next meeting(s)
Some working sessions were arranged: Steve and Bruce will get together to test new ROD firmware variants at RAL on Thursday 9 January. Murrough will visit Birmingham to work with Gilles on CPM database and run control integration on Wednesday 8 January.The next software meeting will probably best be held during the Mainz visit - though some phone discussions beforehand may also be essential. Dates to be fixed.
Actions
Actions from this and previous meetings:- Steve: send Cano test vector reader examples and advice, also describe how the "Bill files" are used in CPROD tests
- Steve: write and circulate proposal for updating the test vector API to handle multiple files and/or multistep runs
- Bruce/Murrough: write and circulate proposal for handling multistep runs in DaqInterface and run controller
- Murrough: implement test vector descriptors in MainzTest database
- Murrough: add to the database lists of TTCrx chips to be configured via TTC broadcast commands
- Bruce: complete Module Service document and submodule syntax description
- Bruce/Murrough: define required HDMC improvements
- Murrough: tackle project management issues: eg schedule (Gantt chart, stages of evolutionary delivery), risks, etc
- Murrough: write database user guide
- Murrough: complete run control design document
Last updated on 31-Jan-2003 by Murrough Landon