Closed radonnachie closed 1 year ago
At the very least we should disable_tx for the duration of the function.
This hasn't been an obvious issue in the case for <=2 antenna. It's only really creeping up with more (currently 13 antenna).
Does disabling TX successfully work around this?
rev 13.6 of the firmware (inbound) will remove the need to sync the boards to load the LO phase accumulators. Instead, they can be commanded to load at a specific time (like the coarse delay block), and this has no effect on the higher level system.
disabling tx seems only to solve the instance 0 crash.
I'll test this firmware now
Issue is resolved with firmware version "adm_pcie_9h7_dts_dual_4x100g_dsp_8b_2022-10-09_2043.fpg" and the applying of lo_fshifts
with force_load()
in the cosmic_f.cold_start(). @jack-h is requested to review and close issue.
This is a core difference in the manual
configure_remotefpgas.py
and the automatedobserve.py
processes: the former applies an LO F-Shift as part of configuration while the later applies zero F-Shift at configuration, awaits certain criteria and then directly sets the LO F-Shift.Steps to reproduce
configure_remotefpgas.py
set_lo_frequency_shift
to apply an LO F-ShiftObservation: After step 1. the ingest GB/s is as expected. After step 2. the ingest GB/s falls (arbitrarily between the recipients) and hashpipe instance 0 crashes with
0x1 (local length error)
(see).