Reproduce Issue

[heatingma]

Hi, thanks for open-sourcing DREAMPlace. I notice that the README states:

If your results deviate significantly (i.e., >5% longer HPWL) from the following numbers, something may be wrong.

and reports the following results for DREAMPlace 4.1.0 on ISPD2005:

Benchmark	Iterations	HPWL(x10^6)	Time(s)
adaptec1	748	68.2	27.6
adaptec2	784	86.3	40.1

I have tried to reproduce these results using the current GitHub version (cloned on 2026-05-14), following the installation instructions in the repository. Then I have used the default test JSON configurations provided in the repo. However, the reported HPWL values I obtained are:

Benchmark	Iterations	HPWL(x10^6)	Time(s)
adaptec1	605	72.8	10.4
adaptec2	649	81.9	12.4

The runtime seems faster than the README table, and I want to know whether the difference in results and time is caused by the version update (4.3.0 vs 4.1.0).

Thanks!

[heatingma]

adaptec1.log
adaptec2.log

[limbo018]

According to your log, the use_bb and macro_place_flag have not been turned on. These options are the feature for DREAMPlace 4.1. You may need to explicitly turn them on.

[heatingma]

Hello, after setting use_bb and macro_place_flag to 1, the results actually became worse. In addition, the latter (macro_place_flag) seems to have no effect on ISPD2005, since all the macros are fixed. See dreamplace/PlaceDB.py:

self.total_movable_macro_area = total_movable_macro_area
self.total_movable_cell_area = total_movable_cell_area
# if no movable macro, turn off macro place flag
if total_movable_macro_area <= 0:
    params.macro_place_flag = False

[limbo018]

I got confused. Are you testing macro placement or standard cell placement? Are you using any of the benchmarks downloaded from the following:

[Constwelve]

It seems you are running the original ISPD2005 benchmark without movable macros. The provided reference results are for macro placement, where all macros are allowed to move. Therefore, the difference in results is reasonable.

[Constwelve]

Your results are similar to those reported in the DREAMPlace paper: https://yibolin.com/publications/papers/PLACE_CSTIC2020_Lin.pdf. I think there is no reporduce issue.

[heatingma]

Yes, I am running the original ISPD2005 benchmark without movable macros. I have realized that I had overlooked the statement all fixed macros and IO pads regarded as movable macros. My reproduction results are basically consistent with those in the paper: https://yibolin.com/publications/papers/PLACE_CSTIC2020_Lin.pdf

[heatingma]

Hello, I’ve recently been trying to use DREAMPlace, and I may continue to ask questions regarding reproducing results. This time it’s about the MMS dataset. Here are my reproduction results.

adaptec1 65085622.0
adaptec2 74422325.0
adaptec3 152686985.0
adaptec4 141583983.0
bigblue1 85400797.0
bigblue2 124860004.0
bigblue3 272153006.0
bigblue4 647132372.0
newblue1 56989763.0
newblue2 149114799.0
newblue3 260481700.0
newblue4 176571619.0
newblue5 324821193.0
newblue6 387927988.0
newblue7 854150476.0

The configuration file is based on mms, with the addition of use_bb: 1 and macro_place_flag: 1 required for version 4.1.0.

It seems that the results of NewBlue are much better than the results in current table.

[heatingma]

When I conduct experiments on ISPD2005, I find that the placement results did not seem to strictly adhere to the chip space provided by the .scl files. For example, for bigblue3, the position of o1079817 in the placement result is (4041, 136), and the cell size is (16, 12). However, from the .scl file, we can see:

CoreRow Horizontal
  Coordinate    :   136
  Height        :   12
  Sitewidth     :    1
  Sitespacing   :    1
  Siteorient    :    1
  Sitesymmetry  :    1
  SubrowOrigin  :    7807	NumSites  :  19620
End

I would like to know why this is the case. Is it because DreamPlace does not strictly follow the chip layout defined in the .scl file during legalization, but instead performs a certain degree of approximation? For instance, treating the chip space as a complete rectangle?"

[limbo018]

o1079817

For bigblue3, some of the rows start from x = 335, while some of the rows start from x = 7807. The legalization engine does not honor part of the rows and will extend the placement space into a rectangular box. This is because the bookshelf parser is not so complete.

[limbo018]

Hello, I’ve recently been trying to use DREAMPlace, and I may continue to ask questions regarding reproducing results. This time it’s about the MMS dataset. Here are my reproduction results.

adaptec1 65085622.0
adaptec2 74422325.0
adaptec3 152686985.0
adaptec4 141583983.0
bigblue1 85400797.0
bigblue2 124860004.0
bigblue3 272153006.0
bigblue4 647132372.0
newblue1 56989763.0
newblue2 149114799.0
newblue3 260481700.0
newblue4 176571619.0
newblue5 324821193.0
newblue6 387927988.0
newblue7 854150476.0
The configuration file is based on mms, with the addition of use_bb: 1 and macro_place_flag: 1 required for version 4.1.0.

It seems that the results of NewBlue are much better than the results in current table.

Can you attach the log for newblue1?

[heatingma]

newblue1.log
newblue4.log

[Constwelve]

Hi @heatingma — re-ran all 16 MMS designs on TITAN RTX (current master, CUDA 11.8 / torch 2.0.1, use_bb=1,
macro_place_flag=1).

Key finding: the reproducibility gap comes from target_density. The shipped per-design JSONs at
install/test/mms/.json use different target_density values (adaptec1–4 / bigblue1–4 = 1.0, but
newblue1/2/3/6/7 = 0.8–0.9, newblue4/5 + adaptec5 = 0.5). The reference numbers you're comparing against were
produced with target_density = 1.0 everywhere — visible in the parameters dump at the top of the attached
newblue1.log ('target_density': 1.0, even though the shipped JSON for newblue1 ships with 0.8).

When I override every design to target_density = 1.0, the numbers line up:

│ design │ mine ×10⁶ │ ref ×10⁶ │ Δ │
│ newblue1 │ 57.16 │ 56.99 │ +0.3 % │
│ newblue2 │ 149.13 │ 149.11 │ +0.0 % │
│ newblue3 │ 312.81 │ 260.48 │ +20.1 % │
│ newblue4 │ 176.75 │ 176.57 │ +0.1 % │
│ newblue5 │ 324.68 │ 324.82 │ −0.0 % │
│ newblue6 │ 388.08 │ 387.93 │ +0.0 % │
│ newblue7 │ 855.04 │ 854.15 │ +0.1 % │

15 of 16 within ±0.7 %. Build is reproducible — the previous "deviation" was just the shipped JSON defaults
differing from the config the reference was generated with.

newblue3 is the remaining outlier; it's macro-area-dominated (macro/cell area ≈ 13.6), so the macro-placement
step lands in a different basin. Probably seed/numerical sensitivity on that one design, not a build issue.

For your original adaptec1 = 72.8 M vs README 68.2 M, that's the ISPD2005free table (different setup). If you
share that JSON we can re-run there — but I'd bet on the same target_density story.