FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-14-2005, 11:11 AM
stockton
Guest
 
Posts: n/a
Default 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
Reply With Quote
  #2 (permalink)  
Old 04-14-2005, 11:33 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

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" <[email protected]> schrieb im Newsbeitrag
news:[email protected] om...
> 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



Reply With Quote
  #3 (permalink)  
Old 04-14-2005, 02:20 PM
Jochen
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

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

Reply With Quote
  #4 (permalink)  
Old 04-14-2005, 04:45 PM
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

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

Reply With Quote
  #5 (permalink)  
Old 04-14-2005, 06:04 PM
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

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

Reply With Quote
  #6 (permalink)  
Old 04-14-2005, 09:44 PM
Ray Andraka
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

:
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 [email protected]
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759


Reply With Quote
  #7 (permalink)  
Old 04-15-2005, 05:38 AM
Marc Randolph
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

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/xil...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_d...PagePath=12191

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

Good luck,

Marc

Reply With Quote
  #8 (permalink)  
Old 04-15-2005, 07:03 AM
Erik Walthinsen
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

[email protected] 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 ;-)
Reply With Quote
  #9 (permalink)  
Old 04-15-2005, 07:40 AM
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

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

Reply With Quote
  #10 (permalink)  
Old 04-15-2005, 07:57 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.


"Erik Walthinsen" <[email protected]> schrieb im Newsbeitrag
news:[email protected]
> [email protected] 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/v...C_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
[email protected]

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

PS I am offline for the next 10 days.






Reply With Quote
  #11 (permalink)  
Old 04-15-2005, 08:20 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Fitting functionality in an XC2VP30 FPGA.

Hi Simon,

there is some risk that it may require some tweaking to get it fit and work.
But it should defenetly be possible to fit. If XST synthesis is not good
enough better synthesis tool may be needed. But try to the MAP report for
for ABC when mapped together, and check how much the slice count drops for
ABC from A+B+C. If the slice count doesnt drop and the and adding D would
not also not yield to better slice utilization ratio, then there could be
fit problem.

Antti


<[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> 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
>



Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Ml310(xc2vp30) with ppc 405,multi processor share memory? stella FPGA 2 02-25-2005 11:08 AM
Xlilinx (xc2vp30-5fg676) Fred FPGA 3 11-22-2003 09:10 AM
fitting Xilinx CPLD - I/O Pin Termination Valentin Tihomirov FPGA 1 11-13-2003 03:33 PM


All times are GMT +1. The time now is 01:45 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved