Layers

dick_freebird

I know I've suggested this in the past, but I think it would be
clean if the "Edit>Layers>Edit Layer Specification" command
were duplicated in the Layers right-click context menu.

I'm back staring at a several-hundred-line layertable trying
to transcribe names from one foundry document, to my .lyp
(using the GUI, probably would have been more efficient to
do it by text...). So I have to ping-pong between the Layers
window context menu, and the Edit> menu tree, over and
over. Right-click much better.

I have another question regarging the Layers display.
I find that some layers are still displaying only the
layer/datatype despite having a valid name in the
Layer Specification. Some display only name but have
assigned layers. But others display name, layer, datatype.
I cannot find what controls this behavior (want to display
all 3, in uniform format).

dick_freebird

I'm having a different issue now (on the same project).

That is, I have an old process development wafer DB which
I am trying to harvest transistors off of, to modify. I have a
.lyp which has worked for me fine (created from scratch by
menu hand work and plenty of it). But when I open the
legacy file, I get a ton of new layers and my specific problem
is that the existing layer/purpose/name is ignored, and a new
duplicate layer/purpose with no name, is created and holds
all the polygons. So if I am in a layout with existing objects on
my existing layers, I get a whole bunch of stuff that's on new,
same-numbered, but not-same (and not where they belong)
layers.

So I have two of everything, and one is auto-gen'd fill codes,
and the display seems to not be able to make up its mind
which to use. And moving the object from one "99/1" to the other
"99/1" does not make it change its mind about rendering.

I took the auto-gen'd layer 99/1, changed its name to proper
and fill codes to match, and now I have two dead-same, but not
same somehow.

So questions...

• How do I make the technology .lyp "get used", rather than
  "augmented" with duplicates? It seems obvious (to me) that if a
  layer/purpose pair already exists, then it ought to receive any
  and all objects assigned that layer/purpose. What would make
  the import, not do that? And how to enforce?

• What's the proper / best way to "merge all layers of layer/purpose"
  into one, if I have such duplication, without losing objects? Is there
  any such thing? If not, what's the best plan for cleaning?

• I don't think I can share the .lyp in more than cartoon detail
  without the foundry's permission, but I could probably provide
  snippets that answer a question, is anyone feels like asking.
  I'm thinking maybe I need to get into text-editing the .lpy (starting
  with saving and inspecting for duplicates - what, how and why?)

• Is there any documentation regarding .lyp form, content, style
  that would inform an effort to text-edit my way to a clean .lyp?

• Wondering whether there is opportunity for a more capable /
  smooth layers editing "window" (or maybe I construct a
  "session" with the layers stuff enlarged to where I can pick
  rather than scroll, of course having the Edit>Layer>Edit Layer
  Specification at that level by right-click rather than 4 menu
  steps down in the main window, would be a modest time saver
  times a couple hundred. If I succeed at that I'll post it.

dick_freebird

I see this behind the Import panel

Which perhaps defaults to importing -all- the layers -even if-
in the mapping table? I would like behavior to be "use existing, if"
and "create if not". But I can't say for sure what the text about that
is really trying to imply (or whether my off-the-cuff interpretation
is on the mark).

dick_freebird

I tried "Clean Up Layer Entries" and it gave almost the
opposite of what I wanted. Rather than letting me combine
duplicates, it blows away all unused (though valid for masks)
layers, and leaves the duplicates untouched / unremarked.

That command is also not "Undo"-able....

Matthias

Sorry, I somehow missed that post ...

Rrgarding the first issue - do you intend to save to OASIS or some other format that supports layer names? Because only in that case, giving the database layers names only make sense.

If you read from GDS and want to assign layer names, the layer mapping feature may help. You discovered that already and here is how you use it:

this will assign layer names upon reading. You can configure that per technology in case you're using the technology feature. When you enable the "Read all layers" option, this would create all the other layers with non-assigned layer/datatype combinations - but in that case without a name of course.

Regarding the second question I cannot readily confirm the behavior you describe. The intended behavior is that: assume you have a .lyp file with layer/datatype/name specification like that:

  <source>diffusion 1/0@1</source>

if you feed in a GDS file with layer 1/0 it should be assigned to that layer entry in the .lyp file even though there is no name. If you feed in a CIF file (which only has names) with a layer named "diffusion", it should also be assigned to that .lyp file entry. Basically layer/datatypes have priority, so I do not fully understand that you get new layer entries for the same layer/datatypes.

Maybe sharing a simple sample might help to further identify the problem's root cause. I can't say right now, why the new layers are created and obviously are not associated with the existing layers.

Best regards,

Matthias