Minutes of RoB-IN Meeting No.3
Held at UCL on Monday, 28-Oct-1996

(Last mod: 07-Nov-1996 / R.Cranfield)

Present: O.Boyle, R.Cranfield, G.Crone, B.Green, R.McLaren, J.Strong

1) Minutes
2) CERN update
3) Relevance of RoB-IN Development
4) Documentation
5) Processor Choice / Hardware Iterations / Timetable
6) Design Issues
7) PCI v PMC
8) Long Term
9) Next Meeting
10) Summary of Actions

1) Minutes

The minutes of Meeting No.2 were approved.

RC had decided to postpone the revision of the work timetable since the proposed modifications depended upon decisions about to be taken.

2) CERN update

RM reported that there had been agreement during the last Atlas week to follow the proposal by Phillipe Farthouat to use S-Link and its associated data format for RoD/RoB communication. Phillipe and RM had made a point of discussing this with the main sub-detector RoD responsibles -- list supplied subsequently by RM:

Calorimeter Liquid Argon Patrick Le Du
TileCal Marzio Nessi
Muons Cathode Strip Chambers Polychronakos Venetios
Muon Drift Tube Chambers Adriaan Konig
Resistive Plate Chambers Emilio Petrolo
Thin Gap Chambers Lorne Levinson
Inner Detector PIXEL Giovanni Darbo
SCT Andy Lankford
TRT Philippe Farthouat

The URL of the data-format proposal is http://www.cern.ch/HSI/format.

RoD URDs (or more probably RoD specs) were being constrained by the Front-End Requirements Document (Farthouat/Le Du). RC asked if points previously raised as relevant to RoB were in this document:

  1. Use of TTC input for checking beam-crossing IDs against event IDs: at RoD or RoB?
  2. "Pinging" of RoD from RoB to check that RoD is alive.
  3. Use of XON/XOFF to prevent RoB overflow.

On these points:

It had been previously decided in the RoB-IN group that there should be NO TTC input to the RoB; RM thought that it was being generally accepted that XON/XOFF flow control should be employed on the RoD/RoB link; and, after much discussion, it was felt that pinging was probably not a good idea. None the less RM would check with Farthouat.

Other notes:
The viability of the RoD link should probably be checked at RoD initialisation. With S-Link, once you have XOFF you have another 4 control lines as well: although uses for these are not yet apparent the RoB-IN design should ensure that these are all writable.

As for Prototype -1 there had been no (or 1?) meetings during the summer. Mapelli had ordered 2 S-Links (on PMC) for use with RIO2s.

S-Link status:
Fibre-channel and G-Link boards (100 MB/s) finished and under test; Optobus (50 MB/s) built, but not yet tested; electrical (50 MB/s) being developed at Cracow (uses LVDS drivers and SCSI cable, should be cheap).

There had been no updates to the RoB or RoB-IN URDs.

3) Relevance of RoB-IN Development

RM still thinks that RoB-IN is on the right track. JS wondered whether RoB-IN timescale fits in with other prototype work. RM reported that Andy Lankford is now interested in earlier development of the SCT RoD (despite what he had said earlier to JS and John Baines); also Adriaan Konig is interested in testing at 100 MB/s by end 1997. 100 MB/s is needed at some point by Prototype -1 and RoD testers. Sub-detectors don't need high-performance RoBs, but would probably use them once RoDs are available.

JS suggested that it would be useful to circulate a (brief) document to let potential RoB-IN users know what was being designed and to give them an opportunity to tell us whether or not they were interested. RC agreed to produce this from the draft description and URD intro - it would be essentially a "sales blurb" for DAQ and RoD designers.

4) Documentation

GC showed a printout of the Web page that he has put together to contain all the RoB-IN documentation. This is currently site and password protected. It was agreed that this was a satisfactory way to maintain our documentation and that the password protection should remain, with all members of the RoB-IN team having access (so we can feel uninhibited about what we put up). GC would be the maintainer of this Web-based documentation.

RC proposed that the "functional design" document listed in the original timetable be replaced by a "running" design document held as a section of the Web page documentation. This would be preset with bullet points for the various design issues, which would be filled in as they are considered. GC agreed to provide a mechanism for "pulling" the complete design document in one operation (probably an automatically generated LATEX file).

5) Processor Choice / Hardware Iterations / Timetable

The discussion began with consideration of the AMD29k and PPC-603e as the only two processors apparently meeting the constraints: all the others seemed too slow, apart from the Pentium which was too hot. The AMD29k was discounted since AMD had announced that this product line would be curtailed (also AMD seem in a somewhat precarious commercial position). However RM was also interested in the i960RP since it is designed for easy interfacing to PCI.

We went on to discuss the merits of splitting the hardware development into two stages, primarily to allow for the early production of a board that could be used for software development. The first stage would be a board with cpu and PCI bridge (either in PCI or PMC format) and may be available "off the shelf" as an evaluation kit (e.g. i960). Initially this seemed a good idea, but we were concerned when we projected that the first full board would not be ready for testing until mid-1997.

After much discussion it transpired that the most critical factor in the processor choice is probably development time. There was concern that a general-purpose processor like the PPC might be particularly tricky to embed. The i960 might be easier depending on the details of its evaluation kit, but the easiest option seems to be the C40 or C30 since it should be a straightforward evolution of the existing buffer. The problem with the TI chips is their comparatively low performance, but this is not so important if they can be coded in assembler (the original performance estimates assumed C, at a factor 2 slower).

The conclusion was that we should proceed with on the assumption that we will use the C30, which is reasonably compatible with the C40, but without some of the special features which are no longer relevant to the buffer design. An important advantage of the C30 is that is about a quarter of the size of the C40, which may prove crucial when trying to fit the design into a PMC footprint. However, RM will still enquire about higher speed versions of the i960, and we should still try to find out if there are development facilities that would simplify designing around the PPC. A processor-choice subgroup of BG and GC was commissioned to pursue these matters.

RC agreed to update the timetable in discussion with BG and GC assuming the use of the C30.

6) Design Issues

We attempted to draft a list of design issues which would appear as bullet points on the Web page documentation:

(Check through draft spec and URD. Order as URD.)

7) PCI v PMC

We discussed the relative merits of producing a PCI or PMC format board. The advantage of the former is that it would be easier to design and easier to develop with (more development sites). However it was felt to be fundamentally important to produce a board meeting the PMC constraints (with the possible exception of board height). There might still be merit in producing a PCI board for use where, for example, a VME-based PPC cannot be provided; it might even be worthwhile to produce a PCI board FIRST to ease development.

However it was stressed that it is crucial that the design fit on a PMC board; we should confirm as soon as possible whether or not this can be done, and if not, what compromises might make it possible.

8) Long Term

There was some discussion of likely long-term formats (and performance parameters). RM was confident that the current plan using PMC PCI and VME was still a good path to follow

9) Next Meeting

JS, RC(?), to meet with RM and OB in CERN during November Atlas week - next meeting to be arranged then (in UK for cost reasons?).

10) Summary of Actions