FPGARelated.com
Forums

floorplanning

Started by Lukasz Salwinski May 13, 2005
hello,
   there seems to be a plethora of textbooks on VHDL/Verilog
available. But what about floorplanning ? Are there any
resources (print/Web) available ?

lukasz
When you need to worry about floor planning.. you had better have a PhD.
Its one of the black arts when you are concerned about arrival times ... its
far better to let the tools do it for you in most cases, but there are
occasions where the tools fall flat but then you only fix the fault not
place the whole design.

That's also why there are a few books.. but not many I would suspect.

Simon


"Lukasz Salwinski" <lukasz@ucla.edu> wrote in message
news:d630a5$jd9$1@zinnia.noc.ucla.edu...
> hello, > there seems to be a plethora of textbooks on VHDL/Verilog > available. But what about floorplanning ? Are there any > resources (print/Web) available ? > > lukasz
Funny that you think it takes a PhD to drive layout tools,

In olden days most chips were layed out by non degreed draftpeople who
did not do the circuit design, but kinda knew what looks right.

There were at least 2 books for them, Motorola, and Tanner EDA both
have IC layout books, still valid today for polygon editing and even
floorplanning since its the same idea no matter who you worked for or
even 3u v .2u just more rules and layers.

As for FPGA floorplanning, all I see is the (not much) help guides,
never seen any books on it, they would date too quickly, knowledge is
very specific to each family, even each member. It is a bit of a black
art and takes alot of practice too. For my own tastes the manual draw
flow is about 100x too slow to be practical except for critical
repeated blocks.

Its probably worth doing some test layout work along the way to get a
feel for what the tool will do with different options but the results
vary so much with the smallest changes. Like throwing it all up in the
air and see it land differently every time. When the timing is easy,
the tool has 0 incentive to do better. When the timing is almost
impossible, the tool has only heuristics to find a result and it never
looks like what a person would produce.

In an empty design theres not much call for it, but in a tight packed
design its already too late. But there is one time it is justified and
that is when you have N copies of same mega cell that could be hand
packed and stepped and repeated. It may not actually be much faster by
the cell, but it most certainly can improve packing density and makes
all copies more or less the same timing spec. Humans really can do
better at highly structured layout but the tools will exhaust your
patience pretty quickly.

Unless you are way over 120MHz I doubt you need it unless you know how
to do it anyway.

johnjakson at usa dot com

I forgot to say that manual design is inherantly bottom up design which
means you assemble objects and see their interactions as you edit them
even if the logic is incomplete. The tools should not care as long as
you believe the logic is correct.

But the FPGA layout tools don't like that, they insist on a complete
design that interferes with what you are trying to accomplish.

I have been fighting this battle for 20+ years with EDA writers, they
don't use their own tools the way some of us would wish, only in the
proscribed way. At one time I did IC mask layout and had no way to turn
DRC off which is like driving around with a cop in your passenger seat,
only much worse!

I wonder how much demand there would be for a realy slick and
commercial FPGA layout tool that had at least a basic model of the LUTs
and wiring delays that could be correlated with actual devices. I have
some ideas on this but other projects come 1st.


johnjakson at usa dot com

Simon Peacock wrote:

>When you need to worry about floor planning.. you had better have a PhD. >Its one of the black arts when you are concerned about arrival times ... its >far better to let the tools do it for you in most cases, but there are >occasions where the tools fall flat but then you only fix the fault not >place the whole design. > > >
I disagree. If you need the performance, floorplanning can make a huge difference, especially in designs that are heavily data path. The automatic placement tools fall seriously short of what a human can do. No need for a PhD though. I find that floorplanning skill seem to be more of a inate ability thing: either you have it or you don't. Some people are really good at it from day one, while others never do get the knack regardless of how long they study it. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
"Simon Peacock" wrote:

