The Control FPGA receives data from two DataIO FPGAs, has L1 input and SVT/XTRP input, TS interface connections, SVT output, and two SLINK ports to P3, one spare bus to P3 as well. It also has the VME and CDFCtrl interfaces. Note there is no SRAM attached to this FPGA due to the lack of additional IO pins. Each bus in the schematics are breifly described below:
L1_IN_OUT(68:0) is the bus for L1 trigger input and output. The data bus is 64 bits which are mapped onto L1_IN_OUT(63:0). L1_IN_OUT(65:64) are the buffer bits, and L1_IN_OUT(67:66) are the data strobes. L1_IN_OUT(68) is the enable bit controlled (only) by Control FPGA to enable the input or the output since the L1 trigger input and output share the same FPGA IO pins. Control FPGA can drive L1 trigger data out by enabling the output and disable the input. Note that the L1 input connection signal map follows Fred signal definition, while the L1 output connection signal map follows PreFred signal definition (historic reasons). To drive L1 data out for Fred, one should take care of the signal map difference in firmware as they are different. For details, see L1 input and output connection schematics.
SVT_IN(22:0), SVT_Status(4:0) and SVT_Ctrl(3:0) are for SVT input FIFOs. The implementation follows that of SVT. 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 the Control FPGA.
CKM(7:0) is a bus connected to all three FPGAs, can be used for optional internal communication (from Control FPGA to DataIO FPGA). They are not used in firmware right now.
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 ...).
TS_IN(11:0) and TS_OUT(11:0) are used for TS interface. Note these connections are not essential in the teststand case (although one could in principle use the input and output as a "pass-through" for L2-TS cable from alpha to TS crate. this way, Pulsar could "spy" the handshake between alpha and TS). The other reason these connections are here was: just in case we may use Pulsar as a prototype (candidate) for a possible L2 upgrade for Run2b in the future, and it's easy to implement.
S0_spare(24:0) is the spare bus to P3. This can be used, for example, to bring one SVT input from AUX card (without external FIFO) or can be any user defined signals to/from AUX card.
SVT_OUT(22:0) and SVT_Out_DS,SVT_OUT_Hold are for SVT output.
Pulsar_ID(5:0) are are used for Pulsar_ID. 6 bits dip switch is used to set the ID for each Pulsar board. This implementation follows the general CDF board requirement.
Two HP LA connectors are used for debug lines: DebugA(15:0) and DebugB(15:0).
CDFCtrl(53:3) are CDF control signals from P2 backplane. Not all the signals on the bus are made visible to Control FPGA as it doesn't need all of them (for example, CDF_EVID bits, CDF_CALIB bits are not used on Control FPGA, but are available to DataIO FPGAs just in case someone wants them). Control FPGA has the capability to drive the Pulsar inter-communication lines (Pulsar_init, error, freezze, lostlock and spare), while both Control FPGA and DataIO FPGA can listen to these lines (one exception:DataIO FPGA doesn't see Pulsar_spare). 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.
All other clocks (SRAM clock, SVT FIFO read clock) are driven directly
from Control FPGA (which can be a copy of Roboclock, the algorithm clock).
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 DataIO FPGAs the output buses will stay close to the side facing P3 ... etc. The same has been done for many other signals etc. more details here.
Last updated on $Date: 2002/05/17 3:08:10 $ (UTC)