It looks like you're new here. If you want to get involved, click one of these buttons!
I can see that there is a library system in Klayout,
https://www.klayout.de/doc-qt5/about/about_libraries.html
I am researching if this could help me into what I am trying to achieve.
My first target is to understand if this can enable to completely deconstruct/reconstruct (import/export) a layout into a library.
Maybe you have already an answer to that, otherwise:
Thanks!
Comments
Maybe you could simply write what your application is. That's probably easier to discuss.
Here my replies:
1. Yes, a cell in a library layout can refer to another cell in that library. But that's a normal reference then, no library reference. Some people made the mistake to use a library reference to itself and that adds a lot of complexity without benefit.
2. Yes, when KLayout saves a file with library references, it embeds a copy of the library cell. This means, a layout is always complete - if you don't have the library, you can still see the full layout. Only if you have the libraries, the library references are connected to the library. Otherwise the library references are marked as "defunct". Internally that is called a "cold proxy" which is a cell that remembers being connected to a library, but can't do so currently.
3. Eh ... yes. What do you mean exactly? Yes, a library can contain whole hierarchical designs. Essentially a library is made for holding everything from device cells to complex macros or whole chips. But keep in mind that a copy is involved. If memory footprint is an issue, this may be important.
4. The Library API is part of the standard API. See for example
Layout#create_cell(https://www.klayout.de/doc-qt5/code/class_Layout.html#k_63) in the variants that allow specification of a library name. This call will create a "proxy cell" that acts as a link to a library cell. Proxy cells are the core concept behind KLayout's library reference implementation and they carry the link information in what you call metadata. The metadata stored in GDS is "opaque" - there is no specification. KLayout writes this information into a "context cell" (in OASIS: special properties) and restores it from there. This is an extension to GDS which is essentially compatible with the GDS format, but can cause trouble with foundries that don't understand this extension. The solution is to stream out without the context to create a standard GDS file ready for tapeout. The new LStream format specifies a way to store library references without this hack (see https://codeberg.org/klayoutmatthias/lstream).Matthias
Thanks for the very clear answers!
K-layout libraries have a different structure to other libraries known to me (cadence libraries, Texeda libraries). More over there is a major limitation to klayout libraries:
if I want to make several variations of a top level, I will need to create layouts with full hierarchy, which in consequence will make the designs very large, and cell listing very long. It will be difficult to be used for tasks like Floorplanning.
Of course it is not an issue, but could also be a semantic discussion about what defines a "library".
If you are interested, I already worked a bit on an alternative oasis library format, which would be similar to the libraries that I know of.
It would be too long to place the whole concept here: If you would like we could have a call (let me know how you would like to get contacted), or wait a bit more time before I manage to put the idea into a complete code to completely validate the strategy.