The-OpenROAD-Project / The-OpenROAD-Project/OpenROAD-flow-scripts
`openroad` binary in official `openroad/orfs` Docker images crashes with SIGILL (illegal instruction) in CTS on any CPU without AVX-512
Nobody has claimed this yet.
- Dominant language
- Verilog
- Stars
- 748
- Forks
- 525
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 56
Description
Subject
[Build] / Docker images (also affects the prebuilt binaries — see #4105)
Describe the bug
The openroad binary shipped in the official openroad/orfs Docker images
executes an AVX-512 instruction somewhere in the CTS stage. On any CPU without
AVX-512 the flow runs normally through synthesis, floorplan, placement, and
post-placement resizing, then dies deterministically at the start of CTS:
Error: cts.tcl, 83 child killed: illegal instruction
Elapsed time: 0:02.26[h:]min:sec. CPU time: user 1.89 sys 0.28 (96%). Peak memory: 140276KB.
make[1]: *** [Makefile:511: do-4_1_cts] Error 1
make: *** [Makefile:511: results/nangate45/gcd/base/4_1_cts.odb] Error 2
This is not an "old hardware" problem: it reproduces on AMD EPYC 7542 (Zen 2,
2019 datacenter part) and EPYC Milan-class Kubernetes nodes. No AMD CPU before
Zen 4 (late 2022) has AVX-512, and Intel removed it from consumer parts from
Alder Lake on — so the images are unusable on a large fraction of modern
machines, failing with a message that (per #4105) gets read as user error.
Evidence that it is specifically the image build, and specifically AVX-512:
- Every design fails identically at CTS in the image on non-AVX-512 hosts
(tested nangate45/gcd, nangate45/black_parrot, nangate45/mempool_group,
asap7/swerv_wrapper — tiny gcd traps ~2 s intoclock_tree_synthesis). - The same image runs the same designs through CTS and detailed routing
without issue on Intel Xeon nodes that have AVX-512 (verified on 2 different
AVX-512 nodes vs 4 different non-AVX-512 nodes, both AMD and older hardware,
on the NRP Nautilus Kubernetes cluster). - A native build of the same ORFS commit (
a5ff7ef7d, OpenROAD submodule
6b9d7fb806) on the same AVX-512-less EPYC 7542 host runs all of these
designs through the full flow with no issue (several hundred completed runs). - All flow stages before CTS run for hours in-image on the affected CPUs, so
the binary is not globally miscompiled — a specific code path reached first
in CTS (TritonCTS itself or a dependency kernel compiled with AVX-512,
e.g. an-march=native/ build-host-autodetected object in the image build)
contains the offending instructions.
Issue #4105 reports the same signature (cts.tcl ... child killed: illegal instruction, 26Q1 prebuilt binaries) and went stale without a root cause —
this is very likely the same defect.
Expected Behavior
Official images/binaries should run on the x86-64-v3 baseline (AVX2) that the
rest of the binary already targets — either by compiling the whole image at a
portable -march, or using runtime dispatch for any AVX-512 kernels.
Environment
- Images tested, both failing identically on the same host:
docker.io/openroad/orfs:26Q3-54-ga5ff7ef7d
(digestsha256:a6140cf4dc568e10238356f67b9fd73b9074955eeda6f2ee126bc60f5d7fc3ac)docker.io/openroad/orfs:latestas of 2026-07-25 (26Q3-209; its openroad
reports26Q2-209-g0d9d73ffba) — fails atcts.tcl, 82with the same
SIGILL, so current images are still affected.- #4105 shows the same signature on 26Q1 prebuilt binaries.
- Failing hosts: AMD EPYC 7542 (Zen 2) / Ubuntu 24.04 / docker 27.x; AMD EPYC
Milan-class and pre-AVX2 Kubernetes nodes (NRP Nautilus). - Working hosts (same image, same commands): Intel Xeon nodes with AVX-512.
To Reproduce
On any machine whose /proc/cpuinfo has no avx512 flags (any AMD before
Zen 4, any Intel consumer CPU from 12th gen on):
docker run --rm docker.io/openroad/orfs:26Q3-54-ga5ff7ef7d bash -c \
'source ./env.sh; cd flow && make DESIGN_CONFIG=./designs/nangate45/gcd/config.mk cts'
Fails in ~3 minutes total (~2 s into the CTS stage) with
Error: cts.tcl, 83 child killed: illegal instruction. The same command on an
AVX-512 machine completes.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the failure with the documented docker run command and inspect cts.tcl around the reported child failure and Makefile target do-4_1_cts. Compare the official image build with the native build and trace the OpenROAD submodule or dependency used by CTS for AVX-512-specific compilation. Done means the official image completes CTS on the stated non-AVX-512 hosts while retaining the x86-64-v3 baseline.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, linux
- Domain
- build-system, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100