99% Utilisation !

Should we ever get to that ?
I know typically A and X bother recommend 80-85% resource usage and so do a
lot of others
But besides having no provision for expansion of design and probably
extremely long p&r times, what are the other dangers of such a high resource
utilisation, if our clock is only 40 MHz.
Also what if we are using all 8 Rocket IOs in a device ?

"Adarsh Kumar Jain" <adarsh.jain@cern.ch> wrote in message
news:coi7rq$nce$1@sunnews.cern.ch...
> Should we ever get to that ?
> I know typically A and X bother recommend 80-85% resource usage and so do
a
> lot of others
> But besides having no provision for expansion of design and probably
> extremely long p&r times, what are the other dangers of such a high
resource
> utilisation, if our clock is only 40 MHz.
> Also what if we are using all 8 Rocket IOs in a device ?

You're worried because you have 99% slice utilization?  Don't!  Check your
LUT and register usage and you'll find you're probably *well* under the 99%
mark.  The P&R software tends to spread things around in the fabric, one
element per slice until the slices are each occupied with something, then
begin to backfill the extra slice resources to get the design in the part.
It seems inefficient, but it's what we have to deal with.

I look forward to the day when the slice components are be freely rearranged
by the P&R software; why have two registers locked together at the map phase
when P&R needs to make the tough decisions?

Adarsh Kumar Jain wrote:
> 
> Should we ever get to that ?
> I know typically A and X bother recommend 80-85% resource usage and so do a
> lot of others
> But besides having no provision for expansion of design and probably
> extremely long p&r times, what are the other dangers of such a high resource
> utilisation, if our clock is only 40 MHz.
> Also what if we are using all 8 Rocket IOs in a device ?

Most of the area of an FPGA is routing.  Maybe you should try to
maximize the useage of that.  Sounds like you could gain more efficiency
there than in the LUT usage.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

In article <41ACB09D.75F34B34@yahoo.com>, rickman  <john@bluepal.net> wrote:
>Most of the area of an FPGA is routing.  Maybe you should try to
>maximize the useage of that.  Sounds like you could gain more efficiency
>there than in the LUT usage.  

Except that because of marketing and perception reasons (tehre's no
good way to say "routing utilization" that users currently
understand), the routing is significantly overprovisioned for most
designs to allow high chip utilization.

Running at high utilization is a LOT easier if a large amount of the
logic is floorplanned/placed, it makes both placement easier and
routing easier.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

"John_H" <johnhandwork@mail.com> wrote in message 
news:3y1rd.8$8%.1119@news-west.eli.net...
> "Adarsh Kumar Jain" <adarsh.jain@cern.ch> wrote in message
> news:coi7rq$nce$1@sunnews.cern.ch...
>> Should we ever get to that ?
>> I know typically A and X bother recommend 80-85% resource usage and so do
> a
>> lot of others
>> But besides having no provision for expansion of design and probably
>> extremely long p&r times, what are the other dangers of such a high
> resource
>> utilisation, if our clock is only 40 MHz.
>> Also what if we are using all 8 Rocket IOs in a device ?
>
> You're worried because you have 99% slice utilization?  Don't!  Check your
> LUT and register usage and you'll find you're probably *well* under the 
> 99%
> mark.  The P&R software tends to spread things around in the fabric, one
> element per slice until the slices are each occupied with something, then
> begin to backfill the extra slice resources to get the design in the part.
> It seems inefficient, but it's what we have to deal with.
>
> I look forward to the day when the slice components are be freely 
> rearranged
> by the P&R software; why have two registers locked together at the map 
> phase
> when P&R needs to make the tough decisions?
>
>

Reference Xcell journal Issue 50 Fall 2004
Introduced in September 2003, ISE 6 adds a new timing driven map option that 
helps get better design utilization for your FPGA devices, particularly if 
the device is already 90% utilized.  Timing driven map is a next generation 
enhancement to ISE physical synthesis placement with logic slice packing for 
Virtex-II, Virtex-II Pro and Spartan-3 devices to improve placement quality 
for unrelated logic.

I think I tried using this with ISE 6.2i with Spartan-3.  Looked to me like 
it was a keeper.
-Newman 

"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
news:coibq8$up9$1@agate.berkeley.edu...
> Running at high utilization is a LOT easier if a large amount of the
> logic is floorplanned/placed, it makes both placement easier and
> routing easier.
Spot on, Nicholas. One further point; often the time you spend on
Floorplanning is more than recovered in P&R times, certainly for repeatedly
used RPMs.
Cheers, Syms.

In article <313t6uF37n91nU1@uni-berlin.de>,
Symon <symon_brewer@hotmail.com> wrote:
>"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
>news:coibq8$up9$1@agate.berkeley.edu...
>> Running at high utilization is a LOT easier if a large amount of the
>> logic is floorplanned/placed, it makes both placement easier and
>> routing easier.
>Spot on, Nicholas. One further point; often the time you spend on
>Floorplanning is more than recovered in P&R times, certainly for repeatedly
>used RPMs.

