Page History

...

From Matt: The ATCA crate in the FEE has a crate number that must differ from the other crates on the network.  That crate number comes from the shelf manager.  So, when we get a shelf manager, we'll need to set its crate ID.  That determines the third byte for all the IP addresses in the crate.  10.0.<crate>.<slot+100>.  See LCLS-II: Generic IPMC Commands#HowtosetupATCAcrateID for setting the ATCA crate ID.

An example session from Matt:

[weaver@psdev02 ~]$ ssh root@shm-neh-daq02
key_load_public: invalid format
Warning: Permanently added 'shm-neh-daq02,172.21.156.127' (RSA) to the list of known hosts.
root@shm-neh-daq02's password:
sh: /usr/bin/X11/xauth: not found
# clia shelfaddress
Pigeon Point Shelf Manager Command Line Interpreter
    Shelf Address Info: "L2SI_0002"

Trigger Delays

• the total delay of a trigger consists of three pieces:  CuDelay, L0Delay (per XPM and per readout group), and detector delays.  Note that L0Delay is also called "PartitionDelay" in the rogue registers.  L0Delay variable is:  DAQ:NEH:XPM:0:PART:0:L0Delay (second zero is readout group).  Note: L0Delay only matters for the master XPM.
• Matt writes about CuDelay:  The units are 185.7 (1300/7) MHz ticks.  You only need to put the PV or change it in xpmpva GUI.  It will update the configdb after 5 seconds.  You may notice there is also a CuDelay_ns PV (read only) to show the value in nanoseconds.  Best not to change CuDelay while running: we have noticed it can cause some significant issues in the past.
• Matt says the units of L0Delay are 14/13 us, because the max beam rate is 13/14 MHz.
• L0Delay has a lower limit of 0 and an upper limit around 100.
• CuDelay is set in the supervisor XPM and affects all client XPMs (e.g. TMO, RIX).  Matt tries to not adjust this since it is global.
• In the various detector specific configdb/*config.py the current value of L0Delay for the appropriate readout group is included in the "delay_ns" calculation.  So if, for example, L0Delay is adjusted then the "delay_ns" set in the configuration database remains constant.
• Moving timing earlier can be harder, but can be done by reducing group L0Delay.
• In general, don't want to reduce L0Delay too much because that means the "trigger decision" (send L1accept or not, depending on "full") must be made earlier, which increases the buffering requirements.  This doesn't matter at 120Hz, but matters for MHz running.  The only consequence of a lower L0Delay is higher deadtime.
• Note: if the total trigger delay increases (start_ns) then also need to tweak deadtime "high water mark" settings ("pause threshold").   How do we know if the pause threshold is right: two counters ("trigToFull and "notFullToTrig" for each of the two directions) to try to measure round-trip time, which should allow one to calculate the pause-threshold setting.
• Detectors with minimal buffering (or run at a high rate) need a high L0Delay setting (depends on ratio of buffering-to-rate)

• Ric asks: Does XPM:0 govern L0Delay or does XPM:2 for TMO and XPM:3 for RIX do it for each, individually? Matt replies: Whichever is the master of the readout group determines the L0Delay.  The other XPMs don't play a part in L0Delay.  Only fast detectors (hsd's, wave8's, timing, should have large L0Delay)

• We should try to have slower detectors have a smaller L0Delay (wasn't possible in the past because of a firmware bug that has been fixed)
• the per-readout-group L0Delay settings (and CuDelay) are stored under a special tmo/XPM alias in the configdb and are read when the pyxpm processes are restarted:

...

"rix" and "tmo" ones are in the hutches.  "daq" one is currently in the FEE and the "neh" one is in room 208 of bldg 950.

Resetting Boards

...