Function for cleaning up cell names

CreatedByCreator

Does anyone know if there is a way to clean up cell names that have had the "$#" tacked onto the end?

I think the source of these cell name modifications is that I frequently create layouts with sources from multiple libraries which sometimes have cells with the same name. The content of the cells with repeated names should be the same as well, but when they exported without the cell context (or opened by another layout editor), all the $'s appear.

I've also noticed that with multiple libraries linked, the cell names won't show the "$" unless I open the rename cell dialog.

Is there a built in function that will let me replace all cells with *$# at the end regardless of the rest of the cell name? In some instances, there actually is no cell without the $# label (typically labeled $1) and so in that case, the cell with the lowest number $# would be renamed to remove the "$#".

My guess is that this would have to be scripted to whitelist/blacklist certain cell names since for PCells, the $# added to each cell variant is necessary.

Any help is appreciated.

Thank you!
CBC

Matthias

Hi CBC,

Like you noticed, the "$#" suffix is needed to disambiguation of the cells. KLayout does not require the cell names to be unique, but GDS does. So, KLayout internally tries to assign a new name to every cell.

If you have two libraries, i.e. "LIB1" and "LIB2" and both have a cell "A", then KLayout's cell tree would show "LIB1.A" and "LIB2.A", but the cells internally will be called "A" and "A$1". If you remove "LIB1.A", then only "A$1" remains, but "A" will be reused when you reference or create another cell called "A". You also see the internal names in the "rename cell" dialog, but there is no good reason to rename a library cell - except to change the internal name.

For PCells that is mandatory, as PCell variants also need to have unique names. After all, the original intent is not lost, if you load the layout again into KLayout - with the meta information stored in the context, KLayout can recreate the link to the library and/or PCell and you won't see the actual name.

The concept of variant formation is pretty common in other streamout schemes. In the end, the goal is to maintain structural integrity of the GDS file and avoiding name clashes in GDS is a key requirement. You don't want to spoil your layout, just because some logic decides that two logically different cells can be joined after a name clash. That's also why I would advise against trying to tamper with the cell structure. In my experience, suffixed cell names are less annoying than loss of layout integrity - these problems have the tendency to pop up in the night before tapeout.

There are arguments for a cleanup though. If you do LVS, the cell names matter. Hence the suffix will destroy schematic to layout correspondence. However, name clashes are also a problem in schematic and SPICE files, so it's a very good idea to avoid name clashes in general. Recently I have hardened KLayout against creation too many cell variants because of that problem, but the scenario that triggered that requirement was in the context of a third-party library manager, which had a tendency to create many levels of library indirections. So I think that was a kind of special case.

If you really need a cleanup for whatever reason, it's not exactly a simple job. Like you say, you need to differentiate between necessary and unnecessary disambiguation. Instead of white- or blacklisting, the best strategy is most likely to do some analysis of the cell content and joining cells only which are really identical (that needs a definition of "identity" at least). The algorithm needs to work recursively, as cells can reference other cells, and for parent cells to be identical, identity of the child cells is required too.

It's possible to create such a tool, but as a minimum side effect you will loose context. So for example, if "LIB1.A" and "LIB2.A" are identical for some reason, such a tool would combine both, and maybe give you "LIB1.A" only. So if later you decide to change "LIB2.A" to be different from "LIB1.A", this change will no longer be reflected in the layout. Considering that real-world layouts usually have a significant hierarchical complexity and it is difficult to track such side effects, I'd seriously consider if you really want to have such a feature.

Matthias

CreatedByCreator

Thanks Matthias, I agree completely with your analysis. Since I'm not running LVS, this isn't an insurmountable issue for me.

In this case, since I'm "combining" parts from different libraries, I am fine with losing the context and for this tapeout to become it's own library. Especially since if I wanted to reference parts from previous libraries, they would still be there in their own library (assuming that the tool doesn't/can't change anything in the library files).

I was mainly asking to see if anyone had scripted a solution for this already. Perhaps the best way at the moment is to just use the replace cells function that you've already built into the cell list context menu and manually combine.

Thank you!