Does OpenLane correct those violations automatically?

Leviathan, No not automatically. (This is the result after the tool is done.) They are violating max fanout which means they are high load nets that will switch slowly. This can present as 3 different problems in real silicon: 1 sensitive to adjacent nets switching fast which can cause coupling and delay changes. 2 they could be the victim of a rapidly switching adjacent net causing a logic glitch. While these numbers are much worse than normal recommendations they are not in the territory where you are likely to fail. (So up to you if you resolve them or not.))3 they can/may fail max delay in sta also. If you care about speed these should be fixed. IFF you do not care about speed then I would focus at this point on HOLD timing violations and getting a functional design.

Thanks a lot for the analysis! We can live with slower things for now. But for a 24-hour no-human-in-the-loop solution we should develop an automated way to deal with the fanout, I think we could either add buffers in the outputs (if they aren't too slow), or we could duplicate the cells and drive them from the same inputs, and spread the outputs across the duplicated cells.

interacting with several teams and multiple designs go through the tools has helped us Id several issues for immediate improvement in the flows.

We did some "optimizations" and the question is, whether this has any chance of ever working?