Hi Ed, I could make the phone meeting tomorrow at 10am if it is still on - please consult with Fernando and let me know. (You guys can write me at 9am, that is warning enough!) Fernando tentatively indicated it would get rescheduled... Better to proceed if possible I think. I think this discussion should proceed on our mailing-list (I am attaching your original document here for the benefit of other readers). I read your document, a block diagram might make it a little clearer but I think I understand what you are proposing. However, I'm afraid I don't quite agree with the plan. You propose that the SD module resync the 3 trigger bits to the outgoing half-crate clock [good] but then you go on to skew them in two different ways: First, you intend to use LVDS for the trigger bits and LVPECL for the clock. _Why_ _not_ just use LVPECL for everything? (Same question I've asked before...) Second, you intend to skew the various clock lines on the SD board to compensate for the slot-slot skew on the backplane [I don't see why we care about slot-slot skew], but _why_ _not_ then also skew the trigger lines on the SD board. As it is, your slot-clock-deskew scheme introduces a skew between clock and trigger bits within 1 slot. You add a "requirement" that the front-end boards deskew it if necessary. Well, I don't have any room for delay chips, etc., and while I could maybe use the FPGA DLL blocks to deskew, it's a pain I intend to avoid. I am not providing any such deskew feature, the ADC125 expects the trigger bits to have a particular, well-defined, universal timing specification for _example_ as follows: "The trigger bits shall be valid 0.5 ns after the rising edge of the clock and held valid until 0.0 ns after the next rising edge of the clock." However, I agree that I only require about a 3 ns window to capture the trigger bits (I am doubling the "1.5ns" figure to be conservative). So, if you wish to implement the (within-slot) skew-introducing mechanisms described, it is ok as long as you can guarantee me some fixed 3 ns window. I would prefer to, for example, simply capture the trigger bits on the falling edge of my received clock, but I will implement one (universal) phase shift as required to put the capture point anywhere in the 8 ns cycle, as long as you can specify it ~now. I don't know what the backplane slot-slot skew in VXS is (this is in the spec, right?), if it is <3 ns or so I suppose it will be possible for both of us to have our way. On the other hand, I think a better approach would be as follows: -A- Fanout your clock -B- Use trace delay (as you say, it's low jitter) to deskew the slot clocks that result (in "D" below). -C- Fanout 1:2 each of these -D- One goes to slot clock line directly -E- One drives the clock of three 'EP52's or equivalent -F- The 'EP52's drive the slot trigger lines directly To clarify a few other points: 0. Reset is just another trigger bit. The trigger distribution (and trigger receiver hardware in front end boards) should not preclude any possible encoding different commands into the bits. With 3 lines you could have 3 trigger commands (one-hot encoding), or 7 trigger commands (binary excluding 000 as a NOP), or more by serializing. Yes maybe you're "sure" you'll never need more than 3 even 10 years from now. Still, the fixed hardware, I mean boards not FPGA firmware, ought to not care about the meaning of these bits. Probably this is true of your plan for the TI and SD, I don't know. 1. I don't at all understand why the slot-slot clock skew is a big deal. The signal cables (at least for the ADC125 and F1TDC for FDC) will have a few ns of skew. Even for the ADC250, the only detrimental effect of clock skew would be to misalign the timing of signals in the energy sum... but no doubt there has to be some way of adjusting the timing of different channels and modules (by integer clock ticks) to get the energy sum to work right anyway... Isn't that true? The only other effect of clock skew is to change the "t0" calibration offset for each channel, that's ok, there has to be some calibration offset anyway... 2. Yes the ADC125 will have the geographical address pins connected so the GA is available to the VME interface FPGA. I don't intend to send it out to my other FPGA's in particular the one that does the trigger and data processing function. I _could_ of course, I just don't intend to at this time. 3. When you say the busy signal is "LVDS, positive asserted" I take it as an affirmative answer to my question that DP29+ > DP29- is the assertion of busy, DP29+ < DP29- is the negation. 4. I still have question now how does the TI take the incoming trigger information and break it down into commands for modules at 250, 125, and 31.25 MHz clock rates... Are you implying that there is a 32 ns deadtime in the trigger system, i.e., that the ADC125 will _never_ be triggered on back-to-back cycles or in fact never triggered less than 4 cycles after a previous trigger. This would be useful information, I've inquired before about it but to my knowledge I haven't heard a definitive specification. I am assuming still the ADC125 may be triggered on two consecutive cycles, but I suppose then the ADC250 will never be, and I don't understand how the F1TDC's are to handle that. Well, we can discuss further tomorrow. It's good that we're getting these important details sorted out, and I must apologize if I'm being too pushy here but I think it is important that the plan is thoroughly understood, and that it also does not just push issues from one side of a "fence" to another. Sincerely, Gerard Ed Jastrzembski wrote: > Hi Gerard, > Attached is a brief description of our ideas about signal > distribution at the crate level. I'm looking forward to hearing your > comments tomorrow. > -Ed J. > > > Gerard Visser wrote: > >> Hi Fernando, Ed, >> Sounds good - I'll look forward to reading that. >> Next friday at 10 is fine with me, I have another meeting at 11am, >> but it's good to have a time limit anyway :) >> >> - Gerard >> >> Fernando J. Barbosa wrote: >> >>> Hi Gerard, >>> >>> I talked to Ed and he will be sending you an email outlining the >>> architecture of the signal distribution chain. We have talked in the >>> past about parts of the system but it is best to put it all in >>> perspective. Actually, this will serve us well as a brief review, >>> especially in light of the main readout modules that use the VXS crates. >>> >>> Additionally, I would like to suggest that we have a conference call >>> next Friday at 10:00 a.m. (EST) to go over the VXS signal distribution >>> and its impact on board resources, delays, etc. Please let me know if >>> this works for you. >>> >>> Thanks, >>> Fernando >>>
Signal Distribution in a Crate Using VXS.doc