The-OpenROAD-Project
GDS Reader & Writer in ODB
GDS Reader & Writer
This Project adds GDS input and output features to OpenRoad. It would replace the current GDS manipulation scheme, which is through Klayout, and further OpenRoad's capability to provide a tightly integrated RTL-to-GDSII flow.
This PR is created as part of the GSoC '24 project with CHIPS Alliance, mentored by Mehdi Saligane.
Features
- Full set of data structures in OpenDB for storing GDS information
- GDS file parsing, supporting all of the commonly used record fields in modern GDSII.
- Layout manipulation through GDS data structures
- GDS file outputs from layout stored in OpenDB
- Parsing primitive layer information from .lyp files in Klayout
Future Works
- Add GDS operations to the OpenRoad GUI
- Integrate GDS data structures together with existing OpenDB structures
- Conversion between LEF/DEF and GDS
How To Use
The entry point to the gds manipulation functionalities are at src/odb/include/odb/gdsUtil.h, src/odb/include/odb/gdsin.h, and src/odb/include/odb/gdsout.h. Documentation for the detailed classes and functions are in the file.
A more detailed specification of the Writer/Reader for future developers is available here.
Example Usage
For an example on how to use the GDS reader & Writer, check out src/odb/test/cpp/TestGDSIn.cpp
@fangzhonglyu Nice! I don't want to overburden this pull request as already getting support to read/write .gds files is a big step.
Just FYI, I was working on a test to ensure that the build output is identical with indentical input(which is a big deal when working with Bazel like build systems that cache outputs) and @maliberty told me that that .gds files have dates in them.
Would it be possible to add an option to write zero dates into the .gds files?
Here is the test that I proposed, but abandoned for now until the underlying issues can be resolved: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2223
@oharboe note that the gds today is generated by klayout so this would help only for future work.
@oharboe note that the gds today is generated by klayout so this would help only for future work.
For my part reproducible .gds and .spef files is into the future anyway, so waiting for .gds writing directly from .odb is OK as it reduces the totalt engineering effort.
Is klayout only used to write .gds files and will klayout be dropped after .odb to .gds writes is activated in ORFS?
In some PDKs klayout could be used for DRC checking. It will likely be a while until OR can generate GDS as this is just a first step.
@fangzhonglyu do you plan to handle aref?
Yes, AREF is already built into the reader/writer and shares the same class as SREF
@fangzhonglyu please ping when you have addressed all the feedback and this is ready for re-review.