Hi, can we run the openlane flow on multiple cores...
# openlane
n
Hi, can we run the openlane flow on multiple cores? Or is there any option to speed it up?
a
Currently you can only set the number of threads to use for detailed routing, which takes the longest, using the
ROUTING_CORES
parameter.
n
Thanks @Ahmed Ghazy, do you know what is the maximum number can we set (default=4)?
r
@Nguyen Dao you can ususually use nproc to see your number of processors
so something like
export ROUTING_CORES=$(shell nproc 2>/dev/null)
@Nguyen Dao or if you can use makefiles, see nproc.mk in openlane top directory
@Olof Kindgren this is a perfect example usecase for edalize-run-in-cloud
n
I only see it runs on 1 cpu when checking the running process (openlane)
I set
ROUTING_CORES
to 12 in my case but this option is for detailed routing. My flow is still stuck at Global Routing (fastroute)
r
@Nguyen Dao is it still running?
n
I’ve stopped it to change the options, now re-run it but don’t see any improve
r
@Ahmed Ghazy looks like this could be some kind of pathalogical case or infinite loop. Test case is https://github.com/FPGA-Research-Manchester/FABulous-SKY130
@mkk ^
o
@Rob Taylor Actually had a talk with @Ahmed Ghazy and @mshalan yesterday about Edalize, OpenLane and cloud use-cases
r
nice :)
n
Update: the flow works fine with 1x2 and 2x2 CLBs fabrics without timing optimization (OpenPhySyn doesn’t support disable timing loops). For the 4x4 CLBs fabric, it’s stuck at global routing (fastroute)?
r
Does the time go up exponentially?
Could we produce a 2x2 clb gds and then stitch together to make a bigger fabric?
n
Running time are almost same: 12s (1x2 clbs) and 13s (2x2 clbs)
r
Interesting. Same for 3x3?
I wonder - are you hitting memory limits and it’s going into swap?
n
I haven’t tried 3x3, need to ask Jing to generate codes. I don’t think memory is limited, it used only 1% of memory (64GB) when routing
r
Same when going the 4x4?
n
yes, same memory at 1%
r
Very odd. Ok let’s get a 3x3 tested, find out where this breaks and then let’s submit a bug
Or maybe 2x4 if that’s easier
n
it’s OK with 2x4, global routing took 16s, looks like the running time doesn’t go exponentially
r
Weird!
Ok, it’d be good to prepare a test case that shows the working version and the non working version and submit that as a bug against openlane
m
Did you solve the problem? We got the same problem when tried to route small memory.