Перейти к содержанию

Лабораторная 11.19 — Runtime-запуск bridge_txrx_mux с самотактированием

Цель

Запустить полный overlay bridge_txrx_mux (TX и RX оба проходят через модем PL) с самотактируемой последовательностью управления пакетом и определить, продвигается ли tx_valid_count или rx_valid_count, когда PL TX и PL RX активны одновременно.

Предыдущие работы использовали bridge_rx_only (только PL RX) со стоковым TX хоста как свидетелем. Эта работа возвращается к полному двунаправленному overlay и использует самотактируемый режим, в котором PL TX стартует первым, ждёт фиксированное время установления, и только затем начинается опрос RX: имитируя аппаратный контроллер тайминга.

Зачем самотактируемый режим

В стандартном режиме управления пакетом хост посылает команду старта и сразу опрашивает rx_valid_count. Если тракту PL TX нужно время, чтобы «прогреть» конвейер DMA AD9361 до того, как активируется тракт RX, слишком ранний опрос всегда видит ноль. Самотактируемый режим вводит настраиваемое окно установления TX до начала опроса RX.

Файлы

Путь Назначение
blocks/block_11_integrated_sdr_project/python/lab_11_19_runtime_bridge_txrx_self_timed_bringup.py самотактируемый запуск полного overlay, JSON-доказательства

Запуск

python blocks/block_11_integrated_sdr_project/python/\
lab_11_19_runtime_bridge_txrx_self_timed_bringup.py \
  --bit-bin tmp/bridge_txrx_mux.wordswap.bit.bin \
  --tx-settle-ms 250 \
  --poll-limit 256 \
  --run-tag self_timed_live

Самотактируемая последовательность

загрузить overlay → проверить ID axi_gpreg
настроить AD9361 (915 МГц / 3,84 МС/с)
выставить burst_start
ждать tx_settle_ms
↓
цикл опроса:
  читать tx_valid_count, rx_valid_count, received_bits
  если rx_valid_count > 0 или received_bits > 0 → успех
  если достигнут poll_limit → таймаут
↓
восстановить AD9361 → необязательная перезагрузка
сохранить JSON-доказательства

Руководство по параметрам

Параметр Смысл Попробуйте сначала
--tx-settle-ms ожидание после burst_start до опроса RX 250 мс
--poll-limit максимальное число попыток чтения счётчиков RX 256
--poll-delay-ms пауза между опросами 20 мс
--start-offset циклы начального смещения PL-фреймера 62

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

Исход Смысл
tx_valid_count > 0, rx_valid_count > 0 полный двунаправленный запуск успешен
tx_valid_count > 0, rx_valid_count = 0 PL TX работает; нехватка данных RX сохраняется
оба нулевые DMA TX не «прогрет»; проверьте запись AXI burst_start

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

Самотактируемые прогоны неизменно показывали tx_valid_count > 0 (PL TX жив), но rx_valid_count = 0 независимо от значений tx_settle_ms вплоть до 500 мс. Это подтвердило, что «прогрев» TX не является ограничивающим фактором: нехватка данных RX не зависит от того, как долго работает TX до начала опроса RX.

Этот результат вместе с данными Lab 11.15–11.18 сместил расследование к внешнему мониторингу RTL-SDR (Lab 11.20–11.25), чтобы подтвердить, что сигнал TX действительно излучается, пока исследование тракта RX продолжается на уровне bitstream.

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

  • Записано tx_valid_count после первого опроса с tx_valid_count > 0.
  • Записаны rx_valid_count и received_bits при каждом опросе.
  • Указано использованное значение tx_settle_ms.
  • Приложен хвост dmesg.
  • Проведено сравнение с результатом bridge_rx_only из Lab 11.15.

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

Самотактируемый запуск bridge_txrx_mux выполнен с tx_settle_ms = ____ мс и
poll_limit = ____. tx_valid_count достиг ____ через ____ мс.
rx_valid_count после полного окна опроса: ____. received_bits: ____.
«Прогрев» TX является / не является причиной rx_valid_count = 0, потому что ______.