ISPD 2011 Routability-driven Placement Contest and Benchmark Suite

[Announcements] [Contest Benchmarks and Results] [Contact Information] [Schedule] [Submission Information] [Evaluation and Ranking] [Utility Scripts] [Participating Teams] [Frequently Asked Questions] [Benchmark Format] [Call for Participation]


ISPD-2011 Benchmark Suite and Contest Results (Released Apr 01, 2011)

Please cite the following paper when using these benchmarks:
Natarajan Viswanathan, Charles J. Alpert, Cliff Sze, Zhuo Li, Gi-Joon Nam and Jarrod A. Roy, "The ISPD-2011 Routability-Driven Placement Contest and Benchmark Suite," In Proc. ACM International Symposium on Physical Design, pages 141-146, 2011.

  1. superblue18
  2. superblue4
  3. superblue15
  4. superblue12
  5. superblue5
  6. superblue10
  7. superblue1
  8. superblue2

ISPD-2011 Contest Presentation with Results: ISPD_2011_Contest.pdf

ISPD-2011 Contest Placement Files:

Contact Information


Nov 25, 2010 Contest website is up with instructions
Release benchmark 1 to all teams
Dec 09, 2010 Release benchmark 2 to all teams
Feb 07, 2011 Receive alpha (preliminary) binaries from all teams
NOTE: If a team is not able to generate valid placement solutions on the four
benchmarks by this deadline, they will not go forward in the contest.
Update: Mar 11, 2011 Receive final binaries from all teams
Mar 27-30, 2011 ISPD 2011, Announce contest results

Submission Information

  1. Please try to submit a static binary as it helps with portability.
  2. Each team is allowed to submit a single binary that should run on all benchmarks.
  3. For this contest we would like to evaluate single-threaded versions of the placement algorithms. Hence, no parallel implementations are allowed.
  4. No precomputed information can be used to influence the current run. The run directory will be cleaned prior to each run.
  5. Using third-party tools (e.g. solvers, etc.,):
    If you want me to install third-party tools to run your placer, you need to mention it as part of your initial submission. Please note, I can only install publicly available tools. No proprietary tools can be installed.
  6. Purpose of alpha (preliminary) binary submission:
    The purpose of the alpha binary submission is two-fold: (a) to verify that I can run your binary on the contest machine. I will work with you and try to make it run on my side in case there are any issues, (b) to test that your binary is able to produce legal placement solutions on the released benchmarks.
  7. Memory limit per job: 8GB (= max allowed memory to run a benchmark)
  8. Machine configuration for the contest:
    • OS: Red Hat Enterprise Linux. Kernel release: 2.6.18-92.el5
    • CPU: 64-bit Intel(R) Xeon(R) CPU X7350 @ 2.93GHz
    • GCC version: gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)
      Target: x86_64-redhat-linux
    • Information from /proc/cpuinfo:
          processor       : 0
          vendor_id       : GenuineIntel
          cpu family      : 6
          model           : 15
          model name      : Intel(R) Xeon(R) CPU X7350  @ 2.93GHz
          stepping        : 11
          cpu MHz         : 2932.032
          cache size      : 4096 KB
          physical id     : 3
          siblings        : 4
          core id         : 0
          cpu cores       : 4
          fpu             : yes
          fpu_exception   : yes
          cpuid level     : 10
          wp              : yes
          flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
                            clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc 
                            pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
          bogomips        : 5867.04
          clflush size    : 64
          cache_alignment : 64
          address sizes   : 40 bits physical, 48 bits virtual
          power management:

Evaluation and Ranking

Golden Router(s):

Contest Evaluation Script:

Evaluation Metric:

Utility Scripts

Participating Teams

Placer Team Members Affiliation
SimPLR Myung-Chul Kim, Dong-Jin Lee, Jin Hu, Igor Markov University of Michigan
Ripple Xu He, Tao Huang, Linfu Xiao, Haitong Tian, Guxin Cui, Evangeline F.Y. Young The Chinese University of Hong Kong
RADIANT Meng-Kai Hsu, Sheng Chou, Tzu-Hen Lin, Yao-Wen Chang National Taiwan University
NTHUplacer Hsiu-Yu Lai, Yuan-Kang Chuang, Hsueh-Ju Chou, Shao-Huan Wang, Tien-Yu Kuo and Yu-Yi Liang National Tsing Hua University
mPL11 Jason Cong, Guojie Luo, Kalliopi Tsota, Bingjun Xiao UCLA
sc Sifei Wang, Xin Wu, Liu Liu, Haixia Yan, Qiang Zhou Tsinghua University
VDAPlace Sean Liu, Ching-Yu Chin, Chun-Kai Wang, Po-Cheng Pan, Jerry Lee, Du-Hsung Tsai National Chiao Tung University
CPP Jui-Hung Hung, Tsu-Yun Hsueh, Moses Lee, Hsiang-Hui Yang, Tsung-Yen Chang, Yao-Kai Yeh Chung Yuan Christian University
NCKUplacer Chao-Jam Hsu, Cheng-En Lu, Po-Chia Chen, Chung-Lin Lee, J.-M. Lin National Cheng Kung University

