feat(variables): FLOW_INPUT_VARIANT, read inputs from another variant - #4475
feat(variables): FLOW_INPUT_VARIANT, read inputs from another variant#4475oharboe wants to merge 5 commits into
Conversation
FLOW_VARIANT names the directory a run writes to. It also names the directory a run reads from, which means a variant that wants to reuse an upstream variant's results has to physically copy them into its own directory first. Sharing an expensive front end across experiments — one synthesis, one floorplan, many routing variants — is a `cp -r` per fork today. Split the two. FLOW_INPUT_VARIANT names the variant a run reads from and gives INPUT_RESULTS_DIR, INPUT_LOG_DIR, INPUT_REPORTS_DIR and INPUT_OBJECTS_DIR alongside the existing output directories. It defaults to FLOW_VARIANT, so every INPUT_*_DIR expands to a string identical to its *_DIR counterpart and an unchanged run is unchanged. Reads resolve against a search path: RESULTS_DIR first, INPUT_RESULTS_DIR second. RESULTS_DIR has to come first because a stage runs several steps in one process — do-place writes 3_1_place_gp_skip_io.odb and the next step reads it back — and a file this run just wrote must win over the upstream variant's copy of it. orfs_input_path and orfs_input_glob in util.tcl are the search; every write still goes straight to RESULTS_DIR. load_design is the chokepoint: all 18 stage scripts hand it a bare basename, so routing it through orfs_input_path covers the whole flow. The remaining reads are the AUTO_MEMORIES globs, find_sdc_file, the abstract's .spef, yosys_load's netlist, and genMetrics' log/report/ result directories. find_sdc_file's candidate ordering now compares basenames rather than full paths. With one directory the two are equivalent, since every candidate shares a prefix; with two, the directory prefix would otherwise decide which .sdc wins. The Makefile's prerequisite graph is deliberately untouched: it still names $(RESULTS_DIR). A forked variant is driven through the do- targets, which is what the flow.sh path does anyway. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces the FLOW_INPUT_VARIANT feature, allowing a run to read inputs from an upstream variant directory while writing outputs to its own variant directory. This enables sharing expensive front-end stages across multiple downstream experiments without copying files. The changes include updating path resolution in Tcl scripts to search both current and input results directories, updating makefiles, and adding documentation. The review feedback highlights a critical issue in flow/util/utils.mk where using INPUT_*_DIR exclusively for metadata generation and autotuning will incorrectly read upstream metrics instead of the current variant's metrics. Additionally, the reviewer noted an inconsistency in the documentation's Mermaid diagram, which incorrectly depicts the main flow starting at global routing instead of re-running from the floorplan stage to apply new IO constraints.
6a813d0 to
369f779
Compare
…ics limits FLOW_VARIANT and genMetrics.py works only within a single variant. Implement a hard stop in genMetrics.py if FLOW_INPUT_VARIANT is different from FLOW_VARIANT, as cross-variant log/report paths are not supported. Fix GUI reading netlist in forked variants by resolving V_FILE through orfs_input_path. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
369f779 to
c27ec1e
Compare
🔍 QoR checkMetrics reflect the PR merge build — i.e. what will land on the target branch. Advisory — results are log-only and do not affect build status. The authoritative QoR gate remains the local rules-file check. Commit 63 design(s) checked — 0 with regression(s), 1 without a comparable baseline.
|
…AILURE The FLOW_INPUT_VARIANT note about genMetrics.py was accidentally inserted mid-sentence into the GENERATE_ARTIFACTS_ON_FAILURE description; the note already lives in FLOW_INPUT_VARIANT's own description. Regenerated variables.json and FlowVariables.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
…variant Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
|
@maliberty coralnpu failure? |
|
This looks rather error prone given the number of places you had to touch. Would it be easier to just have a copy (or symlink) target? |
That creates an iffy stateful mess in bazel-orfs I am trying to get rid of. |
We've been bitten in the past by the code to infer which .sdc file to load based on the .odb file. Why the dichotomy of .odb and .sdc? There are a million bits and bobs in .odb for all sorts of modules, what makes .sdc special? Perhaps .odb could subsume the .sdc like it does so many other things. The only thing we can do with the freedom we have today is to load the wrong .sdc data. |
3 participants
FLOW_VARIANT names the directory a run writes to. It also names the directory a run reads from, which means a variant that wants to reuse an upstream variant's results has to physically copy them into its own directory first. Sharing an expensive front end across experiments — one synthesis, one floorplan, many routing variants — is a
cp -rper fork today.Split the two. FLOW_INPUT_VARIANT names the variant a run reads from and gives INPUT_RESULTS_DIR, INPUT_LOG_DIR, INPUT_REPORTS_DIR and INPUT_OBJECTS_DIR alongside the existing output directories. It defaults to FLOW_VARIANT, so every INPUT_*_DIR expands to a string identical to its *_DIR counterpart and an unchanged run is unchanged.
This is the ORFS side of The-OpenROAD-Project/bazel-orfs#846, extracted as a single concern patch.