CMX OCB On-Card-Bus ------------------------- Original Rev. 31-Oct-2012 Current Rev. 30-Apr-2014 This file describes the CMX circuit board's On-Card-Bus and its connection to the VME-- backplane bus. The CMX card is a slave only, A24D16 only device on the VME-- bus. In this document I will refer to the L1Calo VME-- bus just as "VME". The OCB connects to 5 objects on the CMX card: ---------------------------------------------- - It connects to the VME backplane receiver and driver chips - to the VME/OCB Bus Management function in the Board Support FPGA - to registers and/or memory in the Board Support FPGA - to registers and/or memory in the Base Function FPGA - to registers and/or memory in the Topological Processor FPGA Circuit Diagrams: ----------------- Please refer to the following circuit diagrams which illustrate the OCB bus and its connection to the VME backplane bus: 08_on_card_bus_and_vme_interface.pdf 20_vme_ocb_management.pdf 25_bspt_management_of_vme_ocb.pdf An overall drawing of the Hardwired Oversight Logic, including its oversight of the OCB/VME, is shown in the following: 24_hardwired_oversight_logic.pdf Signals in the On-Card-Bus: --------------------------- - OCB_D15:OCB_D00 16 Data Bus lines, bi-directional, 2.5V - OCB_A23:OCB_A01 23 Address lines, always driven from the VME end, 2.5V - OCB_DS_B Data_Strobe_B, always driven by VME end, 2.5V - OCB_WRITE_B Write_B data bus Direction, always driven by the VME end, 2.5V - OCB_SYS_RESET_B System_Reset_B, always driven by the VME end, 2.5V - OCB_GEO_ADRS_6:OCB_GEO_ADRS_0 Geographic Address lines, always driven by the VME end, 2.5V, 0,4,5,6 come from the backplane, 1,2,3 come from jumpers on the CMX - Note that only the VME/OCB management function in the BSPT_FPGA controls the DTACK_B signal to the VME backplane bus. FPGA Connections to the On-Card-Bus: ------------------------------------ - All FPGA connections to the On-Card-Bus are via 2.5 Volt I/O Banks on the BSPT, BF, and TP FPGAs. - The BSPT, BF, and TP all connect to the On-Card_Bus so that their internal registers and/or memory structures will be "visible" on the VME backplane. - Logically the BSPT makes a second separate connection to the On-Card_Bus to provide certain bus management functions. Inside the BSPT FPGA there are two separate sections related to the OCB: a section for normal VME register and/or memory access and a section for the VME/OCB bus management. Bus Management: --------------- The OCB is managed by a small set of logic in the Board Support FPGA. This OCB management consists of the following: - The BSPT_FPGA recognizes when a VME cycle has been started for which this CMX card is the addressed target. The BSPT_FPGA knows its VME address range based on the Geographic Address of the crate and of the slot that this CMX card finds itself in. A fixed delay after the start of a VME cycle targeting this CMX card the BSPT will assert the DTACK_B signal to the VME bus. The BSPT will then manage the "tear down" of this VME cycle, i.e. when the master releases the DS_B signal the BSPT bus management function will release this card's DTACK_B signal. - The BSPT_FPGA manages both the Direction of and the Output Enable of the level translators and the data bus transceivers that connect the OCB Data Bus to the VME backplane. During a VME Read cycle that addresses this CMX card the data bus translators and transceivers drive data to the VME bus with their outputs enabled During a VME Write cycle that addresses this CMX card the data bus transceivers and translators drive data to the OCB with their outputs enabled When no cycle is taking place or when there is a cycle taking place that does not address this CMX card the data bus transceivers and translators are in the direction to send data to the OCB with their outputs disabled. Note that in this condition the keepers on the 2.5V to 3.3V translators will maintain valid CMOS logic levels both on the OCB data lines and on the transceiver pins. - The VME Address lines are received from the backplane bus by 74LVC16373A chips. These parts include both a receiver and a transparent latch. If desired, the OCB management function in the BSPT_FPGA can use the Latch Enable signal to these chips to hold stable the state of the OCB Address lines during cycles on the VME bus. - The CMX card includes Hardwired Oversight Logic to prevent a CMX card, under fault conditions, from hanging the the VME backplane bus and thus blocking VME communications with any card in that L1Calo crate. Specifically this Hardwired Oversight Logic verifies: that the BSPT FPGA is configured, that all CMX card power supplies are running, and that the BSPT FPGA has asserted an OK signal before this hardwired logic will allow: the CMX card's DTACK_B signal to be asserted onto the crate backplane or the Data Bus Transceivers to drive data onto the crate backplane. - NOTES: The BSPT_FPGA must be configured and running for any VME communications to take place with the CMX card. The BSPT has two separate functions wrt the OCB: It manages the VME/OCB as described above It is a device on the OCB, i.e. it may have an address range on the OCB and thus have registers or memory that is visible from the backplane VME. Because the DTACK_B signal is centrally managed, the OCB appears as a synchronous bus to all the registers and/or memories in the 3 FPGA devices that are connected to it. Reading from or writing to these registers and/or memories must take place within a fixed length of time. Physical Layout of the OCB Traces on the CMX Card: -------------------------------------------------- - If the OCB signals were all layout out on one layer in their natural order they would appear as vertical traces running down on the East side of the BSPT, BF, and TP FPGAs. In their natural order, on one layer, the signals going from West to East are: GA1:GA3, D00:D15, A23:A17, DS_B, Write_B, Reset_B, GA0, GA4:GA6, A16:A01 OCB to Backplane VME Connection Details: ------------------------------------------- - The OCB connects to the VME backplane bus via level translator chips followed by bus transceiver or receiver chips. - The 2.5V logic level of the OCB is converted to the 3.3V level required by the bus transceiver and receivers using 74AVCAH164245 level translators. This is the same level translators that is used on other parts of the CMX card. - The bus data transceiver chip is a 74LVT16245B. The bus receiver chips are 74LVC16373As. - The DTACK_B line is driven by two sections of a 74LVC38A open drain chip. Details of the Anticipated OCB/VME Management Firmware: ------------------------------------------------------- - As on the CMM card, the registers and memories on the CMX are expected to access and provide read cycle data or absorb write cycle data within a fixed amount of time after the VME Master asserts DS_B. I.E. the asynchronous nature of a real VME Bus is dispensed with on the OCB. - The VME/OCB management provided by the BSPT will "sync up" the OCB to its 40.08 MHz clock. In this way the registers and memories in the 3 FPGAs that are connected to the OCB do not have to individually worry about OCB cycles at random phases in their clock. - The OCB cycle starts when the BSPT OCB management firmware detects and confirms that the DS_B signal has gone to its low asserted state and sees that the address lines OCB_A(23:1) indicate an address within the range of this CMX card. - The VME/OCB management provided by the BSPT detects whether or not a given VME cycle is targeting its CMX card. It generates an internal "this_cycle_is_for_me" signal that is used to enable various control functions. The inputs to the decoder that generates the "this_cycle_ is_for_me" signal include the 23 OCB Address lines and the 7 Geographic Address lines. 4 of the Geo Adrs signals come from the backplane and the other 3 are set by jumpers on the CMX card. The output of the decoder logic that generates the "this_cycle_is_for_me" signal should passed through a D flip-flop that is clocked only after the OCB Address lines are stable and the decoder has had time to settle. The intent of this precaution is to eliminate the chance that natural skew in the decoder or in its inputs will falsely trigger a CMX card into responding to a cycle that does not target it. The internal "this_cycle_is_for_me" signal must be terminated as soon as OCB_DS_B returns HI or anytime that the OCB_SYS_RESET_B signal is asserted. - The internal "this_cycle_is_for_me" signal is used to control the the Enabling of the VME/OCB Data Bus transceiver and level translator. Note that the enable signal from the BSPT to the Data Bus transceivers is protected by Hardwired Oversight Logic. CMX has the normal standard requirement of holding valid CMOS signal levels on its OCB Data Bus between VME cycles that target it. This is taken care of by the level "keepers" that are built into the 74AVCAH164245 level translator chips. This simplifies the logic that controls the Direction and Enable signals to these translators. - The internal "this_cycle_is_for_me" signal along with the OCB_WRITE_B signal are used to control the the Direction of the VME/OCB Data Bus transceiver and level translator. - The internal "this_cycle_is_for_me" signal along with the OCB_DS_B signal are used to control the DTACK_B signal that is generated by the CMX card. CMX asserts DTACK_B a fixed number of 40.08 MHz clock cycles after the bus management logic has detected (and confirmed) the falling edge of OCB_DS_B for a VME cycle that is targeting this card. CMX releases DTACK_B as soon as OCB_DS_B returns HI or anytime that the OCB_SYS_RESET_B signal is asserted. Note that the CMX card includes Hardwired Oversight Logic to control when it is allowed to assert its DTACK_B signal. - The VME Reset_B signal, when asserted, should immediately stop all VME/OCB bus activity on a CMX card. When Reset_B is asserted it must clear the internal "this_cycle_is_for_me" signal (thus getting the CMX card off of the VME Data Bus and it must stop asserting DTACK_B if it is doing so. - Note that the CMX card includes Hardwired Oversight Logic to prevent it from "hanging" the VME backplane bus in a L1Calo crate in the event that there is a failure in an on-board power supply or in the event that the BSPT FPGA looses its configuration (or has not yet been configured). This Hardwired Oversight Logic prevents a CMX card from asserting its DTACK_B signal and from sending data onto the VME Bus until: all power supplies on the CMX card are running normally, the BSPT Configuration Done signal is asserted, the BSPT has asserted its "Running OK" signal and jumper JMP59 has been installed on the card. This Hardwired Oversight Logic is shown in circuit diagram 24_hardwired_oversight_logic.pdf In the lower left-hand corner you can see the protection on the CMX DTACK_B signal. Near the bottom of the right-hand column you can see the protection on enabling the VME Data Bus Drivers. - The receivers on the CMX card for the VME Address, DS_B, Write_B, and Reset_B signals are 74LVC16373 chips with transparent latches. When the "Latch Enable" signal to these chips is HI then their outputs will follow their inputs. When LE is LOW then their outputs "hold". Note that there are separate Latch Enable signals to the sections of the 74LVC16373 chips that carry the VME Address lines and to the section that carries the VME Control signals, e.g. DS_B, Write_B, and Reset_B. You can see the separate VME_ADRS_RECVR_LE and VME_CTRL_RECVR_LE signals in circuit diagram 20_vme_ocb_management.pdf Clearly the 74LVC16373 receivers for these VME Control signals must always be transparent. The BSPT generates the Latch Enable signals to all sections of the 74LVC16373 receivers but except for some kind of special testing it is assumed that the Latch Enable to the section of 74LVC16373 receivers for the VME Control signals will just be tied HI in the BSPT (HI --> transparent). List of Control Signals from the Bus Management Function in the BSPT FPGA to the Transceivers, Receivers, Drivers, and Translators that Connect the OCB to the VME Bus: --------------------------------------------------------- All signals that are described in the following table are fully defined in the following net list files: bspt_fpga_all_other_nets_n2p.txt vme_bus_interface_chips_n2p.txt hardwired_oversight_logic_n2p.txt In the following table the signals are listed in the same order as they appear in circuit diagram 20_vme_ocb_management.pdf - BSPT_RUNNING_OK_B This signal allows the BSPT to tell the Hardwired Oversight Logic that, from its point of view, everything is OK. This is a Low Active signal. BSPT should confirm that the Virtex FPGA(s) are Configured before setting this signal Low. - BSPT_SEND_VME_DTACK_B Controls sending the VME DTACK_B signal from the CMX card. This control signal passes through Hardwired Oversight Logic on its way to the DTACK_B VME driver chip. This signal should be taken LOW to request that the CMX card assert its DTACK_B VME signal. - VME_D_BUS_TRNCVR_DIR Controls the Direction of the VME Data Bus Transceiver U352. This control signal runs directly to the U352 VME Transceiver. Once the CMX is ready for VME access then this signal should be taken LOW for VME Writes and must go HI for VME Reads. This signal MUST always be in the same state as the OCB_D_BUS_TRNSLT_DIR signal. - BSPT_VME_D_BUS_TRNCVR_OE_B Controls the Output_Enable_B of the VME Data Bus Transceiver U352. This is a control signal that passes through Hardwired Oversight Logic on its way to the U352 VME Data Bus Transceiver. Once the CMX is ready for VME access then this signal should be taken LOW when this card is the target of a VME Read or Write cycle. - OCB_D_BUS_TRNSLT_DIR Controls the Direction of the OCB Data Bus Translator U355. This is a control signal that runs directly to the U355 OCB Data Bus Translator. Once the CMX is ready for VME access then this signal should be taken LOW for VME Writes and must go HI for VME Reads. This signal MUST always be in the same state as the VME_D_BUS_TRNCVR_DIR signal. - OCB_D_BUS_TRNSLT_OE_B Controls the Output_Enable_B of the OCB Data Bus Translator U355. This is a control signal that runs directly to the U355 OCB Data Bus Translator. Once the CMX is ready for VME access then this signal should be taken LOW when this card is the target of a VME Read or Write cycle. - VME_ADRS_RECVR_LE Controls the LE signal to the U354 VME Receiver and to the half of the U353 VME Receiver that is used for "Address type" information. This is a control signal that runs directly to U354 and to the Address section of the U353 Receiver. Once the CMX is ready for VME access then between VME cycles this LE signal should remain HI to keep these receivers transparent. During a VME cycle this LE signal may go LOW so that these VME Receivers will "Hold" their address information during the cycle. - VME_ADRS_AND_CTRL_RECVR_OE_B Controls the OE_B signal to all sections of both the U353 and U354 Receivers for the VME Address and Control type signals. This is a control signal that runs directly to the U353 and U354 chips. Once the CMX is ready for VME access then this signal should be taken LOW and stay continuously LOW to enable the output of these VME Receiver chips. - OCB_ADRS_AND_CTRL_TRNSLT_DIR Controls the DIR signal to all sections of both the U356 and the U357 Translators for the OCB Address and Control type signals. This is a control that runs directly to the U356 and U357 chips. Once the CMX is ready for VME access then this signal should be taken LOW and stay continuously LOW to select the B input to A output direction for these translator chips. - BSPT_OCB_ADRS_AND_CTRL_TRNSLT_OE_B Controls the OE_B signal to all sections of both the U356 and the U357 Translators for the OCB Address and Control type signals. This is a control signal that passes through Hardwired Oversight Logic before it goes to U356 and U357. Once the CMX is ready for VME access then this signal should be taken LOW and stay continuously LOW to enable these translator chip outputs. - VME_CTRL_RECVR_LE Controls the LE signal to the half of the U353 VME Receiver that handles "Control type" information. This is a control signal that runs directly to this one section of the U353 VME Receiver. Once the CMX is ready for VME access then this LE signal must continuously be held HI to keep this VME Receiver's latch transparent. Special note about the VME_ADRS_RECVR_LE, VME_CTRL_RECVR_LE and VME_ADRS_AND_CTRL_RECVR_OE_B control signals: ------------------------------------------------------------ Because I made a mistake in the orientation of the VME Receiver chips U353 and U354 during layout the control signals listed in the heading of this section are not wired to the correct pins on these chips. This mistake has the following implications: - The VME_ADRS_RECVR_LE control signal from the BSPT is actually tied to the OE_B pins on U354 and to the OE_B pin on the address half of U353. The VME_CTRL_RECVR_LE control signal from the BSPT is actually tied to the OE_B pin on the control half of U353. The VME_ADRS_AND_CTRL_RECVR_OE_B control signal from the BSPT is actually tied to all of the LE pins on U353 and U354. - One can not use the VME_ADRS_RECVR_LE signal to freeze the 24 lines of the OCB Address Bus during a VME cycle. If one wants to design the VME firmware for the CMX card so that the OCB Address Bus is frozen during a VME cycle this can still be done at the I/O Blocks that receive these lines on the FPGAs. Freezing the address bus is only necessary if one wants to pipe-line the VME cycles. - These 3 control signals are generated in the VME Management section of the BSPT firmware. In this BSPT firmware one must set these 3 control signals as follows: VME_ADRS_RECVR_LE permanently set LOW VME_CTRL_RECVR_LE permanently set LOW VME_ADRS_AND_CTRL_RECVR_OE_B permanently set HI