Spartan 3E slower that Spartan 3?

There is a second reason to be anonymous.. I get 200+ spam emails a day.. so I don't have a valid email address for publicly searchable news groups... but I have been an engineer for over 20 years... and my email address is about as old too... In fact I designed the modems that connected the ISP to the university. I think it had a 3000 series fpga from memory :-)

Simon

Spam avoidance is a good idea, but it does not require anonymity. You cn obfuscate your return address, but still reveal your identity to us humans. Peter

Especially when messages get posted 4 times ;)

Cheers, Jon

Hi Mr. Mercury,

You are correct that Spartan-3E FPGAs use the same general logic design as Spartan-3 FPGAs, are manufactured on the same 90 nm process technology as Spartan-3 FPGAs, and use the same manufacturing facilities. So why are Spartan-3E speeds files slower?

The current Spartan-3E speed file is strictly based on conservative simulation results. Once silicon and manufacturing characterization is complete, the values are typically improved to better match real silicon.

In theory, Spartan-3E FPGAs will be about the same performance as Spartan-3 FPGA. However, in theory, theory and practice are identical but in practice they are usually different. :-) We're just being conservative until characterization is complete.

Also, look for improved performance for some architectural elements. The new Spartan-3E multiplier has additional pipelining options that boost performance. Likewise, there is new differential DDR circuitry (not to be confused with DDR SDRAM) that relaxes the critical timing path by 2X.

In specific, we fully expect a Spartan-3E -4 speed grade to support DDR266 SDRAMs, just like a Spartan-3 -4 speed grade.

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

All,

From the GPD folks:

The Spartan-3E has the same CLB and same process as Spartan-3 and therefore the majority of the timing numbers are expected to be the same. There are improvements to the I/O, DCMs, clocks, and multipliers, which may result in some minor improvements in performance in those areas.

The reason for the difference right now is that these are the advanced (preliminary, whatever) numbers, which are based on simulations. The "real" speeds file will come later, after the part is fully characterized.

Austin Lesea

What's GPD btw ?

Sylvain

General Products Division

As opposed to what I am in, APD, Advanced Products Division (we think very highly of ourselves.....)

Both groups report to FPG, or the Field programmable gate array Products Group (I just love how we make up obscure acronyms).

Of course, next week, it may all change again (structure is a fluid thing, and even when the structure isn't changing, the names might be).

Yet another reason to always talk to the GSD (Global Services Division) or as it has always been called, the Hotline. They get a new roadmap everytime things change, and they have direct access to the 'fire chiefs' who handle escalated cases (cases involving "lines down" issues).

Austin

Not for arithmetic in the fabric if you believe the speed files (and I have to):

parameter V2Pro -7 V4sx55-10 (slice L) (slice M) topcyf 560-731 460-572 465-576 tbyp 73 98 98 tdick 174-208 299-1053 293-1162

Time to get on the carry chain is a little faster, but time per bit (tbyp) is 30% slower and time to get off the carry chain is 200+% slower. Xilinx says use DSP48 adders for anything over about 12 bits. Yes, that makes the design faster, but there is not nearly enough adders this way, and unless you need a mult in front of your add, you throw away one of the multipliers. Real world DSP designs have more than just multiply accumulates. More typically, there is an order of magnitude or more difference in the number of multipliers vs the number of adders. I'm currently working a design that illustrates the slow down in the carry chain in a way that really hurts. In this case, it is a beamforming receiver that needs nearly all the multipliers, plus needs to do a large number of adds, which are forced to be in the fabric. The achievable clock speed is no greater than the V2Pro version of the design because of this carry chain slow down. In order to be used as a

350+ MHz device, BOTH the fabric and the DSP48's have to be able to work at those speeds, and for realistic designs, that includes arithmetic in the fabric.

Austin, please tell me that these numbers are going to improve substantially and soon. It is really dissappointing to see the carry chains lose performance despite the shift to 90nm. Being that this is a real design, not a lab exercise, I have to use the results of the timing analyzer (which means the speed file numbers are treated as gospel as far as the customer is concerned) to get the design past the review.

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

the

to

I doubt many people who need a low-cost device can afford a V4...

If you want value AND blazing speed, I'd suggest taking a look at Altera's Cyclone/Cyclone II, which are 50-60% faster than Spartan-3 (and thus 70-80% faster than Spartan-3E? Eek). But don't trust me. Download our Quartus II Web Edition and give things a whirl.

As for Austin's story that Xilinx is guard-banding the timing models by a lot, I'm not sure why they need to do that. What is the cause for the huge uncertainty? They should know the process well and thus have good-quality transistor models and capacictance tables. And the architecture really hasn't changed. Shouldn't a good (

ahhh... but Cyclone doesn't do bus lvds or have on chip terminators.

But in reality.. if you are after blazing speeds and are thinking cheap.. think again.. have you seen the price of the dual core X86 processors ???

Simon