Fitting functionality in an XC2VP30 FPGA.

Dear All,

I am trying to establish if I can fit the following functionality into
a single FPGA.

I have FPGA resource utilisation statistics (from the ISE tool MAP
process) for four functional blocks. I also have the statistics on the
number of available resources on the XC2VP30 FPGA.

My question is can I use the individual MAP reports to accuratly
estimate if my four seperate functional blocks will fit in the XC2VP30
FPGA?

                 XC2VP30  Block A  Block B  Block C  Block D  Total

Slices           13,696   4,248    2,771    848      5,370    13,237
   Flip-Flops    27,392   5,056    3,406    95       4,888    13,445
   4-Input LUTs  27,392   5,885    3,036    1,581    8,281    18,782

Since each of the four blocks were 'compiled' (MAP reports generated
in the ISE tool) individually no slice contains un-related logic.

The other FPGA resources (DCMs, GCLKs, PPCs etc ... ) are all under
utilised.

My understanding is that since the 'Total' number of slices used is
less than the number of slices available on the 'XC2VP30' no slice
will have to contain un-related logic so my four blocks (Block A - D)
will fit inside my XC2VP30 FPGA.

Is this correct or have I made some critical assumptions regarding
combining functionality within the FPGA and regarding timing aspects?

Regards

Simon

Hi Simon,

if decvice total is 13.696 and A+B+C+D total is 13.237 then I am 99%
positive that combining A+B+C+D in single design ABCD will cause problems.
Unless of course large parts of A,B,C or D are optimized away when combined.
Hm, I take the 99.8% back, lets say I am 80% sure you will have _some_ sort
(possible not related to # of slice resource used) of problems. The ABCD
slice useage can be lower (thats why I reduced the 99% sure to 80% sure)
than the A+B+C+D as the slice utilization ratio may be better but here it
depends how good the design fits and how good the tools really are.

the 'unrelated logic' is not what I you think it is, I think. Unrelated
means that the tools generated additional logic that was not in the original
design, in order to achive performance or routing or any other reason. So
its not directly bound to the slice utilization.

I am sometimes wrong (usually not). Anyway cases where I am wrong or my
guess is totally wrong interest me, so please post some results what
happened with ABCD in single design !

antti
http://gforge.openchip.org

whuuuuuuups!
I checked your domain name ;) well my advice (based on your numbers) is that
you should take larger FPGA (if the A, B, C, D can not be optimzed to use at
least 10% less resources) just to be prepared for in-field design change
that may cause the design to not fit any more.


"stockton" <simon.stockton@baesystems.com> schrieb im Newsbeitrag
news:dbcd481c.0504140211.42f75283@posting.google.com...
> Dear All,
>
> I am trying to establish if I can fit the following functionality into
> a single FPGA.
>
> I have FPGA resource utilisation statistics (from the ISE tool MAP
> process) for four functional blocks. I also have the statistics on the
> number of available resources on the XC2VP30 FPGA.
>
> My question is can I use the individual MAP reports to accuratly
> estimate if my four seperate functional blocks will fit in the XC2VP30
> FPGA?
>
>                  XC2VP30  Block A  Block B  Block C  Block D  Total
>
> Slices           13,696   4,248    2,771    848      5,370    13,237
>    Flip-Flops    27,392   5,056    3,406    95       4,888    13,445
>    4-Input LUTs  27,392   5,885    3,036    1,581    8,281    18,782
>
> Since each of the four blocks were 'compiled' (MAP reports generated
> in the ISE tool) individually no slice contains un-related logic.
>
> The other FPGA resources (DCMs, GCLKs, PPCs etc ... ) are all under
> utilised.
>
> My understanding is that since the 'Total' number of slices used is
> less than the number of slices available on the 'XC2VP30' no slice
> will have to contain un-related logic so my four blocks (Block A - D)
> will fit inside my XC2VP30 FPGA.
>
> Is this correct or have I made some critical assumptions regarding
> combining functionality within the FPGA and regarding timing aspects?
>
> Regards
>
> Simon

would agree to 90% to what Antti said, but my experience is:

if you only need a small amount off all available Slices - means
implementations A,B,C,D on their own - the the tools will use more
Slices than they would take having a "fully loaded" FPGA.

