Лабораторная 11.17 — Развёртка start_offset после runtime-повторной инициализации RX common при стоковом TX хоста¶

Цель¶

Определить, влияет ли параметр start_offset в AXI-gpreg на результат rx_valid_count = 0, наблюдавшийся в Lab 11.15.

Поле start_offset определяет, сколько тактов PL-фреймер ждёт после триггера начала пакета, прежде чем начать выборку символов. Если задержка конвейера AD9361 → PL меняется между стоковой и runtime-загрузками, изначально выбранное значение (62) может заставить фреймер брать выборки вне допустимого окна, объясняя нулевой rx_valid_count даже при здоровом тракте DMA.

Конструкция развёртки¶

Скрипт перебирает start_offset от 0 до настраиваемой верхней границы (по умолчанию 127) с шагом 1. Для каждого значения он:

перезагружает overlay bridge_rx_only (свежо на каждой итерации или один раз в начале, управляется --reload-per-iter);
при необходимости принудительно повторно инициализирует rx_common;
запускает стоковый пакет TX хоста;
опрашивает rx_valid_count и received_bits;
записывает снимок счётчиков.

Развёртка записывает массив JSON по одной записи на значение start_offset плюс сводку о том, какие значения (если есть) дали rx_valid_count > 0.

Файлы¶

Путь	Назначение
`blocks/block_11_integrated_sdr_project/python/lab_11_17_runtime_rx_common_reinit_start_offset_sweep.py`	перебор `start_offset`, сбор снимков счётчиков gpreg, запись JSON-отчёта

Запуск¶

python blocks/block_11_integrated_sdr_project/python/\
lab_11_17_runtime_rx_common_reinit_start_offset_sweep.py \
  --bit-bin tmp/bridge_rx_only.wordswap.bit.bin \
  --start-offset-max 127 \
  --json-out docs/assets/lab117_start_offset_sweep_live.json

Полная развёртка 0–127 занимает примерно 5–10 минут в зависимости от --poll-limit и задержки SSH.

Ожидаемые результаты¶

Файл	Содержимое
`docs/assets/lab117_start_offset_sweep_live.json`	снимки счётчиков по итерациям
Сводка в консоли	первый `start_offset` с `rx_valid_count > 0` либо «none found»

Как интерпретировать результат¶

Исход	Интерпретация
Некоторые значения `start_offset` дают `rx_valid_count > 0`	задержка конвейера изменилась; используйте рабочее значение в последующих работах
Все значения `start_offset` дают `rx_valid_count = 0`	дело не в задержке; нехватка данных DMA глубже
`rx_valid_count > 0`, но `received_bits = 0`	тактирование фреймера работает, но выравнивание бит нарушено: проверьте `rx_decision_mode`

Живой результат 2026-06-23¶

Развёртка по start_offset ∈ [0, 127] дала rx_valid_count = 0 для каждого проверенного значения. Это исключает неверную настройку start_offset как первопричину нехватки данных RX под runtime-overlay. В сочетании с результатом Lab 11.16 данные указывают на более глубокую проблему тракта DMA AD9361 → PL, сохраняющуюся после любой одиночной подстройки регистра.

Чек-лист отчёта¶

Указаны диапазон start_offset и шаг развёртки.
Приложен JSON-файл развёртки.
Отмечено, дало ли какое-либо значение rx_valid_count > 0.
Записана использованная настройка повторной инициализации rx_common.
Указан вывод о задержке конвейера как факторе.

Шаблон инженерного вывода¶

start_offset перебирался от ____ до ____ с шагом ____ при повторной инициализации rx_common
____ (включена / выключена). rx_valid_count > 0 наблюдался при значениях start_offset:
____ (либо «нет»). Задержка конвейера является / не является основной причиной результата
rx_valid_count = 0, потому что ______.