CERN QMUL
L1Calo Software Meeting at RAL on 24 April 2001
Present: Bruce, Eric, Gilles, Murrough, Norman, Steve.Actions from Previous Meetings
- Test plans: Norman insists these should emerge from the hardware designers first...
- Three Concurrent CPUs arrived at RAL despite us asking them to hold the order pending discussions on whether we would prefer their new board which has better bus error handling but no SCSI driver (only IDE). Norman and Bruce will visit Concurrent soon to discuss the issues in more detail.
- Norman will attend to the LVL1-LVL2 interface document this week. The CMM specs now contain updated event formats from the merger modules (but we still have no single document with all ROD input and output fragment formats). The VME-- specification exists in Normans personal web space. It should probably be moved to the Atlas-L1 space and there is still a feeling that it should be made into a document and entered in EDMS someday.
Report from the ROD-ROIB/ROS Tests
Norman presented a comprehensive report on these tests at the recent UK meeting (19 April).Outstanding issues and comments include:
- We need to find a firmware fix to the flow control problems
- Also more work is required on the CPM slice data firmware
- The CPU freezes occasionally, maybe due to incorrect handling of bus error, possibly in the driver or our use of it in HDMC. This should be investigated and understood.
- Ways of cutting the reboot time of the CPU should be found. This severely limits how often the crate can be powered off and on.
- We dont understand the 20kHz event rate limit we had with the ROS. Its half what was obtained with the MIROD.
- Apart from that, we need a DSS firmware upgrade to allow the buffers to wrap around. We could then run longer series of events without computer intervention and improve our overall event rate.
The ROS tests were done with a simple Slink test program. When we get our Slink hardware (due in April) we could repeat them. We should also try to get the "collapsed" ROS code too. However at the moment it only handles a single Slink. We need to find the timescale for handling multiple Slinks.
Our internal tests used two "in house" Slink host boards. We should consider using the SliDAS and SliDAD - this may require a CES RIO2 to host them though.
Recent Work
Run Control
Murrough has not done much on this since the last meeting. However the document on our configuration database contains some more on trigger menu and calibration data.Monitoring/simulation
Steve is still working on his ideas for simulation and will present them in a document. He has started looking at Bills work on test vectors with a view to incorporating that into his scheme. We need an overall package rather than a set of standalone programs. Meanmwhile there are some fixes and other comments from Bruce that need incorporating.He has not done much on monitoring: we do some monitoring based on event data and some continual monitoring. Is there anything else? How does the continual monitoring interact with the run control? We need the system to be initialised in order to start the monitoring but dont necessarily want to stop monitoring in between runs.
In event monitoring, how will we detect latency errors. We need a calibration program to establish the correct system timing, but if something changes afterwards how well can we diagnose it?
HDMC
After our discussion at the previous meeting, Murrough produced a document setting out his view on a set of changes required to HDMC to make it more suitable for use in the DAQ environment. He and Bruce discussed this during the recent TDAQ week at CERN. Some changes were made as a result and the latest draft was circulated.One extra comment from Bruce concerns the case where effectively two 16 bit registers are combined into a single 32 bit register, eg on a module such as the DSS and ROD which need 32 bit accesses. We havent come up with a nice scheme for handling this, though ideally we would ask the designers of the programming model to avoid unnecessary compression of separate functions into a single register.
Although Bruce is not entirely happy, we do appear to have a basis for future work. Since we hope that Oliver will be able to work on implementing these changes, it would be sensible if we had a longer discussion with him. An extra software day before the main meeting in Mainz seems suitable.
Software Coordination Across Level 1
Nick is arranging a video conference in late May or early June to discuss coordination of software across the whole of level 1.We dont want to add extra layers of bureaucracy, but at the same time some coordination will be useful. Maybe the remit should be confined to specific areas, eg the trigger menu etc.
One issue will be software quality. Within the calo trigger software group we have not implement much of a software process. Again we dont want to overload ourselves, but we could do better that we have in the past, eg with more documentation and reviews.
The Online software group have a web page on these issues.
Moving away from our own software quality, we discussed the software process for the firmware developed by our engineers. This issue should be raised at the hardware meetings.
AOB
None.Actions
New actions from this meeting:- Bruce: pursue various ROS questions with Dave Francis
- Steve: document ideas for monitoring/test framework
- Norman: finish various documents...
- Murrough: finish run control related documents for review
- Gilles: finish CPM test plan document
Next meeting
The next meeting is officially on 12 June. There may be smaller meetings on 8 and 20 May before the hardware meetings.Last updated on 20-Oct-2001 by Murrough Landon