99% Utilisation !

untill and unless you are able to meet your design constraints (speed,
power etc) with acceptable software/manual efforts, you should really
not worry about the device utilization.
I always try to fit the design in the smallest possible device.
Sometimes i am able to use more than 90% LUT and sometimes quite
lesser. everything depends on your design constraints


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

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


Hmmm. Every time I've used this it's always slowed down my design.
 
Cheers,
JonB

"Jon Beniston" <jon@beniston.com> wrote in message 
news:e87b9ce8.0412010145.4af756ec@posting.google.com...
>> 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.
>
>
> Hmmm. Every time I've used this it's always slowed down my design.
>
> Cheers,
> JonB

JonB,

It definitely takes map longer to run.  I was using XST 6_2i sp3 with a goal 
of 100 MHz (Spartan 3 - 1500).  I initially kept all the hierarchy, but when 
I went over 90%, I started to get nervous and had XST flatten the design. 
The utilization went down by 5% to 7%, but the timing deteriorated. After 
several recode attempts to speed up the critical path, only to have another 
unrelated path show a slow down, I went to timing driven map and used 
selective keep hierarchy attributes in some of the modules "perhaps a lazy 
man's floor plan".  Utilization stayed about the same, and internal timing 
was met with ease.  Perhaps I attributed too much of timing improvement to 
the timing driven map, and not enough to the selective keep hierarchy.

-Newman

John,

There is something you can do about it:  use a local copy of the control
signal and put a keep buffer on it. The snippet below is a simple VHDL
example:

signal lcl_ce std_logic;
attribute syn_keep boolean;
attribute syn_keep of lcl_ce:signal is true;

begin
lcl_ce<= ce;

process(clk)
begin
if rising_edge(clk) then
    if lcl_ce='1' then
        q<=d;
    end if;

The keep buffer causes the local signal to be named differently so that
the local signal doesn't exceed the fan out limit.  That keeps all the local
destinations for the control signal on the same named net, which in turn
keeps them able to be mapped with the desired placement.  The keep
buffer itself is removed during PAR.  Use a separate local copy for each
register.

For the LUTs, if you keep the logic to a single level between FFs, the
mapper does a pretty decent job at keeping the LUT with the FF.
Unfortunately, it doesn't do so well keeping a LUT near a second LUT
when there is no FF between, and as you mention, the combinatorial
names are not always consistent from run to run, especially with tool
version changes in the mix.  You can do a little better with the names
by using the syn_keep on the intermediate signal to force a particular
partitioning of the logic between LUTs, and it will usually keep the name
of the forced signal on the first LUT (but not always; depends on the tool).

Hope that helps!





john jakson wrote:

> 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

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

I've done this some time ago with a XC2S30 having 2 LUTs left and
successfully p&r and then targettting onto some real hardware. I also have a
test build that we use on our Broaddown2 XC3S400 that uses every I/O and
99%+ of registers with no problems.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk

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

Ray Andraka <ray@andraka.com> wrote in message news:<41AE683C.E925DA23@andraka.com>...
> John,
> 
> There is something you can do about it:  use a local copy of the control
> signal and put a keep buffer on it. The snippet below is a simple VHDL
> example:
> 


snipping

Thanks Ray, I will Verilog those suggestions into the layout, I'm sure
that will help.

regards
johnjakson_usa_com