Ah well actually the techlef has a `AREA` set and ...
# openroad
t
Ah well actually the techlef has a
AREA
set and it's still generating wires of less than that area 😢
a
It depends on where the wire is being generated, either in the detailed router or by PDN. They both should respect minimum area rules, it's a bug if not. There's also a small chance it's a design problem if there is no legal way to fix the min area. Usually the detailed router adds "patch metals" to extend wires that are below the minimum area, but if it can't do so without causing a violation, then it won't. But, it could also just be a bug. Best case is to file a GitHub issue with testcase
t
It's a routed wire and there is definitely space to extend it. Actually you can see it has been extended ( because it's a stub on met2 when going from met1 to met3).
a
Yeah, I would file an issue with reproducible then. It might be an odd edge-case.
m
Generally OR will patch small wires to meet min area rules. They are common so it must be something particular to this case
t
Yes, I see wire stubs to do that. And this particular wire was also extended just not enough. I still didn't open an issue because it's not trivial to reproduce since it's sort of random and all our build happen in github action so getting a small reproducible is a pain ...
a
@tnt did you figure this out? I am also facing this problem, openroad is generating many wire stubs smaller than the minimum area. I tried overcompensating by tricking the lef file, still looks like openroad is not respecting the rules 🙂
t
Nope, the work around with LEF worked well enough for us to pass.
✅ 1
Didn't investigate further.
a
Alright! just to make sure, as I am using ORFS (docker), the lef file to edit would be ~/OpenROAD-flow-scripts/flow/platforms/ihp-sg13g2/lef/sg13g2_tech.lef correct?