Still stuck on this tritonRoute issue, it's always...
# openlane
Still stuck on this tritonRoute issue, it's always immediately before
start track assignment
. There is no useful context in the logs, just the console logs before it is killed. I doubt it is OoM as the docker process peaks at about 3.8GB and there is a lot of vacant memory to use. Does anyone have advice on how to figure out the root cause, or potential causes for this? I'll reply in a thread with more context
Copy code
init gr pin query ...

start track assignment
[ERROR]: during executing: "TritonRoute /Users/dan.rodrigues/hw/caravel/openlane/vdp_lite_user_proj/runs/17-11_21-41/tmp/routing/tritonRoute.param |& tee >&@stdout /Users/dan.rodrigues/hw/caravel/openlane/vdp_lite_user_proj/runs/17-11_21-41/logs/routing/tritonRoute.log"
[ERROR]: Exit code: 1
[ERROR]: Last 10 lines:
child killed: kill signal
I've tried manual pin assignment and tweaking density but no apparent change, it takes quite a while to confirm that changes did / didn't have an effect but can't figure out a pattern without any useful context from the logs
you can try
on it see in what part in crashes.
it looks like there's a .params to invoke triton in isolation so I'll see what context I can grab from it
@drr Usually I just set
ulimit -c unlimited
then run gdb on the executable +
file post-mortem.
So I can just run through the normal flow without worrying about how to call it properly.
thanks, was wondering why I wasn't see a coredump then realized I'm probably not getting one in this case if it's `SIGKILL`:
Copy code
start track assignment
show the segfault ?
right, apparently it was OoM, which makes sense given
, this is in a docker with a host with little apparent memory pressure so when I revisit this, I'll see if there's some docker memory limit I've overlooked
Copy code
[ 4235.939787] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=3b56e41474d323a7ab9fea7036cb3c92854310f00d71c669cddd181b1b40c1a6,mems_allowed=0,global_oom,task_memcg=/docker/3b56e41474d323a7ab9fea7036cb3c92854310f00d71c669cddd181b1b40c1a6,task=TritonRoute,pid=3181,uid=72580522
[ 4235.943285] Out of memory: Killed process 3181 (TritonRoute) total-vm:2803892kB, anon-rss:1901784kB, file-rss:0kB, shmem-rss:0kB, UID:72580522 pgtables:5336kB oom_score_adj:0
[ 4236.184555] oom_reaper: reaped process 3181 (TritonRoute), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
I can try to clone and run it here.
What's the link already ?
Found it. But I never run a design from the caravel, only ever run design in the openlane repo. How do you run it ?
Thanks. I noticed the "2GB limit" in my docker prefs, that's probably not helping! I'll retry after dialing it up For the caravel stuff I'm doing:
./flow_design -design (abspath to path-to-my-repo/openlane/vdp_lite_user_proj)
It can run off either a design name or a full path to whatever has the
probably needs copying to the directory you run that from...there must be a cleaner way to handle
files but haven't tried much with that yet
(reduce.hex is in /vdp/reduce.hex)
Ah yeah, didn't know you could give an absolute path.
still routing ...
~ 3G of ram peak ATM
Running DRC.

Thanks for trying it, so you can atleast get a GDS out of it I no longer have crashes although I did get a yosys error when writing`*.lvs.powered.v` later on in the flow
Copy code
Warning: Identifier `\clknet_7_119_0_wb_clk_i' is implicitly declared.
many like this one here, but since it's working for you and I'm using the yosys in the docker, it might be a version issue. The config.tcl was slightly tweaked compared to what you pulled so I'm rerunning with exactly the same one, I'll see what happens
..ugh it's another SIGKILL actually, time to dial up the memory some more!
yeah, yosys peaked at 7G
Finally completed.
About 70 min.
Copy code
DRC style is now "drc(full)"
Loading DRC CIF style.
[INFO]: COUNT: 964


Number of pins violated: 96
Number of nets violated: 66
So not DRC clean 😕
I guess iterating towards DRC clean is going be most of the effort here, just wish it was faster especially for a design that doesn't seem too complex
shrinking the die area instead of unnecessarily padding it greatly reduced the time pent, similar number of violations though. about 80 antenna violations and a whole lot of these:
Copy code
Poly resistor spacing to poly < 0.48um (poly.9)
interestingly all the magic violations are the same..
I lied, there's also a ton of these, but seem closely related:
Copy code
Poly resistor spacing to diffusion < 0.48um (poly.9)
@drr If you're still getting OoM and you're running under macos, you can click on the docker icon in the menu bar Preferences->Resources and try to add a bit of swap space.
8G seemed to be enough fortunately but the oversize die area was bloating the RAM requirement, I shaved off the excess and it's much faster and less RAM hungry now
yeah, it was rather empty 😅