The OpenROAD project contains a specific repository that defines a set of useful actions that can be triggered to implement several valuable functions. Refer to the repository https://github.com/The-OpenROAD-Project/actions. The README.md file lists the actions provided for various useful functions that can be applied to the OpenROAD project repositories.

One such function is openlane_run. The action is defined here: https://github.com/The-OpenROAD-Project/actions/blob/main/openlane_run/action.yml

openlane_run

This action aims to automatically run a given design through the OpenLane flow. This is useful when a user pushes a commit to a design in the repository. This action will automatically trigger a complete run of the OpenLane flow on the design using the specified ol_tag as shown in the following usage description. This feature can also test the design against newly released OpenLane tags and keep track of the last known stable tag. Specific tools may also be updated to the latest version, which will trigger an automatic re-run of the OL. Designers can thus ensure a working version of their designs in OpenLane at all times.

Optionally a PR can be created to update a stable tag file stored in the repository. Arguments:

  • ol_tag [optional, default: master]: OpenLane tag. You can set to ol_tag_file to use the value from the file content.
  • update_tag [optional, default: false]: if the test is successful update stable tag pointed by the ol_tag_file input.
  • ol_tag_file [optional, default: .github/openlane-stable-tag]: File where to store stable OpenLane tag. The file must exist before running with this feature.
  • tools_list [optional, default: ]: List of tools to update to the latest version. Multiple values are separated by a space, e.g., “openroad_app magic”.

Use Model

You will need a GitHub repository with the source code for your design and a valid OpenLane config.tcl file to include and enforce this action. We provide a sample GitHub repository here that showcases the three most common use models. The repository contains the source code for the spm design (copied over from the OpenLane repository) with its config.tcl file.

The openlane-stable.yml workflow will trigger on every push to the repository, thus testing the design source code change.

The openlane-latest.yml workflow will trigger on every push and every day at 10 pm UTC. This workflow ensures that new OpenLane releases work for your design. If all tests are green, a PR will be created to update the stable tag.

The openlane-latest-or-latest.yml will trigger on every push and every day at 10 pm UTC. This workflow is intended for those who wish to test their design with the latest release of a tool, in this example, OpenROAD app.

To add a workflow to your repository, you can start copying the sample workflow file here. You must use the same folder structure (i.e., .github/workflows/). After adding the workflow file, you will need to commit and push your changes to GitHub.

$ cd

$ mkdir -p .github/workflows/

$ cd .github/workflows/

$ wget https://raw.githubusercontent.com/The-OpenROAD-Project/actions-test/main/.github/workflows/openlane-latest.yml

$ wget https://raw.githubusercontent.com/The-OpenROAD-Project/actions-test/main/.github/workflows/openlane-stable.yml

$ wget https://raw.githubusercontent.com/The-OpenROAD-Project/actions-test/main/.github/workflows/openlane-latest-or-latest.yml

$ git commit -m ‘Add workflows’ .

$ git push

The final step is to enable the action for your repository; see GitHub docs here. Note that GitHub actions are free and unlimited only for public repositories. You can also manually trigger runs using the GitHub action dispatch feature; see GitHub documentation here.