It looks like you're new here. If you want to get involved, click one of these buttons!
Some background:
I guess here's my theory and I'd appreciate your corrections/insight/better explanation:
If you save a GDS file that used library cells with context information and then ended up merging it with another file that was saved without context information (using the same cells), you would end up with a file that shows one set of cells as "[LibraryName].[LibraryCell]" and another set of cells just named "[LibraryCell]". When I run this through my cell swap I end up with "[LibraryCell]" and "[LibraryCell]$1" (we strip the context info during cell swap and DRC and some other checks.)
(Typically I tell the designer they have $1 issues, but they don't see it because KLayout tries to resolve the Library. I've noticed if I open the file with the mixed cells in something else, like LayoutEditor, it immediately shows the $1 because that program doesn't or can't deal with the library.)
So I suppose I'm just trying to make sure I understand what's going on and what could cause it so I can help designers fix it. I don't think this is a bug or anything that needs to get fixed. I think KLayout is functioning the way it should - MAYBE having the option to open a file ignoring context information could help? But it comes down to this library context information, right? And that can only be triggered by saving with or without that check box and merging two files. It's not like a designer could add a library cell with context and then elsewhere add it without context. Right?
Appreciate the sanity check!
Comments
Hello @NMF,
first sorry for this delayed reply.
Actually, libraries are a special concept that KLayout introduces. It is not a standard concept of GDS. This is why other tools do not known about that.
GDS internally does not have connections to a library. For example, the "Basic.TEXT" PCell is stored as "TEXT" and the context information (stored in a special cell or in specific properties in case of OASIS) will tell KLayout that this cell is actually coming from a library called "Basic". On reading, "TEXT" will be connected to "Basic" and hence show up as "Basic.TEXT".
If you have multiple variants of this PCell - by using different parameters or texts in that case - you may have multiple "Basic.TEXT" cells with different parameters. In GDS that is mapped to "TEXT", "TEXT$1", "TEXT$2" etc. and the context information will tell KLayout which cell is assigned to which parameter set.
For plain libraries, if for example you have a library called "stdcells" and you use some "NAND22" cell from it, this cell is likely to show up as "NAND22" in GDS and "stdcells.NAND22" in KLayout. But if someone for example creates his own cell called "NAND22" or uses some "NAND22" from a second library (like "stdcells_hvt"), then you may have two cells called "NAND22" and "NAND22$1". It should not happen, but I cannot rule out flaws that create two internal cells for the same library cell (I am not aware of such a flaw however).
So bottom line is: if you want to implement a cell swap that is aware of the true nature of a cell (in KLayout terms), you need to ask KLayout. KLayout can turn "NAND22$1" into "stdcells_hvt". If you drop context information, you will no longer be able to get this information, so I'd advise against going that way. Instead, you could read a file, dump a cell conversion table, and use this tables in your cell swap script.
Here is a simple script that dumps this translation table:
It gives for example:
Was that information helpful?
Regards,
Matthias