flow: add OpenROAD built-in synth as _syn variant of every flat design

[oharboe]

Summary

Adds OpenROAD's integrated synthesizer (sv_elaborate + synthesize,
introduced by OpenROAD #10473)
as a universal _syn variant of every flat design driven by
design() in flow/designs/design.bzl. Relocates and generalises
the throwaway smoke target from
OpenROAD #10479
— that PR explicitly said the proper home for this was
bazel-orfs / ORFS, not OpenROAD's test tree.

End state for every flat design (gcd, aes, ibex, jpeg, …):

bazelisk build //flow/designs/asap7/gcd:gcd_syn_synth   # OpenROAD-built-in synth
bazelisk build //flow/designs/asap7/gcd:gcd_synth       # existing Yosys synth (unchanged)
bazelisk test  //flow/designs/asap7/gcd:gcd_syn_test    # QoR check when RULES_JSON present

Design

Purely additive. No existing Makefile recipe, bazel rule, design,
or target's behaviour is altered. The Yosys path stays exactly as it
is. Pieces:

• flow/scripts/synth_syn.tcl (new) — povik's driver. Reads
  LEF/Liberty/SDC via the ORFS env vars and writes 1_synth.odb +
  1_synth.sdc directly, bypassing the Yosys 1_2_yosys.v →
  synth_odb.tcl chain.
• flow/Makefile (new target do-syn-synth) — one phony recipe that
  invokes $(OPENROAD_CMD) -no_init -exit $(SCRIPTS_DIR)/synth_syn.tcl.
  No existing recipe touched.
• patches/bazel-orfs/0002-add-orfs_openroad_synth-…patch — parallel
  orfs_openroad_synth_rule + orfs_openroad_synth macro in
  bazel-orfs. OrfsInfo shape matches orfs_synth_rule so
  orfs_flow(previous_stage = {"floorplan": ":<name>_syn_synth"})
  chains downstream stages unchanged. Vendored here until the
  integrated syn tool stabilises and this lands upstream.
• flow/designs/design.bzl — design() now also emits the _syn
  chain for every flat design via a DESIGNS lookup + helper.
  Hierarchical designs (blocks non-empty) are skipped — the
  built-in synthesizer doesn't handle BLOCKS yet. All _syn
  targets are tagged manual so bazel build //... is unaffected.

Test Plan

• bazelisk build //flow/designs/asap7/gcd:gcd_syn_synth — runs
  OpenROAD on synth_syn.tcl via do-syn-synth; produces
  1_synth.odb + 1_synth.sdc under the _syn variant's results
  dir; log shows sv_elaborate / synthesize / syn::stats.
• bazelisk build //flow/designs/asap7/gcd:gcd_synth — unchanged
  Yosys path; no regression.
• bazelisk build //flow/designs/asap7/gcd:gcd_syn_final —
  downstream _syn_* stages chain from the syn-produced
  1_synth.odb and reach 6_final.gds.
• bazelisk build //... — manual-tagged _syn variants stay
  out of wildcard builds; pre-existing chains build as before.

Why this layout vs. PR 10479's genrule + SYNTH_NETLIST_FILES

PR 10479 used a genrule to produce a Verilog netlist and fed it
through the existing Yosys-aware SYNTH_NETLIST_FILES escape hatch.
That works for Verilog-emitting drivers like its
synthesize_gcd.tcl. povik's synth_syn.tcl instead writes
1_synth.odb directly — so it slots in cleaner as a separate synth
rule alongside orfs_synth_rule rather than as a netlist feeder.

Notes for follow-up

• The integrated synth tool is brand new; expect _syn_test
  baselines to drift until #10473 stabilises. The manual tag
  keeps that drift out of routine CI.
• Hierarchical designs are deliberately skipped pending BLOCKS
  support in the integrated synthesizer.
• When this lands upstream in bazel-orfs, drop
  patches/bazel-orfs/0002-…patch and bump BAZEL_ORFS_COMMIT.

[gemini-code-assist]

Code Review

