140 likes | 316 Views
Design Criteria and Proposal for a CBM Trigger/DAQ Hardware Prototype. Joachim Gläß Computer Engineering, University of Mannheim Contents Requirements from Algorithms and Networks Design Considerations Proposal for a Hardware Architecture. September 9, 2004 Second FutureDAQ Workshop.
E N D
Design Criteria and Proposal for a CBM Trigger/DAQ Hardware Prototype Joachim Gläß Computer Engineering, University of Mannheim • Contents • Requirements from Algorithms and Networks • Design Considerations • Proposal for a Hardware Architecture September 9, 2004 Second FutureDAQ Workshop
Requirements • example: • algorithms for D-trigger • tracking of STS using Hough-transform (-> talk this afternoon) • Kalman-filter track following through MAPS (-> talk this afternoon) • primary vertex determination in y-z plane • secondary vertex and invariant mass • network • L1 processor network • hypertree readout network • event building • active buffer • hardware prototype should also be usable and used for implementations of all algorithms and networks Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
network Requirements • Different algorithms -> different hardware => programmable hardware => Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Design Considerations • FPGA combines flexibility of programming with implementation directly in parallel hardware processor • prototyp hardware testbed for all algorithms • small number of different building blocks • system should be capable to assimilate several algorithms as well as the appropriate network at the same time -> test system aspects • several FPGAs for algorithms • one FPGA for network • same type of FPGA to facilitate HDL development and maintanance of the tools Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Design Considerations • > 50,000 logic cells per FPGA from requirements (logic cells in FPGA not 100% utilisable) • testing, debugging, embedded CPUs • readout, writing of processed data / initialisation data during operation -> VirtexIIpro • 4 x 2.5 Gbit/s as substitute for 10 Gbit/s (integrated in VirtexIIpro) • external memory 8 x (1M x 16) from requirements Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
network Design Considerations • network connection to other units • > 1 x 10 Gbit/s = 4 x 2.5 Gbit/s • => 8 x 2.5 Gbit/s links • enables network topologies apart from star, ring, torus • number of FPGAs for algorithms • > 2 (balance between network and algorithm) • max. 4 (complexity of PCB) • 1 x 10 Gbit/s = 4 x 2.5 Gbit/s connections • => 8 – 16 x 2.5 Gbit/s links Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Proposal for a Hardware Architecture • XC2VP50 • 53,136 logic cells • 16 x 2.5 Gbit/s links • FF1152 or FF1517 flip-chip ball grid array package • 692 or 852 user I/Os • XC2VP70 • 74,448 logic cells • 20 x 2.5 Gbit/s links • FF1517 or FF1704 flip-chip ball grid array package • 964 or 996 user I/Os • XC2VP100 • 99,216 logic cells • 20 x 2.5 Gbit/s links • FF1704 flip-chip ball grid array package • 1040 user I/Os Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Proposal for a Hardware Architecture • system with 4 x XC2VP70 • extendable to 4 x XC2VP100 • 4 x 2.5 Gbit/s per connection Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Proposal for a Hardware Architecture • Alternative systems 3 x XC2VP70 reduceable to XC2VP50 7 x XC2VP70 extendable to XC2VP100 2 x 2.5 Gbit/s per connection 5 x XC2VP70 reduceable to XC2VP50 2 x 2.5 Gbit/s per connection Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Proposal for a Hardware Architecture • Alternative systems 4 x XC2VP70 extendable to XC2VP100 4 x 2.5 Gbit/s per connection 5 x XC2VP70 extendable to XC2VP100 2 x 2.5 Gbit/s per connection Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Proposal for a Hardware Architecture • external memory • 8 x (1M x 16) ZBT synchronous SRAM • ZBT: read/write access without dead cycles • supports > 200 MHz • DDR modules for PPC (?) • additional 2.5 Gbit/s links • 2 x SFP connectors • additional data input/output • additional network • additional Gb Ethernet • interface to/from PC • PCI/X • USB • Ethernet 4 x XC2VP70 extendable to XC2VP100 10 Gbit/s per connection Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Proposal for a Hardware Architecture • Systemsize • implement and test several algorithms and network at the same time • test real system aspects • workload balancing • find bottlenecks early • reasonable systemsize • 3 – 4 FPGAs for algorithms • 1 FPGA for network • 1 system – 1 board • NO connectors, cables, backplanes, additional boards • power supply and interfaces (PCI, USB, Ethernet) only once Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Summary • Goals • system has to be flexible and easily adaptable to many different algorithms for all kind of detector types that are needed for triggering • aim is to arrive at a modular solution based on a small number of building blocks that are linked by high-speed interconnects • system should be capable to assimilate several algorithms as well as the appropriate network at the same time • Design Criteria (from Requirements) • > 50,000 logic cells per FPGA • testing, debugging, embedded CPUs • 4 x 2.5 Gbit/s as substitute for 10 Gbit/s • external memory 8 x (1M x 16) Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering
Summary • Proposal for Hardware Architecture • system with 4 x XC2VP70 • extendable to 4 x XC2VP100 • 4 x 2.5 Gbit/s per connection • connection from/to board • SFP • connections to PC • PCI/X • USB • Gb Ethernet Joachim Gläß, Univ. Mannheim, Institute of Computer Engineering