DREAMPlace: A Placement Engine That Borrows PyTorch's Autograd

The problem DREAMPlace takes on, and who has that problem

Analytical placement is an optimization problem with two competing terms: total wirelength, which pulls connected cells together, and cell density, which pushes them apart so they do not overlap. Classical placers solve this with numerical methods written by hand, and the hand-written parts are where the engineering effort goes. DREAMPlace's premise, stated in the README, is an analogy between nonlinear VLSI placement and deep learning training. If the placement objective is differentiable, then a deep learning framework already knows how to compute its gradients and how to run the optimizer on a GPU.

That framing tells you who the project is for. It is for placement researchers and physical design engineers who want to change the objective, add a term, or test a new solver, without rewriting a numerical kernel in C++. The README also gives the performance motivation: over 30X speedup over the CPU implementation RePlAce in global placement and legalization on ISPD 2005 contest benchmarks with an Nvidia Tesla V100 GPU, and roughly 16X speedup for the integrated detailed placer ABCDPlace on million-size benchmarks against NTUPlace3 on CPU. Those are the authors' published figures, not measurements I have reproduced.

How placement becomes a PyTorch graph

The mechanism is a mapping, not a wrapper. Placement state (cell positions) is held as tensors. The wirelength model and the density model are expressed as tensor operations, so the framework's automatic differentiation produces the gradient of the placement objective with respect to cell coordinates. The optimizer step that a training loop would apply to weights is applied to positions instead.

The density term is where the analogy gets concrete. The README's animation table names four artifacts of a run: a density map, an electric potential map, and an electric field. That is the electrostatic formulation: cells are treated as charge, density overflow is converted into a potential field, and the field's gradient pushes cells toward even distribution. DREAMPlace 3.0, per the publication list, extends this to multi-electrostatics for region constraints, which is the version of the idea that handles designs partitioned into regions rather than one uniform die.

The repository is not Python all the way down. The primary language is C++, and Limbo and Flute are integrated as git submodules. Flute is the rectilinear Steiner minimal tree package used for wirelength estimation. Limbo supplies supporting C++ utilities. The Python layer is the configuration and driver surface; the kernels and the data structures sit in the compiled core, and PyTorch is the runtime that supplies both the tensor abstraction and the GPU execution.

Building it: Docker, or a compiler you have to choose carefully

The README splits installation into Python dependency, build, benchmarks, and run. On dependencies it is unusually prescriptive. Python 3.5 through 3.9. PyTorch 1.6, 1.7, 1.8 or 2.0, with the note that other versions may work but were not tested. Boost 1.55.0 or later, installed and visible for linking. Bison 3.3 or later. GCC is the sharp edge: the README recommends GCC 7.5 with c++17 support and explicitly does not recommend GCC 9 or later because of backward compatibility issues. That is a real constraint on a modern Linux distribution whose default compiler is far newer.

Two build paths are documented: with Docker and without Docker. The Docker path exists precisely because the dependency set is awkward to assemble by hand, and it is the one I would try first. If you build without Docker, the submodules matter. Limbo and Flute must be checked out, and a plain clone that skips submodule initialization will fail at build time rather than at configure time, which makes the error harder to read.

On hardware, the README states the tool runs on both CPU and GPU, and that on a machine without a GPU only CPU support is enabled, using multi-threading. So a GPU is not a hard requirement to get a working binary, but the speedup figures in the README are GPU figures.

Configuration keys and what a run actually looks like

Runs are driven by configuration rather than by long command lines. The README's table of contents lists a Configurations section, and the reference flow diagram in the images directory shows the stages of a DREAMPlace 4.1 run. Because the supplied material is a cleaned README excerpt, I cannot quote the individual key names or their defaults here; they live in that Configurations section and in the JSON configuration files shipped with the repository. Treat the config file as the interface you will actually be editing, and read the shipped examples rather than guessing key names.

