CERN QMUL
L1Calo Software Meeting at RAL on 28 November 2001
Present: Bruce, Eric, Gilles, Murrough, Norman, Steve.Actions from previous meetings
- Software tools: Murrough has tried CodeWarrior for Linux but it crashes on RedHat 7.1. Not investigated why yet. Reports of KDevelop2 are good.
- Bruce has contacted Juergen Hannappel regarding problems he found with the VME driver (making D32 and D16 access via the same mapping). Juergen thought this shouldnt be a problem and indeed the problem now seems to have gone away, possibly due to changes in our VMEBus subclass - but also perhaps with the new CPU? Murrough should check if the older QMW CPU still shows the problem and Bruce to recheck at RAL. Bruce suggested that anyway we invest in VME debug hardware (eg VMETRO) so we can analyse any future problems.
- Other actions are carried over...
Actions arising from the ASSO
One of our actions arising from the ASSO is that we should name a contact person with the two calorimeter groups to deal with issues relating to calibration. We felt it should probably be one of the software group on our side, probably dealing with a software person from the calorimeter groups. Possible candidates will be canvassed...Another action is to identify people working on software. Murrough will circulate a list before we send it off.
NIKHEF workshop
It was not strictly part of this software meeting, but some software related items arising at the NIKHEF TDAQ workshop were reported at the UK meeting which preceded the software meeting.The workshop included some interaction with the Livio Mapelli and the DIG team. We should discuss what we should tell them are our priorities.
Bruce: ROS and CPROD
Bruce has now received some useful notes written by Jos Vermeulen on the ROS software and its installation. The original hope was to ask Gordon Crone for a ROS driving lesson. But at NIKHEF Livio suggested coming to CERN with a PC to have the ROS installed, which is clearly less convenient.Bruce has worked on the CPROD and DSS related classes from his "looper" development in a move towards the proposed Module Services package. Some issues remain to be resolved, such as use of the run type information and how to propogate information and commands between a module and its submodules.
It was suggested that Bruce and Murrough spend some time working together soon to integrate the run control work with this module service prototype work.
Steve: Simulation
Steve reported interest from Paul Hanke in using the simulation package to simulate aspects of the PPM and PPrAsic. Some things (such as BCMUX) is already in the package. It is not clear who would actually be writing the rest of what would be required - but it only adds to the need to provide documentation!Murrough: Run Control
Murrough showed a couple of slides on run control (and a few other issues which werent discussed). He has implemented a first version of calibration sequencer to drive the run control through a series of steps. It was however felt that the priority should be the integration with module services and real hardware.Bruce: Module Services
Bruce has had no comments whatever on his draft document on the module services. People should give him their feedback.He expects to update to document to incorporate the emerging design of the generic Module Services classes. It is probably best if the detailed specific services for individual modules are covered by separate documents, but Bruce will act as general convener to encourage consistency.
Gilles: CPM Module Services
Gilles presented a couple of slides showing his ideas for what services he expects the generic Module Service class to provide what additional services are specific to the CPM class. While the precise definition of the services may change, we felt that the balance between the generic and specific services was right.His second UML diagram should be corrected to be consistent with what we agreed before, ie CPM Module service class is a subclass of the generic Module service class which should probably be a pure interface.
Norman: Work on the CMM
Norman has started defining the test plan for the CMM, beginning with basic board tests, systematic register functionality, then moving on to standalone module dataflow followed by integration with ROD and other modules.He has done some work in preparing the HDMC description of the module. He has an Excel macro which takes an Excel description of the register map and creates the HDMC configuration file fragments and a parts file for the module. This might be of interest to others...
He then tried to generate "regbuild" register subclasses from his CMM configuration file and soon encountered some of the unresolved problems with regbuild. In particular it has been known for some time that the "Readonly" and "Readwrite" flags for registers should ideally be moved from the parts file to the configuration file. There is also a need for a similar flag for "Pulse" registers. This requires changes to both regbuild and the underlying HDMC configuration file syntax and the code that reads it. Rather than adopt workarounds in regbuild, we should try to make these changes properly.
Norman: Handling of L1As in test and simulation
Norman then moved on to talk about how we handle L1As in running playback tests and how we generate the expected output test vectors. The problem is how to synchronise L1As with the values scrolling through the playback memory.An elegant idea suggested by Bruce is to use the DSS for this purpose. With the TTC we can synchronise the DSS and CMM (or other module) playback memories. The DSS, with a parallel output daughtercard can be loaded with 32K values which would be mostly zero but with an occasional single bit set which could be used to send the L1A. If this bit is fired say every 257 clocks and the CMM playback memories are 256 deep, then the L1A will be generated in a predictable series for each playback value successively. The resulting event data from the CMM can then be analysed by a monitoring program.
The problem of organising the test vectors still remains. Ie how to correlate the data loaded into playback memories with other settings (masks, thresholds, etc) configured in the modules. We didnt have time to discuss this.
TTCrx part
We very briefly touched on the need for a TTCrx part, probably an HDMC hardware part with associated GUI, to hide the details of our implementation of access to the TTCrx registers via I2C bus. We probably only need access to about four registers to set the delays and check the status. There may need to be a thin Module Services layer wrapper to interact with database objects.Schedule and Gantt chart
Before the meeting Murrough had circulated an extremely preliminary Gantt chart showing a breakdown of the software tasks with the people expected to be responsible for them and a very first guess at the times for each one. Feedback was encouraged and quite a bit was provided during the discussion.The chart was created with a simple Mac shareware program. MS Project offers better facilites and we should use that instead. As a first step Murrough should send the data to Norman.
Murroughs draft does not include any tasks related to testing the hardware - which is time consuming and while it can involve software work, takes people away from the "pure" software tasks. However their time on this work should be shown. The chart should also include links to when the hardware modules are expected.
AOB
Norman raised an issue related to project management. Where we have identified contacts with other ATLAS groups, eg DIG, Online, ROS etc he felt that to avoid possible confusion we should generally channel communication through those people after internal discussion.Actions
Actions from this meeting:- Murrough: check D32 and D16 access with VMEBusEltec on QMW CPU
- Bruce/Murrough: initial integration of run control and module services
- Norman: find/define remaining data formats
- Steve: documentation for simulation package
- Steve: consider organisation of test vectors
- Bruce: identify run types in the present CPROD tests
- Bruce/all: investigate software development tools
- Bruce: complete Module Service document
- Murrough: complete run control design document
- Murrough: update HDMC changes document with recent suggestions and include the proposed long term strategy
Next meeting
The next meeting will hopefully be a video conference between RAL and Heidelberg on Monday 17 December - subject to confirmation. We would aim to start at 10:00 UK time.Last updated on 29-Nov-2001 by Murrough Landon