Does anyone ever use placement?...

Main Page | Report this Page

Computers Forum Index » Computer Architecture - FPGA » Does anyone ever use placement?...

Page 1 of 1

Does anyone ever use placement?...

Author

Message

Steve Ravet...

Posted: Fri Nov 06, 2009 12:56 am

Guest

Do any of you advanced users ever use the floorplanning tools to do
placement? I'm not talking about placing clock buffers or other individual
items, I'm talking about ASIC style floorplanning for units and sub-units.
I've asked AE's about that and the response is always to let the tool do
placement. So I'm asking experts: Do you ever floorplan, and if so why?
To speed up map? To help with timing? Thanks for any insight,

--steve

Gabor...

Posted: Fri Nov 06, 2009 12:56 am

Guest

On Nov 5, 2:56 pm, "Steve Ravet" <steve.ra... at (no spam) arm.com> wrote:

Quote:

Do any of you advanced users ever use the floorplanning tools to do
placement? I'm not talking about placing clock buffers or other individual
items, I'm talking about ASIC style floorplanning for units and sub-units..
I've asked AE's about that and the response is always to let the tool do
placement. So I'm asking experts: Do you ever floorplan, and if so why?
To speed up map? To help with timing? Thanks for any insight,

--steve

My approach is let the tools run, and if they fail miserably
(generally only a matter of meeting timing, not completing
routing) then see how I can help them along. I had a fairly
full Virtex 2 design and had some issues with timing. This was
before Xilinx picked up PlanAhead and I tried the PlanAhead tool
from HierDesign. I found that at least in my case PlanAhead
actually made matters worse than just letting the tools place
anything anywhere. I imagine there are some more highly-
structured designs where this would not be the case. About
the only other thing I do is place block RAM's when I find that
the tools are not placing them efficiently. My experience has
been that the general FPGA fabric is best placed by the tools.

I should also note that my designs are generally for boards
that already exist so the pins are locked down. I normally
assign pins myself except for things like DDR memory, where
I let the MIG core guide the pin placement, and even then
I restrict the banks to help in PCB layout. Also my experience
is limited to Xilinx and Lattice parts.

Regards,
Gabor

rickman...

Posted: Fri Nov 06, 2009 12:56 am

Guest

On Nov 5, 2:56 pm, "Steve Ravet" <steve.ra... at (no spam) arm.com> wrote:

Quote:

Floorplanning is a major PITA, not from the perspective of the tools
not being easy to use (although I don't make any claims to the
contrary either) but just from a development perspective. To use
floorplanning you need to add a fairly messy/complex step to your
process in order to get a design you can test. This has to be
repeated each time you make a change, at least on the part changed. A
small change to an HDL design can often result in much larger changes
to the implementation due to optimizations.

I can't say any of this for certain since I have not needed to
floorplan for almost a decade and I am sure the tools are better. I
believe at least Xilinx has some incremental compile feature which
should help to minimize the extent of changes due to a design change.
That would help, but it still remains a messy proposition.

I know there are some people who use floorplanning regularly, Ray
Andraka for one. He started with FPGAs back when we used schematic
for entry. He had built up a large library of schematic functional
blocks with hierarchical placement properties which allowed him to
floorplan an entire design. I believe he resisted HDL for some time
because he thought he would loose this investment. After his
customers insisted that he use VHDL (government I believe) he looked
at it with a critical eye, tried some test cases with support from
Xilinx (his is mainly a Xilinx house) and found he could use the same
placement features by instantiating the same sort of functional and
primitive elements. So I believe this has worked out very well for
him, especially since HDL also adds a lot of benefit from being text
based rather than requiring a particular product for the schematics.

The bottom line, yes, you can do projects with floorplanning which
will help with both fitting and speed in a design, especially if it
has repeating units. But it is a long row to hoe and works best if
you will be using this process repeatedly to amortize the learning
curve costs as well as take advantage of design reuse that is
possible. But if your project doesn't *require* it, why bother?

Rick

Nico Coesel...

Posted: Fri Nov 06, 2009 4:18 am

Guest

Gabor <gabor at (no spam) alacron.com> wrote:

Quote:

On Nov 5, 2:56=A0pm, "Steve Ravet" <steve.ra... at (no spam) arm.com> wrote:
Do any of you advanced users ever use the floorplanning tools to do
placement? =A0I'm not talking about placing clock buffers or other indivi=
dual
items, I'm talking about ASIC style floorplanning for units and sub-units=
.
I've asked AE's about that and the response is always to let the tool do
placement. =A0So I'm asking experts: =A0Do you ever floorplan, and if so =
why?
To speed up map? =A0To help with timing? =A0Thanks for any insight,

--steve

My approach is let the tools run, and if they fail miserably
(generally only a matter of meeting timing, not completing
routing) then see how I can help them along. I had a fairly
full Virtex 2 design and had some issues with timing. This was
before Xilinx picked up PlanAhead and I tried the PlanAhead tool
from HierDesign. I found that at least in my case PlanAhead
actually made matters worse than just letting the tools place
anything anywhere. I imagine there are some more highly-
structured designs where this would not be the case. About
the only other thing I do is place block RAM's when I find that
the tools are not placing them efficiently. My experience has
been that the general FPGA fabric is best placed by the tools.

I had to do that once but I used the constraints to force the location
of a block RAM. That improved timing considerably.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Kastil Jan...

Posted: Fri Nov 06, 2009 1:02 pm

Guest

Hi,
I do not know if I am an advanced user, but I have a few experiance with
floorplanning tool. I tried use a PlanAhead tool to meet timing of the
design in Virtex5 110 and failed misserably. But during this time I gained
a few experiance, some of them comes from reading I did, others I
discovered by my own.

First, you should floorplan complete and optimized design. Floorplanning
is a complex issue, such as optimalization and it is much more harder to
do both at the time.

Design should be modular. Meaning that if you have a design, where every
unit communicates with every other on the high frequency (which is exactly what
we had). Than you will not be able to floorplan very effectively (you can
at least place some critical components). If you have such modules, that
the problems are inside the module, than your floorplanning will help.
PlanAhead also allows you to run map and par only on the problematic
module, which can decrease time of the work.

Be carefull with the LOC (placing of the part). Once I tried to LOC all
components of the component in the design that was placed to ensure
repeatibility of the map and par. The result was that map failed saying
that LOC constrains are incorect.

A few times I met a strange situation, where correct LOC (on LUT,
register, ..) made the path worse. Let me explain: There was a
time critical path. After some time, map a par found the solution for this
path that met the timing. So I LOC its parts in the design and run map and
par. I was surprised, that the path did not met the timing again. So
LOCking of the critical path is surely not a right way.

This is my personal experience from the ISE10.1 and ISE11.2.

If you want to decrease time of the implementation run, you could look at
the guided map or partitions.

Jan

On Thu, 5 Nov 2009, Steve Ravet wrote:

Quote:

Ben Jones...

Posted: Fri Nov 06, 2009 1:25 pm

Guest

On Nov 5, 7:56 pm, "Steve Ravet" <steve.ra... at (no spam) arm.com> wrote:

Quote:

Do any of you advanced users ever use the floorplanning tools to do
placement? I'm not talking about placing clock buffers or other individual
items, I'm talking about ASIC style floorplanning for units and sub-units..
I've asked AE's about that and the response is always to let the tool do
placement. So I'm asking experts: Do you ever floorplan, and if so why?
To speed up map? To help with timing? Thanks for any insight,

--steve

I think floorplanning is undersupported in most current FPGA tools
(certainly in the Xilinx tools), but sometimes it's a necessity. In
fact, I'd say that anyone doing a non-trivial FPGA design (and is
there any other kind?) should at least be aware of the impact that
placement decisions will have on their design. And this goes double
for anyone using hard blocks such as DSPs and processors and EMACs and
so on. In the end, your design is not being turned into software, but
hardware - a real, physical thing that has a real physical layout. As
you point out, ASIC people fully realise that layout is important (and
hard). I fail to see why FPGA design is really that different.

To my mind there are two aspects to placement/floorplanning. One is
the "low-level tweaking" aspect, where you might have to fiddle around
making sure that a few critical elements are placed properly relative
to one another so that timing isn't compromised. Or you might be
trying to do a very dense design, with no wasted space, and use
placement constraints to force certain logic functions to share a
resource. This sort of placement is fiddly, time-consuming, error-
prone, and often needs to be re-done when a design undergoes changes -
and worse, you can easily make your design bigger and/or slower if
you're not 100% sure of what you're doing. This is the placement job
that you'd really hope the FPGA tools would do well, because it seems
ideally suited to automation based on the software's intimate
knowledge of the device architecture and design rules. It's similar to
the argument for high-level languages versus assembly language in the
software domain.

Most of the time, the tools do an OK job of the low-level mapping.
When they don't, it's often very hard to persuade them to do it
differently. This is often a source of great frustration if you're
trying to push the boundaries of what's possible in a device. I
personally think there are three occasions on which this sort of
dabbling-in-black-magic is warranted:

1) When designing a common component that will be re-used often within
a design, and within other designs. So the pain can be amortized over
many projects.

2) When the component in question is the "key" to the success of a
particular design. The commercial viability of your product might
hinge on the ability to do (say) a very fast pipelined 72-bit addition
operation. So the pain can be justified.

3) When you've finished your design and it doesn't meet timing because
the tools are misbehaving. In this case, the pain can be partially
mitigated by ranting about your problems on usenet. :-)

But there's a whole other kind of placement, too, which is device-
level floorplanning. That is, rather than being concerned about the
details of which LUT goes where, you're thinking about whether the DDR
controller should go on the left- or the right-hand side of the chip.
Taking into account the locations of other devices on your PCB, you
must decide which Ethernet MAC to use. Or which PowerPC, and then,
where to put all its peripherals. Or you have two filter blocks that
use DSP slices, and you want to ensure that they both take them from
the same column. Or you have two blocks with very complex internal
routing and you want to make sure the tools keep their areas
completely separate to improve runtime and avoid congestion.

This is the sort of problem that I think is very hard to solve
automatically. It's a bit like town planning. You wouldn't just say "I
need 10,000 houses, four schools, 50 shops and restaurants and a
hospital" and expect some piece of software to come up with an optimal
solution. You at least need to give it some constraints. Some idea of
the geography. Some idea of what ought to be near to what. Tools like
planahead are supposed to help with this sort of thing, but there are
plenty of other ways.

For example, I have seen a design go from <130MHz to >200MHz simply
from adding a few area-group constraints to guide the placement
algorithm into making sensible decisions. Usually you don't get much
run-time improvement out of the mapper - if anything, constraint
processing tends to slow the tools down - but that's usually re-couped
in the routing stage, because the problem the router has to solve is
far better defined when the functional sub-blocks are nicely separated
out, rather than tangled together in spahetti.

Depending on what you're trying to achieve with an FPGA, you might
never ever need to touch a placement constraint at all. But as devices
get bigger and bigger I think more and more users are going to hit the
limits of the tools, and will start to require an awareness of the
true physical nature of their designs in order to complete them
successfully. When that happens, I'm also hoping we'll see an
improvement in the actual mechanics of influencing placement decisions
- both low-level and high-level - within the various design suites.

Cheers,

-Ben-

(It seems that, thanks to quantitative easing, my $0.02 is now trading
at around $0.22.)

rickman...

Posted: Fri Nov 06, 2009 4:21 pm

Guest

On Nov 6, 1:41 am, Kim Enkovaara <kim.enkova... at (no spam) iki.fi> wrote:

Quote:

rickman wrote:
I can't say any of this for certain since I have not needed to
floorplan for almost a decade and I am sure the tools are better. I
believe at least Xilinx has some incremental compile feature which
should help to minimize the extent of changes due to a design change.
That would help, but it still remains a messy proposition.

My biggest problem is that the Xilinx placer is horribly bad. It seems
to place everything at random and then just hopes that it might be
able to meet the timing and route the mess. Of course if you have
time just run all the different seeds for the placement, one of them
might be good enough guess Wink

Manual placement of the memories usually
helps a lot.

My own feeling is that the Altera placer is better than the Xilinx
altough it also has some problems with the different size memories
(M144k vs M9k etc.).

Fortunately there are physical synthesis tools for FPGAs from
3rd parties, they at least make reasonable placement for the FPGA
tools to start their work.

I wasn't aware that any of the third party tools did *any* placement.
I thought they just produced a net list of the primitives and let the
Xilinx place and route tools do all of that. Am I mistaken?

