Tutorial insight

MPW Designs in OpenROAD CI Improve Quality for Everyone

OpenROAD’s Jenkins-powered continuous integration keeps the flow stable by exercising real shuttle submissions, catching issues before they reach designers relying on OpenLane and SkyWater shuttles.

OpenROAD™ treats quality as a first-class feature. Every commit runs through a Google Cloud Platform-based Jenkins farm that continually validates functionality, QoR, and runtime. The objectives are simple:

  • Exercise a broad spectrum of design sizes and hierarchies.
  • Catch regressions and code-quality issues as early as possible.

Continuous integration pipeline

The CI system (see jenkins.openroad.tools) runs unit tests at the tool level and flow-level regressions that track key metrics—mirroring the Metrics4ML definitions surfaced on the OpenROAD dashboard. Dynamic code coverage and Coverity static analysis add another layer of safety before changes merge.

Running these workloads in the cloud ensures developers get feedback quickly, even as the project scales to full 24-hour, no-human-in-loop RTL→GDSII runs.

Why MPW designs matter

OpenLane and OpenROAD power hundreds of Efabless multi-project wafer (MPW) tape-outs. To keep that flow reliable, production-proven designs from Google’s shuttle program are periodically promoted into the public regression suite.

Explore the repository at github.com/The-OpenROAD-Project/OpenLane-MPW-CI. At the time of writing it houses more than 80 projects—roughly 72% of MPW shuttle submissions from runs 2–4—covering everything from simple logic to macro-heavy SoCs.

How to contribute

Designers can submit their own projects via pull requests. By donating representative workloads you help OpenROAD catch corner cases sooner, improve QoR over time, and ensure each new shuttle run benefits from stronger tooling.