Pulsar DataIO FPGA schematics description

Overall description

Two DataIO FPGAs are used to interface with 4 mezzanine cards, L1 input and SVT/XTRP input. The schematics for the two FPGAs are identical (but firmware could be different). VME and CDF control signals are also visible to these FPGAs. One bit FPGA_ID is used to tell the difference between the two (e.g. via VME access). The first DataIO FPGA has FPGA_ID set to 0 (at top level) , while the 2rd one has FPGA_ID set to 1 (see top level schematics). Each bus in the schematics are breifly described below:

Input Data Buses

F1inout(45:0) is from J1 mezzanine card connector. There are 32 data bits (F1data0 to F1data31), and 14 control signals. The name convention for the control signals follow that of SLINK input (from LDC card). Some of them can be also used for custom mezzanine cards in case custom mezzanine cards are plugged in (see mezzanine card connector schematics). The 32-bit data bus will be also used as data bus for custom mezzanine card cases. FCtrl1(32:0) bus contains all the necessary control signals from custom mezzanine card (from J3 connector). This control bus (or J3) is not used for SLINK case. The control signals are defined in such a way that the directions (input or output) are about the same (except for a few optional signals) in both Tx and Rx case. This way, the only direction change will be the 32-bit data bus for Tx and Rx. F2inout(45:0) and FCtrl2(32:0) are the same but from the other mezzanine card connection. Note that each J3 has one FPGAWRclk (used to write or read data to/from custom mezzanine cards in case FIFOs are implemented on the mezzanine cards). It is driven directly from the DataIO FPGA (We may need a buffer for this clock?) Please note that the mezzanine card connection (J1 and J3) signals are user defined. The names on the schematics follow that of SLINK signals for J1, and for J3, the names are from the first hotlink Tx/Rx mezzanine card prototype in which FIFOs (FPGAs) are implemented. If the custom mezzanine card does not have FIFO (or FPGAs), then only a few signals are needed and the signals can be re-defined inside DataIO FPGAs.

CARD1_ID(3:0) and CARD2_ID(3:0) are from two mezzanine cards. DataIO FPGA will use the ID information to determine what type of mezzanine card is plugged in, and to make sure that the firmware is compatible with the mezzanine card type (i.e. input or output). At power up, all data bus to mezzanine card should be tri-stated, and mezzanine card detection unit will first check the CARD_ID and if it is the right type for this firmware, the "gate" can be closed. Otherwise, if wrong type mezzanine card is detected, an error LED will be lit. The CARD_ID should be latched into a register which can be accessed via VME.

L1_IN(68:0) is the bus for L1 trigger input. The data bus is 64 bits which are mapped onto L1_IN(63:0). L1_IN(65:64) are the buffer bits, and L1_IN(67:66) are the data strobes. L1_IN(68) is the enable bit controlled (only) by Control FPGA to select input or output since the L1 trigger input and output share the same FPGA IO pins. For dataIO FPGA, it only receives L1 trigger data, and can check the enable bit (as input) from control FPGA to make sure it is input. (note: Control FPGA can drive L1 trigger data out by enabling the output and disable the input).

SVT_IN(22:0), SVT_Status(4:0) and SVT_Ctrl(3:0) are all for SVT input FIFOs. The implementation follows that of SVT. Since there are three main FPGAs, the SVT input will go to three independent set of FIFOs, this way each FPGA can read the data from its own SVT input FIFO independently (for details, see SVT input block). The FIFO read clock is directly driven by each FPGA.

CKM(7:0) is a bus connected to all three FPGAs, can be used for internal communication. not used in the firmware at this point. They can be defined as inputs for DataIO FPGAs, and output for Control FPGAs, for example.

VmeJtagNext(3:0) and VmeJtagPrev(3:0) are used (as an option) for configuring the FPGAs via VME. This is from GhostBuster design and we need to look into the details on how to use it (has not been tested on GhostBuster board yet...).

FPGA_ID is set at top level to identify the two DataIO FPGAs.

Output Data Buses