>When you need to worry about floor planning.. you had better have a PhD. >Its one of the black arts when you are concerned about arrival times ... its >far better to let the tools do it for you in most cases, but there are >occasions where the tools fall flat but then you only fix the fault not >place the whole design.
Floorplanning doesn't take a PhD. Datapath floorplanning is more like doing a jigsaw puzzle than anything else. The tools can't and don't do a the best or even a very good job of placement. Not the fault of the vendors, it is a very hard problem to find the best answer in the general case. The tools do an acceptable job for most designs anymore. What humans can easily do is to find a very good answer, especially if the structure is regular or can be made to be regular, or if there is one key problem to solve. For the first case, think about a simple datapath. The logic, when built into LUTs (and other elements) often can be made as a regular structure where each bit uses basically the same logic, and if this logic is placed the same for each bit, then the control lines can be short and regular as well. This can make for a fairly simple to implement, fairly optimal design. Datapath floorplanning is an "easy" problem, as it can be done by a computer program that completes in reasonable time. If you design enough datapaths, you could save time building up a library of elements and building from those. There are dathpath building tools for ASICs, and they have been around for almost a decade. Maybe in another decade someone will bring one out for FPGAs, as part of a high end FPGA tool. For the second case, my most recent design is fairly low speed, ~50 MHz in a Spartan-3. At one point in time, I was getting a timing failure on a BlockRam -> some data path logic -> multiplier path. The only reason why this was failing was that the automatic placement put the BlockRam in one corner of the part and the multiplier in the far corner of the part. I'm not sure why the tools have such problems with the large blocks, but my experience is that the automatic placement of BlockRams and multipliers is often poor. The cure was simple: I fixed placed all the BlockRams and multipliers to something reasonable. I've also seen cases where, to meet timing, a LUT or FF had to be in a specific location or a few specific locations. The automatic placement would often get close, but close wasn't good enough. -- Phil Hays Phil-hays at posting domain (- .net + .com) should work for email
The problem is that most users design top down.. and when it comes to
profit.. it's top down.
And I agree... quite a few years ago we used to argue with the vendors about
the problems with their tools... But I am more philosophical these days.

Even if there was a basic model of an LUT, you would have to have a
different model for each family.. and probably for each device... the skill
in designing this is far more than the 'average' task... also using this
would force limitations in families or devices... that's the opposite that
any vendor wants.

And I think you summed it up perfectly.. nice concept.. but who has the time
to do it for a minority of the users?

Simon

"JJ" <johnjakson@yahoo.com> wrote in message
news:1116076267.579559.109770@g14g2000cwa.googlegroups.com...
> I forgot to say that manual design is inherantly bottom up design which > means you assemble objects and see their interactions as you edit them > even if the logic is incomplete. The tools should not care as long as > you believe the logic is correct. > > But the FPGA layout tools don't like that, they insist on a complete > design that interferes with what you are trying to accomplish. > > I have been fighting this battle for 20+ years with EDA writers, they > don't use their own tools the way some of us would wish, only in the > proscribed way. At one time I did IC mask layout and had no way to turn > DRC off which is like driving around with a cop in your passenger seat, > only much worse! > > I wonder how much demand there would be for a realy slick and > commercial FPGA layout tool that had at least a basic model of the LUTs > and wiring delays that could be correlated with actual devices. I have > some ideas on this but other projects come 1st. > > > johnjakson at usa dot com >
"Ray Andraka" <ray@andraka.com> wrote in message
news:17ohe.16613$aB.5455@lakeread03...
> Simon Peacock wrote: > > >When you need to worry about floor planning.. you had better have a PhD. > >Its one of the black arts when you are concerned about arrival times ...
its
> >far better to let the tools do it for you in most cases, but there are > >occasions where the tools fall flat but then you only fix the fault not > >place the whole design. > > > > > > > I disagree. If you need the performance, floorplanning can make a huge > difference, especially in designs that are heavily data path. The > automatic placement tools fall seriously short of what a human can do. > No need for a PhD though. I find that floorplanning skill seem to be > more of a inate ability thing: either you have it or you don't. Some > people are really good at it from day one, while others never do get the > knack regardless of how long they study it. >
Performance is usually the best place for the tweak.. the problem with hand placing is that a placement for one family won't necessarily be any good for another.. and it will reach a point where within the same family.. placements won't necessarily be combatable IMO. I would also agree with the you've either got it or not... that's why engineers still have jobs and we haven't all been replaced by computers.. hence the black art crack :-) Floor planning is best learned by trial and error I think... I also suspect that most people are best ignoring it until the have to do otherwise.. debugging is best done at higher levels and ignorance can be bliss.. or at least let you sleep at night. My best is to use Symplify... I build constraints into my VHDL and use Xilinx unisim to force certain placement or a particular grouping (usually for IO) and check the floor planner to make sure it does it. More than that.. I ignore.. especially if the timings are OK.. I don't have to go deeper or work weekends and I finish on time with confidence (and a pay check!) Simon
"Maybe in another decade someone will bring one out
for FPGAs, as part of a high end FPGA tool. "

