python interface

[tvt173]

would be cool to create a python binding (i.e. with pyo3). i think you would attract a lot more users that way.

[dan-fritchman]

Thanks for checking it out!

There are a few things you could do right now:

• Layout21 is really “made of” the VLSIR (https://github.com/vlsir/vlsir) data model, which is defined using the ProtoBuf SDL. And there are existing Python bindings for all of VLSIR in https://pypi.org/project/vlsir/. You would have to invoke a command-line program to convert that Protobuf into EDA formats, e.g. GDSII.
• All of the layout21, gds21, and lef21 data structures are also serde-serializable. So you can turn them into your favorite serialization format. We have particular support for JSON, YAML, and TOML. If you wanna light-weight muck with them in Python, that’s a very quick start.
• There’s no intent to build more elaborate bindings to the specific formats, e.g. GDSII, LEF. If there’s ever a more fully featured set of Python (& co) bindings, e.g. with PyO3, they’d be to layout21raw, tetris, and the other layers of IC layout description, independent of the file formats. PRs are always welcome!

[growly]

To expound the first suggestion a little further, the ethos behind the ecosystem in which Layout21 exists (VLSIR) is to decouple components with distinct responsibilities (like the Unix philosophy). You can write GDSII by expressing your layout as a protocol buffer in the corresponding VLSIR types and then use the proto2gds tool (in layout21converters) to create a GDS. The VLSIR schema supports (or is planned to support) the GDS geometric primitives. Any abstraction of the interface, like a python library more usable than the protobuf one, would have to be collected in a language-specific project.

As an example, this C++ project will write layout data to protobufs and then use proto2gds to convert that to GDS for viewing.

Also in the same project, this Python script will read the layout of some cell in protobuf format and perform basic geometric transformations. You can import existing GDS libraries (e.g. a standard cell library) into the VLSIR protobuf format using gds2proto in layout21converters.

[tvt173]

thanks for the explanations, @dan-fritchman and @growly. just out of curiosity, why did you choose to use protocol buffers as an intermediate representation?

@joamatab @flaport

[flaport]

@dan-fritchman just used your project within a small rust project within our company. Loved the simplicity and minimalism :)

[dan-fritchman]

Glad you like it!

Re:

thanks for the explanations, @dan-fritchman and @growly. just out of curiosity, why did you choose to use protocol buffers as an intermediate representation?

I would probably call them an "interchange format" more than an "IR", but I get what you mean. Generally I think of the criteria as being:

• Binary. Particularly for polygon-by-polygon layout.
• Cross-language
• Support the languages that we actually want to use. Thus far primarily Rust, Python, C++.

The primary alternatives which meet those criteria are generally in the "Protobuf spinoffs" family: Capn Proto, FlatBuffers, etc. Plus I'd note for less data-intensive use cases e.g. debugging, all of the (Rust) datatypes are also serializable to anything serde supports. We make particular use of YAML, JSON, and TOML.

(Plus @growly is a Google lifer with lots of experience with Protobuf.)

[joamatab]

Thank you

we are considering using VLSIR as the backend for gdsfactory to speed up reading and writing to GDS, as well as leveraging all your interfaces with spice, Xyce simulators

https://github.com/gdsfactory/gdsfactory/issues/521

we could use geometry_pb2.py to create a protocol buffer representation, what could we use to go from GDS using the python bindings?

@proppy @mithro @HelgeGehring @thomasdorch @TannerRogalsky

[dan-fritchman]

Joaquin, great to hear you're interested in using this.

• As for the SPICE interfaces - this should be pretty straightforward. Add a dependency on VlsirTools, and if you'd like some (a lot of) niceties layered atop it, Hdl21. And if you have those command-line simulators installed, they should "just work" (tm).
• As for GDS import & export - you certainly can do what you've suggested, using Python to create our protobuf objects, and then Rust to convert those to GDS. Before you get too far down that road, I wonder: is using Python to write those protobuf structures just going to replace it as your bottleneck?

[tvt173]

hard to say for sure, i think... my baseline for thinking about it is comparing gdspy to gdstk... main areas where i see substantial speedups are on gds read/write, flattening, booleans, etc. i think that basically comes down to places where we are unpacking hierarchy (hence lots of loops and vertices!)... even if we do creation/manipulation in python and pass as protobuf data to rust, as long as the data has a nice hierarchical structure, i think we could expect pretty reasonable speed...

that said, that was part of why i was asking about a pyo3 interface to start the thread... of course it should be a more "direct" interface with more chances for speedups if we did so. not sure if it's worth the effort though or to use protobuf as the intermediate "handshake". maybe a flattening test would be an interesting benchmark... create a simple but large hierarchical design in python, create protobuf, flatten in gds21, reload into python... see how long it takes vs the same operation fully in gds21

[proppy]

not sure if it's worth the effort though or to use protobuf as the intermediate "handshake"

I think another aspect to potentially consider would be gain in simplicity and future-proof interop that a tool like gdslibrary could get by relying on protobuf (other any IDL really: cap'n'proto, flatbuffers) as the intermediate format.

Currently my understanding is that all the composition happen thru gds files i.e:

• that's what you read from the PDK cells
• that's what you get after combining multiple cells into components
• that's what you export at the end before sending the mask to the foundry).

Relying on a friendlier intermediate format that has a more direct mapping between its memory and disk representation w/ polyglot bindings, could allow for:

• speedups and simplification across the whole flow
• easier interop with emergent tools in this ecosystem (no need to bring in a full gds parser)
• preserving interop with the existing ones (you can still convert down to gds).

Dropping @xtofalex in there too because I know they have similar thinking going on for https://github.com/xtofalex/naja/, and @QuantamHD because I know they had having similar thoughts wrt https://github.com/The-OpenROAD-Project/OpenROAD odb format.

[tvt173]

yeah, good points @proppy . and we could get some very nice performance benefits and separation of concerns I think if we expand the schema a bit more to allow for some higher-level abstractions for photonics-- i.e. an "extrusion" = cross section + path.

when composing the layout in python we could just call extrude() and create the simple intermediate representation. then convert the extrusion to polygons on the rust side when we export (or need to query the polygons)