<@U0175T39732>: It has something to do with the w...
# magic
t
@User: It has something to do with the way that I am reading boundary layers; there are several different ways that SkyWater defines boundaries, and it may be that there is more than one of those in the cell. Magic should probably stop issuing a message as long as any boundary it reads is the same as the one it already knows about.
m
But this isn't a cell boundary but a shape boundary. For example, the bitlines on met2.
t
It cannot (?) do that on metal2. It comes from the "boundary" input operator, which is trying to find a layer in the GDS that corresponds to a cell boundary. The layers used to make boundaries are 235:4, 81:4, and 81:3. If there are two of those layers in the cell, you get the message.
m
This is a boundary record in the GDS file format, not a cell boundary.
t
That should not trigger that error message. Do you have a smallish GDS that produces that error message?
m
Let me stare at this more. Maybe it's something else.
Ok, so the boundary is duplicated on 235:4 (prBoundary) and 81:4 (areaid.stdc). What about the second message about duplicated instances? Does the magic GDS parser assume that structures are defined before they are referenced?
Do you also treat 81:2 (areaid.ce) as a boundary?
areaid.core
t
No, only the three above; ideally I should have only one type for a boundary, but SkyWater uses those several different types interchangeably (and apparently in combination as well). I think the easiest thing to do is to stop issuing a message unless the boundary area is different. Or else just ignore it.
If you have references before definitions in the GDS then it is probably best to use "gds ordering true" before reading the GDS.
👍 1
m
That fixes that!