What the README does establish about the run surface: global placement and legalization are the stages the 30X figure refers to, and detailed placement is handled by ABCDPlace, which is integrated rather than separate. ABCDPlace is described as batch-based and concurrent, running on multi-threaded CPUs and GPUs, which is why its speedup is quoted against a sequential placer. Benchmarks are not bundled. The README has a How to Get Benchmarks section, and the published results are on ISPD 2005 contest benchmarks, so you will be fetching benchmark data before you can reproduce anything.

Where DREAMPlace is the wrong tool

The dependency pinning is the first failure mode. If your environment is Python 3.10 or newer, or your toolchain defaults to GCC 9 or later, you are outside the tested range and the README says so directly. You can try, and the README allows that other versions may work, but you are on your own for build errors.

The second limitation is scope. DREAMPlace is a placer. It is not a router, and it is not a timing analysis engine. The README's own recommendation points elsewhere for broader coverage: it suggests HeteroPlace for GPU-accelerated placement and routing on industrial designs. That recommendation is the clearest signal that the authors see DREAMPlace as one stage of a flow rather than a flow.

The third is the research-tool pattern. The publication list maps versions to papers: 2.0 for open-source GPU global and detailed placement, 3.0 for multi-electrostatics with region constraints, 4.0 for timing-driven placement with momentum-based net weighting, 4.1 for second-order information in mixed-size placement, and 4.3 corresponding to HeteroSTA, a CPU-GPU static timing analysis engine. Each version is a research contribution. That means the interesting behaviour is documented across conference and journal papers, and the README is an index to them rather than a manual. If you need a placer with a support contract and a regression suite, this is not that.

The alternative, and the actual difference in approach

RePlAce is the CPU baseline the README measures against, and it is the honest comparison because it is the same algorithmic family: nonlinear analytical placement with a density penalty. The difference is implementation strategy, not formulation. RePlAce implements its numerical kernels directly, in C++, tuned for CPU execution. DREAMPlace expresses the same objective in a differentiable programming framework and lets PyTorch supply the gradient computation and the GPU kernels. The 30X figure is the gap that strategy produces on the stated benchmark set and hardware.

NTUPlace3 is the second baseline, and it is a different kind of comparison. It is a sequential detailed placer, and ABCDPlace is measured against it at roughly 16X on million-size benchmarks. The difference there is parallelism: ABCDPlace batches independent detailed placement moves so they can run concurrently on multi-threaded CPUs or a GPU, whereas a sequential placer processes moves one at a time. Note the asymmetry in the README's own framing: the global placement comparison is GPU against CPU, while the detailed placement comparison is described as GPU-accelerated against a CPU placer. Read the hardware column before quoting either number.

Maintenance, versions and the licence

There are no releases retrieved for this repository, so versioning is by branch and by paper rather than by tagged artifacts. The default branch is master and the last push recorded is 2026-07-18, so the project is not archived and is still receiving commits. The practical consequence of a release-less repository is that pinning a known-good state means pinning a commit hash, and the submodules (Limbo and Flute) have their own histories that you also need to pin. Upgrading means re-reading the paper for whichever version number you are moving to, because the version numbers are paper identifiers.

The licence is BSD-3-Clause. That is a permissive licence, which generally means you can use, modify and redistribute the code including in proprietary products, subject to the conditions the licence text sets out, typically around retaining the copyright notice and disclaimer. This is a description of the licence family, not legal advice. If you are shipping DREAMPlace inside a commercial tool, read the LICENSE file in the repository and the licences of the bundled submodules, Limbo and Flute, since those are separate components with their own terms.

Editorial conclusion

Adopt DREAMPlace if you are doing placement research or need a scriptable placer you can modify at the objective-function level, and you have a machine that matches the documented Python 3.5 to 3.9, PyTorch 1.6 to 2.0 and GCC 7.5 range with Boost and Bison installed. Do not adopt it if you need a supported commercial flow, a Windows build, or a placer whose timing engine covers industrial designs; the README points at HeteroPlace for that. Before committing, clone with submodules, confirm Limbo and Flute actually populated, and run the CPU-only build first to separate compiler problems from CUDA problems.

Official sources

1. Issues
2. License: BSD-3-Clause
3. limbo018/DREAMPlace on GitHub
4. README