[Fpga-synth] Try out spartan3e projects, questions

[Theo Verelst]

On Sat, 2008-08-16 at 13:04 +0200, Magnus Danielson wrote:
> > I'm currently working on a design with two Virtex-5 330T parts and while 
> > it is true the primitives may be rated at 500MHz, those primitives must 
> > be connected to each other.  If you have any significant combinational 
> > depth and route complexity the max clock speed will rapidly drop to a 
> > few hundred MHz even with significant pipelining and floorplanning.  I'm 
> > not saying it is impossible, but running a complex design at the rated 
> > speed of the device is difficult.  125MHz is easy, 250MHz isn't bad, 
> > 300+ starts to get hard.
> 
> Agree.
> 
> The trick to go upspeed and succseed is not attempting to fill the FPGA. 
> We consider 70% as "full". Beyond that will placement become more and 
> more lengthy and unpredictable, both in convergance and convergance time.
> 
> BRAMs and MULT blocks can be fully utilized most of the time, but LUTs 
> is harder, they require headroom.
> 
> Fiddeling with synthesis options can be a worthwhile process. You can 
> trade between area and speed. Duplicating circuits can make route and 
> placement easier and thus allow higher speeds. Avoiding it means less 
> area but lower speed. There are many things like that. Taking time to 
> make some designs "fit" better is certainly worthwhile. That's where 
> much of the engineering time goes. Small resource usage and much 
> functionality. It is always rewarding when one finds that combination. 
> But you have to start early in trying to make the big picture fit. Also 
> trying to get all of the key aspects on the table, or the redesigns will 
> take both more time and resources than a propper design. It is also 
> important to have a clear view of the nitty gritty aspects so that not 
> too much is hacked in later.
> 
> Cheers,
> Magnus
> _______________________________________________
> Fpga-synth mailing list
> Fpga-synth at rubidium.dyndns.org
> http://rubidium.dyndns.org/cgi-bin/mailman/listinfo/fpga-synth


Well, from the specs and an example LUT-row delay line in the Spartan3e
starter-kit a single LUT plus some interconnect line has a delay
reciprocal of about 500 MHz, and the Xilinx 'Wizard' allows certain
blocks like lookups and MULadds to be designed with over 300 MHz 
throughput, no matter how that is achieved.

The 70 percent of course is not another given than based on the 
Xilinx free (but unfortunately not Open Source) design software, or 
possibly the non-free silicon compilation suite, coming from that 
sort of background, I'd say such rule of the thumb is normally not 
the rule in chip design, but a result of rather detached hardware 
and logical design tracks being brought together by the general 
software. In more normal english, using a HDL isn't what a good chip 
designer will necessarily see as detached from the resulting floorplan 
or routing.

I guess it's like I can feel too that everybody wants to drive 
a sportscar for a few dimes, and that some FPGA's just like the 
3e starterkit uses seem to offer some of that, which is great.

It'll depend on wether you work for Nallatech or want to professor 
a new generation of students (long ago I was into such idea) for
nowadays lets say NVIdia Cuda design or so what your focus will be,
in the first case you'll want even more detached from the hardware 
itself and want to use on top of a HDL something like C-vhdl or so 
to use some hefty FPGAs (which become cheaper I suppose when often sold)
for number crunching. Or in the latter case the sportscars are made
cheap by a few (hopefully) well paid commercial people.

As a student in (EE) network theory I thought the idea of the whole 
silicon compilation track was terribly interesting, and great to see 
at work. The IT world appears to have done it's best to bog down even 
the making of a potentially great scientific calculator in Windos, which
is a shame. I suppose for a hefty notebook a few times bigger than the
spartan 3E has a bearable design response time, currently.

Theo