openroad | UCSC OSPO

Final Blog: Rectilinear Floorplans in OpenROAD

Wed, 22 Oct 2025 00:00:00 +0000

Final Progress: Enabling Rectilinear Floorplanning in OpenROAD

Hello! I’m excited to share my final progress on implementing rectilinear (polygonal) die support in OpenROAD’s floorplanning flow as part of Google Summer of Code 2025. Under the guidance of my mentors Eder Monteiro and Augusto Berndt, we’ve made significant strides in extending OpenROAD to handle non-rectangular die shapes.

Here’s a link to my original proposal

Project Overview

This project aims to add support for rectilinear floorplans in OpenROAD, an open-source EDA tool used for digital chip design. Currently, OpenROAD only supports rectangular floorplans, which limits its use in modern designs that often require more complex shapes, especially in advanced packaging, chiplet architectures, and 3D ICs.

The project enables users to define floorplans using arbitrary rectilinear shapes made of $90^{\circ}$ corners. It involves three main components:

Accepting polygonal input during floorplan setup
Generating standard cell rows and routing tracks that follow the shape boundaries
Updating pin placement logic to work with irregular outlines

By enabling these capabilities, OpenROAD becomes more flexible and suitable for real-world designs where blocks may need to fit together like puzzle pieces. This can lead to better area utilization and potentially shorter interconnects.

The core challenge is maintaining robustness and backward compatibility while introducing this major new feature that touches multiple aspects of the design flow.

Pull Requests made

Support for Rectilinear dies in PPL (Pin Placement) - https://github.com/The-OpenROAD-Project/OpenROAD/pull/8182
Support for Rectilinear dies in IFP (Init Floorplan) - https://github.com/The-OpenROAD-Project/OpenROAD/pull/7893

Key Contributions

Phase 1: Init Floorplan (IFP) Module Support

The first half of the project focused on adding support for rectilinear floorplans in the IFP (Init Floorplan) module. This foundational work established the infrastructure for handling non-rectangular die shapes.

1. Polygonal Die Definition

Implemented support for accepting polygon vertices as input to define rectilinear die shapes.
Modified the TCL interfaces to accept a list of vertices of the rectilinear die in the -die_area and -core_area parameters and automatically switch to rectilinear flow.
Developed validation logic to ensure polygons are rectilinear and valid.

2. Standard Cell Row Generation

Developed a scanline-based algorithm to generate standard cell rows that conform to complex polygonal boundaries.
The algorithm sweeps horizontally across the die area and identifies valid row regions within the polygon.
Routing Track generation logic could directly be used for rectilinear die shapes.

3. Testing and Validation

Created comprehensive test cases for L-shaped, T-shaped, and other rectilinear configurations for floorplan creation and row generation.
Ensured backward compatibility with rectangular floorplans.
Added error handling for edge cases like invalid polygon specifications.

Demo: U-Shaped Die Row Generation

One of our test cases involved generating rows for a U-shaped die. Here is a snapshot from the OpenROAD GUI displaying perfectly laid out rows:

Phase 2: Pin Placement (PPL) Module Support

1. Core Data Structure Migration

Leveraged the odb::Line class instead of the simple Edge enum (which only handled 4 rectangular edges) to store edge data of rectilinear dies. This allows the system to handle an arbitrary number of polygon edges.
This required refactoring nearly every function in the pin placement pipeline, as the Edge enum was deeply embedded throughout the codebase.
The new representation is more flexible and can handle N-sided polygons while maintaining clean abstractions.

2. Pin Slot Calculation

Rewrote the defineSlots() function family to work with polygon edges while maintaining compatibility with existing die shapes.
Ensured slots are generated only within valid polygon boundaries.

3. Pin Orientation Algorithm

One of the most challenging aspects was determining the correct orientation for pins on polygon edges. For rectangular dies, this is trivial, but for complex, concave polygons, it’s non-trivial.
Leveraged the ray tracing algorithm to determine the correct pin orientations. The algorithm casts rays from edge midpoints to determine which side faces the interior of the polygon.
This ensures pins are correctly oriented and handles complex cases like concave polygons.

4. Hungarian Matching and Simulated Annealing for Polygons

Successfully extended both Hungarian Matching and Simulated Annealing to work with rectilinear dies as well as regular dies.
The flow now checks if the provided die is rectilinear and intelligently switches the flow accordingly.

Demo: T-Shaped Die Pin Placement

The image below shows pins placed on a rectilinear, T-shaped die:

Code Quality

Followed OpenROAD coding standards and conventions
Comprehensive error handling and validation
Extensive code reviews with multiple rounds of refinements
Well-documented functions and algorithms

Testing and Validation

Created multiple test cases covering various rectilinear shapes
Regression testing to ensure backward compatibility
Edge case handling (concave polygons, tight geometries, etc.)
Integration testing with downstream OpenROAD flows

Future Work

Supporting constraints for pin placement in PPL - currently in progress
Improved GUI support for viewing and editing polygonal floorplans
Further optimizing algorithms for very large polygons

Acknowledgements

I would like to thank my mentors, Eder Monteiro and Augusto Berndt for their patience, support and guidance throughout the project. Thanks to Stephanie and the entire UC OSPO team as well as Google Summer of Code for providing me with this incredible opportunity.

Mid-term Blog: Rectilinear Floorplans in OpenROAD - Progress Update

Sun, 03 Aug 2025 00:00:00 +0000

Mid-term Progress: Enabling Rectilinear Floorplanning in OpenROAD

Hello! I’m excited to share my mid-term progress on implementing rectilinear (polygonal) die support in OpenROAD’s floorplanning flow as part of Google Summer of Code 2025. Under the guidance of my mentors Eder Monteiro and Augusto Berndt, we’ve made significant strides in extending OpenROAD to handle non-rectangular die shapes.

