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

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" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

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

is that

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

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:

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

Good luck,

Marc

snipped-for-privacy@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

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

funnyly there is confusing presse announcement from Atmel (a partner of reconfig org project) from 5th March 2005

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

:) 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 snipped-for-privacy@truedream.org

comments are welcome in my guestbook

PS I am offline for the next 10 days.

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

schrieb im Newsbeitrag news: snipped-for-privacy@l41g2000cwc.googlegroups.com...