# Non-determinism with OpenROAD **URL:** \ **Category:** Developers\ **Created:** [March 25, 2026, 2:44pm UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132 "2026-03-25T14:44:01Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![gudeh](https://avatars.discourse-cdn.com/v4/letter/g/f4b2a3/32.png) [@gudeh](https://yosyshq.discourse.group/u/gudeh)\ **Post date:** [March 25, 2026, 2:44pm UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/1 "2026-03-25T14:44:01Z")
Hey there, there might a non-determinism happening with yosys. The following screenshots are from OpenROAD at the Yosys stage, both logs should have no differences among them. They come from a pair of runs with a no-op branch. I would hope for some guidance on how to investigate further. We seem to be using a different instance master at message 23.10 for Mapping module With sky130hd/microwatt: ![image](https://global.discourse-cdn.com/free1/uploads/yosyshq/original/1X/f28913eae0720fc9ba00d9adbd9572ec41111b7a.png) I also created an issue in OpenROAD GH for this at: [Yosys non-determinism · Issue #9943 · The-OpenROAD-Project/OpenROAD · GitHub](https://github.com/The-OpenROAD-Project/OpenROAD/issues/9943) ---
**Author:** ![KrystalDelusion](https://avatars.discourse-cdn.com/v4/letter/k/8baadc/32.png) [@KrystalDelusion](https://yosyshq.discourse.group/u/KrystalDelusion)\ **Post date:** [March 26, 2026, 4:15pm UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/2 "2026-03-26T16:15:43Z")
Are these both on the same system or two different systems? And is it the same input for both (not equivalent, but identical)? [Both of those have existing issues](https://github.com/YosysHQ/yosys/issues?q=is%3Aissue%20state%3Aopen%20determinism) ---
**Author:** ![gudeh](https://avatars.discourse-cdn.com/v4/letter/g/f4b2a3/32.png) [@gudeh](https://yosyshq.discourse.group/u/gudeh)\ **Post date:** [March 26, 2026, 4:59pm UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/3 "2026-03-26T16:59:10Z")
Yes, the same system and the same input. I was able to reproduce locally. My colleague also observed the behavior, he created the issue: [[Synthesis] nangate45/swerv\_wrapper QoR fluctuation due to Yosys abc\_new nondeterminism · Issue #4056 · The-OpenROAD-Project/OpenROAD-flow-scripts · GitHub](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues/4056) And he was able to make a workaround at: [synth: Add sort before ABC to avoid nondeterminism (workaround) by openroad-ci · Pull Request #4058 · The-OpenROAD-Project/OpenROAD-flow-scripts · GitHub](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/4058). He mentioned: “`abc_new` visits modules in `dict` insertion order which can vary between runs” ---
**Author:** ![KrystalDelusion](https://avatars.discourse-cdn.com/v4/letter/k/8baadc/32.png) [@KrystalDelusion](https://yosyshq.discourse.group/u/KrystalDelusion)\ **Post date:** [March 26, 2026, 7:23pm UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/4 "2026-03-26T19:23:14Z")
Looking at the `synth.tcl`, this is (potentially) the second `abc` run. Do you know if this is being produced with or without the `SYNTH_RETIME_MODULES` enabled? (more specifically, is this the first or second run of ABC). AFAIK if you’re using the same inputs, ABC should be the only thing that could change the insertion order (since it could be running in parallel and the order could depend on the order that ABC processes return). ---
**Author:** ![KrystalDelusion](https://avatars.discourse-cdn.com/v4/letter/k/8baadc/32.png) [@KrystalDelusion](https://yosyshq.discourse.group/u/KrystalDelusion)\ **Post date:** [March 27, 2026, 1:31am UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/5 "2026-03-27T01:31:35Z")
@widlarizer you’re probably more familiar with topological sorting than I am. What happens when `Toposort::sort()` is called with topologically equivalent cells? Do they maintain their original sorting? Is there a benefit to (optionally?) introducing a fallback sort so that topologically equivalent modules have a canonical sort (e.g. by ID)? This issue does seem to disappear when calling `design->sort()` before the call to `order_modules()` in `abc_new.cc`, though I’m unclear what is causing the modules to be stored in a different order (as far as I can tell the Yosys runs are equivalent up to the iterating through the modules, at least as far as `yosys -X` output is concerned) so as much as I would prefer to identify and resolve the source of the change in order, just canonicalizing the order instead may be the easier approach. ---
**Author:** ![widlarizer](https://avatars.discourse-cdn.com/v4/letter/w/bbce88/32.png) [@widlarizer](https://yosyshq.discourse.group/u/widlarizer)\ **Post date:** [March 27, 2026, 10:47am UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/6 "2026-03-27T10:47:07Z")
I checked and abc only gets called once in the report. Something is wrong. Sorting harder is not a solution, everything prior to abc should be deterministic so we have figure out what isn’t and fix it rather than hiding it. The canonicalized inputs are also equal, no src attribute polution or anything. I’ll see, could be related to opt parallelization, but not necessarily, we fuzzed all that I think ---
**Author:** ![mliberty](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@mliberty](https://yosyshq.discourse.group/u/mliberty)\ **Post date:** [March 27, 2026, 2:47pm UTC](https://yosyshq.discourse.group/t/non-determinism-with-openroad/132/7 "2026-03-27T14:47:02Z")
I believe Jaehyun / Codex has traced this down to using a std::set of pointers which gives iterations of modules in a non-deterministic order.