Possible%20changes%20to%20electronics

1
Possible changes to electronics

• Paul Dauncey
• Imperial College

• Some ideas on iterations to the design
• Reduce number of uplinks?
• Remove large memory?

2
Reduce number of uplinks?

• Data rate on downlinks is minimal
• Makes sense to use single (expensive) fibre to
  multiple FECs and split signals on DIC.
• Saved 20k - 2k - 3k 15k
• Less obvious to do the same for the uplinks
• Data volume is high so reduces readout rate
• Potential savings are 18k (but might be more)

3
Make uplink 16-1 also

• Complicates DIC needs to combine 16 (one-bit _at_48
  MHz) signals and feed into one fibre
• Will FEC-to-FEC skew be small enough that no
  resynchronisation is necessary?
• Will some intelligence be needed on the DIC, e.g.
  dual port RAM, to get data in phase again?
• Reduces data rate out of each FEC by factor of 16
• Look at when that dominates

4
Document design rates

• Data rates in current design
• Large-to-small memory data reduction 20ms
  (independent of data contents)
• Uplink readout 16ms per shower or 30ms for
  total large memory
• VME readout (25 Mbytes/s) 600ms per shower or
  10s for total large memory
• Completely dominated by VME speed as uplinks run
  in parallel

5
Output vs input rates (1)
6
Reduced uplink rates

• Data rates with 16-1 uplinks
• Large-to-small memory data reduction 20ms
  (independent of data contents)
• Uplink readout 250ms per shower or 400ms for
  total large memory
• VME readout (25 Mbytes/s) 600ms per shower or
  10s for total large memory
• Still dominated by VME speed but does have a
  non-negligible effect

7
Output vs input rates (2)
8
Implications for BEC (1)

• Would have only 6 fibre pairs from 6 DICs, so
  each BEC only has one fibre pair
• Enough front panel space to combine all BECs into
  one board
• Saving from PCB costs 10k
• Space for all components on one board?
• FCT interface much simpler single input
• Could BEC become source of clock and StartTrain,
  i.e. effectively the FCT?

9
Implications for BEC (2)

• With one board, is VME still sensible?
• Direct interface to PCI card? (UCL?). May gain
  back some rate loss?
• Still requires 250 Mbytes total of memory, with
  cost 40k
• Unless DICs now read one at a time, when only 40
  Mbytes required, 7k
• Save substantial space on board
• Implications for FEC synchronisation check all
  FECs send handshake at same time

10
Reduced uplink rates

• Data rates with 16-1 uplinks serial DIC readout
• Large-to-small memory data reduction 20ms
  (independent of data contents)
• Uplink readout 800ms (?) per shower or 2.5s for
  total large memory
• VME readout (25 Mbytes/s) 600ms per shower or
  10s for total large memory
• Comparable with VME speed halves original rate

11
Output vs input rates (3)
12
Remove large memory

• Large memory stores raw data before reduction
  write reduced data directly to small memory?
• Raw input data rate is 112 chs _at_ 12 MHz
• Need to allow same output rate for peaks
• Input is 10 bits/ch but output needs time stamp
  and gain/channel label so 30 bits/ch.
• Use 200 pins/FPGA (10 in 30 out) x 5 ch need
  23 FPGAs if no multiplexing.
• E.g. output _at_ 24 MHz, reduce to 14 FPGAs

13
Other factors

• At low beam rates, speed dominated by
  large-to-small data reduction
• Reduced from 20ms to 1ms, e.g. order of
  magnitude improvement for rates 100 Hz.
• Cannot read out all raw data any more
• Could only store 10 directly
• Cost large memory 400 saved on both FEC and
  BEC. 14 FPGAs? Could be 1000/FEC...
• Probably not a saving overall

14
Summary

• Combining uplinks at DIC would save 18k,
  making a single BEC would save another 10k and
  serially reading the FECs would save another
  35k, at a cost of a factor 2 in speed at high
  rates
• Sounds worth pursuing
• Removing the large memories would possibly cost
  20k, reduce functionality but gain a factor 10
  in speed at low rates
• Probably not a benefit overall