Hub FPGA Signal Types -------------------------- Initial Rev. 28-Nov-2016 Current Rev. 16-Jan-2017 For each signal "type" that connects to the Hub's FPGA this file provides: - A short description of the function of that signal type. - A description of how the I/O Block that handles that signal type should be setup. - A description of the FPGA logic that is necessary to properly handle that signal type in a minimal safe Hub firmware implementation. - Where applicable a reference is given to the Hub Circuit Diagram(s) where that signal type is shown so that you can see how it is used on the Hub circuit board. Select I/O Signals: ------------------- Clock and Clock Management Signals: This sections lists the various Select I/O clock signals and clock management signals in the Hub design. See Hub Circuit Diagrams: 39, 40A, 40B, and 41. CLOCK_25_MHz_FPGA This is a single ended clock input to the FPGA. This clock is used in the Ethernet circuits. This is not an LHC locked clock. This is a 3.3V CMOS clock signal that is always running. The FPGA needs to always provide a 3.3V CMOS receiver for it. No special internal FPGA termination should be necessary to correctly receive this clock signal. Logic_Clk_320.64_MHz_to_FPGA_ Dir/Cmp Logic_Clk_40.08_MHz_to_FPGA_ Dir/Cmp These are the main Logic Clock signals for the Hub FPGA. These are AC coupled LHC locked clocks. The FPGA must receive them as differential signals, 100 Ohm terminate them, and DC Bias these FPGA inputs by including the proper combination of DQS_Bias and EQ_Level0 attributes in the setup of these I/O Blocks. Even if these clocks are not used in a minimal safe FPGA design they must still be properly received. Ref_40.08_MHz_from_Other_Hub_ Dir/Cmp This is an AC coupled LVDS input to the Hub FPGA. In a shelf with two Hub Modules this clock path is used on the Hub that does not receive an Optical Felix TTC signal. Because this is AC coupled the I/O Block that receives this signal must be setup with the correct combination of the DQS_Bias and EQ_Level0 attributes. This FPGA input should include a 100 Ohm differential terminator. This input needs to be setup and instantiated in all versions of the Hub FPGA firmware. Ref_40.08_MHz_from_FPGA_to_Rec_ Dir/Cmp This is an LVDS output from the Hub FPGA that runs to an LVDS receiver and then connects to the reference input on the 40.08 MHz PLL. I believe that we should include this output even in a minimal safe FPGA design even if we only tie the input to the LVDS driver Low. PLL_40.08_MHz_Lock_Detect_to_FPGA PLL_320.64_MHz_Lock_Detect_to_FPGA These are two Lock Detect signals from the PLL Clock circuits on the Hub Module. When Hi they indicate that the associated PLL has locked onto its reference input. The FPGA needs to always provide 1.8V CMOS receivers for these two signals. Select_Input_Second_40_Fanout This signal is an output from the Hub FPGA. It is used to enable or disable the Hub circuit board from sending out 40.08 MHz Reference Clocks on Zone-2 of the Backplane. Recall that in a shelf with 2 Hub Modules, that only the primary Hub that receives the Optical Felix TTC signal will send out its 40.08 MHz Reference Clocks to the FEX modules. The secondary Hub (the Hub that does not receive an Optical Felix TTC signal) must not send out its Zone-2 Reference Clocks. This is a 1.8V CMOS open-drain output from the Hub Module. When Low it enables the Hub Module to send out its Zone-2 Reference Clocks. When the open-drain output transistor in the FPGA I/O Block is Off then its backplane Reference Clock output drives will be shutdown. In a minimal safe design I think that we want this open-drain output to pull this signal Low so that we can see these Reference Clock outputs. SPARE_OSC_TO_FPGA_ Dir/Cmp This is a spare differential clock input to the Hub FPGA. As long as we are not installing this part (U562) then nothing special needs to be done with these input pins to the FPGA even in a minimal safe FW design. Ethernet Switch Chip Management Signals: Each of the 3 Broadcom Ethernet Switch chips has its own set of 4 management signals with the Hub FPGA. See Hub Circuit Diagram 17. FPGA_SW_?_ATC_LOOP_DET This is a control signal from the Hub FPGA to the Ethernet Switch chips. I assume that this signal will eventually be controlled from a bit in an IPBus visible register. A minimal Hub FPGA design could just tie this signal Low. A Slow Slew and 4 mA Drive level is fine for this 3.3V CMOS static level output signal. FPGA_SW_?_LOOP_DETECTED This is a status signal from the Broadcom Switch chips to the Hub FPGA. I assume that this status bit will eventually be visible in an IPBus register. The FPGA needs to at least always provide a receiver for this 3.3V CMOS input signal. FPGA_SW_?_MDC Because the MDC/MDIO interface on the Broadcom Switch chips is in Slave mode, this clock signal runs from the Hub FPGA to the Switch chip. Eventually I assume that these pins on the Hub FPGA will be controlled by firmware that implements the MDC/MDIO part of a MAC. For minimal safe firmware this line could just be driven Low by a Slow Slew 4 mA 3.3V CMOS output driver. FPGA_SW_?_MDIO This is a bi-directional data line between the Hub FPGA and the MDC/MDIO interface in the Broadcom Switch chips. Eventually I assume that these pins on the Hub FPGA will be handled by firmware that implements the MDC/MDIO part of a MAC. In a minimal safe Hub FPGA design I would provide a 3.3V CMOS receiver for this signal with a weak pull-up resistor at its input. Hardware Address Signals: ISO_SLOT_HW_ADRS_? These 8 signals bring the backplane Hardware Slot Address to the Hub FPGA. The IPMC module also receives these signals. Even if the Hub FPGA is not going to use this Hardware Slot number information it must still receive these 8 lines with 3.3V CMOS receivers. See Hub Circuit Diagram 13. SHELF_ADRS_?_TO_FPGA These are 8 signals that bring the Shelf Address information from the IPMC to the Hub's FPGA. These lines connect to "User I/O" pins on one of the ARM CPUs in the IPMC module. The Hub Firmware needs to at least always provide 3.3V CMOS receives for these signals. OVERALL_ADRS_?_TO_RES_NET These are 8 outputs from the Hub FPGA that provide an Overall Hardware Address to the ROD mezzanine. This Overall Hardware Address is made up of the Slot Hardware Address that comes from the Backplane and the Shelf Hardware Address that comes from the IPMC. In a minimal safe FPGA implementation I would just tie all 8 of these Overall Hardware Address lines Low. These can be 1.8V CMOS Slow Slew 4 mA Drive outputs. I2C Bus Signals: Hub_I2C_to_FPGA_SCL Hub_I2C_to_FPGA_SDA Note that this I2C bus makes TWO connections to the Hub FPGA. See Hub Circuit Diagram 37. It connects to pins: BE16 IO_L23P_T3U_N8_I2C_SCLK_65 BF16 IO_L23N_T3U_N9_I2C_SDA_65 that provide for a Slave I2C interface to the FPGA System Monitor, and It connects to pins: BA29 IO_L18P_T2U_N10_AD2P_67 BB29 IO_L18N_T2U_N11_AD2N_67 so that one can implement a Master I2C interface so that for example the Hub FPGA can talk to the Hub's DCDC Converter power supplies. In a minimal safe design both of these I2C signals at both pin pairs should connect to 1.8V CMOS Receivers. I2C_Buf_150?_ENABLE These are control signals from the Hub FPGA to the Sensor I2C Bus translator/buffer chips. These translator/buffer chips allow the overall Sensor I2C Bus on the ROD-Hub cards to be divided up into sections. Eventually we may need to control dividing up the Sensor I2C bus either from bits in an IPBus visible register of from a control signal from the ROD to the Hub. For a minimal safe Hub FPGA design these 3 I2C buffer control signals can just be tied Hi which will enable these I2C translator/buffers. These control signals are 3.3V Slow Slew 4 mA Drive outputs from the Hub FPGA. MiniPOD Management Signals: Each of the MiniPODs has 4 management signals associated with it. The Hub's Receiver and Transmitter MiniPODs each have their own private set of these 4 management signals. Hub Circuit Diagram 21 shows the layout of these signals. The setup of the MiniPOD management signals on the Hub is very similar to that used on the CMX card. Recvr_MiniPOD_INTR_B Trans_MiniPOD_INTR_B Interrupt signals from the MiniPODs to the FPGA. Low indicates interrupt. The FPGA should always provide 3.3V CMOS receivers for these two signals. Recvr_MiniPOD_RESET_B Trans_MiniPOD_RESET_B These are Reset signals from the FPGA to the MiniPODs. Low indicates Reset. A minimal safe design should at least drive these lines Hi with a Slow Slew 4 mA Drive 3.3V CMOS output. In a full firmware design I assume that these Reset signals will be controlled from bits in an IPBus visible register. Recvr_MiniPOD_SCL Trans_MiniPOD_SCL These are the clock signals for the bi-directional serial data path between the FPGA and the MiniPODs. In a minimal safe design I would drive this signals Low with a Slow Slew 4 mA Drive 3.3V CMOS output. Recvr_MiniPOD_SDA Trans_MiniPOD_SDA These are the bi-directional data lines for the serial data path between the FPGA and the MiniPODs. In a minimal design I would provide a 3.3V CMOS receiver for these signals. Miscellaneous Select I/O Signals: ACCESS_SIGNAL_?_FROM_FPGA These two output signals from the FPGA run to a translator/buffer chip and then to pins in the front panel J2 connector. See Hub Circuit Diagram 53. The purpose of these signals is to allow one to see with an oscilloscope some aspect of the FPGA's operation. Unless needed for something special these 1.8V CMOS output signals can be configured for a Slow Slew rate and modest 4 mA Drive. A minimal safe Hub FPGA design could just tie these 2 signals Low. HUB_FPGA_LED5?_DRV These three signals are outputs from the Hub FPGA that control front panel LEDs. These are 1.8V CMOS signals and using a Slow Slew and 4 mA of Drive would be fine. A minimal safe Hub FPGA design could just tie these 3 output signals Low. Hubs_SMB_Alert_B This is an input signal to the Hub's FPGA from the 7 DCDC Converter power supplies on the Hub Module. When Low it indicates that one or more of these Hub power supplies is in trouble (or at least wants attention). Normally this signal should be Hi. This is a 3.3V CMOS signal and the FPGA must always have a receiver for it even if it does not make use of this signal. ALL_HUB_POWER_GOOD_TO_FPGA This is an input signal to the Hub's FPGA from the Power Control circuits on the Hub Module. This is a 3.3V Select I/O signal in Bank 84. When Low this signal indicates that there is some kind of power supply problem on the Hub Module. When Hi this signal indicates: that all 7 DCDC Converters report that they are operating correctly, and that the Isolated +12V supply is Enabled, and that the output from the Linear MGT_AVAUX and BULK_2V5 supplies is good. The Hub FPGA must always instance a 3.3V CMOS receiver for this signal even if it does not make use of this signal. This signal comes through a 2.7k Ohm isolation resistor from a 5V source. MGT_FO_EQU_ENB_GRP_?? These 13 control signals are outputs from the Hub FPGA that enable or disable the equalization in the MGT Fanout chips. All fanout chips that service a given data source either have their equalization enabled or disabled. I assume that eventually these 13 equalization enable signals will be separately controllable from bits in an IPBus visible register. In a minimal safe Hub FPGA design all of the Equalization Enable signals can just be tied HI. I would drive them as 1.8V CMOS outputs with Slow Slew and 8 mA of Drive. The loading on these signals will only be about 150 uA but the high Drive level may help if we need to ramp up the FAN_1V8 rail voltage. TBD_SPARE_LINK_?_ Dir/Cmp These are 8 To Be Determined spare lines between the Hub and ROD FPGAs. Currently none of them have an assigned function. If needed they can be operated as either 8 separate 1.8V CMOS signals or as 4 separate LVDS signals. As with all CMOS signals we can not just leave them floating. As unassigned spare signals the agreement with ROD is that we will run them as 8 separate CMOS signals and that the Hub will drive them and the ROD will receive them. Further the agreement with ROD is that the Hub will keep these signals tri-stated until the ROD asserts it Power Control #2 signal HI to the Hub. See Hub Circuit Diagram 42. Even in a minimal safe firmware design the Hub needs to implement this functionality. These 8 lines should be driven with Slow Slew 4 mA Drive 1.8V CMOS output blocks. See also the hub_0_ab_non-MGT_ROD-Hub_connections.txt document. Phys_U21 and Phys_U22 signals: Each Phys Chip makes 16 connections with the Hub's FPGA. These Phys Chip <--> FPGA connections are shown in Hub Circuit Diagram 35 and make up a RGMII interface bus. In the real Hub operation these 16 signals will be managed by MAC IP firmware. This RGMII connection between the FPGA and the Phys Chips includes signals that may require fast slew rates, higher drive current, and DCI back (series) termination. These RGMII signals have been laid out carefully on the Hub circuit to minimize cross-talk, reflections, and signal loss. Careful consideration must be given to how the RMGII signals are handled in the FPGA I/O Blocks to provide both a good RGMII interface and to minimize interference with other parts of the Hub Module. For a minimal safe Hub FPGA design we still should handle these CMOS signals in a defined rational way. I would provide Low current Drive Slow Slew 1.8V CMOS outputs tied Low for the following signals: Phys_U2?_TXD0 Phys_U2?_TXD1 Phys_U2?_TXD2 Phys_U2?_TXD3 Phys_U2?_TX_EN Phys_U2?_GTX_CLK Phys_U2?_MDC I would provide 1.8V CMOS receivers for the following signals: Phys_U2?_RXD0__MODE0 Phys_U2?_RXD1__MODE1 Phys_U2?_RXD2__MODE2 Phys_U2?_RXD3__MODE3 Phys_U2?_RX_CLK__PHYAD2 Phys_U2?_RX_DV__CLK125_EN Phys_U2?_CLK125__LED_MODE Phys_U2?_MDIO Phys_U2?_INT_B ROD Present and ROD Power Control Signals: These 7 signals have to do with letting the Hub know whether or not a ROD is installed on it, Controlling (i.e. enabling) the power on the ROD, and letting the Hub know whether or not all ROD power is good and that the ROD is ready for normal trigger system operation. See Hub Circuit Diagrams 32 and 42 for more information. See the file hub_0_ab_non-MGT_ROD-Hub_connections.txt ROD_PRESENT_B_TO_FPGA This signal is a pull-down resistor on the ROD. When the ROD is NOT present this signal goes HI on the Hub. The Hub must always provide a 1.8V CMOS receiver for this signal even if it does not use it. ROD_Power_Control_2_FPGA This is an input to the Hub's FPGA. When HI this signal indicates that all power supplies on the ROD are operating correctly. The Hub must always provide a 1.8V CMOS receiver for this signal even if it does not use it. ROD_Power_Control_3_FPGA This is an input to the Hub's FPGA. When HI this signal indicates that the ROD is Configured and fully ready for normal L1Calo operation. The Hub must always provide a 1.8V CMOS receiver for this signal even if it does not use it. ROD_Power_Control_4_FPGA This is a spare power control signal. In a minimal safe firmware design the Hub should provide a 1.8V CMOS receiver for this signal with a weak pull-up resistor at its input. ROD_Power_Enable ROD_Power_Enable_B These two signal are outputs from the Hub FPGA that through some hardwired logic on the Hub tell the ROD when it may turn ON its power supplies. The hardwired logic associated with these signals is shown in Hub Circuit Diagram 32. These are 3.3V Slow Slew 4 mA Drive CMOS outputs. A minimal safe design (that just locks OFF the ROD power) should set ROD_Power_Enable Low and set ROD_Power_Enable_B Hi. FPGA_RODs_SMBALERT_B This is an input to the Hub's FPGA that when LOW indicates a power supply problem on the ROD. During normal operation this signal should always be HI. Pull up current to 1V8 is provided by a 1k Ohm resistor on page 25 of the ROD schematics. A normal 1.8V CMOS receiver should be used. The FPGA needs to always provide a receiver for this signal. MGT Transceiver Signals: ------------------------ Comb_Data_to_Cap_to_FEX_*_ Dir/Cmp Comb_Data_to_Cap_to_Other_Hub_ Dir/Cmp Comb_Data_to_Cap_to_ROD_ Dir/Cmp These 14 Combined Data signals are MGT Outputs from the FPGA. Hub Circuit Diagrams 22 and 23 indicate which of the Combined Data signals needed to be inverted in their MGT Transmitter in order to provide standard right-side-up polarity over the Backplane and at the Receiver. This_Hubs_RO_?_to_Cap_Its_ROD_ Dir/Cmp This_Hubs_RO_?_to_Cap_Other_ROD_ Dir/Cmp These 4 MGT outputs are the readout data from the Hub FPGA. One of these links goes to the ROD on This Hub (where it can only receive the Lane 0 signal) and the second pair goes to the MGT Fanout on the Other Hub from which it is routed to both the Other Hub's FPGA and to the Other Hub's ROD. Hub Circuit Diagrams 22 and 23 indicate the MGT Transmitter logic inversions that should be included in the firmware setup. MiniPOD_Trans_Fiber_??_Data_ Dir/Cmp These are 8 MGT Transmitter outputs that run to the Transmitter MiniPOD. Hub Circuit Diagram 23 indicates which of these MGT Transmitters needs to include a logic inversion so that all 8 of these Transmitter MiniPOD fibers provide a right-side-up light signal. Rec_MP_Fiber_?_to_FPGA_ Dir/Cmp These 4 MGT inputs come from the Receiver MiniPOD. Hub Circuit Diagrams 22 and 23 indicate which of these links need to be inverted in the MGT receiver in order to compensate in a polarity flip in the trace routing. MGT_FO_CH_??_OUT_Hub_ Dir/Cmp These are the 74 MGT inputs to the Hub FPGA that carry the FEX readout data and the readout data from the Other Hub. Hub Circuit Diagrams 22 and 23 indicate which of these MGT Receivers need to invert their input signal. These 74 signals are specified by their MGT_Fanout_Channel number. Combined_Data_from_OTHER_Hub_ Dir/Cmp This signal is an MGT Input to the Hub FPGA. As indicated in Hub Circuit Diagram 22 the MGT receiver for this signal needs to invert it to compensate for the polarity flip in the Hub circuit board traces. This_RODs_Readout_Ctrl_to_GTH_Input_ Dir/Cmp This is the MGT input for the Readout Control data from the ROD on This Hub. Hub Circuit Diagram 23 indicates that this MGT Receiver should be setup to provide a logic inversion to properly receive this data. Note that this high bandwidth link from the ROD to the Hub FPGA was provided so that if the ROD ever needs to send a lot Readout Control information to the FEX data sources that we can provide such a data path (i.e. to match the bandwidth of the Combined Data links to the FEX cards). On the other hand if the ROD only needs to send one bit On/Off Readout Control to the Hub FPGA then one of the ROD-Hub TBD spare links could be used to transport that simple type of Readout Control. MHz_320.64_COPY_?_ Dir/Cmp These 8 clocks are the MGT Reference clock inputs to the Hub FPGA. They have been spread through out the 20 MGT Quads so that no MGT Transceiver needs to go further than the adjacent Quad to get its reference clock signal. These are AC coupled LHC locked clock signals. All clock polarities have been kept right-side-up to keep clock duty factor uncertainty from turning into clock jitter. See Hub Circuit Diagram 41.