( ESNUG 341 Item 1 ) --------------------------------------------- [1/26/00]
Subject: ( ESNUG 335 #1 ) PhysOpt, Gambit, Module Compiler, Avanti Saturn
> Using our PhysOpt flow, 300k gate layout partitions typically took 2 to
> 3 passes to achieve both timing and routing convergence. Each iteration
> (doing steps 4 through 8 above) took 2 days for the first pass and 1 day
> for each incremental pass. Since PhysOpt tweaks placement for timing
> fixes while simultaneously assessing routing congestion, we found it
> made better optimizations. We also found first pass placement quality
> from PhysOpt was better in both timing and routeability than first pass
> placements from the Avanti Apollo timing-driven placer.
>
> - Bob Prevett
> NVIDIA Santa Clara, CA
From: Nick Summerville <nsummerv@ford.com>
Hi, John,
I read Bob's review of PhysOpt in ESNUG 335 #1 and was intrigued by the
placement/timing results he quoted. I had evaulated some of the placement
software from which the PhysOpt software came and did not see the kind of
placement quality he talked about. Perhaps my knowledge of the basis of
PhysOpt placement is incorrect. Did this placer come from technology
developed by Gambit? What kind of utilizations do you typically achieve,
or, what kind of transistor densities do you usually achieve?
I was also wondering what the total placement times were for the block(s)
in question. I can see how the INITIAL placement for PhysOpt or a variety
of other placers would be better than Avanti. Avanti's initial placement
frequently is not that great. But in our evaluations (admittedly some time
ago) the Avanti placer achieved the best final placement in the shortest
amount of time.
With respect to the timing driven placer (and router) in Avanti, yes the
run times and level of effort are substantially greater when timing-driven
is invoked. We have found that frequently it is less effort to run the
placer in non-timing driven mode, achieving a certain level of utilization,
and then do IPO/ECO corrections to close the gap on timing. However, I'm
certain Nvidia's clock speeds are greater than ours. We typically are under
60 Mhz, and frequently are under 40 Mhz. We rarely have systemic timing
failure, only small numbers of paths that need to be corrected. Whenever
we've had systemic failure, we often can trace the problem to inappropriate
constraints during synthesis.
And finally, do you think the PhysOpt placer would be faster or yield
smaller layouts than the Avanti placer run in non-timing mode?
- Nick Summerville
Ford Microelectronics Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: Bob Prevett <prevett@nvidia.com>
John,
Gil Herbeck of Radix20 wrote me saying "I gather from your description of
the PhysOpt flows that you guys aren't using Module Compiler anymore." If
anyone got the impression, I'm sorry. Module Compiler and DC were used to
generate the original netlist from Verilog/MCL. PhysOpt didn't come into
the picture for us until after we had a netlist ready for P&R.
- Bob Prevett
NVIDIA Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ An Engineer At LSI Logic ]
Hi John,
Keep me anon. I work in the Methodology Development group at LSI Logic. I
read Bob's review of Synopsys PhysOpt in ESNUG and am very interested in
finding out more of your issues in working with an Avanti backend. Were
there issues with getting the PDEF into Avanti? Was it translated via
SCHEME? Did both cell placement and global routing information transfer
from PhysOpt into Avanti? Did PhysOpt have a good understanding of
blockage due to memories, power rails, etc?
Also, he didn't mention whether his "old" flow utilized Avanti Saturn for
physical re-synthesis. Did it?
- [ An Engineer At LSI Logic ]
|
|
