Dan's Questions > The following is a list of areas in the CMX design > where I can imagine that there may be problems: > 1. TTCDec signals to the Base Function and Topological > Processor FPGAs - what signals are needed and what > signals are optional ? This is mainly an issue > with the Base Function FPGA where we do not want to > use any routing real-estate for un-needed TTCDec > signals if that real-estate could be better used > for optimum routing of the 400 backplane processor > signals. All TTCDec output signals are being routed > to the Board Support FPGA. Routing to the Topological > Processor FPGA is not as much of an issue. Will > potential uses of the CMX card require TTCDec signals > that the CMM did not use ? From Uli: Probably not, but perhaps the CMMers should comment > 2. Clock Generation - the current design uses narrow > band quartz oscillator PLLs for clock generation > (to provide the cleanest possible clocks for the > Xilinx GTX Transceivers) but this makes the CMX > a 40.08 MHz operation only card. It can not run > at 40.00 MHz. Is this OK ? From Uli: The topo processor is designed for 40.08 only RTDP, so there is probably no reason to have the upstream module run at 40.00. However, would be great if you could let us know about the device chosen... From Weiming: Concerning the G-Link reference clock issue, I checked the current ROD schematic that it is capable of both simplex method 2 and simplex method 3 (HDMP-1022/1024). Although the ROD spec says the G-Link is running in simplex method 2, I believe it is actually running in simplex method 3, which means the G-Link receiver on current ROD uses the local crystal clock (40.00MHz) for frequency acquisition at link start-up. Further on in the HDMP-1022/1024 datasheet, it recommends to select crystal oscillators between 0.1% to 0.001% matching for reasonable link lock up time. Now the difference between 40.00 and 40.08 is 0.2%, outside of the recommended range. So, it seems a 40.00MHz crystal clock is needed for G-Link on CMX. > 3. Fiber-Optic cable options - are there any details > of the CMX to L1Topo fiber-optic cables that we > need to agree upon now, e.g. male vs female MTP > connectors on the CMX ? The current CMX design > uses 12 fiber MTP connectors (not 24 or ...) > is that OK ? Will we need special MTP patch > cables to wire up the system ? If so who is > purchasing these cables ? From Uli: should be male 12-way connectors on your modules. We will require cables that re-organize the fibres from 4*12-way female to 48-way female. We have assumed we will buy our input cables, however so far we haven't got any quote on that. Understood we need to confirm that soon. > 4. The Avago MiniPOD optical devices are tall enough > so that by the VME specification CMX will be > illegally tall by 0.79mm i.e. the tops of the > MiniPOD devices will come 0.79mm into the 2.54mm > wide inter-board separation zone. We have looked > at the cards that these MiniPODs will be up against > and it looks like everything will physically fit > but we should all agree that this design is either > OK or decide that CMX should try to use the MicroPOD > optical components. From Uli: Within a month or so the new micropod/AMP devices are meant to appear on the market. We have just signed a new NDA and hope to receive information on those devices as well. In case you consider that a possible modification post prototype... > 5. I do not understand the connections between the > CAN-Bus monitoring and the VME-Bus that I see on > the CMM card. What is needed / preferred here ? > Is it "legal" to keep the CAN-Bus monitoring a > simple separate independent system on the CMX card ? > CMX will have a different list of CAN-Bus monitor > points than the CMM does. Is this a software issue > for the CAN-Bus microprocessor ? > 6. Over the years we have made lots of Xilinx FPGA > designs and have used basically all of the ways to > configure a Xilinx part except for using a > System-ACE. I have a nice design to copy in the > CMM and from Yuri's work but clearly we dare not > screw up configuration. Because of lack of front > panel space the not so "Compact Flash" card on > the CMX does not plug in through the front panel. > Is that OK ? > 7. Testing - The simple stuff like: initial power up, > configuration, VME communication, stand alone data > loop tests, we can take care of. Is this period of > L1Topo and CMX reviews a good opportunity to sketch > out the first "get the cards together" tests ? > With planning we could try to make any firmware that > is written for stand alone tests also work for the > get together tests. With high speed serial links > the Physics community has some history of everything > working well until all of the cards in a system > are put together so it's good to start the > "cards together" tests early if we can. From Uli: I agree that we should plan for connecting up systems early, in the CERN test lab.