Background
Every design in HighTide has two RTL sources selectable at build time:
- Release — pre-generated Verilog committed into the repo (default, fast, offline).
- Dev — RTL regenerated from upstream via
designs/src/<design>/dev/setup.sh, opt-in via bazel build --define update_rtl=true.
The switch is a select() on //:update_rtl inside each design's BUILD.bazel, backed by a rtl_dev_gen genrule that invokes setup.sh.
For NVDLA (added in #68), the rtl alias currently points at :rtl_release unconditionally. --define update_rtl=true has no effect on NVDLA — regenerating its RTL from upstream still requires running designs/src/NVDLA/dev/setup.sh manually and committing the result.
Why it wasn't done in the first PR
- 423-file output. A Bazel
genrule must enumerate every outs = [...] up front. NVDLA produces a 423-file vmod/ tree, versus one .v file for cnn / NyuziProcessor.
- Heavyweight toolchain.
setup.sh installs JDK 11, OpenSSL 1.0.2u, Perl 5.10.1, Python 2.7.18, and SystemC 2.3.0 from source, then runs NVIDIA's tmake for hours. Not friendly to a hermetic Bazel action (needs network, large disk, internal caching that fights Bazel's).
Options
- (a) Tarball output + extraction rule.
rtl_dev_gen produces a single vmod.tar, a second rule extracts into a per-build tree. Bazel stays happy about declared outputs; NVDLA's generator doesn't need to learn file lists.
- (b) Generated
srcs.bzl listing outputs (the bp_processor pattern). setup.sh emits dev/generated/srcs.bzl as a side-effect of its run; the genrule declares those paths. Requires srcs.bzl to be committed alongside the generated tree.
- (c) Keep release-only, document the manual refresh workflow. Status quo.
Acceptance
bazel build --define update_rtl=true //designs/asap7/NVDLA/partition_a:partition_a_final regenerates the RTL from the pinned upstream submodule and builds cleanly.- Manual refresh path (
designs/src/NVDLA/dev/setup.sh + commit) still works for CI/baseline refreshes.
- Document the chosen approach in
designs/src/NVDLA/README.md (or CLAUDE.md) alongside the existing dev-mode section.
Related
Background
Every design in HighTide has two RTL sources selectable at build time:
designs/src/<design>/dev/setup.sh, opt-in viabazel build --define update_rtl=true.The switch is a
select()on//:update_rtlinside each design'sBUILD.bazel, backed by artl_dev_gengenrule that invokessetup.sh.For NVDLA (added in #68), the
rtlalias currently points at:rtl_releaseunconditionally.--define update_rtl=truehas no effect on NVDLA — regenerating its RTL from upstream still requires runningdesigns/src/NVDLA/dev/setup.shmanually and committing the result.Why it wasn't done in the first PR
genrulemust enumerate everyouts = [...]up front. NVDLA produces a 423-filevmod/tree, versus one.vfile for cnn / NyuziProcessor.setup.shinstalls JDK 11, OpenSSL 1.0.2u, Perl 5.10.1, Python 2.7.18, and SystemC 2.3.0 from source, then runs NVIDIA'stmakefor hours. Not friendly to a hermetic Bazel action (needs network, large disk, internal caching that fights Bazel's).Options
rtl_dev_genproduces a singlevmod.tar, a second rule extracts into a per-build tree. Bazel stays happy about declared outputs; NVDLA's generator doesn't need to learn file lists.srcs.bzllisting outputs (thebp_processorpattern).setup.shemitsdev/generated/srcs.bzlas a side-effect of its run; the genrule declares those paths. Requiressrcs.bzlto be committed alongside the generated tree.Acceptance
bazel build --define update_rtl=true //designs/asap7/NVDLA/partition_a:partition_a_finalregenerates the RTL from the pinned upstream submodule and builds cleanly.designs/src/NVDLA/dev/setup.sh+ commit) still works for CI/baseline refreshes.designs/src/NVDLA/README.md(orCLAUDE.md) alongside the existing dev-mode section.Related