Page History
...
Our first large area detector (2Mpx, 5kHz). Total data volume 2Mpx*5kHz*2bytes/px=20GB/s. 5 tiles in each quad. Each tile is 4 asics. Each ASICs is 144*192*4 (4 is number of asics).
Issues
Possible fiber configurations (with uniform distribution of tiles across nodes):
Some slides from Matt describing how to run epixHR prototype in MFX with LCLS-I timing: https://docs.google.com/presentation/d/1gauhczW2oMYa72_jbCMgenUQj7HGwxyCLvFPvMVpK84/edit?usp=sharing
The GitHub for the epixhr 2x2 prototype is https://github.com/slaclab/epix-hr-single-10k
Issues
Possible fiber configurations (with uniform distribution of tiles across nodes):
- 4 nodes: 5 tiles (1 quad) per node (5GB/s on one node, 21Hz per core (full-image equivalent))
- 10 nodes: 2 tiles per node (
- 4 nodes: 5 tiles (1 quad) per node (5GB/s on one node, 21Hz per core (full-image equivalent))
- 10 nodes: 2 tiles per node (2GB/s on one node, 8Hz per core(full-image equivalent))
- 20 nodes: 1 tile per node (1GB/s on one node, 4Hz per core(full-image equivalent))
...
- cpo to clarify with dionisio how many "configuration processes" we have?
one per quad? one per detector? one per panel?
- mikhail's projection onto the plane
o need simulated geometry
- need fake serial id numbers: test fetching of constants for a few panels
- multiple-segments per drp node. one executable per segment?
one executable for two segments? (prefer the latter). or redefine
a segment to be e.g. two panels (breaks our previous model of one
segment being one piece of silicon)
o need to event-build pgp which is a big change?
o label each drp detector with one segment: epixhr_0. can we have
two segments inside the dgram? (e.g. 0,1)
o Ric points out that if we have multiple segments per drp exe then
we could conceivably take advantage of that for things like veto
computations. But we would have to distribute the panel data in
an intelligent way.
- run drp-python
- run libsz compression
- run det.calib()
- eventually: veto using Ric's teb. currently we have python-decision
(parallelized for multiple nodes with multiple teb's). but for the
generation of the trigger data (e.g. "number of photons in my panels")
feels like we should use drp-python. but this needs development.
- eventually: inject more realistic (simulated?) data. use skopi for this?
EpixHR2x2
Fiber Lane Assignments
The fiber lane assignments for the 2x2 boards is
Lane[0] = Data
Lane[1] = Data
Lane[2] = ?
Lane[3] = Timing
ASIC Versions
The v2 ASIC requires descrambling of the data and the matrix readback does not work. The v4 ASIC should correct these issues.
Beam Test Trigger Setup
Detector tests run in the MFX beam line with hard x-ray beam from the LCLS NC accelerator. Thus, the 120 Hz beam is aligned with particular phases of the 60Hz AC power line, and the time between beam pulses varies with the power line sampling. In order to emulate high rate run triggers but still achieve alignment with the beam, an event code generating sequence is run in the XPM that restarts a train of triggers each 120 Hz cycle. For example, to simulate a trigger rate of 5 kHz, 41 triggers are generated with 200 us spacing every 120 Hz cycle (thus, 4920 kHz). The LCLS NC timing event codes provide enough time (~834us) to fire a few of these triggers before the beam arrives. The sequence would then generate new event codes at the following time intervals after receiving event code 40 from the accelerator:
event code | name | description | usec after EC 40 |
---|---|---|---|
0 | run trigger | used by detector to latch beam response | 34, 234, 434, 634, 834, ..., 8034 |
1 | daq trigger | used to readout detector | 834 + subset of run trigger |
2 | parent trigger | used to trigger daq parent group | 0 + all daq trigger |
3 | target | marks the daq event in-time with beam | 834 |
The XPM is programmed using the seq_epixhr script. It's usage is:
(ps-4.6.3) bash-4.2$ seq_epixhr -h
usage: seq_epixhr [-h] [--rate RATE] [--tgt TGT] [--daq DAQ] [--full] [--f360] [--minAC MINAC] [--pv PV] [--test] [--plot] [--verbose]
Sequence for EpixHR DAQ/Run triggering
optional arguments:
-h, --help show this help message and exit
--rate RATE Run trigger rate (Hz)
--tgt TGT DAQ trigger time (sec)
--daq DAQ DAQ trigger at RUN trigger rate/N
--full DAQ trigger at RUN trigger rate (same as --daq 1)
--f360 DAQ trigger at 360 Hz
--minAC MINAC Minimum 120H interval in 119MHz clocks
--pv PV XPM pv base
--test Calculate only
--plot Plot sequence
--verbose Verbose
The pv argument programs the sequence to a particular engine within the XPM, thus assuming the event codes that appear. Lastly, the a readout group must be driven by the run trigger event code. Since the DAQ makes no use of this readout group, it has to be done manually with groupca.
Running devGui
From Alex Batyuk:
Code Block |
---|
cd /cds/home/w/weaver/epix-hr-new/software
source ./setup_l2si.sh
python scripts/ePixHr10kTDaqLCLSII.py --start_viewer True --start_gui True |