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
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.
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:
- Use of TTC input for checking beam-crossing IDs against event IDs:
at RoD or RoB?
- "Pinging" of RoD from RoB to check that RoD is alive.
- 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.
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.
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).
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.
We attempted to draft a list of design issues which would appear as
bullet points on the Web page documentation:
- Block diagram
- Mechanical layout (beginning with starting template showing S-Link and
CMC constraints - OB agreed to provide S-Link template).
- PCI message passing
- Error handling
- Testing / testability
- Self-test
- Initialisation / reset
- Downloading / EPROM
- Off-board control
- Input buffering
- Processor choice
- Memory size & organisation / fifo width
(Check through draft spec and URD. Order as URD.)
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.
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
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?).
- ACTION 1) RC to produce RoB-IN "product brief" for distribution
- ACTION 2) GC to update WWW page with design issues
- ACTION 3) BG + GC to make processor recommendation
- ACTION 4) RC to update timetable for the C30 processor option
- ACTION 5) OB to provdide S-Link template drawing
- ACTION 6) RM to inquire about higher-speed versions of i960