Feature request: Support for polygonal macro cell outlines.

[WRansohoff]

It looks like the DEF file format allows for polygonal DIEAREA configurations, which can be used to define macro cells with simple shaped outlines.

When a non-rectangular outline is passed into the OpenROAD tools by reading a .def file, it appears to be ignored in favor of a rectangular bounding box.

Would it be possible to add support for polygonal or rectilinear outlines, particularly in non-core designs? Here is a minimal example of a macro cell template whose shape does not appear to be currently supported:

VERSION 5.8 ;
DIVIDERCHAR "/" ;
BUSBITCHARS "[]" ;
DESIGN macro_cell_name ;
UNITS DISTANCE MICRONS 1000 ;

DIEAREA ( 0 0 ) ( 0 150000 ) ( 150000 150000 ) ( 150000 75000 ) ( 75000 75000 ) ( 75000 0 );

# (Pin definitions, etc...)
END DESIGN

Thank you

[maliberty]

I think this is a good topic but it isn't a trivial change. Not only does the db need to store the shape but all the tools need to respect it. I expect the later to be a bunch of changes.

@tspyrou - any thoughts on priority?

[WRansohoff]

Thank you for the response!

I figured that it might not be a simple change, and for now, it looks like it is somewhat possible to work around the issue by placing routing obstructions and empty macro cells in areas outside of the desired shape. But it would be nice to see native support for the feature in a future release.

[maliberty]

That seems like a good workaround. The io placer may still get confused though so you might need to use placement constraints with it.

[eder-matheus]

@WRansohoff @maliberty ioPlacer has the "-exclude" option that can be used to define regions of the die boundary where pins cannot be placed. But I'll update the code to do it automatically.
@WRansohoff can you provide a testcase?
Thanks!

[WRansohoff]

Sure - sorry for the delayed response. The proof-of-concepts that I made used the OpenLANE scripts, so I had to adapt an ordinary OpenROAD project to demonstrate the same idea. Here is a minimal example of a design that attempts to implement a rectilinear outline using the current tooling.

I see a couple of small issues when I build it: PDN rails seem to get placed in the macro area, and the def2gds.py KLayout script only appears to process the first GDS file that it is given. But it should demonstrate the basic idea, and I can attach GDS/DEF/etc files if you encounter any issues building it.

You're also correct that I/O placement is an issue with more complex designs; the test case that I linked to does not address that, because it contains few enough pins that the I/O signals seem to get placed in valid locations. The '-exclude' ioPlacer option sounds like a promising way to address the problem; does ioPlacer also have a way to specify the order of pins along each edge?

Thanks for taking a look!

[maliberty]

@Colin-Holehouse please see the note about PDN rails

[eder-matheus]

@WRansohoff I've updated ioPlacer to detect regions blocked by macros and routing obstructions and it is already available in the public repo. About this question: "does ioPlacer also have a way to specify the order of pins along each edge?", the answer is yes. Check the -group_pins option in the Pin Placement documentation (https://github.com/The-OpenROAD-Project/OpenROAD#pin-placement)