For reference, this was the OpenDB snippet I used :

MET1 = tech.findLayer('met1')
VIA = tech.findVia('L1M1_PR')
encoder = odb.dbWireEncoder()
encoder.begin(wire)
encoder.newPath(MET1, "ROUTED")
encoder.addPoint(x0,y)
encoder.addTechVia(VIA)
encoder.addPoint(x1,y)
encoder.addTechVia(VIA)
encoder.end()

What's the connection you're trying to achieve? A via from met1 to li1 -> move some horizontal distance -> via back up to met1?

Connecting two cells pins, so go from the pin area that's on

li1

to

met1

, move some horizontal distance, go back down to

li1

@User: That's an interesting case. I have interpreted the above (and the DEF snippet you shared:

+ ROUTED met1 ( 209862 226950 ) L1M1_PR ( 212255 * ) L1M1_PR ;

) the same way magic did, which is consistent with what is in the LEF/DEF reference:

viaName

Specifies a via to place at the last point. If

you specify a via, layerName for the next

routing coordinates (if any) is implicitly

changed to the other routing layer for the via.

For example, if the current layer is metal1, a

via12 changes the layer to metal2 for the

next routing coordinates.

I am gonna say that klayout is the one in the wrong here; magic is parsing the statement correctly, in my opinion. (@User can maybe also confirm this?). The conclusion is, the code above is not doing what you described; every time you place a via, you switch the layer. You started with met1 and then placed a via, so you are on li1 now. Changing the first layer to li1 does the opposite and shows, at least in magic, correctly, which would generate the GDS view.

@Ahmed Ghazy Thanks for the analysis ! I'll report that as a klayout bug then.

For the record, I agree with @Ahmed Ghazy’s analysis, although I have not tried it in klayout. I do remember going through a round of bug fixes in magic related to the same topic, some years ago.

I opened https://github.com/KLayout/klayout/issues/625 yesterday with the details and files to reproduce it. I'll see what feedback I get from the author.