Subject:
Re: CERN-TMS: Data Measurements Required
From:
Jeroen Belleman <Jeroen.Belleman@cern.ch>
Date:
Thu, 02 Nov 2006 10:57:00 +0100
To:
Terry Barnaby <terry@beam.ltd.uk>, Andrew McCormick <am@alpha-data.com>
CC:
Greg Kasprowicz <grzegorz.kasprowicz@cern.ch>, Bill Blyth <bb@alpha-data.com>, Uli Raich <Uli.Raich@cern.ch>

Terry Barnaby wrote:

> On the calculation of averages using filters rather than mean's, do you have a filter characteristic in mind ? Would something like a 4th order lowpass FIR based filter be Ok ? Should we reset the filters on a harmonic change or would it be Ok to keep the filters running and live with the artifacts of the change ?


No, a 4th order FIR won't do. The original specs called for averaging
over 100 or so turns and I think a 100-tap FIR is unreasonable. A 1st
or 2nd order IIR should do fine, however. I think it's OK to keep the
filters running without ever resetting them. The purpose is to get
better resolution by reducing the 'bandwidth' of the measurement.

> You state that the System Controller should keep a cache of "interesting or frequently made measurements". Which measurements would be interesting or frequent ? We could just cache all measurements made.


I was talking of the measurement requested by the operators. Typically
they ask for trajectories at injection, transition and around various
intentional orbit distortions. The idea is that once requested, we'd
keep doing the measurement, even if no request is outstanding, so that
we can pop it onto the screen immediately when finally a request is
made, without having to wait for the accelerator to go through its
cycle.

> I assumed that we would only store the RF buckets actually containing beam anyway so this should not be a problem.


Filling patterns tend to vary. I don't want to have to tweak the
system *every* time something changes, so the original spec said we'd
store data for all RF buckets, whether filled or not. However, there
is nothing against skipping empty buckets for beams with stable
filling patterns.

>  [...] Indeed we could install the Linux development tools on the System Controllers if required so that the spare system controller could be used to compile code for the system.


Yes, that would be good.

> There is a preliminary softwareDesign document on the website that covers the softwareDesign in a bit more detail. This is at:
> https://portal.beam.ltd.uk/support/cern/design/softwareDesign.pdf


OK, I picked it up. Ah, more RPCs. ;-) I must read it more carefully
in order to appreciate its implications.

> 1. We have stated that the System Controllers would have SCSI or SATA
> disk drives. [...]

I have no preference.

> 2. On the subject of sampling particular signals for testing purposes as
> stated in the specification document "4.12 Diagnostics". Is it Ok to
> switch a Pick-Up from normal operation to test mode where it would store
> the test signals in the DDR memory instead of the normal data signals,
> or do you want the ability to capture the test signals while performing
> normal data processing ?

The latter, really. The test signals are needed to be able to verify
correct operation and to allow trouble-shooting. Running in a special
test mode would make no sense. Only short records (~1k samples) of two
signals from the mentioned set would be needed at a time. Maybe we can
use a standard FPGA debugging tool, such as Chipscope instead. It would
be a nuisance to have to start up an FPGA development environment in order
to use it though, not to mention that these tools tend to mutate rather
more often than I like. I'd also want remote access, over the network.

> 3. We are hoping to have the higher level design documents finished
> early next week. As part of the Tender terms CERN has to agree the
> design before we can embark on the development and implementation of the
> system. The time-scales for the hardware development are especially tight.
> Do you know how long CERN will need, after we present the design
> documents, to agree to the TMS design ?

Oh dear, there's a hard question! If I were the only one involved,
a week or two should be enough I'd think. Just the time to carefully
read the docs and get answers to the questions that may arise.
As soon as our administration is involved, any planning I might try to
make just becomes so much wind. Have you heard of this newly discovered
chemical element, Administratium?

> 4. Have you had a chance to think about the integrated
> PhaseTable/SwitchTable idea ? I have put more info on this in the document:
> https://portal.beam.ltd.uk/support/cern/design/pupeApi-t1.pdf

Yes, last week (24/10) I said 'OK, no problem' to this question, however
I now see I was a little too quick. The basic idea of 16 phase tables,
initialised entirely in time for the new cycle, is fine. Just counting
timing input events to step to the next table is not. Better would be to
associate one table with each timing event, so that if an event is missing,
we still get the right table after the next event. Harmonic changes must be
counted however, because we decided to put them all on the same wire.

That's all for now.

Best regards,
Jeroen Belleman