Prev: CPLD + MCU SoC from Cypress, free samples too!
Next: Serial interface between PC and FPGA using matlab
From: Brian Drummond on 7 Nov 2009 06:10
On Thu, 5 Nov 2009 13:56:22 -0600, "Steve Ravet" <steve.ravet(a)arm.com> wrote:

>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,

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
From: KJ on 7 Nov 2009 10:34
On Nov 7, 6:10 am, Brian Drummond <brian_drumm...(a)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.

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
From: Brian Drummond on 7 Nov 2009 17:58
On Sat, 7 Nov 2009 07:34:05 -0800 (PST), KJ <kkjennings(a)sbcglobal.net> wrote:

>On Nov 7, 6:10�am, Brian Drummond <brian_drumm...(a)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
First  |  Prev  | 
Pages: 1 2 3
Prev: CPLD + MCU SoC from Cypress, free samples too!
Next: Serial interface between PC and FPGA using matlab