I don't disagree that the placer is nowhere near optimal. But I have
done enough hand placement to realize that unless you have a very
regular design that you can clearly see the optimal placement, it can
be very hard to do a good job yourself. Of course you can spot the
bad placements the tool does, but it is very often true that if you
optimize one thing, you will mess up something else. Of course, the
point is that you optimize the parts that have trouble meeting timing
and allow the portions with lots of slack to get worse. For the tool
to know which parts these are would require iterating through
placement *and* routing which I don't think they do. Am I wrong about
that? I guess that is where the multiple seeds come in.

Don't mention Altera to me. Although their current tool might be a
lot better, I had to do a project using Max Plus II and it totally
sucked! Not only was it not so good at the P&R thing, it would claim
a design was passing timing analysis when it would fail on the bench.
We spent tons of time trying to get that blivet* to work using cold
spray and a chip heater.

* A blivet is 10 pounds of $#!? in a 5 pound bag or in this case an
FPGA using 90% of the logic.

Rick

Steve Ravet...

Posted: Sat Nov 07, 2009 1:54 am

Guest

Synplify Premier includes physical synthesis for Xilinx, which does graph
based placement while synthesizing. It knows about all the routing
resources and can place logic accordingly. It forwards a boatload of
location constraints to the placer. I evaluated it a couple years ago and
it didn't work, there was some lack of communication between synthesis and
ISE. I'll be using it again in a couple months, this time on big v6 parts.

Thanks for the comments everyone. My FPGA work is mainly ASIC emulation, so
no IP blocks, no particular PCB concerns (most FPGA I/O is connected to
other FPGAs). I just know that the ASIC implementation team spends a lot of
time floorplanning, and I was wondering if there was any benefit to applying
that to the FPGA.

Someone else mentioned the smartguide option... I use this all the time.
It cut P&R runtime from 18 hours down to 6 on a 92% full V5 LX330 design.
When I get a design that routes successfully and has good timing I keep it
and use it to guide the next placement.

regards,
--steve

"rickman" <gnuarm at (no spam) gmail.com> wrote in message news:a53d433a-97a2-4d7e-a9c2-
I wasn't aware that any of the third party tools did *any* placement.
I thought they just produced a net list of the primitives and let the
Xilinx place and route tools do all of that. Am I mistaken?

Rick

John Adair...

Posted: Sat Nov 07, 2009 7:45 am

Guest

I'd pretty much agree with other comments and say I use it as a last
resort tool. The problems when parts are changed make it a problem.
That all said we used floorplanning in conjunction with FPGA Editor
some years ago to achieve our 10Gbit CRC32 IP in relative slow Virtex-
II fabric. That particular design has 3 levels of LUTs in some of it
and had to run at 300Mhz+. We got down to identifying individual
inputs of the LUT to use in interconnecting logic in some cases to
make go quick enough. A long job but in the end successful.

I would always play with synthesis, map and P&R options before using
floorplanning for these reasons. I would also look at the worst areas
in the design too and see if the design could change to sort a timing
issue that way. Using the multiple P&R seeds is often worth one or two
nS.

John Adair
Enterpoint Ltd.

On 5 Nov, 19:56, "Steve Ravet" <steve.ra... at (no spam) arm.com> wrote:

Quote:

Do any of you advanced users ever use the floorplanning tools to do
placement? I'm not talking about placing clock buffers or other individual
items, I'm talking about ASIC style floorplanning for units and sub-units..
I've asked AE's about that and the response is always to let the tool do
placement. So I'm asking experts: Do you ever floorplan, and if so why?
To speed up map? To help with timing? Thanks for any insight,

--steve

KJ...

Posted: Sat Nov 07, 2009 3:34 pm

Guest

On Nov 7, 6:10 am, Brian Drummond <brian_drumm... at (no spam) btconnect.com>
wrote:

Quote:

One placement approach I have successfully used is to let the tools do their
thing and JUST fail to meet timing (say 50 or fewer timing errors).

Yep

Quote:

Then examine
the timing report; typically all 50 errors are related to one FF or LUT in an
obviously stupid place. Use FPGA editor to move it, and run reentrant PAR to fix
the offending routes.

In that situation, I'll first look into ways of changing the logic in
the source code to effectively breaks up the long path or remove
unneeded signal dependencies and I may never hear from that timing
path again regardless of fitter placement.

