( ESNUG 344 Item 2 ) --------------------------------------------- [2/23/00]
Subject: ( ESNUG 343 #2 ) Texas Instruments' 5-Way Physical Synth Shootout
> I am absolutely positive that when some benchmarks have completed, we
> will definitely hear about the results from the winning vendor. Since
> these benchmark boasts have not materialized yet, we can only conclude
> that no-one is in boasting position, yet. The moment you find one, John,
> could you please make sure to publish it in ESNUG?
>
> - [ One Of The EDA Boys ]
From: Anthony Hill <hillam@dal.asp.ti.com>
Hi, John,
I know your ESNUG readers have been clamoring for details. Here's what
we've seen so far. I work for one of the DSP design groups at Texas
Instruments, and we've been evaluating Physical Compiler (PhysOpt) for the
past couple months. Generally when I see these sort of reviews, I am
left with an underlying scepticism about the actual test case and whether
the design complexity was sufficiently difficult to challenge the tool.
So we're going to give your readers the details of our evaluation and let
them decide.
The testcase we use to stress new tools/flows is a cache + controller block
consisting of about 30k nets and 8 large RAMs placed in a long rectangular
floorplan. There are placement regions for the standard cells between some
of the RAMs and along most of the width of the block. Total RAM area is
~~70% of the block area, and the RAMs are essentially blockages for all but
the top-level of metal. The target clock frequency for this block is
200MHz in a 0.25um 5-metal layer process.
This testcase has historically been our most difficult for getting timing
convergence. Wire-load models are essentially useless for any routes which
must go over the RAMs and global/detail routers have often found themselves
lost when trying to route over/around the RAMs. As the RAMs have ports on
two opposing sides, you can imagine the routing headaches. The last time
we taped-out this block (2 months ago) we went through 13 ECOs and a
number of manual tweaks to get the performance where we needed it.
We handed off our gate-level netlist to the local Synopsys AEs right before
Christmas. They came back with a placed netlist on the first week of
January. It had routability problems along a very thin standard cell
region between a RAM and the block boundary. (It has a 256-bit bus which
has to do a 90-degree turn over top of it.) We had known about that problem
a priori and had needed to add a blockage in our baseline Avanti P&R
environment as well. We thought PhysOpt might be smart enough to avoid
placement in that region, but it was not. We added the blockage for the
next run.
The second netlist which the local AEs handed off was routable and timing
looked good. There is a known architectural speed path in this design.
The critical path in the placed netlist generated by PhysOpt was that long
architectural path -- you couldn't do any better. PhysOpt also fixed all
timing problems for paths within the critical_range of that architectural
path. One impressive thing about the PhysOpt netlist was its routability.
It was easier to Avanti route the PhysOpt-placed netlist in Apollo II than
it was to Avanti route the Avanti-placed netlist. (!)
Synopsys has since handed off the tool to us and we've been running
PhysOpt in-house. One feature we were particularly interested in was the
RTL->placed gates flow. We've been able to run small testcases, but since
we do some rather exotic stuff using some funky DesignWare and clock
gating, we couldn't use it from the RTL level. So, until Synopsys
integrates clock tree synthesis into PhysOpt and allows gated clocks at
the RTL level, it means we'll stay in gates->placed-gates mode for now.
Another problem we think most design teams will have with the flow is scan
testing. The handling of tieoff cells using a 'compile -scan' flow is a
problem as the tieoffs 'go away' after placement. (PhysOpt does not have
a concept of an 'ideal_cell' -- yet.)
So the bottom line is this: PhysOpt promises to save us a couple X off our
design cycle time. (I'll let the Synopsys marketers argue about the
magnitude of X.) The timing convergence for this testcase was quite
impressive. It also fixed nearly all of our design rule constraints in the
first go (which helps hot-carrier reliability, noise, etc.) We were also
quite impressed with the correlation between Synopsys' global route
estimates and our back-end detailed route results. (Historically, we've
generally seen pretty good correlation between groute and droute with our
Avanti backend.)
Some PhysOpt drawbacks: the routing tech file is not very robust and still
shows some discrepancies (against Simplex) when routes go over routing
channels or through low routing-density regions. Also, PhysOpt does not
currently handle non-minimum width metals (which probably doesn't affect
most customers, but does impact the wire spacing/sizing crowd and those who
have to do a lot of wire sizing for electromigration).
We've also sent this testcase to other physical synthesis vendors. Politics
won't let me name names, but here's our non-specific experiences.
One of them punted, claiming that they only wanted to do our design flat and
that it was unroutable. Another had some pretty impressive results, but
their clock skew numbers were out in left field, and their power consumption
was quite high. That vendor is working to enhance their tool to resolve
those issues. Time will tell how competitive they will be to PhysOpt. A
third vendor (who's offering really amounts to a tool which they've had in
the market for some time) claimed good results, but upon analysis it turned
out their timing engine was spitting out bad results everywhere. The fourth
large player in this area didn't even warrant an evaluation. (We've
evaluated their 'synthesis' tools in the past and found such poor results,
it wasn't worth our time.)
> Why is there no mention of the different timing engines with the Synopsys
> flow? For instance, Design Compiler uses DesignTime, yet PrimeTime is the
> sign-off engine, and I'm not sure what the timing engine is in PhysOpt or
> Chip Architect.
>
> - Donna Rigali
> Cadence
Another great feature of using PhysOpt (maybe I'll get a free shirt for this
one, John) is that you have essentially the same timing engine throughout
your design flow. We've never had any major timing consistency issues
between PrimeTime and DesignTime (although PT seems to handle tieoff
propagation differently than DT in some cases). This solves a lot of
problems we've had in the past (and are still having) getting agreement
between 'other' timing engines and PrimeTime.
- Anthony Hill
Texas Instruments Dallas, TX
|
|
