open-source-silicon.dev

`child killed: segmentation violation` during `or_route.tcl` - is this a design problem or a bug?

Well ... possibly both.
A tool should never crash with a segmentation violation, but usually here it does that because of some issue and really it should have exited with an error message instead of a  crash.

<@U01837QU37V> I'm getting the same errors you did/are, starting with `detailed placement failed`. I worked around that the same as you did by setting `PL_RANDOM_GLB_REPLACEMENT` to 1. However, this resulted in the same segmentation violation you had. Coincidentally, I was watching my RAM usage and just before the segment fault occurred, it spiked to max. Seems like random placement may not be the way to fix the detailed placement issues. Have you identified any other workaround for those?

<@U01FA0DGYGN> Are you using some macros by any chance ?

Are you referring to verilog macros as in: ``define macroname(ARGS) macrotext` ?

No, I'm referring to pre-built IP inserted as blocks in the design. But I guess that's a "no" then.

I was watching my RAM usage but never saw it spike before crashing, so I don't think it was an out of memory error. My machine has 128 GB and it sat around 11 GB during the run (but Chrome is 90% of that)

what i've learned is that detailed placement is very finnicky, and cannot handle large moves in order to find a solution. it tends to "smear" out cells near where they're deposited by initial placement

the problem is that initial placement is somewhat intelligent _unless_ you do random

Yeah detailed placement has sort of a maximum radius on purpose. Basically global placement is supposed to put things vaguely organized based on their function / connectivity and then detailled placement legalizes that without scrambling it too much.

right, yeah that makes a lot of sense. the problem i have is that i have to "intelligently" move cells that are deposited on top of other macros somewhere else such that they can still be `detailed_placement`ed and so that `or_route` will work.

<@U016HU5HK8V>’s script somewhat intelligently moves cells to the middle of where the connected cells are, but this might need a couple of passes to work, and in my design didn't

yeah, that's sort of what I did with my 'forrbid area' script except it's not so smart :stuck_out_tongue:

i ended up just translating cells by half the width or height of the design, using what i know about where my cells are

really though this problem can only be properly solved in the algorithm that does initial placement

in any case i found that routing didn't crash when cells weren't too far from where they were supposed to be

yeah, the initial placement can actually take a constraint file I think but I didn't investigate.

oh really? i'll have a look into it. i doubt we'll make this deadline now anyway

Has this placement problem been reported on the openlane github with an open issue? If not, should it be reported?

it should be. I believe Amr and Ahmed are aware but probably very busy on other stuff, so it would be good to document. i'm more interested in finding a workaround right now though