Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Questions about Libraries
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:
- is it possible in a library layout file to have cells coming from itself
- When a layout containing library references is saved, KLayout stores some meta information: does it also save the layout, or is it possible to not save the layout?
- if both points are valid, when we import a cell from a library with a reference to another cell it is possible to have the full hierarchy ?
- finally what is the format of the metadata, is there any python APIs to code it?
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.
Hi Jonathan,
If you work on an alternative, you may be interested in that here: https://codeberg.org/klayoutmatthias/lstream. It's an open format that supports the idea of external library references among many other things.
The replication mechanism is important, as it always gives you a full GDS. GDS or OASIS do not have external references. And it allows users to see the full layout even if they do not have the libraries and specifically not the PCells you use. In Cadence there is only streamout and then there is no (good) way back to OA.
Also, DBU translation and layer mapping happens during the replication, so the replica is actually a translated version, not a link. This way you can mix library components with different DBU for example.
But the replication is not written in stone. Actually there is an activity towards dropping the replication - at least in the file: https://github.com/KLayout/klayout/tree/lib-file
But if you want the Cadence concept, you should go for Cadence. KLayout first of all is a GDS and OASIS tool and library management is not the primary intent.
Matthias
LStream is definitely great indeed!
Would you be able to help me assess what are the perspectives for this format:
Note: in my project, the format is not an alternative, it is using what is existing, so oasis files only.
I could build oasis external reference simply using the naming of cells (cellname)(specialcharacter)(library)
of course it does not integrate netlist and schematics and working on it lose its meaning if a format like LStream exists.
Hi @jonathan,
LStream is currently just a proposal, but I implemented the layout view part in KLayout for real-world applications. Right now, that subset is available for reading and writing and external references will be somewhat better supported in the next minor release. In that release, you can define libraries through a library definition file and drop the replication mechanism for these libraries.
In OASIS, KLayout uses properties to annotate instances for being taken as library references. That is compatible with the OASIS standard, but I wanted something extensible for the future. Like support for other object types (e.g. pins), connectivity, PCell support or additional shape types (e.g. edge pairs). Also there is the curvilinear universe which needs better support (yes, I know there are MULTIGON objects in OASIS, but that is a different story).
GDS is even worse. Properties are very limited in GDS, so I packed all that context information into a separate top cell. That way, GDS stays GDS, but the price is an expensive serialization scheme.
LStream is based on Cap'n'Proto which is inherently extensible in the same way XML or JSON are. I think that's a more solid basis for future applications. Hence I went that way.
Your approach does not sound wrong. Actually having dangling references is a common way to define insertion points for external layouts. The mechanism is not foolproof if you don't have a strict separation of cell namespaces, but it's good enough for top level assembly in a digital flow for example. I understand what you implement is a kind of convention that establishes a more solid definition of such insertion points. That still makes sense.
Matthias