Frequently Asked Questions

  1. Since the overall runtime is part of the evaluation metric, I wonder what type of platform is used to run the binaries. How many cores are available? Is there a GPGPU for acceleration?
    For this contest we would like to evaluate single-threaded versions of the placement algorithms. Although run-time is going to be part of the evaluation metric it is not the primary / dominant metric on which the placers will be evaluated. The primary metric is going to be the routability of the placement(s), as measured using the golden routers / congestion analyzers. Having said that, we want a placer to get a good solution in a reasonable amount of run-time. Hence we are bringing the run-time into the evaluation metric. In other words, we would not expect any placer to get a significant advantage if it is extremely fast compared to say, the median run-time of all the placers participating in the contest.

  2. Is cell flipping / rotation allowed?
    No. For this contest cell flipping / rotation is not allowed. All cells will be assumed to be in their default orientation.

  3. How do I handle non-rectangular nodes during placement and routing?
    During placement, for each non-rectangular node, you need to use the constituent shapes in the "circuit.shapes" file to determine the overlapping bins, and adjust their density, etc. In addition, for overlap calculation (legality checking) you should use the constituent shapes of the node. For routing, the routing blockage section in "circuit.route" file gives all the nodes that serve as blockages. Quite a few of them are non-rectangular nodes. For those nodes you need to use the constituent shapes in the "circuit.shapes" file to figure out the tile overlap and associated edge capacities.

  4. What is Sitewidth and Sitespacing? In our understanding, Sitespacing is the minimum space between two nearby standard-cells. Is that correct?
    Sitewidth refers to the width of a "placement" site, and Sitespacing refers to the spacing between adjacent "placement" sites. Please note Sitespacing does not refer to the minimum space between adjacent standard-cells. In other words, two standard-cells can abut with each other. But the lower-left x-coordinate (or left boundary) of every standard-cell must be placed on a location that is a multiple of the SiteSpacing. Please refer to the figure below for a legal placement.
    Cell Placement

  5. Can we assign a macro in between rows?
    All macros and standard-cells should be aligned to the circuit rows. For this contest there will no movable macros. All movable nodes will only be standard-cells, and they should be placed within the circuit rows as shown in the figure above.

  6. How to determine the total number of routing tracks per tile edge?
    The benchmark format follows the convention laid out in the ISPD 2008 routing contest. Essentially, for each tile edge, the "VerticalCapacity" or "HorizontalCapacity" values per layer give a measure of the total available space per tile edge. They are not the total number of global routing tracks per tile edge. Hence, if the capacity for a particular layer is 80, and the minimum wire width and spacing are both 1, this corresponds to 80 / (1+1) = 40 minimum width tracks per tile edge.
    For the following configuration:
    VerticalCapacity : 0 80 0 80 0 80 0 80 0
    HorizontalCapacity : 0 0 80 0 80 0 80 0 80
    MinWireWidth : 1 1 1 1 2 2 2 4 4
    MinWireSpacing : 1 1 1 1 2 2 2 4 4
    Number of global routing tracks per tile edge:
    M1: 0/(1+1) = 0
    M2-M4: 80/(1+1) = 40 (for whichever capacity is not zero)
    M5-M7: 80/(2+2) = 20 (for whichever capacity is not zero)
    M8-M9: 80/(4+4) = 10 (for whichever capacity is not zero)

  7. Is the routing capacity of a tile related to the tile width or height?
    The routing capacity of a tile is not related to the tile width or height in any manner.

  8. What about pin layers? In "circuit.route" file, layers are defined for some pins. What should be the metal layer for other pins?
    For any node that does not appear in the circuit.route file (under the Terminal_NI section), all its pins should be considered to be on M1 (default).

  9. For routing, if multiple blockages intersect/overlap with a tile edge how should the capacity of the tile edge be calculated?
    If multiple blockages intersect/overlap with a tile edge, then the capacity of the edge should reflect the total space blocked by all the blockages.

  10. For the blockages, Should I consider blockage edges as a blockage or just edges inside the blockage are considered a blockage? The figure doesn't show this.
    The following figure gives a more detailed description of the blockage map construction (tile edge capacity adjustment):
    Blockage Map

  11. Regarding the offsets in the "circuit.nets" file, are the numbers in terms of number of tiles/bins? Or should I just add them to the node center (computed from .nodes and .pl) to find pin coordinates?
    The pin-offsets in the "circuit.nets" file are not in terms of the number of tiles/bins. They are absolute values from the center of the node. You should just add them to the node center to get the pin coordinates.

  12. What is Siteorient and Sitesymmetry?
    Siteorient and Sitesymmetry are used to specify the orientation of the standard-cells. For the contest no flipping or rotation is allowed. All cells will need to be placed in their default orientation. Hence, you do not have to consider these two parameters.

Benchmark Format

The detailed description of the benchmark format can be found in this file: Benchmark_Format.pdf. Teams are advised to read this file as it has important information regarding the benchmark format, including new features for both placement and routing.

Call for Participation

Registration for the contest is closed.
For the contest announcement and call for participation, please see pdf or txt.