This could be the case here, too: you need 50% of FFs and 70% of LUTs
!?!

If - and only if - there's the possibility that 'some' ressources
could fit into the same Slice, then your complete design will fit...

I'd be interested in the outcome of the story ;-)

> I checked your domain name ;) well my advice (based on your numbers)
is that
> you should take larger FPGA 

didn't get this one...

Jochen

Thanks for your responces guys,

The problem that I have is that I want to use a specific COTS board
(for other unrelated reasons) which has the XC2VP30 FPGA on it, so I
need to make an educated decision as to whether I can fit ABC & Ds
functionality in the XC2VP30 before I commit to buying it.

Otherwise everything gets turned on its head and I will have to find
another suitable COTS board with a larger FPGA or get one desinged and
built (not going to happen says the boss!!)

I am thinking that the only way that I can be sure that ABC & D will
fit it to bring together the functionalty in a single design and
'compile' it in the ISE tool. Problem with that is that D is specific
to the COTS board and I cannot get hold of D before I buy the board, I
think this is called a Catch 22 situation.

Cheers

Simon

P.S. I will keep you posted re. outcome. - Didn't understand about
domain name either !!!

Posted on behalf of Marc:

Hello Simon,

I'm not where I can post a response to your Usenet posting, but I
figured I would email you most of my thoughts...


The short answer is that it varies too much from design to design to
tell you with 100% certainity if it'll fit, without trying it - but in
my experience, your design will almost certainly fit.

The long answer is that the tools are somewhat lazy, and that laziness
makes slice utilization a very poor indicator of how full the design
is.  Well, it's a poor indicator until you surpass 99%.  Then the
tools have to actually start working.  Until that point, the tools
appear to not worry about minimizing slice usage at all (I assume it
does this to improve routability).

Said another way, IMO, slice counts tend to be a worst-than-worst-case
indicator of utilization.  If you can add up slice counts and they
still don't reach the slice count of the target device, you are almost
guaranteed it will fit (the almost is there because nothing is for
certain in engineering until its working!).

We have MANY designs, from 2VP7 through 2VP50, to 4VLX25.  All but one
has slice utilizations approaching 99% and we don't have trouble
fitting in any of them.  The one exception has 86% slices used (for a
design with 70% LUTs used).  Across the other designs, max LUT
utilization is 86%, and max FF utilization is 75%.   That I have seen,
LUT or FF utilization tends to be a much better indicator of device
utilization, and with modern (V2Pro and V4) devices, I don't usually
start even thinking about it until LUTs go over 80% or FF's go over
75%.  You are well under ALL these numbers (slice, LUT, or FF).

Now, all of this assumes your designs are about the size of what they
will be when the project is finished.  And as others have pointed out,
you will need to gauge the likihood (and estimate the possible size)
of any future additions or modifications, even unforeseen ones.

Have fun,

   Marc

:
You will probably be OK.  The mapper tends to put one lut/ff per slice 
when there is lots of room in the device.  Note that your total slice 
count for the individual designs is a bit less than the slice count in 
the device, so even without sharing slices you'll fit.  A better 
indicator is the LUT and FF counts, but with the caution that depending 
on the design you may not be able to pack some of them in the same 
slice.  In your case, I don't see a problem.

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

Howdy Simon,

   I forgot to explain why I mentioned 99% slice usage... doing so
should help confirm your (correct) understanding of unrelated logic.
The tools actually output a message that explains unrelated logic:

NOTES:
  Related logic is defined as being logic that shares connectivity -
  e.g. two LUTs are "related" if they share common inputs.
  When assembling slices, Map gives priority to combine logic that
  is related. Doing so results in the best timing performance.
  Unrelated logic shares no connectivity. Map will only begin
  packing unrelated logic into a slice once 99% of the slices are
  occupied through related logic packing.
  Note that once logic distribution reaches the 99% level through
  related logic packing, this does not mean the device is completely
  utilized. Unrelated logic packing will then begin, continuing until
  all usable LUTs and FFs are occupied. Depending on your timing
  budget, increased levels of unrelated logic packing may adversely
  affect the overall timing performance of your design.

(taken from
http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/sim/sim0020_5.html)

