From 651519ffb5599fac9ab612c429fea85d318b7660 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=98yvind=20Harboe?= Date: Fri, 10 May 2024 13:51:44 +0200 Subject: [PATCH] README: some generic blurb moved in from megaboom MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Øyvind Harboe --- README.md | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git a/README.md b/README.md index d2026a04..471ba609 100644 --- a/README.md +++ b/README.md @@ -5,6 +5,77 @@ This repository contains [Bazel](https://bazel.build/) rules for wrapping Physic * Docker flow - based on ORFS installed in the docker container that is used for running bazel targets * Local flow - relies on local installation of the ORFS +There are many build flows on top of OpenROAD +--------------------------------------------- + +There are numerous build flows on top of OpenROAD, these are some: + +- ORFS. The developers of OpenROAD use this flow + to test the tool. It has features specifically for reporting bugs and + is simple to understand for OpenROAD developers as well as novice + users. It provides a lingua franca in the community to discuss features + and test cases. +- [Hammer](https://chipyard.readthedocs.io/en/latest/VLSI/Hammer.html) is used with + Chipyard. +- https://www.zeroasic.com/ has a Python based workflow that supports both + commercial tools and OpenROAD. + +Why Bazel on top of ORFS? +------------------------- + +ORFS and OpenROAD is work in progress and one should expect for +large designs to get involved with the community or need a +support contract with Precision Innovations (https://www.linkedin.com/in/tomspyrou/). + +Using ORFS directly, instead of modifying it or creating an alternative flow, +makes it easy to get the very latest features and version of OpenROAD and ORFS +as well as having access to the tools, `make issue` and `deltaDebug.py`, +required to articulate familiar and easily actionable github issues for +the OpenROAD and ORFS maintainers. + +Challenges with large designs and ORFS that Bazel helps address +--------------------------------------------------------------- + +- **Long build times**; hours, days. +- **Artifacts** are needed. Synthesis, for instance, can + be very time consuming and it is useful to share synthesis artifacts + between developers and CI servers. On a large design with multiple + developers and many pull requests in flight, it can become error + prone to manually track exactly what version of built stages that + are still valid. Ideally one should be able to check out a + pull request and automatically get the right prebuilt artifacts. +- **Dependencies** in ORFS are at the file level. For instance, synthesis must be + redone if the clock period changes, but many other changes to .sdc do not require + resynthesis. With finer grained dependencies, superfluous time consuming + resynthesis, floor planning, placement, cts and routing can be avoided. +- **Examining failures** for global/detailed place/route, that can take many + hours to build, is useful. Artifacts for failed stages are needed to + examine the problem: failed .odb file as well as any reports. This workflow + always existed for detailed routing: detailed routing succeeds, has exit code 0, + even if there are DRC errors. +- **Mocking abstracts** when doing initial top-level floorplanning is needed to + separate concerns. It can be useful to skip one of place, cts, route for + the macros until one starts to converge on a workable + top level floorplan. This is supported via `mock_abstract` in `openroad.bzl` +- **Efficient local storage of build artifacts** are needed as .odb files are + large and they should not exist in duplicates unnecessarily. Bazel + uses symbolic links. ORFS can not use symbolic links for .odb files because, + long story short, `make` does not work properly with symbolic links. This becomes + especially important when working with many branches and pull requests where + there is a large degree of shared .odb files. +- **Parallel builds** are required for macros. +- **Remote build services** are required for large projects where + developers machines are powerful enough to examine results, but + not to run builds. +- **Cross cutting builds** such as completing floor planning for all macros, + then place, then cts, then route is required to be able to separate concerns. + When iterating on the concerns, it can be useful to complete placement under + human supervision to iterate quickly, but to leave routing for CI servers to complete. +- **Select level of detail of artifacts** is useful throughout the + development process. Initially for a macro, artifacts are useful for inspection + for synthesis, floorplan, place, cts, route and abstract. Later, for stable macros, + abstracts are adequate(no .odb file, only .lef, .lib and .gds). + ## Requirements * [Bazelisk](https://bazel.build/install/bazelisk) or [Bazel](https://bazel.build/install) - if using `bazel`, please refer to `.bazelversion` file for the recommended version of the tool.