( ESNUG 399 Item 2 ) --------------------------------------------- [08/08/02]
Subject: ( ESNUG 395 #3 ) PhysOpt-MPC Best Usage & An insert_dft Follow-Up
> As always, caveat emptor: there certainly is a place for MPC in a flow
> but caution should be exercised (specifying *no* option is probably a
> very bad idea, and the more information one provides, the better).
> No silver bullet, I'm afraid.
>
> - Jean-Marc Calvez
> STMicroelectronics Grenoble, France
From: Neel Das <neel.das@corrent.com>
Hi John,
Back in December I reported IN ESNUG 385 #11 certain issues we'd seen with
insert_dft in our PhysOpt flow. With the 2002.05 (Solaris) and 2002.05-1
(Linux) binaries, the QOR from insert_dft -physical has improved to where
we're getting comparable results (not necessarily better results) as
insert_scan. Thanks, Synopsys! We're now going to switch over to the
new command, if for no other reason but that insert_scan will eventually
stop getting supported. :)
Let me dwell a little on the -mpc and -quick flows in PhysOpt. (We're using
PhysOpt 2002.05 quite a bit now.)
First, why would you want to use the -mpc switch? For prototyping, right?
OK, so for a realistic prototype, one would want to include at the very
least a rough power plan. In high performance designs, it is not uncommon
to allocate 40% or more of routing resources even on multiple layers to the
power delivery strategy. Not including the capability to include a power
plan has for us severly limited the usefulness of the -mpc switch. To take
this one step further, PhysOpt ought to be able to identify not just the
power grid but also via obstructions (if you consider fat power straps
intersecting with fat vias, you get an idea of how limited routing resources
could be in that vicinity). Currently, -mpc also produced illegally placed
pins (some pins protruded out of the core boundary), which meant it's not
straightforward to take the output from such a flow into Apollo/Astro (which
we use for routing/CTS) and examine routability.
The -quick switch, which has been added for prototyping, was interesting as
well. So far, in the experiments I've run, I did try, but couldn't find a
lot of use for this feature. With all the limitations that have been built
in, I couldn't get a good handle on either timing or congestion prototyping.
I'm enclosing results from 4 runs I did on one of our larger blocks.
Platform: Linux PhysOpt Version: 2002.05-1
[in all cases, idential pin location specifications were used]
1. with mpc, auto-floorplanning, '-quick' switch:
WNS: 1.92 TNS: 2869.74 Number of Violating Paths: 3886
Nets with DRC Violations: 30241
Total moveable cell area: 3927650.2
Total fixed cell area: 0.0
Core area: (0 0 2367000 2369280)
2. with mpc, floorplan used size from older chip design, '-quick' switch:
WNS: 1.32 TNS: 1796.94 Number of Violating Paths: 2711
Nets with DRC Violations: 23450
Total moveable cell area: 36366765.
Total fixed cell area: 0.0
Core area: (0 0 4085000 2440000)
3. with mpc, floorplan used size from older chip design, '-congestion
-congestion_effort high' switch
WNS: 0.00 TNS: 0.00 Number of Violating Paths: 0
Nets with DRC Violations: 29
Total moveable cell area: 3318074.0
Total fixed cell area: 0.0
Core area: (0 0 4085000 2440000)
4. with mpc, auto-floorplan, '-congestion -congestion_effort high' switch
WNS: 0.06 TNS: 0.19 Number of Violating Paths: 22
Nets with DRC Violations: 22
Total moveable cell area: 3133408.2
Total fixed cell area: 0.0
Core area: (0 0 2234400 2234880)
Note that #4 is something we could start to work with. Good overall timing
and congestion. I would need to increase the floorplan to account for
power/ground straps.
I think it would be helpful if the -mpc switch *always* produces a routable
floorplan in the absence of user-provided x/y dimensions, regardless of
whether -quick is getting used or not.
The best approach in my opinion is to use the -mpc switch with a 'realistic'
compile strategy. Use the -mpc until you can put together a rudimentary
floorplan (including power straps) in a 'real' design planner: then switch
to the real FP immediately. In our case, -mpc did produce a nice, compact
floorplan, but when we used it with -quick, the design was too congested
to try a route.
People need to be especially careful with congested designs (if PhysOpt's
congestion map displays hotspots.) What happens in many cases is PhysOpt's
Steiner router gets out of sync with the 'real' router we use, thereby
resulting in lots (may be thousands in some clusters) of minor DRC
violations (max_tran and max_cap violations). In many of our clusters,
we've seen PhysOpt reports congestion that Apollo/Astro's router doesn't,
'cos it can detour around the congested hotspots. We also have seen an
outstanding issue (a STAR has been filed) with PhysOpt not being able to
fix a few hold violations on scan paths. We have to spend considerable
time verifying, binning and hand-fixing the DRCs. Until PhysOpt and the
global router being used get merged (at least to the degree of track and
layer assigments), this problem will continue to exist.
Which brings me to another issue that I'm interested in. Synopsys has been
working on the detail block-level router (Route66) and Clock Tree Compiler
(CTC) for some time now. With the merger, it now has former Avanti tools
that already have been tested and used extensively in the field. It doesn't
take a great leap of faith to imagine a scenario in the not-too-distant
future (within a year?) where PhysOpt will have the ability to read from and
write to a Milkyway database. I think that leaves the Route66 and CTC teams
about the same time to demonstrate a significant runtime/performance or QOR
advantage over the Apollo/Astro solutions. If the performance differential
is minor, which tools will survive? Hmm...
- Neel Das
Corrent Corp. Tempe, AZ
|
|
