Subject: Re: CERN-TMS: Questions From: Jeroen Belleman Date: Mon, 23 Oct 2006 17:04:50 +0200 To: Terry Barnaby CC: Greg Kasprowicz , Uli Raich Terry Barnaby wrote: > Hi Jeroen, > > Thanks for the information, I will feed back this into the design. > Please bear with us has we come up to speed on the details of the TMS :) > > On the H-CHANGE event, would it be possible for the start and end of the > H-CHANGE period to be signaled[...] > > Another option would be to have a register which defines how many RF buckets the TMS should sample per orbit. The TMS would then provide data values for this number of RF buckets in memory irrespective of the actual number of RF buckets (although they should be the same). This number would then be updated on the H-CHANGE signal to a new value. This would then be used for the next set of particle bunches the address of which would be stored in a H-CHANGE table. This would make sure that the memory usage would be consistent and accurate. A H-CHANGE_START and a H-CHANGE_END is indeed what we have at present. The present system is blind in between, which is oone of the issues I'm trying to fix with the new system. Your 2nd option is more in line with what I had in mind. There is no need for a register to hold the number of RF buckets, because that is implicit in the way the Gate column of the phase table is filled. We constrain the H-change to occur on an integer number of turns, switch from one Gate column to the next and record the address at which this happens in the H-change table. All PU stations should see the change at the same address. I think it's water tight. Of course, for the matter of DMA access, there is still a discontinuity at the H-change, the system storing h1 values before and h2 after. As I said, I think we'll resolve that by simply prohibiting DMA *across* a H-change. We just stop a given DMA transfer at the H-change and then initiate another with different address increments for the part just after. Software would ensure that that condition is fulfilled. > On the subject of loading the "actual frequency register of the PLL a few ms before injection", could this just be done on CYCLE_START and CAL_STOP or can it be on the INJECTION signal itself or does it need to have a programmable delay from CYCLE_START in ms ? Well, we may have a little bit of a can of worms here. Or perhaps not. I'm just not entirely sure. Let me explain: The reference frequency Fref, which we get from the accelerating RF system, is based on a DDS oscillator, driven by a look-up table which gets its input from a measurement of the magnetic field of the main bending magnet. The relation between field and frequency is shown here: http://cern.ch/jeroen/tmp/synchro0.shtml . The look-up table contains the curve traced out by that function. The field measurement is transmitted using B-up and B-down pulses with a resolution of 10uT. Every cycle, we reset B-counters at CYCLE-START. Then, about 25ms into the cycle, a burst of pulses arrives which brings up the B_counter to the field present at that time, which I believe is just the remanent field, about 5mT. At around 100ms, i.e., around CAL_STOP, it starts to ramp up towards the injection field, about 101mT for protons, which it reaches at around 160ms. So, if we set our initial frequency at CAL-STOP, Fref is still very low, if it's present at all. When it sweeps up with the magnetic field, our synchronisation loop will catch and follow the first harmonic of Fref that happens to sweep past its initial value, and thus it will end up running at a much higher frequency than intended. I think... The loop is purposely designed so that it will lock to harmonics of the input frequency. After all, that is what it must do when locking to a single bunch on h=8, for example. Effectively, it is then locked to the eighth harmonic of the input signal. We avoid all this by setting the frequency at a time when Fref actually has the right value, just before injection. It must be done *before* injection, and not *at injection* so that the loop has time to align its phase with Fref before the beam actually arrives. An alternative is to initialise it at CAL_STOP, but leave the loop open, so that it cannot lock to anything. Then close the loop a few ms before injection. We already have a millisecond counter. We would need an additional comparator and a register to hold the initialisation timing to make this happen. > What is the actual resolution of the output data you require ? I have set this as 16bits per Sigma, DeltaX and DeltaY value in the PUPE API. We note that Gregs VHDL code uses 24 bits per value. To simplify and improve access speeds it would be best to use 64bits per set of values. > We could use 16+16+16 + 16 spare (the spare 16 bits could be used for other purposes such as timing in microseconds etc) or we could use 21+21+21 + 1 spare. The latter would be more difficult for software to handle but if we use an output DMA engine this could translate to 21bit to 32bit values on the fly if required. I think it's the 16+16+16 + 16 spare scheme which is best. We won't get any better resolution by using more bits. In principle, 10 bits would be enough to get the required resolution if the ADCs were optimally filled. (0.1mm in a 80mm aperture). Throw in a few more bits to deal with partially filled ADCs and various other limitations that certainly exist but won't come to mind right now, and I think 16 bits is still generous. > > Using the Xilinx internal PowerPC cores should not eat deeply into the FPGA resources [...] rough estimate of 25%. > There would be other issues with this approach however including: > 1. Extra development time [...] > 2. Routing on the FPGA would be harder [...] > 3. How to boot the FPGA fabric[...] > > We believe that within the cost and timing constraints of the project > it would be best to stick with the original cPCI bus based design for now. However, we will include the Gigabit Ethernet ports on the hardware and design the software and API's such that the system could be modified, in the future, to use this approach. > Is this Ok ? Yes, I think that is the right course of action. I'll continue right away with the questions in your 2nd message of today: > You say that the machine cycles can be consecutive. > Is there a minimum time we can assume between the CYCLE_END and > CYCLE_START timing signals ? Yes, fortunately, there is. The official CYCLE_END occurs 30ms before the next CYCLE_START. If we use ELFT for that purpose, it's even earlier, but it varies from cycle to cycle. I've seen from 400ms to over a second. I'll send you "The PS controls for newcomers", all of 1.3MB, in a separate message, as I don't want to burden the Cc: recipients' mailboxes with it. Regards, Jeroen