{"id":19290928,"url":"https://github.com/the-openroad-project/bazel-orfs","last_synced_at":"2025-02-23T23:52:39.159Z","repository":{"id":221298602,"uuid":"753728398","full_name":"The-OpenROAD-Project/bazel-orfs","owner":"The-OpenROAD-Project","description":null,"archived":false,"fork":false,"pushed_at":"2024-10-29T10:05:42.000Z","size":462,"stargazers_count":5,"open_issues_count":0,"forks_count":5,"subscribers_count":6,"default_branch":"main","last_synced_at":"2024-10-29T11:02:31.953Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Starlark","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/The-OpenROAD-Project.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-02-06T17:24:15.000Z","updated_at":"2024-10-29T09:21:17.000Z","dependencies_parsed_at":"2024-02-07T08:23:42.235Z","dependency_job_id":"92219cad-d3bf-4456-abf0-c9bb9bacad7e","html_url":"https://github.com/The-OpenROAD-Project/bazel-orfs","commit_stats":null,"previous_names":["the-openroad-project/bazel-orfs"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2Fbazel-orfs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2Fbazel-orfs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2Fbazel-orfs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2Fbazel-orfs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/The-OpenROAD-Project","download_url":"https://codeload.github.com/The-OpenROAD-Project/bazel-orfs/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":240395749,"owners_count":19794573,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T22:23:00.677Z","updated_at":"2025-02-23T23:52:39.129Z","avatar_url":"https://github.com/The-OpenROAD-Project.png","language":"Starlark","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Bazel-orfs\n\nThis repository contains [Bazel](https://bazel.build/) rules for wrapping [OpenROAD-flow-scripts](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts) (ORFS).\n\nWhy Bazel on top of ORFS?\n-------------------------\n\nbazel-orfs gives all the expected Bazel advantages to ORFS: artifacts, parallel builds, remote execution, repeatable builds, etc.\n\nAlso, ORFS and OpenROAD is work in progress and one should expect for\nlarge designs to get involved with the community or need a\nsupport contract with Precision Innovations (https://www.linkedin.com/in/tomspyrou/).\n\nUsing ORFS directly, instead of modifying it or creating an alternative flow,\nmakes it easy to get the very latest features and version of OpenROAD and ORFS\nas well as having access to all ORFS features, including debugging\nfeatures such as `make issue` and `deltaDebug.py`.\n\nSince bazel-orfs uses the unmodified ORFS, it is easy to articulate familiar\nand easily actionable github issues for the OpenROAD and ORFS maintainers.\n\n## Requirements\n\n* [Bazelisk](https://bazel.build/install/bazelisk) or [Bazel](https://bazel.build/install) - if using Bazel, please refer to [.bazelversion](./.bazelversion) file for the recommended version of the tool.\n* [Docker](https://docs.docker.com/get-docker/) - Bazel utilizes Docker to set up the environment using ORFS artifacts from the container.\n  The Docker image used in the flow defaults to `openroad/orfs`, with tag specified in the [module](./MODULE.bazel) file.\n\n  \u003e **NOTE:** The `bazel-orfs` doesn't execute flows inside the Docker container, but rather uses the container as a source of ORFS artifacts.\n* (Optional) Locally built [ORFS](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts). To use it, `env.sh` file from OpenROAD-flow-scripts has to be sourced or `FLOW_HOME` environment variable has to be set to the path of the local `OpenROAD-flow-scripts/flow` installation.\n\n## Usage\n\nCore functionality is implemented as `orfs_flow()` Bazel macro in `openroad.bzl` file.\n\nIn order to use `orfs_flow()` macro in Bazel Workspace in other project it is required to use bazel-orfs as an external dependency through one of [Bazel Module Methods](https://bazel.build/rules/lib/globals/module):\n* from git repository\n\n  ```starlark\n  bazel_dep(name = \"bazel-orfs\")\n  git_override(\n      module_name = \"bazel-orfs\",\n      remote = \"\u003cURL to bazel-orfs repository\u003e\",\n      commit = \"\u003cgit hash for specific bazel-orfs revision\u003e\",\n  )\n  ```\n\n* from local directory\n\n  ```starlark\n  bazel_dep(name = \"bazel-orfs\")\n  local_path_override(\n      module_name = \"bazel-orfs\",\n      path = \"\u003cpath to local bazel-orfs workspace\u003e\",\n  )\n  ```\n\nThe macro can now be placed in the BUILD file. The macro usage can look like this:\n\n```starlark\norfs_flow(\n    name = \"L1MetadataArray\",\n    abstract_stage = \"route\",\n    macros = [\"tag_array_64x184_generate_abstract\"],\n    stage_arguments = {\n        \"synth\": {\n            \"SDC_FILE\": \"$(location :test/constraints-top.sdc)\",\n            \"SYNTH_HIERARCHICAL\": \"1\",\n        },\n        \"floorplan\": {\n            \"CORE_UTILIZATION\": \"3\",\n            \"RTLMP_FLOW\": \"1\",\n            \"CORE_MARGIN\": \"2\",\n            \"MACRO_PLACE_HALO\": \"30 30\",\n        },\n        \"place\": {\n            \"PLACE_DENSITY\": \"0.20\",\n            \"PLACE_PINS_ARGS\": \"-annealing\",\n        },\n    },\n    stage_sources = {\n        \"synth\": [\":test/constraints-top.sdc\"],\n    },\n    verilog_files = [\"test/rtl/L1MetadataArray.sv\"],\n)\n```\n\nThe macro from the example above spawns the following Bazel targets:\n\n```\nDependency targets:\n  //:L1MetadataArray_cts_deps\n  //:L1MetadataArray_floorplan_deps\n  //:L1MetadataArray_generate_abstract_deps\n  //:L1MetadataArray_grt_deps\n  //:L1MetadataArray_place_deps\n  //:L1MetadataArray_route_deps\n  //:L1MetadataArray_synth_deps\n\nStage targets:\n  //:L1MetadataArray_cts\n  //:L1MetadataArray_floorplan\n  //:L1MetadataArray_generate_abstract\n  //:L1MetadataArray_grt\n  //:L1MetadataArray_place\n  //:L1MetadataArray_route\n  //:L1MetadataArray_synth\n```\n\nThe example comes from the [BUILD](./BUILD) file in this repository.\n\nTo test different variants of the same design, the `orfs_flow` can be provided with an optional argument `variant`.\n\n```starlark\norfs_flow(\n    name = \"L1MetadataArray\",\n    abstract_stage = \"route\",\n    macros = [\"tag_array_64x184_generate_abstract\"],\n    # [...]\n    variant = \"test\",\n)\n```\n\nThis definition creates similar Bazel targets with additional variant appended after the design name:\n\n```\nDependency targets:\n  //:L1MetadataArray_test_cts_deps\n  //:L1MetadataArray_test_floorplan_deps\n  ...\n  //:L1MetadataArray_test_generate_abstract_deps\n\nStage targets:\n  //:L1MetadataArray_test_synth\n  //:L1MetadataArray_test_floorplan\n  ...\n  //:L1MetadataArray_test_generate_abstract\n```\n\n## Implementation\n\n### openroad.bzl\n\nThis file contains simple helper functions written in Starlark as well as macro `orfs_flow()`.\nThe implementation of this macro spawns multiple `genrule` native rules which are responsible for preparing and running ORFS physical design flow targets during Bazel build stage.\n\nThese are the genrules spawned in this macro:\n\n* ORFS stage-specific (named: `target_name + “_” + stage` or `target_name + “_” + variant + “_” + stage`)\n* ORFS stage dependencies (named: `target_name + “_” + stage + “_deps”` or `target_name + “_” + variant + “_” + stage + “_deps”`)\n\n### Bazel flow\n\nRegular Bazel flow uses artifacts from the Docker environment with preinstalled ORFS.\n\nIt implicitly depends on a Docker image with ORFS environment pre-installed being present.\nThe Docker image used in the flow is defined in the [module](./MODULE.bazel) file, the default can be overridden by specifying `image` and `sha256` attributes:\n\n```starlark\norfs = use_extension(\"@bazel-orfs//:extension.bzl\", \"orfs_repositories\")\norfs.default(\n    image = \u003cimage\u003e,\n    sha256 = \u003csha256\u003e,\n)\nuse_repo(orfs, \"docker_orfs\")\n```\n\nSetting this attribute to a valid image and checksum will enable Bazel to automatically pull the image and extract ORFS artifacts on `bazel run` or `bazel build`:\n\n```bash\nbazel build \u003ctarget\u003e_\u003cstage\u003e\n```\n\n\u003e **NOTE:** If `sha256` is set to an empty string `\"\"`, Bazel will attempt to use a local image with name provided in the `image` field.\n\n### Local flow\n\nA locally built and modified [ORFS](https://openroad-flow-scripts.readthedocs.io/en/latest/user/UserGuide.html) can also be used to run the flow:\n\n```bash\nbazel run \u003ctarget\u003e_\u003cstage\u003e_deps -- \u003cabsolute_path\u003e\n\u003cabsolute_path\u003e/make do-\u003cstage\u003e\n```\n\nThe `_deps` is used to distinguish between copying the results into the mutable folder for that stage versus copying the required files to execute said stage.\n\nIt is also possible and convenient to run within the sandbox as the arguments after the absolute path are forwarded to make:\n\n```bash\nbazel run \u003ctarget\u003e_\u003cstage\u003e_deps -- \u003cabsolute_path\u003e \u003cmake args...\u003e\n```\n\nTo view the floorplan:\n\n```bash\nbazel run tag_array_64x184_floorplan $(pwd)/tmp gui_floorplan\n```\n\n\u003e **NOTE:** If the directory under the `\u003cabsolute_path\u003e` does not exist, it will be created. If a relative path is provided, the `bazel run` command above will fail.\n\nA convenient way to run the floorplan and view the results would be:\n\n```bash\nbazel run MyDesign_floorplan_deps -- `pwd`/build\nbuild/make do-floorplan\nbuild/make gui_floorplan\n```\n\nBy default, the `make do-\u003cstage\u003e` invocation will rely on the ORFS from [MODULE.bazel](./MODULE.bazel), unless the `env.sh` script is sourced, or the `FLOW_HOME` environment variable is set to the path of the local `OpenROAD-flow-scripts/flow` installation:\n\n```bash\nsource \u003corfs_path\u003e/env.sh\n\nbazel run \u003ctarget\u003e_\u003cstage\u003e_deps -- \u003cabsolute_path\u003e\n\u003cabsolute_path\u003e/make do-\u003cstage\u003e\n```\n\n\u003e **NOTE:** The synthesis stage requires the `do-yosys-canonicalize` and `do-yosys` steps to be completed beforehand.\n\u003e These steps are necessary to generate the required `.rtlil` file for the synthesis stage.\n\u003e\n\u003e ```bash\n\u003e source \u003corfs_path\u003e/env.sh\n\u003e\n\u003e bazel run \u003ctarget\u003e_synth_deps -- \u003cabsolute_path\u003e\n\u003e \u003cabsolute_path\u003e/make do-yosys-canonicalize do-yosys do-synth\n\u003e ```\n\n### Override BUILD configuration variables\n\nConfiguration variables can be overwritten on the command line by passing them in as arguments to the local flow:\n\n```bash\n$ bazel run tag_array_64x184_floorplan $(pwd)/tmp print-CORE_UTILIZATION\n[deleted]\nCORE_UTILIZATION = 40\n```bash\n$ bazel run tag_array_64x184_floorplan $(pwd)/tmp CORE_UTILIZATION=5 print-CORE_UTILIZATION\n[deleted]\nCORE_UTILIZATION = 5\n```\n\n### Stage targets\n\nEach stage of the physical design flow is represented by a separate target and follows the naming convention: `target_name + “_” + stage`.\n\nThe stages are as follows:\n\n* `synth` (synthesis)\n* `floorplan`\n* `place`\n* `cts` (clock tree synthesis)\n* `grt` (global route)\n* `route`\n* `final`\n* `generate_abstract`\n\n### Generate abstract targets\n\nThose targets are used to create abstracts (`.lef` and `.lib` files) for macros.\n\nAbstracts are generated at the `target + \"generate_abstract\"` stage, which follows one defined via `abstract_stage` attribute passed to the `orfs_flow()` macro:\n\n\u003cpre lang=\"starlark\"\u003e\norfs_flow(\n    name = \"tag_array_64x184\",\n    \u003cb\u003eabstract_stage = \"floorplan\",\u003c/b\u003e\n    stage_arguments = {\n        \"synth\": SRAM_SYNTH_ARGUMENTS,\n        \"floorplan\": SRAM_FLOOR_PLACE_ARGUMENTS | {\n            \"CORE_UTILIZATION\": \"40\",\n            \"CORE_ASPECT_RATIO\": \"2\",\n        },\n        \"place\": SRAM_FLOOR_PLACE_ARGUMENTS | {\n            \"PLACE_DENSITY\": \"0.65\",\n        },\n    },\n    stage_sources = {\n        \"synth\": [\":constraints-sram\"],\n        \"floorplan\": [\":io-sram\"],\n        \"place\": [\":io-sram\"],\n    },\n    verilog_files = [\"//another:tag_array_64x184.sv\"],\n    visibility = [\":__subpackages__\"],\n)\n\u003c/pre\u003e\n\nBy default it's the latest ORFS-specific target (`final`).\n\n\u003e **NOTE:** Abstracts can be generated starting from the `floorplan` stage, thus skipping the `synth` stage.\n\nAbstracts are intended to be used in builds of other parts of the design that use the given macro.\nThey're useful for estimating sizes of macros with long build times and checking if they will fit in upper-level modules without running time consuming place and route flow.\n\n\u003e **NOTE:** Stages that follow the one passed to `abstract_stage` will not be created by the `orfs_flow()` macro.\n\n### Mock area targets\n\nMock area targets are created on top of the stage targets and overrides `_generate_abstract` target to produced mocked abstracts.\n\nThe flow contains:\n* `target_name_variant + “_synth_mock_area”` - synthesis which has its whole internal logic removed,\n* `target_name_variant + “_mock_area”` - reads `DIE_AREA` and `CORE_AREA` from default floorplan results and scale them by value defined in `mock_area`,\n* `target_name_variant + “_floorplan_mock_area”` - floorplan with overridden `DIE_AREA` and `CORE_AREA` values,\n* `target_name_variant + “_generate_abstract”` - abstracts generated based on mocked synthesis and floorplan.\n\nTo create mock area targets, `mock_area` has to be added to `orfs_flow` definition:\n\n```starlark\norfs_flow(\n    name = \"lb_32x128\",\n    stage_arguments = LB_STAGE_ARGS,\n    stage_sources = LB_STAGE_SOURCES,\n    verilog_files = LB_VERILOG_FILES,\n    mock_area = 0.5,\n)\n```\n\nThe mock has the same pinout as the original macro and similar size which makes it useful in early design stages.\n\n### Constraints handling\n\nConstraint files are passed down to `orfs_flow()` macro through [Stage targets](#stage-targets) arguments and sources:\n\n\u003cpre lang=\"starlark\"\u003e\norfs_flow(\n    name = \"tag_array_64x184\",\n    abstract_stage = \"synth\",\n    \u003cb\u003estage_arguments = {\n        \"synth\": {\n            \"SDC_FILE\": \"$(location :constraints-sram)\",\n        },\n    },\n    stage_sources = {\n        \"synth\": [\":constraints-sram\"],\n    },\u003c/b\u003e\n    verilog_files = [\"//another:tag_array_64x184.sv\"],\n    visibility = [\":__subpackages__\"],\n)\n\u003c/pre\u003e\n\nThose accept a Bazel label that points to the file.\nThere are however cases, where e.g. SRAM constraints file includes additional TCL script.\nIn such scenario a filegroup should also define the `data` attribute with the additional script.\n\n\u003cpre lang=\"starlark\"\u003e\nfilegroup(\n    name = \"constraints-sram\",\n    srcs = [\n        \":test/constraints-sram.sdc\",\n    ],\n    \u003cb\u003edata = [\n        \":test/util.tcl\",\n    ],\u003c/b\u003e\n    visibility = [\":__subpackages__\"],\n)\n\u003c/pre\u003e\n\n### Dependency targets\n\nThe dependency targets fall under the `target_name + “_” + variant + “_” +stage + “_deps”` naming convention, and are used to prepare the environment for running the ORFS stage targets.\nEach stage of the physical design flow depend on two generated `.mk` files that provide the configuration for the ORFS.\nOne is specific for the stage of the flow and the second one is common for the whole design being built.\n\nThey can be found under the following paths:\n\n```bash\n\u003cpath\u003e/config.mk                                                             # Common for the whole design\n\u003cpath\u003e/results/\u003cmodule\u003e/\u003ctarget\u003e/\u003cvariant\u003e/\u003cstage_number\u003e_\u003cstage\u003e.short.mk   # Specific for the stage\n```\n\nAdditionally, the dependency targets are responsible for constraints handling and generating the shell scripts that are used to run the ORFS stages both in the Bazel and Local flow:\n\n```bash\n\u003cpath\u003e/make     # Running the ORFS stages\n\u003cpath\u003e/results  # Directory for the results of the flow\n\u003cpath\u003e/external # Directory for the external dependencies\n```\n\n### GUI targets\n\nThe GUI and CLI targets can only be run from the generated shell script.\n\nFor the GUI:\n\n```bash\nbazel run \u003ctarget\u003e_\u003cstage\u003e -- \u003cabsolute_path\u003e\n\u003cabsolute_path\u003e/make gui_\u003cstage\u003e\n```\n\nFor the CLI:\n\n```bash\nbazel run \u003ctarget\u003e_\u003cstage\u003e -- \u003cabsolute_path\u003e\n\u003cabsolute_path\u003e/make open_\u003cstage\u003e\n```\n\nCLI and GUI is not available for all stages, consequently these targets are created only for:\n\n* `floorplan`\n* `place`\n* `cts` (clock tree synthesis)\n* `grt` (global route)\n* `route`\n* `final`\n\n## Tutorial\n\nTo execute the build flow for the `cts` (Clock Tree Synthesis) stage of the `L1MetadataArray` target, use the following command:\n\n```bash\nbazel run @bazel-orfs//:L1MetadataArray_cts -- `pwd`/build\n```\n\nBazel will automatically download the Docker image with the ORFS environment and run the flow.\n\nThis will build the `L1MetadataArray` target up to the `cts` stage and place the results in the `build/results` directory.\nIt's important to provide an absolute path to the directory where the flow artifacts will be stored.\n\n### Dependencies in ORFS Makefile versus Bazel\n\nWhen using bazel-orfs, the dependency checking is done by Bazel instead of ORFS's makefile, with the exception of the synthesis canonicalization stage.\n\nORFS `make do-yosys-canonicalize` is special and will do dependency checking using ORFS `Makefile` and output `$(RESULTS_DIR)/1_synth.rtlil`.\n\nThe `.rtlil` is Yosys's internal representation format of all the various input files that went into Yosys, however any unused modules have been deleted and the modules are in canonical form(ordering of the Verilog files provided to Yosys won't matter). However, `.rtlil` still contains line number information for debugging purposes. The canonicalization stage is quick compared to synthesis and adds no measurable overhead.\n\nCanonicalization simplifies specifying `VERILOG_FILES` to ORFS in Bazel, simply glob them all and let Yosys figure out which files are actually used. This avoids redoing synthesis unnecessarily if, for instance, a Verilog file related to simulation changes.\n\nThe next stage is `make do-yosys` which does no dependency checking, leaving it to Bazel. `do-yosys` completes the synthesis using `$(RESULTS_DIR)/1_synth.rtlil`.\n\nThe subsequent ORFS stages are run with `make do-floorplan do-place ...` and these stages do no dependency checking, leaving it to Bazel.\n\nbazel-orfs also does dependency checking of options provided to each stage. If a property to CTS is changed, then no steps ahead of CTS is re-run. bazel-orfs does not know which properties belong to which stage, it is the responsibility of the user to pass properties to the correct stage. This includes some slightly surprising responsibilities, such as passing IO pin constraints to both floorplan and placement.\n\n### Using the local flow\n\nThe local flow allows testing the build with locally built OpenROAD-flow-scripts.\nIt is based on Bazel `make` targets, for more information on those, please refer to [Dependency targets](#dependency-targets) paragraph.\n\nLet's assume we want to perform a `floorplan` stage for the `L1MetadataArray` design using the locally built ORFS.\n\n1. Source `env.sh` of your local ORFS installation or set the `FLOW_HOME` environment variable to the path to your local `OpenROAD-flow-scripts/flow` directory:\n\n  ```bash\n  source \u003cORFS_path\u003e/env.sh\n  # Or\n  export FLOW_HOME=\u003cORFS_path\u003e/flow\n  ```\n\n2. Build the stages prior to the `floorplan` stage:\n\n  ```bash\n  # Initialize dependencies for the Synthesis stage for L1MetadataArray target\n  bazel run @bazel-orfs//:L1MetadataArray_synth_deps -- `pwd`/build\n\n  # Build Synthesis stage for L1MetadataArray target using local ORFS\n  build/make do-yosys-canonicalize do-yosys do-synth\n\n  # Initialize dependencies for the Floorplan stage for L1MetadataArray target\n  bazel run @bazel-orfs//:L1MetadataArray_floorplan_deps -- `pwd`/build\n  ```\n\n3. Execute the shell script with ORFS make target relevant to given stage of the flow:\n\n  ```bash\n  build/make do-floorplan\n  ```\n\n### Running OpenROAD GUI\n\nLet's assume we want to run a GUI for the `route` stage for the `L1MetadataArray` target.\n\n1. Initialize and build stages up to the `route` stage:\n\n  ```bash\n  bazel run @bazel-orfs//:L1MetadataArray_route -- `pwd`/build\n  ```\n\n2. Execute the GUI shell script:\n\n  ```bash\n  # Start the GUI for the Route stage for L1MetadataArray target\n  build/make gui_route\n\n  # Or open the GUI through the CLI\n  build/make open_route\n  gui::show\n  ```\n\n### Tweaking aspect ratio of a floorplan\n\nNotice how the `CORE_ASPECT_RATIO` parameter is associated with\nthe floorplan and *only* the floorplan stage below:\n\n```diff\ndiff --git a/BUILD b/BUILD\nindex 095d63b..4b78dea 100644\n--- a/BUILD\n+++ b/BUILD\n@@ -74,7 +74,7 @@ orfs_flow(\n         \"synth\": SRAM_SYNTH_ARGUMENTS,\n         \"floorplan\": SRAM_FLOOR_PLACE_ARGUMENTS | {\n             \"CORE_UTILIZATION\": \"40\",\n-            \"CORE_ASPECT_RATIO\": \"2\",\n+            \"CORE_ASPECT_RATIO\": \"4\",\n         },\n         \"place\": SRAM_FLOOR_PLACE_ARGUMENTS | {\n             \"PLACE_DENSITY\": \"0.65\",\n```\n\nBazel will detect this change specifically as a change to the floorplan, re-use the synthesis result and rebuild from the floorplan stage.\nSimilarly, if the `PLACE_DENSITY` is modified, only stages from the placement and on are re-built.\n\nTo apply and view the changes:\n\n```bash\n# Build tag_array_64x184 macro up to the floorplan stage\nbazel run @bazel-orfs//:tag_array_64x184_floorplan -- `pwd`/build\n\n# View final results from GUI\nbuild/make gui_floorplan\n```\n\nIf the remote caching is enabled for Bazel, reverting the change and rebuilding the floorplan stage will be completed instantaneously, as the artifact already exists:\n\n```bash\n# Revert the change\ngit restore BUILD\n\n# Rebuild the floorplan stage\nbazel run @bazel-orfs//:tag_array_64x184_floorplan -- `pwd`/build\n\n# View final results from GUI\nbuild/make gui_floorplan\n```\n\n### Fast floorplanning and mock abstracts\n\nLet's say we want to skip place, cts and route and create a mock abstract where we can at least check that there is enough place for the macros at the top level.\n\n\u003e **WARNING:** Although mock abstracts can speed up turnaround times, skipping place, cts or route can lead to errors and problems that don't exist when place, cts and route are not skipped.\n\nTo do so, we modify in `BUILD` file the `abstract_stage` attribute of `orfs_flow` macro to `floorplan` stage:\n\n```diff\ndiff --git a/BUILD b/BUILD\nindex 095d63b..9756fbf 100644\n--- a/BUILD\n+++ b/BUILD\n@@ -110,7 +110,7 @@ orfs_flow(\n\n orfs_flow(\n     name = \"L1MetadataArray\",\n-    abstract_stage = \"route\",\n+    abstract_stage = \"floorplan\",\n     macros = [\"tag_array_64x184_generate_abstract\"],\n     stage_arguments = {\n         \"synth\": {\n```\n\nThis will generate targets that can be verified in the `bazel query` output:\n\n```bash\nbazel query '...:*' | grep 'L1MetadataArray'\n\n//:L1MetadataArray_synth_deps\n//:L1MetadataArray_synth\n//:L1MetadataArray_floorplan_deps\n//:L1MetadataArray_floorplan\n//:L1MetadataArray_generate_abstract\n```\n\nThe abstract stage follows the one defined via `abstract_stage` attribute passed to the `orfs_flow()` macro.\nHowever it always falls down to the `\u003ctarget\u003e_generate_abstract` pattern and can be built with the following command:\n\n```bash\nbazel build @bazel-orfs//:L1MetadataArray_generate_abstract\n```\n\nThis will cause the Bazel to generate the abstracts for the design right after the `floorplan` stage instead of `route` stage.\nThe output `LEF` file can be found under the `bazel-bin/results/\u003cmodule\u003e/\u003ctarget\u003e/base/\u003ctarget.lef\u003e` path.\n\nFor more information please refer to the description of [Abstract targets](#generate-abstract-targets).\n\n## Bazel hacking\n\n### Run all synth targets\n\n```bash\nbazel query :\\* | grep '_synth$' | xargs -I {} bazel run {} -- `pwd`/build\n```\n\nThis will run all synth targets in the workspace and place the results in the `build/results` directory.\n\n### Forcing a rebuild of a stage\n\nSometimes it is desirable, such as when hacking ORFS, to redo a build stage even\nif none of the dependencies for that stage changed. This can be achieved by changing\na `PHONY` variable to that stage and bumping it:\n\n```diff\ndiff --git a/BUILD b/BUILD\nindex 095d63b..5b618ba 100644\n--- a/BUILD\n+++ b/BUILD\n@@ -114,6 +114,7 @@ orfs_flow(\n     name = \"L1MetadataArray\",\n     abstract_stage = \"route\",\n     macros = [\"tag_array_64x184_generate_abstract\"],\n     stage_arguments = {\n         \"synth\": {\n+            \"PHONY\": \"1\",\n             \"SDC_FILE\": \"$(location :test/constraints-top.sdc)\",\n             \"SYNTH_HIERARCHICAL\": \"1\",\n         },\n```\n\n### Building the immediate dependencies of a target\n\n```bash\nbazel build @bazel-orfs//:L1MetadataArray_synth_deps\n```\n\nThis will build the immediate dependencies of the `L1MetadataArray` target up to the `synth` stage and place the results in the `bazel-bin` directory.\nLater, those dependencies will be used by Bazel to build the `synth` stage for `L1MetadataArray` target.\n\n### Tools location after `bazel run ...`\n\nA mutable build folder can be set up to prepare for a local synthesis run, useful when digging into some detail of synthesis flow:\n\n    $ bazel build tag_array_64x184_synth_deps -- `pwd`/build\n    $ build/make print-YOSYS_EXE\n    YOSYS_EXE = external/_main~orfs_repositories~docker_orfs/OpenROAD-flow-scripts/tools/install/yosys/bin/yosys\n\nThis is actually a symlink pointing to the read only executables, which is how yosys is able to find the yosys-abc alongside itself needed for the abc part of the synthesis stage:\n\n    $ ls -l $(dirname $(readlink -f build/external/_main~orfs_repositories~docker_orfs/OpenROAD-flow-scripts/tools/install/yosys/bin/yosys))\n    total 37456\n    -rwxr-xr-x 1 oyvind oyvind 23449673 Aug 15 07:05 yosys\n    -rwxr-xr-x 1 oyvind oyvind 14725193 Aug 15 07:05 yosys-abc\n    -rwxr-xr-x 1 oyvind oyvind     3904 Aug  7 23:11 yosys-config\n    -rwxr-xr-x 1 oyvind oyvind    65609 Aug 15 07:05 yosys-filterlib\n    -rwxr-xr-x 1 oyvind oyvind    73845 Aug  7 23:11 yosys-smtbmc\n    -rwxr-xr-x 1 oyvind oyvind    17377 Aug  7 23:11 yosys-witness\n\n### `make issue` floorplan example\n\nTo create and test a `make issue` archive for floorplan:\n\n    bazel run lb_32x128_floorplan_deps `pwd`/build\n    build/make ISSUE_TAG=test floorplan_issue\n\nThis results in `build/floorplan_test.tar.gz`, which can be run provided there `openroad` application is in the path.\n\nA local ORFS installation can be used by running `source env.sh`.\n\nAlternatively, the ORFS installation used with Bazel, can be used by using `make bash` to set up the environment of the ORFS extracted into the Bazel build environment:\n\n    build/make bash\n    export PATH=$PATH:$(realpath $(dirname $(readlink -f $OPENROAD_EXE)))\n    tar --strip-components=1 -xzf ../floorplan_test.tar.gz\n    ./run-me-lb_32x128-asap7-base.sh\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthe-openroad-project%2Fbazel-orfs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fthe-openroad-project%2Fbazel-orfs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthe-openroad-project%2Fbazel-orfs/lists"}