Questions from Richard:                       Rev. 11-May-2014
-----------------------


1) It would be good to have a rough idea of power consumption
   of the CMX, the current drawn from the 5V input, with for
   example the CMX running in a CMM Emulation mode. There isnt
   much headroom in the crate power.  (Fortunately the upgraded
   CPMs will each take slightly less power.Sorry I dont have a
   value to hand)


I'm sorry but we have no measurements of power consumption
when the CMX is running Physics Trigger firmware,  e.g. CMM
emulation.  The estimates of the power consumption provided
by the Xilinx tools that I have seen for draft versions of
the Physics Trigger firmware are too low to be believed.

The only actual measurements that I have are the quiescent
power draw and power draw while running the GTX MiniPOD link
test.  The GTX MiniPOD link generates data in the BF FPGA,
sends it out through a MiniPOD transmitter, receives it with
a MiniPOD receiver and checks the received data in the TP
FPGA.  This test operates all 12 channels in a MiniPOD at
6.4 Gbps.  The power consumption numbers that I have are:

 - the measured quiescent power draw of a CMX with the
   TP FPGA installed is about  22.4 Watts

 - the estimated quiescent power draw of a standard CMX
   card without the TP FPGA is about  19 or 20 Watts.

 - the measured power draw of a CMX card with a TP FPGA
   while running the GTX MiniPOD link test is about
   36.8 Watts

Two CMX cards  (one with the TP FPGA and one "standard" card
without a TP FPGA)  have been operated in a crate in USA15.
Perhaps there is monitoring data available from that crate's
power supply that would show how it was getting along when
these CMX cards were installed.




2) Have you tested all MGTs together, maybe with all the
   cable drivers running too.


I too would like to see all 24 GTX MiniPOD transmitter
channels operating at once  and  all 36 GTX MiniPOD
receiver channels doing the same.  L1Calo does not own
this functionality until we have proven that it works.

I believe that there was a firmware issue trying to put in
an IBERT core that operates all of the GTX transceiver
channels at once.  I need to ask Wojtek and Pawel about this.
On the CMX project I'm are not involved with the firmware.

As your question hints, the Xilinx GTX documentation gives
some warnings about heavy use of the FPGA's Select I/O in
parallel with use of its GTX transceivers.  The CMX Physics
application includes relatively heavy use of potentially
noise generating Select I/O output lines,  e.g. the
simultaneous switching of the 66 BF FPGA outputs for the
CTP signals.  We have discussed the wisdom of setting the
speed and drive level of these BF FPGA outputs no higher
than necessary.  Other applications of the CMX will include
BF FPGA output pins in operation driving signals to the
backplane LVDS cable transceivers.

Another area of concern with the operation of the BF FPGA is
that simultaneously switching outputs on this part will make
enough ground noise to interfere with its reception of the
400 single ended backplane processor signals.  From
measurements and simulation we know that the valid sampling
window for these signals is small and that they are not
spending much time at guaranteed valid logic levels.  Noise
in the BF FPGA's ground or VCCO structures reduces the valid
sampling window of the backplane processor signals.  The BF
FPGA firmware that is used to test and characterize the
receptions of the backplane processor signals includes
sending junk data out the CTP driver pins just to generate
the same type of noise environment that we know will exist
when the real Physics Trigger firmware is in operation.