How many dollars do you think such a productivity tool would be worth?

An ASIC guy will easily pay $100K for that sort of thing, I bet the
average FPGA guy today would squirm at $5K. ASIC EDA tool developments
are financed by VCs who expect a decent ROI. At few $k per seat, I see
less chance of that even if volumes could be higher.

Now if what X is saying about make it your asic is true, then many more
ASIC guys will be changing over to FPGA design flows, but the problem
is tools, ASIC guys are used to high value high cost tools for 1M gate
designs.

Well if FPGAs can do 1M equivalent size projects then will these ASIC
guys want better more open tools or will they happily accept total
vendor lock in. As an x ASIC guy I know the answer to that, they will
hate it.

But I suspect if a Meta FPGA model can be built for each popular FPGA
device, I could see some useful tools being built. Not sure if it will
happen.

see other post on OSX

Since I only see FPGAs through Webpack eyes, I can't know what
Synplicity, Mentor offerings can do for the floor planning pros. It
keeps coming back to the synthesis, who is in charge of the vision
thing, timing driven synthesis has no grand vision internally. For a
decent high end floor planning tool, you would need to either work with
that synthesis internals or just replace it with human driven placement
and let the synthasis finish up whats left over.

In the past I suggested that schematic driven design (RIP) could easily
be the basis of floorplanning, every schematic symbol drawn maps
directly to an area of hand synthesied logic blocks, hiearchical driven
design.

Since that approach is dead, I would now suggest using the output
schematic that come from synthesis and annotate that with floor
planning hints. The problem there is that those schematics are worse
than what a 3yr old can draw.

As you said, when I make 16 copies of something, the average EE sees a
bright light and draws an array and reduces the problem 2 fold,
datapath plus control. The average dim witted tool (always written by
PhDs no doubt) smashes away all logical structure and randomizes
everything. Until the EDA tool guys understand this, the tools won't
get better. If anything I believe they will get worse as FPGAs keep
getting bigger.

The key with regularity is that for humans it drastically simplifies
the solution N fold and makes things managable. For tools, its just
more cycles.

end of rant

johnjakson at usa dot com
transputer2 at yahoo dot com

Simon, I am not so sure the Meta model would have to be super accurate,
just reasonably so.

It would have to describe the varying delays through LUTs, and switch
fabric and cover the more obvious features available, probably in a HDL
model. That automatically sets off alarm bells at the vendor since now
anybody can see how their structures are built. Does anybody really
care, its not like you can go fab a clone even if you have a detailed
model of slice.

Even if the timing was 20% off, just being able to put FFs and adders
and what not in the best possible place for datapath given this
accuracy would be far better than the dim wit SW can do with likely not
much better nos. Once the ucf or xcf file is sent back to the vendor
tool, we can see if the result is better or not.


If the features can be openly described in the pdf spec, then it can be
modelled and correlated with actual models in an automated fashion
against the vendor tools.

In an ASIC, such foolery is limited since every bodies std cell library
is basically the same.

johnjakson at usa dot com