Present
Notes
Summary of actions
The hardware development has slipped ~4 weeks and is still in the logic design phase -- partly due to the need to provide hardware for the Demo-B programme. The good news is that the i960 chips have arrived much sooner than originally projected. It is hoped to make up the slippage by accelerating the hardware debugging phase, rather than the module debugging phase. It is important to ensure that the external tasks (board manufacture and BGA chip mounting) are smoothly scheduled.
Several points were raised on the hardware plans:
It was stressed that appropriate test pin connections should be provided from the start, since reallocation of test pins by reprogramming could provoke new timing problems.
Dave asked about the possibility of increasing the buffer size. This had been discussed with Barry and did not seem likely, but Bob agreed to check again in view of Dave's concerns [*Action 1]. It was noted that event rejections may come in blocks of as many as 100 at a time, which might cause events to stay in the buffer longer than otherwise. Nonetheless the others present did not think that the proposed buffer-size would really be a problem.
Discussion of buffer size lead onto discussion of page size and the possibility of making this software configurable. However it was pointed out that the page-size cannot be very variable i.e. not much larger than 1KB, because of the general bandwidth and event rate restrictions.
It was wondered whether the MACH chip could be reloaded over PCI.
There was some discussion on when the module would be ready/required. The project plan is for it to be available by the end of 1997. As far as Prototype -1 is concerned it could be used if available earlier, and it would not be disastrous if it is a little later.
As to how many modules would be required, the DAQ team would come back on this [*Action 2].
Bob went on to report that software development is essentially on schedule, using Intel's i960-RP evaluation kit. Gordon has ported the Intel (i960) development tools to Linux, as a convenient platform for development of PCI code. There is a firmware bug on the i960 board which limits PCI access to on-board memory, but this should be correctable by reprogramming the initialisation EPROM.
The i960 code is downloaded from the PC via a high-speed serial connection. When the buffer manager code runs on the i960 it communicates across the PCI bus with Linux processes which represent the hardware buffer on the one hand and the ROB controller on the other. Initial measurements of the buffer manager's indexing loop times are encouraging and suggest that the software may be fast enough written in C as planned.
Bob noted that there are some processor communication issues which need decisions. The message content needs definition, and there is a question as to how receiving processes will know that DMA's have finished properly. It was agreed by the DAQ representatives that monitoring requests require careful investigation. Dave reported later in the meeting that he had suggested that Gordon be commissioned to write the message passing code for Prototype -1, which would presumably help to ensure a smooth interface between the ROB-IN and DAQ components. Livio was in favour of this suggestion, as were Bob and Gordon. Dave promised to check with Guiseppe Mornacchi and to come back to Bob and Gordon about how to proceed with this [*Action3].
Bob then went through the list of design issues, reporting the updates arising from a recent meeting between Bob, Barry and Gordon. These updates have now been incorporated in the ROB-IN Web pages.
One point which arose from the discussion of testing was the need for a SLIDAS S-LINK test module. In this context Barry should also remember to provide a means of setting the S-LINK test bit for testing S-LINK.