If that doesn't cut it, turning loose the fitter to vary the synthesis
and fitter settings and seeds and such is rather painless and
generally comes back with better settings that stand up to future
design iterations.

KJ

Brian Drummond...

Posted: Sat Nov 07, 2009 4:10 pm

Guest

On Thu, 5 Nov 2009 13:56:22 -0600, "Steve Ravet" <steve.ravet at (no spam) arm.com> wrote:

Quote:

I last seriously tried floorplanning in the ISE 6.3 era. (And previously in
3.1). My approach then was to try floorplanning significant blocks (e.g.
multipliers in logic), and save them as black boxes with RLOCs, then incorporate
them in larger blocks (e.g. interpolators) in a hierarchical manner, and so on,
until the remaining logic would auto-place as I wanted.

This was using Floorplanner (not PlanAhead), and saving as relatively placed
modules (large UCF files full fo RLOCs).

Conclusions then:
(a) hierarchical floorplanning worked, sort of, IF you could step oh so
carefully around all the bugs not just in Floorplanner but in the back end tools
as well.
(b) It must have been almost completely untested, judging by the number and type
of bugs I was finding.
(c) You had to flatten each level of hierarchy after floorplanning, ending up
with one huge UCF file of RLOCs to use at the next level up

but...
(d) performance on a large block increased from 80 to 130MHz.

Then...
(e) it would degrade again if you packed several such blocks together,
apparently due to routing straying outside one block increasing congestion in
its neighbour. "Guard bands" between them helped, but waste space...

I got about half my design running well in a hierarchical floorplanned manner,
in several weeks (about 75% chasing bugs), before I couldn't dedicate (waste?)
any more time on the project.

And I haven't made time to try again with newer releases, to see how
Floorplanner has improved, or if PlanAhead is better.

Short answer then was: left alone, the tools leave at least 30% of possible
speed on the table, but to do better on a large design would be a lot of work.
(I guess that sort of work may be worthwhile in ASIC design, and the tools
support it better)

You may argue that experience from so long ago isn't worth describing; but other
comments here suggest things aren't much better today.

The bugs can be worked around, then fixed.

But if packing the fast blocks together still loses their performance, it really
isn't worthwhile (except for specific purposes, e.g. around hard IP like DSPs,
or to fix specific instances of poor auto-placement.

One placement approach I have successfully used is to let the tools do their
thing and JUST fail to meet timing (say 50 or fewer timing errors). Then examine
the timing report; typically all 50 errors are related to one FF or LUT in an
obviously stupid place. Use FPGA editor to move it, and run reentrant PAR to fix
the offending routes.

Quick, easy, and about half the time, effective.

Of course the GUI-based reentrant flow in ISE10 was set up to delete the old
file, run PAR reentrant, and fall over because the old file was missing...

- Brian

Brian Drummond...

Posted: Sun Nov 08, 2009 3:58 am

Guest

On Sat, 7 Nov 2009 07:34:05 -0800 (PST), KJ <kkjennings at (no spam) sbcglobal.net> wrote:

Quote:

On Nov 7, 6:10 am, Brian Drummond <brian_drumm... at (no spam) btconnect.com
wrote:

One placement approach I have successfully used is to let the tools do their
thing and JUST fail to meet timing (say 50 or fewer timing errors).

Yep

Then examine
the timing report; typically all 50 errors are related to one FF or LUT in an
obviously stupid place. Use FPGA editor to move it, and run reentrant PAR to fix
the offending routes.

In that situation, I'll first look into ways of changing the logic in
the source code to effectively breaks up the long path or remove
unneeded signal dependencies and I may never hear from that timing
path again regardless of fitter placement.

Agreed that is often a better option.

I wasn't very clear; I have seen this happen on one signal, exactly like 2^8
other signals which meet timing, except this has one FF placed at X99Y99 in the
opposite corner to the rest of the block. (I'm only exaggerating slightly!)
In that case moving the errant FF can be faster than a new placement, and
certainly less disruptive than a redesign.

As you say, another PAR seed (or try 5 with a home-scripted MPPR), or even an
unrelated design change, can also make the problem go away.

In this situation, placement is just one more tool in the box.

And maybe less useful than it was with earlier tool versions.

- Brian

Page 1 of 1

All times are GMT The time now is Sat Nov 28, 2009 7:40 pm Computers Forum Index