CMX Review: Sam's comments > Here is my initial list of comments and questions: > > 1.4 Requirements changes since PDR: > > it is pointed out that there are three cable I/O backplane > signal pairs not connected to the RTM. These were added as > contingency (and because there was room for them...). > It is understood that the RTM would need to be replaced > to use these. Am I correct in understanding that > these pins are connected to the BF FPGA on the CMX? That is correct. From the Base Function FPGA the CMX can drive or receive all of the backplane LVDS pin pairs, 28 LVDS signals on each of the 3 cables. Cable #1 consists of signals M_00 to M_26 plus M_81 Cable #2 consists of signals M_27 to M_53 plus M_82 Cable #3 consists of signals M_54 to M_80 plus M_83 > 2.2.1 Inputs from JEM or CPM (and elsewhere): > > It has already been pointed out that the characteristic > impedance of the backplane lines are 60 Ohms ? 10%, not 65. We plan to move the CMX design to have 60 Ohm traces for its backplane inputs. The 60 Ohm traces are an easier pcb to manufacture. I plan to move the simulation of this circuit so that both the backplane and the CMX will be 60 Ohm Zo but I have not done this yet. I'm not anticipating that this 65 to 60 Ohm change in Zo will make a large change in the simulator output. > In 3.2, > > it is mentioned that a transition from 65 to 50 Ohms over ~1 cm > final trace to the BF input pins has very low impact on signal > integrity (as expected). So 60 to 50 should be even better. Because this last 1 cm is short compared to the signal wavelength the main effect that I expect to see from it is a small capacitive "bump" at the end of the transmission line. The I/O Block and the package capacitance for these Virtex-6 inputs is already a little over 10 pFd so this was a potential concern. The simulation shows that it is not much of a problem. As one would expect, the thing that we can not live without is back termination on these lines from the processors. > 3.6 DAQ and RoI G-link outputs > > Each slow optical output link is implemented in an SFP transceiver, > with the input signals disconnected (RD+, RD-, Rx_LOS). > I know we have assumed G-link output up to now for everything, > but in the L1Topo review it turned out that we cannot count > on the availability of 9U L1Calo RODs to read out L1Topo. > So if we use the TP FPGA for readout, we may have to implement > S-link readout directly to the DAQ and RoIB systems. > This means bi-directional optical links, plus an electrical > "FIFO full" output. > > So here is my question....is it possible to connect the input signals > (RD+, RD-, Rx_LOS) from the two TP SFP cages and the TP FPGA? > This would make it possible to run an s-link protocol from that FPGA. > I know that the front panel is too crowded to make room for a pair > of LEMO connectors as well, but if we needed to use a CMX > for topo processing, I guess we could break out a couple > of the CTP LVDS output signals and externally convert them > to TTL over LEMO. As the design now stands we are using all 36 GTX receiver inputs on the TP FPGA to receive high-speed signals from the 3 MiniPOD devices that are inputs to the TP FPGA. To connect the SFP transceiver RD+, RD- lines to the TP FPGA would require either dropping some of these MiniPOD channels or moving the design to a different Virtex-6 part for the TP FPGA. If it is useful it should be possible to route the RD+ RD- signals from any of the SFP cages to GTX inputs on the Base Function FPGA. Would a Virtex generated S-Link need a reference clock for these GTX transceiver other than the currently available LHC locked 40.08 and 320.64 MHz ? We could probably place 2 mid card LEMO connectors and make front panel notches to pass through 2 small coax cables if that is useful. What signal levels are needed for this connection ? We do have Emergency/Spare/DeBug signals from each of the 3 FPGAs on the CMX routed to a header (J14) on the card. In general we like the idea of including as much flexibility and as many "lifeboats" as practical in the CMX design. What we do not put in etch will not be there if we need it. We strongly welcome ideas like this and are happy to include any extra flexibility features that do not interfere with the intended function of the CMX card. > 4.7 Jumpers > > Geographic address bits 1, 2 and 3 are not needed at all by the CMX. > > Basically, each type of module in the crate uses only the address > bits necessary to distinguish it in the system. For CMM (and CMX), > there are only two such modules in the crate. So geographic address > pin 0 is enough to identify which of the two possible slots a CMM/CMX > is sitting in. To tell the CMM/CMX which of the six crates it is > sitting in, address pins 4-6 are set by an octal rotary switch > that encodes the crate number. > > So you don't need jumpers for these bits (or for that matter, > FPGA I/O pins). It took me a while to understand the system wide Geographical Addressing in the L1Calo. It's a nice clean setup. I can understand how the firmware in the CMX FPGAs could be smart enough to know what its doing without Geo-Adrs lines 1,2,3 but I had assumed that we need to define the state of all 7 Geo Adrs bits because all 7 are used as ID bits by the TTCDec when the TTCDec is being Reset. Because we do not know all of the details and history of L1Calo - this is an example of what we have tried to do, i.e. when in doubt use both belt and suspenders. Additional Comments to Sam's Questions: --------------------------------------- From Steve in reply to needing all 7 Geo-Adrs bits for TTCDec > just on the point below, yes I think you're right. > If the TTCDec uses these bits in the current CMM, then > we should do the same. But it's worth being aware of > the fact that so far in operating L1Calo, we've never > made use of individually addressed TTC commands, to the > best of my knowledge. I think we've only ever used > broadcast commands, so this is not a highly important > aspect of the system. From Sam in reply to Steve > Are you sure we are not using individually addressed TTC > commands? How do the deskew clocks get adjusted? From Uli in reply to Sam > I believe (and can confirm for the JEM) that on L1Calo > we have always controlled TTCrx clock skew via VME / I2C. From Steve in reply to Uli > Yes, that's also true for the CPM and I'm pretty sure > this is true throughout. Some modules don't actually > use it (eg the ROD, and possibly the PPM). From Sam In reply to routing SFP cage RD+ RD- signals to the BF FPGA > This MIGHT be useful. As I understand, The RX line on the > SLINK receives a flow-control signal back from the > destination to stop transmission if the destination buffer > is getting full. So if that signal can be sent from the BF > to the TP FPGA (a regular GPIO line should do), this could > be a workable solution. In reply to the required GTX clock for Virtex generated S-Link > The S-link is designed for 40 MHz data input and output, > so I am pretty sure the available (CMX) clocks ought to > work. I would ask for confirmation from RAL, who built > the L1Calo ROD. > > For more information, here is the HOLA documentation: > > http://hsi.web.cern.ch/hsi/s-link/devices/hola/ > > And here is the S-link specification: > > http://hsi.web.cern.ch/HSI/s-link/spec/spec/ In reply to CMX mid card Lemo connectors for S-Link > According to the specification, the L1Calo ROD uses a > single-pole LEMO 00 connector for ROD BUSY, with TTL > logic level (active low). From Uli in reply to Sam > Be warned about reference clocks for high speed links: > Both the G-link (I believe to remember) on the existent > RODs, and the TLK2501 on the existent HOLA require a > frequency match between transmitter and receiver within > 100ppm. Our RODS have a 40.0000 G-Link reference, the > existent HOLAs a 100.000 MHz reference crystal clock, > as far as I know. > > So into neither of the devices we should send any data > at LHC buch clock multiples, unless we are prepared to > mount an appropriate crystal clock on the receivers. From Sam in reply to Uli > Thanks for catching that, Uli. > > I found the parts list for the HOLA, and they do indeed > use a 100.000 clock generator from Pletronics. > > I am attaching the list for reference, in case it is useful.