So as you can see from the output message, until it reaches 99%, the
tools almost go out of their way to use up slices before starting to
work a bit harder and put things that don't share inputs together.  If
your unrelated logic is 0%, there is still considerable headroom above
99%.  It's only when unrelated logic packing auto-activates that you
need to be concerned about being over 99%, and even then, it varies
drasticly by design.  Here is the output of one design I helped with a
few years ago in ISE 5.3.3i:

Logic Utilization:
  Total Number Slice Registers:    10,129 out of  18,560   54%
  Number of 4 input LUTs:          13,491 out of  18,560   72%
Logic Distribution:
    Number of occupied Slices:                        9,278 out of
9,280   99%
    Number of Slices containing only related logic:   5,259 out of
9,278   56%
    Number of Slices containing unrelated logic:      4,019 out of
9,278   43%

[note that it is ONLY saying that 43% of the used slices contain
unrelated logic... it isn't saying that utilization is 99% + 43%, or
anything like that]

BTW, this whole discussion about unrelated logic usage only applies if
you leave the -timing option for MAP turned off (at least in ISE 6.x or
7.x).  If -timing is turned on, I believe that slice packing is done
differently such that you won't get an unrelated packing number... in
theend, with -timing you should get better results, but it keeps the
designer a little more in the dark about how full the design really is.


None of this changes the fact that since your total slice usage is less
than your target device, so it should fit with no problems.

Here is another explaination of unrelated logic:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=12191

Summary: in some instances, it can adversely affect routability or
routing delays.  In short, it varies by design. :-)

Good luck,

   Marc

simon.stockton@baesystems.com wrote:
 > Didn't understand about domain name either !!!

I think he's implying that military equipment contractor (BAE Systems) 
== doesn't have to scrimp on a potentially undersized FPGA to save 
(literally) a buck.

Makes sense to me ;-)

As mentioned before the issue is not about money but about the
availavility of a specific COTS board, albeit with a potentially
limiting FPGA XC2VP30 on it.

See previous post.

Thanks to everyone who has contributed, it looks like there still is a
risk about fitting ABC & D in the XC2VP30 but it is smaller that
perhaps I first understood.

Simon

"Erik Walthinsen" <omega@pdxcolo.net> schrieb im Newsbeitrag
news:425F5935.1010009@pdxcolo.net...
> simon.stockton@baesystems.com wrote:
>  > Didn't understand about domain name either !!!
>
> I think he's implying that military equipment contractor (BAE Systems)

its funny that BAE systems appeared again today during my re-search, namly
BAE holds 35% of MBDA and an email from MBDA.fr domain is listed as project
coordinator for the dynamically reconfigurable FPGA project www.reconfig.org
funnyly there is confusing presse announcement from Atmel (a partner of
reconfig org project) from 5th March 2005
http://www.atmel.com/dyn/corporate/view_detail.asp?ref=&FileName=celoxica_3_7.html&SEC_NAME=Product

about is some new product to be expected later this year, but unclear if
thats hardware or just new tools.

> == doesn't have to scrimp on a potentially undersized FPGA to save
> (literally) a buck.
>
> Makes sense to me ;-)

:) correct - for an system to be used in mission critical leave at least 10%
free. To the original poster: even saying that with 80% you can expect some
trouble, I am also sure that it is actually possible to FIT the ABCD into
the target device, specially if D is delivered as HDL source code, you just
may have to use synplify or physical synthesis to get better fit, and again
this may not be needed at all, as the slice count for ABCD may drop by large
% from the sum of A+B+C+D

my wording isnt perfect english as english is the only human language from
the 5 I speak that I havent learned at all. I just had to read the
datasheets and learned the english language by guessing the meaning. I have
also written a disassembler, Processor ISA description and partial
description of the on chip peripherals document by reading 64K binary memory
dump (and knowing nothing more than that 64k binary data) - the chip was
CCU3000 and my learned (by reading binary dump) knowledge was quite correct
as I later got the datasheets as well and compared :)

Antti who is hitting 40 (decimal) on April 21 and has never had the joy to
enjoy a paid vaccation is looking forward in the hope to be afford a real
vaccation with the family - target goal is set for 2006. Thats my dream
antti@truedream.org

comments are welcome in my guestbook http://www.truedream.org/guestbook

PS I am offline for the next 10 days.