CMX Review: Uli's comments > I did comment on reference frequency tolerance of > ROD link and S-Link earlier. Yes, thank you for that information. We still need to discuss this in the CMX Review meeting. What do folks want, should we make CMX so that it can directly drive S-Link ? > Moreover I started to dig into the real-time transmission > again after noticing that you specify the VCXO frequency > as 40.0787 MHZ, whereas the L1Topo receive reference > crystal clocks had been specified as 40.08 MHz. That's > just 30 ppm difference, however, I do not know what the > truth is, and it would be good to know the true LHC bunch > clock frequency including error. The crystal clock used > on L1Topo has a total frequency error (over full > temperature range) of 150 ppm. GTX and GTH have a > requirement of 200ppm max (at highest bit rates). So with > an additional error on the LHC clock we are approaching > that limit. Yuri found a couple of very nice references for me about the actual LHC RF frequencies. We have all 3 of these documents on our CMX web site here in the directory: http://www.pa.msu.edu/hep/atlas/l1calo/reference/other/clock/ I have a summary of this information near the end of the following file in a section called "Background:" http://www.pa.msu.edu/hep/atlas/l1calo/cmx/hardware/details/cmx_ab_clock_gen_and_dist.txt The 40.0787 MHz center frequency of the quartz PLLs that are currently specified for the CMX was picked to be in the center of the LHC RF range when both proton and heavy ion running are considered. The actual PLL devices have a "pull range" of +- 50 ppm. The actual range of the LHC RF is only about +- 7 ppm from this 40.0787 MHz PLL center frequency. My assumption is that CMX will always be locked to a reference frequency near the 40.08 MHz LHC frequency. If CMX needs to run at 40.00 MHz then we need to change the current design. > The reason we opted to go for crystal based reference on > the receiving end was for the excellent jitter figures, > though, if that generates frequency tolerance issues... > To be decided whether we should do something about that > at either prototype or production module stage. Would > consider daughter module... I too want to provide the cleanest practical reference clocks to the Virtex GTX transceivers - that's why I like the crystal clocks. > Mainz wish to pay for their inputs. To be decided whether > going for 6-->48 or 12-->48 octopus. It was our understanding that for simplicity and convenience that folks wanted the CMX to use MTP feedthroughs with only one ribbon of 12 fibers. That gives the most straight forward input to the "optical patch panel" between CMX and L1Topo. Does the Review Panel have any new recommendations about how the CMX optical MTP outputs should be setup ? > backplane signal termination: > Didn't we say (ages ago) that the clock lines should be > terminated at both ends, and for the data lines source > termination would be considered good enough ? Obviously this is a very important point. For the I/O Banks that receive the processor data and clock lines the CMX layout provides DCI reference resistors and one variable reference voltage. For the CMX we have assumed that any required termination will be of a form internal to the FPGA. During the review I hope that we can discuss this topic, verify that nothing else is needed on the CMX circuit board, and explicitly state what termination schemes are to be used. This point is similar to the last question in Richard's note, i.e. exactly how does the CMX receive the 400 160 MHz backplane signals. Philippe is digging up links to the existing documents that he can find on this topic and will included them in the CMX Review web site. We need to be explicit and say for example parallel termination if that's what people mean. > VME-- > On the JEM we have 3.3V signalling, 5V-tolerant. Can't > see a point going for true 5V signalling. How is it done > on the other processor modules ? Yes, CMX is doing the same thing. I've built all our VME stuff that way for years. The only 5V VME part is the open collector 74F38 driver for the VME DTACK_B line. It sits right next to where the 5V bus needs to run anyway. Most of the 5V components on the CMX have to do with the CAN-Bus monitoring. We stayed with these 5V components to have "guaranteed" Can-Bus micro-processor software compatibility with the CMM card. In the end, I'm not certain how well that is going to work out. I would be very happy to dump all of the 5V parts. > TTCdec reset / ID: > you generate some ID bits without resistors, with > 3-statable drivers. Not sure it has been done on the other > modules like that before (not on the JEM anyway). Reading > through the TTCRx manual lets one assume that should work. > However there seems to be no timing diagram showing when > signals are asserted and read in wrt reset signal edges. I too could not find in the TTCRx document any timing information to indicated when during its Reset process that the TTCRx actually reads in the 16 ID bits. Currently CMX: Receives 4 Geo-Adrs lines from the backplane and uses jumpers to define the other 3 Geo-Adrs lines. This makes the full set of 7 Geo-Adrs lines. It uses pull-up pull-down resistors to define the 9 TTCDec ID bits that do not come from the 7 Geo-Adrs lines. It uses 3 state buffers to send these 7 Geo-Adrs lines to the TTCDec as ID bits during the TTCDec Reset process. This setup in the current the CMX design is very similar to what I see in the CMM design. Additional Comments to Uli's Questions: --------------------------------------- From Sam in reply to CMX TP FPGA driving S-Link > My own feeling is that yes, if the TP FPGA is to have > L1Topo capability we ought to be able to directly drive S-link. > > The current CMM drives G-link outputs with a 40.000 MHz > crystal clock. What is the downside to providing a 40.000 MHz > oscillator on board the CMM? > > This could be used to drive the emulated G-link outputs > with the same frequency as other L1Calo readout links, > and also S-link at a compatible frequency. From Sam in reply to CMX being 40.08 MHz LHC locked only > Most of the CMX does need to run at 40.08 MHz. But as i > said above, in the current system the G-links run at > 40.00 MHz, and the existing CMM firmware includes code > for managing the transition between the two clock domains. From Sam in reply to crystal based reference clocks > But we also want synchronous transmission, so at the > transmitting end we need to use a jitter-cleaned LHC > clock derived from the TTCdec deskew output From Sam in reply to CMX optic output MTP with 1 ribon > It was the understanding at the time, but if front-panel > space can be usefully freed by going to 2 x MTP 48, I would > support this. We need to discuss this at the review. From Sam in reply to Geo-Adrs and TTCDec ID > This sounds very reasonable. As I pointed out before, > the CMX only needs Geo-Adr bit 0 (and the three crate-ID bits) > to uniquely identify itself in the system. But you are right > that the TTCDec does need more bits to set a unique TTC > address. So following the lead of the current CMM design > is a good plan.