RoB-in outline specification

(Last mod: 20-Jun-1996/RC) -- Converted to HTML 23-Oct-1996 GJC

(See also associated documents:

Overview

The ROB-IN will comprise a single-width PMC module containing a hardware-controlled event-fragment buffer memory and a buffer-manager processor, which will manage the use of the buffer memory pages according to data requests and trigger decisions received across the PMC's PCI interface, and furnish requested data to predetermined addresses on the PCI bus (e.g. ROB-OUT or ROB-Controller memory).

Event-fragment data input

Event-fragment data will be received on an S-LINK LDC interface connection from the ROD at an average rate of up to 100 MBytes/sec and written directly into "pages" of buffer memory using addresses taken from the "free-page FIFO". There will need to be some buffering between the S-LINK input and the buffer memory since each is driven by a different clock, but a long FIFO is not required. Indeed a simple "double-buffer" may suffice.

Under certain circumstances an XOFF signal back to the ROD will be generated on the S-LINK interface in order to stem the flow of data. This will automatically occur whenever the number of entries in the free-page FIFO drops below a programmable threshold, or when the ROB-IN is powered up or reset.

At the end of each page, or at the end of each event-fragment, the last address used will be written to the "used-page FIFO" along with status bits indicating whether this is the first, intermediate, or last page of the event-fragment. The address logic will then read the next value in the free-page FIFO as a base for addressing the subsequent page.

Both the START and the END of each event-fragment will be signalled on the S-LINK input (for instance by bits in a "control" word flagged by the S-LINK control/data bit).

The length of pages will be adjustable in the hardware logic. Neither this nor the buffer-memory size should be unduly constrained by address-widths.

Access to buffer memory

Access to the buffer memory must be multiplexed between the front-end input and the ROB-IN processor and/or DMA to the PMC interface. In normal operation the front-end access need only be write access and the processor or DMA access need only be read. For testing, however, it is planned to allow both read and write access from the processor/DMA side.

The multiplexing need not be symmetrical in bandwidth (in the current ROB the processor can only take a maximum of one cycle in four), but consideration must be given to possible eventual delays on the PCI bus for any accesses directly between the PCI and buffer memory and these may be increased if the read bandwidth is restricted.

Buffer management

The tasks of the buffer manager are to:

to service the free-page and used-page FIFOs
to index the event-fragments
to receive various event-fragment-data requests (for RoI data, monitoring data and LVL3 data) and provide the requested data if possible
to receive LVL2 decisions and either set aside data awaiting a LVL3 data request or make the relevant data pages available for re-use (by putting them in the free-page FIFO)
to monitor, record and report error conditions
to be able to reset the system and carry out appropriate test procedures on request

Input messages are:

RoI-data request
Monitor-data request
LVL3-data request
LVL2 decision
Various control messages

Possible outputs are:

RoI-data for LVL2 processing
Monitor-data
LVL3-data for LVL3 processing
Various error and status messages

Software strategies will be explored, but it is likely that they will be based on principles employed in the current ROB:

polling and servicing different input sources in turn
indexing event-fragments in a simple cyclically-used lookup table according to the low order bits of the event-ID

In addition some strategy will be needed to keep track of long-lived events which would be overwritten in the simple indexing scheme e.g. moving their indices aside to a linked list of "special" event-fragments.

It will also be necessary to explore the implications of decisions arriving in groups as is now planned; this may favour a different polling strategy.

PCI communications

See associated document by G.Crone...

Message history

The proposed "software FIFO" scheme has the benefit of automatically providing a history window for the most recent messages and data, which is a reasonable interpretation of the URD history requirement.

Error handling

Various kinds of errors can be detected in principle (see ROB-IN URD) and it is intended to keep simple counts of these for later interrogation/reporting.

Some kinds of errors indicate a possible input link failure and it is proposed to investigate the use of XOFF/XON signalling to test the viability of the link (see separate note).

Self-testing

The possibility of local pattern generation or the use of a loadable test-data memory will be investigated (see above). Such circuitry will have to be controllable from the ROB-IN processor, but should ideally feed into the input side of the ROB-IN (in place of the ROD input) in order to test out the buffer hardware logic.

Consideration will also be given to the provision of LEDs and/or logic-analyser probe points, for instance to reflect the status of a writeable test register.