The CLEO VMEchip Gate Array MCST and CBLT Support in an Altera FPGA

Paper: 154
Session: G (poster)
Presenter: Wanke, Rainer, Ohio State University, Columbus
Keywords: data acquisition systems, simulation, special architectures


The CLEO VMEchip Gate Array
MCST and CBLT Support in an Altera FPGA

K. Honscheid, C. Gwon, J. Lorenc, R. Wanke, A. Wolf
Ohio State University
174 W 18th Avenue
Columbus, Ohio 43210}

E. Lipeles, A. Shapiro, A. Weinstein, F. Würthwein
California Institute of Technology

A. Bean, D. Coppage, C. Darling, B. Forrest, T. Noor
University of Kansas

C. Strohman
Cornell University

V. Fadeyev, J. Staeck, I Volobouev
Southern Methodist University

CLEO Collaboration

The front-end electronics for the CLEO III trigger, the RICH and the
silicon vertex detector will be built in VME. The databoards for all
these systems have a very similar architecture: a component specific part
followed by a multiple event buffer and a VME bus interface.
The last two units are carefully designed so
so they can be used by all CLEO III components.

The fastest way for a VME CPU board to read data via the backplane is
via a 64bit block transfer.
However,
within VME64 there is no operation that guarantees efficient readout of
large blocks of data that are sparsely distributed among a series of
slave modules in a VME crate.
This has led the NIM Committee's VME for physics task group
(VME-P) of the VME International Physics Association (VIPA)
to propose two new protocols,
multi-cast (MCST) and chained block transfer (CBLT),
that enable a master to address many slaves
at once.

For CLEO III we have implemented these new VME-P protocols in an Altera
FPGA chip (EPM7256).
This VME-slave interface chip supports A32/D64 and A32/D32 CBLT cycles.
It furthermore supports standard read/write cycles for A32/D32 that are
used for board debugging and
during board initialization to load detector constants.
The VME chip's addressable registers are compliant with VME64 and VME-P
specifications for the CR/CSR space. Read/write access is therefore
accomplished with a special AM code (0x2F) and A24/D32. The latter can
be changed easily for CPU board that don't support CR/CSR addressing
as specified by VME64.

A multi-cast cycle (MCST) is a write-only
broadcast cycle where the master broadcasts
some information to all slaves at once. *DTACK is asserted by the last slave
after a token has passed through the *IACKIN/*IACKOUT daisy
chain to make sure that every slave
has decoded the broadcast.
We use this broadcast as a "read next event''
signal. All slave modules respond to this by resetting some control and status
registers, advancing the on-board read buffer counter,
and pre-fetching the first data word of the next event.
Chained block transfer or CBLT
cycles are read operations only.
The basic idea of a CBLT is to have a master CPU address several
slaves at once. The slaves determine who is to drive
the data bus in response to a data strobe by passing a token via
the *IACKIN/*IACKOUT daisy chain.
*BERR is asserted by the last slave
after all data is read out for an event.
From the perspective of the master in a crate a CBLT is nothing more than
a block transfer to the CBLT address that is terminated by a bus error.
Nothing special beyond VME64 is required from the master as all
non-standard features are implemented in the VME slave interface.
Whether a slave takes part in the token passing scheme, and which position
it holds within the chain is defined during board initialization by setting
FIRST, LAST, and CBLT-enable bits in a slave's control and status
register (CSR).

The CBLT protocol has the advantage that the master CPU doesn't have to know
how much data there is for a given event, nor how this data is distributed
across the data-boards in a VME crate.