Re: VME Histogramming memory

[mooney@aps.anl.gov (Tim Mooney)]

Alan Blankman (Lecroy) writes:
>
> I have found out that the VME histogramming memory from Struck Co. has not
> yet been completed.  I was not aware of this last week, and I must
> apologize for inadvertently misleading you.  In fact, Struck had not wanted
> us to it in our catalog... yet it slipped in anyway.  Again, my apologies
> for not being aware of its 'vaporware' status.
> 
> My understanding is that they have not yet found enough interested parties
> to warrant the investment.  Please allow me to redirect the question back
> to you; how many APS groups might be interested in such a product?  I would
> like to report an estimate back to Struck, to help them re-evaluate their
> current stance.

I think nearly all of them would be interested at some level, depending
on the features that actually get implemented, whether or not they will
have a chance to request new features, whether or not a custom VME
crate is required, and the cost.  Currently, there are around 40
beamlines at APS, with an average of roughly two experimental stations
each, in operation or under active development.  The facility has room
for roughly 30 more beamlines.  Most of the beamlines are instrumented
with VME.  I don't know what fraction of the experimental stations
would purchase a VME histogramming module.  I'm cc'ing this message to
all of the APS beamlines in the hope they will answer the question
directly.

For APS beamline-controls folks:  Here are the (planned?) features of
Struck's VME Histogramming Memory Unit, as listed in Lecroy's latest
catalog:

- Up to 65535 counts/channel
- 4M to 64M channels
- Direct memory increment mode (+1)
- Direct memory modify mode (8-bit modifier)
- 1k to 16k input FIFO (peak input rate to 20 MHz)
- Dual ported memory access (read while counting)
- Automatic overflow handling (overflow address stored in FIFO)
- Memory clear with one instruction
- TTL compatible inputs
- Simple input handshake (signal, ack, data)
- Uses standard SIMMs

Personally, I'd like the option to specify at startup time the data
depth (e.g., 16 or 32 bits).  I'd also like to know the expected
sustained input rate, whether or not the module would be useable as a
multichannel scaler (i.e., address increment controllable from a time
base, and/or from an external signal), what possibility there might be
for hardware supported regions of interest (e.g., set an output bit, and
optionally halt acquisition, when the sum over some predetermined range
of channels reaches a predetermined number), and whether or not there
will be any support for multiplexing several (say 16) separate input
sources.

Tim Mooney