This pull request introduces support for OpenROAD's integrated synthesizer as a parallel synthesis path. Key changes include a new Makefile target, a Tcl script for synthesis, and updates to the Bazel build logic to automatically generate a _syn variant for flat designs. Review feedback highlighted several opportunities to improve the robustness of the synth_syn.tcl script, such as adding guards for optional environment variables like DONT_USE_CELLS and SYNTH_SLANG_ARGS, improving path handling for include directories, and replacing design-specific hardcoding with generic configuration variables.

[gemini-code-assist]

The script will fail if the DONT_USE_CELLS environment variable is not defined in the environment. It should be guarded with a check to ensure robustness across different PDKs and designs.

if { [env_var_exists_and_non_empty DONT_USE_CELLS] } {
  set_dont_use $::env(DONT_USE_CELLS)
}

[oharboe]

no

[gemini-code-assist]

The script will crash if SYNTH_SLANG_ARGS is not defined in the environment. Using env_var_or_empty provides a safe fallback for optional variables.

lappend elaborate_args {*}[env_var_or_empty SYNTH_SLANG_ARGS]

[oharboe]

no

[gemini-code-assist]

Joining the list into a string and then using {*} to expand it later is redundant and can lead to issues if any directory paths contain spaces. It is better to keep vIdirsArgs as a list throughout.

set vIdirsArgs [list]
if { [env_var_exists_and_non_empty VERILOG_INCLUDE_DIRS] } {
  foreach dir $::env(VERILOG_INCLUDE_DIRS) {
    lappend vIdirsArgs "-I$dir"
  }
}

[oharboe]

yes

[gemini-code-assist]

Hardcoding design-specific logic like this reduces the maintainability and reusability of the script. Consider using a generic environment variable (e.g., SYNTH_REMOVE_PORTS) that can be set in the design's configuration (e.g., in cva6/config.mk).

if { [env_var_exists_and_non_empty SYNTH_REMOVE_PORTS] } {
  syn::remove_ports $::env(SYNTH_REMOVE_PORTS)
}

[oharboe]

not for now

[oharboe]

@povik Thoughts? You're listed as reviewer.

I'll incorporate your feedback + merge with origin/master to fix conflicts in one go.

[povik]

@oharboe My plan was to control switching on syn with a variable so individual designs can opt in.

[oharboe]

@oharboe My plan was to control switching on syn with a variable so individual designs can opt in.

Easy to add. Say the word.

I propose that we always add it, but that they are tags = ["manual"] unless designs opt in. This will allow you to explicitly bazelisk test foo_syn_synth, but they are not run with bazelisk test ...

[oharboe]

If we merge this, then you can easily run all designs locally with a modified OpenROAD and only those designs that are ready are run in CI.

ORFS bazelisk test ... needs to be wired up first in CI though.

[povik]

We need a solution independent of CI migrating to bazelisk, i.e. if one runs make -C flow DESIGN_CONFIG=.../config.mk for a design with syn opt-in it will use syn for synthesis. Should I do that myself in a separate PR, and then we can rebase yours on top of it, or do you want to do it here?

[oharboe]

We need a solution independent of CI migrating to bazelisk, i.e. if one runs make -C flow DESIGN_CONFIG=.../config.mk for a design with syn opt-in it will use syn for synthesis. Should I do that myself in a separate PR, and then we can rebase yours on top of it, or do you want to do it here?

That's already supported in bazel-orfs here:

bazelisk build designs/asap7/gcd:gcd_syn_synth

_syn_ is because FLOW_VARIANT=syn.

bazel-orfs also allows setting up a tmp folder with make, something like:

bazelisk run designs/asap7/gcd:gcd_syn_synth_deps

Then:

make -C tmp/designs/asap7/gcd/_main --file=flow/Makefile do-xxx

[oharboe]

@povik I think you have everything you need here, but there's new stuff to learn, or if you have Claude it is able to figure out magic incantations from plain language for all your testing needs of openroad syn. If you have a fast workstation(local or remote) available to you, you can easily do sweeps of testing like "all asap7 designs that are not to big" or "designs that failed in last PR"

[povik]

I see but the CI will run

make -C flow DESIGN_CONFIG=.../config.mk

without any bazelisk setup and I need to make it run syn on the designs with opt-in, hence why I'm asking if I should do a separate PR for that.