@User: (1) Magic saves the path to cells, so that it does not get confused about cells with the same name in different libraries. You can use "load <name> -dereference" in case a cell library is no longer in the same path that it was when a file was saved. I should probably provide a pop-up window with options like "ignore all" for this, to avoid the problem of having thousands of error messages dumped to the console. (2) I have a lambda grid that is 2x the base grid. Use "snap int" to be able to move around on the base grid (internal units). (3) The error says the via width is wrong. That looks like a scaling issue of some kind? It's not clear to me what I'm looking at in the layout. That's zoomed in on a standard cell layout that was routed with qrouter? I think I need to see a larger area to get some context. The "no overlap" errors are coming from the LEF views that were created by magic; I need to update open_pdks with an option I added to magic that should prevent those errors, but I had been waiting on an update of skywater-pdk (I'll check it today).

My bad, these are two decaps with overlapping rails, this was implemented with openlane flow

(1) You get better screenshots if you use "magic -d OGL" (or "magic -d XR" if your OpenGL implementation is overly restrictive, which is nVidia's fault). For "-d XR" you need to have the libcairo-dev package installed prior to building magic. (2) There is a known issue with the power rails which we are currently working through, having to do with the fact that the SkyWater cells marked only the metal1 layer as belonging to the power pins, while marking the layers underneath as obstructions, while magic's LEF generation output all of the layers as belonging to the pin. That means that a in mixture of abstract views from both magic and the original SkyWater, sometimes you end up with obstruction layers overlapping regular layers, which is flagged as an error (even though it's not). We'll have that fixed pretty soon. (3) The errors you highlighted around the power posts looks like something different, and I'm not sure why that is getting flagged as an error, because I have loaded outputs from openlane before and didn't see any problem around the power connections. If you could send me a DEF file of a small example, that might help. But since the contacts are probably defined in the technology LEF file, it might be that the problem is there.

Do you mean this file?

designs/copperv/runs/ver4/results//routing/copperv.def

or the mag file? ok, that seems to be it

grep def designs/copperv/runs/ver4/logs/magic/magic.drc.log
Reading DEF data from file /Users/ronaldv/Projects/repositories/openlane/designs/copperv/runs/ver4//results/routing/copperv.def.

Uploading

@20Mhz: That's the common error with OpenGL; off-screen rendering is disabled in the OpenGL implementation. The best workaround (which looks like it will work in your case because the "-d XR" version managed to draw the toolbar icons correctly) is to compile magic with the "--enable-cairo-offscreen" option passed to "configure". That will use libcairo for the off-screen rendering, which bypasses the OpenGL problem. Then you should be able to run "-d OGL".

works, 🙌