@User Weird, when I do -d XR it doesn't highlight any errors. But they are still there! (Some of them are valid errors)

There can be weirdnesses in the implementation of either Cairo or OpenGL depending on the system and video card. But that view makes it a bit easier to see where the errors are. I don't know why there's a metal5 width error but it's possible that it is an artifact of the other errors and will go away when they do. If not, I'll need to figure out why it's being flagged.

Ok, good to know

There are ways to get the checkbox at the top to be out of sync with what's in the window; I think it may not respond to pushing and popping the cell stack. Come to think of it, I should be able to fix that pretty easily. Run the command "drc count" if you want to be sure about what magic thinks of the state of the DRC.

And the other question is whether TritonRoute does the same, but you may not know

The magic techfile defines metal and metal obstruction on the same plane, so there is no way to represent both in the same place except in different cells, and that will get flagged as an illegal type overlap error. For magic, you would need the cut-out around the pin in the LEF view.

Ok, that's what I've been doing, and learned about that pin behavior in the LEFDEF spec so I thought I would ask.

I'm always learning new things that are buried deep in the LEF/DEF spec, and it is always an unpleasant surprise.

Last question: Is there a way to enable -d XR from the .magicrc 🙂

No, it's something that has to be configured during the launch script and is too late once magic has started.

Is there an env variable you can set to do it then?

You can just create a shell alias for it. . .

True

I've been caught by that before. I need to do something about that color scheme.