MIPP upgrade

Here is the message from Ron:

I just got done talking to Jin-Yuan Wu, Marcus Larwill, and Bob Demaat.

Some of the highlights...

They have minimal to no software experience.

They feel they have not been involved with software for several years and would need significant
modernization. Yes, I should talk to Raja because I would like to know what software was used for the last run,
but it does seem that since the last run was a few years ago, that that old software might be in need of

They mentioned that the last time they developed/debugged that it was under Vxworks where they were booting
some mvme2301 vintage ppc on the 14th floor off of some computer at CDF. The point was that it was not as "self-
contained" as they would like. They thought that reading out/testing from Linux would be a good thing.

I'm wondering about what testing software environment would be best to, down the road, interface with AD
controls systems --- in other words, I'm wondering if I should help develop the new acnet software???
Jim did mention how strong EPICS was in this area: being able to set up a test stand and develop a IOC that would
slide easily into the production system; I agree.

The hardware is in it's infant stage.

The board actually has two possible readout paths: VME and fast ethernet. They definitely want VME but
realize that they would be able to get greater throughput (per crate) if they used the fast ethernet (and some
low cost switch).

The board has not been plugged into a VME crate. So far, only basic testing has been done via a serial
(RS232) port.

I'm going on vacation starting, basically now, and will be gone all next week. I, not too briefly, discussed
this with Jim and do think it is a good idea for Jim to talk with Raja about the state of the existing (old)

I did mention to Bob that Spentz would be wanting to get from him a feel for how strong of a future MIPP has.
Bob seemed fairly unsure to me,

My Meeting with Raja and Company

Raja printed the MIPP upgrade proposal for me. This document highlights some of the architecture details and the hardware that they want to purchase.

Some interesting numbers are that they get four seconds of every
two minutes, and they are designing the system so that the processing of that four seconds of data happens
in thirty seconds. The events are 100KB, and about 12,0000 events are received in the four seconds. If
they are to transfer 12000 * 100000 = 1.2GB each 30 seconds (or maybe 56 seconds). If I assume that the basic
VME crate can transfer at 10MB/s, then we'd need four crates to get the needed 40MB/s to achieve the transfer
in 30 seconds. I think 10MB/s assumes no burst or DMA transfer. The VMS64 would double this number.

The board we discussed is called the MRC (MIPP readout controller). It is an 8 port universal readout board.
The second board they are developing is an MTM (MIPP trigger module). It sends serial information to the
MRC to tell it what is happening. The data will buffer up at the MRC, and then be read out by the
crate controller board. They have been using the CAEN bus extender to bridge from the VME create to a PCI
PC bus for their test stands. They confirmed what Ron had said about the lack of VME interface on the MRC.
This means they do not have a decision on the board's register-level interface that software will need to

Raja claimed to have most of the DAQ written from run one and that most of it would be reused.
This is difficult to believe at the lower levels since the hardware is almost entirely different.

The environment they seem to be familiar and comfortable with is Linux, on the PC and on the embedded
processor board.

The work they want is in four parts. Within each section is a comment about how well I understand each
the work to be done.

Test stand

They want to exercise the board - trigger it, read out data, store the data in files. For this, they
claim to just want a PC hooked to the VME crate, with specialized software to operate the board
and read out results.

This sort of test stand solution does not sound like a good thing for our group to do. A more
generic body of module testing code would be more appropriate. Using a standard VME crate
with an embedded processor board would probably be more appropriate.

What is needed here is a "driver" to operate the board and do the readout. The complexity of this
driver will depend on the operating system chosen, the infrastructure software available,
and the register level interface. I could image
using DMA to read out the buffer of the MRC.

There will need to be some control and read out software written to operate actually operate the
experiments carried out in testing the board, to transfer data out of the embedded processor,
and to store the results.

Production environment

A system is needed that can support many MRC cards and probably includes the MTM.
Some existing create-level software seems to exist, but I do not know how adaptable or
applicable it is. The test stand software will probably need to be upgraded to support
this functionality. The storage, transfer, and control functions will need some additional
work and testing.

It would be nice to use the same test stand driver here and controller/transfer code.

Event builder upgrade

Since the hardware architecture and design is different, the event builder need to be
updated to assemble events pieces from across many crates and cards.

Integration with existing DAQ

The current DAQ has a module interface for handling incoming event data and for decoding it.
Some work will be necessary to get the data from the event builder, unpack it, and make it
available to the existing DAQ tools / programs / systems.


In short, there needs to be new lower-level code to interact with the new hardware, and their
needs to be software that couples the old DAQ system with the new data that comes it.