comp.arch.fpga : Selection of Device

of system gates) at the initial stage of the project.

Guess the number of registers or flip-flops in your design ( you get 2 ffs per slice) and guess the amount of RAM (you get 18 K bits per BlockRAM) and guess the number of I/O. Gate count is not a meaningful number in FPGAs.

That should give you a start> Hi all,

of system gates) at the initial stage of the project.

And, if your desing will work with a clock of more than, say, 50 MHz, double or triple your stimates to take into account possible routing and FF duplication problems.

BTW, double or triple it anyway. You will feel happier, with not much cost increase.

Bets regards,

Zara

I can suggest three alternative selection strategies. Sadly, two are rubbish!

1) Start with your budget. Fit the biggest part you can afford. 2) Use the smallest part available. You'll find that necessity becomes the mother of invention. 3) Ask your FAE about your specific design.

Cheers, Syms. :-)

Inviato da X-Privat.Org - Registrazione gratuita

Nice one. probably the best.

And budget grows exponentially, due to hours lost in redesigning and using obscure device-dependent resources to get the thing to work. Or incrementing the number of tasks done by SW. You know, SW engineers tend to be untreatable.

If you have one. If he knows the modern components available. If it is not yourself.

Cheers,

Zara

Nice one. probably the best.

And budget grows exponentially, due to hours lost in redesigning and using obscure device-dependent resources to get the thing to work. Or incrementing the number of tasks done by SW. You know, SW engineers tend to be untreatable.

If you have one. If he knows the modern components available. If it is not yourself.

Cheers,

Zara

Nice one. probably the best.

And budget grows exponentially, due to hours lost in redesigning and using obscure device-dependent resources to get the thing to work. Or incrementing the number of tasks done by SW. You know, SW engineers tend to be untreatable.

If you have one. If he knows the modern components available. If it is not yourself.

Cheers,

Zara

One thing you can do is to identify blocks and try and size those. If the function is something you could buy an IP for then have a look at datasheets for those products to get an idea on size. There are a lot of IP products listed with datasheets on the Xilinx and Altera etc websites. If it something else you can always give some more details to the group and someone will probably have an idea on size.

From the design end certain things will limit your selection like the numbers of I/O needed or features like RAM, flops, luts etc. As said elsewhere it is worth planning contingency - don't start with the expectation of fully using the largest device in a given footprint. Go mid-range as expectation but have the bigger parts in mind as project savers. We use the Spartan-3s in a FG456 package a lot in our products and there is 4 sizes available with a notional size spread of x5 so you can have a wide range in size. Most Xilinx packages have a choice of size and there is a nice table near the end of section1 of the datasheet showing what is available.

Failing all of that just get stuck in and build some modules to run through the tools and get some real sizes.

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


"Pravin G"  wrote in message 
news:ee9c84b.-1@webx.sUN8CHnE...
> Hi all,
>
> We want to implement a design in a spartan - 3. and select a device (in 
> terms of system gates) at the initial stage of the project.
>
> Is there any method for this.

Pravin G schrieb:

of system gates) at the initial stage of the project.

Ask the designer who will implement the design for an estimate. (If s/he has a boss, ask the boss) There really is no other way because it is not uncommon to have a factor of 10 in LUT count between FPGA designers.

For example I just saw a design that used 90% of the area for a huge mux that allowed to read back all parameter registers. Using a shift register instead or getting rid of the readback requirement would improve area 10x.

Sometimes there are obvious limits as Peter suggested: The number of I/Os, number of BRAMs, number of multipliers. But LUT count is impossible to predict without knowing the engineer.

Kolja Sulimma