Announcements

• Apr 01, 2011 (FRI):
  Released the "official" ISPD-2011 Benchmark Suite. Please look under the Contest Benchmarks and Results section. Please delete all previous benchmark files.
  Released the ISPD-2011 contest presentation with results. Please look under the Contest Benchmarks and Results section.
  Released the final placement (.pl) files from all the teams. These placement files correspond to the contest results.
  
  
• Feb 22, 2011 (TUE): Released benchmarks 3 and 4 to all teams.
• Feb 21, 2011 (MON): Released finalized version of coalesCgrip. Please check the VERSION file in the top-level directory. It should say: "coalesCgrip V1.3".
• Feb 11, 2011 (FRI): Released first "golden" router, contest evaluation script and evaluation metric. Please look under the Evaluation and Ranking section.
• Feb 11, 2011 (FRI): Updated the vertical and horizontal capacity values in the "pnr18.route" and "pnr04.route" files with the lines below:
  VerticalCapacity : 0 60 0 60 0 60 0 56 0
HorizontalCapacity : 0 0 60 0 60 0 60 0 56

• Feb 11, 2011 (FRI): Final binary submission deadline is extended to Mar 11, 2011.. Please note, this is a hard deadline as I will need time to evaluate your binaries on other circuits of the benchmark suite for the contest.
• Jan 19, 2011 (WED): Released important submission guidelines including contest machine configuration.
• Jan 18, 2011 (TUE): Released script to check for placement legality.
• Dec 29, 2010 (WED): Corrected error in benchmark pnr04. Released corrected version of benchmark pnr04 to all teams.
• Dec 09, 2010 (THU): Released benchmark 2 to all teams.
• Nov 25, 2010 (THU): Contest website is up with instructions. Release benchmark 1 to all teams. Please read the file "Benchmark_Format" under Benchmark Format. This has important information regarding the benchmark format, including new features for both placement and routing.

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:

• CUHK_Ripple
• UCLA_mPL11
• UMich_SimPLR
• NTU_Radiant
• Tsinghua_SC
• NCTU_VDAPlace
• NCKU_NCKUplacer
• NTHU_NTHUplacer

Contact Information

• This year the contest will be administered by Natarajan Viswanathan from IBM. Please send all emails regarding the contest to nviswan@us.ibm.com.
• Please add "ISPD2011_Contest" to your subject line to get a quick response from the contest administrator!

Schedule

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):

• coalesCgrip, Hamid Shojaei and Dr. Azadeh Davoodi, University of Wisconsin, Madison.
  Feb 21, 2011: Finalized version of coalesCgrip. Version: coalesCgrip V1.3
• Notes:
  1. This tool requires the IBM ILOG CPLEX optimization tool. Please refer to the coalesCgrip website and IBM ILOG CPLEX Optimization Studio for Academics for details about obtaining an academic license.
  2. You should download the following two files from the IBM website to install and work with CPLEX: (a) cplex_studio122.acad.linux-x86.bin (b) access.ilm.
  3. If you want to compile/link the library version of coalesCgrip then you need to use the version compatible with gcc 4.1.2. That is the gcc version on the contest machine.
• The binary version of coalesCgrip used to generate the contest results is also available on the coalesCgrip website. Please look for the binary named CGRIP_300_900_1.exe

Contest Evaluation Script:

• Usage:    ispd2011_evaluate_solution.pl   [options]   < circuit.aux >   < placement solution >   < routing solution >
  ispd2011_evaluate_solution

Evaluation Metric:

• For each circuit in the benchmark suite, the placers will be ranked based on the contest evaluation metric. The final rank for a placer will be the sum of the individual ranks on all the circuits. The placer with the smallest total rank wins the contest.
• The primary contest evaluation metric is based on the following criteria:
  • The Total Overflow (TOT_OF) of the routing solution from the golden router(s). The "Total Overflow" is a measure of the routing congestion of the placement solution.
  • The runtime of the placer.
• Primary Contest Metric = TOT_OF * (1 + PLACER_RUNTIME_FACTOR)
• The "PLACER_RUNTIME_FACTOR" is similar to the ISPD-2006 placement and ISPD-2008 routing contests. For each circuit in the benchmark suite, it is based on the ratio of the placer run time to the median run time of all the placers.
• In case of a tie in the primary contest metric, the secondary contest metric (tie-breaker) will be used. The secondary metric is: ROUTED_WIRE_LENGTH * (1 + PLACER_RUNTIME_FACTOR). The ROUTED_WIRE_LENGTH is the tile-to-tile wire length from the global router and not the pin-to-pin wire length.
• We would like to stress that although runtime is a part of the contest metric, the "Total Overflow" will be the dominant component. In other words, a placer will not get a significant advantage if it is extremely fast compared to the median runtime of all the placers participating in the contest.

Utility Scripts

• Check the legality of the placement solution. Usage: ispd2011_check_legality < circuit.aux > < solution.pl >
  ispd2011_check_legality

Participating Teams

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.
   


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):
    


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

Call for Participation