fwiw ORFS defaults to the number of cpus from nproc

I think that explains sudden but very short bursts of all cores being used? Helpful, but doesn't do much for the overall flow. It would be nice if more tools picked up the number of cores from

nproc

. Openlane has an environment variable for

ROUTING_CORES

but doesn't set it in any examples (case in point: the Caravel user project example (!)), but it does make a big difference. In the openlane flow, magic's DRC is one of the lengthier items and there are certainly ways to parallelize that, although probably the better solution is just to migrate to klayout. Has anyone profiled the average runtime of the various tasks during synthesis/place/route and determined where the key chokepoints are?

I think ROUTING_CORES should default to nproc's value rather than a fixed 2

@Tim Edwards Here's where most of the time is spent when running Microwatt through Openlane. Times are in seconds:

- drc - magic 2580.36
- detailed_routing - openroad 1028.05
- spice extraction - magic 557.69
- gdsii - magic 508.67
- synthesis - yosys 310.38
- global placement - openroad 218.56
- lvs - netgen 144.44
- sta - openroad 70.86
- sta - openroad 61.7
- sta - openroad 58.9
- resizer timing optimizations - openroad 54.07
- cts 50.47

Definitely it shows that magic suffers from not being multiprocessing.

Some discussion about this from a while ago: https://open-source-silicon.slack.com/archives/C016YSAP6TZ/p1610566555026400

@Anton Blanchard how many cpus used for detailed routing?

@Matt Liberty 12 core, 24 thread (AMD)