<@U016EM8L91B> Any thoughts on speeding up the mag...
# magic
a
@User Any thoughts on speeding up the magic DRC checks when run in openlane? I tried building with optimisation, but in my case it didn't help much (runtime seems to be dominated by loads). My first thought was OpenMP, but I'm still pretty lost when I get deep in the DRC code. Perhaps a quick hack would be to break the DRC rules up and run magic N times in parallel. Longer term I guess parallelising it by region (vs by rules) would be faster if we are dominated by loads.
t
I have looked into the issue of parallelizing parts of magic, but it is difficult. That was in the days before OpenMP, so perhaps it is easier now? You cannot break the rules up, because the DRC works by scanning all edges in a plane, then looking up the rule in a 2-D table for [inside type][outside type]. The thing that would be easiest to parallellize would be the planes; the DRC can be run separately on well/active/metal1/metal2/... planes. The only issue would be that they all write to the same DRC result plane, so there would have to be a mutex lock on that.
But, the DRC is broken into two parts, which is the edge-based rules vs. the GDS-based rules. The latter is likely what causes the most slow down. There is an "optimized" DRC style variant "(routing)" which looks only at the basic metal width/spacing/area rules. It does not catch all rules, but it is very fast.
a
Ahh interesting, let me try that
Thanks for the tips