The Names of Things

dick_freebird

I was asked about something, that made me think about using
instance names to find (say) a specific transistor.

But I find that there -is- no instance name to a placed cell. I find
no "handle", although the coords are shown attached to objects.
Perhaps the coords and name are the only handle. But seems
to me that a managed list ought to assign a name to each element
just to keep order (two objects could share same coords).

Being able to search by name is a great help, when it happens.
Forcing same name onto schematic and layout objects really
helps with LVS debug.

Am I just not looking in the right place or the right way? Or,
is this a thing which can be "brought to the surface" to let
us assign the names we want, and manipulate layouts using
them for our purposes?

Matthias

Hi @dick_freebird,

Problem is: GDS does not have instance names. There is no way to store them, except through properties, which are not standardized.

KLayout does netlist extraction into a database, which is stored along with the data in the LVS report (lvsdb). This database cross-references a subcircuit from the netlist to a specific instance. It also keeps information about the shapes of nets and the locations of devices. If you have a LVS report, you can load it into the netlist browser ("Tools/Netlist Browser"). If you click on a circuit node of subcircuit in the "Netlist" section it will take you to the instance.

Here is the example from https://github.com/KLayout/klayout/issues/1813. It has three instances of a cell called "buf_x1":

The netlist browser can also take you to a specific net, the nets attached to subcircuit pins or to device instances.

Matthias

dick_freebird

If properties are a thing, albeit unused, I'd like to see some
thought given to how they could be. Perhaps a few properties
like 'instanceName' would be big levers. I certainly do like
using instance names as first guess for correspondence.

And if, for example, a PCell could "reflect" text properties
(like "M20" or "R12"), that would achieve my goals (of getting
a hierarchy-aware search-by-name, and getting a displayed
name hard-bound to a placed object, which if I chose would
be matching the schematic object).

I understand that the LVS and net browser can do this (when
layout is in a verifiable state, which is often sometime later
than when I'm trying to find some particular instance).

I have found Brand X similarly limited in this way (some
things only work once you've passed LVS, or gotten real
close) but Brand X will let me do all kinds of stuff with
properties (including hierarchical pass-down).

It seems to me that in the GDSII there must be -some- kind of
unique index for objects, even if we don't see it? So wonder
if there could be some "meta" layer that doesn't require a lot
of rip-up, but could maybe be a linked list of that index and
its instanceName "not-GDS-property", make a map-file that
placement or property editing would update & maintain, without
too much "touching the GDS guts" other than maintaining
index sync?

Matthias

Hi @dick_freebird,

properties are basically available, but those are not standardized (only numbers) and I feel they are not commonly used and have to some limitations. GDS is basically only a serial format listing instances, so no index of any kind.

I feel what you are basically looking for is some way to connect an instance and maybe shapes to things from the schematic - so more on the creation rather than on the output side. I think that is what is in general summarized by "connectivity information". Having that would be great deal - like allowing "generate from schematic", enabling fly lines, instant short checks and much more. I wish I could support that, but that is a big topic and my time is limited. Technically I'd not see an issue to store that in GDS properties or - some KLayout specific extension that is called "meta information".

Matthias

dick_freebird

Yes, I think we understand it the same. I'm thinking that smart
folks could come up with a simple architecture for using
properties (how many uses, really?), set a standard (API?)
and then enable more sophisticated yet less difficult checking
and searching.

I've put the thought-worm in your ear and now I'll wait for it
to chew its way to daylight. That's been working out so far...
PCells, DRC, LVS, none of that's "native", right?

dick_freebird

Let me pose a "pathfinder" question-bundle.

Suppose that I made a transistor layout of fixed
geometry. Further suppose that I wanted to place
a text in that layout, which would "reflect" a GDS
"property" added (say, cellRef is the property name
and property value ="M15").

What would be the format-text to make that happen,
displaying M15 at the text object origin rather than
the literal string arg of the text object?

Is there anything like that, that would work?

How difficult and interesting would be making it?