Creating an FEOL Class in OpenROAD

[chetanyagoyal]

This is in regard to https://github.com/chipsalliance/ideas/blob/main/gsoc-2023-ideas.md#create-feol-classes-in-openroad-and-a-gds-writer, a GSoC project proposed in 2023. I would like to take this up for 2024's run of GSoC, and was wondering what the project entails. For reference, I have been contributing to OpenFASoC for a large part of the year and have good knowledge of their codebase, and some knowledge of OpenROAD-flow-scripts

[maliberty]

@msaligane was the mentor in 2023 so it would be good to get his input. I expect the hardest part would be dealing with hierarchy (aref/sref) as OR's odb is rather flat in its lef/def orientation. New layers shouldn't be too hard. The rest of the system will have to be more aware of them and the GUI will need some updating.

I would be good to have a specific use case beyond just read/write gds. There should be some value added by doing it in OR as opposed to klayout or gdsfactory.

[stefanottili]

klayout and it’s strm2gds/oas buddy tools not only read gds/oasis/lef/def/ascii but also magic’s format.
As a viewer it is a decade of performance usability features ahead of OR.
I would argue that adding a odb reader to klayout would be the most efficient course of action here.
But even then, the only benefit would be to merge odb with gds leafcells without having to save def.

[QuantamHD]

The usability improvements of a write_gds command in OpenROAD would definitely be worth it. It's a very high friction step to have to write out a DEF and import it into layout with some python scripting.

[stefanottili]

Could you elaborate what you consider a “high friction step” ?

a) using strm2oas/gds there is no need for python scripting to merge lef/def/gds/oas/mag.

If I’m not mistaken, openroad can writes a single lef, so no need to specify all input lef’s.
I’m assuming that a potential chip seal-ring contains a reference to the design.

b) A large part of def file size is the logical netlist connectivity.

A switch for write_def to only write geometry could speed up the openroad write def, strm2oas read def step.

c) If strm2oas/gds could read odb directly one could save time.

Which is small compared to the hours of openroad p&r runtimes and won’t save much compared to the write/read def steps.

The only drawbacks are that the odb seems to be a somewhat moving target and that klayout uses gpl, so there seems to be no code sharing allowed, right ?

[maliberty]

odb is BSD so it can be used wherever. We can't use any of klayout in OR due to the GPL.

[QuantamHD]

In my opinion "high friction" is anytime you're required to leave a tool then call some other binary on a collection of files to get an output. Gathering all those files in OpenROAD means the user need only setup and install one tool and read in the files once. The goal is a clang a.c like experience for the user.

Any deviation from that, in my opinion, is friction. How high is dependent on the individual.

[stefanottili]

Having openroad write gds/oas would be useful, because it reduces the file size compared to odb.

But I would recommend not to duplicate the ability to read and collect all the gds/oas pieces coming from various other sources. This functionality already exists in strm2oas.

[QuantamHD]

I think we should be able to write a usable GDSII for manufacturing which includes the standard cell gds. More macro heavy things maybe not.

[msaligane]

We have been looking into this in the previous GSOC. Hopefully, this project gets approved for Chetanya to finish the project.