Questions from Ian: Rev. 10-May-2014 ------------------- > I didn't see any power measurements. Do you have them ? > Temperature measurements would also be nice. Power draw is obviously a function of the firmware running in the FPGAs. The card that I have worked with at MSU for power consumption tests is a card that includes the TP FPGA. The highest power draw that I have seen with this card is when it is running the GTX MiniPOD test. That data path is: BF FPGA --> MiniPOD Trans --> optic --> MiniPOD Rec --> TP FPGA This test operates all 12 channels in the MiniPOD at 6.4 Gbps. - When this CMX card is powered up but neither Virtex FPGA has been configured it draws about 22.4 Watts - When it is running the GTX MiniPOD test described above this card draws about 36.8 Watts - When it is running the above GTX MiniPOD test the Si temperature of the BF FPGA is about 40 or 41 deg C and the TP FPGA is a couple of degrees cooler. The BF heat sink is partially down wind of the TP heat sink. - There is about a 14.4 Watt increase with the GTX MiniPOD test running. All but 1 Watt of this increase comes from the Virtex Core and GTX supplies. The last 1 Watt comes from the Bulk 2V5 rail and I assume goes to the MiniPODs that are operating during this test. - I estimate that the quiescent power draw of a standard CMX card (without the TP FPGA) is about 19 or 20 Watts. > Pg 16 (+ elsewhere): impedance control -- do you know the > impedance of the last 1cm of input signal traces? Have you > done any TDR tests to observe the reflection? I'm just > curious -- the crate tests results show it isn't a problem. I will describe the CMX card's 60 Ohm traces that bring the processor card signals to the BF Virtex FPGA pins. - For most of the length of the 60 Ohm controlled impedance traces we designed the card with our estimate of the required trace width to produce a 60 Ohm Zo trace but we allow the PCB house to adjust the width of these trace segments to actually give 60 Ohm in the final PCB stackup. - For the "last cm" of these traces, which is in the trace escape pattern under the BGA, we keep the width locked at a value that gives the best PCB yield in this the highest density area of the PCB. - Note that some of these Processor Input 60 Ohm traces need to reach fairly far under the BGA. - We designed the long part of the 60 Ohm traces, that the PCB house was allowed to adjust, with a 0.12 mm width. During PCB manufacturing they plotted these traces at 0.122 mm to achieve an actual width of 0.11 mm that was the required width to give 60 Ohm Zo in the final stackup. - The last short section under the BGA was designed at 0.13 mm and resulted in an actual width of about 0.116 mm during PCB manufacturing - To first order the Zo goes as the Log of the width so 0.11 and 0.116 are about the same. - The exact Zo of this last short section is not well defined because of the forest of vias that it is running through many of which are active signals. - The anti-pads in the Ground planes for these vias would in general tend to increase the Zo so increasing to a 0.116 width is in the right direction to hold the Zo constant in this "last cm". - For me the other big concerns in this signal path are: the 10 pFd lumped capacitance at the end of this 60 Ohm trace from the input capacitance to the FPGA the longer uncontrolled Zo running through the backplane connectors - We simulated the processor card output to CMX FPGA input with different Zos for the "last cm". Any rational value made very little difference. In the simulation of this signal path the clearly most important aspect was having a back termination that was approximately correct. - I do not have the equipment to do a meaningful TDR measurement on these traces. To be meaningful it would requires a very careful setup and require having the bump from the FPGA input capacitance in place. > Pg 17: if new RTMs are required (for operation at 160 Mb/s) > whose responsibility are they? This is not something that > should impact on CMX production, but we should probably > clarify this. I don't know whose responsibility this would be. The current RTMs look lake a nice clean differential layout and I assume that they were made for 100 Ohms differential Zo and are probably OK at 160 MHz. I don't know if there are any plans to immediately test 160 MHz operation of the CMX LVDS Rear Cable connections. It's my understanding that the CMX front panel CTP LVDS connections will never be operated above 40 MHz but they have been tested at 80 MHz. > Pg 17 (+ elsewhere): is the default (CMX-CMX) cable direction > determined by geographic location? Is the default cable > (CMX-CTP) direction correct (i.e., transmit)? > > General: should functionality that isn't expected to be used, > hasn't been properly tested and would require a large amount > of firmware effort to implement, be included in the module > specification? In the past we have removed such items. > Perhaps it could be moved to an appendix? The direction of all 5 LVDS "ports" on the CMX card is under firmware control. If desired the firmware can simply hardwire any or all of them in a given direction. On CMX we needed to allow either the BF or the TP FPGA to send data out on the CTP LVDS connectors. Thus we needed some level of management of these LVDS "ports". To me the cleanest design was to use the same components and same general layout for both the front panel CTP LVDS and for the rear cable LVDS. This PRR Hardware Document is the final written description of the CMX card that we plan to make. I pushed to have this document completely describe all of the CMX card's hardware and what it can do. I did not want a description of just the subset of the CMX hardware capability that will probably be used. In this respect the CMX is probably special. For example, it has a TP FPGA with 3 MiniPODs and 2 SFP optical packages that need to be described even through there are no plans to use them. Half of this card will probably never be used but needs to be described so that people know what options are available. > Pg 47 (+ appendix L): how many of these jumpers are really > jumpers, and not solder bridges, etc? It would be nice if > such things as geographic address, for example, that > shouldn't need to be changed, were implemented in a fashion > that couldn't be easily changed or knocked off. However, > this is a trivial point and not worth delaying production. I wish that the CMX card had far fewer jumpers (e.g. zero). It grew all of these jumpers because: We kept hearing rumors about various things that people might want to do with the CMX so we did not want to hardwire things and thus rule out some function. We are still new to Atlas L1Calo and worried that we have misunderstood something and thus I did not want to hardwire functions that could result in the first CMX cards being junk. In general I don't like hardwiring even simple control lines that would be impossible to change later, e.g. hardwiring the FPGA Configuration Mode pins underneath the BGA. I would rather bring such things out to jumpers just in case we need access to them in the future. To manage the 100 jumpers there is a file (appendix L) that describes each one - including what its default state will be when the cards are assembled. Jumpers like the Geographic Address, that are the same on all of the cards, are installed during assembly. Jumpers that are unique to each card, e.g. Card Serial Number, are installed during Final Assembly at MSU. I believe that all jumpers on the CMX card are on the back side where there is more space for silkscreen description of each jumper and to avoid using tools and soldering on the easier to damage component side of the card when a jumper is being changed. Most of the jumpers are zero Ohm 0603 packages that work well during automated assembly and can also be easily worked by hand. In most of the locations where jumpers are not installed during the main assembly process we have solder paste applied and reflowed on just one pad of the 0603 foot print. This makes hand rework easier if that is necessary. The 0603 package is thin enough that I have not had any trouble so far knocking them off the back of the card. > Trivial CMX_PRR_Hardware_Document > The cross references are in a different font or font size. > Is this deliberate? > Section 2.6 is in a different font size. > Any figures for power draw? You have a sharp eye. Some of the cross references are one font size smaller. That was not intentional. The references to the web pages are in a different color for emphasis. We tried to put everything about the CMX hardware on the web for easy access. All of the data-sheets are there and all of the manufacturing data (gerbers, xy placement, everything). Section 2.6 is one font size smaller because it picked up that size during text entry and neither of us noticed it. So far the only measurements that I have on power draw are the numbers given at the top of this note. The power draw estimates from the Xilinx tool for the drafts of the Physics firmware are too low for me to believe (3 watts or something).