then I move things around and get another silly er...
# openlane
then I move things around and get another silly error somewhere else. Why is the router choosing paths that will violate DRC?
I think I know the answer. As I'm using openram, I turn off MAGIC_DRC_USE_GDS because otherwise I have to wait 10 minutes for magic to find 2M drc errors.
but then magic uses the def/lef instead, which doesn't appear to be the same as the gds
if I copy the final gds and lef files to the correct places and then run precheck, it passes
so I think for me the solution is turn off drc completely with RUN_MAGIC_DRC = 0
and only use precheck for drc
ok that seems to work for me
trying precheck on the efabless platform
@User there are 2 ways to write the LEF: one with just the pins and blocking layers for the internal stuff, and one with all the internal wiring details. If you use the simplified (which is the default I think in OpenLane) then the router has to go around, and maybe too little space is available. If you use the detailed LEF then the router can (and will) connect to a trace wherever possible. PS I Hope I got this explanation right, but consider I am still a newbie myself in the digital backend business :-) I guess @User can give a better answer…
thanks harald
I don't follow though, the routing surely only happens once?
@User: What Harald is referring to: The LEF view can either show all the details of the routing inside the macro or standard cell, or it can just draw a blanket "obstruction" layer over the whole thing. If the detail router sees the first kind of abstract view, it will be free to place routes over any area inside a macro that's got empty space available for routing. But if that macro is replaced with an abstract view that has obstruction layers covering the entire cell, then some of those routes may end up inside the area of obstruction, where there's really empty space underneath but you can't tell that when all you get is a giant square of obstruction. I'm not sure that that's the issue here, but I know it was an issue at one time, especially with the SRAM which has a lot of empty space around the edges. And a detailed LEF of the SRAM showing all the wiring is MB in size, so it's much better to just show the SRAM as an abstract view with obstruction layers over the entire macro.