Home design with BNL Immediate plans for DUNE-UK hardware effort - - PowerPoint PPT Presentation

home design with bnl
SMART_READER_LITE
LIVE PREVIEW

Home design with BNL Immediate plans for DUNE-UK hardware effort - - PowerPoint PPT Presentation

Home design with BNL Immediate plans for DUNE-UK hardware effort Giles Barr Oxford: UK DUNE DAQ project kickoff meeting 17-18 October 2019 7 Home design with BNL Summary: Collaborating on a Versal design with BNL is very interesting


slide-1
SLIDE 1

Home design with BNL

Immediate plans for DUNE-UK hardware effort

Giles Barr Oxford: UK DUNE DAQ project kickoff meeting 17-18 October 2019

7

slide-2
SLIDE 2

Home design with BNL

  • Summary:
  • Collaborating on a Versal design with BNL is very interesting indeed
  • BNL less interested in a non-Versal design
  • UK has some open questions with Versal still (such as: when technical

info and reference designs become available, cost)

  • Plan:
  • We will proceed with system design studies of both a Zynq and Versal

design in parallel until more Versal info is available

  • To get serious commitment and detailed technical info from potential

board manufacturers and from our studies, we will proceed with the Zynq design in 'full detail' – i.e. sufficient to actually build the board, and will stop this when the Versal open questions are clear. [*]

[*] The item in blue is not to indicate a preference for non-Versal; on the contrary, the advantage is we don't spend much extra effort by elevating the feasibility study to an actual design on the Zynq (where we have sufficient technical details, reference designs etc.). We thereby end up in a reduced risk situation by being in possession of a practical design, and we have firmer knowledge of UK board manufacturer capability, power distribution, and other things that are similar between Zynq and Versal.

8

slide-3
SLIDE 3

Home design with BNL (2)

  • Overall goal is to end up with a board that can do

all the things we need. Designed in such a way that ultrascale+ firmware can be ported easily to it.

  • Versal will do this
  • (and Zynq if it continues to be a backup solution)
  • COTS boards will do this
  • Use COTS ultrascale+ boards to develop firmware

and software vigorously in parallel with hardware development.

  • We should have a bit of brainstorming to see how to do

this (either now, or after DAQ sprint)

9

slide-4
SLIDE 4

Does the board 'do all the things we need'?

  • Must present this question in upstream-DAQ meetings to

gain consensus that what we intend to build indeed does what we need.

  • Will attempt to practice those arguments here today:
  • Requirements:
  • Board capable of copying all data into host-memory with FELIX

firmware and software on PCIe bus.

  • Board capable of providing hit-finding etc. in firmware.
  • DRAM memory and SSD buffering on board for trigger latency

functions.

  • Maximum flexibility at design-start (now) to later tune things:
  • Size of FPGA, number of boards, memory bandwidth, whether

memory feature is included at all, etc.

10

slide-5
SLIDE 5

Essential Requirements at Conceptual Level

  • 1. Online trigger and data selection
  • 2. Pre-trigger RING buffer up to e.g. 10s,
  • 3. Post-trigger 100s FIFO buffer
  • 4. DAQ up time >99% + minimize maintenance cost over 20

years

  • 5. Reserve engineering margins for running additional and

unknown processes in the future (new ideas).

  • 6. Project restrictions: Some of R&D and construction

(hardware) should be in UK.

  • 7. Compatible with FELIX firmware suite. (desirable)

11

slide-6
SLIDE 6

The discussion focusses around these five approaches

  • A. ZU19 – preferred next board choice in Oxford [Want to

change this to ‘in UK’ when more discussion].

  • B. ZU15(or 6 or 9) – Temporarily deprecated, but included

for comparison.

  • C. KU15P – like ZU19 but no processor.
  • D. Versal – like ZU19, but one generation more modern.
  • E. Stop hardware development now - commercial boards

will be available (e.g. Bittware VU9P)

12

slide-7
SLIDE 7

Layout considerations

Take FPGA-only raw cost from UK proposal and see how many chips can be purchased, maximize SystemLogicCells (SysLog) per APA and BRAM per APA for this cost. Have scaled

  • ur quantity/education discount from quote

for UK grant request 2018, not included latest devaluations of £ L. Arranged in tables below: Major columns are how many FPGAs per APA

13

slide-8
SLIDE 8

Layout considerations

BRAM+URAM (previous slide was BRAM only)

14

slide-9
SLIDE 9

Layout considerations

This slide is to show off that we did a lot

  • f configurations, different sockets etc.

15

slide-10
SLIDE 10

Architecture considerations

Objective is to find combinations of Xilinx giving a lot of flexibility and explore the cost optimum.

  • Now (2019): We must choose the

socket type now, and make sure there are enough links and bandwidth to handle the sensible configurations.

  • When we order bulk (2022):

Choose the Xilinx chip that fits into

  • ur socket – handle on the amount
  • f logic and memory per link.
  • When we turn on the detector

(2026): Choose how many cards per APA are used, to fine-tune the logic and bandwidth. Versal good for 20-links per card, too expensive for 10-, 7-, 5- or 4-links. So not much good for flexibility in 2026 unless price drops. Zynq is opposite: Good for 10-, 7-, 5-

  • r 4-links, but under-resourced for

20-links per card. Zynq is overall cheaper (always the case that older is cheaper, until it goes out of production, which will probably be sooner). Simpler card to design. Kintex is same as Zynq but no processor All these options are good, so we pick from a number of good ones. 16

slide-11
SLIDE 11

Conclusions

  • Some choices on the hardware need making early (compared with firmware and

software, where the reverse gear is easier to find)

  • It is not really that controversial, we have optimized and found two or three

really good choices

  • Important to now convince upstream DAQ group (and data selection group) we

have selected the optimum

  • Remaining choice is a very common one in DAQ:
  • Do we go with the new shiny generation, that is more expensive, ATLAS like it, but leaves

us less development time.

  • Or go for the one we know, can get a first version quickly – best if we want to do long term

reliability tests (this is what attracts me to it), but will go out of production sooner. Pleasingly, COTS options exist Will study both these as more info about Versal emerges, will do the Zynq with intention of building it – gives us hardware in pocket well within schedule.

  • All these should be straightforward to port a standard FELIX/DUNE-trig suite to.
  • Use evaluation boards to develop firmware in parallel with hardware
  • Evaluation boards also serve as a fallback solution

17

slide-12
SLIDE 12

Backup

18

slide-13
SLIDE 13

Architecture considerations

The following four architectures for DUNE have been discussed widely

Option 1 = FELIX-CPU only, no memory or SSD on HW board. Option 2 = FELIX with memory and SSD but no processor. Can run the planned IPBus-based firmware and FELIX firmware. Option 3 = As option 2 but with CPU in

  • FPGA. Allows CPU-assisted firmware
  • architecture. As fallback (not proposing

development under option 3) can send PCIe traffic over Ethernet from CPU instead. Option 4 = As option 3 but no FELIX. Not currently proposing this, but included for cost comparison.

A B C D E 1 Y N Y Y Y 2 Y N Y Y Y 3 Y N N Y N 4 Y Y N Y N

Here is how they match up with the five approaches

  • n previous slide

A (ZU19) and D (Versal) are the most flexible. C (KU15) and E (VU9P) have no processor so exclude option 3. B is not as flexible.

19