And don't forget the performance win.  I have a deliberately dinky 3
pipeline stage encryption core:  placing just PART of the core allows
the 125 MHz timing to be met easily, with a vast fraction of the tool
time.

RLOC is your friend.


-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

All valid points.  99% utilization is probably the slice usage, not the LUT
usage, so you may still have plenty of margin (you are really between 50% and
99% LUT utilization, check the map results for LUT and memory usage.  At 40 MHz,
you will probably not have a problem if you were smart about your design (no
logic with layer upon layer of LUTs).  As the device gets filled, you may find
that routing starts becoming an issue.  That can be mostly alleviated by doing
some floorplanning.  Many of our designs have LUT utilization above 80%.  The
PAR times can get long, especially with less than optimal placement.  At 40 MHz,
you may also be able to take advantage of a multiplied clock to reduce logic
should you get painted into a corner.  I think you've got plenty of wiggle room
to get out of a tight spot if you get there in future design spins.  You may
have to be smart about the design to fit a larger change in.

Nicholas Weaver wrote:

> In article <313t6uF37n91nU1@uni-berlin.de>,
> Symon <symon_brewer@hotmail.com> wrote:
> >"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
> >news:coibq8$up9$1@agate.berkeley.edu...
> >> Running at high utilization is a LOT easier if a large amount of the
> >> logic is floorplanned/placed, it makes both placement easier and
> >> routing easier.
> >Spot on, Nicholas. One further point; often the time you spend on
> >Floorplanning is more than recovered in P&R times, certainly for repeatedly
> >used RPMs.
>
> And don't forget the performance win.  I have a deliberately dinky 3
> pipeline stage encryption core:  placing just PART of the core allows
> the 125 MHz timing to be met easily, with a vast fraction of the tool
> time.
>
> RLOC is your friend.
>
> --
> Nicholas C. Weaver.  to reply email to "nweaver" at the domain
> icsi.berkeley.edu

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

All valid points.  99% utilization is probably the slice usage, not the LUT
usage, so you may still have plenty of margin (you are really between 50% and
99% LUT utilization, check the map results for LUT and memory usage.  At 40 MHz,
you will probably not have a problem if you were smart about your design (no
logic with layer upon layer of LUTs).  As the device gets filled, you may find
that routing starts becoming an issue.  That can be mostly alleviated by doing
some floorplanning.  Many of our designs have LUT utilization above 80%.  The
PAR times can get long, especially with less than optimal placement.  At 40 MHz,
you may also be able to take advantage of a multiplied clock to reduce logic
should you get painted into a corner.  I think you've got plenty of wiggle room
to get out of a tight spot if you get there in future design spins.  You may
have to be smart about the design to fit a larger change in.

>

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

nweaver@soda.csua.berkeley.edu (Nicholas Weaver) wrote in message news:<coif35$vs4$1@agate.berkeley.edu>...
> In article <313t6uF37n91nU1@uni-berlin.de>,
> Symon <symon_brewer@hotmail.com> wrote:
> >"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
> >news:coibq8$up9$1@agate.berkeley.edu...
> >> Running at high utilization is a LOT easier if a large amount of the
> >> logic is floorplanned/placed, it makes both placement easier and
> >> routing easier.
> >Spot on, Nicholas. One further point; often the time you spend on
> >Floorplanning is more than recovered in P&R times, certainly for repeatedly
> >used RPMs.
> 
> And don't forget the performance win.  I have a deliberately dinky 3
> pipeline stage encryption core:  placing just PART of the core allows
> the 125 MHz timing to be met easily, with a vast fraction of the tool
> time.
> 
> RLOC is your friend.


There is another reason to consider hand placement even if you don't
need the perf. When you build up a floorplan its as likely to go
slower as faster so it it has to be done incrementally keeping only
the better placement decisions. As the plan fills out you get a much
better feel for what area different logic funcs take up. Its all very
time consuming though! Worth doing for datapaths, but only for control
logic if timing really forces it.

For instance dualport LUT rams, srl16s, mux4s usually take 2 LUT sites
and have to be paired with a related FF and leave 1 FF site unused.
Apart from those, its almost possible to use up 99% of the FFs in a
datapath as long as say the reg width are even and related registers
are controlled by same signals. With that in mind, it then becomes
possible to adjust the logic design so that more datapath logic will
fall nicely into the unused LUT columns where there might be a row of
plain FFs.

This brings up 1 little gripe with XST mapper. 
When a ck en has large fanout and drives many different regs of
different widths, the FF driving the enables will be split into clones
(good part) but often the branches will enable groups of FFs that is
less optimal and cuts across a slice pair.

In my cpu project, with some 20 regular 16b regs on 1 enable I get
told to remove 1 FF from the middle of a few of these regs because of
this odd splitting which is tiresome. Its too early to manually split
such enables.

Are there any switches to force grouping of replicated FF signals to
stay within  pairs? Timing driven placement seemed to help, as well as
not placing the ck enable FFs.

My other gripe about floorplanning is the LUT structures/names are
liable to change on me even if the logic that created it doesn't so I
try not to place those since they tend to get placed/pulled near the
connected FFs that I did place. Still lots to learn:-)

regards
johnjakson_usa_com