1. Samuel Silverstein Stockholm University CMM++ firmware development Backplane formats (update) CMM++ firmware

2. 2 Questions:  How much work to produce initial firmware for the CMM++?  Can a "Day-1" compatible CMM++ be implemented in the target Virtex-6?  Implications for CMM++ hardware? Idea: Adapt "Day-1" Jet CMM f/w to Virtex-6  Existing VHDL with minimal changes  Same development environment (Mentor/ISE)  Set realistic user constraints (UCF)

3. 33 CMM++ concept (Yuri) Glink Legacy DAQ and ROI readout SNAP12 12-fiber bundles, 6.4/10 Gbit/s/fiber Tx and/or Rx Legacy LVDS outputs to CTP Virtex 6 HX565T Input from JEM/CPM Input from JEM/CPM modules (160 MHz) LVDS merger links SNAP12 VME-- Not a complete picture!

4. 44 The current CMM Glink DAQ and ROI readout LVDS outputs to CTP Virtex E (system) Input from JEM/CPM Input from JEM/CPM modules (40 MHz) LVDS merger links VME-- Virtex E (crate) VME CPLD TTCrx

5. 55 "Day-1" firmware, first try: Glink DAQ and ROI readout LVDS outputs to CTP Virtex E (system) Input from JEM/CPM Input from JEM/CPM modules (40 MHz) LVDS merger links VME-- Virtex E (crate) VME CPLD TTCrx Implement in Virtex 6 (XC6VHX565T-2FF1924) from existing VHDL

6. 6 Firmware is easy to port Top-level VHDL design, containing both crate and system FPGAs plus interconnects (done) Most of code pure VHDL, ports transparently Two architecture-specific changes  Block RAMs 4k  18k or 36k (Done 1  1)  Clocking: DLLs  MMCM  Advanced mixed-mode clock manager (Done)  Note: UNISIM libraries for Mentor compatibility

7. 7 Results from first attempt Note: numbers come from Precision, not ISE  Take as an early, rough estimate Plenty of resources left in FPGA  Logic slices: about 2% used  Registers: about 2% used  Block RAM: about 5%  Can be reduced by at least 1/2 by more efficient use of 18kb and 36 kb memories. Significantly faster than Virtex-E  Max. frequency more than 120 MHz without trying  Can save several ticks of latency I/O requirements very close to limit...

8. 8 I/O budget for V6HXT565 Available I/O (not including transceivers): 640 pins Real-time data path:  Backplane input (16 x 25): 400  Cables (3 x 25):+75  CTP output (2 x 33): +66 = 541 pins Control and timing:  VME-- from CPLD35  TTC (L1A, BCR, deskew 1 and 2)+4  Crystal clock+1  clr_pe,rst,rst_dll,pbk_en,can_mc,en_cblout +6 = 46 pins Readout:  Glink data outputs 2 x 2040  DAV pins 2 = 42 pins Indicator LEDs : 8 + 8 pins TOTAL: 637 / 640 637  This is after removing spare TTL and test ports.

9. 9 637/640 is too many I/O banks include multi- function pins:  VREF  Global clock inputs So we can't use all of the pins just for I/O

10. 10 Can we save I/O? Available I/O (not including transceivers): 640 pins Real-time data path:  Backplane input (16 x 25): 400  Cables (3 x 25):+75  CTP output (2 x 33): +66 = 541 pins Control and timing:  VME-- from CPLD35  TTC (L1A, BCR, deskew 1 and 2)+4  Crystal clock+1  clr_pe,rst,rst_dll,pbk_en,can_mc,en_cblout +6 = 46 pins Readout:  Glink data outputs 2 x 2040  DAV pins 2 = 42 pins Indicator LEDs : 8 + 8 pins TOTAL: 637 / 640 637.  <600 Move to FPGA from CPLD Implement Glink in Virtex 6?

11. 11 Glink in Virtex 6: Glink emulation already done in other FPGAs  Altera provided code for Stratix GL  Has been ported to Xilinx FPGAs  Virtex 4, Virtex 5 L1Muon collaborators at INFN most recently ported to Virtex 5, with both simple and enhanced modes  Shared code, documentation to me  Seems straightforward to adapt to Virtex 6

12. 12 "Day-1" firmware, next try: Glink DAQ and ROI readout LVDS outputs to CTP Virtex E (system) Input from JEM/CPM Input from JEM/CPM modules (40 MHz) LVDS merger links VME-- Virtex E (crate) VME CPLD TTCrx

13. 13 Next steps... Add Glink functionality in two GTX tx Produce "realistic" user constraint file (UCF)  All I/Os arranged in appropriate banks  Correct signal levels for backplane, cables, CTP, etc...  Differential global clock inputs  etc... Implement in ISE to check actual resource use, clock speed Simulate to verify correct behavior

14. 14 Looking even further ("stage 2") Add block for receiving and distributing 160 MHz backplane signals Add multi-Gbit tranceivers to serialize and send out backplane data over fibers Do similar for non-system-merging CMM++

15. 15 CMM++ "stage 2" Glink SNAP12 to CTP Input from JEM/CPM Input from JEM/CPM modules (160 MHz) LVDS merger links VME-- INPUTINPUT CrateSYS 8b/10b ser

16. 16 Backplane formats P1P2P3P4P5P6P7P8 Threshold bits ROI 1 (8b)Threshold bits ROI 2 (8b) Fine Pos ROI 1 Fine Pos ROI 2 Fine pos ROI 3 Fine Pos ROI 4 Threshold bits ROI 3 (8b)Threshold bits ROI 4 (8b) Jet Energy ROI 1 (12b)Jet Energy ROI 2 (12b) Jet Energy ROI 3 (12b)Jet Energy ROI 4 (12b) JEM: CPM: P 1L P 1R P 2L P 2R P 3L P 3R P 4L P 4R P 5L P 5R P 6L P 6R P 7L P 7R P 8L P 8R Threshold bits ROI 1 (8b) Threshold bits ROI 2 (8b)Threshold bits ROI 3 (8b)Threshold bits ROI 4 (8b) Threshold bits ROI 5 (8b)Threshold bits ROI 6 (8b)Threshold bits ROI 8 (8b) Threshold bits ROI 9(8b)Threshold bits ROI 10 (8b)

17. 17 Thoughts / conclusions Straightforward to port existing CMM VHDL code to Virtex 6  FPGA-specific elements using Unisim I/O is a limiting factor, seems to point towards a favored architecture  External CPLD for VME interface  G-link readout emulated with GTX transmitters Early CMM++ staging possible by adding more components to "Day-1" design  Don't need to start each new stage from scratch! No show stoppers so far!