Here’s a link to my original proposal

Project Overview

My project focuses on extending OpenROAD’s floorplanning capabilities to support rectilinear die shapes. This enhancement is crucial for modern VLSI design flows involving advanced packaging, 2.5D/3D ICs, and irregular chiplet-based designs where non-rectangular dies are increasingly common.

The core challenge is maintaining robustness and backward compatibility while introducing this major new feature that touches multiple aspects of the design flow.

Progress Made

1. Tcl Frontend modification and Input Parsing

Successfully extended the Tcl interface to accept rectilinear die specifications:

The initialize_floorplan command can now accept a list of coordinates specifying a polygon and automatically trigger the rectilinear floorplanning flow.
Added robust input validation for rectilinear coordinates
Ensured backward compatibility with existing rectangular floorplan flows

2. Die creation and Validation

Leveraged the internal structure odb::Polygon to store the vertices of the shape.
Implemented polygon validation to ensure shapes are valid rectilinear polygons
Added proper error handling and user feedback for invalid polygon inputs

3. Row Generation for rectilinear Dies - Major Milestone

The most significant achievement has been implementing the make_polygon_rows functionality, which generates standard cell rows that conform to the rectilinear die boundaries. This was one of the most challenging aspects of the project. To solve this, we developed an efficient scanline-based approach to fill rectilinear areas with rows by clipping the row lengths according the the boundary of the shape supplied.

4. Testing and Validation

Tests were added to the regression suite and were used to successfully test the entire initialize_floorplan flow. The changes made were merged into OpenROAD successfully. PR Link

makeRows demo :

One of our test cases involved generating rows for a U-shaped die. Here is a snapshot from the OpenROAD gui displaying perfectly laid out rows:

Next Steps

I am currently working on the pin placer (ppl) module and extending it to support rectilinear floorplans. This requires a careful re-evaluation of each step, including the cost function used to optimize pin placement.

Rectilinear Floorplans in OpenROAD

Thu, 10 Jul 2025 00:00:00 +0000

Google Summer of Code ‘25: Enabling Rectilinear Floorplanning in OpenROAD

This summer, under the guidance of my mentors Eder Monteiro and Augusto Berndt at the OpenROAD project, I am implementing support for polygonal (specifically rectilinear) die shapes in OpenROAD’s floorplanning flow.

Here’s a link to my original proposal

What is OpenROAD and why polygonal floorplans?

OpenROAD is a fully autonomous RTL-to-GDS digital layout toolchain. The OpenROAD flow delivers an Autonomous, No-Human-In-Loop (NHIL) flow, 24 hour turnaround from RTL-GDSII for rapid design exploration and physical design implementation.

Until now, OpenROAD primarily supported rectangular die shapes in its floorplanning. This limits its use for advanced packaging, 2.5D/3D ICs, or irregular chiplet-based designs, where non-rectangular dies are increasingly common.

By extending the floorplanner to handle rectilinear (non-manhattan, but still axis-aligned) dies, we open the door for a broader class of cutting-edge VLSI layouts.

Motivation and what gap does this fill?

From my background in electronics engineering, I’ve seen that advanced packaging hsd been unusual die shapes, whether for stacking, interposers, or simply to optimize area and thermal profiles.

Right now, OpenROAD’s inability to handle these non-rectangular dies is a blocker for certain modern flows. My project directly addresses this by:

Extending the Tcl and internal APIs to accept and validate polygonal die/core shapes.
Modifying the row generation and site placement algorithms to conform to polygonal boundaries.
Ensuring that all downstream modules (global placement, detailed placement, routing) can consume the new floorplan data structures without any issues.

My approach & engineering plan

My work focuses on maintaining robustness and backward compatibility, while introducing this major new feature.

Floorplan Input: Users can now specify die/core shapes as sequences of x/y coordinates (-die_polygon and -core_polygon) directly from the Tcl interface.
Data structures: Extend OpenROAD’s internal representations to store arbitrary rectilinear polygons and propagate these safely through the design pipeline.
Row Generation: Develop a new functions (make_polygon_rows) to fill polygonal die areas with standard cell rows, properly clipped to the die shape.
Verification: Build rigorous regression and sanity checks. This includes both internal checks and external DEF writeouts that can be visualized in other tools.
Testing & Benchmarks: Prepare a suite of testcases (including complex T-shaped and L-shaped dies) to validate correctness.

I’m especially careful to keep the existing rectangular flow untouched. The new features only engage when the user explicitly specifies polygonal options.

Acknowledgments

I’m deeply grateful to my mentors from the OpenROAD community who have given invaluable guidance - Eder Monteiro and Augusto Berndt. I’m also excited to contribute this to an open-source EDA project that’s shaping the future of accessible hardware design.

Memory Compiler in OpenROAD

Thu, 13 Jun 2024 00:00:00 +0000

Greetings! I’m Yash Kumar working on the OpenROAD Memory Compiler Project for which my proposal under the mentorship of Matt and Austin aims to enhance the OpenROAD flow by integrating a DFFRAM generator that extensively uses the OpenDB database to build and layout various memory components like bits, bytes, and 32x32 configurations and more. Taking inspiration from the work of the AUCOHL repository’s DFFRAM memory compiler,

The goal is to develop a DFF/Latch-based RAM that utilizes standard cell libraries. The compiler will generate different views (HDL netlist, functional models, LEF, DEF, Timing, etc.) for specified size configurations, targeting compact design and optimal routing. The compiler should work across various PDKs satrting with Sky130. My initial works tries to test the Bit and Byte level design.