( ESNUG 395 Item 3 ) --------------------------------------------- [06/26/02]
Subject: A Small Mob Brutally Pummels Cooley For Writing About PhysOpt-MPC
> That's why it was interesting that Synopsys, at the same SNUG, let users
> see its experimental PhysOpt-MPC (minimum physical constraints) tool.
> Basically, MPC is a prototyper for RTL jocks stumbling around in PhysOpt.
> MPC assumes a default floorplan for your block. Your is aspect ratio is
> 0.8, cell utilization is 65 percent, origin is at 0,0, corner keepouts are
> 100 um, IO margins are 20 um, and the easiest pin placement is assumed.
>
> Using PhysOpt-MPC this way, an RTL jock responsible for a 300 K gate block
> in a 5 M gate design doesn't have to muck around with DEF or PDEF 3.0
> floorplans just to get a feel for how his block's timing roughly works.
> The quick & dirty PhysOpt-MPC runs let you know if you have a few critical
> paths and what they are. Or it says that 75 percent of your paths are
> critical and you have a serious architectural problem with that block.
>
> And by tweaking the MPC defaults, an RTL designer can also find the rough
> trade-offs in metrics like timing vs. utilization vs. aspect ratios. He
> can see how a 2:1 aspect ratio with 50% utilization may be his fastest
> design -- while at 1:1 and 60 percent, the block has the least conjestion.
> In a nutshell, MPC gives you early physical feedback on your RTL blocks.
>
> - from "Gary's Weird Prediction"
From: Milan Lazich <milan.lazich@Magma-DA.COM>
To: John Cooley <jcooley@world.std.com>
John,
How come you didn't mention Magma? We made a product announcement in this
area a month before Synopsys did. We invited you -- and Gary Smith was
one of the speakers.
- Milan Lazich
Magma
---- ---- ---- ---- ---- ---- ----
From: John Cooley <jcooley@TheWorld.com>
To: Milan Lazich <milan.lazich@Magma-DA.COM>
Milan, I have two very good reasons:
1.) I didn't have space in a 400 word column. I also didn't mention
Silicon Perspectives, either.
2.) I honestly didn't know you had anything in that space. I wasn't
at your press conference, Milan.
Sorry about that.
- John Cooley
---- ---- ---- ---- ---- ---- ----
From: Milan Lazich <milan.lazich@Magma-DA.COM>
To: John Cooley <jcooley@TheWorld.com>
John,
You may have two reasons, but they're not "very good" -- the first is
irrelevant, the second specious.
I personally invited you to the event and you declined. I guess you also
didn't see Mike Santarini's coverage of the announcement. Try reading
"EE Times" some time -- it's a pretty good rag.
- Milan Lazich
Magma
---- ---- ---- ---- ---- ---- ----
From: John Cooley <jcooley@TheWorld.com>
To: Milan Lazich <milan.lazich@Magma-DA.COM>
Milan, at the time that you invited me (and when I wrote that column), I was
burried deep in getting that massive SNUG'02 Trip Report out plus helping a
client with an EDA problem that I can't talk about.
I was lucky to make it to bed by 2:AM those days. Again, sorry.
- John Cooley
---- ---- ---- ---- ---- ---- ----
From: Jack Erickson <erickson@cadence.com>
Hi John,
We've had this in PKS since our initial release. We highlighted it during
our demo at DAC. If we get a chance to elaborate on this capability, here
is a good explanation from Craig Crump, one of our PKS experts:
"You run PKS starting from RTL with the default 1x1 aspect ratio and
80% utilization. You can even let PKS auto place the pins for you.
During the initialization of the block PKS will keep the bus pins
grouped. Using this default floorplan you can get an idea if the
block is anywhere close to making timing.
Once you have decent results, on the early RTL passes, you can give the
gates to the physical design specialist to come up with the floorplan.
This is better than floorplanning on estimates as there are gates with
some hope of descent physical timing.
As the RTL continues to refine, the physical design specialist can give
information that is useful in future passed of PKS. Starting with info
about the aspect ratio & utilization, and continuing with pin placements
up to full DEF or PDEF floorplan specification.
In this way the spins that you make through synthesis to refine the
design can get more and more refined floorplans input to them, and move
toward timing and design closure at the same time."
I'll be interested to see the rest of the discussion on this.
- Jack Erickson
Cadence
---- ---- ---- ---- ---- ---- ----
From: Glenn Gullikson <glenng@cadence.com>
John, Jack,
Another point to note is that PKS suports "dynamic floorplanning". The user
can set parameters like block halos, pin side assignments, power stripes
rules, etc. at the RTL level. They get applied to the design at the point
they are needed; i.e. the pins are placed and power stripe rules are applied
after the bounding box for the block/die is calculated (since the bounding
box depends on the area of the design after preplacement optimization given
it is derived from the utilization), block halos are applied automatically
after block placement completes, rows are also automatically generated, etc.
One final point is that PKS allows the option to "grow" the block size
during post-placement optimization w/ a rules based approach to "anchoring"
macros to sides or other macros such that they can be fixed or allowed to
move in groups. Pins, power stripes, block halos, rows, etc. are all
automatically updated based on the expanded block boundary.
- Glenn Gullikson
Cadence San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Dave Reed <dave@mondes.com>
Hi John,
I'm afraid you're more than a little behind the times in the area of
silicon virtual prototyping. Our product was first used by a customer on a
production design in December 2000. Anyone who has been looking at this
issue seriously can quickly see the naivete of the PhysOpt-MPC approach that
you were touting in your column. Floorplanning decisions have a profound
effect on the physical design process -- subtle floorplanning changes can
make huge differences in the final timing and area of a block. The idea
that a "default" floorplan can somehow yield useful physical information
is completely wrong.
Today's real world prototyping tools allow designers to begin work on a
design long before a final gate-level netlist is available. Rather than
producing a pseudo-floorplan, these tools allow users to benefit from the
best available information as they refine their designs.
It may be tempting to wish away the challenges of physical design, but to
imagine that you can replace physical domain knowledge with an approach as
trivial as the PhysOpt-MPC you described in your column widely misses
the mark.
- Dave Reed
Monterey Design Systems
---- ---- ---- ---- ---- ---- ----
From: Jean-Marc Calvez <jean-marc.calvez@st.com>
Hi, John,
We've had access to PhysOpt-MPC here. I know that it is extremely popular
with front-end designers who positively can't stand to be waiting (a few
weeks sometimes) for a floorplan from the back-end person. These users now
consider PhysOpt-MPC to be the best thing since sliced bread. They all
wanted to try it when they learned of the feature.
However, in the only test I participated in, MPC was quite disappointing.
The context was a highly congested 0.18 standard cell block (no hard macro)
that had to be ported to 0.13, with an increase in clock frequency. PhysOpt
barely succeeded to meet timing in 0.18 and the occupation ratio was in the
low 90%. I wrote a small program to convert a 0.18 um DEF floorplan to 0.13
(basically keeping the same number of placement sites, placing the ports at
the same relative positions), and I tried that floorplan against MPC with
similar directives (aspect ratio and total area were the only directives
specified).
Well, while my "scaled" floorplan met timing at the increased frequency and
ended up with an occupation ratio of 60%. (Woohoo! Look Ma, no congestion!)
The MPC-driven physical synthesis was much more disappointing with timing
violations all over the place (WNS about 2.5ns, TNS in the 400ns). We
tentatively concluded that pre-placement of ports was really a crucial point
that shouldn't be overlooked, and our Synopsys FAE reemphasized the point.
Further experiments with various PhysOpt-MPC options yielded a no-violation
design (almost, 30ps WNS) but the area was about 20% larger than with the
scaled floorplan.
So I am not sure that MPC will be that efficient in helping the frontend
designer figure the timing issues early in its design. Sure, you get
results; whether they are significant or not is anyone's guess (if it
weren't for the scaled floorplan that met timing, just by looking at the
results from MPC, we'd sure consider to be in trouble as far as timing
closure was concerned).
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: Nir Sever <nir@zoran.co.il>
Hi John,
I'm impressed by Synopsys marketing. They can take the most trivial thing:
create a DEF file with a given size and random pin location and call it
"PhysOpt-MPC". They are probably going to charge for it too. Amazing.
This is an NCG task for a week. Every P&R tool and floor plan editor has
had this for years. Amazing.
- Nir Sever
Zoran Israel
---- ---- ---- ---- ---- ---- ----
From: James Tyson <jtyson@altera.com>
Hi, John,
We've been doing exactly this kind of thing with PKS for a while. It gives
us a better idea of area and speed for modules, without having to put any
effort into floorplanning, etc.
I'm surprised that this is only now a feature of PhysOpt.
- James Tyson
Altera European Technology Centre High Wycombe, Bucks, UK
|
|
