( ESNUG 412 Item 2 ) -------------------------------------------- [05/22/03]
Subject: ( SNUG 03 #18 ) Astro Benchmarks Better Only On Multiple CPU Runs
> We ran Apollo on a SunFire 280 with 2 x 750 Mhz processors, 4 Gb mem,
> Solaris 2.8. (We were not using multi-threading.)
>
> We ran Astro on Linux RedHat 7.2 with the big mem patch. It has 4 Gigs
> of memory, and the processor speed was ~1.1 GHz.
>
> The design was ~200 k instances.
>
> Astro version 2001.2.3.5.0.3
> Apollo II version 2000.2.3.4.0.9
>
> My run time numbers are rounded to the nearest 5 min or so.
>
> Apollo/Saturn Astro Linux Speed Up
> ------------- ----------- --------
> Read Netlist 12 min 4 min 3x
> Load SDC 25 1 25x
> Quick place, HFN,
> Transition Fix 155 30 5x
> IPO 360 90 4x
> CTS/CTO 60 30 2x
> -----------------------------------------------------------
> Total 612 155 4x
>
> Much of the speed increase resulted from the fact Astro runs in memory
> rather than on disk.
>
> - Craig Farnsworth
> Cogency Semiconductors
From: Korri Rederick <korri.rederick=person domain=motorola lot yon>
Hi, John,
Since we use the PhysOpt RTL-to-placed-gates flow for synthesis & placement,
and we use Clocktree Compiler for clocktree synthesis, I have focused
primarily on the router performance between Astro and Apollo. I have used
two TSMC18 (5 metal) testcases for my analysis; one small chip and one
medium sized chip. In both cases, the chips were routed flat, at the chip
(top) level.
I found several bugs with the original Astro version we installed (Astro
version 2001.2.3.5.0.3.1). Most of these were long runtime problems, but a
couple were complete show-stoppers. All except one of these bugs have been
fixed using the latest hotfix (2001.2.3.5.0.3.patch3_HOTFIX.123).
The last opened bug affects runtimes of the "axgRoutOpt" command, which I
usually run after detail route and search & repair to clean up some of the
"maze" routing and shorten up the overall route lengths. Sometimes this
also helps clean up the last few hundred route violations on highly
congested designs. With my two testcases, I see about a 400% increase in
execution time for this command. Even in Apollo, this command runs
significantly longer than the initial route so I was hoping for an
improvement, not a degradation in performance. Below are the runtimes for
both testcases:
Testcase #1 (small size)
Total number of cell instances: 44,090
Total number of nets: 49333
Machine: 550 MHz Sun Sunblade 100 (1CPU) 1792 M RAM
command Apollo Astro Astro (HF123)
axgRoutOpt 1:05:04 3:33:09 4:12:59
Testcase #2 (medium size)
Total number of cell instances: 165,855
Total number of nets: 180,341
Machine: 550 MHz Sun Sunblade 100 (1CPU) 1792 M RAM
command Apollo Astro Astro (HF123)
axgRoutOpt 3:24:31 13:12:49 13:42:12
Synopsys/Avanti wants a testcase, and they say they cannot duplicate the
issue without one. I haven't had time gift-wrap a testcase for them, so
until then I don't expect this issue to get resolved.
As for the rest of Astro, the runtimes for library creation, Verilog import,
placement, floorplan, etc., have all been about the same between Astro and
Apollo, but the route times (if I skip the optimize command) are better.
The new Astro tool allows for distributed routing which I also liked. Not
only can the job run on multiple CPU's on the same machine, but also on
multiple machines on the same network. I wish I had the time to test this
feature on a large design, but my two testcases were consistent so I would
expect similar results. These are the same testcases as above, and the
placement for each testcase came from PhysOpt, so the comparison is fair
(same placement used for Apollo and Astro).
Testcase #3 (small)
Machine: 9 CPU 400 MHz Sun Enterprise 4500 28 G RAM
Apollo route time: 0:37:20
Astro route times:
1-CPU 0:27:56
2-CPU 0:23:45
4-CPU 0:18:17
Testcase #4 (medium)
Machine: 9 CPU 400 MHz Sun Enterprise 3000 28 G RAM
Apollo route time: 2:28:37
Astro route times:
1-CPU 2:07:21
2-CPU 1:38:54
4-CPU 1:17:16
Concerning migration from Apollo to Astro, the biggest pain is that all the
reference libraries had to be recompiled to get timing information out of
Astro. We also had to update the technology file to include table-look-up
values for the parasitics, which can be extracted from the Star-RCXT input
files automatically using one of the Astro commands. All in all, it was
not a big deal.
The way we are using the place and route tool (primarily as a router), there
is only a small advantage to switching over. For this reason, we are still
using Apollo for all our customer designs.
- Korri Rederick
Motorola Semiconductor
|
|
