Skip to content

Add: SIMPLER_TENSOR_DATA_TIMEOUT_MS to override the tensor-data wait - #2114

Draft
ChaoZheng109 wants to merge 1 commit into
hw-native-sys:mainfrom
ChaoZheng109:feat/tensor-data-timeout-env
Draft

Add: SIMPLER_TENSOR_DATA_TIMEOUT_MS to override the tensor-data wait#2114
ChaoZheng109 wants to merge 1 commit into
hw-native-sys:mainfrom
ChaoZheng109:feat/tensor-data-timeout-env

Conversation

@ChaoZheng109

Copy link
Copy Markdown
Collaborator

Summary

  • Make the tensormap_and_ringbuffer orchestration tensor-data wait
    (get_tensor_data / set_tensor_data, TENSOR_DATA_TIMEOUT_MS, 15 s)
    overridable per run with SIMPLER_TENSOR_DATA_TIMEOUT_MS, so a caller can
    tell a slow producer from a stuck one without reinstalling simpler.
  • The value rides the path the scheduler watchdog already uses: host env parse
    InitArgs.tensor_data_timeout_ms → resident-SO global latched by
    simpler_aicpu_init → read once per wait_for_tensor_ready() call. Sim
    latches the same value through the existing optional-symbol path.
  • Default is unchanged (15 s) and an unset variable changes nothing — 0
    means "keep the compiled default".
  • The new budget deliberately stays outside the
    scheduler/op-execute/stream-sync ordering group: that group is validated as a
    unit and a failure discards every override in it, so folding in a value the
    host cannot see (the default is compiled into the runtime) would let it
    invalidate an otherwise valid set. An unreachable value is reported by
    tensor_data_timeout_can_latch() as a warning instead.
  • host_build_graph is untouched: it resolves tensor data on the host and has
    no such wait.
  • The tensor_wait_timeout ST now lowers this one budget to 1 s instead of
    raising the other three above 15 s. The old env set was rejected by the
    ordering check anyway (SCHEDULER=30000ms is not below OP_EXECUTE=30s), so
    the case was passing on the compiled defaults and burning the full 15 s.

Testing

  • ctest -LE requires_hardware — 132/132 pass (extends
    test_runtime_timeout_config with the new field, an invalid-value case,
    and a case pinning "tensor-data stays out of the ordering verdict")
  • Simulation tests pass — tests/st/runtime_fatal_codes --platform a2a3sim
  • Hardware tests pass — tests/st/runtime_fatal_codes -k tensor_wait_timeout --platform a2a3 under task-submit: PASS in 7.9 s (was 21 s), and the
    device log shows the override actually reaching the AICPU —
    FATAL(code=8): Timeout (50000000 cycles) = 1 s at a2a3's 50 MHz counter,
    against 750000000 (15 s) without it.
  • clang-format, check_english_only.py, check_headers.py, markdownlint clean

Note for review

This adds one behavior-gating environment variable, which
.claude/rules/env-macro-gating.md requires be called out explicitly. It is the
fourth in the timeout family (SIMPLER_SCHEDULER_TIMEOUT_MS /
SIMPLER_OP_EXECUTE_TIMEOUT_US / SIMPLER_STREAM_SYNC_TIMEOUT_MS, #1112), opt-in
and default-off in the same sense: unset means the compiled default.

@coderabbitai

coderabbitai Bot commented Sep 3, 2026

Copy link
Copy Markdown

Warning

Review limit reached

Next included review available in 12 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 16d96c3f-125b-423a-b6f0-4fc0565c9d00

📥 Commits

Reviewing files that changed from the base of the PR and between 2a1920b and 17c4c35.

📒 Files selected for processing (25)
  • docs/dfx/args-dump.md
  • docs/dfx/profiling-config-naming.md
  • docs/troubleshooting/device-error-codes/stall.md
  • docs/troubleshooting/local-timeout-defaults.md
  • docs/user/reference/cli.md
  • src/a2a3/platform/include/common/kernel_args.h
  • src/a2a3/platform/onboard/aicpu/kernel.cpp
  • src/a2a3/platform/sim/host/device_runner.cpp
  • src/a2a3/platform/sim/host/device_runner.h
  • src/a2a3/runtime/tensormap_and_ringbuffer/docs/SCALAR_DATA_ACCESS.md
  • src/a2a3/runtime/tensormap_and_ringbuffer/runtime/runtime_core.cpp
  • src/a5/platform/include/common/kernel_args.h
  • src/a5/platform/onboard/aicpu/kernel.cpp
  • src/a5/platform/sim/host/device_runner.cpp
  • src/a5/platform/sim/host/device_runner.h
  • src/a5/runtime/tensormap_and_ringbuffer/docs/SCALAR_DATA_ACCESS.md
  • src/a5/runtime/tensormap_and_ringbuffer/runtime/runtime_core.cpp
  • src/common/platform/include/aicpu/aicpu_device_config.h
  • src/common/platform/include/host/runtime_timeout_config.h
  • src/common/platform/onboard/host/device_runner_base.cpp
  • src/common/platform/shared/aicpu/aicpu_device_config.cpp
  • src/common/runtime_status/error_names.h
  • tests/st/runtime_fatal_codes/kernels/orchestration/tensor_wait_timeout_orch.cpp
  • tests/st/runtime_fatal_codes/test_runtime_fatal_codes.py
  • tests/ut/cpp/common/test_runtime_timeout_config.cpp

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

The orchestration get_tensor_data / set_tensor_data spin in
tensormap_and_ringbuffer is bounded by TENSOR_DATA_TIMEOUT_MS, compiled into
the runtime at 15 s. Changing it needed a rebuild, so callers in other repos
could not tell a slow producer from a stuck one without reinstalling simpler,
and the tensor_wait_timeout ST had to raise the other three watchdogs above
15 s (an env set the ordering check rejects outright, since 30000 ms is not
below a 30 s op-execute) and then wait out the full 15 s on hardware.

Route the budget through the path the scheduler watchdog already uses: the
host parses the env var, forwards a validated value in InitArgs, the AICPU
entry latches it into the resident SO, and wait_for_tensor_ready reads it once
per call. 0 keeps the compiled default, so an unset variable changes nothing.
Only tensormap_and_ringbuffer consumes it; host_build_graph resolves tensor
data on the host and never waits.

The budget stays out of the scheduler/op-execute/stream-sync ordering group.
That group is validated as a unit and a failure discards every override in it,
so folding in a value the host cannot even see — the default lives in the
runtime — would let it invalidate an otherwise valid set. What ordering buys
instead is reachability: a wait that expires after the scheduler or op-execute
timeout never latches TENSOR_WAIT_TIMEOUT, because the run is already being
reaped. tensor_data_timeout_can_latch() reports that as a warning, and the
clean shutdown remains the scheduler watchdog's job for every stall shape.

The ST case now sets the wait to 1 s instead of pushing three other timeouts
out of the way: it latches code 8 in 7.9 s instead of 21 s, and the device log
confirms the override reaches the AICPU (Timeout (50000000 cycles) at a2a3's
50 MHz counter, against 750000000 for the default).
@ChaoZheng109
ChaoZheng109 marked this pull request as draft September 3, 2026 09:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant