All JEM1 processor FPGAs will be configured via two different, independent paths. On ATLAS configuration will be done through a Xilinx SystemACE-CF configurator, consisting of an ASIC and a compact flash memory. SystemACE works via the JTAG port. During the debug phase, however, configuration download will be accomplished through the VME port. While in normal operation the VME-- bus will be fully controlled by an FPGA, there is a CPLD available to guarantee access to the module while the FPGA is unconfigured. This CPLD will allow for the configuration of the FPGAs via VME.
1) The SystemACE-CF is a complete configuration solution acting as a multi-way bridge between the external JTAG scan port, the JTAG chain through all FPGAS used for both scan and configuration, a standard compact flash memory, and the processor bus (VME). Upon power-up the ACE controller automatically configures the FPGAs. To this end it requires the flash device and some control signals that need on JEM1 be controlled via a CPLD (ie. GeoAddress...). Since it is JTAG based, the ACE controller does not access the serial or parallel configuration pins. However, the M-pins need to be set appropriately to avoid malfunction. Also the DONE and possibly PROGRAM and INIT lines need to be served (to be confirmed). The ACE controller will be located on the JEM main board so as to allow for front panel access to the flash device. It would be advantageous to have double socket footprint so that eventually on ATLAS the flash memory can be inserted in an internal slot, once the debug phase is over. The ACE controller will be controlled via the control CPLD that is located on the main board. It will have access to all VME bus signals and GEOADD. A wide port for spare signals is looped to the ROC daughter.
2) The VME-controlled configuration will be via the byte-wide configuration port on the ROC. A separate control FPGA is not required, since eventually the flash configurator will boot up automatically without any support device. The configuration port will be controlled through a CPLD. The CPLD will disable itself after successful configuration of the ROC and the control FPGA will take over the VME bus handling once it is configured. The successful configuration of the control FPGA is signalled to the CPLD through a dedicated user pin of the FPGA. This line carries an external pull-up resistor and will be connected to the GTS line of the CPLD. The CPLD has two write-only registers (or a single register with 8+1 width?) to allow for byte-wide configuration and for a configuration reset of the control FPGA. The CPLD and the FPGA should be wired such that the control FPGA is able to reset itself (might require the CPLD to stretch the reset command??) and start afresh with the CPLD taking over control. This configuration method is intended for the initial setup in the lab only to avoid frequent re-programming of the flash memory. While it is intended to completely disable the CPLD after successful configuration of the module, some functionality (RESET) might be retained if it turned out that the system is not coming up error free under certain conditions. CPLD resources permitting a de-multiplexing of 16 bit VME to two 8-bit configuration bytes is envisaged to speed up the operation. Once the ROC on all 16 JEMs is configured, a more complex buffered scheme might be used to configure the other processor FPGAs. These are configured serially. The ROC needs to control their D0, PROGRAM, INIT, M lines.
The availability of the CPLD XC2C64-7VQ100C needs to be checked *now*. This device carries 64FFs only. Since quite some FFs are required for counters ( timers) some other operations might need to be asynchronous to free the FF resources. Otherwise a larger device (minimum 128) would need to be chosen XC2C128 might be preferred anyway so as to benefit from clock division option (will require the incoming clock to be routed to two global clocks so as to have two frequencies available on the global network) (later upgrade if not available now).
System control is via the VME bus. While the processor FPGAs (input, main) are driven through separate ports of the ROC, the ROC itself, the SystemACE configurator and the CPLDs are connected to a common VME bus. On the ROC the VME bus fully overlaps with the configuration port (D7:0). It is yet to be decided whether the ACE controller will be connected to the VME bus directly or through a CPLD based bridge.
Since several devices are assumed to control the internal VME bus, DTACK (active-low) needs to be open-drain driven with a pull-up resistor (check whether a pull-down with drivers pulling high would be an option). The signals could all be actively driven tri-state with the pull-up/down resistor being rather high impedance and used only to keep the signal while switching over from device to device (consider the use of weak keeper).
VME CPLD I/O use:
On the VME CPLD the 40MHz crystal clock will run into a global clock buffer. If the decision will be taken to use the same CPLD for SystemACE, a 2nd crystal oscillator (33MHz) will be tracked to a 2nd global clock buffer. GSR will be tracked to the VME reset line (can outputs be connected to GSR ? we need to route the signals to the processors as well (but probably not while the CPLD is active)). GTS will be routed to the ROC_configured output of the ROC.
References:
SystemACE http://direct.xilinx.com/bvdocs/publications/ds080.pdf
CPLDs Coolrunner
at Xilinx
The DCS circuitry is located partially on the main board, partially on the ROC daughter.
All MAX1668 are bussed and allocated different addresses, see above. ALERT is wire-ORred. ALERT and SMBDATA require pull-up!
Decide whether the micro controller resides on main board or ROC. If located on main board, TXD and RXD should be fed to spare connector pins un the ROC daughter for future use. Also feed the two CPM G-Link sense lines to the ROC
Supply voltages sensed:
References:
http://www.ep.ph.bham.ac.uk/user/staley/schematics/sheet28.pdf
http://pdfserv.maxim-ic.com/arpdf/MAX1668-MAX1989.pdf
http://www.semiconductors.philips.com/cgi-bin/pldb/pip/pca82c250.html
Due to the relocation of CAN and configuration to the main board, the ROC daughter is simplified. It carries ROC chip, TTCdec, G-links and a CPLD only. So as to reduce the required ROC pin count, the parallel VME address can be level-shifted by the CPLD located on the ROC (large Coolrunner) and distributed to the processor FPGAs (single output to multiple destinations). While we adhere strictly to point-to-point connections on the main board, the ROC daughter is not required to do so (easily replaced if buggy).
JTAG: the various JTAG chains will be joined on the front panel D-Sub connector with help of a jumper connector. JTAG access from VME (CAN?) via CPLD or FPGA should be made available so as to update the CPLDs via JDRIVE software in situ. (is Coolrunner ispable on the fly?)