Vti(38:0) bus is the output (for example in SLINK format, but doesn't have to be) to Control FPGA. The name convention for control signals follows that of SLINK. There are 32 data bus (UD_output0 to UD_output31) and a few control lines. Although there is a data clock (UCLK) to Control FPGA from DataIO FPGA, the control FPGA can simply use its own clock (which is the same algorithm clock) to latch the data in. Therefore, the UCLK will not be used as data clock and it can be used as internal communication line (from DataIO to Control) together with two ctrlspare lines.

Debug(15:0) goes to a HP LA connector. 2 additional lines for clocks.

Control Buses

VmeData(31:0), VmeAddr(23:2) and CDFCtrl(2:0) are all used for VME access to this FPGA.

CDFCtrl(53:3) are CDF control signals from P2 backplane. Not all the signals are made visible to DataIO FPGA, but most of them are. The ones not made visible to DataIO FPGA are made availble to Control FPGA. This way, all the P2 CDF control signals shown in the CDFCtrl(53:3) bus are available to Pulsar (either to DataIO FPGA, or to Control FPGA, or both). For details, check the VHDL code. (one example here). CDFCLK_VOID from this bus is not used, rather a buffered version of CDFCLK is used (see CDFclkBus(2:0) which is from clock block).

SRAM interface. There is one SRAM(cy7c1350-100) attached to each DataIO FPGA (put data sheet here). There are 66 IO pins used for this SRAM (data, address, and control). The clock to SRAM is directly driven by the DataIOFPGA.

LEDs controlled by DataIO FPGA

There are three user-defined LEDs for each DataIO FPGA. The meaning for each is user defined. One possible way to assign the meaning of LEDs is: use one for data IO activity from mezzanine card one, the other for mezzanine card two. while the third one can be used for other case such as mezzanine card ID detection. This definition could be (at least) useful during prototype debugging/test.

Clock Distribution

CDFclkBus(2:0): CDFCLK goes into DataIO FPGA (dedicated input), CDF_clkA goes to mezzanine card J3 (see FCtrl1(32:0) bus), CDF_clkB goes to the other mezzanine card J3 (see FCtrl2(32:0) bus).

Roboclock is the algorithm clock for DataIO FPGA (dedicated clock pin), SLINK40MhzClk (dedicated clock pin) is an optional clock which can be potentially used to drive LSC card from DataIO FPGA.

All other clocks (SRAM clock, mezzanine card J3 read/write clock, SVT FIFO read clock) are driven from DataIO FPGA (which can be a copy of Robclock, the algorithm clock).

FPGA IO pin assignment issues

The IO pin assignment for this FPGA can be found in DataIO FPGA pin file from QuartusII. There are two clock pins for 20K400BC652 FPGA, one with PLL (U2) and the other (W34) without. Roboclock is assigned to the one (U2) with PLL (although PLL is not used in firmware right now), SLINK40Mhzclk is assigned to the other (W34) dedicated clock pin. There are 4 dedicated input pins AP17, AP19, B17 and B19. CDFCLK is assigned to AP17, CDFRECOVER is assigned to AP19, SLINK input 1 LCLK is assigned to B17, SLINK input 2 LCLK is assigned to B19. Note that these special pin assignment is done automatically by QuartusII compiler with core fimware VHDL code. The assignment is as expected. In addition, since the SLINK input LCLK is assigned to dedicated input pin, we cannot use this pin to drive the UCLK in case we need to use DataIO FPGA to drive SLINK LSC card. For this reason, there is one UCLK pin assigned to this FPGA and is tied to LCLK. To drive LSC card, the clock will be driven from UCLK pin to the LSC card, and the data will be clocked out by LCLK (clock feedback from UCLK to LCLK as they are tied together). In all other cases, the UCLK pin should be defined as input in firmware (and ignored). An alternative way to do this is to use a jumper to select an external SLINK clock for UCLK to drive LSC... we choose not to use jumper here.

There are many other signals (out of 502 user pins) are assigned BY HAND. This is to make routing easier. For example, the input bus will stay close to the side facing the mezzanine card connectors, the output bus will stay close to the side facing Control FPGA... etc. The same has been done for SRAM signals, debug signals etc. more details here.

Last updated on $Date: 2002/05/15 3:08:10 $ (UTC)