Subject: Re: CERN-TMS: Data Measurements Required From: Jeroen Belleman Date: Thu, 02 Nov 2006 10:57:00 +0100 To: Terry Barnaby , Andrew McCormick CC: Greg Kasprowicz , Bill Blyth , Uli Raich 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