@User@User would it make sense to rearrange our steps so we fail as early as possible on a bad run, eg moving the klayout steps and xor comparisons later on. I've even moved the LVS checking before magic DRC for now because it takes less time to execute and catches obvious issues.
01/29/2021, 2:20 PM
@Anton Blanchard (cc: @Ahmed Ghazy): I'm open to the idea specially with the runtime differences. But, a counter argument would be why would you run LVS on a design that is not DRC clean, and with the introduction of flow quitters eventually the flow will be aborting when any violations are found and so the counter argument would make more sense. Still, the runtime difference (speedup) is something to consider.
@Anton Blanchard: However, we can definitely move the Klayout functions to the end, since at the moment they are just there for show without a real benefit.
01/30/2021, 2:36 PM
Hmm, from my point of view, LVS and DRC are independent checks, so we could theoretically even run them in parallel, given that there are enough ressources. Hmm, can we estimate how much RAM LVS and DRC checks will take? I am afraid that both might fail if the RAM demand of both checks exceeds the available ressources. But perhaps an opt-in for parallelisation through an environment variable might be good?
Hmm, would it be possible to freeze a docker container in case of low memory, so that docker writes its contents to disk, and when the other parallel job completed it continues operation?
That way we could run several docker containers in parallel, but it would not necessarily fail in case of memory exhaustion?